Gestion et versionnement des prompts

Un prompt en production fait partie du comportement de votre logiciel. La gestion de prompts est la discipline qui consiste à le traiter ainsi : savoir quelle version tourne, qui l’a modifiée et pourquoi, si elle a été testée et comment revenir en arrière. Cette pratique s’appelle parfois PromptOps.

Les problèmes qu’elle résout

• Un prompt est modifié dans un tableau de bord et personne ne peut dire ce qu’il était la semaine dernière.
• Le même prompt est copié dans quatre services et trois d’entre eux sont périmés.
• Un petit changement de formulation double le coût en tokens, et on s’en aperçoit sur la facture.
• Une mise à niveau du modèle change le comportement et aucun test ne montre comment.
• Une clé d’API est collée dans un fichier de prompt et validée dans le dépôt.

Stockez les prompts comme des fichiers

Gardez chaque prompt dans son propre fichier sous gestion de versions, à côté du code qui l’utilise.

prompts/
  support-reply.md
  ticket-classify.md
  summarize-incident.md

Les fichiers vous donnent historique, différences, relecture, blame et retour arrière gratuitement. Un fichier texte brut ou Markdown avec des variables nommées suffit :

## Task
Classify the support ticket as billing, bug, or feature request.

## Output format
Return only the label.

## Input
<ticket>
{{ticket}}
</ticket>

Évitez de construire les prompts par concaténation de chaînes dispersée entre des fonctions. Si personne ne peut lire le prompt entier à un seul endroit, personne ne peut le relire.

Séparez le modèle des données

Un modèle de prompt a des instructions fixes et des variables nommées. Gardez-les séparés :

• Les variables sont explicites. {{ticket}}, pas un emplacement de format sans nom.
• Chaque variable est délimitée. Enveloppée dans des balises, pour que le texte inséré ne puisse pas se lire comme des instructions.
• Le rendu se fait à un seul endroit. Une fonction remplit les modèles, échappe l’entrée et consigne la version de modèle utilisée.

Versionnez chaque changement

Utilisez les commits comme versions. Chaque changement a un auteur, une date et un message qui explique pourquoi.

Enregistrez le couple qui compte. Le comportement dépend du prompt et du modèle. Consignez la version du prompt et l’identifiant du modèle à chaque requête, afin de pouvoir relier une sortie à ce qui l’a produite.

Tenez un journal des modifications pour les prompts importants. Une ligne par changement : quoi, pourquoi et l’effet sur les résultats des tests.

Étiquetez les versions. Quand un prompt est déployé, étiquetez-le. Revenir en arrière devient alors une opération connue.

Relisez les changements de prompts comme ceux du code

Une différence de prompt mérite une vraie relecture. Les relecteurs devraient se demander :

• Le changement contredit-il une instruction existante ?
• Quelque chose a-t-il été retiré, comme une contrainte ou le format de sortie ?
• Le nombre de tokens a-t-il bougé, et est-ce acceptable ?
• Existe-t-il un test pour le comportement que ce changement doit corriger ?

Des contrôles automatiques répondent à plusieurs de ces questions avant qu’un humain ne regarde. La barrière de test des prompts fait échouer la construction lorsqu’un fichier de prompt tombe sous un score de qualité minimal, dépasse un budget de tokens ou contient un constat critique. La configuration vit dans le dépôt :

{
  "include": ["prompts/**/*.md"],
  "model": "gpt-4.1",
  "minScore": 70,
  "maxTokens": 2000,
  "failOn": "critical"
}

Comme les contrôles sont déterministes et hors ligne, ils n’ont pas besoin de clé d’API en CI et ne produisent jamais d’échec intermittent.

Testez avant la publication

Les contrôles statiques confirment que le prompt est sain. Un jeu de tests de sortie confirme qu’il se comporte toujours bien. Lancez les deux quand un prompt change, et relancez les tests de sortie quand la version du modèle change. Voir le test et l’évaluation de prompts.

Déployez progressivement

Pour les prompts avec du trafic réel :

1. Ombre. Exécutez la nouvelle version à côté de l’ancienne et comparez les sorties sans les montrer aux utilisateurs.
2. Canari. Envoyez une petite part du trafic à la nouvelle version et surveillez les taux d’erreur, la validité du format et les signaux utilisateurs.
3. Promouvez ou annulez. Décidez sur les chiffres.

Gardez la version précédente déployable jusqu’à ce que la nouvelle ait fait ses preuves.

Surveillez en production

Suivez, par version de prompt :

• Les tokens d’entrée et de sortie, et le coût.
• La latence.
• La part de réponses qui échouent à la validation.
• Les refus et les replis.
• Les retours des utilisateurs, quand vous les collectez.

Faites attention à ce que vous journalisez. Les prompts et les sorties peuvent contenir des données personnelles et des secrets. Journalisez des métadonnées par défaut et masquez le contenu avant de le stocker. Voir la détection des données personnelles et des secrets dans les prompts.

Gardez les secrets hors des prompts

Les fichiers de prompts sont lus, comparés, partagés et envoyés à des tiers. N’y stockez jamais d’identifiants. Transmettez les secrets aux outils par votre application, pas par le contexte du modèle. Un scanner en CI attrape les accidents ; le scanner de sécurité des prompts échoue dès qu’il détecte un identifiant.

Responsabilité et réutilisation

• Donnez un responsable à chaque prompt. Quelqu’un décide des changements et répond aux questions.
• Partagez via une bibliothèque, pas en copiant. Une seule source, importée là où c’est nécessaire.
• Documentez le contrat. Les variables qu’il prend, ce qu’il renvoie et ce qu’il suppose.
• Retirez les anciens prompts. Les prompts inutilisés sont quand même copiés par la prochaine personne qui les trouve.

Des points de départ choisis et testés aident ici. Les modèles PromptFlowEngine sont tenus à un score élevé, sans avertissement, à chaque construction.

Outils dédiés ou fichiers simples

Les plateformes de gestion de prompts ajoutent un éditeur visuel, le suivi d’expériences et un accès pour les non-ingénieurs. Elles valent la peine lorsque beaucoup de personnes extérieures à l’ingénierie modifient des prompts. Pour la plupart des équipes, des fichiers dans git plus des contrôles automatiques donnent l’essentiel sans rien de nouveau à exploiter. Quel que soit votre choix, les exigences sont les mêmes : une source de vérité unique, un historique, une relecture, des tests et un retour arrière.

Une liste de contrôle pour démarrer

• Chaque prompt de production est un fichier sous gestion de versions.
• Les variables sont nommées et délimitées.
• La version du prompt et le modèle sont consignés avec chaque requête.
• Un contrôle statique s’exécute à chaque pull request.
• Un jeu de tests existe et s’exécute quand le prompt ou le modèle change.
• Des budgets de tokens sont fixés et appliqués.
• Aucun secret dans les fichiers de prompts, vérifié automatiquement.
• Il existe une façon documentée de revenir en arrière.