Recrutement · August 2, 2026 · 13 min de lecture

Questions d'entretien pour ingénieur IA : comment évaluer les réponses

Questions d'entretien pour ingénieur IA à destination des responsables du recrutement : à quoi ressemblent les bonnes et mauvaises réponses sur la RAG, la conception d'agents et la fiabilité, avec une approche de notation.

← Fait partie de Les cinq piliers du recrutement : ce que les évaluations mesurent

Ce guide est écrit pour le responsable du recrutement ou le lead technique qui mène la boucle pour un ingénieur IA — la personne que vous placez dans des fonctionnalités LLM en production qui doit les maintenir honnêtes, rapides et abordables. Il n'est pas écrit pour le candidat, bien qu'un candidat soit bienvenu à le lire et à apprendre exactement ce que vous cherchez. Cet aveu est important, car il nomme le problème que ces questions d'entretien pour ingénieur IA doivent surmonter : en 2026, les candidats se préparent avec un assistant, et toute question que vous pouvez formuler clairement peut recevoir une réponse claire de quelqu'un qui n'a jamais livré un pipeline de récupération de sa vie. Une liste de questions mémorables est un examen divulgué. Ce guide vous donne donc plus qu'une liste. Pour chaque question, il vous dit ce qu'une réponse solide couvre, à quoi ressemble une réponse faible, où les réponses junior et senior divergent, une approche de notation qui maintient l'honnêteté de vos intervieweurs, et — pour les compétences qui décident du recrutement — le moment où vous arrêtez de poser des questions et commencez à les regarder travailler. Utilisez-le dans la boucle, après un court exemple de travail et avant l'offre, pas comme un filtre à part entière.

Comment noter les réponses de façon cohérente ?

Décidez à quoi ressemble une bonne réponse avant de rencontrer le candidat, pas pendant qu'il parle. Cette seule habitude fait la différence entre un entretien structuré et un concours de sympathie. Le reste en découle : posez à chaque candidat les mêmes questions dans le même ordre, et notez chaque réponse par rapport à des critères écrits plutôt qu'à l'intuition.

Un barème pratique est une échelle de un à cinq avec des critères comportementaux rédigés à l'avance. Pour une question donnée, un 5 pourrait se lire « nomme le mode de défaillance sans y être invité, donne un exemple concret de son propre travail, et décrit comment il a mesuré la correction » ; un 3, « donne une réponse correcte selon les manuels sans exemple vécu » ; un 1, « récite une définition ou dévie de la question ». Rédigez ces critères pour chaque question que vous prévoyez de poser. Cela prend un après-midi et c'est l'heure la plus productive de tout le processus, car elle convertit une impression vague en un score comparable. C'est une science générale des entretiens structurés, pas quelque chose de propriétaire — le guide des entretiens structurés couvre la pratique. Chaque intervieweur note de façon indépendante et ne compare ses notes qu'ensuite, afin que la voix la plus forte lors du débriefing ne devienne pas silencieusement la décision.

Systèmes à récupération augmentée

La récupération est là où vivent la plupart des fonctionnalités produit LLM et là où elles échouent silencieusement pour la plupart. Ces questions sondent si le candidat comprend la récupération comme un système d'ingénierie avec des modes de défaillance, ou comme une recette mémorisée. Le signe révélateur est la spécificité : une réponse solide nomme où la récupération se casse ; une réponse faible récite les étapes dans l'ordre et s'arrête.

• Décrivez-moi ce qui se passe entre la question d'un utilisateur et la réponse du modèle dans une fonctionnalité à récupération augmentée — les réponses solides décrivent le découpage, l'indexation, le classement et l'assemblage du prompt comme des choix avec des compromis ; signal d'alerte : réciter les étapes comme un pipeline fixe sans décisions à l'intérieur.
• Votre fonctionnalité de récupération renvoie des réponses confiantes, fluentes et incorrectes. Comment la diagnostiquez-vous ? — les réponses solides distinguent un échec de récupération d'un échec de génération avant de toucher le prompt ; signal d'alerte : sauter directement aux ajustements de prompt sans vérifier ce qui a été récupéré.
• Comment décidez-vous de la taille des blocs et du chevauchement pour un corpus ? — les réponses solides le lient à la forme des documents et des requêtes et admettent qu'ils mesureraient ; signal d'alerte : citer un seul nombre comme universellement correct.
• Que faites-vous quand la récupération ne renvoie rien d'utile pour une requête ? — les réponses solides ont un repli prévu et ne laissent jamais le modèle inventer du contexte ; signal d'alerte : supposer que la récupération renvoie toujours quelque chose de pertinent.
• Comment évaluez-vous si votre récupération est réellement bonne, indépendamment de la réponse du modèle ? — les réponses solides nomment des métriques spécifiques à la récupération et un ensemble étiqueté ; signal d'alerte : juger la récupération uniquement selon que la réponse finale semblait correcte.
• Dans quel cas n'utiliseriez-vous pas du tout la récupération et mettriez-vous simplement le contexte dans le prompt ? — les réponses solides raisonnent sur la taille du corpus, la fraîcheur et le coût ; signal d'alerte : traiter la récupération comme obligatoire pour chaque fonctionnalité LLM.

