Il y a une différence fondamentale entre écrire des prompts pour explorer un LLM et écrire des prompts qui tournent en production 24h/24 avec de vrais utilisateurs.
La première fois qu’un de mes agents a merdé en prod — réponse incohérente, boucle infinie sur un edge case — j’ai réalisé que mon approche était encore celle d’un explorateur, pas d’un ingénieur.
La fiabilité n’est pas négociable
En mode expérimentation, une réponse bizarre sur 10 appels, c’est intéressant. En production, c’est un bug.
Premier principe intégré : traiter les prompts comme du code qui peut planter. Ce qui implique :
- Définir exactement les conditions d’échec (quand le LLM doit dire “je ne sais pas”)
- Tester avec des inputs malformés, contradictoires, vides
- Avoir une sortie dégradée explicite
Un prompt de prod a toujours une instruction de fallback. “Si tu n’as pas les informations nécessaires, réponds uniquement : INSUFFICIENT_DATA”. Pas d’interprétation, pas d’invention.
Structurer les outputs pour le code qui les consomme
En exploration, on lit les réponses à la main. En production, c’est du code qui parse la sortie.
J’impose systématiquement une structure JSON pour tout ce qui doit être consommé :
Réponds UNIQUEMENT avec ce JSON, sans markdown, sans texte avant ou après :
{
"action": "create|update|skip",
"confidence": 0.0-1.0,
"reason": "une phrase max"
}Le champ confidence est sous-estimé. Il permet de router les cas limites vers une vérification humaine plutôt que de laisser le LLM décider seul.
Versionner les prompts comme du code
Changer un prompt système en prod sans versionner, c’est comme merger sans diff.
Mon organisation :
prompts/
├── v1/
│ ├── system.md
│ └── classify.md
├── v2/
│ └── system.md
└── current -> v2/Chaque version est taguée. Si une régression apparaît, rollback en 30 secondes.
La longueur du contexte est une variable de coût
Ce que les tutos ne disent pas : chaque token du prompt système se paye à chaque appel. Sur un agent en boucle, un prompt de 2 000 tokens × 10 000 appels/jour, ça se voit dans la facture.
J’optimise les prompts de prod comme j’optimise du SQL : supprimer ce qui n’est pas utilisé, compresser les instructions redondantes. Un prompt de prod est le résultat de plusieurs itérations de compression, pas le premier draft.
Les modèles ne sont pas interchangeables
Haiku, Sonnet, Opus ne se comportent pas pareil sur le même prompt. Un prompt finement ajusté sur Sonnet peut produire des résultats différents sur Haiku — pas forcément mauvais, mais différents.
Je maintiens des configurations par modèle cible. Et quand une nouvelle version sort, je revalide sur mon jeu de tests avant de migrer.
Ce que ça change concrètement
Prompt engineering en production se rapproche du software engineering :
- Tests de régression sur un jeu d’exemples représentatifs
- Monitoring des outputs (taux de réponses hors format, taux de fallback)
- Versioning et changelog des prompts
- Revue avant tout changement en prod
Ce n’est pas plus complexe que de maintenir une API — c’est juste très différent de ce que la plupart des tutos d’introduction montrent.
Stéphanie Caumont
Product Owner IA · En savoir plus