À force de bricoler des prompts toute la journée, on finit par se mentir un peu. On croit qu’un prompt est « juste du texte », donc pas besoin d’ingénierie. Puis un matin, tout casse.
Le modèle change, la température par défaut n’est plus la même, un outil ajoute une sécurité, ou simplement… tu as modifié deux lignes « vite fait » hier soir. Résultat : la réponse n’a plus le ton, la structure, ou pire, elle hallucine un truc gênant. Et toi tu es là, à relire un diff dans ta tête. Sans historique. Sans test. Sans pipeline. Le grand vide.
L’idée de cet article : appliquer une logique CI/CD aux prompts. Comme pour du code. Versionner, tester, déployer. Et surtout, le faire de manière pragmatique, pas avec une usine à gaz.
Sur Le Blog Tech Pro de Samyn-Antoy ABASSE (oui, celui que tu lis là), je parle souvent de méthodes « build/scale/sell ». Le CI/CD pour prompts, c’est exactement ça. Tu construis un prompt comme un produit. Tu l’améliores. Tu le livres. Et tu gardes la main.
Objectif : sortir du « prompt artisanal » et passer au « prompt industrialisé, mais humain ».
Pourquoi faire du CI/CD pour prompts
Un prompt en production, ce n’est pas une phrase inspirante sur un Notion. C’est un composant.
Et comme tout composant, il a des risques :
- régression : ton prompt marchait hier, aujourd’hui il sort un résultat bancal.
- dérive : petit à petit, tu ajoutes des consignes, puis ça devient contradictoire.
- dépendance au modèle : GPT, Claude, Mistral, Gemini… chacun a ses habitudes.
- risque conformité : données sensibles, secrets, citations, droits d’auteur, etc.
- coût : plus ton prompt est long, plus tu payes, plus ça ralentit.
Le CI/CD te force à formaliser. Ça peut sembler lourd au début, mais franchement, quand tu as 10 prompts critiques pour un projet, tu ne veux plus revenir en arrière.
À quoi ressemble un « prompt en production »
Avant la tuyauterie CI/CD, il faut s’entendre sur ce qu’on déploie.
Pour moi, un prompt « sérieux » c’est :
- un template avec variables (ex.
{lang},{tone},{audience},{input}) - des règles (do, don’t)
- un format de sortie contractuel (JSON, Markdown, sections fixes)
- des exemples (few shot) si nécessaire
- une stratégie de fallback si l’entrée est ambiguë
- des tests avec entrées représentatives
Et si tu utilises un agent ou un workflow (LangChain, n8n, Make, Zapier, etc.), le prompt est souvent juste une pièce. Mais une pièce critique.
Architecture simple : repo Git pour prompts
Oui, Git. Pas besoin de réinventer.
Structure de repo recommandée
text prompts/ README.md prompts/ blog_post/ system.md user.md config.yml tests/ cases.yml expected/ case_01.md evals/ scoring.py scripts/ run_eval.sh
Quelques idées :
system.md: le cadre, la personnalité, les interdits.user.md: le template de la demande, avec variables.config.yml: modèle, température, max tokens, stop sequences, etc.tests/: tes cas de tests.expected/: sorties attendues (si tu fais des tests déterministes) ou critères (si non déterministes).
Versionner : conventions, tags, changelog
Le gros piège, c’est de versionner « à l’arrache ». Un prompt change, mais personne ne sait pourquoi. Et dans 3 semaines, tu as une discussion stérile du genre : « on revient à l’ancien ».
Conventions utiles
Semantic versioning pour prompts : MAJOR.MINOR.PATCH
- MAJOR : changement de format de sortie, nouvelles contraintes fortes.
- MINOR : amélioration compatible, plus de précision, nouveaux exemples.
- PATCH : typo, micro-ajustement.
Tiens aussi un changelog : même basique, mais écrit.
Exemple de messages de commit :
feat(prompt): ajoute contrainte de citations vérifiablesfix(prompt): limite les réponses à 1200 motsrefactor(prompt): simplifie les règles de ton
Et quand tu déploies : tag blog_post-v1.4.0.
Tu verras, juste ça, ça calme déjà le chaos.
Tester : ce qu'on teste vraiment avec des prompts
Tester un prompt, ce n'est pas seulement vérifier « la réponse est bonne ». Déjà parce que « bon » est flou. Et ensuite parce que les modèles sont probabilistes.
Donc on teste des propriétés.
1) Tests de format
Le plus simple, et le plus rentable. Tu peux faire ça avec un parseur JSON, ou des regex simples.
- La sortie est en JSON valide.
- Le Markdown a des titres attendus.
- Les sections obligatoires sont présentes.
- Aucune balise interdite n'apparaît.
- Pas de texte hors structure.
2) Tests de sécurité et conformité
Même si ton modèle est « safe », un prompt mal fichu peut pousser à des sorties borderline. Tu veux éviter :
- La fuite de secrets.
- Les instructions dangereuses.
- L'exposition de données personnelles.
- Tout contenu non autorisé.
3) Tests de qualité
Plus dur, mais faisable.
- Score de lisibilité
- Longueur max
- Absence de répétitions
- Cohérence du ton
- Couverture de points clés
Souvent, je fais un scoring hybride : règles + LLM-as-a-judge, mais avec prudence.
4) Tests de non-régression sur dataset
Tu prends 20 à 50 entrées réelles (anonymisées), tu rejoues le prompt, tu compares.
Pas forcément au mot près. Plutôt sur des scores ou des contraintes.
Outils concrets pour faire des evals
Il y a des frameworks, oui. Mais tu peux faire simple.
Option « minimaliste » : scripts maison
- Un YAML de cas de tests
- Un script Python qui appelle l'API du modèle
- Un dossier de résultats
- Un scoring basique
- Un seuil défini : la CI échoue si le seuil n'est pas atteint
Option « structurée » : frameworks d'évaluation
- promptfoo : très pratique pour tester prompts et comparer modèles.
- OpenAI Evals : puissant, plus orienté OpenAI.
- LangSmith : bon pour tracer, observer, évaluer des chaînes.
- Ragas : utile pour RAG, QA sur documents.
Je ne vais pas te vendre une religion ici. Si tu as 3 prompts, fais simple. Si tu en as 30, outille-toi.
Exemple : un cas de test en YAML
Le cas de test suivant illustre comment valider qu'un prompt conserve la bonne structure et la bonne concision :
- id : tone_simple_fr
- Variables : langue française, ton simple et direct (pas marketing), audience développeur junior
- Input : "Explique la différence entre CI et CD pour un pipeline GitHub."
- Assertion : le texte doit contenir "intégration continue"
- Assertion : le texte doit contenir "déploiement continu"
- Assertion : le texte ne doit pas dépasser 250 mots
CI : GitHub Actions pour exécuter les tests
Ton pipeline peut être très court :
- PR ouverte
- tests prompts
- si OK, merge
Exemple de workflow GitHub Actions (simplifié) :
yaml name: prompt-ci
on: pull_request:
jobs: test-prompts: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.11" - run: pip install -r requirements.txt - run: python evals/scoring.py env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
Oui, ça coûte des tokens. Donc :
- limite le nombre de tests en PR
- fais une suite complète la nuit
- cache ou réduis la génération
- utilise un modèle moins cher pour certaines validations de format
CD : déployer un prompt, ça veut dire quoi
Ça dépend de ton système.
Cas 1 : ton app charge les prompts depuis un repo
Simple : tu déploies l’app, les prompts sont dans l’image Docker. Le prompt change = nouvelle version de l’app.
Cas 2 : prompts stockés dans un « prompt registry »
Tu peux stocker les prompts dans :
- un bucket S3
- une base (PostgreSQL)
- un KV (Redis)
- un outil interne
Dans ce cas, le CD consiste à publier la version vX.Y.Z dans le registry, puis mettre à jour une référence.
Cas 3 : outils no-code
Si ton prompt vit dans n8n / Make / Zapier, le CD est souvent manuel. Mais tu peux :
- exporter les workflows en JSON et les versionner
- automatiser l’import via API quand c’est possible
- au minimum, mettre le prompt dans Git et coller la version dans l’outil
Le truc important : un prompt doit avoir une identité. Un ID + une version.
Stratégie de déploiement : canary et rollback
Oui, comme en dev.
- canary : 5 pour cent des requêtes utilisent le nouveau prompt.
- monitoring : tu mesures erreurs, taux de rework, satisfaction, temps de réponse.
- rollback : tu repasses à la version précédente en 10 secondes.
Sans rollback, tu as juste de la foi.
Observabilité : logs utiles, mais pas intrusifs
Quand un prompt échoue, tu veux comprendre pourquoi.
Ce que je log souvent :
- version du prompt
- modèle utilisé
- température et paramètres
- longueur entrée et sortie
- erreurs de parsing
- score de test ou de heuristique
Mais attention aux données sensibles. Anonymise, tronque, hash. Et évite de stocker des inputs utilisateurs bruts si ce sont des données perso.
Images à insérer dans l’article
Sur WordPress, tu peux intégrer ces visuels simplement. Voilà ce que je mettrais, à des endroits clés.
1) Schéma CI/CD pour prompts
2) Exemple de structure de repo Git
3) Exemple de pipeline GitHub Actions
Ces images sont des placeholders propres. Remplace-les plus tard par tes captures (promptfoo, Actions, dashboards). Mais au moins, l’article respire déjà.
Bonnes pratiques que je garde sous la main
Quelques règles simples, qui évitent beaucoup de douleur :
- Contrat de sortie d'abord : définis le format avant le style.
- Règles courtes : mieux vaut 8 règles solides que 30 consignes fragiles.
- Détecter l'ambiguïté : si l'input manque de contexte, demander une question.
- Limiter les libertés : température plus basse quand tu veux du stable.
- Isoler les prompts : un prompt par responsabilité.
- Documenter comme un composant : usage, variables, exemples, anti-exemples.
Mini recette : mettre en place ça en 2 heures
Si tu veux une marche à suivre rapide :
- Crée un repo
prompts. - Mets ton prompt principal en
system.mdetuser.md. - Ajoute 10 cas de test YAML.
- Écris un script Python de test.
- Branche GitHub Actions sur les PR.
- Tag une version quand tu merges.
- Loggue la version en prod.
Ce que doit faire ton script Python de test
- Appeler ton modèle.
- Valider 3 ou 4 assertions simples.
Et ensuite tu améliores. Tranquille.
Pour aller plus loin sur mon blog
Si ce genre de méthode te parle, tu peux jeter un œil aux autres articles et pages sur Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, surtout la partie productivité, prompt engineering et méthodes de travail. L'idée, c'est de partager des systèmes qui tiennent dans le temps, pas des astuces qui brillent 24 heures.
Conclusion
Le CI/CD pour prompts, ce n’est pas un luxe. C’est juste la suite logique quand un prompt commence à créer de la valeur, ou à casser des choses.
Versionner te donne de la mémoire. Tester te donne de la confiance. Déployer proprement te donne la vitesse. Et si tu ajoutes rollback + observabilité, tu as un vrai système.
Et là, tu peux enfin arrêter de « prier » après chaque modification de prompt. Tu merges. Tu testes. Tu ship. Puis tu dors.
Questions fréquemment posées
Pourquoi est-il important d'appliquer une logique CI/CD aux prompts ?
Appliquer une logique CI/CD aux prompts permet de gérer efficacement les risques tels que la régression, la dérive, la dépendance au modèle, les risques de conformité et le coût. Cela force à formaliser, versionner, tester et déployer les prompts comme des composants logiciels, assurant ainsi leur fiabilité et leur maintenabilité dans le temps.
Qu'est-ce qu'un "prompt en production" selon l'article ?
Un prompt en production est un composant structuré comprenant un template avec variables (ex. {lang}, {tone}), des règles claires (do/don't), un format de sortie contractuel (JSON, Markdown), des exemples (few shot) si nécessaire, une stratégie de fallback pour gérer l'ambiguïté, ainsi que des tests avec des entrées représentatives. Il s'agit d'un artefact sérieux et formalisé prêt à être intégré dans un workflow ou un agent.
Comment structurer un dépôt Git pour gérer ses prompts efficacement ?
Une structure recommandée inclut un dossier 'prompts/' contenant les fichiers system.md (cadre, personnalité), user.md (template avec variables), config.yml (paramètres du modèle), un dossier 'tests/' avec cases.yml pour les cas de test, 'expected/' pour les sorties attendues ou critères d'évaluation, et 'evals/' avec scripts d'évaluation. Utiliser Git permet de versionner proprement et garder un historique clair.
Quelles conventions de versionning adopter pour les prompts ?
Il est conseillé d'utiliser le Semantic Versioning : MAJOR.MINOR.PATCH. MAJOR pour les changements majeurs affectant le format ou contraintes fortes, MINOR pour des améliorations compatibles ou nouveaux exemples, PATCH pour des corrections mineures comme typos. Tenir aussi un changelog écrit et utiliser des messages de commit clairs aide à comprendre l'évolution du prompt.
Quels sont les principaux risques liés à l'utilisation non contrôlée des prompts ?
Les principaux risques incluent la régression où un prompt qui fonctionnait bien produit soudainement des résultats bancals ; la dérive due à l'accumulation contradictoire de consignes ; la dépendance spécifique à un modèle particulier ; les problèmes de conformité liés aux données sensibles ou droits d'auteur ; ainsi que l'augmentation du coût et du temps de traitement liée à la longueur excessive du prompt.
Quelles bonnes pratiques recommandes-tu pour tester efficacement ses prompts ?
Tester un prompt ne se limite pas à vérifier une seule sortie. Il faut définir des cas de test représentatifs couvrant différentes entrées possibles, comparer les résultats attendus (deterministes ou critères qualitatifs) et automatiser ces tests via des scripts d'évaluation. Cela garantit que le prompt conserve son ton, sa structure et évite les hallucinations gênantes même après modifications ou mises à jour du modèle.
0 Commentaires