La question sur l'échec de récupération est votre point phare ici, donc passez-y du temps. Une réponse junior traite toute la fonctionnalité comme une boîte noire : la réponse était incorrecte, donc elle réécrit le prompt, ajoute une ligne disant au modèle de ne pas inventer des informations, et espère. Une réponse senior refuse de toucher le prompt avant de savoir quelle moitié a cassé. Elle tire les blocs récupérés pour la requête défaillante et les lit. Si le bon document n'a jamais été récupéré, le prompt n'a jamais été le problème — le bug est en amont, et aucune quantité d'admonestations du prompt ne réparera un document qui n'a jamais atteint la fenêtre de contexte. Si le bon document a été récupéré et que le modèle a quand même répondu incorrectement, c'est maintenant un problème de génération. Le candidat qui récite les étapes de récupération parfaitement, puis ne peut pas dire pourquoi son moteur a renvoyé le mauvais document, a mémorisé la carte et n'a jamais arpenté le terrain.

Conception d'agents et d'outils

Les agents sont le schéma le plus suremployé dans le domaine en ce moment, ce qui fait de la retenue le signal. Les ingénieurs IA les plus compétents vous dissuadent des agents aussi souvent qu'ils vous en convainquent. Ces questions concernent moins la capacité du candidat à câbler un appel d'outil que leur capacité à savoir quand toute l'architecture est une erreur. Si votre équipe construit de vrais produits agentiques, associez cela à comment recruter un ingénieur d'agents IA.

• Dans quel cas n'utiliseriez-vous pas un agent et opteriez-vous plutôt pour un workflow fixe ? — les réponses solides partent de la chose la plus simple qui fonctionne et réservent les agents aux tâches genuinement ouvertes ; signal d'alerte : traiter les agents comme le choix moderne évident pour tout.
• Un outil que votre agent appelle renvoie des données inutilisables, mais le modèle y croit et continue. Comment concevez-vous pour éviter cela ? — les réponses solides valident la sortie des outils et ne supposent jamais qu'un outil a réussi ; signal d'alerte : faire confiance aux réponses des outils parce que le modèle semblait confiant.
• Comment empêchez-vous un agent de boucler sur un appel d'outil malformé à 2h du matin ? — les réponses solides décrivent des limites de boucle, des délais d'attente et de l'observabilité ; signal d'alerte : aucune contention des défaillances et aucun moyen de voir ce que l'agent a fait.
• Comment décidez-vous quelles actions un agent est autorisé à prendre de façon autonome par rapport à celles nécessitant un humain dans la boucle ? — les réponses solides raisonnent sur le rayon d'impact et la réversibilité ; signal d'alerte : autonomie totale sans réflexion sur le coût d'une erreur irréversible.
• Comment testez-vous un agent quand son chemin à travers les outils change à chaque exécution ? — les réponses solides évaluent le comportement et les résultats, pas une seule transcription fixe ; signal d'alerte : supposer qu'une démo sur le chemin heureux prouve que ça fonctionne.
• Décrivez une conception d'agent que vous avez abandonnée ou simplifiée. Qu'est-ce qui vous a fait reculer ? — les réponses solides montrent un scepticisme acquis par une vraie douleur ; signal d'alerte : n'avoir jamais remis en question une approche agentique.

« Dans quel cas n'utiliseriez-vous pas un agent » est le point phare de ce groupe, et c'est un piège pour le candidat à la mode. Une réponse junior, surtout de quelqu'un qui a lu la vague actuelle de tutoriels sur les agents, se tourne par défaut vers un agent et décrit une orchestration multi-étapes élaborée pour une tâche qui n'est en réalité que trois appels API séquentiels. Il confond la sophistication avec le jugement. Une réponse senior part de l'autre bout. Elle demande ce que la tâche nécessite réellement, note que les agents ajoutent de la latence, du coût, du non-déterminisme et toute une catégorie de modes de défaillance, et les réserve aux problèmes où le chemin ne peut genuinement pas être connu à l'avance. Il vous dira volontiers que la dernière chose qu'il a livrée aurait pu être un agent mais était meilleure sous forme de workflow simple. L'ingénieur qui vous dissuade d'un agent a généralement nettoyé après l'un d'eux.

