Comment abordez-vous la conception d'un prompt pour une nouvelle fonctionnalité propulsée par un LLM, du premier brouillon jusqu'à la production ?

Je commence par écrire la spécification de la tâche avant d'écrire la moindre ligne de prompt: le format d'entrée exact, le schéma de sortie exact, et trois ou quatre exemples travaillés de ce à quoi ressemble une bonne réponse, avec au moins un cas limite. Je rédige une première version comme une instruction directe avec un rôle clair et des contraintes, puis je la fais tourner sur un petit jeu de test construit à la main d'une vingtaine de cas couvrant la variété des entrées réelles, pas seulement les cas faciles. À partir de là, j'itère avec une boucle serrée: je change une seule variable à la fois, que ce soit la formulation des instructions, le choix des exemples ou le format de sortie, et je vérifie sur le jeu de test avant de passer au changement suivant, car empiler plusieurs modifications à la fois rend impossible de savoir ce qui a réellement aidé. Une fois le prompt stable sur le jeu construit à la main, j'élargis le jeu de test avec des données proches de la production et je le fais passer dans un framework d'évaluation comme promptfoo ou Braintrust pour détecter automatiquement les régressions. Ce n'est qu'ensuite que j'ajoute des contraintes de sortie structurée et une gestion des réponses malformées. Je conserve chaque version dans le contrôle de version avec les résultats d'évaluation associés, pour qu'un changement de prompt soit revu comme un changement de code.

Comment évaluez-vous si un changement de prompt est réellement une amélioration ?

Un changement de prompt n'est réel que s'il fait bouger une métrique définie avant le changement, donc la première étape est toujours d'avoir un jeu d'évaluation fixe et une méthode de notation en place. Pour les tâches avec une bonne réponse claire, comme l'extraction ou la classification, je note en comparaison exacte ou structurée. Pour la génération ouverte, j'utilise un dispositif LLM-as-judge avec une grille détaillée, recoupé avec un échantillon annoté par des humains d'au moins trente cas pour confirmer que le modèle juge est suffisamment aligné avec le jugement humain pour qu'on lui fasse confiance. Je fais toujours tourner l'ancien et le nouveau prompt sur le même jeu d'évaluation dans la même session, pas séquentiellement à quelques jours d'écart, car le comportement du modèle dérive même sur un prompt fixe quand les fournisseurs mettent à jour leurs modèles silencieusement derrière une API. Je regarde la distribution complète des scores, pas seulement la moyenne, car un changement qui aide le cas médian mais casse une catégorie précise de cas limites n'est pas une amélioration nette même si la moyenne monte. Je ne déploie le changement qu'une fois que le jeu d'évaluation montre un gain clair et reproductible, et je garde l'ancienne version du prompt taguée pour pouvoir revenir en arrière rapidement si les signaux de production contredisent l'évaluation hors ligne.

Comment décidez-vous quel modèle utiliser pour une tâche donnée, et comment gérez-vous les changements de version de modèle ?

Le choix du modèle dépend de la complexité de la tâche, du budget de latence et du coût par requête, à peu près dans cet ordre. Pour des tâches simples de classification ou d'extraction, j'utilise par défaut un modèle plus petit et plus rapide, car un modèle de raisonnement haut de gamme est souvent une dépense gaspillée pour une tâche qui ne nécessite pas de raisonnement en plusieurs étapes. Pour les tâches qui demandent un vrai raisonnement, l'usage d'outils ou une synthèse sur long contexte, je me tourne vers un modèle frontier et j'accepte le compromis de latence et de coût, car se tromper coûte plus cher que les tokens supplémentaires. Je benchmarke deux ou trois modèles candidats sur mon jeu d'évaluation avant de trancher, plutôt que de choisir sur réputation générale, car le modèle qui performe le mieux sur les benchmarks publics n'est pas toujours celui qui performe le mieux sur ma tâche et mes données spécifiques. Quand un fournisseur sort une nouvelle version de modèle, je ne la laisse jamais se mettre à jour automatiquement en production sans faire tourner d'abord la suite d'évaluation complète, car même un changement de version mineur peut modifier le comportement suffisamment pour casser un prompt qui dépendait des particularités de l'ancien modèle. Je fixe les versions de modèle explicitement dans la configuration et je traite une mise à jour comme une release délibérée et testée, exactement comme je traiterais une montée de version de dépendance dans le code applicatif.

Comment réduisez-vous les hallucinations dans les sorties d'un LLM ?

