Versionner les prompts comme du code

« Retoucher rapidement le prompt » sans test, c'est comme un commit de production non testé — la différence ne se remarque souvent que lorsque quelque chose est déjà cassé depuis longtemps.

Les prompts sont du code, pas de la configuration

Un prompt détermine le comportement tout autant qu'une ligne de code — c'est pourquoi il mérite le même soin : contrôle de version dans Git, changements traçables et tests avant chaque déploiement.

Versionner dans Git

Les prompts appartiennent au dépôt, pas à un fichier texte volant ou une fenêtre de chat. Chaque changement devient ainsi traçable via les commits, peut être examiné précisément dans un diff et annulé si besoin via un revert.

Mesurer avant/après

Une petite collection fixe de cas de test avec le comportement attendu montre si une modification de prompt améliore effectivement les choses ou dégrade secrètement autre chose. Sans cette référence, toute évaluation reste une pure intuition.

Détecter les régressions et revenir en arrière

Si la collection de tests obtient de moins bons résultats après un changement qu'avant, c'est un signal clair de régression — et grâce au versionnage, l'état précédent qui fonctionnait peut être restauré à tout moment.

Pourquoi « retoucher rapidement » est risqué

Une seule phrase modifiée peut avoir un effet inattendu ailleurs dans le même prompt, car les modèles de langage traitent l'ensemble du contexte de façon conjointe. Sans test, un tel effet de bord reste souvent inaperçu pendant des jours, jusqu'à ce qu'un utilisateur le déclenche par hasard.

EXEMPLE

Version antérieure (prompts/support-antwort.md, v1.2) : « Réponds poliment et brièvement à la demande du client. » → Collection de tests : 30/30 cas de test respectent le format attendu. Version suivante (v1.3, une phrase ajoutée) : « Réponds poliment, brièvement et avec une proposition de résolution du problème à la demande du client. » → Exécuter à nouveau la collection de tests : 27/30 réussissent — 3 cas de test produisent désormais des propositions de solution trop longues au lieu de la brièveté requise. → Résultat : régression détectée, la v1.3 est affinée avant le déploiement plutôt que mise en production directement.

🛠️ EXERCICE — À TOI DE JOUER

Construis une petite collection de tests pour un prompt personnel et vérifie une modification par rapport à celle-ci avant de l'adopter.

Enregistre un prompt existant dans son propre fichier au sein d'un dépôt Git, si ce n'est pas déjà fait.
Écris 10 petits cas de test avec une entrée et le comportement attendu (par ex. format attendu ou contenu attendu).
Fais tourner la version actuelle du prompt sur les 10 cas de test et note le taux de réussite.
Modifie le prompt comme prévu, effectue un commit séparé pour ce changement, et refais tourner les 10 mêmes cas de test.
Compare les deux taux de réussite avant d'adopter le changement comme référence.

✅ AUTO-VÉRIFICATION

☐ Le taux de réussite a-t-il baissé après la modification, alors que tu ne t'y attendais pas ?
☐ Peux-tu restaurer l'ancienne version du prompt via l'historique Git en moins d'une minute ?

QUIZ RAPIDE

Pourquoi une simple évaluation intuitive ne suffit-elle pas pour juger si une modification de prompt constitue réellement une amélioration ?