Benchmarks IA : le guide pour décoder les scores des modèles

Chaque lancement de modèle d'IA s'accompagne désormais d'un mur de scores : SWE-Bench Pro, Terminal-Bench 2.1, GPQA Diamond, Humanity's Last Exam, AutomationBench, GDPval... Des noms obscurs, des pourcentages, des graphiques en barres. Pour un dirigeant, la question est simple : qu'est-ce que tout cela veut dire, et qu'est-ce que ça change pour moi ?

Voici le décodeur. Pas une liste de plus, mais ce que mesure réellement chaque grand benchmark, et surtout comment lire un score sans se faire avoir.

L'enjeu est concret : choisir un modèle, ou un fournisseur, sur le mauvais chiffre, c'est risquer de bâtir un projet entier sur une performance qui n'existe pas chez vous. Savoir lire ces scores, c'est distinguer le progrès réel du marketing.

D'abord, qu'est-ce qu'un benchmark ?

Un benchmark, c'est un examen standardisé pour modèles d'IA : un ensemble figé de questions ou de tâches, plus une méthode de notation automatique. L'intérêt est de comparer plusieurs modèles dans les mêmes conditions, et de suivre les progrès dans le temps.

Il en existe deux grandes familles. Les examens de connaissance et de raisonnement (des questions à réponse vérifiable), et les tests d'agents (on confie au modèle une vraie tâche, et on note le résultat final, pas le chemin). Les seconds sont devenus les plus intéressants, parce qu'ils se rapprochent du travail réel.

Un piège classique avant même de commencer : ne confondez pas un benchmark et un modèle. Le benchmark mesure ; le modèle est mesuré. Un benchmark de code comme DeepSWE définit les épreuves ; des modèles comme Claude, GPT ou Gemini sont ce qu'on y évalue.

En un coup d'œil

Avant le détail, une vue d'ensemble des benchmarks les plus cités et de ce qu'ils mesurent réellement :

À quoi ça ressemble, concrètement ?

Les noms restent abstraits tant qu'on n'a pas vu une épreuve. Trois exemples pour fixer les idées :

• Une question de GPQA Diamond porte par exemple sur un mécanisme précis de chimie organique ou de physique, formulée pour qu'aucune recherche web ne donne la réponse : il faut le raisonnement d'un spécialiste. Un non-expert avec accès à internet échoue ; les experts du domaine atteignent environ 65 %.
• Une tâche de SWE-bench part d'un vrai ticket d'un projet open-source (« tel comportement est incorrect dans telle bibliothèque Python »). Le modèle reçoit le dépôt, doit trouver les fichiers concernés et produire un correctif qui fait repasser une suite de tests cachée. Pas de QCM : ça marche ou ça ne marche pas.
• Une tâche d'OSWorld ressemble à « ouvre ce tableur, filtre les ventes du trimestre et exporte un PDF ». L'agent doit cliquer, taper et naviguer entre des applications réelles ; on vérifie l'état final de la machine, pas les étapes. L'humain réussit environ 72 % de ces tâches, les modèles bien moins.

Comment un score est calculé : sortie vérifiable ou réponse jugée

C'est le cœur d'un benchmark, et la colonne la plus importante du tableau ci-dessus (« Type de score »). Il existe deux grandes façons de noter une réponse, et elles n'ont pas la même valeur de preuve.

1. La sortie est vérifiable, contrôlée par du code. Il y a une bonne réponse vérifiable automatiquement : un test passe ou échoue, la réponse exacte est connue, l'état final du système est correct ou non. C'est le cas de SWE-bench (le correctif fait-il passer les tests ?), de GPQA (la bonne réponse est connue) ou d'AutomationBench (les bons systèmes sont-ils dans le bon état ?). Avantage : objectif, reproductible, non négociable. C'est le score auquel on peut le plus se fier.

2. La réponse est jugée, par des humains ou par une autre IA. Pour les tâches ouvertes (un e-mail, un rapport, une conversation de santé, « ce code serait-il accepté par un mainteneur ? »), il n'existe pas de réponse unique vérifiable par un test. On fait alors appel à des experts humains (GDPval, HealthBench) ou, de plus en plus, à un autre modèle qui note à leur place : c'est le fameux « LLM-as-a-judge » (un modèle qui en juge un autre). C'est plus souple, mais cela introduit des biais connus : un modèle-juge tend à préférer les réponses longues, son propre style, ou la première réponse présentée. Et faire corriger une IA par une IA reste, par construction, un peu circulaire.

