Recrutement · July 29, 2026 · 9 min de lecture

Comment recruter un ingénieur IA : compétences à tester en 2026

Comment recruter un ingénieur IA en 2026 : ce que le rôle implique réellement, la discipline d'évaluation qui le distingue d'un ingénieur en machine learning, et comment la tester.

← Fait partie de The five pillars of hiring: what assessments measure

Ce guide s'adresse aux responsables du recrutement et aux leaders en ingénierie qui ouvrent un poste qui n'existait pas il y a trois ans. Un ingénieur IA construit des fonctionnalités produit reposant sur des LLM — pipelines de récupération, harnais d'évaluation, orchestration de prompts et d'outils, le tout dans un budget de latence et de coûts — et le poste existe parce que les modèles de fondation ont transformé « entraîner le modèle » en « concevoir autour du modèle ». Vous en avez besoin lorsque plusieurs fonctionnalités dépendant de modèles sont déjà en production et que le travail de les maintenir fiables ne s'arrête jamais ; vous n'en avez pas besoin lorsqu'une seule fonctionnalité de chatbot pourrait confortablement s'intégrer dans votre équipe existante. Le rôle est généralement rattaché à l'ingénierie, proche de la surface produit qu'il alimente plutôt que dans un groupe de recherche. Voici la partie inconfortable : c'est le titre le plus rebaptisé de la tech en ce moment, et la compétence qui compte vraiment — savoir comment vous savez que la fonctionnalité fonctionne — est celle qui n'apparaît jamais sur un CV.

Que fait réellement un ingénieur IA ?

Un ingénieur IA livre des fonctionnalités produit construites sur des modèles qu'il n'a pas entraînés. Une semaine type : affiner un pipeline de récupération qui continue de remonter des documents obsolètes, écrire un ensemble d'évaluation qui détecte la régression avant les utilisateurs, réduire une chaîne de prompts qui a discrètement doublé le budget de latence, et déboguer pourquoi l'agent boucle sur un appel d'outil malformé à 2h du matin. Le modèle est un composant ; l'ingénierie est tout ce qui l'entoure.

C'est la version honnête du travail, et elle ne ressemble pas du tout à la démo. Remarquez à quel point peu de ce travail consiste à « écrire un prompt astucieux ». Le prompt, c'est la petite heure facile. Les journées difficiles sont consacrées aux éléments qui rendent une fonctionnalité LLM sûre à déployer auprès de vrais utilisateurs :

• Construire et maintenir le pipeline de récupération — découpage, indexation, classement — pour que le modèle réponde à partir du bon contexte plutôt que d'en inventer un avec assurance.
• Orchestrer les prompts et les outils : enchaîner les appels, connecter le modèle aux fonctions, gérer le cas où un outil retourne des données incorrectes et où le modèle les croit quand même.
• Posséder le harnais d'évaluation — les ensembles d'évaluation, la suite de régression, les vérifications hors ligne et en ligne qui répondent à la seule question qui compte : cette fonctionnalité fonctionne-t-elle vraiment ?
• Tenir un budget de latence et de coûts : mettre en cache ce qu'on peut, router les requêtes peu coûteuses vers des modèles moins chers, et connaître au centime ce que coûte une fonctionnalité pour mille appels.
• Traquer les modes de défaillance avant que les clients ne les trouvent — hallucination, injection de prompts, dérive silencieuse lorsque le modèle sous-jacent change sous vos pieds.
• Faire tourner tout cela en production avec une vraie journalisation, de vrais mécanismes de repli, et un plan pour le jour où le fournisseur déprécie le modèle sur lequel vous avez construit.

En avez-vous vraiment besoin ?

Vous avez besoin d'un ingénieur IA une fois que vous disposez d'une vraie surface LLM — plusieurs fonctionnalités adossées à des modèles en production, une charge d'évaluation qui ne s'arrête jamais, et une ligne de coûts qui commence à faire mal. En dessous de ce seuil, un bon ingénieur logiciel doté d'une véritable AI fluency y répond, et ouvrir le poste trop tôt signifie simplement payer une prime pour quelqu'un qui passera la plupart de son temps sur du travail backend ordinaire.

