Benchmark IA : transformer les scores en preuves d’audit

L’essentiel

• Un benchmark IA mesure la performance d’un modèle sur un jeu de tâches figé, selon une règle de notation connue. Il répond à la question « quel modèle est le plus fort sur ce test », pas à celle de l’adéquation à votre destination prévue.
• Le règlement européen sur l’IA impose aux fournisseurs de systèmes à haut risque de déclarer leurs métriques d’exactitude dans la notice d’utilisation. L’obligation porte sur votre métrique, pas sur le classement d’un tiers.
• Les scores publics perdent leur valeur probante : les tests les plus cités sont saturés, et leurs questions publiées finissent dans les corpus d’entraînement.
• Un résultat ne devient une preuve que si vous pouvez établir ce qui a été exécuté, sur quelles données, contre quelle version de modèle, par qui et à quelle date.
• La preuve qui résiste à un audit provient presque toujours d’un jeu de test interne dérivé de la destination prévue, pas d’un classement public.

Ce qu’un benchmark IA mesure réellement

Un benchmark IA est un test normalisé : un jeu de données d’entrée figé, des sorties attendues, et une règle de notation qui convertit le comportement du modèle en un nombre comparable. La pratique consiste à exécuter des modèles contre ces tests, puis à interpréter ce qui en ressort. Comme tous les modèles affrontent les mêmes entrées sous la même règle, le benchmark transforme une impression en une valeur que deux interlocuteurs peuvent contester avec les mêmes faits sous les yeux. C’est réellement utile, et c’est précisément là que les ennuis commencent. Un benchmark est un échantillon fini tiré d’une distribution. Le travail auquel vous destinez un modèle d’IA relève d’un ensemble ouvert de situations tirées d’une distribution beaucoup plus désordonnée. Le score reste toujours un indicateur indirect, et l’écart entre cet indicateur et ce qui vous importe n’est jamais imprimé sur le classement.

Les trois composants d’un benchmark

Chaque benchmark comporte trois éléments, et chacun peut défaillir indépendamment des autres.

• Le jeu de données : les entrées, et le plus souvent les sorties de référence servant à la notation.
• La méthode d’évaluation : la règle qui convertit les sorties en score. Appariement de réponses pour les questionnaires à choix multiples, exécution de tests unitaires pour le code, ou juge algorithmique pour les productions ouvertes.
• Le classement : le tableau qui rend les résultats comparables et, accessoirement, dignes d’être manipulés.

La vérité de référence mérite une attention particulière, car elle plafonne silencieusement tout ce qui repose sur elle. Si le corrigé est faux, une bonne réponse du modèle est comptée comme une erreur, et l’ensemble du résultat hérite de ce bruit.

Les familles de capacités et leurs angles morts

Aucun test isolé ne rend compte de ce qu’un modèle sait faire. La discipline découpe donc l’évaluation par capacité, et seule une lecture transversale donne une image honnête.

• Connaissances (MMLU, MMLU-Pro) : étendue du rappel factuel. Le MMLU original est largement saturé, si bien que les écarts entre modèles de pointe ne portent plus aucun signal.
• Raisonnement (GPQA Diamond, Humanity’s Last Exam) : résolution en plusieurs étapes sur des questions délibérément difficiles. Difficiles aujourd’hui, cibles de contamination demain.
• Code (SWE-bench Verified, LiveCodeBench) : correction de tickets réels dans un dépôt plutôt que rédaction de fonctions isolées. Les tests au niveau de la fonction ont perdu l’essentiel de leur pouvoir discriminant.
• Agents (GAIA) : planification et usage d’outils sur plusieurs étapes. Les résultats dépendent autant de l’échafaudage autour du modèle que du modèle lui-même.
• Multimodal (MMMU) : raisonnement sur du texte, des images et des schémas. Un modèle textuel solide peut y obtenir un score médiocre.
• Préférence humaine (Arena Elo) : quelle réponse les gens préfèrent en comparaison aveugle. Cela mesure la préférence et le style, non l’exactitude, et les deux divergent plus souvent que le classement ne le laisse croire.

Pour les équipes travaillant spécifiquement sur les modèles de langage, le détail famille par famille figure dans notre guide des benchmarks LLM. Ce qui suit vaut pour toute classe de modèle.

Quand le score devient une obligation réglementaire

La littérature traite le benchmark IA comme une habitude d’ingénierie. Pour quiconque met un système sur le marché européen, il s’apparente davantage à une obligation documentaire, et ce changement de cadre modifie ce qu’est un bon benchmark.

