Recrutement · August 2, 2026 · 12 min de lecture

Questions d'entretien pour prompt engineer : comment évaluer les réponses

Questions d'entretien pour prompt engineer à destination du responsable du recrutement : 24 questions par compétence, ce que révèlent les bonnes et mauvaises réponses, et quand tester plutôt qu'interroger.

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

Ce guide est destiné au responsable du recrutement assis en face d'un candidat prompt engineer, qui cherche à déterminer si les réponses fluides décrivent une véritable discipline ou un script mémorisé. Cette distinction n'a jamais été aussi difficile à tracer, car le candidat a presque certainement répété avec un assistant. Toute question ayant une réponse nette et consultable — définissez le few-shot prompting, citez trois façons de réduire les hallucinations — est désormais un examen divulgué : il a lu les mêmes fils que vous, les a soumis à un modèle, et arrive avec une récitation polie qui ne dit rien sur sa capacité à faire le travail. Ce guide n'est donc pas une liste de questions à dérouler et cocher. C'est un guide pour évaluer les réponses : à quoi ressemble une réponse solide par rapport à une réponse faible, comment noter de façon cohérente, et — la partie que tous les articles de liste passent sous silence — quand arrêter de poser des questions et commencer à regarder la personne travailler. Le rôle s'est consolidé, passant d'une astuce de formulation à une discipline de systèmes fondée sur la mesure, et la formulation habile est désormais le signal d'imposteur le plus clair.

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

Avant les questions, la notation — car les entretiens non structurés récompensent celui qui ressemble le plus à l'intervieweur, pas celui qui peut faire le travail. Décidez des questions une fois pour toutes, posez-les à chaque candidat dans le même ordre, et notez par écrit ce que contient une réponse faible, satisfaisante et solide avant que quiconque s'assoie. C'est la notation ancrée sur des comportements, et c'est le changement unique qui améliore le plus la précision avec laquelle un entretien prédit la performance.

L'ancrage fonctionne parce qu'il vous oblige à vous engager sur un standard pendant que vous êtes encore calme, plutôt que de vous laisser convaincre par un candidat sympathique en fin d'après-midi. Un barème pratique va de un à cinq, avec des critères comportementaux : pour une question de débogage, un 1 « se précipite sur des changements de formulation aléatoires, sans hypothèse, sans mesure » ; un 5 « regroupe les échecs par type, énonce une théorie, change une variable, et vérifie que le résultat tient sur tout l'ensemble ». Vous ne notez pas l'éloquence de quelqu'un, mais si le comportement qu'il décrit correspond au poste. Les mécaniques pour bien faire cela — formulation des critères, calibration du jury, réduction des effets de halo — figurent dans notre guide des entretiens structurés, et relèvent d'une science générale des entretiens, pas d'un dispositif propriétaire.

Questions sur l'évaluation et les habitudes de mesure

C'est le cœur du rôle, donc investissez le plus d'efforts d'ancrage ici. Un prompt engineer qui ne sait pas mesurer est un rédacteur avec un vocabulaire plus large. Chaque question ci-dessous pose la même chose sous un angle différent : transformez-vous « la sortie semble décalée » en un chiffre, ou en un nouveau round de bidouillage ?

• Comment savez-vous qu'un prompt s'est réellement amélioré ? — une réponse solide se tourne vers un ensemble de cas et une métrique ; le signal d'alerte est « ça se lit mieux », car un ressenti n'est pas une mesure.
• Expliquez-moi comment vous avez construit un ensemble d'évaluation pour un vrai prompt. — les candidats solides collectent de vrais échecs, étiquettent les sorties attendues et testent les changements sur tout l'ensemble ; le signal d'alerte est de traiter trois exemples choisis à la main comme une couverture.
• Racontez-moi un cas où vous pensiez qu'un prompt était corrigé et où il ne l'était pas. — vous voulez une régression spécifique qu'ils ont manquée puis détectée ; le signal d'alerte est un candidat qui ne se souvient pas d'avoir eu tort, ce qui signifie qu'il n'a jamais mesuré assez précisément.
• Comment décidez-vous qu'un changement vaut la peine d'être livré quand la métrique monte sur certains cas et baisse sur d'autres ? — les réponses solides pondèrent les échecs qui comptent le plus ; le signal d'alerte est d'optimiser un chiffre-titre tout en cassant des cas limites.
• Quelle taille doit avoir un ensemble d'évaluation pour que vous lui fassiez confiance ? — écoutez le jugement sur la couverture, pas un nombre magique ; le signal d'alerte est « quelques exemples suffisent » ou une règle rigide appliquée aveuglément au problème.
• Quand deux prompts obtiennent le même score sur votre ensemble, comment choisissez-vous ? — les candidats solides parlent de robustesse et de comportement sur des cas non vus ; le signal d'alerte est de choisir celui qui est le plus ingénieux pour lui-même.

