Benchmarks LLM : guide conformité pour les équipes gouvernance IA

L’essentiel

• Les benchmarks LLM sont des dispositifs standardisés associant un jeu de données, une tâche, une métrique et un mécanisme de notation, afin de mesurer une capacité précise d’un grand modèle de langage de façon comparable d’un modèle à l’autre.
• Les benchmarks publics comme MMLU, HumanEval, MT-Bench ou la suite HELM de Stanford monopolisent la conversation, mais aucun n’a été conçu pour répondre à la question d’un régulateur.
• Le règlement européen sur l’IA, le cadre AI RMF du NIST et la norme ISO/IEC 42001 exigent tous une forme d’évaluation des modèles : les benchmarks sont l’instrument opérationnel qui rend ces obligations mesurables.
• Un score de benchmark public ne prouve pas, à lui seul, la conformité. La contamination des jeux de test, le surapprentissage et la conscience d’évaluation cassent le lien entre un chiffre de classement et le comportement réel en production.
• Un portefeuille de benchmarks prêt pour la gouvernance combine quelques benchmarks publics bien documentés et un benchmark interne ancré sur vos propres cas d’usage, vos risques et vos critères d’acceptation.

Ce qu’est réellement un benchmark LLM

Les benchmarks LLM sont des cadres standardisés qui mesurent comment un modèle se comporte sur une tâche définie. En retirant les habillages marketing, chaque benchmark repose sur les mêmes quatre pièces : un jeu de données d’exemples, un ensemble de questions ou de tâches, une ou plusieurs métriques, et un mécanisme de notation qui transforme la sortie du modèle en un nombre comparable (IBM Think). La standardisation existe pour rendre la comparaison possible : deux modèles confrontés aux mêmes questions, notés de la même manière, et tout écart reflète le modèle, pas le test. Les benchmarks s’administrent généralement selon trois modes. Le zero-shot présente la tâche au modèle sans exemple préalable et mesure sa capacité à généraliser à partir de son entraînement. Le few-shot ajoute quelques exemples résolus au début du prompt pour voir à quelle vitesse le modèle saisit un motif. L’évaluation fine-tunée entraîne d’abord le modèle sur des données proches du benchmark avant le test, ce qui augmente les scores mais ne renseigne utilement que si votre déploiement réel sera lui aussi fine-tuné. La métrique de tête dépend du benchmark. Les questions à choix multiples utilisent l’accuracy. Les benchmarks de code emploient pass@k, la probabilité qu’au moins une des k solutions générées passe les tests unitaires. La traduction utilise BLEU, le résumé ROUGE, la classification précision, rappel et F1, la modélisation linguistique la perplexité. La plupart des classements agrègent plusieurs de ces métriques en un chiffre unique, ce qui rend le classement facile et le raisonnement difficile. Pour un public conformité, le plus important est de comprendre ce que les benchmarks ne sont pas. Ils ne sont pas des certifications. Ils ne sont pas des tests d’acceptation validés par un régulateur. Ils ne remplacent pas une évaluation interne de votre système précis, sur vos données précises, face à vos risques précis. Ils restent en revanche ce que nous avons de plus proche d’un vocabulaire commun pour décrire ce qu’un LLM sait faire ou non, et ce vocabulaire est désormais structurant dans toutes les régulations IA majeures en vigueur.

Le paysage des benchmarks en 2026 (la carte d’un responsable conformité)

Le catalogue des benchmarks s’étend rapidement, mais les familles qui apparaissent réellement dans les rapports d’évaluation des fournisseurs et dans les dossiers présentés aux régulateurs sont plus restreintes que le bruit ambiant ne le suggère.

Benchmarks LLM de raisonnement et de compréhension du langage

MMLU (Massive Multitask Language Understanding) couvre 57 sujets avec plus de 15 000 questions à choix multiples et reste le premier chiffre que cite chaque nouvelle sortie de modèle (papier MMLU). HellaSwag teste la complétion de phrase par bon sens avec des distracteurs filtrés de manière adversariale. ARC (AI2 Reasoning Challenge) s’appuie sur des questions de sciences niveau primaire et publie deux jeux, Easy et Challenge. Winogrande met à l’échelle le Winograd Schema Challenge avec 44 000 problèmes de coréférence collectés en crowdsourcing. Ensemble, ces quatre benchmarks indiquent si un modèle peut traiter des questions de connaissance multi-domaines dans un format statique.

