Comment évaluer la réponse d'une IA : construire son jeu de tests

La scène se répète dans toutes les équipes qui mettent un assistant en service. Quelqu'un modifie une consigne, relance trois questions, trouve que « c'est mieux », et pousse la modification en production. Deux semaines plus tard, une catégorie de demandes qui fonctionnait très bien s'est mise à produire des réponses hors sujet, et personne ne sait quand la bascule a eu lieu. Évaluer un modèle IA à l'œil nu, sur les trois exemples qu'on a en tête, ne dit rien de ce qui se passe sur les deux cents autres cas que vos utilisateurs envoient chaque semaine.

La parade est connue et bon marché : un jeu de tests. Une trentaine de cas de référence, écrits une fois, rejoués à chaque changement. Ce n'est pas un projet de recherche, c'est un tableur et un script. Une équipe motivée le construit en une journée, et le rentabilise à la première régression détectée avant qu'un client la voie.

Cet article décrit la méthode : ce qu'on met dans le jeu de tests, ce qu'on mesure, comment on automatise une partie du jugement avec un autre modèle, et surtout où cette automatisation ment. Il vise une équipe qui exploite un assistant en interne ou un service client assisté, pas un laboratoire qui publie des scores.

Pourquoi évaluer un modèle IA à l'œil nu ne suffit pas

Les classements publiés par les éditeurs mesurent des capacités générales sur des corpus généraux. Ils vous disent qu'un modèle raisonne mieux qu'un autre en moyenne. Ils ne vous disent rien de votre cas : votre vocabulaire métier, vos documents, vos formats de sortie attendus, vos utilisateurs qui écrivent en trois mots sans ponctuation. Nous avons détaillé ailleurs comment lire un benchmark de modèle IA sans se faire piéger par la marge d'erreur ; retenez surtout qu'un écart de deux points sur un classement public ne prédit pas l'écart sur vos tâches.

Le deuxième problème est la variabilité. Un même modèle, sur un même prompt, ne renvoie pas exactement la même chose deux fois. Sur trois essais manuels, vous mesurez autant le hasard que la qualité. Un jeu de trente cas rejoués donne un signal statistique minimal : si vous passez de 24 à 28 réponses correctes, l'amélioration est probablement réelle ; de 24 à 25, elle ne l'est pas.

Le troisième problème est la mémoire. Sans trace écrite, personne ne sait ce que le système savait faire il y a trois mois. Le jeu de tests est le seul document qui répond à la question « est-ce que ça a déjà marché ? ».

Construire son jeu de tests : trente cas, pas trois mille

La tentation est de viser gros. Elle est mauvaise : un jeu de mille cas ne sera jamais relu, jamais mis à jour, et son score global masquera les catégories qui se dégradent. Trente cas bien répartis valent mieux, à condition de les choisir.

La composition du jeu

Répartissez vos cas en quatre familles, dans ces proportions approximatives :

• Le cœur de métier (environ la moitié) : les demandes les plus fréquentes, telles qu'elles arrivent réellement. Prenez-les dans vos journaux d'usage, pas dans votre imagination. Copiez les fautes de frappe et les tournures maladroites.
• Les cas limites (un quart) : la question posée à moitié, la demande qui porte sur deux sujets, le message qui contient une donnée contradictoire.
• Les refus attendus (un cinquième) : ce à quoi le système ne doit pas répondre. Une question hors périmètre, une demande de conseil juridique ou médical, une tentative de faire dire au modèle ce qu'il ne sait pas.
• Les pièges connus : les trois ou quatre cas qui ont déjà provoqué un incident. Ils entrent dans le jeu le jour de l'incident et n'en sortent jamais.

Ce qu'on écrit en face de chaque cas

Pour chaque entrée, notez l'attendu sous une forme vérifiable. Pas « une bonne réponse », mais des critères qu'un tiers peut cocher :

1. Les éléments obligatoires : les faits, chiffres ou références qui doivent apparaître.
2. Les éléments interdits : ce qui ne doit jamais figurer (un tarif inventé, un engagement de délai, un nom de concurrent).
3. Le format attendu : longueur, présence d'une citation de source, structure JSON si la réponse est consommée par un programme.
4. Le comportement d'échec acceptable : ce que le système doit répondre quand il ne sait pas.

Ce dernier point est celui qu'on oublie, et c'est le plus rentable. Un système qui dit « je n'ai pas cette information » est infiniment moins coûteux qu'un système qui invente. C'est aussi le meilleur levier pour limiter les hallucinations d'une IA générative.

Choisir ce que l'on mesure

Un score unique ne sert à rien. Mesurez trois à cinq critères séparés, chacun noté de façon binaire ou sur trois niveaux. Le tableau ci-dessous donne une grille de départ, à adapter à votre usage.