Combien d'essais ? pass@1, pass@k, pass^k. Un même modèle n'affiche pas le même score selon le nombre de tentatives autorisées, et ces notations reviennent partout dans les classements de code. pass@1 : un seul essai, le score est le pourcentage de tâches réussies du premier coup, soit ce que vous obtenez réellement en production (une requête, une réponse). pass@k : on autorise k essais et la tâche compte comme réussie si au moins un aboutit ; le score monte donc mécaniquement avec k, si bien qu'un « pass@10 » impressionnant peut masquer un pass@1 médiocre. pass^k (lu « pass-hat-k ») mesure l'inverse, la fiabilité : la tâche ne compte que si les k essais réussissent tous. Un agent qui ne réussit qu'une fois sur deux est inutilisable au quotidien, et c'est précisément ce que pénalise τ-bench pour le service client.

Pour un décideur, la règle est simple : un score vérifiable vaut plus qu'un score jugé. Quand un fournisseur annonce un pourcentage, demandez comment il est calculé. Un 90 % validé par des tests automatiques est une preuve ; un 90 % attribué par un modèle-juge est un avis, utile mais à pondérer. Et pour vos propres évaluations internes, exigez des critères vérifiables (« la facture est-elle correctement extraite, oui ou non ? ») plutôt qu'une impression générale.

Connaissance et raisonnement : les « examens »

• MMLU (2020) : le grand classique. Environ 16 000 questions à choix multiple dans 57 matières. Longtemps la référence « culture générale », il est aujourd'hui saturé (les meilleurs modèles dépassent 90 %) et ne sépare plus les modèles de pointe. Sa version durcie, MMLU-Pro, passe à 10 choix par question pour rester discriminante.
• GPQA Diamond (2023) : 198 questions de sciences de niveau doctorat (biologie, physique, chimie), conçues pour être « anti-Google » (même un non-spécialiste avec accès au web échoue). Les experts du domaine tournent autour de 65 %. Attention : 198 questions, c'est peu, donc le score est bruité et la contamination guette.
• Humanity's Last Exam (2025) : ~3 000 questions extrêmement difficiles dans plus de 100 disciplines, écrites par des experts pour rester au-delà de la portée des modèles. À son lancement, les meilleurs plafonnaient à quelques pour cent. C'est un test de connaissance pure, pas d'utilité concrète.

Code et ingénierie logicielle

C'est la catégorie la plus suivie, car la plus économiquement parlante.

• SWE-bench (2023) et sa version vérifiée par des humains, SWE-bench Verified (500 tâches) : on donne au modèle un vrai ticket GitHub et un dépôt de code, il doit produire le correctif qui fait passer les tests. Le score = % de tickets résolus. Devenu si populaire qu'il a été « gamé » : des tests qui fuitaient gonflaient les scores, au point qu'OpenAI a cessé de le mettre en avant fin 2025.
• SWE-Bench Pro (2025) : la version dure, pensée pour l'entreprise. 1 865 problèmes nécessitant des modifications sur de nombreux fichiers. Révélateur : les meilleurs modèles y tombent à ~23 %, contre 70 %+ sur Verified. Même tâche, barre plus haute, scores qui s'effondrent.
• DeepSWE (2026, par Datacurve) : 113 tâches d'ingénierie logicielle originales, écrites de zéro (donc sans contamination) sur 91 dépôts et 5 langages, conçues pour départager les agents sur des tâches longues. Les solutions exigent environ 5,5 fois plus de code que des benchmarks comparables malgré des énoncés plus courts. Score en pass@1. Son classement illustre bien un piège de décideur : le modèle en tête (Fable 5, 70 %) coûte ~21 $ par tâche, là où le deuxième (GPT-5.5, 67 %) fait presque aussi bien pour ~7 $, soit trois fois moins cher pour 3 points d'écart. Le n°1 d'un classement est rarement le meilleur rapport qualité-prix.
• Terminal-Bench (v2.1) : 89 tâches où l'agent doit piloter un vrai terminal (admin système, traitement de données, sécurité). Peu de tâches, donc chaque correction d'énoncé fait bouger le classement, d'où la version 2.1.
• ProgramBench (2026) : reconstruire un logiciel à partir du seul binaire et de sa documentation, sans code source ni internet. 200 tâches, jugées par des centaines de milliers de tests automatiques. Les modèles de pointe y sont proches de 0 %.
• FrontierCode (2026, par Cognition) : ne demande pas seulement « est-ce que ça passe les tests », mais « est-ce que ce code serait accepté par un mainteneur humain » (qualité, absence de régression, style du dépôt). Sur son palier le plus dur (« Diamond », 50 tâches), même les meilleurs modèles restent sous 15 %.