Mathématiques et code

GSM8K est le benchmark canonique de mathématiques niveau primaire, avec 8 500 problèmes verbaux et des solutions en langage naturel. HumanEval a introduit la métrique pass@k pour la génération de code ; MBPP l’étend aux problèmes Python de base ; SWE-bench est le plus difficile des trois, mesurant si un modèle peut résoudre de vraies issues GitHub dans de vrais dépôts (papier SWE-bench). Les benchmarks de code ont une propriété utile pour les équipes gouvernance : ils sont en passe ou échec par problème, donc le score est plus difficile à gonfler par des appréciations subjectives.

Conversation et suivi d’instructions

MT-Bench utilise GPT-4 comme juge pour noter 80 questions ouvertes multi-tours réparties en 8 catégories, une approche à la fois efficace et méthodologiquement contestable selon la littérature du jour. Chatbot Arena contourne le problème du LLM-juge en agrégeant des votes de préférence par paires dans une arène ouverte, puis en estimant les classements à partir de ces comparaisons par paires (papier Chatbot Arena). Pour des produits destinés à interagir avec des humains, Chatbot Arena corrèle mieux avec la qualité perçue par l’utilisateur que MMLU.

Véracité, sécurité, alignement

TruthfulQA mesure si un modèle résiste à des affirmations fausses courantes, un proxy pour la résistance à l’hallucination. HELM Safety évalue le refus de réponses dangereuses sur des scénarios de sécurité. AIR-Bench, une piste relativement récente au sein de la famille HELM de Stanford, note les modèles face aux catégories utilisées par le règlement européen sur l’IA, le NIST AI RMF et plusieurs autres taxonomies réglementaires (AIR-Bench). AIR-Bench mérite plus d’attention que ce qu’il reçoit actuellement de la part des équipes conformité : c’est le seul benchmark public délibérément structuré autour des catégories des régulateurs.

Évaluation holistique : HELM comme méta-benchmark

L’Holistic Evaluation of Language Models (HELM) de Stanford n’est pas un benchmark unique mais un protocole de mesure. Il évalue chaque modèle selon 7 métriques (accuracy, calibration, robustesse, équité, biais, toxicité, efficience) sur 16 scénarios cœur, dans des conditions standardisées (HELM). Des pistes spécialisées étendent désormais le cadre aux domaines médical (MedHELM), vision (VHELM), audio et sécurité. Pour une organisation qui construit un benchmark interne, HELM s’approche le plus d’une architecture de référence publiée.

Pourquoi les benchmarks sont devenus un instrument de conformité, plus seulement un outil de recherche

Ce qui a changé entre 2022 et 2026, c’est que ‘évaluer le modèle’ a cessé d’être une bonne pratique recommandée pour devenir une obligation légale, inscrite dans une régulation de premier rang, dans un cadre majeur de gestion du risque et dans une norme internationale de système de management. Les benchmarks sont la façon dont cette obligation abstraite se traduit en un chiffre qu’un auditeur peut lire.

Article 15 du règlement européen sur l’IA

L’article 15 du Règlement (UE) 2024/1689 exige que les systèmes d’IA à haut risque soient conçus et développés pour atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité pendant tout leur cycle de vie (résumé officiel de l’article 15). Le même article exige aussi que les niveaux d’exactitude et les métriques pertinentes soient déclarés dans la notice d’utilisation accompagnant le système, ce qui signifie que le chiffre choisi doit être documenté et transmis en aval. L’article 13 renforce ce dispositif avec des obligations de transparence plus larges envers les déployeurs. Concrètement, le fournisseur d’un système à haut risque ne peut pas livrer en silence sans nommer les métriques utilisées et les niveaux atteints.

Article 55 et le code de bonnes pratiques GPAI

