Prompt IA : comment tester une nouvelle version sans casser ce qui fonctionne ?

Une nouvelle version de prompt n’est pas meilleure parce qu’elle produit une réponse plus convaincante. Elle est meilleure si elle améliore le cas visé sans dégrader les autres cas importants.

Pour le vérifier, conservez l’ancienne version, préparez un petit jeu d’essais représentatifs, écrivez des critères observables avant de comparer, puis consignez chaque régression. Six cas bien choisis peuvent déjà éviter le piège du « cela a marché une fois ». Ils ne prouvent pas que le prompt fonctionnera toujours : ils rendent simplement la décision plus sérieuse et reproductible.

La méthode ci-dessous convient à un prompt utilisé régulièrement pour résumer, extraire, classer, reformuler ou préparer un document. Elle ne remplace pas les contrôles humains, juridiques, métier ou de sécurité nécessaires à certains usages.

Une belle réponse isolée ne constitue pas un test

Imaginons que vous modifiiez un prompt pour obtenir des comptes rendus plus courts. Vous l’essayez sur les notes d’une réunion claire : le résultat est excellent. Vous remplacez donc l’ancienne version.

Le lendemain, les notes ne précisent pas le responsable d’une action. Le nouveau prompt, plus directif, invente un nom au lieu de signaler l’information manquante. La forme s’est améliorée, mais la fiabilité a reculé.

C’est une régression : une modification apporte un gain sur un point tout en détériorant un comportement qui comptait déjà. Le problème n’est pas réservé aux équipes techniques. Il apparaît dès qu’un même prompt sert à plusieurs personnes, plusieurs formats d’entrée ou plusieurs situations.

La documentation officielle d’OpenAI présente les évaluations comme un moyen de vérifier que les sorties respectent des critères de contenu et de style définis à l’avance, notamment lors d’un changement de modèle. Elle résume le cycle en trois étapes : décrire la tâche, exécuter des entrées de test, puis analyser et améliorer. Cette logique peut être appliquée manuellement dans un tableau, sans développer un système automatisé : guide officiel sur les évaluations.

Étape 1 — figer ce que vous êtes réellement en train de comparer

Avant le premier essai, nommez les deux versions : par exemple CR-reunion-v3 et CR-reunion-v4. Ne remplacez pas le texte de la v3 dans le même document : vous perdriez le point de comparaison.

Dans votre fiche de test, notez aussi :

• l’outil et, lorsque l’information est disponible, le modèle utilisé ;
• les réglages qui peuvent modifier la réponse ;
• la date du test ;
• les documents ou données fournis ;
• le format de sortie attendu ;
• la personne qui décide entre les deux versions.

Pourquoi ces précautions ? Si le prompt, le modèle et les données changent en même temps, vous ne savez plus ce qui explique l’écart. Dans un outil grand public, certains paramètres peuvent rester invisibles ou évoluer. Il faut alors écrire honnêtement « environnement non maîtrisé » et refaire les essais importants, pas inventer une stabilité.

Étape 2 — construire un mini-jeu de six cas

Ne choisissez pas six exemples presque identiques. Faites varier ce qui peut casser.

Utilisez des données fictives ou correctement anonymisées lorsque les informations réelles sont confidentielles. Retirer un nom ne suffit pas toujours : une combinaison de poste, date, lieu et événement peut encore identifier une personne. En cas de doute, créez un cas synthétique qui conserve la difficulté sans reprendre le dossier réel.

Le jeu doit rester assez petit pour être rejoué après chaque modification. Ajoutez ensuite les vrais cas d’échec, une fois nettoyés de toute donnée personnelle ou sensible. Le guide OpenAI sur la boucle d’évaluation insiste précisément sur l’intérêt d’analyser les erreurs, de les mesurer et d’itérer au lieu de retoucher un prompt à l’intuition.

Étape 3 — écrire les critères avant de regarder les réponses

Un critère doit permettre de dire « oui », « non » ou « à revoir » sans se réfugier dans « je préfère ce style ».

Pour notre compte rendu, les critères pourraient être :

1. aucune décision absente des notes n’est ajoutée ;
2. chaque action conserve son responsable et son échéance lorsqu’ils sont présents ;
3. toute information manquante est marquée « à confirmer » ;
4. les décisions sont séparées des idées et des questions ouvertes ;
5. la sortie respecte les quatre rubriques demandées ;
6. le texte tient sous 180 mots, sauf si cette limite supprimerait une décision.

Le sixième critère montre un conflit possible. La brièveté est souhaitée, mais elle passe après l’exactitude. Écrivez donc aussi l’ordre de priorité : fidélité, informations d’action, structure, puis concision.

Évitez une note globale de 8/10 sans définition. Elle donne une impression de précision, mais masque le motif de l’échec. Une ligne par critère est plus lente au départ et beaucoup plus utile au moment de décider.

La fiche « prompt, cas, critère, décision » à copier

Identité du test

Tableau de comparaison

Sous le tableau, ajoutez trois lignes :

• gain recherché : ce que la nouvelle version devait améliorer ;
• régression bloquante : le défaut qui impose de revenir en arrière ;
• prochaine action : adopter, corriger, séparer en deux prompts ou demander un contrôle métier.

Étape 4 — comparer sans favoriser la version candidate

Exécutez l’ancienne et la nouvelle version sur les mêmes cas. Dans la mesure du possible, masquez leur nom pendant la relecture : « réponse A » et « réponse B » limitent l’envie de récompenser le prompt dans lequel vous venez d’investir du temps.

Pour une tâche déterministe — extraire une référence, produire un tableau avec des colonnes imposées — un passage peut suffire à détecter une erreur nette. Pour une tâche plus ouverte, répétez les cas les plus importants. Une variation entre deux exécutions n’est pas forcément une régression du prompt ; elle peut venir du comportement probabiliste du modèle ou d’un changement d’environnement.