La question phare ici est la première, et l'écart entre les réponses junior et senior est saisissant. Un prompt engineer junior décrit l'examen à l'œil de quelques sorties et la décision qu'elles semblent meilleures — pas vraiment faux, mais non mis à l'échelle ; ça fonctionne tant que le prompt n'a pas d'importance. Un candidat senior répond de façon structurelle : il nomme l'ensemble de cas, vous dit qu'il contient un éventail représentatif des types d'échecs de production, et lit le différentiel plutôt que le score absolu, car un changement qui corrige dix cas et en casse silencieusement deux est une perte nette déguisée en victoire. La réponse junior s'épuise après « ça semble mieux ».

Le deuxième point phare est l'histoire de régression. Demandez à n'importe quel prompt engineer expérimenté de raconter un cas où une correction n'a pas tenu et vous entendrez une vraie histoire, racontée avec la texture amère de quelqu'un qui en a souffert : une mise à jour du modèle a discrètement rendu des sorties propres légèrement moins bonnes, personne ne l'a remarqué jusqu'à ce qu'un chiffre en aval bouge, et il l'a retracé et mis une garde en place pour que le prochain surgisse automatiquement. Un candidat incapable de produire cette histoire n'a jamais livré des prompts qui comptaient, ou ne les a jamais mesurés assez précisément — dans les deux cas rédhibitoire pour un rôle fondé sur le maintien de l'honnêteté des sorties dans le temps.

Questions sur la récupération et la conception du contexte

Le prompt engineering moderne s'arrête rarement au prompt. La plupart des travaux conséquents consistent à alimenter le modèle avec le bon contexte — documents récupérés, sorties d'outils, état structuré — et un candidat solide sait qu'une excellente instruction sur un mauvais contexte échoue quand même. Ce groupe sonde s'ils voient l'ensemble du système ou seulement la zone de texte.

• Comment décidez-vous quel contexte donner au modèle par rapport à ce que vous omettez ? — les réponses solides traitent le contexte comme un budget dépensé sur ce qui change la réponse ; le signal d'alerte est de tout entasser et d'enterrer le signal.
• Racontez-moi un cas où le modèle avait tort et où la correction était dans la récupération, pas dans le prompt. — vous voulez quelqu'un qui localise un échec dans la bonne couche ; le signal d'alerte est de croire que chaque problème cède à une meilleure formulation.
• Comment structurez-vous les informations récupérées pour que le modèle les utilise réellement ? — les candidats solides ordonnent, étiquettent et formatent le contexte délibérément ; le signal d'alerte est de coller des blocs bruts et d'espérer.
• Que faites-vous quand le moteur de récupération renvoie quelque chose de plausible mais de faux ? — écoutez s'ils détectent et gèrent un mauvais contexte ; le signal d'alerte est de ne pas avoir conscience que la récupération peut silencieusement empoisonner un bon prompt.
• Comment empêchez-vous une longue fenêtre de contexte de dégrader la réponse ? — les réponses solides savent que plus de contexte n'est pas gratuit et dilue l'attention ; le signal d'alerte est de traiter une grande fenêtre comme une licence pour arrêter de filtrer.
• Comment débogueriez-vous une réponse correcte en isolation mais incorrecte pour la situation de l'utilisateur ? — vous voulez quelqu'un qui vérifie si le modèle a reçu le bon contexte ; le signal d'alerte est de s'arrêter à « la sortie semble correcte ».

Le point phare ici est le diagnostic récupération-versus-prompt, et il sépare nettement le penseur systèmes du manieur de mots. Une réponse junior traite une sortie incorrecte comme un prompt à reformuler, et passe un après-midi à ajuster la formulation d'un problème qu'aucune formulation ne peut résoudre. Une réponse senior demande ce que le modèle a réellement reçu : le bon document a-t-il seulement été récupéré ? Si oui et que la réponse est encore incorrecte, c'est un problème d'instruction ; sinon, aucun prompt ne pourra sauver un document qui n'a jamais atteint la fenêtre de contexte. Cet instinct — localiser l'échec dans la bonne couche avant de toucher quoi que ce soit — distingue le rôle du certificat, et rejoint le point que notre guide comment recruter un prompt engineer fait sur les candidats qui insistent qu'un prompt peut tout régler.