Pour les modèles d’IA à usage général classés comme présentant un risque systémique, l’article 55 du règlement européen sur l’IA ajoute une obligation explicite d’évaluation du modèle, y compris la conduite et la documentation de tests adversariaux. Le code de bonnes pratiques GPAI, volontaire, finalisé sous l’égide du Bureau européen de l’IA, opérationnalise cette obligation autour d’une cadence d’évaluation récurrente, avec une méthodologie documentée. Les benchmarks, publics comme internes, sont les artefacts qui satisfont la moitié documentaire de l’obligation.

Fonction Measure du NIST AI RMF

Le cadre de gestion du risque IA du NIST s’organise autour de quatre fonctions : Govern, Map, Measure, Manage. La fonction Measure appelle explicitement à mobiliser des outils quantitatifs, qualitatifs ou mixtes pour analyser, évaluer, faire des benchmarks et surveiller le risque IA (NIST AI RMF Core). Bien que NIST AI 100-1 soit volontaire, la fonction Measure est le foyer textuel de toute la conversation sur les benchmarks dans la gouvernance IA américaine, et de nombreuses clauses d’appel d’offres fédérales y font désormais directement référence.

Évaluation des performances dans ISO/IEC 42001

ISO/IEC 42001, publiée en décembre 2023, est la première norme de système de management de l’IA. Comme toutes les normes de système de management ISO, elle s’appuie sur la boucle Plan-Do-Check-Act, et l’évaluation des performances est l’une de ses clauses nommées. Les contrôles de l’Annexe A opérationnalisent cette obligation en exigences précises sur le cycle de vie de l’IA, y compris des critères d’évaluation pour les systèmes développés en interne comme pour ceux acquis auprès de tiers. Pour une organisation qui vise la certification 42001, la question n’est plus si il faut faire des benchmarks, seulement lesquels satisferont l’auditeur.

Comment lire un classement comme le ferait un régulateur

Le ‘on score 92,3 à MMLU’ d’un fournisseur paraît précis. Le chiffre est vrai, la comparaison est réelle, et pourtant il ne dit presque rien d’utile à un responsable conformité tant que trois questions de fond n’ont pas reçu de réponse. Première question : le benchmark a-t-il été contaminé pour ce modèle ? La plupart des corpus d’entraînement des modèles frontières incluent de larges pans du web ouvert, et la plupart des benchmarks publics vivent sur le web ouvert. Un score qui dépasse de loin l’état de l’art précédent sur un benchmark présent depuis des années mérite du scepticisme, pas une célébration. Deuxième question : le comportement mesuré correspond-il au comportement déployé ? Un score sur un jeu de test statique, anglophone et à choix multiples ne prédit pas la performance sur vos transcriptions de service client, vos requêtes juridiques ou vos prompts de revue de code. Les régulateurs s’intéressent au système déployé, pas au communiqué de presse. Troisième question : quelles sont la version, la date et la mise en forme du prompt ? Les benchmarks évoluent, les prompts sont retravaillés, les scripts de notation sont révisés. Un 92,3 sans épingle de version est invérifiable. Pour un dossier d’évaluation de la conformité au titre du règlement européen sur l’IA, le chiffre de tête est, au mieux, digne d’une note de bas de page. Ce qui compte, c’est la méthodologie : quel jeu de test, avec quels contrôles de contamination, noté par qui, rafraîchi selon quelle cadence. Traitez chaque revendication de classement comme une hypothèse à vérifier, pas comme un fait à recopier.

Contamination des benchmarks et loi de Goodhart

