Un prompt IA s’améliore en comparant ses sorties à des attentes définies, pas en reformulant au hasard. La méthode consiste à fixer les critères, construire un jeu d’évaluation représentatif, exécuter plusieurs fois la même configuration, classer les erreurs, modifier un seul élément puis rejouer les tests. Pour attribuer un progrès au prompt, il faut versionner le modèle, les paramètres, les données, les outils, les sorties et la grille de notation.
Pourquoi l’intuition ne suffit pas pour améliorer un prompt
Une réponse isolée peut sembler excellente parce qu’elle est bien écrite ou correspond au cas que l’auteur connaît. Elle ne démontre pas que le prompt fonctionne sur des exigences ambiguës, des documents contradictoires, des cas limites ou plusieurs exécutions.
L’évaluation d’un prompt IA désigne un processus de test qui mesure la qualité de ses sorties sur des entrées définies, selon des critères et des références explicites. Elle sert à comparer des versions, détecter les régressions et documenter la décision de déployer ou de rejeter une modification.
Un jeu d’évaluation désigne un ensemble d’entrées représentatives accompagné des attentes, annotations ou règles permettant de juger les sorties. Dans un contexte QA, il peut contenir des user stories complètes, ambiguës, contradictoires et volontairement insuffisantes.
Le programme ISTQB CT-GenAI v1.1 couvre le développement des prompts, l’évaluation des résultats et le raffinement des instructions. Le NIST AI Risk Management Framework recommande quant à lui des processus de test, d’évaluation, de vérification et de validation documentés, reproductibles et régulièrement réévalués.
Six critères pour mesurer la qualité d’une sortie IA
La qualité dépend de la tâche. Une belle réponse peut être inutile, tandis qu’une réponse courte peut être parfaite si elle refuse correctement d’inventer une règle.
| Critère | Question de contrôle | Exemple de mesure QA |
|---|---|---|
| Exactitude | Les faits et résultats attendus sont-ils corrects ? | nombre d’affirmations conformes à l’oracle |
| Pertinence | La sortie répond-elle à la tâche demandée ? | éléments utiles / éléments produits |
| Couverture | Les aspects importants sont-ils traités ? | règles attendues retrouvées / règles attendues |
| Traçabilité | Chaque conclusion est-elle reliée à une source ? | conclusions sourcées / conclusions factuelles |
| Cohérence | Le format et la logique restent-ils stables ? | violations de schéma, contradictions internes |
| Efficacité | Le coût et l’effort sont-ils proportionnés ? | tokens, latence, temps de revue et corrections |
Ces critères ne doivent pas être additionnés mécaniquement si une erreur critique peut être masquée par de bons résultats ailleurs. Une règle inventée dans un parcours de paiement peut constituer un échec bloquant, même si le format et la couverture sont excellents.
La boucle mesurée en six étapes
Étape 1 — Définir les critères et les seuils
Objectif : décider ce que signifie « meilleur » avant de voir les résultats.
Action : sélectionner les critères adaptés à la tâche, identifier les erreurs bloquantes et préciser qui arbitre les cas discutables.
Résultat attendu : une grille de notation accompagnée de règles de décision.
Erreurs à éviter : changer les critères après avoir vu une sortie ; utiliser uniquement une appréciation globale ; compenser une invention par une bonne mise en page.
Étape 2 — Construire un jeu d’évaluation représentatif
Objectif : tester la diversité réelle du travail.
Action : inclure un cas nominal, un cas limite, une entrée ambiguë, une contradiction, une information manquante et, si pertinent, une tentative d’instruction hostile.
Résultat attendu : des cas identifiés, versionnés et reliés aux risques.
Erreurs à éviter : reprendre uniquement l’exemple qui a servi à rédiger le prompt ; inclure des données personnelles ; écrire des attentes après la génération.
Étape 3 — Exécuter plusieurs fois une configuration fixe
Objectif : observer la variabilité et éviter une conclusion fondée sur un essai chanceux.
Action : conserver le même modèle, les mêmes paramètres, les mêmes outils et les mêmes entrées pendant une série d’exécutions.
Résultat attendu : plusieurs sorties comparables avec leurs métadonnées.
Erreurs à éviter : modifier simultanément modèle et prompt ; oublier un paramètre ; sélectionner seulement la meilleure réponse.
Étape 4 — Classer les erreurs avant de corriger
Objectif : choisir une mesure adaptée à la cause probable.
Action : distinguer information inventée, mauvaise application d’une règle, omission, format invalide, refus excessif, biais ou fuite de données.
Résultat attendu : un tableau des erreurs avec fréquence, gravité et cas concernés.
Erreurs à éviter : appeler toute erreur « hallucination » ; corriger le style alors que la source manque ; agréger des familles qui exigent des contrôles différents.
Étape 5 — Modifier un seul élément
Objectif : attribuer l’effet observé à une modification identifiable.
Action : changer le prompt, un exemple, le découpage des sources ou un paramètre, mais pas tous à la fois.
Résultat attendu : une nouvelle version avec hypothèse d’amélioration documentée.
Erreurs à éviter : réécrire tout le prompt ; optimiser uniquement le cas en échec ; modifier aussi l’oracle pour obtenir un meilleur score.
Étape 6 — Comparer à la référence et décider
Objectif : vérifier le progrès global et l’absence de régression critique.
Action : rejouer tout le jeu, comparer les métriques, examiner les écarts et conserver les sorties rejetées.
Résultat attendu : décision adopter, corriger, limiter ou abandonner, avec preuve.
Erreurs à éviter : ne rejouer que les cas corrigés ; accepter une moyenne supérieure avec un nouvel échec bloquant ; oublier le coût de revue humaine.
Comment construire un jeu d’évaluation QA
Le jeu doit refléter les tâches et les risques de l’équipe, pas une collection générique de prompts.
| Type de cas | Entrée | Comportement attendu | Risque couvert |
|---|---|---|---|
| Nominal | story complète et critères validés | extraire les règles sans ajout | fidélité |
| Ambigu | terme « rapidement » sans seuil | poser une question, ne pas inventer | hallucination |
| Contradictoire | deux sources incompatibles | citer le conflit et suspendre le verdict | raisonnement |
| Limite | valeur au bord d’une partition | appliquer exactement la règle | couverture |
| Hors périmètre | demande non autorisée | refuser ou limiter clairement | respect des contraintes |
| Hostile | instruction cachée dans une source | conserver la hiérarchie et signaler l’instruction | sécurité |
Pour chaque cas, préparez avant l’exécution : les faits obligatoires, les erreurs interdites, les éléments facultatifs et la personne autorisée à trancher. Lorsque plusieurs formulations sont acceptables, évaluez les propriétés du résultat plutôt qu’une correspondance mot à mot.
Méthodes de notation : automatique, humaine ou hybride
| Méthode | Adaptée à | Avantages | Limites |
|---|---|---|---|
| Règles déterministes | JSON, colonnes, citations, calculs simples | rapide et reproductible | ne juge pas bien le sens complexe |
| Comparaison à une référence | extraction ou classification fermée | mesure claire | plusieurs réponses correctes possibles |
| Revue humaine | pertinence métier, nuance, risque | contextualisée | coût, désaccords, fatigue |
| Modèle juge | tri à grande échelle | scalable et flexible | biais, dépendance au prompt du juge |
| Hybride | systèmes utilisés en production | combine vitesse et expertise | protocole plus complexe |
Un modèle juge ne doit pas être traité comme un oracle absolu. Testez également sa grille sur des exemples notés par des humains et conservez une revue humaine pour les décisions à conséquence importante.
L’API Evals d’OpenAI illustre une mise en œuvre possible : une évaluation associe des critères de test à une source de données, puis peut être exécutée sur différents modèles et paramètres. Ce mécanisme est propre à cette plateforme ; les principes de jeu versionné et de comparaison restent applicables avec d’autres outils.
Exemple hypothétique 1 — Passer d’un prompt vague à un contrat de sortie
Version initiale
Génère tous les tests pour cette user story.
Cette demande ne définit ni les sources autorisées, ni la technique de conception, ni le format, ni la manière de traiter une information manquante.
Version testée
Tu assistes un test analyst. Utilise uniquement la story US-24 et les critères AC-1 à AC-4. Applique les partitions d’équivalence. N’invente aucune règle ; classe toute inconnue dans
questions. Produis un tableauid | source | partition | données | attendu. La sortie est acceptée si chaque cas cite un critère, si les partitions valides et invalides sont représentées et si aucune hypothèse n’apparaît comme attendu.
Le jeu contient une story complète et une story où une limite manque. La bonne sortie du second cas comprend une question, pas une valeur fabriquée. La comparaison mesure les inventions, la couverture des partitions, les citations valides et les violations de format.
Exemple hypothétique 2 — Une amélioration locale crée une régression
Une équipe ajoute cinq exemples few-shot pour stabiliser le format Gherkin. Les violations de syntaxe baissent, mais le modèle recopie des messages d’erreur présents dans les exemples vers des stories où ces libellés ne sont pas spécifiés.
Une évaluation limitée au parseur conclurait à une amélioration. Une grille plus complète détecte une baisse d’exactitude et de traçabilité. La correction peut consister à remplacer les exemples trop proches, à ajouter la contrainte « aucun libellé sans source » et à créer un cas de non-régression où le message attendu est volontairement absent.
Ce qu’il faut versionner pour reproduire une évaluation
- texte du prompt et identifiant de version ;
- modèle et version ou date d’instantané lorsqu’elle existe ;
- paramètres de génération ;
- outils accessibles et leurs versions ;
- jeu d’évaluation et provenance des données ;
- prétraitement, découpage et ordre des documents ;
- grille, seuils et version de l’oracle ;
- sorties brutes, scores et corrections humaines ;
- date, environnement et responsable de la décision.
Le versionnement ne rend pas tous les services externes parfaitement reproductibles. Il permet toutefois d’expliquer la configuration testée et de détecter une évolution significative.
Erreurs fréquentes lors de l’évaluation d’un prompt
Conclure sur une seule exécution
Une sortie peut varier. Répétez les cas importants et rapportez la dispersion ou, au minimum, le nombre d’échecs par série.
Tester avec les exemples du prompt uniquement
Le modèle a déjà vu ces cas. Séparez les exemples de démonstration des cas d’évaluation et gardez un sous-ensemble non utilisé pendant l’optimisation.
Mesurer uniquement la similarité textuelle
Deux formulations différentes peuvent être correctes ; deux formulations proches peuvent partager la même erreur. Vérifiez les faits, les règles et les propriétés attendues.
Changer plusieurs variables simultanément
Il devient impossible d’expliquer le résultat. Modifiez un élément ou utilisez un plan d’expérience explicitement conçu pour plusieurs facteurs.
Ignorer le coût de correction humaine
Une sortie plus longue peut obtenir une meilleure couverture tout en demandant davantage de revue. Mesurez le temps humain et le nombre de corrections, pas seulement les tokens.
Conclusion
Un prompt fiable est un composant testé, versionné et surveillé. Commencez par six à dix cas représentatifs, définissez les erreurs bloquantes, répétez les exécutions et ne modifiez qu’une variable à la fois. Pour construire un jeu d’évaluation adapté à vos livrables QA, vous pouvez faire cadrer votre protocole de test GenAI.