Prompt engineering en production : ce qui change quand c'est du vrai code

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.