Ne mélangez pas non plus trois comparaisons :

• nouveau prompt avec ancien modèle ;
• ancien prompt avec nouveau modèle ;
• nouveau prompt avec nouveau modèle.

Si le modèle change, gardez au moins une cellule qui isole ce changement. Sinon, notez la limite et évitez d’attribuer le résultat au seul prompt.

Exemple fictif — raccourcir un compte rendu

Cet exemple est une simulation pédagogique, sans données de client.

Modification candidate : la v4 ajoute « sois bref, ne pose aucune question et complète chaque action avec un responsable ».

Cas incomplet :

Notes : Le devis doit être relu avant vendredi. Samira enverra la nouvelle grille tarifaire. La personne chargée de la relecture n’a pas été désignée.

Sortie v3 :

Action 1 — Relire le devis avant vendredi — Responsable : à confirmer.
Action 2 — Envoyer la nouvelle grille tarifaire — Responsable : Samira — Échéance : à confirmer.

Sortie v4 simulée :

Samira relit le devis avant vendredi et envoie la nouvelle grille tarifaire.

La v4 est plus courte, mais elle attribue à Samira une responsabilité absente des notes. Elle échoue au critère prioritaire d’exactitude. La bonne décision n’est pas forcément d’abandonner toute la v4 : remplacez l’instruction « complète chaque action » par « n’invente aucun champ ; écris “à confirmer” si l’information manque », puis rejouez les six cas.

Exercice corrigé — adopter, corriger ou séparer ?

Une équipe teste un prompt de réponse aux demandes internes.

• Sur quatre cas simples, la version B est plus claire et respecte le format.
• Sur un cas ambigu, elle choisit une procédure alors que deux sont possibles.
• Sur un cas risqué, elle demande une validation humaine comme prévu.
• Le critère prioritaire est : « ne jamais choisir une procédure lorsque les informations sont insuffisantes ».

Que décider ?

Correction : ne pas adopter la version B en l’état, même si elle gagne quatre cas sur six. Le cas ambigu viole un critère bloquant. Corrigez l’instruction pour exiger les informations manquantes, puis rejouez toute la suite. Si les demandes ambiguës obéissent à une logique très différente, séparez éventuellement le flux : un prompt de qualification d’abord, puis le prompt de réponse. Cette séparation est une option à tester, pas une garantie de fiabilité.

Étape 5 — versionner la décision, pas seulement le texte

Conservez avec chaque version :

• la raison du changement ;
• les cas joués ;
• les critères réussis et échoués ;
• les régressions acceptées, refusées ou encore inconnues ;
• le nom du décideur et la date ;
• la condition de retour à la version précédente.

Cette trace évite de redécouvrir la même erreur trois semaines plus tard. Elle aide aussi un collègue à comprendre pourquoi une formulation apparemment lourde existe : elle protège peut-être un cas limite déjà rencontré.

Une régression peut parfois être acceptée. Par exemple, une version plus longue peut être retenue si elle réduit les omissions sur une tâche réglementée. L’arbitrage doit être explicite et validé par la personne compétente. Un score moyen ne doit jamais annuler un défaut critique.

Quand le petit tableau ne suffit plus

Passez à une démarche plus structurée lorsque le prompt :

• alimente une automatisation ou un grand volume de dossiers ;
• influence une décision financière, juridique, médicale, RH ou de sécurité ;
• manipule des données personnelles ou confidentielles ;
• est utilisé par plusieurs services avec des attentes différentes ;
• doit être comparé sur des dizaines de scénarios et plusieurs modèles.

Il faut alors définir les responsabilités, la protection des données, les validations métier, le suivi des incidents et, si nécessaire, une évaluation automatisée. Un outil d’évaluation n’autorise pas à lui seul l’usage des données et ne transforme pas une sortie plausible en vérité.

Choisir une formation adaptée à ce besoin

Le sujet n’est plus simplement « apprendre à écrire de meilleurs prompts » si vous savez déjà obtenir une réponse correcte. Votre besoin porte plutôt sur la spécification d’une tâche, la construction de cas normaux et limites, les critères d’acceptation, la comparaison et le versionnage.

La formation StraFormation Prompting avancé : concevoir, tester et versionner des consignes professionnelles correspond à ce niveau de décision. Sa page précise qu’elle vise des utilisateurs déjà familiers des outils d’IA, qu’elle ne constitue pas une simple bibliothèque de prompts et qu’elle travaille les cas normaux, limites et adversariaux, l’évaluation et le versionnage. Le présentiel à Strasbourg, le distanciel, l’individuel ou le collectif sont des modalités à étudier ; le programme exact, les comptes, la durée, les exercices et les conditions doivent être confirmés dans la proposition.

Pour une orientation utile, préparez votre fiche et indiquez : la tâche réelle, le type de données, le nombre d’utilisateurs, la version actuelle, un cas qui échoue, les critères bloquants, les contraintes de confidentialité et l’échéance. Si vous débutez encore avec l’IA, commencez plutôt par le parcours général IA et automatisation, qui part de la tâche, des données, du contrôle et de la décision.

Aucune formation, méthode ou suite de tests ne garantit l’exactitude, la conformité, un gain de temps ou un retour sur investissement. Ces effets doivent être mesurés sur le travail réel, avec les contrôles appropriés.

Le réflexe à conserver

Avant de modifier un prompt partagé, posez deux questions : quel défaut précis voulons-nous corriger, et quels comportements déjà utiles refusons-nous de perdre ?

Écrivez les cas et les critères avant de regarder la nouvelle réponse. Une amélioration qui ne survit pas à ce petit test n’est pas encore une version à déployer.