Je traite la réduction des hallucinations comme un problème en couches plutôt que quelque chose qu'un seul ajustement de prompt résout. Au niveau du prompt, je demande explicitement au modèle de dire quand il ne sait pas plutôt que de deviner, et je lui donne la permission de répondre 'information insuffisante' comme sortie valide, car les modèles hallucinent souvent parce que le prompt exige implicitement une réponse. Pour tout ce qui est factuel, j'ancre la réponse dans du matériel source récupéré plutôt que de m'appuyer sur la connaissance paramétrique du modèle, et je lui demande de citer le passage précis utilisé, ce qui améliore la précision et me donne un moyen de vérifier la réponse automatiquement. J'utilise des formats de sortie structurés autant que possible, car forcer le modèle dans un schéma réduit la surface disponible pour une fabrication qui sonne confiante. Pour les sorties à fort enjeu, j'ajoute une passe d'auto-vérification, un second appel qui vérifie la première réponse par rapport au matériel source et signale les affirmations non soutenues. Aucune de ces techniques n'est parfaite isolément, mais combinées elles rattrapent la plupart de ce qu'un seul prompt bien écrit laisse passer, et je suis le taux d'hallucination résiduel via mon jeu d'évaluation pour savoir si l'approche en couches fonctionne vraiment ou ajoute juste de la latence.

Parlez-moi d'une fois où un prompt qui fonctionnait bien en test a échoué en production.

J'avais construit un prompt qui classait les tickets support entrants dans l'une de douze catégories, avec un score de plus de 95 % de précision sur mon jeu de test de deux cents exemples annotés. En production, la précision est tombée à environ 78 % en une semaine. En creusant les échecs, le pattern était clair: mon jeu de test avait été construit à partir de tickets historiques tous en anglais, mais environ un quart du trafic réel arrivait en français et en espagnol, et le modèle basculait par défaut sur une catégorie 'autre' générique dès que la langue de l'entrée changeait, un cas que le prompt original n'adressait jamais parce que je n'avais pas pensé à vérifier la distribution des langues du trafic réel par rapport à mon jeu de test. J'ai reconstruit le jeu d'évaluation pour refléter le vrai mix de langues, ajouté des exemples multilingues explicites au prompt, et ajouté une étape de détection de langue en amont pour que le prompt de classification reçoive un indice de langue plutôt que de deviner. La précision est remontée à 93 % sur les trois langues en quelques jours. La leçon: un jeu de test construit à partir d'un échantillon pratique, plutôt que reflétant réellement la distribution de production, surestimera toujours la qualité d'un prompt.

Décrivez une situation où vous avez dû vous opposer à une demande produit qui aurait rendu un prompt non fiable ou dangereux.

Un product manager voulait que l'assistant support donne des réponses définitives sur si une action donnée affecterait la garantie d'un client, formulées avec pleine confiance plutôt qu'avec des nuances, car les tests utilisateurs montraient que les réponses nuancées frustraient les gens. Le problème, c'est que les conditions de garantie variaient selon la gamme de produit et la date d'achat, et notre système de récupération n'avait pas toujours une couverture complète des cas limites de politique, donc une réponse fausse mais confiante portait un vrai risque financier et de confiance. J'ai préparé une courte analyse montrant les catégories de questions de garantie où notre confiance de récupération était réellement élevée par rapport à celles où elle était faible, et j'ai proposé un chemin intermédiaire: des réponses directes et confiantes pour les catégories à haute confiance, et un renvoi explicite 'je vous mets en relation avec un spécialiste' pour les catégories à faible couverture, plutôt qu'une politique uniforme de réponses confiantes partout. J'ai appuyé cela avec les scores de confiance de récupération réels sur un échantillon de deux semaines plutôt qu'un argument de risque abstrait, ce qui a rendu le compromis concret pour le product manager plutôt que théorique. L'équipe produit a accepté l'approche à paliers, et elle a été livrée sans une seule réclamation liée à la garantie sur le trimestre suivant.

Donnez un exemple de la façon dont vous avez amélioré un prompt ou une fonctionnalité IA sous-performante.