Article 15 : déclarer sa métrique d’exactitude

L’article 15 du règlement européen sur l’IA impose aux systèmes à haut risque d’atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité, et de se comporter de manière constante à cet égard tout au long de leur cycle de vie. La phrase décisive pour les équipes gouvernance est la suivante : les niveaux d’exactitude et les métriques d’exactitude pertinentes doivent être déclarés dans la notice d’utilisation. Cette formulation inverse le réflexe habituel. L’obligation n’est pas de bien figurer sur un test public reconnu. Elle consiste à nommer la métrique que vous jugez pertinente pour votre système, à énoncer le niveau que vous atteignez, et à assumer les deux. Une position dans un classement ne libère pas de cette obligation, et la citer à la place de votre propre mesure constitue une lacune qu’un évaluateur repère vite. Le texte anticipe néanmoins des référentiels partagés. Il charge la Commission, en coopération avec les parties prenantes et des organisations telles que les autorités de métrologie et d’étalonnage, d’encourager le développement de référentiels et de méthodes de mesure. Ce chantier est en cours plutôt qu’abouti, et la charge du choix et de la justification de la métrique repose donc sur le fournisseur. L’article 15 s’applique à compter du 2 août 2026, échéance qui tombe dans l’horizon de planification décrit dans notre guide opérationnel du règlement IA.

Modèles à usage général : article 55 et code de bonnes pratiques

Les fournisseurs de modèles à usage général portent une obligation d’évaluation distincte et bien plus explicite. Le code de bonnes pratiques GPAI publié par le Bureau européen de l’IA en juillet 2025 impose aux fournisseurs de modèles présentant un risque systémique, seuil actuellement fixé à une puissance de calcul d’entraînement supérieure à 10^25 FLOPs, de maintenir un cadre de sûreté et de sécurité couvrant les évaluations de modèle, les exercices d’équipe rouge, la surveillance après commercialisation, la cybersécurité et le signalement d’incidents. L’évaluation n’est plus ici un exercice de comparaison. C’est une argumentation de sûreté, et elle doit être entretenue après la mise sur le marché plutôt que produite une fois au lancement. Les déployeurs qui bâtissent sur ces modèles en héritent les conséquences, raison pour laquelle notre note sur l’IA à usage général traite les preuves d’évaluation du fournisseur comme une donnée d’achat et non comme une curiosité technique.

ISO 42001 et NIST AI RMF : la lecture système de management

Deux référentiels volontaires font passer le benchmark du statut d’activité à celui de processus gouverné. ISO/IEC 42001 place l’évaluation des performances dans un système de management certifiable. Dès lors qu’une campagne de mesure relève du chapitre 9, elle cesse d’être une diapositive pour devenir un enregistrement doté d’un responsable, d’une périodicité et d’une piste d’audit. Le NIST AI Risk Management Framework est plus direct. Sa fonction MEASURE applique métriques, référentiels, tests et analyses aux caractéristiques de confiance, et appelle à un étalonnage régulier du système comme de la pratique de gestion des risques qui l’entoure. Les travaux du NIST sur les processus de test, d’évaluation, de vérification et de validation posent l’exigence sans détour : ces processus doivent être objectifs, reproductibles ou industrialisables, en place, suivis et documentés, et respecter les normes scientifiques, juridiques et éthiques dans un cadre ouvert et transparent. Cette phrase est la meilleure spécification d’un benchmark défendable que quiconque ait écrite. Observez ce qu’elle ne dit pas : rien sur le test à exécuter, et tout sur la capacité d’un tiers à le rejouer et à retrouver le même résultat.

Pourquoi un score public constitue une preuve faible

Le procès des scores publiés n’a rien d’une posture contrariante. Il vient de la littérature de l’évaluation elle-même.

Saturation et contamination

Les tests les plus cités sont saturés. Les modèles de pointe se regroupent à un ou deux points les uns des autres, et l’écart résiduel tient souvent à des questions ambiguës ou mal étiquetées plutôt qu’à une différence de capacité. Un examen où tout le monde obtient la meilleure note ne peut plus remplir sa seule fonction. La contamination pose un problème plus aigu. Les référentiels sont publiés ouvertement pour que la communauté puisse les reproduire, ce qui envoie leurs questions et leurs réponses dans les corpus web servant à entraîner la génération suivante. Un modèle ayant effectivement vu le test pendant son entraînement le réussira sans généraliser. Les travaux de synthèse sur la contamination le formulent crûment : le score mesure la mémorisation et non la capacité, et le classement ne permet pas de faire la différence.