Soyez donc honnête sur votre échelle avant de publier l'offre. Si vous avez une seule fonctionnalité de chatbot et un wrapper autour d'une API unique, la personne qu'il vous faut est un bon ingénieur logiciel capable de travailler aisément avec un modèle — consultez comment recruter un ingénieur logiciel et évaluez l'AI fluency en plus. Si votre problème est d'entraîner ou d'affiner des modèles plutôt que de construire dessus, vous cherchez plutôt le côté orienté recherche du spectre — c'est un recrutement entièrement différent, couvert dans comment recruter un ingénieur en machine learning. L'ingénieur IA gagne sa place dans le milieu complexe : des fonctionnalités LLM en production avec suffisamment de volume pour que l'évaluation, les coûts et le travail sur les modes de défaillance deviennent une discipline à temps plein plutôt qu'une quête secondaire.

Quelles compétences distinguent un véritable ingénieur IA d'un imposteur rebaptisé ?

Chaque titre créé par l'essor de l'IA attire des CV rebaptisés, et celui-ci en attire le plus : un après-midi à suivre un tutoriel d'API se transforme en « ingénierie IA » sur un CV. Le candidat rebaptisé peut décrire les prompts qu'il a écrits. Le vrai peut vous dire comment il savait que la fonctionnalité fonctionnait — ce qui est toute la nature du poste. Trois compétences tracent la ligne, et aucune d'elles ne se met bien en valeur sur un CV.

• La discipline d'évaluation — la compétence définissante. Ils construisent l'ensemble d'évaluation avant de faire confiance au correctif, distinguent l'évaluation hors ligne de l'évaluation en ligne, et traitent « ça avait l'air bien quand j'ai essayé » comme un aveu, pas comme une preuve.
• La réflexion sur les modes de défaillance — ils nomment les hallucinations, l'injection de prompts et la dérive sans y être invités, et conçoivent pour le cas où le modèle se trompe plutôt que de supposer qu'il a raison. Ils savent qu'une fonctionnalité qui fonctionnait la semaine dernière peut casser quand le fournisseur met silencieusement à jour le modèle.
• L'ingénierie des coûts et de la latence — ils raisonnent en tokens et en millisecondes, savent quand un modèle moins cher est suffisant, et peuvent vous dire ce que coûte une fonctionnalité à grande échelle sans chercher une calculatrice.
• La maîtrise de la récupération et de l'orchestration — de vrais pipelines, pas un seul appel d'embedding : ils réfléchissent au découpage, au classement, et à ce qui se passe quand la récupération ne retourne rien d'utile.
• Suffisamment d'ingénierie logicielle pour livrer — journalisation, mécanismes de repli, versionnement du prompt comme du code. Un ingénieur IA qui ne peut pas faire tourner sa fonctionnalité en production est un prototypeur avec une belle démo.

Le moyen le plus rapide de détecter un ingénieur IA rebaptisé est de lui demander comment il savait que sa dernière fonctionnalité fonctionnait. Le vrai parle de l'ensemble d'évaluation et des modes de défaillance qu'il a traqués. L'imposteur parle du prompt dont il était fier. Même question, réponse complètement différente.

Comment tester ces compétences ?

Vous ne pouvez pas révéler la discipline d'évaluation uniquement par des questions, car le candidat rebaptisé a lu les mêmes articles de blog que vous. Le seul signal fiable est le travail réaliste : mettez une fonctionnalité LLM réaliste devant lui, donnez-lui un modèle avec lequel travailler, et observez comment il le dirige, vérifie ses résultats et le corrige quand il est faussement confiant. C'est le prisme AI fluency — vous évaluez la relation de travail entre la personne et le modèle, pas sa mémoire des schémas de prompts.

Construisez la tâche autour d'une fonctionnalité défaillante de manière intéressante : un endpoint de récupération retournant des réponses fluentes mais fausses ; un agent qui boucle sur un mauvais appel d'outil ; une chaîne de prompts qui fait silencieusement exploser le budget de latence. Puis observez. Recourt-il à une évaluation avant de faire confiance à son propre changement ? Nomme-t-il un mode de défaillance que vous n'avez pas mentionné ? Remarque-t-il l'implication en termes de coûts du modèle qu'il vient de choisir ? Un test de mise en situation professionnelle comme celui-ci prédit bien mieux le comportement au travail qu'un tableau blanc, et l'exécuter dans un AI Sandbox — où un modèle est vraiment disponible plutôt qu'interdit — est la seule façon d'observer le comportement AI fluency qui définit le rôle. Pour le noter de manière cohérente, comment évaluer l'AI fluency et le Cadre 4D — Delegation, Description, Discernment, Diligence — vous donnent une grille ; Discernment et Diligence ont le plus de poids pour un ingénieur IA, car détecter les erreurs du modèle est toute la mission. Oui, c'est le type d'exercice que notre plateforme propose ; une version maison avec un dépôt défaillant et un chronomètre vous apprendra la plupart des mêmes choses.

