Évaluer la qualité d'un prompt

Pourquoi évaluer un prompt comme un livrable

Un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire qui fonctionne bien lors d'un test manuel n'est pas un prompt fiable. La différence tient à une question simple : a-t-il été évalué sur un échantillon représentatif, avec des critères explicites, avant d'être mis entre les mains d'utilisateurs ou branché sur un système en production ? Dans l'immense majorité des projets, la réponse est non — le prompt a été ajusté à l'œil, sur trois ou quatre exemples, jusqu'à obtenir une sortie qui « a l'air bien ».

Cette approche fonctionne pour un usage ponctuel. Elle échoue dès que le prompt est réutilisé à volume, exposé à des entrées variées, ou intégré dans un flux où une sortie incorrecte a un coût réel — un e-mail mal classé, une réponse client erronée, une extraction de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire qui casse un pipeline en aval. Ce chapitre montre comment vérifier qu'un prompt tient réellement la route, avec la même rigueur qu'on appliquerait à n'importe quel livrable technique.

Évaluer un prompt, c'est le traiter comme un composant logiciel : il a des spécifications, des cas de test, des critères de réussite mesurables, et un processus de validation avant déploiement. Ignorer cette étape ne fait pas disparaître les défaillances, elle les retarde jusqu'au moment le moins pratique — après la mise en production, devant un vrai utilisateur.

Publier un prompt en production sans golden set ni rubrique revient à livrer du code sans tests unitaires. Le fait que ça « marche » sur les premiers essais ne garantit rien sur la distribution réelle des entrées que le prompt rencontrera.

Les limites de l'évaluation informelle

Trois biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire reviennent systématiquement quand l'évaluation reste informelle, faite au fil de l'eau pendant la rédaction du prompt.

Le premier est le biais de confirmation : on teste le prompt avec les exemples qui viennent naturellement à l'esprit, souvent ceux pour lesquels on a déjà une idée de la bonne réponse. Les cas ambigus, contradictoires ou en bordure de périmètre sont rarement testés spontanément — ce sont pourtant eux qui révèlent les failles les plus coûteuses en production.

Le second est l'instabilité du jugement humain. Une même personne, évaluant la même sortie à deux moments différents, ne donne pas toujours le même verdict. La fatigue, l'ordre de présentation des exemples, l'humeur du jour influencent le jugement bien plus qu'on ne l'admet en général.

Le troisième est l'absence de seuil de décision. Sans critère écrit à l'avance, la question « ce prompt est-il prêt ? » se résout par intuition, ce qui empêche toute comparaison objective entre deux versions d'un même prompt et rend chaque décision de déploiement difficile à justifier a posteriori.

Un prompt ajusté itérativement sur les mêmes trois ou quatre exemples finit presque toujours par se sur-adapter à leurs particularités. Le golden set de validation doit contenir des cas jamais vus pendant la phase de rédaction, sous peine de mesurer une performance illusoire.

Construire un golden set

Un golden set est un ensemble de cas de test représentatifs, associés à une réponse attendue ou à des critères de réussite explicites. C'est la brique fondatrice de toute évaluation sérieuse : sans lui, aucune comparaison entre versions de prompt n'est reproductible, et chaque itération repart de zéro.

Composition

Un golden set utile mélange plusieurs catégories de cas :

• Cas nominaux — les entrées typiques, celles que le prompt rencontrera le plus souvent en usage réel.
• Cas limites — entrées courtes, longues, incomplètes, dans une langue ou un format inhabituel.
• Cas pièges — formulations ambiguës, instructions contradictoires dans l'entrée elle-même, tentatives d'injection de consignes.
• Cas négatifs — situations où la bonne réponse est un refus, une demande de clarification, ou une réponse vide.

Un golden set de 30 à 50 cas suffit généralement pour un prompt de complexité moyenne en phase de démarrage ; les projets à fort volume ou fort enjeu montent régulièrement à 150-300 cas, organisés par sous-catégorie métier.

Sources des cas

Les meilleurs cas de test ne s'inventent pas, ils se collectent. Trois sources à privilégier :

