Une démo montre qu'une fonctionnalité IA peut marcher. Elle ne montre pas qu'elle marche sur les mille demandes que vos utilisateurs vont lui envoyer. Une éval (pour « évaluation ») répond à cette question. C'est un jeu de cas de test réels, un résultat attendu pour chacun, et une note calculée de la même façon à chaque passage.
Une démo n'est pas une mesure
Un LLM ne donne pas toujours la même réponse à la même question. Changez une phrase des instructions, passez à une nouvelle version du modèle, ajoutez un document : certaines réponses s'améliorent, d'autres se dégradent. Sans mesure, personne ne sait lequel des deux effets l'emporte.
Concept clé
Une éval est un test répétable : les mêmes cas, la même façon de noter, à chaque changement. Elle remplace « ça a l'air bien » par un score que l'on compare d'une version à l'autre. Définissez ce qui est « assez bon » avant de construire, pas après la démo.
Sur cent cas, la fonctionnalité obtient un score global de 88 %.
Les cas de test comptent plus que l'outil. Ils doivent ressembler à ce que vos utilisateurs envoient vraiment, cas difficiles compris : une question hors sujet, un document trop long, une demande que même un humain trouverait ambiguë. En octobre 2026, la documentation d'Anthropic conseille de privilégier le volume : beaucoup de cas notés automatiquement valent mieux que quelques cas notés à la main.
Pour noter, il existe trois méthodes. Un script compare la sortie au résultat attendu ; c'est rapide et fiable, mais cela ne juge que ce qui se compare exactement. Un humain juge mieux, mais il est lent et coûteux. Un modèle peut noter selon une grille, à condition d'avoir vérifié qu'il note juste.
Tout part d'un jeu de cas de test réels, avec un résultat attendu pour chacun.
Ce que ça change pour vous
Pour les product managers
Écrivez les critères de réussite avant le premier prototype, et rendez-les mesurables : « 95 % des demandes de remboursement classées dans la bonne catégorie », pas « des réponses de qualité ». Partez de vingt cas réels, tirés de tickets ou d'e-mails, et faites écrire le résultat attendu par la personne qui traite ces demandes aujourd'hui. Un script ou un modèle note ensuite chaque passage. Sur vingt cas, chacun pèse 5 points : assez pour repérer les erreurs, pas pour prouver un seuil de 95 %. Dans une startup, ce premier jeu suffit pour décider de continuer. Dans un grand groupe, il devient la preuve qu'on vous demandera avant d'ouvrir la fonctionnalité à d'autres équipes.
Pour les tech leads
Branchez les évals dans l'intégration continue, comme les tests unitaires. Chaque changement de prompt système, de modèle ou de documents fournis doit relancer le jeu complet et afficher l'écart avec la version précédente. Versionnez les cas avec le code. Dans une startup, un script et un tableur suffisent au début. Dans un grand groupe, les cas contiennent souvent des données clients : ils relèvent alors des mêmes règles d'accès et de conservation que la production.
Sur 220 cas par passage, l'intervalle sur l'écart ne contient plus zéro : on distingue 95 % de 90 %.
Pour aller plus loinPourquoi un score moyen ne suffit pas
Un score global peut monter pendant qu'une catégorie de cas s'effondre. Par exemple, une fonctionnalité qui passe de 88 % à 91 % peut avoir perdu tous les cas où elle devait répondre « je ne sais pas ». Regroupez les cas par type (simples, ambigus, hors sujet, pièges) et suivez chaque groupe séparément. Gardez aussi la liste des cas ratés : c'est elle qui montre où porter l'effort.
Méfiez-vous enfin des petits écarts. Sur cent cas, un score de 90 % comporte une marge d'incertitude de l'ordre de six points dans chaque sens : le passage de 88 % à 91 % peut n'être que du hasard. Pour distinguer de façon fiable 90 % de 95 %, comptez plusieurs centaines de cas : à deux cents, l'écart reste à la limite du hasard.
L'erreur classique
fAIling RÈGLE VI
Le piège : La démo, c'est le produit
Une démo réussie sur trois exemples choisis par l'équipe ne dit rien des cas que l'équipe n'a pas imaginés. Avant de présenter la fonctionnalité au comité de direction, étendez votre premier jeu à cinquante cas réels, testez-la sur ce jeu et présentez le score avec la démo.
Lire la règle VI du manifesteÀ essayer
Prenez une tâche que vous confiez déjà à un assistant IA, par exemple résumer un compte rendu de réunion. Pour un premier essai, rassemblez dix exemples réels et écrivez, pour chacun, ce qu'un bon résumé doit contenir. Soumettez les dix exemples, notez chaque réponse « correct » ou « incorrect », puis changez une seule phrase de vos instructions et recommencez. Comparez les deux scores.
Autour du sujet
Pour aller plus loinUn modèle comme juge
Quand le bon résultat ne se compare pas mot à mot (un ton, un résumé, une explication), on peut demander à un modèle de le noter. En octobre 2026, la documentation d'Anthropic conseille une grille détaillée, une note simple (« correct » ou « incorrect », ou une échelle de 1 à 5) et un juge qui raisonne avant de noter. Elle recommande de vérifier la fiabilité du juge avant de l'utiliser à grande échelle. Ses exemples indiquent aussi qu'il vaut mieux, en général, faire juger par un autre modèle que celui qui a produit la réponse. En pratique, faites noter une partie des cas par un humain, et comparez avec le juge.
Pour aller plus loinRelancer les évals à chaque nouveau modèle
Les éditeurs remplacent régulièrement leurs modèles. En octobre 2026, Anthropic prévient ses clients au moins 60 jours avant de retirer un modèle rendu public, et recommande de tester vos applications sur le modèle de remplacement bien avant la date de retrait. Une nouvelle version peut être meilleure en moyenne et moins bonne sur votre tâche : plus bavarde, plus prudente, ou différente dans son format de sortie. Avec un jeu de cas de test, la migration devient une comparaison de scores. Sans lui, elle se joue sur l'impression de quelques personnes, puis sur les plaintes des utilisateurs.
Pour aller plus loinConstruire les cas de test à partir de la production
Après le lancement, les meilleurs cas de test viennent de vos utilisateurs. Une réponse signalée comme fausse, une conversation abandonnée, une demande que personne n'avait prévue : chacune peut devenir un cas de test. Le jeu grandit ainsi avec le produit, et suit ce que les utilisateurs font vraiment. Les journaux de production contiennent souvent des données personnelles. Retirez ces données, anonymisez-les ou pseudonymisez-les avant d'en faire des cas de test.
Quoi en faire
Écrivez les critères de réussite avant le premier prototype et rendez-les mesurables : « 95 % des demandes de remboursement bien classées », pas « des réponses de qualité ».
Tirez les cas de ce que les utilisateurs envoient vraiment, cas difficiles compris, et faites écrire le résultat attendu par la personne qui fait la tâche.
Suivez chaque type de cas à part et méfiez-vous des petits écarts : sur cent cas, passer de 88 % à 91 % peut n'être que du hasard.