Loi de Goodhart et validité de construit

Quand une mesure devient un objectif, elle cesse d’être une bonne mesure. Dès lors qu’un référentiel devient le chiffre que les laboratoires mettent en avant et sur lequel les acheteurs filtrent, l’incitation glisse de la construction de meilleurs modèles vers l’obtention de meilleurs scores. Le phénomène est documenté. Une méta-revue interdisciplinaire associée au Centre commun de recherche de la Commission européenne, Can We Trust AI Benchmarks?, recense neuf problèmes systémiques du benchmarking, parmi lesquels des incitations mal alignées, des défauts de validité de construit et des risques de manipulation. La validité de construit est le plus discret : elle demande si un test mesure bien ce qu’il prétend mesurer, et une part surprenante des référentiels publiés ne peut pas l’établir. Le manuel Benchmarks 101 d’Aspen Digital propose une typologie des défaillances en trois volets : données de mauvaise qualité, conception ou mesure défectueuse, résultats mal interprétés. Son exemple mérite d’être gardé en tête au prochain score spectaculaire. Des chercheurs ont établi qu’environ 30 % des questions de biologie et de chimie de Humanity’s Last Exam, référentiel pourtant conçu pour être difficile, appelaient des réponses fausses ou indéfendables.

L’écart entre le laboratoire et le terrain

Un benchmark mesure en laboratoire, pas en conditions réelles. Il intervient aussi plus tôt dans le cycle de vie qu’on ne l’imagine, lors de la définition des objectifs et de la construction du modèle, alors que l’analyse d’impact et les exercices d’équipe rouge viennent ensuite, une fois qu’il existe un système à sonder. Les conséquences ne sont pas théoriques. Aspen Digital documente des modèles de dermatologie évalués sur le jeu de données de l’International Skin Imaging Collaboration : leur score global était élevé, et leur performance se dégradait nettement sur les peaux foncées dès lors que les métriques étaient ventilées par phototype. Le chiffre agrégé était exact et la conclusion qu’on en tirait était fausse. Cet exemple trace la frontière dont traite cet article. Un score de capacité ne vaut pas assurance en matière de droits fondamentaux, et aucune quantité de score ne remplace les tests ventilés décrits dans notre guide des biais de l’IA. L’évaluation de l’équité est une obligation distincte, dotée d’une méthode distincte, et non une sous-partie de la mesure de performance.

Ce qu’un benchmark peut et ne peut pas prouver

Les équipes gouvernance ont besoin d’une frontière applicable sans rouvrir le débat scientifique à chaque fois. Voici la nôtre.

Un benchmark PEUT prouver	Un benchmark NE PEUT PAS prouver
Une capacité relative sur une tâche définie, à un instant donné	L’adéquation à votre destination prévue
Une régression entre deux versions de modèle sur un jeu interne figé	À lui seul, la métrique d’exactitude déclarée exigée par l’article 15
Qu’une procédure de mesure documentée et reproductible existe et a été suivie	L’absence d’impact discriminatoire sur les groupes concernés
Un filtre de présélection utilisé pour établir une liste restreinte	La résistance aux entrées adverses ou hors distribution
La progression agrégée d’une capacité dans le temps	Le maintien de la performance après une mise à jour silencieuse côté fournisseur
Qu’une affirmation précise a été testée et non simplement avancée	À lui seul, la conformité à un quelconque référentiel

La lecture tient en une phrase. Un benchmark n’est recevable comme preuve que si vous pouvez établir ce qui a été exécuté, sur quelles données, contre quelle version de modèle, par qui et à quelle date. Tout ce qui figure dans la colonne de gauche dépend de l’existence de cet enregistrement. Rien dans la colonne de droite ne devient vrai parce qu’un score était élevé. Là où le benchmark ne peut pas porter la charge, elle retombe sur les contrôles décrits dans notre guide de la gestion des risques liés à l’IA.

Construire un benchmark interne qui tient devant un auditeur

La conclusion pratique de tout ce qui précède est que le benchmark qui mérite un investissement est en général celui que vous construisez.

Partir de la destination prévue, pas du classement

