Prompts en production : les versionner comme du code

Dans beaucoup de projets, les prompts sont traités comme des réglages anodins, modifiés à la main dans une interface web ou un fichier de configuration oublié. On change une formulation pour améliorer une réponse, on ne note rien, et quelques semaines plus tard, personne ne sait plus quelle version est en production, ni pourquoi la qualité a bougé. C’est un incident en attente, et il se produit tôt ou tard.

Un prompt est en réalité du code, au sens le plus précis : c’est une instruction qui détermine le comportement du système. Une modification de prompt change la sortie aussi sûrement qu’une modification de fonction, souvent sans qu’aucun test ne le détecte. Le traiter autrement que le reste du code, c’est renoncer à la reproductibilité, à la comparaison et au retour arrière, les trois choses qui font qu’un système se maintient.

Cet article décrit comment versionner les prompts comme du code : où les stocker, comment les modifier, comment les tester, et comment savoir à tout moment quelle version produit quel résultat.

Sortir les prompts des interfaces web

La première étape est de faire sortir les prompts de l’endroit où ils meurent : l’interface web du fournisseur, le champ de configuration, le document partagé. Un prompt qui vit dans une interface n’a ni historique ni revue. On le modifie, l’ancienne version est perdue, et aucune trace ne dit ce qui a changé ni pourquoi.

La bonne pratique est de les placer dans le dépôt de code, sous forme de fichiers versionnés, au même titre que les modules. Concrètement, un prompt devient un fichier texte, dans un dossier dédié, soumis aux mêmes règles que le reste : on le modifie par une demande de modification (pull request sur GitHub ou GitLab), on le relit, on le fusionne. À partir de là, il a un historique Git, et chaque changement est attribué et daté. Si l’équipe préfère un outil dédié, Langfuse et LangSmith proposent une gestion de prompts versionnés ; l’essentiel est que chaque version soit identifiée et retrouvable.

Séparer le prompt de sa logique d’appel

Un prompt n’est pas seulement un texte, c’est un texte qui s’insère dans un appel au modèle, avec des variables, un contexte et des paramètres. La bonne structure sépare ces deux choses. Le texte du prompt vit dans un fichier versionné. La logique d’appel, qui récupère le bon prompt, le remplit et appelle le modèle, vit dans le code.

Cette séparation a un avantage immédiat : on peut changer la formulation sans toucher à la logique, et inversement. Elle permet aussi de gérer plusieurs variantes d’un même prompt, pour tester une nouvelle formulation en parallèle de l’ancienne, sans déployer de code. C’est la condition de la comparaison, qui est le cœur du travail sur les prompts.

Un prompt, une version, un jeu de test

Versionner un prompt ne sert à rien si on ne peut pas savoir ce qu’il vaut. La valeur d’un prompt se mesure sur un jeu de test : un ensemble d’exemples représentatifs, avec la sortie attendue, sur lesquels on évalue la formulation. Ce jeu de test doit être lié au prompt, pas éparpillé dans les esprits.

Concrètement, chaque prompt est accompagné de ses cas de test. Quand on modifie le prompt, on relance le jeu de test, et on compare le score à la version précédente. Si la nouvelle formulation améliore certains cas et en dégrade d’autres, on le voit, et on décide en connaissance de cause. C’est exactement ce que fait un test unitaire pour une fonction, appliqué à un texte, et c’est la base des tests de non-régression pour l’IA.

Comparer les variantes avant de basculer

Le travail sur un prompt est rarement une amélioration nette. Une formulation gagne sur certains exemples et perd sur d’autres. La seule façon de trancher est de comparer les variantes sur le même jeu de test, en mesurant le score de chacune. Cette comparaison se fait hors production, en exécutant le modèle sur les exemples, et elle produit un verdict chiffré. Des outils d’evals comme Promptfoo ou DeepEval font exactement ce travail : ils exécutent plusieurs variantes de prompt, voire plusieurs modèles (GPT, Claude, Mistral), sur le même jeu de cas, et affichent les scores côte à côte. Branchés dans la CI (GitHub Actions, par exemple), ils bloquent une modification qui dégrade le score.

Ce verdict permet de décider sans impression. Si la nouvelle variante gagne globalement, on l’adopte. Si elle perd, on la garde de côté. Si elle est meilleure sur certains cas et pire sur d’autres, on peut affiner, ou accepter le compromis en connaissance de cause. Le point décisif est que la décision repose sur des chiffres, pas sur une lecture à l’œil.

Le retour arrière et la traçabilité en production

Quand un prompt est en production, deux choses sont nécessaires. La première est de savoir, à tout moment, quelle version tourne. La seconde est de pouvoir revenir à la version précédente en quelques secondes si la nouvelle dégrade. Ces deux choses découlent directement du versionnement : chaque déploiement note la version du prompt, et le retour arrière n’est qu’un déploiement de l’ancienne version.

Cette traçabilité se relie aux logs et traces de l’agent. Si chaque appel journalise la version du prompt utilisée, dans un outil d’observabilité LLM comme Langfuse ou LangSmith, on peut reconstituer exactement ce qui s’est passé quand un utilisateur a reçu une mauvaise réponse. C’est la même exigence que pour le code : sans version, un incident est inexplicable ; avec version, il devient une information exploitable.

Les prompts des agents : la même règle, plus de fichiers

Les agents ajoutent une complexité : ils ne se résument pas à un prompt, mais à un système de prompts, chacun jouant un rôle précis. Le prompt principal, les consignes d’appel d’outils (function calling ou descriptions d’outils MCP), les formats de sortie, les garde-fous. Que l’agent soit construit avec LangGraph, l’OpenAI Agents SDK ou le Claude Agent SDK, ces textes restent des fichiers à versionner. Chacun de ces textes est une pièce du comportement, et chacun doit être versionné comme les autres.

La règle ne change pas, elle s’étend. Chaque prompt d’agent vit dans un fichier versionné, avec son jeu de test, et la version de l’agent est la somme des versions de ses prompts et de son code. C’est ce qui rend un agent reproductible, ce qui est une exigence de base dès qu’il agit en production sur des données réelles.

Par où commencer pour versionner vos prompts

Versionner les prompts n’est pas une contrainte supplémentaire, c’est ce qui rend un système IA maintenable et mesurable. Sur un projet existant, on commence par un état des lieux : où vivent vos prompts aujourd’hui, qui les modifie, et quels cas réels peuvent servir de jeu de test. Ensuite, on les rapatrie dans le dépôt, on branche la comparaison des variantes dans la CI et on journalise la version utilisée à chaque appel.

C’est une des briques de notre méthode de mise en production, aux côtés des evals et des garde-fous. Si vos prompts sont encore modifiés à la main dans une interface, c’est le chantier le plus rentable à ouvrir avant le prochain incident.