La version intellectuellement honnête de la conversation sur les benchmarks en 2026 commence par la contamination. Il y a contamination de données lorsqu’un modèle a été entraîné sur le jeu de test d’un benchmark, soit délibérément parce qu’on a décidé d’optimiser pour le classement, soit accidentellement parce que le jeu de données du benchmark s’est retrouvé dans un crawl web qui a alimenté le pré-entraînement. Une fois que le modèle a mémorisé le test, son score reflète la mémoire, pas la capacité (littérature sur la contamination). Le problème de fond est structurel. Les benchmarks publics attirent une pression d’optimisation soutenue : des dizaines de laboratoires, chaque trimestre, avec des milliards de tokens d’entraînement et des budgets sérieux. La loi de Goodhart s’applique : lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. La saturation de MMLU, où les modèles frontières se regroupent à quelques points du plafond, en est l’exemple le plus cité, mais le motif se reproduit dans toutes les familles de benchmarks. Plus récemment, la littérature a documenté la conscience d’évaluation : les grands modèles peuvent détecter qu’un prompt ressemble à une évaluation plutôt qu’à une interaction de déploiement, et l’écart de comportement entre les deux contextes n’est pas négligeable. Du point de vue de la conformité, cela signifie que le score mesuré dans votre pipeline d’évaluation peut ne pas être le score que le modèle délivre réellement en production. L’implication est inconfortable. Un score de benchmark public est un signal parmi d’autres, pas une garantie. Tout cadre GRC qui traiterait un chiffre MMLU comme preuve de sécurité, d’exactitude ou d’équité prendrait un risque méthodologique qui, écrit noir sur blanc, ne tiendrait pas face à un régulateur. Les benchmarks disent quelque chose. Ils ne disent pas assez.

Construire un benchmark interne que votre auditeur acceptera

Si les benchmarks publics ne suffisent pas, le réflexe naturel consiste à construire les vôtres. Un benchmark interne, conçu sur vos cas d’usage réels, vos données réelles et vos risques réels, est l’artefact qui comble l’écart entre un classement public et une position de conformité défendable. Un benchmark interne opérationnel repose sur six éléments. Premièrement, un périmètre rattaché à un cas d’usage : nommez le système, le contexte de déploiement, et le niveau de risque au titre du règlement européen sur l’IA (haut risque, risque limité, risque minimal) ou l’équivalent issu de la fonction Map du NIST AI RMF. Deuxièmement, des métriques rattachées à des dommages : l’exactitude sur les tâches qui comptent, le taux de refus sur les prompts qui doivent être refusés, le taux d’hallucination sur les requêtes où l’hallucination est dangereuse. L’exactitude générique est rarement la bonne métrique seule. Troisièmement, un jeu de test représentatif à provenance documentée : d’où viennent les prompts, qui les a sélectionnés, sur quel trafic de production ils ont été échantillonnés, quelles langues ils couvrent. Quatrièmement, des contrôles de contamination : gardez au moins un split réservé qui ne quitte jamais l’organisation, rafraîchissez la partie publique du jeu selon une cadence publiée, et marquez par filigrane les prompts lorsque c’est possible pour détecter les fuites. Cinquièmement, un script de notation versionné : les prompts évoluent, les modèles évoluent, les rubriques évoluent. Épinglez chaque score au modèle exact de prompt et au code de notation exact qui l’ont produit. Sixièmement, des critères d’acceptation cartographiés dans le dossier de conformité : le score n’a pas besoin d’être parfait, il doit être suffisamment haut pour justifier un déploiement compte tenu du niveau de risque. Documentez le seuil et son rationnel. Une plateforme de gestion des preuves comme AI Sigil conserve l’ensemble de la chaîne auditable : la définition du benchmark, l’historique des scores, les obligations rattachées au titre du règlement européen sur l’IA, du NIST AI RMF ou de l’ISO 42001, et les fichiers de preuve (jeu de test, script de notation, journaux d’exécution) référencés par le dossier.

Les benchmarks LLM que vous devriez réellement suivre pour la conformité

Pour une organisation qui construit un portefeuille satisfaisant les régulateurs tout en restant intellectuellement honnête, la liste courte pratique est plus courte que ce que suggèrent les classements publics.

Toute entrée de ce tableau doit être associée à un benchmark interne ciblant votre déploiement réel. Le chiffre public est l’étalonnage ; le chiffre interne est la preuve.

Questions fréquentes