Agents : outils et ordinateur

• τ-bench (tau-bench, 2024) : conversations de service client multi-tours où l'agent doit parler à un utilisateur simulé, appeler des outils (API) et respecter des règles internes. Son apport : la métrique pass^k, qui mesure la fiabilité (réussir la même tâche k fois de suite), pas juste un coup de chance.
• AutomationBench (2026, par Zapier) : de vrais workflows métier inter-applications via API (ventes, support, finance, RH). On ne note que le résultat final dans les bons systèmes, pas le raisonnement.
• OSWorld (et OSWorld-Verified) : l'agent pilote un vrai ordinateur (clics, clavier, applications réelles) pour accomplir des tâches ouvertes. 369 tâches, notées sur l'état final de la machine. L'humain tourne à ~72 %, les modèles bien en dessous : loin d'être saturé.

Métiers et domaines

• GDPval (2025, par OpenAI) : 1 320 vraies tâches de 44 métiers (livrables réels : présentations, analyses, tableurs). Pas de % de bonnes réponses, mais un taux de préférence face à des livrables d'experts humains. La variante GDPval-AA est une ré-implémentation indépendante d'Artificial Analysis avec un classement Elo.
• HealthBench (2025, par OpenAI) : 5 000 conversations de santé réalistes, notées selon des grilles écrites par des médecins. La version Professional (2026) cible l'usage par les cliniciens.
• Legal Agent Benchmark (2026, par Harvey) : des missions juridiques complètes, notées « tout ou rien » sur chaque critère. Les meilleurs scores restent à quelques pour cent.
• BioMysteryBench (2026, par Anthropic) : de la vraie recherche en bio-informatique sur des données brutes. À noter : benchmark publié par Anthropic pour évaluer ses propres modèles.
• ExploitBench (2026) : jusqu'où un agent de cybersécurité grimpe « l'échelle » de l'exploitation logicielle, du simple plantage jusqu'à l'exécution de code.
• Blueprint-Bench : raisonnement spatial, transformer ~20 photos d'un logement en plan 2D correct. La plupart des modèles font à peine mieux que le hasard.

Comment lire un score sans se faire avoir

Maintenant le plus important. Quelques réflexes :

1. Un score élevé peut juste signifier que le test est saturé. 92 % sur MMLU ne distingue plus rien. Regardez les benchmarks durs (et récents), pas ceux que tout le monde « maxe ».
2. Les scores ne sont pas comparables entre eux. 90 % d'exactitude sur un QCM, un taux de préférence sur GDPval, un pass^k de fiabilité sur τ-bench, un « tout ou rien » sur FrontierCode : ce ne sont pas la même chose. Un « 13 % » sur un test dur peut valoir mieux qu'un « 90 % » sur un test facile.
3. Petit jeu de tests = score bruité. 198 questions (GPQA Diamond), 89 tâches (Terminal-Bench) : quelques énoncés mal calibrés suffisent à bouger un classement.
4. Regardez qui a écrit le benchmark. Plusieurs sont publiés par l'éditeur du modèle évalué (Anthropic pour BioMysteryBench) ou par un fournisseur (Harvey pour le Legal Agent Benchmark). Ce n'est pas disqualifiant, mais cela appelle un regard critique.
5. La contamination existe. Si les réponses ont fuité dans les données d'entraînement, le score est faussé. C'est arrivé à SWE-bench Verified.
6. Ils sont en anglais et génériques. Quasiment tous ces tests sont rédigés en anglais, sur des tâches standard (sciences, tickets open-source). Un bon score n'y présage rien de la performance sur vos documents en français et dans votre métier : voyez-les comme un point de départ, pas comme un verdict.

