“Un prompt n'est pas un vœu chuchoté à un génie. C'est un cahier des charges remis à un contractuel.”
Un prompt est un document structuré
Un prompt de production n'est pas une phrase. C'est un document en couches : un message système qui établit le rôle et les règles, des instructions claires pour la tâche, deux ou trois exemples résolus, l'entrée réelle de l'utilisateur, et une spécification du format de sortie. Chaque couche accomplit un rôle différent, et en omettre une est là où la qualité s'échappe.
La raison pour laquelle la structure bat l'ingéniosité : les modèles sont bien meilleurs à l'imitation qu'à suivre des instructions abstraites. Montrez au modèle exactement à quoi ressemble une bonne sortie et il reproduira le patron. Décrivez-la avec des adjectifs et il improvisera.
Les techniques qui portent le poids
La plupart des conseils sur les prompts sont des optimums locaux qui s'effondrent à la prochaine version du modèle. Quelques principes se généralisent parce qu'ils concernent l'information, pas des astuces :
- Contraintes — précisez le format, la longueur et ce qu'il faut exclure. Une boîte serrée se remplit bien ; un prompt ouvert s'improvise.
- Exemples (quelques tirs) — montrez des paires entrée/sortie. C'est le levier à plus fort impact que vous puissiez ajouter à un prompt.
- Décomposition — découpez une tâche en plusieurs étapes en plusieurs prompts, ou demandez au modèle de raisonner par étapes avant de répondre.
- Rôle et public — « vous êtes un éditeur technique rigoureux qui écrit pour des non-experts » façonne le registre plus sûrement que n'importe quel adjectif dans l'instruction.
- Schéma de sortie — précisez la forme exacte (clés JSON, sections) que vous analyserez en retour.
Laissez le modèle réfléchir avant de répondre
Pour tout ce qui implique du raisonnement, demander directement la réponse finale laisse de la qualité sur la table. Laisser le modèle produire d'abord un raisonnement intermédiaire — la « chaîne de pensée » — améliore mesuralement les résultats sur les problèmes en plusieurs étapes, parce que chaque jeton généré peut se conditionner sur les précédents. Vous lui donnez de l'espace pour travailler.
La forme pratique : demandez le raisonnement, puis la réponse, dans une sortie structurée, et extrayez la réponse. Ou, avec les modèles de « raisonnement » plus récents, la réflexion se fait en interne et vous payez simplement en latence et en jetons. Dans tous les cas, les problèmes difficiles demandent de la délibération, pas une réponse spontanée.
Versionnez vos prompts comme du code
Un prompt est la chaîne de caractères la plus structurante de votre application, et les équipes l'éditent couramment dans une zone de texte en production sans aucun historique. C'est insensé dès qu'on le dit à voix haute. Les prompts appartiennent au contrôle de version, avec un journal des modifications, lié à l'exécution d'évaluation qui a justifié le changement.
La discipline : une modification de prompt est une modification de code. Elle obtient une diff, une revue, une exécution d'évaluation et un chemin de retour arrière. « J'ai retouché le prompt et ça semble mieux » est la façon dont les équipes livrent des régressions silencieuses découvertes par des utilisateurs en colère une semaine plus tard.
En une ligne chacun
- Un prompt est un document structuré : système, instructions, exemples, entrée, schéma de sortie.
- Les exemples battent les instructions ; les contraintes battent l'espoir ; laissez le modèle raisonner avant les réponses difficiles.
- Ne collectionnez pas les astuces — intériorisez les principes, qui survivent aux changements de modèle.
- Les prompts sont du code : versionnez-les, révisez-les et conditionnez les changements à une exécution d'évaluation.
Où aller ensuite