Combien de cas faut-il dans un jeu d’évaluation avant une démo ?

Une cinquantaine de cas réels, notés en binaire par un expert métier, constitue un point de départ raisonnable. Pour un système déjà en production, des jeux plus larges sont courants : OpenAI documente par exemple un cas évalué sur 1000 transcriptions de référence.

Qui doit noter les réponses : un expert métier ou un modèle IA ?

Les deux, mais pas en même temps. Un expert métier note d’abord un échantillon en binaire avec une critique écrite. Un juge automatique est ensuite calibré contre ces verdicts humains, puis prend en charge le volume, avec des contrôles réguliers pour détecter une dérive.

Une évaluation formelle est-elle nécessaire pour un simple prototype interne ?

Non. Pour un prototype jetable ou un script déterministe testable par des tests unitaires classiques, une évaluation formelle coûte plus qu’elle n’apporte. Elle devient utile au moment où un vrai utilisateur voit la sortie ou où une décision s’appuie dessus.

Quelle est la différence entre une évaluation IA et un test unitaire classique ?

Un test unitaire vérifie une sortie exacte et déterministe. Une évaluation IA mesure un taux de réussite sur un ensemble de cas face à un système dont les réponses varient, avec des critères de correction parfois subjectifs qui nécessitent un jugement humain ou un juge automatique calibré.

Tester un système IA avant la démo : la méthode en 5 étapes

Q: Qu’est-ce qu’une évaluation IA (eval) ?

C’est un test automatisé ou semi-automatisé qui mesure la performance d’un système IA sur un ensemble de cas représentatifs, avant qu’un utilisateur réel ne le voie, contrairement à une démo qui ne montre qu’un seul scénario favorable.

Qu’est-ce qu’une évaluation IA, et pourquoi la démo ne suffit pas

Une démo réussie prouve une chose : que le système fonctionne sur l’exemple choisi, dans les conditions choisies, le jour choisi. Elle ne prouve rien sur le comportement du système face aux dizaines de variantes que rencontreront les vrais utilisateurs. C’est exactement l’écart qu’une évaluation IA est censée combler.

Une évaluation IA, ou eval, est un test automatisé (ou semi-automatisé) qui mesure la performance d’un système sur un ensemble de cas représentatifs, avant qu’un utilisateur réel ne le voie. Contrairement à une démo, qui montre un seul scénario favorable, une eval mesure un taux de réussite sur plusieurs dizaines ou centaines de cas, y compris les cas limites que personne ne choisirait spontanément pour impressionner un client.

Chez les équipes qui livrent des produits IA en quelques semaines plutôt qu’en plusieurs trimestres, l’absence d’évaluation structurée est la cause la plus fréquente d’un décalage entre « ça marchait en démo » et « ça ne marche pas chez le premier vrai utilisateur ». Ce décalage coûte cher : il se découvre en général au pire moment, une fois le client déjà engagé.

Le piège du succès sur un seul exemple

Un système génératif peut produire une réponse excellente à une question et une réponse fausse, incohérente ou hors sujet à une question presque identique. Cette variance est la nature même des modèles de langage : elle n’est pas un bug qu’on corrige une fois, c’est une propriété qu’on mesure en continu. Choisir un seul exemple pour une démonstration revient donc à tirer une carte dans un jeu dont on ne connaît pas la distribution.

Prenons un cas courant : un assistant qui répond aux questions d’un client sur ses factures. En démo, la question posée est toujours claire, bien formulée, avec un numéro de facture valide. En production, une partie des questions arrivent mal orthographiées, sans numéro de facture, dans une autre langue, ou en mélangeant deux demandes différentes dans la même phrase. Une eval qui ne couvre que le cas « propre » ne détectera jamais que le système répond n’importe quoi dès que l’entrée s’écarte un peu du script.

Le développement piloté par l’évaluation (« eval-driven development ») inverse cette logique : on écrit d’abord une définition mesurable et testable de ce qu’est une réponse correcte pour une catégorie de demande donnée, avec la gestion explicite des cas limites, avant même d’ajuster les instructions du modèle. La démonstration devient alors une conséquence du système qui passe ses tests, pas un objectif en soi.

Trois familles de méthodes, pour trois usages différents

Il n’existe pas une seule bonne façon d’évaluer un système IA. Trois familles de méthodes coexistent, et la plupart des projets sérieux en combinent au moins deux.

Méthode	Principe	Quand l’utiliser	Limite principale
Comparaison à une référence (« reference-based »)	On compare la sortie à une réponse de référence écrite à l’avance	Sorties structurées, extraction, classification, résumés courts	Ne fonctionne pas pour les réponses ouvertes ou créatives
Juge automatique (« LLM-as-judge »)	Un modèle évalue la sortie d’un autre modèle selon des critères écrits	Réponses ouvertes, conversationnelles, résumés longs, agents	Doit être calibré contre des annotations humaines, sinon il dérive
Revue humaine	Un expert métier note la sortie et rédige une critique	Établir la vérité de référence, calibrer un juge automatique, cas sensibles	Coûteux et lent à grande échelle

Dans la pratique, la combinaison la plus efficace fait porter le gros du volume au juge automatique, et réserve la revue humaine aux désaccords, aux cas limites et à un contrôle de dérive périodique du juge lui-même. Un juge jamais recalibré fini par noter généreusement des réponses de moins bonne qualité, un phénomène documenté sous le nom de dérive du juge.

Construire un jeu d’évaluation avant la première démo

Il n’est pas nécessaire de construire une infrastructure d’évaluation complète pour commencer. Cinq étapes suffisent pour transformer une intuition (« ça a l’air de marcher ») en une mesure :