Questions sur le débogage du comportement du modèle

Quand un prompt se comporte mal, la correction dépend entièrement de la raison. Un candidat qui ne peut pas distinguer une hallucination d'une dérive de format d'un refus excessif appliquera le mauvais remède et aggravera les choses. Ce groupe teste s'ils lisent les modes de défaillance avec précision plutôt que d'y réagir.

• Le modèle continue de renvoyer du JSON enveloppé dans des excuses bavards. Comment diagnostiquez-vous et corrigez-vous cela ? — les candidats solides le nomment comme une dérive de format et raisonnent sur les instructions et les exemples ; le signal d'alerte est de traiter un échec de formatage comme un problème factuel.
• Comment distinguez-vous une hallucination d'un échec de récupération d'un refus ? — vous voulez quelqu'un qui distingue les trois, car la correction de chacun diffère ; le signal d'alerte est de regrouper toutes les mauvaises réponses dans « le modèle est mauvais ».
• Un prompt fonctionne neuf fois sur dix et échoue la dixième de façon imprévisible. Comment l'abordez-vous ? — les réponses solides cherchent le schéma plutôt que de déclarer le modèle aléatoire ; le signal d'alerte est d'accepter le non-déterminisme comme une licence pour cesser d'enquêter.
• Comment faites-vous pour qu'un prompt survive à un changement de version du modèle ? — écoutez s'ils construisent contre le comportement plutôt que de sur-calibrer aux particularités d'un modèle actuel ; le signal d'alerte est un prompt tellement ajusté au modèle d'aujourd'hui qu'il est fragile par construction.
• Quand le modèle refuse une demande légitime, comment résolvez-vous cela sans affaiblir la sécurité ? — les candidats solides reformulent précisément plutôt que de forcer le modèle ou de désactiver les garde-fous ; le signal d'alerte est de traiter chaque refus comme un obstacle à contourner.
• Comment reproduisez-vous un échec intermittent de façon suffisamment fiable pour le corriger ? — vous voulez une approche systématique pour isoler les variables ; le signal d'alerte est « je réessaie jusqu'à ce que ça se reproduise », sans méthode pour le répéter.

Le point phare de ce groupe est la question de l'échec intermittent, car elle révèle le tempérament autant que la compétence. Un candidat plus faible entend « échoue une fois sur dix de façon imprévisible » et hausse les épaules — le modèle est non déterministe, que voulez-vous. Un candidat solide entend un schéma qui attend d'être trouvé : il collecte les cas d'échec, cherche ce que le un-sur-dix a en commun, et traite la variance comme un signal plutôt qu'une excuse. Demandez ce qu'il ferait s'il ne pouvait pas le reproduire, et la bonne réponse n'est pas « abandonner » mais instrumenter le système pour capturer la prochaine occurrence avec suffisamment de contexte pour la diagnostiquer.

Questions sur les pratiques de travail : versionnage, révision et collaboration

Les prompts qui comptent sont du code, et ils ont besoin de la même discipline : contrôle de version, révision, documentation, et un moyen de travailler avec les personnes dont le produit en dépend. Ce groupe vous dit si un candidat traite le prompt engineering comme un artisanat solitaire ou une discipline d'ingénierie pratiquée en équipe.

