Évaluation des LLM : tester une IA générative comme un logiciel, avec un cadre en 5 étapes
Comment prouver qu'un assistant, un moteur de questions-réponses ou un agent répond juste avant de le mettre entre les mains de vos clients : critères, jeu de référence, LLM juge, red teaming et intégration dans la chaîne de livraison.
Évaluer un LLM, c'est mesurer le taux de bonnes réponses de votre application d'IA sur un jeu de cas représentatifs, selon des critères fixés à l'avance. Une IA générative ne répond jamais deux fois exactement de la même façon : on ne la teste pas avec une assertion, on la mesure sur un échantillon.
- Trois évaluateurs se complètent : la vérification par le code (format, champs, outils appelés), le LLM juge pour les critères qualitatifs, la revue humaine pour trancher et étalonner.
- Le nombre de cas se calcule : environ 139 cas pour mesurer un taux de réussite de 90 % à plus ou moins 5 points.
- La sécurité se teste aussi : injection de prompt, fuite de données et excès d'autonomie figurent en tête du Top 10 OWASP 2026 pour les applications LLM.
- L'évaluation est une suite de non-régression : elle tourne à chaque changement de prompt, de modèle ou de documents, et bloque la livraison sous un seuil.
Votre plan d'évaluation en 4 réponses : combien de cas, quels critères, quels risques
Décrivez votre application d'IA. Le calcul donne la taille minimale du jeu de référence pour une mesure fiable, puis les critères et les risques à tester en priorité.
Premier échange sans engagement. Calcul indicatif fondé sur l'intervalle de confiance d'une proportion (95 %, ou 99 % si la conséquence est élevée) ; il suppose des cas tirés au hasard parmi les demandes réelles.
Évaluation LLM : la définition
L'évaluation d'un LLM (LLM evaluation) mesure la qualité des réponses d'un modèle de langage, ou d'une application qui l'utilise, sur un jeu de cas représentatifs et selon des critères définis à l'avance. Elle produit des taux (bonnes réponses, réponses fidèles aux sources, refus appropriés) plutôt qu'un verdict unique.
Il faut distinguer deux pratiques. Les benchmarks publics classent des modèles sur des tâches générales. Une entreprise, elle, évalue son application : le modèle plus son prompt, ses documents, ses outils et ses règles, sur ses propres cas d'usage. Un modèle en tête des classements peut échouer sur vos conditions générales de vente.
C'est le prolongement naturel de la démarche QA : définir ce qui est attendu, le vérifier de façon reproductible, et empêcher qu'une modification ne dégrade ce qui fonctionnait.
Une IA ne se teste pas avec une assertion, elle se mesure sur un échantillon
Un test classique compare une sortie à une valeur attendue ; une IA générative peut donner dix réponses différentes et toutes correctes. Les principes du test restent valables, mais l'outillage change.
| Critère | Test logiciel classique | Évaluation d'une application d'IA |
|---|---|---|
| Résultat attendu | Une sortie exacte, identique à chaque exécution | Plusieurs réponses acceptables, formulées différemment d'une exécution à l'autre |
| Vérification | Une assertion : égal, différent, présent, absent | Des critères notés : exactitude, fidélité aux sources, ton, respect des consignes |
| Verdict | Un cas passe ou échoue | Un taux de réussite mesuré sur un échantillon de cas |
| Ce qui provoque une régression | Une modification du code | Le code, mais aussi le prompt, la version du modèle, les documents indexés ou un réglage comme la température |
| Moment du test | Avant la livraison | Avant la livraison, puis en continu en production, car les entrées réelles sont imprévisibles |
La dernière ligne est la plus sous-estimée. Un fournisseur qui met à jour son modèle modifie votre application sans que votre code bouge. C'est exactement le rôle d'un référentiel de non-régression, appliqué à des réponses plutôt qu'à des écrans.
Trois façons de noter une réponse, à combiner selon le critère
La règle : le moins cher qui suffit. Ce que le code peut vérifier ne doit pas être confié à un juge, et ce qu'un juge étalonné note correctement ne doit pas mobiliser un expert.
Vérification par le code
Format JSON valide, champ obligatoire présent, longueur maximale, mot interdit absent, appel du bon outil avec les bons paramètres.
- Force
- Rapide, gratuit, reproductible : à utiliser partout où le critère se vérifie sans interprétation
- Limite
- Ne dit rien de la justesse ni de la pertinence d'une réponse rédigée
LLM juge (LLM-as-a-judge)
Un second modèle note la réponse selon une grille écrite : fidélité aux sources, exactitude par rapport à une réponse de référence, respect des consignes.
- Force
- Évalue des centaines de réponses ouvertes en quelques minutes ; GPT-4 a atteint plus de 80 % d'accord avec les préférences humaines dans l'étude de Zheng et al.
- Limite
- Biais connus (position, longueur, préférence pour ses propres réponses) : le juge doit être calibré sur des notes humaines
Revue humaine
Un expert du métier relit un échantillon de réponses, tranche les cas ambigus et note les échecs critiques.
- Force
- La seule référence sur ce qui est juste dans votre métier ; elle sert aussi à étalonner le LLM juge
- Limite
- Lente et coûteuse : à concentrer sur les cas critiques, les désaccords et un échantillon régulier
Pour les applications de questions-réponses sur documents (RAG), trois critères se sont imposés depuis l'article de Es et al. sur Ragas : la fidélité (chaque affirmation de la réponse est-elle appuyée par les documents récupérés ?), la pertinence de la réponse (répond-elle à la question posée ?) et la pertinence du contexte (les bons passages ont-ils été retrouvés ?). Ils permettent de savoir si une erreur vient de la recherche documentaire ou de la rédaction.
Le cadre de test en 5 étapes, du premier critère à la production
L'ordre compte : sans critères écrits, aucun outil d'évaluation ne produit de résultat exploitable.
-
1
Définir ce qu'est une bonne réponse, cas d'usage par cas d'usage
Écrivez des critères vérifiables avant d'écrire le moindre test : « la réponse cite l'article des conditions générales utilisé », « l'assistant refuse de donner un avis médical », « le montant calculé est exact au centime ». Un critère qui ne peut être tranché par personne ne peut être tranché par un juge automatique.
-
2
Constituer un jeu de référence à partir de cas réels
Trois familles de cas : les demandes les plus fréquentes (tirées des journaux, des tickets ou des questions des équipes métier), les cas limites (question hors périmètre, information absente des documents, demande ambiguë) et les cas adversariaux. Chaque cas porte son entrée, ses critères et, si possible, une réponse de référence validée par un expert.
-
3
Choisir le bon évaluateur pour chaque critère
Ce qui se vérifie par le code se vérifie par le code. Le LLM juge prend les critères qualitatifs, avec une grille explicite et un étalonnage sur une cinquantaine de réponses notées par un humain. La revue humaine tranche les désaccords et les échecs sur les parcours critiques.
-
4
Attaquer son propre système (red teaming)
Testez les risques du Top 10 OWASP pour les applications LLM qui concernent votre cas : injection de prompt, divulgation de données, excès d'autonomie pour un agent. Le cadre du NIST (AI 600-1) recommande que ces exercices soient menés par des personnes qui n'ont pas construit le système.
-
5
Brancher l'évaluation dans la chaîne de livraison, puis en production
Le jeu de référence devient une suite de non-régression : il tourne à chaque changement de prompt, de modèle, de documents ou de code, et bloque la livraison sous un seuil fixé. En production, un échantillon de conversations réelles est évalué en continu, et chaque échec découvert rejoint le jeu de référence.
L'étape 5 relève du même principe que le continuous testing : la qualité se vérifie à chaque changement, pas une fois avant la mise en ligne. Pour l'évaluation du code de test produit par l'IA, lisez aussi notre bilan IA générative dans les tests : ce qui marche vraiment.
Red teaming : les 6 risques OWASP 2026 à attaquer avant vos utilisateurs
Une IA qui répond juste peut aussi être détournée. L'édition 2026 du Top 10 OWASP pour les applications LLM fait monter l'excès d'autonomie de la 6e à la 3e place : quand une IA peut agir, le risque n'est plus seulement ce qu'elle dit, mais ce qu'elle fait.
| Rang | Risque | Ce qu'il faut tester |
|---|---|---|
| LLM01 | Injection de prompt | Instructions cachées dans la demande de l'utilisateur, mais aussi dans un document indexé, un courriel ou une page web lue par l'IA (injection indirecte) |
| LLM02 | Divulgation d'informations sensibles | Demandes visant à obtenir des données personnelles, des informations d'un autre client ou des éléments confidentiels présents dans les sources |
| LLM03 | Excès d'autonomie | Pour un agent : peut-il déclencher une action (remboursement, suppression, envoi) hors de son périmètre ou sans validation humaine ? |
| LLM06 | Consommation non bornée | Demandes qui déclenchent des boucles d'appels au modèle ou aux outils et font exploser le coût ou le temps de réponse |
| LLM07 | Désinformation | Questions dont la réponse n'est pas dans les sources : l'IA doit le dire au lieu d'inventer une réponse plausible |
| LLM08 | Exposition du contexte caché | Tentatives de faire révéler le prompt système, les règles métier, les schémas d'outils ou la logique de décision |
Le profil IA générative du NIST (AI 600-1) recommande que les exercices de red teaming soient conduits par des personnes indépendantes de l'équipe qui a construit le modèle. Chaque attaque réussie devient un cas du jeu de référence : elle sera rejouée à chaque livraison.
Quatre outils open source pour démarrer sans plateforme payante
L'outil compte moins que le jeu de référence : un bon jeu de cas se migre d'un outil à l'autre, une mauvaise grille reste mauvaise partout.
| Outil | Nature | Idéal pour | À savoir |
|---|---|---|---|
| Ragas | Bibliothèque open source | Systèmes RAG : fidélité aux sources, pertinence de la réponse et du contexte récupéré | Issue de l'article de Es et al. (2023) qui a formalisé ces métriques |
| DeepEval | Bibliothèque open source (Apache 2.0) | Tests d'IA écrits comme des tests unitaires, intégrables à la CI | Une plateforme hébergée payante (Confident AI) existe à côté, elle n'est pas nécessaire |
| promptfoo | Outil en ligne de commande open source (MIT) | Comparer des prompts et des modèles sur un même jeu de cas, et mener du red teaming | Racheté par OpenAI en mars 2026, il reste sous licence MIT |
| Giskard | Bibliothèque open source (Apache 2.0) et plateforme payante | Détection de vulnérabilités (injections, hallucinations) et génération de cas de test RAG | Éditeur français |
Ces outils s'exécutent dans une chaîne d'intégration continue comme n'importe quelle suite de tests. Pour les tests de l'interface qui entoure votre IA, notre comparatif des outils d'automatisation de tests couvre Playwright, Cypress et Selenium.
Quatre pièges qui rendent une évaluation rassurante et fausse
Évaluer sur les questions de la démonstration
Les dix questions qui ont convaincu le comité de direction sont celles sur lesquelles l'IA marche. Elles ne disent rien des questions que posent vraiment les utilisateurs.
Changer de modèle sans relancer l'évaluation
Une nouvelle version de modèle, même annoncée comme meilleure, peut dégrader votre cas d'usage précis. C'est une régression comme une autre.
Faire confiance au juge sans l'étalonner
Un LLM juge non calibré produit des notes précises en apparence et fausses en pratique. Comparez ses notes à celles d'un expert avant de lui confier la décision.
Piloter par une note moyenne
Une moyenne de 4,2 sur 5 peut cacher trois réponses dangereuses. Suivez à part le taux d'échec sur les cas critiques, avec un seuil à zéro.
Ce que l'AI Act change : l'exactitude devra être prouvée
Pour les systèmes d'IA à haut risque, l'article 15 du règlement européen sur l'IA exige un niveau approprié d'exactitude, de robustesse et de cybersécurité. Le règlement omnibus numérique, entré en vigueur en juillet 2026, a reporté ces obligations au 2 décembre 2027 pour les systèmes de l'annexe III (recrutement, crédit, accès aux services essentiels, notamment). Le report laisse le temps de s'organiser, il ne supprime pas l'exigence.
Hors haut risque, la logique est la même côté direction : une IA dont on ne mesure pas la qualité est une IA dont on ne peut pas défendre la valeur. C'est ce que nous appelons l'automatisation intelligente des tests : outiller la mesure, la brancher dans la chaîne de livraison, et relier les résultats à des décisions business. Nos expertises en qualité logicielle et automatisation détaillent comment nous intervenons.
Questions fréquentes sur l'évaluation des LLM
Qu'est-ce que l'évaluation d'un LLM ?
L'évaluation d'un LLM consiste à mesurer la qualité des réponses d'un modèle de langage ou d'une application qui l'utilise, sur un jeu de cas représentatifs et selon des critères définis à l'avance : exactitude, fidélité aux sources, respect des consignes, sécurité. Elle combine des vérifications automatiques par le code, un modèle juge et une revue humaine, et produit un taux de réussite plutôt qu'un simple verdict passe ou échoue.
Quelle différence entre évaluer un modèle et évaluer une application d'IA ?
Les benchmarks publics (MMLU et équivalents) comparent des modèles sur des tâches générales. Ils ne disent pas si votre assistant répond juste sur vos contrats, vos produits ou vos procédures. Une entreprise évalue son application : le modèle, son prompt, ses documents et ses outils, sur ses propres cas d'usage.
Combien de cas de test faut-il pour évaluer un LLM ?
Cela dépend de la précision voulue. Pour mesurer un taux de réussite d'environ 90 % à plus ou moins 5 points avec 95 % de confiance, il faut environ 139 cas. Pour plus ou moins 3 points, il en faut environ 385. Sur les cas critiques, la règle de trois s'applique : si l'IA ne commet aucune erreur sur 100 cas, son taux d'erreur réel peut encore atteindre 3 %.
Peut-on utiliser un LLM pour évaluer un autre LLM ?
Oui, c'est la méthode du LLM juge. Dans l'étude de Zheng et al. (NeurIPS 2023), GPT-4 utilisé comme juge atteignait plus de 80 % d'accord avec les préférences humaines, un niveau comparable à l'accord entre deux humains. Les mêmes travaux décrivent des biais de position, de longueur et de préférence pour ses propres réponses : le juge doit être étalonné sur des notes humaines et suivre une grille explicite.
Qu'est-ce que le red teaming d'une IA ?
Le red teaming consiste à attaquer volontairement son propre système d'IA pour trouver ses failles avant les utilisateurs : injections de prompt, tentatives d'extraction de données, détournement d'un agent vers des actions non autorisées. Le Top 10 OWASP pour les applications LLM (édition 2026) fournit la liste des risques à couvrir en priorité.
L'AI Act impose-t-il de tester son IA ?
Pour les systèmes d'IA classés à haut risque, oui : l'article 15 du règlement européen sur l'IA exige un niveau approprié d'exactitude, de robustesse et de cybersécurité, ce qui suppose de le mesurer. Depuis l'adoption du règlement omnibus numérique, ces obligations s'appliquent au 2 décembre 2027 pour les systèmes de l'annexe III. Pour les autres usages, l'évaluation reste la seule façon de prouver que l'IA fait ce qu'on attend d'elle.
Pour aller plus loin
Sources
- Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023
- Shahul Es, Jithin James, Luis Espinosa-Anke et Steven Schockaert, Ragas: Automated Evaluation of Retrieval Augmented Generation, EACL 2024 (démonstrations)
- Cloud Security Alliance, The OWASP Top 10 for LLM Applications 2026: What Changed and Why It Matters, 21 octobre 2026
- OWASP GenAI Security Project, Top 10 for LLM Applications
- NIST, AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024
- Règlement (UE) 2024/1689 sur l'intelligence artificielle (AI Act), article 15
- Future of Privacy Forum, The AI Act implementation timeline: what changes under the AI Omnibus?
- James A. Hanley et Abby Lippman-Hand, If Nothing Goes Wrong, Is Everything All Right?, JAMA, 1983 (règle de trois)
- Ragas, dépôt GitHub
- DeepEval, dépôt GitHub
- promptfoo, dépôt GitHub
- Giskard, dépôt GitHub
L'outil interactif est indicatif. La taille du jeu de référence suit la formule n = z² × p × (1 − p) / E², avec z = 1,96 (95 % de confiance) ou 2,576 (99 %) ; elle suppose des cas tirés au hasard parmi les demandes réelles.
Votre IA est-elle prête à être mise entre les mains de vos clients ?
Nous construisons avec vos équipes les critères, le jeu de référence et la chaîne d'évaluation qui permettent de livrer une IA en sachant ce qu'elle vaut.
Premier échange sans engagement