Évaluation et fiabilité

C'est la compétence définissante du rôle, donc pondérez-la en conséquence. Toute la valeur d'un ingénieur IA réside dans le fait de savoir si une fonctionnalité fonctionne — et d'être capable de le prouver — avant qu'elle n'atteigne un utilisateur. La question la plus utile que vous puissiez poser est de savoir comment ils ont su qu'une fonctionnalité passée fonctionnait ; la réponse trie le véritable de l'imposteur plus vite que tout autre élément de la boucle.

• Comment saviez-vous que votre dernière fonctionnalité LLM fonctionnait réellement avant de la livrer ? — les réponses solides décrivent un ensemble d'évaluation, des vérifications hors ligne et en ligne, et une métrique à laquelle ils faisaient confiance ; signal d'alerte : « ça semblait correct quand je l'ai essayé quelques fois ».
• Quelle est la différence entre l'évaluation hors ligne et en ligne, et quand avez-vous besoin des deux ? — les réponses solides utilisent chacune pour ce qu'elle fait bien ; signal d'alerte : confondre une démo avec une évaluation.
• Comment construisez-vous un ensemble d'évaluation pour une fonctionnalité qui n'en a jamais eu ? — les réponses solides partent de vrais exemples d'échec et le développent délibérément ; signal d'alerte : aucune méthode au-delà de l'examen à l'œil des sorties.
• Le modèle sous-jacent est mis à jour silencieusement par le fournisseur et votre fonctionnalité se dégrade discrètement. Comment le détecteriez-vous ? — les réponses solides ont une suite de régression qui tourne en continu ; signal d'alerte : supposer qu'une fonctionnalité qui fonctionnait la semaine dernière fonctionne encore aujourd'hui.
• Comment vous défendez-vous contre l'injection de prompt dans une fonctionnalité qui prend des entrées utilisateur non fiables ? — les réponses solides traitent les entrées du modèle comme hostiles et conçoivent des limites ; signal d'alerte : ne pas avoir conscience que le texte utilisateur peut détourner le modèle.
• Comment mesurez-vous les hallucinations de façon à pouvoir agir dessus ? — les réponses solides ancrent l'affirmation dans des sources récupérables et la comptent ; signal d'alerte : traiter les hallucinations comme non mesurables et donc ignorées.

« Comment saviez-vous que ça fonctionnait ? » mérite sa propre sonde car c'est le détecteur d'imposteurs le plus rapide de la boucle. Posez-la, puis restez silencieux et laissez-les combler le vide. Le candidat rebadgé — celui dont l'ingénierie IA est en réalité un après-midi à suivre un tutoriel API — parle du prompt dont il était fier et de la démo qui a impressionné un interlocuteur. Un vrai ingénieur IA parle de l'ensemble d'évaluation : comment il l'a assemblé à partir de vrais cas d'échec, quelles régressions il a détectées, le chiffre inconfortable qui lui a dit que la fonctionnalité était moins bonne que tout le monde ne supposait. La version junior sait que l'évaluation compte mais ne l'a exécutée qu'hors ligne, une fois, avant le lancement. La version senior a une évaluation qui ne s'arrête jamais de tourner, car il a subi les conséquences d'un fournisseur mettant à jour un modèle sous une fonctionnalité qui fonctionnait la veille. Même question, trois réponses différentes, et vous pouvez entendre la séniorité dans celle qu'ils donnent.

Jugement en production : coût, latence et repli

Ce dernier groupe distingue les personnes qui ont livré des fonctionnalités LLM à de vrais utilisateurs de celles qui ont construit des prototypes impressionnants. Le jugement en production se manifeste en tokens, en millisecondes et dans le plan pour le jour où quelque chose se casse. Ce sont des questions sans glamour, et c'est précisément pourquoi elles font la distinction — personne ne les répète, donc les réponses sont généralement honnêtes.

• Quel est le coût de votre fonctionnalité par millier d'appels, et comment le découvririez-vous ? — les réponses solides raisonnent en tokens et savent où le coût se cache ; signal d'alerte : n'avoir jamais regardé le coût d'une fonctionnalité qu'ils ont construite.
• Comment décidez-vous quand un modèle moins cher et plus petit est suffisamment bon pour une partie d'une fonctionnalité ? — les réponses solides routent par difficulté de tâche et mesurent le compromis de qualité ; signal d'alerte : utiliser par défaut le plus grand modèle partout.
• Le fournisseur du modèle subit une panne au milieu de votre pic d'utilisation. Que se passe-t-il avec votre fonctionnalité ? — les réponses solides ont un repli et se dégradent gracieusement ; signal d'alerte : une dépendance unique sans plan B.
• Comment réduisez-vous la latence d'une chaîne de prompts lente ? — les réponses solides nomment la mise en cache, le parallélisme et l'élagage de la chaîne ; signal d'alerte : accepter la lenteur comme inhérente aux LLM.
• Comment versionnez-vous et revenez-vous en arrière sur un prompt comme vous le feriez avec du code ? — les réponses solides traitent les prompts comme des artefacts versionnés avec un chemin de retour arrière ; signal d'alerte : des prompts modifiés en direct en production sans historique.
• Que consignez-vous pour pouvoir déboguer une fonctionnalité LLM après qu'elle s'est mal comportée pour un vrai utilisateur ? — les réponses solides capturent les entrées, le contexte récupéré et la sortie du modèle ; signal d'alerte : aucune journalisation au-delà d'un indicateur de succès ou d'échec.