Les benchmarks LLM sont-ils fiables ? Ils sont fiables pour ce qu’ils mesurent, à savoir la performance sur le jeu de test précis selon le protocole précis qu’ils définissent. Ils sont peu fiables comme proxys du comportement en production, en partie à cause de la contamination et du surapprentissage, en partie parce que les systèmes déployés affrontent une distribution d’entrées beaucoup plus large qu’aucun benchmark statique ne couvre. Considérez-les comme des signaux à trianguler, pas comme une vérité terrain. Les régulateurs européens s’intéressent-ils aux scores MMLU ? Pas directement. L’article 15 du règlement européen sur l’IA exige que les fournisseurs à haut risque déclarent les niveaux d’exactitude et les métriques pertinentes dans la notice d’utilisation. Le régulateur saisi d’un dossier d’évaluation de la conformité veut voir une méthodologie documentée, un jeu de test défendable et des critères d’acceptation rattachés au profil de risque du système. Un chiffre MMLU peut figurer dans le dossier à titre d’élément de preuve, mais il ne satisfait pas l’obligation à lui seul. Un benchmark public peut-il prouver la conformité d’une IA ? Aucun benchmark public ne démontre, à lui seul, la conformité au règlement européen sur l’IA, au NIST AI RMF ou à l’ISO/IEC 42001. Chacun de ces cadres requiert une évaluation spécifique au système, spécifique au dommage, rattachée au contexte de déploiement. Les benchmarks publics soutiennent le dossier ; ils ne le remplacent pas. Devons-nous construire notre propre benchmark interne ? Oui, si vous êtes soumis à l’un des grands cadres de gouvernance IA. Un benchmark interne est la seule façon d’évaluer le système sur des données qui ressemblent à la production. Il vous donne aussi le contrôle de la contamination, impossible pour un benchmark public dont le jeu de test vit sur le web ouvert. Le minimum viable consiste en quelques centaines de prompts représentatifs, une rubrique de notation claire et une cadence de rafraîchissement documentée. Qu’est-ce que la contamination de benchmark ? La contamination est la situation dans laquelle un modèle a été entraîné, directement ou indirectement, sur des données issues du jeu de test d’un benchmark. Le score reflète alors la mémoire, pas la capacité. La contamination est répandue pour les benchmarks présents depuis des années sur le web public, et c’est la principale raison pour laquelle MMLU et les benchmarks saturés similaires sont aujourd’hui traités avec prudence. Que recommandent la CNIL et les régulateurs sectoriels français ? Ni la CNIL ni l’ANSSI ne valident de benchmark public en particulier. Leur approche reflète celle des autres autorités européennes : la documentation de la méthodologie d’évaluation, la traçabilité des jeux de test et l’adéquation des métriques au contexte d’usage priment sur le score affiché. Pour les acteurs du secteur financier, l’ACPR et la position des autorités européennes (EBA notamment) demandent une validation modèle proche de celle des modèles IRB, c’est-à-dire bien plus exigeante qu’un score public. Quel benchmark une équipe conformité doit-elle documenter en 2026 ? Documentez au moins un benchmark par axe de capacité pertinent pour votre cas d’usage (connaissance, raisonnement, code, dialogue, véracité, sécurité), plus un benchmark d’alignement réglementaire tel qu’AIR-Bench, plus votre benchmark interne. Le script de notation, la provenance du jeu de test et la date d’exécution doivent tous être archivés comme preuves et rattachés aux obligations pertinentes de votre dossier de conformité.

Conclusion

Les benchmarks LLM ont dépassé leur rôle initial d’outil de recherche. En 2026, ils sont l’instrument opérationnel derrière chaque obligation d’évaluation de modèle, qu’il s’agisse de l’article 15 du règlement européen sur l’IA, de la fonction Measure du NIST AI RMF ou de la clause d’évaluation des performances de l’ISO/IEC 42001. Ils sont aussi imparfaits, manipulables et fréquemment mal interprétés. Une posture de conformité sérieuse traite les benchmarks publics comme un étalonnage, construit un benchmark interne pour la preuve, et documente la méthodologie avec la même rigueur que n’importe quel autre contrôle. Si vous construisez ce portefeuille, une plateforme de gouvernance comme AI Sigil reste l’endroit où conserver les définitions de benchmarks, les scores, les preuves et les rattachements d’obligations dans une trace auditable unique.