Chaque équipe d'ingénierie a une histoire de fonctionnalité IA cassée. Les sorties du LLM ont changé, une régression est apparue en production, et personne ne pouvait identifier exactement ce qui avait changé — ni quand. Dans la plupart des cas, le coupable est le même : le prompt vivait quelque part en dehors du contrôle de version.
Les prompts sont du code
Un prompt encode de la logique métier. Il indique au modèle comment se comporter, quoi prioriser, comment formater les sorties, et quels cas limites gérer. Quand vous traitez les prompts comme des chaînes de configuration jetables dispersées dans des variables d'environnement, des lignes de base de données ou des constantes dans un fichier Python, vous perdez toutes les propriétés qui rendent le code maintenable :
- Pas de diffs. Impossible de voir ce qui a changé entre la version qui fonctionnait et celle qui casse.
- Pas de rollbacks. Quand la production plante, vous ne pouvez pas revenir au dernier état de prompt connu comme stable.
- Pas de reviews. Les changements de prompt contournent le processus de pull request — le même processus qui attrape les bugs dans toutes les autres couches du système.
- Pas d'attribution. Vous ne savez pas qui a changé le prompt, ni pourquoi.
Le coût des changements invisibles
Les changements de prompt invisibles sont le tueur silencieux de la fiabilité IA. Un chef de produit modifie un prompt directement dans un dashboard SaaS. Un développeur met à jour une constante de string sans y penser. Une correction bien intentionnée d'un format de sortie casse silencieusement un parser en aval. Aucun de ces changements n'apparaît dans votre historique Git.
Le problème s'aggrave avec le temps. Après six mois, un prompt a été édité une douzaine de fois, et personne n'a de modèle mental fiable de son comportement actuel. Le tester ressemble à deviner.
À quoi ressemblent les prompts versionnés
Quand les prompts vivent dans des fichiers versionnés, vous obtenez tout ce que vous tenez pour acquis dans le reste de votre codebase. Un fichier .waiflo.json contenant votre workflow est commité comme n'importe quel autre fichier source :
git diff HEAD~1 workflows/support_triage.waiflo.json
- "ws_system_prompt": "You are a support agent. Classify tickets.",
+ "ws_system_prompt": "You are a senior support engineer. Classify tickets by severity and category."Ce diff est relisable, attribuable et réversible. Votre pipeline CI peut lancer des évaluations dessus. Vos collègues peuvent laisser des commentaires. S'il casse quelque chose, git revert fonctionne en quelques secondes.
Les schémas typés ferment la boucle
Le contrôle de version seul ne suffit pas. Même un prompt parfaitement versionné peut produire silencieusement des sorties qui cassent le code en aval si le format de sortie change. Le ws_output_schema de Waiflo rend le contrat de sortie explicite et lisible par machine. Quand le schéma change, le diff le montre. Quand la sortie viole le schéma, le runtime le détecte.
La combinaison — prompts versionnés avec schémas typés — vous donne le même niveau de confiance pour la logique IA que pour n'importe quel autre module typé et testé de votre système.
Commencer petit
Vous n'avez pas besoin de tout migrer d'un coup. Commencez par votre fonctionnalité IA la plus critique : celle où une régression serait la plus douloureuse. Déplacez son prompt dans un fichier .waiflo.json. Commitez-le. Ajoutez une vérification CI qui lance votre suite d'évaluation dessus. La boucle de feedback que vous gagnez la première semaine fera la preuve pour faire la même chose partout ailleurs.
Vos prompts font déjà le travail du code. Il est temps de les traiter comme tels.