1. Les journaux de production (ou d'un prototype antérieur) — ils révèlent la distribution réelle des entrées, souvent plus large et plus chaotique que ce qu'on imagine en phase de conception.
2. Les remontées du support ou des équipes métier — chaque signalement d'erreur devient un cas de golden set une fois corrigé, ce qui transforme un incident en actif durable.
3. La génération contrôlée — demander au modèle de produire des variantes d'un cas type reste utile pour couvrir des combinaisons peu fréquentes, à condition de relire chaque cas généré avant de l'intégrer.

Sur 60 cas : 30 tickets réels anonymisés couvrant les six catégories métier, 10 tickets multi-catégories pour vérifier la gestion de l'ambiguïté, 10 tickets hors périmètre (spam, doublons, tests internes), et 10 tickets rédigés dans une langue autre que le français. Chaque cas porte une étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire de référence validée par un responsable support, pas par la personne qui a écrit le prompt — pour éviter tout biais de complaisance.

Maintenance du golden set

Un golden set n'est jamais figé. Chaque défaillance détectée en production — par un utilisateur, par un contrôle qualité, par un client — doit être ajoutée comme nouveau cas après correction du prompt. C'est ce mécanisme qui transforme le golden set en mémoire cumulative des erreurs passées, et qui évite qu'une régression déjà corrigée une fois ne revienne silencieusement avec la version suivante du prompt, un phénomène fréquent dès qu'un prompt est modifié sans filet de sécurité.

Rubriques d'évaluation

Une rubrique est une grille de critères explicites qui transforme un jugement qualitatif (« la réponse est bonne ») en une évaluation décomposée, documentée et reproductible d'un évaluateur à l'autre.

Critères binaires et critères gradués

Deux familles de critères coexistent dans la plupart des rubriques :

• Critères binaires (pass/fail) — le format de sortie est-il valide ? La longueur respecte-t-elle la contrainte ? Le ton est-il conforme à la charte ? Ces critères sont vérifiables automatiquement dans la majorité des cas.
• Critères gradués (échelle, souvent de 1 à 5) — la pertinence de la réponse, sa complétude, sa fluidité rédactionnelle. Ces critères demandent un jugement, humain ou délégué à un modèle évaluateur.

Exemple de grille

Les critères « bloquants » méritent une mention particulière : un échec sur ces critères invalide la sortie indépendamment du score obtenu sur les autres, ce qui évite qu'une réponse bien écrite mais structurellement inutilisable (mauvais format, information hors périmètre) ne soit acceptée malgré tout parce qu'un score moyen la rend flatteuse.

Rédiger la grille de critères avant de générer la moindre réponse du prompt à évaluer réduit fortement le risque d'ajuster les critères a posteriori pour justifier un résultat déjà observé — un biais discret mais très fréquent dès qu'on connaît la sortie avant d'écrire les critères.

Méthodes de scoring

Évaluation humaine

L'évaluation humaine reste la référence pour les critères de jugement fin — ton, nuance, pertinence contextuelle. Elle a un coût réel : temps, disponibilité des relecteurs qualifiés, variabilité inter-évaluateurs. Deux pratiques limitent ce coût sans sacrifier la fiabilité : faire évaluer chaque cas par deux personnes indépendantes et mesurer leur taux d'accord — un désaccord fréquent signale une rubrique mal définie, pas seulement des évaluateurs peu fiables — et faire tourner un même petit sous-ensemble de cas de référence à chaque campagne pour détecter une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire du jugement dans le temps.

LLM-as-judge

Utiliser un modèle de langage pour noter les sorties d'un autre prompt, ou du même prompt à plus grande échelle, est devenu une pratique courante, en particulier pour les rubriques graduées appliquées à fort volume. L'intérêt est la vitesse et le coût ; la limite est que le juge hérite des mêmes biais structurels que le système jugé — il peut préférer les réponses longues, bien formatées, ou rédigées dans un style qu'il reconnaît comme « académique », indépendamment de leur exactitude factuelle.

Un LLM-juge devient exploitable à condition de respecter trois règles : lui fournir la même rubrique explicite que celle utilisée pour l'évaluation humaine, pas une consigne vague du type « note cette réponse » ; lui demander une justification écrite avant la note, ce qui améliore la cohérence du jugement ; et calibrer régulièrement son verdict contre un échantillon noté par des humains.

Un modèle-juge de la même famille que le modèle évalué tend à sous-détecter certains types d'erreurs partagées, notamment les approximations factuelles plausibles. Un audit humain périodique reste nécessaire, même lorsque le juge automatique est bien calibré sur l'essentiel des cas.

Métriques automatiques

Certains critères se mesurent sans jugement subjectif : validité du format (JSON, XML, schéma), champs obligatoires présents, longueur, absence de motifs interdits, temps de réponse, taux d'échec de parsing. Ces métriques automatiques doivent constituer la première couche de tout pipeline d'évaluation : rapides, reproductibles, elles filtrent les échecs évidents avant de solliciter un jugement plus coûteux, humain ou délégué à un LLM-juge.

Tests A/B de prompts

Comparer deux versions d'un prompt — formulation différente, modèle différent, structure de sortie différente — demande un protocole aussi rigoureux qu'un test A/B produit classique. L'intuition selon laquelle « cette version semble mieux répondre » ne suffit pas à trancher.

Protocole

1. Isoler une seule variable. Reformuler l'instruction et changer de modèle en même temps interdit d'attribuer un écart de performance à l'une ou l'autre cause.
2. Faire tourner les deux versions sur le même golden set, dans les mêmes conditions : même température, mêmes exemples few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire si le prompt en utilise, même ordre de présentation des cas.
3. Comparer sur la rubrique complète, pas seulement sur un score global agrégé — une version peut gagner en complétude et perdre en concision, ce qui change la décision selon le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire métier visé.
4. Vérifier la significativité avant de conclure, en particulier lorsque l'échantillon de test reste modeste.

Pièges statistiques

Sur un golden set de 20 cas, un écart de deux points en faveur d'une version ne constitue pas une preuve. La variance naturelle de génération — température non nulle, légère instabilité du modèle d'une exécution à l'autre — peut à elle seule produire un tel écart. Deux garde-fous limitent ce risque : répéter chaque cas trois à cinq fois par version et comparer les moyennes plutôt qu'une exécution unique, et élargir le golden set avant de trancher entre deux versions dont les scores restent proches.

En dessous d'une trentaine de cas, un écart de quelques points entre deux prompts est le plus souvent du bruit statistique, pas un signal exploitable pour décider d'un déploiement en production.

Critères métier et alignement business

Un prompt techniquement correct peut rester un échec métier. La rubrique technique — format, fidélité, complétude — doit toujours être complétée par des critères propres au contexte d'usage : un prompt de génération de réponse client peut être factuellement exact tout en violant une politique de communication de l'entreprise, en proposant un geste commercial non autorisé, ou en adoptant un ton en décalage avec la marque perçue par les clients.

Impliquer les parties prenantes métier — pas seulement l'équipe technique — dans la définition de la rubrique et dans la relecture d'un échantillon de sorties est ce qui distingue un prompt validé « en interne technique » d'un prompt réellement prêt pour la production. Cette implication doit intervenir tôt, au moment de la rédaction de la rubrique, plutôt qu'en fin de projet : un critère métier découvert après coup oblige souvent à retravailler le prompt en profondeur, alors qu'anticipé, il se traduit simplement par une ligne de rubrique supplémentaire — faire relire un échantillon de sorties par un responsable produit, un juriste si le domaine l'exige, ou un responsable de la relation client, selon la nature du risque associé.

Boucle d'amélioration continue

L'évaluation ne s'arrête pas à la mise en production. Trois mécanismes maintiennent la qualité dans la durée, une fois le prompt déployé et utilisé à volume.

• Échantillonnage continu — évaluer régulièrement un échantillon aléatoire des sorties réelles, pas seulement les cas du golden set, pour détecter une dérive liée à l'évolution des entrées ou à une mise à jour silencieuse du modèle sous-jacent.
• Boucle de signalement — un canal simple pour que les utilisateurs ou le support remontent une sortie problématique, avec un processus qui transforme systématiquement ce signalement en nouveau cas de golden set plutôt qu'en correction ponctuelle non capitalisée.
• Revue périodique de la rubrique elle-même — les critères de qualité évoluent avec le produit ; une rubrique figée depuis six mois est un signal d'alerte à investiguer, pas une preuve de stabilité.

Checklist avant mise en production

• Le golden set couvre les cas nominaux, limites, pièges et négatifs, avec au moins 30 cas.
• La rubrique distingue critères bloquants et critères gradués, avec des poids explicites documentés.
• Au moins deux évaluateurs indépendants — humains, ou humain associé à un LLM-juge calibré — ont noté un échantillon commun.
• Les critères métier ont été validés par les parties prenantes non techniques concernées.
• Un test A/B a confirmé que la version retenue surpasse la précédente sur un échantillon suffisant, avec répétitions.
• Un mécanisme de signalement et de mise à jour du golden set est en place pour la phase post-déploiement.

Conclusion

Évaluer un prompt n'est pas une formalité qui ralentit le déploiement, c'est ce qui le rend défendable. Un golden set représentatif, une rubrique explicite et un protocole de comparaison rigoureux transforment une impression subjective — « ça a l'air bien » — en décision documentée et reproductible d'une équipe à l'autre. C'est cette rigueur, plus que la sophistication du prompt lui-même, qui distingue un usage professionnel d'un usage exploratoire.