La question sur le coût est discrètement l'une des plus révélatrices de la boucle, car si peu de candidats ont jamais été obligés de tenir un budget. Demandez ce que coûte une fonctionnalité par millier d'appels et un candidat junior cligne souvent des yeux — il a construit la chose, l'a livrée, et n'a jamais une seule fois regardé la facture, parce que quelqu'un d'autre possédait cette ligne. Pas rédhibitoire pour un junior, mais cela vous dit où il en est. Un candidat senior répond dans la monnaie du poste : cette fonctionnalité est coûteuse parce qu'elle bourre tout le document dans chaque prompt, donc je mettrais en cache la récupération, routerais les requêtes faciles vers un modèle moins cher, et élaguerais d'abord la chaîne. Il a senti la ligne de coût faire mal et cela a changé sa façon de construire. Vous ne testez pas l'arithmétique. Vous testez si le chiffre est réel pour lui.

Quand arrêter de poser des questions et commencer à tester ?

Le moment où un candidat peut répondre à chaque question ci-dessus sans hésitation est le moment où vous devriez le moins faire confiance aux questions. Les entretiens échantillonnent des affirmations ; les exemples de travail échantillonnent le travail. Une description confiante de la façon dont vous diagnostiqueriez une fonctionnalité de récupération cassée est une affirmation. Regarder quelqu'un tirer les blocs récupérés, les lire, et décider seulement ensuite s'il faut toucher le prompt est une preuve — et en 2026, avec des assistants capables de produire la description confiante à la demande, l'écart n'a jamais autant compté.

Donc faites tourner l'exemple de travail avant l'entretien, pas après. Donnez au candidat une tâche adaptée au poste — une fonctionnalité de récupération qui renvoie des réponses fluentes et incorrectes, un agent qui boucle sur un mauvais appel d'outil, une chaîne de prompts qui fait silencieusement exploser le budget de latence — dans un environnement où un modèle est genuinement disponible plutôt qu'interdit, car interdire l'IA à l'évaluation d'un ingénieur IA teste un poste que personne n'occupe. Un exemple de travail comme celui-ci prédit le comportement sur le poste bien mieux que n'importe quelle question, et il vous dit quelles sondes valent le temps d'entretien limité. Si l'exercice montre déjà une solide discipline d'évaluation, approfondissez plutôt sur le jugement en production ou la retenue face aux agents qu'il a laissés ambigus. Laissez le rapport choisir vos questions.

C'est le moment où une plateforme d'évaluation gagne sa place dans la boucle, y compris la nôtre. Notre AI Sandbox fait tourner exactement ce type de session adaptée au poste pour les rôles d'ingénierie IA, et le rapport vous indique où pointer l'entretien ensuite — au niveau des capacités, sans dicter votre décision. Le cas de recrutement plus large pour le rôle se trouve dans comment recruter un ingénieur IA ; la discipline de lire comment quelqu'un travaille avec un modèle, plutôt que s'il peut, est comment évaluer l'AI Fluency, noté par rapport au cadre 4D de Délégation, Description, Discernement et Diligence — les deux derniers portent le plus de poids pour un ingénieur IA, car détecter les erreurs du modèle est l'ensemble du travail. Vous pouvez construire une version maison avec un dépôt cassé et un chronomètre ; si vous préférez voir la nôtre, réservez une démo. Dans tous les cas, le principe tient : posez les questions pour ouvrir la conversation, puis arrêtez de poser des questions et commencez à regarder.

Les meilleurs ingénieurs IA ne sont pas ceux qui ont les réponses les plus fluides. Ce sont ceux qui, face à une fonctionnalité qui semble correcte, refusent de lui faire confiance jusqu'à ce qu'ils l'aient mesurée — et qui vous diront le chiffre inconfortable que la démo avait caché. Interviewez pour cet instinct, puis vérifiez-le dans un exemple de travail, ou vous continuerez à confondre une réponse bien préparée avec ce qui sera livré.