À quoi ressemble la boucle d'entretien ?

Gardez-la courte — les ingénieurs IA talentueux ont plusieurs offres et une boucle lente les perd. Visez un test de mise en situation professionnelle plus un entretien structuré, pas six tours de « feeling ». Un entretien structuré signifie les mêmes questions, dans le même ordre, et la même grille d'évaluation pour chaque candidat, ce qui rend la comparaison équitable et la décision défendable.

• Évaluation sur les compétences, pas sur le pedigree — une tâche courte et pertinente pour le rôle que tout le monde réalise dans les mêmes conditions, remplaçant le tri par CV. C'est le recrutement AI-native, et il élargit le vivier aux ingénieurs autodidactes qui ont appris ce métier faute de diplôme pour cela.
• Le test de mise en situation — la session sur la fonctionnalité défaillante dans le sandbox, notée sur la discipline d'évaluation, la réflexion sur les modes de défaillance, et la conscience des coûts et de la latence.
• Un intervieweur technique passe en revue le travail du candidat avec lui : pourquoi ce correctif, comment l'avez-vous vérifié, que vérifieriez-vous avant de déployer ? L'histoire de la vérification compte plus que le correctif.
• Un entretien comportemental structuré sur l'appropriation et la collaboration — comment ils ont géré une fonctionnalité déployée qui a ensuite dysfonctionné en production.
• Une grille d'évaluation par compétence, remplie indépendamment avant que quiconque compare ses notes, pour que la voix la plus forte dans le débriefing ne devienne pas la décision.

Qu'en est-il de la rémunération et de la séniorité ?

Nous ne publions pas de chiffres de salaires — le marché de ce rôle se recalibre chaque trimestre et tout chiffre ici serait faux au moment où vous le liriez. Qualitativement, les ingénieurs IA commandent une prime par rapport aux ingénieurs logiciels ordinaires en ce moment, car l'offre de personnes dotées d'une véritable discipline d'évaluation est mince et la demande ne l'est pas. Ne laissez pas cette prime vous tenter de sur-niveler : un ingénieur de niveau intermédiaire avec un vrai instinct pour les modes de défaillance vaut plus pour une équipe de fonctionnalités LLM qu'un titre senior avec une maîtrise des tutoriels de prompts. Comparez par rapport à votre propre marché pour l'ingénierie logicielle, ajoutez une prime pour la compétence AI-native démontrée que vous avez réellement observée dans le test de mise en situation, et ancrez l'offre sur des preuves plutôt que sur le terme tendance dans le titre.

Les 90 premiers jours : à quoi ressemble la réussite ?

Un ingénieur IA talentueux passe le premier mois à réduire votre incertitude, pas à ajouter des fonctionnalités. À la quatrième semaine, il devrait avoir construit ou renforcé un ensemble d'évaluation pour une fonctionnalité qui n'en avait pas, et vous avoir dit quelque chose d'inconfortable et de vrai sur ses performances réelles. C'est le signe révélateur : un bon recrutement rend vos fonctionnalités adossées à des modèles mesurables avant de les rendre plus sophistiquées.

• Semaines 1 à 4 — cartographie les fonctionnalités LLM existantes, trouve celles qui fonctionnent sans vraie évaluation, et met en place un ensemble d'évaluation qui fait apparaître une régression que personne n'avait remarquée.
• Semaines 4 à 8 — livre un correctif sur un mode de défaillance important : une faille d'injection de prompts corrigée, un pipeline de récupération qui arrête d'halluciner sur un contexte vide, un mécanisme de repli pour le jour où le modèle se comporte mal.
• Semaines 8 à 12 — maîtrise une ligne de coûts ou de latence, et laisse derrière lui un moyen de la maintenir : un budget, un chemin de routage moins coûteux, un tableau de bord que l'équipe regardera vraiment.
• Tout au long — rend la relation de l'équipe avec le modèle plus honnête. Les fonctionnalités ne sont pas nécessairement plus sophistiquées au jour 90 ; elles sont mesurables, moins coûteuses à faire fonctionner, et moins susceptibles de vous embarrasser en production.