Le prompt système qui pilote ton agent est aussi critique qu'une fonction métier. Pourtant il finit souvent en littérale dans un contrôleur, modifié à la main en prod, sans historique. Le jour où le comportement régresse, personne ne sait quel prompt tournait.
Naïf vs versionné
| Aspect | String hardcodée | Prompt versionné |
|---|---|---|
| Historique | Aucun | Git ou table dédiée |
| Rollback | Impossible | Trivial |
| A/B test | Non | Par version |
| Lien réponse→prompt | Perdu | ID de version loggé |
| Revue de changement | Aucune | PR / diff |
Le minimum viable
- Les prompts vivent dans des fichiers (
prompts/extract_invoice.v3.txt) ou une tableprompt(version, body, created_at), jamais en string inline. - Chaque appel LLM logge la version de prompt utilisée (cf. Logger un LLM sans dépendance). Sans ça, impossible de corréler une régression à un changement.
- Changer un prompt = une PR avec diff lisible, pas un hotfix SSH.
- Garder l'ancienne version active jusqu'à validation de la nouvelle (déploiement progressif).
Le piège du « petit changement »
« J'ai juste reformulé une phrase » est la cause n°1 de régression silencieuse en IA. Un mot changé dans un prompt peut faire chuter un taux d'extraction de 97 % à 80 % sans aucune erreur technique. Le versionnement + les évals (lancées à chaque changement de version) sont le seul filet réel.
FAQ
Pourquoi versionner un prompt système comme du code ?
Parce qu'une modification non tracée peut faire régresser le comportement en prod sans qu'on sache quelle version tournait au moment de l'incident.
Un prompt hardcodé dans le contrôleur pose-t-il un vrai risque ?
Oui : pas d'historique, pas de rollback trivial, pas de lien entre une réponse et la version de prompt qui l'a produite.
Le versioning de prompt permet-il de l'A/B testing ?
Oui, c'est un des bénéfices directs par rapport à une chaîne hardcodée.