Évaluer un prompt : critères, cas de test et non-régression

Pourquoi « ça a l’air bien » ne suffit pas

La façon la plus répandue d’évaluer un prompt consiste à le lancer, lire la réponse, et se dire qu’elle convient. Cette méthode a un défaut structurel : elle mesure l’impression que produit une sortie, pas la fiabilité du prompt qui l’a produite.

Trois raisons rendent ce jugement peu fiable.

Le même prompt ne donne pas deux fois la même réponse. Sauf à travailler à température nulle, et encore, la variabilité est la règle. Une sortie satisfaisante peut être le meilleur tirage d’une distribution dont la moyenne est médiocre.

Un texte fluide inspire une confiance disproportionnée. C’est le biais le plus coûteux du travail avec les modèles de langage : une réponse mal écrite se fait corriger, une réponse élégante et fausse passe. La qualité rédactionnelle et l’exactitude sont deux dimensions indépendantes, et notre jugement les confond spontanément.

On teste sur le cas facile. Naturellement, on essaie son prompt sur l’exemple auquel on pensait en l’écrivant. C’est précisément celui sur lequel il a le plus de chances de réussir, et le moins de chances de nous apprendre quelque chose.

Des critères observables plutôt qu’une impression

Un critère utile est un critère sur lequel deux personnes différentes rendraient le même verdict. « La réponse est bonne » n’en est pas un. « La réponse cite au moins deux sources » en est un.

Il est commode de séparer les critères en deux familles.

Les critères vérifiables mécaniquement

Ce sont ceux qu’un script peut trancher sans intervention humaine : la sortie est un JSON valide, elle contient les cinq sections demandées, elle ne dépasse pas 300 mots, elle ne mentionne aucun nom propre, elle commence par le mot attendu.

Ces critères paraissent triviaux. Ils rattrapent pourtant l’immense majorité des défaillances réelles en production, parce que ce qui casse une chaîne automatisée, c’est rarement une nuance de style, c’est un format qui dérive.

Les critères de jugement

Ils demandent un lecteur : le ton correspond-il au public visé, le raisonnement tient-il, les affirmations sont-elles étayées, les cas limites sont-ils traités. Pour rester exploitables, ils doivent être formulés en questions fermées.

Comparez « le style est-il adapté ? » et « la réponse évite-t-elle le vouvoiement et les termes techniques non définis ? ». La seconde se vérifie en dix secondes et donne le même résultat quel que soit le relecteur.

Construire un jeu de cas de test

Un jeu de test est une liste d’entrées, écrites avant les modifications du prompt, que l’on rejoue à chaque changement. Il n’a pas besoin d’être grand : dix à vingt cas bien choisis suffisent pour un prompt de travail.

Ce qui compte, c’est la répartition. Un bon jeu mélange quatre familles.

Famille	Rôle	Proportion indicative
Cas nominaux	L’usage courant, celui pour lequel le prompt existe	environ la moitié
Cas limites	Entrée très courte, très longue, ambiguë, dans une autre langue	un quart
Cas dégradés	Information manquante, contradictoire ou hors sujet	un sixième
Cas pièges	Ce qui devrait déclencher un refus ou une demande de précision	le reste

Les cas dégradés sont les plus instructifs et les plus négligés. Un prompt de synthèse documentaire donne rarement des problèmes sur un document bien rédigé ; il en donne beaucoup quand le document ne contient pas l’information demandée. Le bon comportement (le dire) est justement celui qu’un modèle a tendance à ne pas adopter spontanément.

Où trouver ses cas de test

Pas dans l’imagination : dans l’usage réel. Les meilleures sources sont les entrées que vous avez déjà traitées à la main, et surtout les échecs passés. Chaque fois qu’un prompt vous a déçu, l’entrée qui a produit cet échec mérite d’entrer au jeu de test, définitivement.

C’est la règle la plus rentable de tout ce texte : tout défaut constaté devient un cas de test permanent. Le jeu grandit alors avec l’expérience, et il devient impossible de réintroduire un défaut déjà corrigé sans s’en apercevoir.

La non-régression, ou le piège de l’amélioration