J'ai hérité d'un prompt de génération de résumés de réunion noté 2,9 sur 5 en moyenne par les utilisateurs, la plainte la plus fréquente étant que les résumés manquaient des actions noyées dans une conversation informelle plutôt qu'énoncées formellement. J'ai pris cinquante des transcriptions les moins bien notées et je les ai lues manuellement plutôt que de deviner la correction, et j'ai trouvé que le prompt original demandait au modèle d'extraire les 'actions' sans définir ce qui comptait comme telle, donc il manquait systématiquement tout ce qui était formulé comme une suggestion ou une question plutôt qu'une instruction directe. J'ai réécrit le prompt avec une définition explicite d'une action, avec des exemples des formulations indirectes qu'il devait capter, et j'ai divisé la tâche en deux passes: d'abord extraire chaque engagement ou déclaration de type tâche candidate, puis une seconde passe pour filtrer et formater les actions confirmées. J'ai validé la correction sur les cinquante transcriptions, puis sur le jeu d'évaluation complet, avant de la déployer en production derrière un feature flag pendant une semaine. La note utilisateur est montée à 4,3 sur 5, et la plainte spécifique sur les actions manquées est tombée à presque zéro dans les retours du mois suivant.

Expliquez-moi comment vous concevriez une suite d'évaluation pour une fonctionnalité IA orientée client avant sa mise en production.

Je commence par définir les modes d'échec qui comptent réellement pour cette fonctionnalité précise, pas un score de qualité générique, car 'bon' veut dire quelque chose de différent pour une fonctionnalité de résumé que pour une fonctionnalité d'extraction de données. Je construis le jeu de test à partir de trois sources: des cas écrits à la main couvrant des cas limites connus, un échantillon d'entrées réelles ou proches de la production, et des cas adversariaux conçus pour casser le prompt, y compris des tentatives d'injection de prompt si la fonctionnalité prend du texte utilisateur en entrée. Je définis une notation par mode d'échec plutôt qu'un chiffre agrégé unique: précision factuelle notée par rapport au matériel source, conformité de format vérifiée par programme puisque cela ne nécessite pas de modèle juge, ton et utilité notés avec LLM-as-judge selon une grille, et sécurité vérifiée sur un ensemble fixe d'entrées problématiques connues. Je calibre les scores LLM-as-judge par rapport à un échantillon annoté par des humains avant de leur faire confiance dans le pipeline, typiquement trente à cinquante cas notés par les deux, et je n'avance pas tant que l'accord n'est pas assez élevé pour faire confiance au score automatisé comme proxy. Je branche tout cela dans la CI pour que chaque changement de prompt fasse tourner l'évaluation complète automatiquement, et je pose une barrière stricte: aucun changement de prompt n'est déployé s'il fait régresser un mode d'échec individuel, même si le score agrégé s'améliore.

Comment gérez-vous le versionnement des prompts et le rollback en production ?

Je traite les prompts comme des artefacts versionnés avec la même rigueur que le code applicatif, stockés dans le contrôle de version plutôt que dans un champ de base de données modifié sur place, pour que chaque changement ait un diff, un auteur et un résultat d'évaluation lié. En production, je garde les prompts derrière une couche de configuration qui peut référencer une version précise par ID, ce qui me permet de faire un rollout partiel ou un test A/B entre deux versions de prompt sans déploiement de code. Chaque version de prompt est taguée avec les résultats d'évaluation qu'elle a passés et la version de modèle sur laquelle elle a été validée, donc si un fournisseur sort une mise à jour, je sais immédiatement quelles versions de prompt doivent être revalidées plutôt que de le découvrir via un pic de signalements d'erreurs. Pour le rollback, je garde la version stable précédente active et accessible via la même couche de configuration, donc revenir en arrière est un changement de configuration plutôt qu'un déploiement, ce qui sort un mauvais prompt de production en quelques minutes plutôt que d'attendre un cycle de release. Je journalise aussi l'ID de version du prompt avec chaque requête en production, donc quand un utilisateur signale une mauvaise réponse, je peux la reproduire avec la version exacte du prompt et du modèle qui l'a générée, plutôt que la version actuelle qui pourrait déjà différer.

Comment abordez-vous le prompting pour un workflow agentique qui doit appeler des outils et prendre des décisions en plusieurs étapes ?