La destination prévue est la notion pivot du règlement européen, et c’est le bon point de départ pour un jeu de test. Écrivez ce à quoi sert le système, qui il affecte, et ce que coûte une réponse fausse dans chaque cas. Rassemblez ensuite des entrées réelles, y compris les plus ingrates : les demandes ambiguës, les cas limites, les saisies mal formées. Ce travail dépasse la lecture d’un classement, et l’évaluation obtenue ne se généralisera pas au-delà de votre cas d’usage. C’est bien l’objectif. Un modèle en tête d’un référentiel public et médiocre sur votre tâche reste le mauvais modèle pour votre déploiement, quels que soient ses scores.

Provenance des données et jeux réservés

Trois propriétés séparent un jeu de test fiable d’un jeu qui vous égare sans bruit.

1. Le modèle n’a pas vu les données. Utilisez des données réservées, générées pour l’occasion, ou postérieures à la date de coupure de l’entraînement. À défaut, vous mesurez de la mémorisation.
2. Les données reflètent votre domaine réel. Du texte web générique ne dit rien de la façon dont un modèle traite des comptes rendus cliniques, des dossiers de crédit ou des tickets internes, dont le vocabulaire, la structure et l’ambiguïté n’ont rien de commun avec un paragraphe d’encyclopédie.
3. La vérité de référence est réellement exacte. Chaque score se mesure contre un corrigé, et un corrigé fautif plafonne un bon modèle tout en récompensant les mauvais comportements.

Ces exigences s’opposent entre elles, et mieux vaut le dire franchement. Les données les plus réalistes sont en général les plus sensibles, donc impubliables, et les publier contaminerait de toute façon les modèles suivants. L’étiquetage manuel à grande échelle introduit exactement les erreurs de référence que la troisième propriété cherche à éviter. Les équipes s’en sortent par la génération synthétique, une pseudonymisation soignée, ou des jeux étroits mais rigoureusement curés. Aucune option n’échappe entièrement à l’arbitrage.

Versionnage, reproductibilité et conservation

La répétabilité et la reproductibilité ne relèvent pas ici du confort d’ingénierie. Le cadre de test AI Verify en fait un principe de gouvernance à part entière et structure chaque contrôle en trois temps : le résultat visé, le processus, et la preuve qui le valide. Ce triptyque recouvre exactement ce qu’un évaluateur réclamera. Une campagne de mesure doit laisser derrière elle un enregistrement comprenant au minimum :

• le protocole de test et la règle de notation
• la version du jeu de données et son empreinte
• l’identifiant du modèle, sa version et le point d’accès utilisé
• l’environnement d’exécution, les paramètres, et le caractère zéro-shot ou few-shot de la campagne
• la date, l’opérateur, et les sorties brutes conservées à côté du score calculé
• la durée de conservation et l’emplacement des artefacts

Cette liste est ce qui transforme un nombre en artefact. C’est aussi ce qui sépare un système auditable d’un système ayant simplement bien performé une fois, distinction développée dans notre article sur l’auditabilité de l’IA. Ces enregistrements appartiennent à la documentation technique exigée par le règlement IA, et non à un répertoire séparé détenu par l’équipe data.

Comment interroger les scores annoncés par un fournisseur

Les tableaux de benchmark sont la première preuve que tout fournisseur met en avant, et ils sont rarement contestés. Sept questions suffisent à faire l’essentiel du travail.

1. Quelle règle de notation, et correspond-elle à notre comparaison ? Exactitude, pass@k et Elo ne sont pas interchangeables. Un pass@1 et un pass@10 pour un même modèle ne mesurent pas la même chose, et un écart Elo décrit un taux de victoire en duel, pas un pourcentage de capacité.
2. Zéro-shot ou few-shot ? Les chiffres few-shot sont systématiquement plus élevés.
3. Jeu complet ou sous-ensemble vérifié ? Les sous-ensembles relus par des humains, purgés des items défectueux, produisent des chiffres plus propres et plus flatteurs.
4. Qui a mené l’évaluation ? Un score produit par le fournisseur sur son propre environnement n’est pas comparable à une mesure indépendante.
5. Le jeu de test est-il public, et a-t-il pu fuiter dans l’entraînement ? Un fournisseur qui n’a pas examiné la contamination livre un score inexploitable.
6. À quelle date la mesure a-t-elle été faite, au regard de la version servie aujourd’hui par l’API ? Les fournisseurs mettent à jour leurs modèles silencieusement derrière des noms d’API stables.
7. Accepteriez-vous de rejouer la campagne sur notre jeu réservé, sous accord de confidentialité ? La réponse à celle-ci est la plus instructive de toutes.