Voici la situation la plus commune. Un prompt donne un mauvais résultat sur un cas précis. On ajoute une instruction pour le corriger. Le cas passe. On considère le problème réglé.

Sauf que l’instruction ajoutée agit sur toutes les entrées, pas seulement sur celle qui posait problème. « Sois plus concis » corrige une réponse verbeuse et ampute les réponses qui avaient besoin de développement. « Cite toujours tes sources » améliore la traçabilité et pousse le modèle à inventer des références quand il n’en a pas.

Cette dégradation est invisible si l’on ne teste que le cas qu’on cherchait à corriger. D’où le principe : après chaque modification, rejouer l’ensemble du jeu, pas seulement le cas visé. C’est exactement la logique des tests de non-régression en développement logiciel, et elle s’applique au mot près.

Concrètement, un tableau suffit : une ligne par cas, une colonne par version du prompt, une case verte ou rouge. Le jour où une colonne fait passer un cas au rouge alors qu’il était vert, vous savez que votre amélioration a un coût, et vous décidez en connaissance de cause.

Faire juger par un modèle : intérêt et limites

Quand le jeu de test grandit, la relecture manuelle devient le goulot d’étranglement. L’idée d’utiliser un modèle comme juge est tentante, et parfois pertinente, à condition d’en connaître les faiblesses.

Un juge automatique fonctionne correctement sur des critères binaires et explicites : la réponse contient-elle une conclusion, respecte-t-elle le format, mentionne-t-elle une incertitude. Il fonctionne mal dès qu’on lui demande une note globale sur dix, qui n’aura aucune stabilité d’une exécution à l’autre.

Deux précautions méritent d’être rappelées. Un modèle juge favorablement les textes longs et bien tournés, y compris quand ils sont faux, le même biais que le nôtre, en plus systématique. Et un modèle qui juge sa propre production est complaisant : utiliser un juge différent du générateur, ou au minimum un contexte séparé, réduit sensiblement l’effet.

Le juge automatique est donc un filtre de premier niveau, pas un verdict. Il élimine les sorties manifestement hors critères et concentre le regard humain sur ce qui mérite discussion.

Une méthode en cinq étapes

1. Écrire les critères avant le prompt. Formuler ce qu’une bonne réponse doit contenir clarifie souvent le prompt lui-même, avant même le premier essai.
2. Rassembler dix cas réels, en incluant délibérément des entrées incomplètes ou ambiguës.
3. Exécuter et noter case par case, sans chercher à corriger tout de suite.
4. Modifier une seule chose à la fois. Deux changements simultanés rendent impossible d’attribuer l’amélioration, ou la dégradation.
5. Rejouer l’ensemble et conserver la trace des deux versions.

La quatrième étape est celle qu’on saute le plus volontiers, et c’est celle qui distingue un prompt qu’on améliore d’un prompt qu’on remue.

Ce que cela suppose de votre outillage

Cette méthode a une conséquence pratique : elle ne tient pas si le prompt est retapé à chaque fois dans une fenêtre de conversation. Comparer deux versions suppose qu’elles existent toutes les deux, qu’on puisse revenir à la précédente, et que les entrées de test soient rejouables à l’identique.

Autrement dit, un prompt qu’on évalue sérieusement est un prompt versionné, dont les variables sont déclarées et dont les valeurs d’essai se substituent sans réécrire le texte. C’est exactement ce que permet un constructeur de prompts, et c’est la raison d’être de Promptique : séparer le gabarit de ses valeurs, garder l’historique, et rendre une comparaison possible.

Sans cette séparation, chaque essai efface le précédent, et l’on retombe sur la méthode du début : lancer, lire, se dire que ça a l’air bien.

À retenir

Évaluer un prompt n’est pas une formalité qui suit la rédaction : c’est ce qui transforme une formulation heureuse en méthode reproductible. Écrivez vos critères avant, testez sur les cas qui vous dérangent plutôt que sur ceux qui vous arrangent, ne changez qu’une chose à la fois, et rejouez tout.

Et gardez la règle qui coûte le moins et rapporte le plus : chaque échec constaté entre définitivement au jeu de test.