Solution · AI Operations
Tes prompts sont en production et personne ne sait avec certitude quelle version tourne
Le prompt est la pièce qui pèse le plus sur le comportement de ton IA, et dans presque toutes les entreprises il s'édite à la main, sans revue, sans historique et sans moyen de revenir en arrière. On monte et on exploite la fonction qui en fait un artefact versionné, testé avant de monter et réversible en une minute.
Le problème
L'artefact qui pèse le plus sur ton IA est le seul que personne ne gouverne
- Personne ne peut affirmer avec certitude quelle version du prompt sert en ce moment, qui l'a changée en dernier ni pourquoi.
- Un changement d'une ligne se publie directement sur la production, parce qu'il n'existe aucun environnement où le tester avant sur des cas réels.
- Quand la qualité chute, impossible de revenir à la version précédente : elle n'est enregistrée nulle part, ou elle traîne dans l'historique d'une conversation de chat.
- Le même prompt vit en double dans le code, dans un outil et dans le presse-papiers de quelqu'un, et chaque copie dérive de son côté depuis des mois.
- Quand le fournisseur met le modèle à jour, il faut revoir les prompts, mais personne ne sait lesquels existent, lesquels dépendent de ce modèle ni avec quel critère ils ont été validés.
- L'équipe a arrêté de toucher aux prompts. Pas parce qu'ils sont bons : parce que les changer fait peur et que personne ne veut être celui qui casse la production un jeudi.
Le coût de ne rien changer
Tu exploites un système dont la pièce la plus déterminante n'a aucun contrôle des changements. Le coût arrive par deux côtés à la fois. D'abord, la régression que personne n'a vue venir et que découvre un client. Ensuite, plus cher, la paralysie : quand changer le prompt est un pari, l'équipe n'y touche plus et le système cesse de s'améliorer pile au moment où le marché se met à bouger. À ça s'ajoute un troisième front, qui apparaît dès que quelqu'un pose la question de l'extérieur : sans historique, tu ne peux pas reconstituer quelles instructions gouvernaient ton système le jour où il a pris une décision précise.
La solution
On monte et on exploite la gestion du changement de tes prompts : version, test, déploiement par paliers et retour arrière
- 1On inventorie et on consolide. On sort chaque prompt de là où il traîne — code, outils, documents, têtes — et on en fait un artefact avec identifiant, propriétaire, version et historique, avec une source unique de vérité que lisent tous les environnements.
- 2On sépare les environnements et on pose un gate. Un changement naît hors production, passe la batterie de cas et ne monte que s'il dépasse le seuil convenu. Le même gate pour tout le monde, sans exception pour cause d'urgence : l'urgence se traite par un chemin rapide documenté, pas en contournant le contrôle.
- 3On construit la batterie de tests du prompt : un jeu de cas réels et adversariaux, figé et versionné, qui s'exécute contre chaque candidat et compare sa sortie à celle de la version en vie. Sans comparaison contre la version en vie, un bon résultat ne veut rien dire.
- 4On déploie par paliers. La version nouvelle entre d'abord sur une part du trafic, l'ancienne tournant en parallèle sur les mêmes entrées, et seulement ensuite sur la totalité. Le retour arrière est un changement de pointeur : une minute, sans déployer de code et sans réunion.
- 5On exploite la fonction au quotidien : qui peut changer quoi, ce qui est revu avant de monter, ce qui reste consigné de chaque changement pour pouvoir le reconstituer après, et la revue programmée chaque fois que le fournisseur bouge le modèle en dessous.
Ce qui change
Ce que tu arrêtes de perdre
La question « quelle version tourne » cesse d'être une enquête et devient une consultation : il y a un identifiant, un historique et un propriétaire par prompt en production.
Mécanisme
Un changement cesse d'être un pari : il est comparé à la version en vie sur les mêmes cas avant de monter, et il monte par paliers sur une partie du trafic.
Mécanisme
Le retour arrière cesse de dépendre de quelqu'un qui se souvient du texte précédent : c'est un changement de pointeur vers une version enregistrée, sans déployer de code.
Mécanisme
Ce qu'on mesure : temps entre la détection d'une régression et son retour arrière, % de changements passés par le gate, changements annulés sur le total et nombre de prompts en production sans propriétaire identifié.
Ce qu'on mesure
Fiche technique
- Travail supprimé
- éditer des prompts à la main sur la production, sans historique, sans comparaison contre la version en vie et sans moyen de revenir en arrière quand la qualité chute
- Mise en place habituelle
- 4–8 semaines
- Entrée
- une proposition de changement sur un prompt en production : un ajustement d'instruction, un changement de modèle ou une correction après un incident
- Sortie
- une version nouvelle testée contre la batterie de cas, comparée à la version en vie, déployée par paliers et réversible en une minute, avec son journal du qui, du quand et du pourquoi
- Compatible avec
- OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfusePromptfooBraintrustGitHub ActionsGitLab CI
- Peut se connecter à
- Tu repositorio y tu circuito de revisión de códigoTus registros de producción, de donde salen los casos de pruebaTu función de evaluación continua de calidad, si ya la tienes montadaTu registro de trazabilidad y tu inventario de sistemas de IA
- Ce qu’on mesure
- temps entre la détection d'une régression et son retour arrière% de changements passés par le gate avant la production% de changements annulés sur le total déployéprompts en production sans propriétaire identifié
- Adapté pour
- les entreprises avec de l'IA en production et plusieurs personnes qui touchent aux prompts — DSI, COO ou responsable IA — qui doivent pouvoir changer vite sans casser, et démontrer ce qui gouvernait le système à chaque instant
- Pas adapté pour
- ceux qui n'ont qu'un seul prompt stable auquel personne ne touche depuis des mois, ou ceux qui cherchent à mesurer si la réponse de l'agent est bonne : ça, c'est l'évaluation de la qualité, une fonction distincte et complémentaire
Questions fréquentes
Par ce qu'ils gouvernent. L'évaluation continue mesure si la réponse de ton agent est bonne aujourd'hui : elle échantillonne de vraies conversations, les note contre un critère et détecte que la qualité a chuté. Cette fonction-ci gouverne le changement de l'artefact qui produit cette réponse : où vit le prompt, qui peut y toucher, quel test il doit passer avant de monter, comment il se déploie et comment on revient en arrière. Elles sont complémentaires et marchent mieux ensemble — la batterie de cas et les métriques de qualité se nourrissent des mêmes données —, mais elles règlent des problèmes différents : l'une te dit que quelque chose s'est cassé, l'autre fait que le casser soit réversible et rare.
Git est la fondation et on l'utilise, mais seul il règle la moitié. Il te donne l'historique et la revue, et c'est déjà plus que ce qu'a la majorité. Ce qu'il ne te donne pas : un environnement où tester le candidat contre des cas réels avant de monter, la comparaison automatique contre la version en vie, le déploiement sur une partie du trafic et le retour arrière sans déployer de code — celui dont tu as besoin à onze heures du soir. En plus, dans beaucoup d'équipes, celui qui écrit le mieux les prompts ne travaille pas dans le dépôt, et l'obliger à passer par une pull request pour changer une phrase finit toujours en copie parallèle.
Au contraire : ce qui freine aujourd'hui, c'est la peur. Dans les équipes sans contrôle des changements, on touche peu aux prompts et en retenant son souffle, parce que le moindre ajustement peut casser quelque chose que personne ne détectera avant qu'un client se plaigne. Quand tester coûte des minutes et revenir en arrière coûte une minute, le prix de l'erreur baisse assez pour que les gens se remettent à expérimenter. Le gate n'est pas là pour ajouter de la bureaucratie : il est là pour rendre le changement bon marché. Et pour ce qui est vraiment urgent, il y a un chemin rapide documenté, avec revue a posteriori obligatoire.
On le monte chez toi ?
Tu as ciblé le problème. On livre la solution et on la laisse mesurée.