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, on le relit, on le fusionne. À partir de là, il a un historique, et chaque changement est attribué et daté.
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.
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é.
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 d’appel. Si chaque appel journalise la version du prompt utilisée, 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, les formats de sortie, les garde-fous. 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.
L’accompagnement Agenticiel pour versionner vos prompts
Versionner les prompts comme du code n’est pas une contrainte supplémentaire, c’est ce qui rend un système IA maintenable et mesurable. Agenticiel aide les équipes à mettre cette pratique en place : on sort les prompts des interfaces, on les place dans le dépôt avec leur jeu de test, et on branche la comparaison des variantes et le retour arrière sur vos processus existants.
La méthode commence par un cadrage facturé, déduit du devis si le chantier part. On regarde où vivent vos prompts aujourd’hui, on construit le jeu de test sur vos cas réels, et on met en place le versionnement avec la traçabilité en production. À partir de là, chaque modification de prompt est mesurée, comparée et réversible.
Ce travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar, rompue aux pratiques de mise en production des modèles. La sous-traitance de développement change le coût sans changer la rigueur : vous parlez directement à ceux qui structurent vos prompts, en français, aux mêmes heures, et vous repartez avec un système dont chaque version est traçable.
Notre approche consiste à traiter les prompts comme le code qu’ils sont : on les versionne, on les teste, on les compare et on peut revenir en arrière, pour que la qualité de vos sorties ne dépende plus de la mémoire d’une personne ni d’une modification faite à la main.