Le 14 janvier, un agent chargé de répondre aux demandes de support s’est mis à refuser certaines demandes qu’il traitait normalement la veille. Aucun déploiement de code n’avait eu lieu ce jour-là. La seule modification identifiée, après recherche, était un ajustement du prompt système, effectué directement dans l’interface d’administration par une personne de l’équipe, sans trace écrite nulle part.
Cet incident, mineur en soi puisque vite corrigé, a suffi à convaincre l’équipe de traiter désormais tout changement de prompt système comme un changement de code applicatif, avec un numéro de version explicite et un changelog associé. Ce texte détaille cette pratique, pas les tests d’évaluation automatisés qui l’accompagnent par ailleurs et qui relèvent d’une démarche distincte.
Pourquoi un prompt modifié « à la volée » pose un problème
Un prompt système hébergé directement dans une interface d’administration, modifiable en quelques clics sans validation ni trace, présente un avantage réel de rapidité : une correction urgente peut être appliquée en quelques minutes. Ce même avantage devient un problème dès qu’un comportement inattendu apparaît plusieurs jours plus tard : sans historique, impossible de savoir si la cause vient d’un changement de prompt, d’une mise à jour du modèle sous-jacent, ou d’un changement de données en entrée.
Le principe retenu : un fichier, un numéro, un changelog
Le prompt système est désormais stocké dans un fichier versionné au même titre que le reste du code applicatif, avec un en-tête indiquant explicitement son numéro de version et la date du dernier changement.
# prompt-systeme-support.md
# Version: 4.2.0
# Dernière modification: 2026-01-14
Vous répondez aux demandes de support d'une plateforme de formation en ligne.
Ne traitez jamais une demande de remboursement directement : orientez-la
systématiquement vers l'ability `creer_ticket_remboursement`.
...Un changelog court, mais systématique
Chaque modification du prompt s’accompagne d’une ligne ajoutée à un changelog dédié, dans le même esprit qu’un changelog de code : une date, un numéro de version, une phrase expliquant le changement et sa raison.
## 4.2.0 - 2026-01-14
Ajout d'une consigne explicite pour orienter les demandes de remboursement
vers l'ability dédiée, suite à un cas où l'agent tentait d'y répondre
directement en texte libre.
## 4.1.0 - 2025-12-02
Reformulation de la description du ton attendu, jugée trop informelle
lors d'un retour client sur une demande sensible.Ce que ce numéro de version permet de relier
Le numéro de version du prompt est systématiquement journalisé aux côtés de chaque session d’agent traitée, au même titre que la version du modèle utilisé. En cas de comportement inattendu constaté a posteriori, cette association permet de vérifier immédiatement si le comportement correspond à la version de prompt alors en vigueur, sans devoir reconstituer l’historique à partir de souvenirs approximatifs de l’équipe.
- Le prompt système vit dans un fichier versionné, jamais uniquement dans une interface d’administration.
- Chaque changement s’accompagne d’un numéro de version et d’une ligne de changelog expliquant le pourquoi.
- Le numéro de version en vigueur est journalisé pour chaque session, pas seulement conservé dans l’historique du fichier.
Ce que cette pratique ne remplace pas
Verser un prompt dans un dépôt de code ne garantit en rien qu’un nouveau prompt se comporte correctement avant sa mise en production : cette vérification relève d’une démarche de test distincte, menée séparément sur un jeu de cas représentatifs avant chaque changement de version notable. Le versionnement seul répond à une question différente, mais tout aussi nécessaire : pouvoir expliquer, après coup, ce qui a changé et quand.
Un prompt qu’on modifie sans laisser de trace n’est pas plus fiable qu’un serveur qu’on redémarre sans savoir quelle configuration vient d’être appliquée.
En résumé
Traiter un prompt système comme du code, avec un numéro de version explicite et un changelog court mais systématique, ne demande aucun outillage sophistiqué : un fichier versionné et une discipline d’écriture suffisent. Cette seule pratique a, sur ce projet, transformé un diagnostic qui aurait pu prendre plusieurs jours en une vérification de quelques minutes lors de l’incident suivant.
