Prompt Engineer

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.