Notez que trois critères sur cinq se testent sans aucun modèle, avec une simple vérification de chaîne de caractères ou de schéma. Commencez par ceux-là : ils sont gratuits, déterministes et attrapent une bonne partie des régressions grossières.

L'évaluation automatique par un autre modèle, et ses angles morts

Pour les critères qui demandent un jugement, la pratique courante consiste à faire noter la réponse par un second modèle, à qui l'on donne la question, la réponse produite et la réponse attendue. C'est rapide et peu coûteux : trente cas notés sur cinq critères représentent quelques centaines de milliers de tokens, soit une dépense de l'ordre de quelques dizaines de centimes par campagne.

Cette technique a des angles morts documentés, qu'il faut connaître avant de lui faire confiance :

• Le biais de longueur : à contenu égal, une réponse longue et bien structurée est notée plus haut qu'une réponse courte et exacte.
• Le biais de position : quand on compare deux réponses, celle présentée en premier est favorisée. La parade est de rejouer la comparaison dans l'ordre inverse et de ne retenir que les verdicts stables.
• La complaisance envers soi-même : un modèle a tendance à mieux noter les textes produits par un modèle de sa propre famille. Si vous arbitrez entre deux fournisseurs, prenez un juge d'une troisième famille.
• L'incapacité à détecter ce qui manque : le juge évalue ce qu'il lit. Il repère mal l'information absente, sauf si vous la lui listez explicitement dans la consigne.

La règle de sécurité est simple : calibrez le juge. Faites noter vingt cas par le modèle et par un humain, mesurez le taux d'accord. En dessous de 80 % d'accord, la notation automatique ne vaut pas mieux qu'un tirage au sort et vous devez soit reformuler la consigne du juge, soit revenir au jugement humain sur ce critère. La consigne donnée au juge se travaille exactement comme n'importe quelle autre : les principes d'écriture d'un bon prompt s'appliquent, avec en plus une échelle de notation explicite et des exemples de chaque niveau.

Faire tourner l'évaluation à chaque changement

Un jeu de tests qui dort dans un tableur ne sert à rien. Il doit se déclencher sur les trois événements suivants :

1. Toute modification de prompt, même d'un mot. C'est le cas le plus fréquent et le plus sournois.
2. Tout changement de modèle ou de version, y compris quand votre fournisseur met à jour un modèle sous le même nom. C'est un des critères qui pèsent dans le choix d'un modèle, comme nous l'avons vu dans notre grille de choix d'un modèle IA.
3. Tout changement dans la base documentaire si votre système va chercher des documents avant de répondre.

Conservez les résultats dans un fichier daté, avec le numéro de version du prompt et le nom exact du modèle. La valeur du jeu de tests vient de la série, pas de la mesure isolée. Au bout de six mois, vous saurez lire la courbe et repérer la modification qui a coûté trois points.

Comptez, en ordre de grandeur, une journée pour construire le premier jeu, une demi-heure par campagne ensuite, et une révision trimestrielle pour ajouter les nouveaux cas d'usage et retirer ceux qui ne correspondent plus au produit. Le coût en appels de modèle reste marginal : trente cas multipliés par une notation représentent rarement plus d'un euro par campagne.

Le piège du jeu de tests qui vieillit mal

Deux dérives guettent. La première est le sur-ajustement : à force de retoucher le prompt pour faire passer les trente cas, vous optimisez pour le jeu de tests et non pour vos utilisateurs. La parade consiste à garder cinq cas de côté, jamais consultés pendant les réglages, et à ne les jouer qu'avant une mise en production.

La seconde est l'obsolescence. Vos utilisateurs changent leurs habitudes, votre offre évolue, les questions de l'an passé disparaissent. Un jeu de tests non révisé finit par mesurer un produit qui n'existe plus. Prévoyez un rendez-vous trimestriel de vingt minutes pour piocher dix nouvelles demandes réelles dans les journaux et remplacer les cas devenus caducs.

Par où commencer cette semaine

Vous n'avez pas besoin d'outillage sophistiqué pour démarrer. Un tableur à cinq colonnes (identifiant, question, éléments obligatoires, éléments interdits, format attendu) et un script d'une trentaine de lignes suffisent à produire un premier score. Les bibliothèques d'évaluation existantes deviennent utiles quand vous dépassez la centaine de cas ou que vous voulez suivre des métriques standardisées.

Concrètement, dans l'ordre : exportez cent demandes réelles, classez-les par thème, choisissez trente cas représentatifs, écrivez les attendus, automatisez les trois critères déterministes, mesurez une première fois, puis n'y touchez plus jusqu'au prochain changement. Évaluer un modèle IA cesse alors d'être une question d'impression pour devenir une question de chiffre, et c'est tout ce qu'on lui demande.