Et surtout, le point qui change tout pour une PME : aucun benchmark ne mesure votre cas d'usage, sur vos données. Un modèle premier sur SWE-Bench peut buter sur votre base de code héritée ; un champion de HealthBench peut ne pas coller à vos protocoles. Le benchmark est une indication générale, pas une preuve de performance chez vous.

Questions fréquentes

C'est quoi un benchmark IA ?

Un examen standardisé (questions ou tâches figées et notation automatique) qui permet de comparer les modèles d'IA dans les mêmes conditions.

Un bon score sur un benchmark garantit-il de bonnes performances dans mon entreprise ?

Non. Un benchmark mesure des tâches génériques, pas votre cas d'usage sur vos données. Un modèle premier d'un classement peut décevoir sur votre base de code ou vos documents : il faut tester en conditions réelles.

Quel benchmark regarder pour le développement logiciel ?

SWE-bench et sa version difficile SWE-Bench Pro pour la résolution de tickets, Terminal-Bench pour le pilotage d'un terminal. Privilégiez les versions récentes et difficiles plutôt que les benchmarks saturés.

Pourquoi les scores ne sont-ils pas comparables d'un benchmark à l'autre ?

Parce qu'ils ne notent pas la même chose : pourcentage d'exactitude, taux de préférence, fiabilité pass^k ou tout-ou-rien. Un 13 % sur un test dur peut valoir mieux qu'un 90 % sur un test saturé.

Comment un benchmark note-t-il les réponses : vérification ou jugement ?

De deux façons. Soit la réponse est vérifiable automatiquement (un test passe, la bonne réponse est connue, l'état final est correct), soit elle est jugée par des humains ou par une autre IA (« LLM-as-a-judge ») pour les tâches ouvertes. Un score vérifié par du code est une preuve ; un score attribué par un modèle-juge reste un avis, à pondérer.

Que veulent dire pass@1, pass@k et pass^k ?

pass@1 : un seul essai, le score est le pourcentage de tâches réussies du premier coup (ce qu'on obtient en production). pass@k : k essais autorisés, réussite si au moins un aboutit, donc un score qui monte avec k. pass^k : réussite seulement si les k essais réussissent tous, une mesure de fiabilité utilisée par τ-bench.

Peut-on se fier aux benchmarks publiés par l'éditeur du modèle ?

Avec prudence. Certains sont produits par l'éditeur évalué ou par un fournisseur ; ce n'est pas disqualifiant, mais mieux vaut privilégier les benchmarks indépendants et croiser les sources.

Le vrai enjeu : votre propre benchmark

Ces classements publics ont deux limites de fond. Ils sont presque tous en anglais et sur des tâches génériques, et ils ne notent que le modèle, alors qu'en production ce qui compte est le couple modèle + harness (tout ce qu'on assemble autour : prompts, outils, accès à vos données via RAG, garde-fous). Un modèle moyen bien outillé bat souvent un meilleur modèle mal intégré.

D'où notre conviction : les benchmarks publics servent à savoir par où commencer à regarder, à présélectionner deux ou trois candidats. Pas à décider. La mesure qui décide, c'est un benchmark maison : un jeu de vos cas réels, avec des critères de réussite vérifiables, sur lequel on compare modèles et harnesses pour vos tâches, à votre coût, avec votre niveau de fiabilité. C'est là qu'est le véritable avantage concurrentiel, parce qu'on ne peut pas améliorer ce qu'on ne mesure pas.

C'est exactement notre approche chez SprintOS : nous ne choisissons pas un modèle sur son classement, nous construisons avec vous le benchmark de vos cas d'usage, puis nous y mesurons modèles et harnesses en conditions réelles. C'est le cœur de SprintAI, qui exécute de vrais tests de bout en bout plutôt que de se fier à un score, et la logique de notre méthode appliquée à vos cas d'usage.

Vous hésitez entre plusieurs modèles pour un projet précis ? Plutôt que de comparer des pourcentages sortis de leur contexte, faites le point avec un expert SprintOS : nous évaluons ce qui compte vraiment, sur votre terrain.