Ingénierie de prompt en production

Ce que la démonstration ne dit pas

Un prompt qui fonctionne en démonstration ne suffit pas en production, et ce n’est pas parce qu’il était mauvais : c’est parce que les exigences ont changé. En démonstration, vous choisissez l’entrée, vous jugez la sortie à l’œil, et vous relancez si le résultat vous déplaît. En production, l’entrée arrive telle quelle, personne ne relit, et la sortie part directement dans un système en aval qui la prend pour argent comptant.

Quatre exigences apparaissent à ce moment précis. La cohérence d’abord : le prompt doit produire des résultats stables sur des milliers d’appels, et non une bonne réponse sur trois essais que vous avez vous-même choisis. La robustesse ensuite, c’est-à-dire la capacité à encaisser des entrées imprévues, malformées ou adversariales — le champ resté vide, le copier-coller de quarante mille caractères, le message qui contient lui-même des instructions destinées au modèle. La performance devient un sujet à son tour, parce que le temps de réponse et le coût, invisibles sur dix requêtes, structurent le budget dès qu’on en compte cent mille par jour. La maintenabilité, enfin, impose que le prompt soit versionné, testé et documenté : celui qui le reprendra dans six mois doit comprendre pourquoi telle phrase bizarre y figure, sinon il la supprimera et rouvrira le bug qu’elle corrigeait.

La boucle de construction

La méthode tient en quatre temps, et l’ordre compte autant que le contenu de chaque étape.

Tout commence par les spécifications, avant d’écrire la moindre ligne de prompt. Vous devez pouvoir énoncer le cas d’usage exact, sans le résumer à une intention vague ; le format de sortie attendu, jusqu’aux noms des champs si une application les consomme ; les cas limites que vous anticipez déjà ; et les critères de succès mesurables. Cette dernière question est celle qu’on saute le plus volontiers, et c’est pourtant elle qui décide si le projet aura une fin. « Une bonne synthèse » n’est pas un critère et vous pourrez itérer dessus indéfiniment ; « les trois actions décidées apparaissent dans neuf résumés sur dix » en est un, et il se vérifie.

Vient ensuite le premier jet, qu’il faut délibérément commencer simple. Le générateur de prompts fournit un point de départ si vous partez de zéro, mais résistez à la tentation d’empiler d’emblée toutes les précautions imaginables : avec quinze consignes écrites d’un coup, vous ne saurez jamais laquelle produit quel effet.

La troisième étape est le test par évaluations. Vous construisez un jeu de test fait de paires entrée/sortie attendue, vous exécutez le prompt dessus, et vous mesurez. Une trentaine de cas soigneusement choisis, dont une bonne part de cas tordus, vous apprendra davantage que trois cents entrées ramassées au hasard dans les logs.

Reste l’itération : analyser les échecs, ajuster le prompt, relancer les tests, recommencer jusqu’à atteindre les performances souhaitées. Ce cycle est le cœur du métier ; tout le reste n’en est que l’outillage.

Prévoir l’échec dans le prompt lui-même

Un prompt de production doit dire quoi faire quand les données ne sont pas conformes, sans quoi Claude comblera le manque par déduction — et une déduction plausible est infiniment plus dangereuse qu’un refus. On lui ménage donc une sortie explicite, repérable par le code appelant.

Si les donnees d'entree sont incompletes ou incoherentes, signale-le dans des balises <erreur></erreur>
plutot que de deviner ou d'halluciner.

Tout l’intérêt de la balise dédiée est là : elle rend le signalement exploitable en aval. Votre application détecte la présence de <erreur>, écarte l’appel et le route vers un traitement humain, au lieu d’enregistrer silencieusement une donnée fausse qu’on découvrira trois mois plus tard.

Traiter les prompts comme du code

Le versioning découle du même principe. Stockez vos prompts dans un système de versioning, associez chaque version à ses résultats d’évaluation, et documentez les changements ainsi que leurs raisons. Sans cette discipline, une équipe se retrouve devant trois variantes d’un prompt de classification sans savoir laquelle tourne réellement en production, ni pourquoi la deuxième a été abandonnée.

Les tests de régression complètent le dispositif. Quand vous modifiez un prompt, réexécutez la totalité des tests existants, pas seulement celui qui vous a poussé à intervenir : une amélioration sur un cas peut en dégrader un autre, et cette dégradation-là est silencieuse. Une consigne ajoutée pour mieux traiter les demandes ambiguës rendra très bien le modèle hésitant sur les cas les plus simples, ceux qui représentent l’essentiel du trafic et que plus personne ne pensait à tester.

Le monitoring prend ensuite le relais, une fois le prompt en service. Les évaluations vous disent ce qu’il fait sur votre jeu de cas ; le suivi en production vous dit ce qu’il fait sur les entrées que vous n’aviez pas imaginées.

Points clés à retenir

• La production ajoute quatre exigences au prototype : cohérence, robustesse, performance, maintenabilité.
• Des critères de succès mesurables définis avant le premier jet évitent l’itération sans fin.
• Le jeu de test à paires entrée/sortie est ce qui transforme une impression en mesure.
• Prévoyez un signalement d’erreur balisé plutôt que de laisser Claude deviner sur une entrée incomplète.
• Versionnez vos prompts et rejouez tous les tests à chaque modification : une amélioration locale peut être une régression globale.