Un fournisseur incapable de répondre vous demande d’accepter un argument commercial comme artefact d’assurance. C’est un constat de risque tiers, pas une note de bas de page technique, et il relève de la même évaluation que les questions de plateforme traitées dans notre comparatif des outils de gouvernance IA.

Questions fréquentes

Qu’est-ce qu’un benchmark IA ? Un benchmark IA est un test normalisé, composé d’un jeu de données figé et d’une règle de notation, qui produit des chiffres de performance comparables entre modèles. On y recourt pour comparer des candidats, suivre la progression entre versions et détecter les régressions. Il mesure la performance sur les tâches du test, lesquelles peuvent ressembler ou non à celles qui vous importent. Le règlement européen sur l’IA impose-t-il de réaliser des benchmarks ? Pas en ces termes. L’article 15 exige des systèmes à haut risque un niveau approprié d’exactitude, de robustesse et de cybersécurité, une performance constante sur le cycle de vie, et la déclaration des niveaux et des métriques d’exactitude pertinentes dans la notice d’utilisation. Cela suppose une pratique de mesure défendable, sans prescrire de référentiel public nommé. Le texte charge par ailleurs la Commission d’encourager le développement de référentiels et de méthodes de mesure avec les autorités de métrologie et d’étalonnage, chantier toujours en cours. Les fournisseurs de modèles à usage général présentant un risque systémique portent une obligation d’évaluation plus explicite au titre de l’article 55 et du code de bonnes pratiques GPAI. Les benchmarks publics gardent-ils une utilité ? Oui, comme premier filtre et non comme verdict. Ils réduisent vite un champ de candidats et révèlent les faiblesses grossières. Ils ne disent rien du comportement d’un modèle sur vos données, dans votre domaine, sous vos contraintes, et la saturation comme la contamination ont creusé cet écart. Traitez une position de classement comme une hypothèse à vérifier. Qu’est-ce que la contamination des données de test ? Il y a contamination lorsque les questions et les réponses d’un référentiel figurent dans les données d’entraînement d’un modèle. Comme les référentiels sont publiés ouvertement pour la reproductibilité, ils sont couramment aspirés dans les corpus d’entraînement. Un modèle contaminé restitue des réponses mémorisées et affiche un score élevé qui s’effondre sur des problèmes inédits du même type. Le phénomène est difficile à détecter, rarement déclaré, et constitue la principale raison de la dérive entre scores publics et performance réelle. En quoi un benchmark diffère-t-il d’un audit IA ? Un benchmark mesure la performance d’un modèle sur une tâche définie. Un audit IA examine le système et l’organisation autour de lui : gouvernance, gestion des risques, provenance des données, supervision humaine, documentation et preuves à l’appui de chaque affirmation. Les résultats de benchmark alimentent l’audit. Pris isolément, ils répondent à une question technique étroite, et l’auditeur demandera comment la campagne a été conçue, versionnée et conservée avant d’accepter le chiffre. Combien de benchmarks exécuter sur un système à haut risque ? Moins que ce que les équipes imaginent, mais mieux choisis. Un jeu de test interne dérivé de la destination prévue vaut mieux que cinq référentiels publics, car c’est le seul dont les résultats parlent d’adéquation à l’usage. Ajoutez une évaluation de l’équité avec des résultats ventilés par groupe concerné, et un test de résistance couvrant les entrées adverses et hors distribution. Ces trois campagnes, versionnées et reproductibles, constituent un dossier plus solide que n’importe quel florilège de classements.

Conclusion

Le benchmark IA n’est pas défaillant, il est mal classé. Traité comme un exercice de palmarès, il produit du théâtre d’achat : un tableau de chiffres que personne ne peut rejouer, mesurant des tâches que personne dans la salle n’a examinées, sur des versions de modèles depuis remplacées. Traité comme une pratique de mesure, il produit quelque chose qu’un évaluateur peut réellement utiliser. Le basculement est modeste et surtout organisationnel. Dérivez le test de la destination prévue. Réservez les données. Consignez le protocole, les versions, l’opérateur et la date. Rangez les artefacts là où vit le reste du dossier technique. Énoncez clairement ce que le résultat ne prouve pas. Cette dernière discipline compte plus que les autres. La position la plus solide devant un régulateur n’est pas un score élevé. C’est une mesure documentée, un énoncé honnête de ses limites, et des contrôles couvrant tout ce que la mesure laisse ouvert. Rattacher ces enregistrements aux contrôles qu’ils étayent, plutôt que de les disperser entre présentations et carnets de notes, constitue le travail concret d’un cadre de gouvernance de l’IA.