• Comment versionnez-vous et revenez-vous en arrière sur des prompts en production ? — les candidats solides traitent les prompts comme des artefacts versionnés avec un chemin de retour arrière ; le signal d'alerte est de modifier des prompts en direct sans historique et sans moyen de revenir en arrière.
• Comment révisez-vous le changement de prompt d'un collègue avant qu'il soit livré ? — vous voulez une vraie révision centrée sur les résultats d'évaluation, pas seulement la lisibilité ; le signal d'alerte est « je l'ai lu et ça semblait correct », sans ensemble de tests dans la boucle.
• Comment documentez-vous un prompt pour que la personne suivante comprenne pourquoi il est construit comme il l'est ? — les réponses solides capturent les modes de défaillance contre lesquels le prompt se défend ; le signal d'alerte est une ingéniosité non documentée que seul l'auteur peut maintenir.
• Racontez-moi un cas où vous avez dû expliquer un compromis de prompt à un interlocuteur non technique. — écoutez un langage simple et une honnêteté sur les limites ; le signal d'alerte est de se cacher derrière le jargon ou de sur-promettre.
• Comment maintenez-vous la cohérence des prompts dans une équipe pour que le produit ne développe pas des personnalités contradictoires ? — vous voulez des conventions partagées et une source de vérité ; le signal d'alerte est que chaque ingénieur garde son propre style privé.
• Comment décidez-vous quand un prompt est devenu trop complexe et doit être divisé ou repensé ? — les candidats solides reconnaissent l'expansion non maintenable et refactorisent ; le signal d'alerte est d'ajouter encore une instruction à un prompt qui s'effondre déjà sous son poids.

Le point phare ici est la question d'explication à l'interlocuteur, et elle compte plus que son cadrage souple ne le suggère. Les prompt engineers sont côte à côte avec des équipes opérationnelles et de marque qui ressentent chaque régression directement, et la capacité à dire « c'est une limitation de récupération, pas quelque chose que je peux régler par le prompt » — sans condescendance ni sur-promesse — préserve ces relations. Un candidat junior se réfugie dans le jargon ou promet une correction qui n'existe pas ; un candidat senior explique le compromis dans les propres termes de l'interlocuteur et gère l'attente avant qu'elle ne se brise. C'est le mélange mesure-plus-communication que notre hub prompt engineering par rôle décrit : le jugement technique est nécessaire, mais l'honnêteté sur les limites est ce qui le rend utilisable par une équipe.

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

Voici la vérité inconfortable sur chaque question ci-dessus : un entretien échantillonne des affirmations, pas du travail. Un candidat peut décrire une belle boucle de mesure qu'il n'a jamais exécutée, et une réponse répétée est désormais indiscernable d'une réponse vécue jusqu'à ce que vous sondiez les détails — et même alors, les détails peuvent s'inventer. Les questions valent la peine d'être posées, elles ne valent pas la peine d'être seules dignes de confiance. À un moment donné, le geste honnête est d'arrêter de demander à quelqu'un de décrire le poste et de le regarder le faire.

L'exercice le plus prédictif pour ce rôle est presque embarrassant dans sa simplicité : remettez au candidat un prompt médiocre et un ensemble de cas sur lesquels il échoue, puis regardez-le diagnostiquer et itérer avec un modèle véritablement disponible. Lit-il les échecs avant de toucher le prompt, les regroupe-t-il par type, change-t-il une variable, et vérifie-t-il la correction sur tout l'ensemble — ou reformule-t-il instinctivement et examine-t-il un seul cas à l'œil ? Faites-le avant la boucle d'entretien, pas après, et laissez ce que vous observez décider quelles questions ci-dessus méritent votre temps limité — en consacrant la conversation aux domaines du diagnostic de récupération et de la communication avec les interlocuteurs qu'un exemple de travail couvre moins directement.

C'est le pont autour duquel nous construisons toute notre approche : une tâche réaliste et adaptée au rôle avec des outils d'IA à portée de main, observée comme une évaluation de candidats plutôt qu'un quiz. C'est ce que fait une évaluation des compétences en prompt engineering — placer la personne dans quelque chose de proche d'un mardi matin et observer comment elle dirige le modèle, le surprend à avoir tort avec assurance, et vérifie avant de livrer. Lire ces signaux est une compétence en soi ; comment évaluer l'AI Fluency couvre à quoi ressemblent une collaboration solide et faible, aux côtés du guide sœur sur les questions d'entretien pour ingénieur IA pour le rôle adjacent. Pesez notre cadrage comme il vous convient — la logique tient : la boucle est ce qui sera livré le trimestre prochain, et la seule façon honnête de la voir est de la regarder. Pour voir le côté de l'évaluation, réservez une démo.

Les meilleurs entretiens pour prompt engineer ne récompensent pas les réponses les plus fluides. Ils récompensent le candidat dont l'histoire résiste à une question de suivi difficile et dont l'exemple de travail montre la même boucle qu'il a décrite. Posez les questions, notez-les par rapport à des critères, puis arrêtez de poser des questions et regardez — car la formulation habile est le signal d'imposteur, et seul le travail dit la vérité.