Je commence par définir les schémas d'outils avec autant de précision qu'un contrat d'API, avec des types de paramètres stricts et des descriptions claires, car des descriptions d'outils vagues sont la cause numéro un d'un agent qui appelle le mauvais outil ou passe des arguments malformés. Je garde le prompt système centré sur la politique de décision de l'agent: quand appeler un outil plutôt que répondre directement, quand demander une clarification à l'utilisateur plutôt qu'avancer sur une hypothèse, et que faire quand un appel d'outil échoue, plutôt que d'essayer d'énumérer tous les scénarios possibles. J'intègre des conditions d'arrêt explicites et un nombre maximal d'étapes, car un agent sous-spécifié bouclera volontiers sur des appels d'outils improductifs si rien ne lui dit de s'arrêter et de réévaluer. Pour les tâches multi-étapes, je privilégie un pattern explicite de planification puis exécution plutôt qu'un appel d'outils purement réactif, où le modèle énonce d'abord la séquence d'étapes prévue avant de les exécuter, car cela rend le raisonnement inspectable et permet de repérer des plans manifestement faux avant qu'aucun outil ne s'exécute réellement. Je journalise la trace complète des appels d'outils pour chaque exécution d'agent, pas seulement la réponse finale, car quand un agent échoue, le signal de débogage utile se trouve presque toujours dans la séquence de décisions intermédiaires, pas seulement dans la sortie finale. J'évalue les exécutions d'agent sur le taux d'achèvement de tâche et sur le nombre d'appels d'outils inutiles, car un agent qui réussit en forçant dix appels redondants n'est pas vraiment prêt pour la production.

Prompt Engineer

Les entretiens pour un poste de prompt engineer testent quelque chose de plus étroit et de plus difficile qu'on ne l'imagine: votre capacité à obtenir un comportement cohérent et mesurable d'un modèle probabiliste par nature, et à le prouver avec une évaluation plutôt qu'avec une impression. Les recruteurs creusent sur la façon dont vous versionnez vos prompts, comment vous détectez une régression avant qu'elle n'atteigne les utilisateurs, et comment vous raisonnez sur le compromis entre un grand modèle frontier et un modèle plus petit et moins cher pour une tâche donnée. Attendez-vous à un terrain vraiment ancré en 2026: usage d'outils en mode agentique, sorties structurées, réduction des hallucinations, et ce que vous faites quand un fournisseur met à jour un modèle discrètement sous votre prompt. Ce guide couvre les questions les plus fréquentes, avec des réponses qui sonnent comme quelqu'un qui livre des prompts en production, pas quelqu'un qui en a seulement lu des articles.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Aller plus loin

Réussir l'entretien comportemental (méthode STAR)Comment se préparer à un entretien technique

Questions d'entretien courantes pour Prompt Engineer

Questions comportementales pour les postes Prompt Engineer

Questions techniques pour les candidats Prompt Engineer

Ce que les recruteurs recherchent pour un poste Prompt Engineer

Ce que les recruteurs cherchent vraiment chez les candidats prompt engineer :

Des preuves plutôt que de l'intuition. Les candidats capables de décrire un jeu d'évaluation et une méthode de notation pour chaque affirmation sur un prompt sont bien plus crédibles que ceux qui disent qu'un prompt 'marche juste mieux'.
La conscience que les modèles dérivent sous vos pieds. Les fournisseurs mettent à jour leurs modèles silencieusement, et les candidats qui fixent les versions et revalident à chaque mise à jour ont clairement déjà été échaudés par ça, ce qui est exactement l'expérience recherchée.
De vraies habitudes de débogage en production. Le versionnement des prompts, la journalisation et la rigueur de rollback sont ce qui distingue quelqu'un qui peut maintenir une fonctionnalité IA en production de quelqu'un qui ne sait qu'en faire la démo.
Du jugement sur le choix du modèle, pas un réflexe d'utiliser le plus gros modèle disponible. Les meilleurs candidats traitent le choix du modèle comme une décision de coût et de latence, pas un automatisme.
Une maîtrise des outils et techniques actuels, pas une vision d'un prompt figée en 2023. Demandez spécifiquement sur les workflows agentiques et les sorties structurées. Si la réponse reste vague, l'expérience du candidat n'est peut-être pas à jour.

Questions à poser à votre interlocuteur

→À quoi ressemble la configuration actuelle d'évaluation et de test des prompts ici, et quelle est sa maturité ?
→Comment gérez-vous le cas où un fournisseur de modèle sort une nouvelle version qui change le comportement sous un prompt existant ?
→Quelle part de ce poste est de la pure conception de prompts par rapport au système environnant: récupération, intégration d'outils, infrastructure d'évaluation ?
→Quel a été le plus gros échec de prompt que l'équipe a livré en production, et qu'est-ce qui a changé en conséquence ?
→Comment les décisions sont-elles prises sur quel modèle utiliser pour une fonctionnalité donnée, et qui possède cette décision ?

Entraînez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit sur votre premier poste suivi.

Métiers similaires

Ingénieur IA

Tech10 questions

Ingénieur Machine Learning

Disponible dans d'autres langues

English Español