Réunir 50 cas réels, si possible d’anciens échecs ou des demandes réelles de l’usage visé, plutôt que des exemples inventés pour l’occasion.
Faire noter chaque cas en binaire (correct ou non) par une personne qui connaît le métier, avec une courte critique écrite qui explique pourquoi.
Calibrer un juge automatique sur ces verdicts humains, en ajustant le prompt du juge jusqu’à ce qu’il tombe d’accord avec l’expert sur la grande majorité des cas.
Fixer un seuil de blocage sur la métrique qui correspond à l’échec le plus coûteux pour l’activité, pas sur une moyenne générale qui masque les cas graves.
Rejouer l’évaluation à chaque changement de prompt, de modèle ou de source de données, avant de montrer quoi que ce soit à un client.

OpenAI documente par exemple un cas de résumé de transcriptions évalué sur un jeu de 1000 transcriptions de référence tenues à l’écart de l’entraînement, ce qui donne un ordre de grandeur pour un système arrivé en production. Le jeu de 50 cas est un point de départ raisonnable, pas un objectif final : il grandit au rythme des nouveaux cas d’échec rencontrés une fois le système en usage réel.

Ce qu’il faut mesurer selon le type de système

Un agent qui déclenche des actions

Pour un agent, la question n’est pas seulement « la réponse finale est-elle correcte », mais aussi « le bon outil a-t-il été appelé, avec les bons arguments, dans le bon ordre ». Un agent qui arrive à la bonne conclusion par un chemin dangereux (mauvais outil, arguments erronés corrigés par hasard) est un agent qui échouera dès que les conditions changeront légèrement. Mesurer uniquement le résultat final donne une fausse impression de fiabilité.

Un système de recherche augmentée (RAG)

Deux mesures distinctes comptent : la qualité de la récupération (les bons documents ont-ils été trouvés) et la qualité de la génération (la réponse s’appuie-t-elle réellement sur ces documents, sans invention). Confondre les deux masque la vraie cause d’un échec : un mauvais résultat peut venir d’une recherche qui rate le bon document, ou d’une génération qui l’ignore complètement et invente une réponse plausible.

Un système génératif simple

Ici, le juge automatique calibré contre une revue humaine suffit dans la majorité des cas, à condition de couvrir explicitement les cas limites : entrées vides, hors sujet, ambiguës, ou dans une langue inattendue. C’est justement la catégorie de cas qu’une démo, par construction, ne montre jamais.

Lire les résultats sans se tromper de conclusion

Un score global élevé peut cacher un échec systématique sur une sous-catégorie précise de demandes, souvent la plus coûteuse pour l’activité. Imaginons une moyenne hypothétique de 92% de réponses correctes : ce chiffre n’a aucune valeur décisionnelle si les 8% d’échecs restants se concentrent sur les demandes des plus gros clients ou sur les cas à enjeu juridique. La bonne pratique consiste à découper le score par catégorie de demande, pas seulement à regarder une moyenne unique, et à fixer le seuil de blocage sur la catégorie la plus sensible plutôt que sur l’ensemble.

Il faut aussi se méfier d’un juge automatique trop indulgent : un juge calibré une seule fois, puis jamais recontrôlé, dérive avec le temps à mesure que le système évalué change. Un contrôle périodique, même sommaire, contre un nouvel échantillon noté par un humain reste la seule façon de vérifier que le juge mesure toujours ce qu’on croit qu’il mesure.

Quand une évaluation formelle n’est pas le bon choix

Construire un pipeline d’évaluation complet n’est pas toujours justifié. Pour un prototype jetable destiné à valider une direction produit avant tout investissement, ou pour un script déterministe classique qui se teste très bien avec des tests unitaires ordinaires, l’effort d’une eval formelle dépasse sa valeur. Dans un cycle de livraison de produit court, de l’ordre de quelques semaines, investir plusieurs jours dans un jeu d’évaluation pour une fonctionnalité qui sera peut-être abandonnée après le premier retour utilisateur est un mauvais arbitrage.

Le signal qui doit déclencher l’investissement dans une évaluation structurée est différent : c’est le moment où un vrai utilisateur va voir la sortie du système, où une décision s’appuie dessus, ou où le système passe d’un usage occasionnel à un usage répété. Avant ce point, une revue manuelle rapide de quelques dizaines de cas par une personne du métier reste suffisante.

Ce que ça coûte, en temps et en discipline

La partie la plus coûteuse n’est presque jamais l’outillage : elle est le temps d’un expert métier pour noter les premiers cas et écrire des critiques utilisables. Cette étape ne se délègue pas à un modèle, sous peine de calibrer un juge automatique contre lui-même, ce qui revient à ne rien mesurer du tout. Une fois cette base humaine posée, rejouer l’évaluation à chaque changement coûte quelques minutes et évite des heures de correction en production, souvent dans l’urgence et sous le regard du client.

Un point de vigilance additionnel : les plateformes d’évaluation évoluent vite et certaines fonctionnalités sont retirées avec peu de préavis, ce qui plaide pour documenter la méthode et les cas de test indépendamment d’un outil précis, plutôt que de dépendre d’une seule plateforme propriétaire pour conserver l’historique des verdicts.

Découvrez le métier de forward deployed engineer, dont l’évaluation avant démonstration fait partie du quotidien, et notre article sur le coût réel d’une fonctionnalité IA en production, qui détaille où va le budget une fois la démo passée. Pour un aperçu de nos formules, consultez nos formules et nos prix, et pour les questions les plus fréquentes sur notre méthode, les questions fréquentes.