Evals : savoir si votre système à base de LLM fonctionne avant que vos clients ne le découvrent
Un système à base de LLM ne se teste pas en lisant dix réponses et en hochant la tête. Il se teste avec des cas réels, des évaluateurs auditables et un seuil qui bloque le déploiement quand la qualité recule. Voici la pile que nous recommandons, avec ses coûts et ses pièges.
Une eval est un test reproductible d'un système à base de LLM : des entrées fixes, des critères explicites et un score comparable d'une version à l'autre. Sans elle, chaque changement de prompt, de modèle ou de niveau d'effort est un pari, et l'intuition ne permet pas de le mesurer.
La pile qui fonctionne compte cinq couches : vérifications en code, jeu de référence versionné, juges LLM calibrés sur des annotations humaines, revue humaine et suivi de la production. Notre règle : commencez avec 20 à 50 cas réels, conditionnez chaque mise en production à ces cas et enrichissez le jeu avec les échecs observés.
Pourquoi le test à l'intuition échoue
Lire quelques réponses donne l'impression de tester. Ce n'en est pas un.
Le test habituel avant lancement est une démo : quelqu'un saisit une douzaine de questions, les réponses semblent correctes, l'équipe déploie. L'échantillon est minuscule, biaisé et jamais rejoué. Quand le prompt, le modèle ou l'index change, personne ne sait si la qualité a bougé.
La perception n'est pas plus fiable. Dans l'essai randomisé de METR (juillet 2025), des développeurs open source expérimentés ont mis 19 % de temps en plus avec des outils d'IA du début 2025, tout en se croyant 20 % plus rapides. Les benchmarks publics ne comblent pas ce vide : en février 2026, OpenAI a cessé de publier SWE-bench Verified après avoir trouvé des tests défectueux dans 59,4 % de 138 tâches difficiles auditées. Et aucun ne mesure l'espagnol d'un assureur de Bogotá ou le français d'une enseigne lyonnaise.
Les enquêtes le confirment : dans celle de LangChain auprès de 1 340 praticiens (fin 2025), la qualité était le premier frein à la mise en production (32 %) et 89 % disposaient d'observabilité, mais seuls 52,4 % faisaient tourner des evals hors ligne.
La pile d'évaluation : cinq couches
Chaque couche attrape ce que la précédente laisse passer.
| Couche | Ce qu'elle détecte | Quand elle tourne | Limite |
|---|---|---|---|
| Vérifications en code | JSON cassé, champs manquants, mauvaise langue, contenu interdit, arguments d'outil invalides | À chaque commit | Ne dit pas si la réponse est juste |
| Jeu de référence (golden set) | Régressions sur des cas connus, avec réponse ou critères attendus | À chaque changement de prompt, de modèle, d'effort ou d'index | Ne couvre que ce que vous y avez mis |
| Juge LLM | Qualité des réponses ouvertes : fidélité aux sources, complétude, ton | Avec le jeu de référence et sur des échantillons de production | Biaisé tant qu'il n'est pas calibré |
| Revue humaine | Cas ambigus ou à fort enjeu, calibrage du juge | Échantillon hebdomadaire, versions majeures | Lente et coûteuse |
| Suivi de production | Dérive, nouvelles intentions, échecs réels, retours utilisateurs | En continu, sur des traces échantillonnées | Voit le problème après l'utilisateur |
Anthropic ajoute deux distinctions utiles. Les evals de capacité suivent ce que le système ne sait pas encore faire et démarrent avec des taux de réussite bas ; les evals de régression protègent ce qui fonctionne et doivent rester proches de 100 %. Pour les agents, pass@k (une tentative sur k réussit) diffère de pass^k (les k réussissent) : seul le second mesure la fiabilité.
Construire le jeu de données
Le jeu de référence est l'actif ; les outils sont remplaçables.
Anthropic recommande de commencer avec 20 à 50 tâches tirées d'échecs réels ; OpenAI, de mêler données de production, retours utilisateurs compris, et cas rédigés par des experts. Votre jeu doit ressembler à votre trafic, pas à un benchmark.
- Des prompts réels issus des logs, des tickets de support et des échanges commerciaux. Les logs contiennent souvent des données personnelles au sens du RGPD ou de la loi colombienne 1581 de 2012 : anonymisez-les avant de les copier dans un jeu de test.
- Des cas limites et hostiles : demandes ambiguës, données sales, outils en panne, questions hors périmètre, instructions injectées dans des documents. Anthropic insiste sur l'équilibre : tester quand un comportement doit se produire et quand il ne le doit pas.
- Des cas en espagnol et en français rédigés par des natifs, pas traduits : montants en COP comme 1.250.000, dates jour/mois, vouvoiement, accents manquants et changements de langue en cours de conversation.
- Un résultat attendu par cas : la réponse exacte quand elle existe, sinon les critères et les sources autorisées.
Versionnez tout ensemble : jeu, prompt, identifiant figé du modèle (pas un alias), niveau d'effort et juge. Gardez de côté une partie que vous n'utilisez jamais pour ajuster, et retirez les cas saturés : Anthropic prévient qu'une eval que tout le monde réussit ne donne plus de signal.
Évaluateurs, biais et calibrage
Prenez l'évaluateur le moins cher capable de trancher.
La correspondance exacte suffit pour la classification, le routage et l'extraction normalisée. Les vérifications programmatiques vont plus loin qu'on ne le croit : un schéma JSON, une requête SQL qui doit s'exécuter, des tests unitaires sur le code généré, une tolérance numérique, une citation qui doit figurer dans les passages récupérés. Les juges LLM à grille couvrent le reste, et le guide d'OpenAI préfère des verdicts réussi/échoué ou par paires aux échelles numériques.
| Biais | Preuve | Parade |
|---|---|---|
| Position | Avec ChatGPT comme juge, inverser l'ordre des réponses a permis à Vicuna-13B de battre ChatGPT sur 66 requêtes sur 80 (Wang et al., 2023) | Juger dans les deux ordres et faire la moyenne ; un verdict qui s'inverse avec l'ordre compte comme une égalité |
| Longueur | Les juges préfèrent les réponses longues (Zheng et al., 2023) ; contrôler la longueur a porté la corrélation d'AlpacaEval avec Chatbot Arena de 0,94 à 0,98 (Dubois et al., 2024) | Des limites de longueur dans la grille ; comparer des réponses de taille similaire |
| Autopréférence | Les juges reconnaissent leurs propres productions et les favorisent d'autant plus qu'ils les reconnaissent bien (Panickssery et al., 2024) | Un juge d'une autre famille de modèles que le système évalué |
Calibrer le juge
- Deux personnes annotent séparément les mêmes 50 à 100 cas avec la grille ; leur accord est votre plafond.
- Passez le juge sur ces cas et lisez chaque désaccord : la plupart viennent de critères flous, à réécrire en questions fermées.
- Faites confiance au juge quand son accord avec les humains approche celui des humains entre eux (Zheng et al. ont mesuré plus de 80 % pour GPT-4, le niveau humain). OpenAI déconseille d'étendre un juge avant ce stade.
- Figez la version du juge et recalibrez quand elle change. Anthropic ne garantit Claude Haiku 4.5 qu'au moins jusqu'au 15 octobre 2026.
Des seuils de régression bloquants en CI
Une eval qui ne peut pas bloquer un déploiement est un rapport, pas un contrôle.
Traitez prompts et configuration comme du code : chaque changement passe par une pull request qui lance les evals, qu'il s'agisse d'une retouche de prompt, d'une nouvelle version du modèle, d'un autre niveau d'effort, d'une base réindexée ou d'un schéma d'outil modifié.
Les modèles changent même quand votre code ne change pas. Claude Opus 5.5, lancé le 22 septembre 2026, utilise par défaut l'effort medium, un cran sous Opus 5 : les équipes qui n'avaient jamais fixé l'effort ont obtenu un autre comportement sans toucher une ligne. Un seuil bloquant transforme ce changement silencieux en build en échec.
- Étagez la batterie : 30 à 50 cas critiques à chaque pull request, le jeu complet chaque nuit et avant chaque version.
- Fixez le seuil à l'avance, par exemple zéro échec sur les cas critiques (sécurité, argent, données personnelles) et pas de baisse de plus de deux points du taux de réussite global.
- Maîtrisez le hasard : lancez les cas critiques plusieurs fois et exigez pass^k.
- Conservez les transcriptions à côté des scores : un score qu'on ne peut pas lire ne se débogue pas.
Les outils, selon leur documentation
Choisissez selon votre stack ; gardez le jeu de données portable.
| Outil | Qui, licence | Usage documenté | À savoir |
|---|---|---|---|
| Inspect | AI Security Institute britannique avec Meridian Labs, MIT | Plus de 200 evals prêtes, agents et multi-agents, outils MCP, sandbox (Docker, Kubernetes, Modal) | METR y a migré ses évaluations d'horizon temporel en janvier 2026 |
| promptfoo | MIT ; OpenAI a accepté de le racheter en mars 2026 | Evals, red teaming et scan de vulnérabilités | Reste open source ; environ 25 000 étoiles |
| OpenAI Evals | OpenAI, open source | Framework et registre d'evals | Environ 19 500 étoiles ; le produit Evals hébergé dans AgentKit, distinct, ferme le 30 novembre 2026 |
| DeepEval | Confident AI, Apache-2.0 | Framework open source d'évaluation de LLM | Environ 18 500 étoiles |
| Ragas | Apache-2.0 | Métriques RAG sans réponse de référence : recherche, fidélité, qualité de la réponse | Environ 15 900 étoiles ; désormais sous vibrantlabsai/ragas |
| LangSmith | LangChain | Évaluateurs en ligne sur les traces de production (juge LLM ou code), avec filtres, échantillonnage et rejeu | Tourne sur les traces enregistrées dans LangSmith |
| Braintrust autoevals | Braintrust, MIT | Bibliothèque open source d'évaluateurs | Environ 1 000 étoiles |
L'outil compte moins que la discipline. Gardez jeux de données et grilles dans des fichiers simples (JSONL, YAML) dans votre propre dépôt, pour changer de framework sans reconstruire le jeu de référence. Pour le RAG, ajoutez les métriques de recherche de notre guide RAG.
Ce que coûtent les evals, et comment échantillonner
Les tokens sont la petite ligne ; le temps humain est la grande.
Un calcul illustratif, pas une mesure de projet : 300 cas (100 en espagnol, 100 en anglais, 100 en français), trois essais par cas. Le système évalué est Claude Opus 5.5 (4 $ / 20 $ par million de tokens) avec 3 000 tokens en entrée et 700 en sortie par cas, raisonnement compris ; le juge est GPT-6 Sol (2 $ / 10 $), d'une autre famille, qui lit 2 500 tokens et en écrit 500.
| Scénario | Volume | Coût |
|---|---|---|
| Passe complète, prix standard | 300 cas × 3 essais | 32,40 $ |
| Passe complète, API Batch | Idem | 16,20 $ |
| Chaque nuit pendant 30 jours, en batch | 30 passes complètes | 486 $ |
| Smoke tests par pull request | 50 cas × 1 essai | 1,80 $ |
La dépense en tokens reste modeste ; le poste cher, ce sont les heures passées à annoter, relire et corriger les grilles. Et la grille du juge est un préfixe stable : OpenAI applique 90 % de remise sur l'entrée en cache avec GPT-6.
Échantillonner la production. La documentation de LangSmith montre des évaluateurs en ligne sur un échantillon, par exemple 10 % des traces. Nous stratifions : une part fixe par route et par langue, plus toutes les traces avec retour négatif, escalade, refus ou longueur inhabituelle. Les vérifications en code peuvent couvrir 100 % du trafic. D'autres leviers dans le vrai coût de l'IA.
La place de notre méthode à 30 prompts, et une check-list
Choisir un modèle est une eval ; la production a besoin des autres.
Chaque déploiement Slash commence par notre méthode de sélection de modèles : 30 prompts fixes et versionnés par client, cinq moteurs par passe, en espagnol, anglais et français, avec mesure de la qualité, des échecs observés, du coût par inférence et de la latence p95. Trente se situe dans la fourchette de 20 à 50 cas qu'Anthropic suggère pour un premier jeu.
Cette passe décide par où commencer ; elle ne remplace ni le seuil bloquant, ni le juge calibré, ni le suivi. Nous recommandons de faire de ces 30 prompts la graine du jeu de référence du client.
Check-list pour une équipe sans evals
- Choisissez une route et écrivez ce qu'est une bonne réponse.
- Réunissez 20 à 50 cas réels et anonymisés, avec des variantes en espagnol, en français et hostiles.
- Écrivez d'abord les vérifications en code : format, schéma, langue, contenu interdit, citations.
- Ajoutez un juge réussi/échoué d'une autre famille de modèles et calibrez-le sur 50 annotations humaines.
- Bloquez les merges en cas d'échec critique et lancez le jeu complet chaque nuit.
- Ajoutez chaque semaine les nouveaux échecs de production et relancez tout quand un fournisseur sort un modèle.
Aucun nouveau modèle, prompt ou niveau d'effort n'arrive en production sans passer le même jeu versionné que la version qu'il remplace. Si vous ne pouvez pas donner le taux de réussite de votre système actuel, c'est le premier chiffre à produire.
L'essentiel
- Lire quelques réponses n'est pas tester : METR a mesuré des développeurs 19 % plus lents avec l'IA alors qu'ils se croyaient 20 % plus rapides.
- Empilez cinq couches : vérifications en code, jeu de référence versionné, juges LLM calibrés, revue humaine et suivi échantillonné de la production.
- Les juges LLM ont des biais documentés de position, de longueur et d'autopréférence : inversez l'ordre, contrôlez la longueur et prenez un juge d'une autre famille.
- Installez un seuil de régression bloquant en CI et lancez-le à chaque changement de prompt, de modèle, d'effort ou d'index, sorties des fournisseurs comprises.
- Une passe complète coûte entre 16 $ et 32 $ dans notre exemple ; le coûteux, et le précieux, c'est le temps humain consacré aux annotations et aux transcriptions.
Sources
- Demystifying evals for AI agents
- Evaluation best practices
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
- Large Language Models are not Fair Evaluators
- Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators
- LLM Evaluators Recognize and Favor Their Own Generations
- Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- Why we no longer evaluate SWE-bench Verified
- State of Agent Engineering
- Models overview
- API pricing
Note éditoriale : cette analyse reflète les informations publiques disponibles à la date de révision. Modèles, prix et règles évoluent vite ; chaque donnée tierce renvoie à sa source et nos opinions sont présentées comme telles. Une erreur ? Écrivez à contact@slash-digital.io.
Les questions qu'on nous pose souvent
Qu'est-ce qu'une eval de LLM ?
Un test reproductible d'un système à base de LLM : un ensemble fixe d'entrées, des critères explicites et des évaluateurs (du code, un modèle ou des personnes) qui produisent un score comparable entre versions de votre prompt, de votre modèle ou de vos réglages.
Combien de cas faut-il pour commencer ?
Anthropic recommande de commencer avec 20 à 50 tâches issues d'échecs réels. Partez de là, rendez-les fiables, puis enrichissez le jeu avec des traces de production plutôt que de viser des milliers de cas synthétiques dès le premier jour.
Peut-on faire confiance à un LLM comme juge ?
Seulement après calibrage. Zheng et al. ont mesuré plus de 80 % d'accord entre GPT-4 et les humains, autant qu'entre humains, mais ces mêmes travaux et d'autres plus récents documentent des biais de position, de longueur et d'autopréférence. Mesurez votre juge sur des annotations humaines avant de vous y fier.
Quel outil d'evals choisir ?
Celui qui s'intègre à votre stack : Inspect, promptfoo, DeepEval, Ragas, OpenAI Evals, LangSmith ou autoevals de Braintrust sont des options documentées. Gardez jeux de données et grilles dans votre propre dépôt pour que ce choix reste réversible.
Les benchmarks publics rendent-ils nos propres evals inutiles ?
Non. Ils mesurent des tâches génériques, surtout en anglais, et peuvent être défaillants : OpenAI a cessé de publier SWE-bench Verified après avoir trouvé des tests défectueux dans 59,4 % de 138 tâches difficiles auditées. Vos prompts, vos langues et vos modes d'échec exigent votre propre jeu.
D'autres analyses à lire
Comment nous choisissons un modèle
Langue, code, agents, coût et confidentialité : l'évaluation menée avant chaque déploiement, avec 30 prompts réels par client.
Agents et ingénierieLe RAG en 2026 : contexte long, recherche hybride et recherche agentique
Une fenêtre d'un million de tokens ne remplace pas la recherche. Ce qui marche en 2026 : chunks contextualisés, recherche hybride, rerankers, agents, droits d'accès et coûts.
Agents et ingénierieAgents IA en production : ce qui marche en 2026
Workflow ou agent, les huit briques, données d'adoption et d'échec, usage de l'ordinateur, règles de conception, coûts, sécurité et check-list.
Et ensuite ?
Mettons-le en production
Racontez-nous votre défi. Nous répondons sous 24 heures ouvrées avec une première lecture honnête : si nous pouvons aider, nous dirons comment ; sinon, nous dirons qui peut.
Je réponds en personne. Pas de formulaires interminables ni de réponses automatiques.