Imaginez qu’un voisin vous envoie un message : « Pouvez-vous m’aider samedi? Il me faut quelqu’un de fort, avec une voiture, qui sait déplacer des meubles. » Avant de dire oui, vous posez quelques questions. Qu’est-ce qu’on déménage? Combien d’étages? Y a-t-il un ascenseur? Souvent, la vraie réponse est simple : il y a un divan lourd qui ne passe pas par la porte. « Fort, avec une voiture, qui sait déplacer des meubles » était l’idée que le voisin se faisait de l’aide nécessaire. Le divan est le vrai problème.
Une offre d’emploi fonctionne de la même façon. Elle décrit la personne qui, selon l’équipe, pourra résoudre son problème. La liste des compétences correspond à la partie « fort, avec une voiture ». Avant de vous demander « Ai-je ces compétences? », trouvez le divan : quel problème cette équipe doit-elle résoudre? Une fois ce problème compris, vous pouvez repérer les lignes importantes, les mots sans substance et les questions à poser.
L’offre ci-dessous concerne une entreprise qui n’existe pas. Nous l’avons créée à partir de 13 offres réelles pour des postes d’ingénieur en apprentissage automatique. Elles venaient de banques, d’entreprises de technologie financière, de livraison et de transport à la demande, et d’un marché en ligne. Nous avons conservé leurs éléments typiques : les parties claires, les parties vagues et les petits problèmes des offres réelles. Puis nous avons tout regroupé dans une seule entreprise. Le guide peut ainsi utiliser la même équipe et le même problème.
Fennick livre des produits d’épicerie et de pharmacie au Canada le jour même. Elle compte environ 600 personnes, a son siège social à Toronto et dessert 14 villes. Lors d’une journée normale, les clients passent environ 85 000 commandes. Un livreur récupère chaque commande dans un magasin partenaire et l’apporte à la porte du client.
Avant le paiement, l’application affiche un délai de livraison : « Arrive dans environ 35 minutes ». Ce nombre vient d’un modèle d’apprentissage automatique. L’équipe Delivery Intelligence est responsable de ce modèle et de quelques autres. C’est une petite équipe : cinq ingénieurs en apprentissage automatique, deux scientifiques des données, un gestionnaire de produit et un gestionnaire d’ingénierie. Cette offre vise à ajouter un ingénieur en apprentissage automatique.
Description de poste
Ingénieur en apprentissage automatique, Delivery Intelligence
Fennick · Toronto, Ontario
Hybride : 2 jours par semaine au bureau
Temps plein
135 000 – 170 000 $ CA + prime + participation au capital
Fennick livre des produits essentiels d’épicerie et de pharmacie à votre porte le jour même, dans 14 villes canadiennes. Notre équipe place les clients au centre de ses décisions et s’appuie sur les données. Nous avançons vite et assumons la responsabilité des résultats. Chaque jour, nos modèles aident des centaines de milliers de personnes à planifier le souper ou à récupérer des médicaments. Ils les aident aussi à obtenir des couches avant l’heure du coucher.
Delivery Intelligence crée les modèles qui soutiennent notre promesse de livraison. Ils comprennent le délai de livraison estimé (ETA) affiché dans l’application et les prévisions de demande pour planifier les effectifs de livreurs. Et ce n’est pas tout. Comme ingénieur en apprentissage automatique, vous serez responsable de tout le cycle de vie des modèles. Cela comprend la définition du problème, les données, l’entraînement, le déploiement, la surveillance et le réentraînement. Vous nous aiderez à améliorer l’exactitude de nos promesses de livraison, surtout aux heures de pointe.
Concevoir, entraîner et déployer des modèles d’apprentissage automatique qui prédisent les délais de livraison, la demande et les effectifs de livreurs.
Créer et maintenir un service de modèles en production capable de gérer un volume croissant avec une faible latence.
Créer des pipelines de variables, par lots et en temps réel.
Concevoir et mener des expériences (tests A/B) pour mesurer l’effet des changements apportés aux modèles.
Surveiller les modèles en production et les améliorer au fil du temps.
Collaborer étroitement avec les scientifiques des données et les équipes de produit, d’ingénierie et d’exploitation.
Explorer comment les LLM et l’IA générative peuvent améliorer nos produits.
Au moins 4 ans d’expérience dans la création et la mise en production de systèmes d’apprentissage automatique, ou 2 ans avec un doctorat.
Solides compétences en Python et en SQL.
Bonne compréhension de l’apprentissage automatique, du gradient boosting (amplification par gradient) à l’apprentissage profond.
Expérience approfondie avec au moins un cadre logiciel d’apprentissage profond (PyTorch ou TensorFlow).
Expérience avec des outils de MLOps (exploitation des systèmes d’apprentissage automatique) comme Kubeflow, Airflow, MLflow, SageMaker, Feast ou Tecton.
Expérience en traitement distribué des données (Spark, Ray ou Dask).
Expérience avec Docker, Kubernetes, Terraform et la CI/CD (intégration et déploiement continus).
Maîtrise des outils de programmation avec l’IA, comme Cursor ou Claude Code.
Une préférence pour la simplicité : vous choisissez la solution la plus simple qui fonctionne.
Maîtrise ou doctorat en informatique, en statistique ou dans un domaine connexe, de préférence.
Cette offre concerne un poste vacant existant. L’expérience de travail au Canada n’est pas requise. Nous utilisons des outils d’IA pour aider à trier les candidatures. Une personne examine chaque candidature avant toute décision. Si vous avez besoin d’une mesure d’adaptation à une étape du processus, informez notre équipe de recrutement.
Offre d'emploi composite pour une entreprise fictive, créée à partir de 13 offres réelles d'ingénieur en apprentissage automatique.
Avant de comparer l’offre à votre CV, répondez à trois questions à son sujet. Écrivez vos réponses. Cela prend environ dix minutes. Comparez-les ensuite aux nôtres ci-dessous.
Quel problème l’équipe doit-elle résoudre? Décrivez-le en une phrase, sans nommer d’outils.
Qui voit ce que le modèle produit, et quelles sont les conséquences pour ces personnes quand il se trompe? Pensez à plus d’un groupe de personnes.
Trouvez deux lignes qui ne concordent pas. Une bonne offre raconte une seule histoire. Où celle-ci en raconte-t-elle deux?
Nos réponses
1. Le problème. Les clients voient un délai de livraison avant de payer. Aux heures de pointe, ce délai n’est pas assez fiable. Fennick a besoin de quelqu’un pour améliorer l’estimation et maintenir sa qualité quand les conditions changent. L’indice se trouve dans une courte phrase : « améliorer l’exactitude de nos promesses de livraison, surtout aux heures de pointe ». C’est le divan. Presque tout le reste de l’offre décrit des façons de le déplacer.
2. Les personnes et le coût d’une erreur. Il y a au moins trois groupes.
Les clients voient l’estimation. Si elle annonce 35 minutes et que la commande arrive en 60 minutes, le client est fâché. Il écrit au soutien et peut demander un remboursement. Certains attendent des médicaments, pas seulement leur souper.
Le personnel de soutien et d’exploitation gère les messages de clients fâchés et planifie les effectifs de livreurs selon les prévisions de demande.
L’entreprise Fennick perd de façon moins visible quand le délai estimé est trop long. Un client qui voit « 90 minutes » peut fermer l’application et commander ailleurs.
Une erreur coûte donc de l’argent dans les deux sens, mais pas le même montant. Un retard fait plus de tort qu’une arrivée en avance. Et « toujours annoncer un délai plus long » n’est pas non plus une solution. L’offre ne dit rien sur ce compromis. C’est un signe que les entrevues aborderont ce sujet.
3. Deux lignes qui ne concordent pas. Il y en a quelques-unes. Voici celles que nous avons remarquées en premier.
Le gradient boosting, mais une expérience approfondie avec PyTorch ou TensorFlow. Les modèles de délai de livraison et de demande apprennent habituellement à partir de tableaux : une ligne par commande. Les colonnes comprennent le magasin, la distance, l’heure et le nombre de commandes en cours. Pour ces données, les arbres à amplification par gradient (par exemple LightGBM ou XGBoost) sont un choix courant et efficace. Alors pourquoi exiger une « expérience approfondie » avec un cadre logiciel d’apprentissage profond?
« Une préférence pour la simplicité », à côté d’une liste de neuf outils de MLOps. Aucune équipe de cinq ingénieurs n’utilise Kubeflow, Airflow, SageMaker, Feast et Tecton ensemble. La liste dépasse les besoins du travail.
« Responsable de tout le cycle de vie des modèles », mais aucun mot sur la qualité des données ou les périodes de garde. Rien non plus sur ce qui arrive quand le modèle se trompe. Si vous êtes responsable de toute la vie d’un modèle, ces éléments occupent une grande place dans le travail.
Si vos réponses sont différentes, ce n’est pas un problème. C’est l’habitude qui compte : commencez par le problème et les personnes, puis regardez les outils. Dans les entrevues, la conversation portera sur le délai de livraison estimé, les clients et les données. Les outils seront abordés seulement comme moyens de résoudre ce problème.
Cherchez le processus d’entrevue dans l’offre. Il n’y est pas. Parmi les 13 offres réelles que nous avons étudiées, aucune ne décrivait les étapes des entrevues. C’est normal, et ce n’est pas un mauvais signe. Cela signifie que vous devez poser la question au recruteur lors du premier appel. Nous décrivons les six étapes de Fennick dans Le déroulement des entrevues.
À la page suivante, nous lisons l’offre ligne par ligne. Nous disons franchement ce qui est vraiment requis, ce qui est seulement souhaité et ce qui manque. Nous indiquons aussi qui devrait postuler et quelles questions poser à chaque étape.
