Benchmark IA : lire les scores des LLM en cinq minutes

Un benchmark IA doit vous aider à choisir ce que vous allez tester ensuite. SWE-bench Verified mesure les performances sur 500 problèmes logiciels sélectionnés ; un bon score ne dit rien de la capacité d’un agent à respecter votre politique de remboursement. Examinez la tâche, les conditions du test et les règles de notation avant de regarder le meilleur résultat.

Vérifié à partir des pages des auteurs des benchmarks et de la fiche du modèle de Google le 15 octobre 2026. Les descriptions ci-dessous expliquent les tests ; les scores de l’exemple sont ceux publiés par Google. L’interprétation et la liste de vérifications sont les nôtres.

Pour un assistant de programmation, commencez par les tâches dans un dépôt de code ou un terminal. Pour un agent de service client, privilégiez l’utilisation d’outils en conversation et le respect des règles métier. Pour un assistant documentaire, intéressez-vous d’abord au raisonnement sur de longs contextes. Un score de connaissances générales peut éclairer ces choix, mais il ne suffit pas à les trancher.

Que mesure un benchmark IA ?

Un benchmark mesure les performances sur un ensemble précis de tâches, selon des règles précises. Il s’apparente davantage à une épreuve sportive qu’à un certificat d’intelligence : un temps au sprint apporte une information utile, sans pour autant désigner la bonne personne pour mener un secours en montagne.

Le jeu de données contient les questions ou les tâches. Le protocole d’évaluation définit ce que reçoit le modèle, les aides dont il dispose et la façon dont le résultat est noté. Le harness, aussi appelé scaffold, est l’environnement logiciel qui entoure le modèle : ses prompts, ses outils et sa boucle d’exécution.

Cette distinction compte lorsqu’une annonce affirme qu’un modèle sait coder. Écrire une fonction à partir d’un prompt court n’a rien à voir avec le travail d’un agent qui explore un dépôt, modifie des fichiers, lance des tests et se remet d’une erreur. Dans le second cas, le score évalue un système en fonctionnement, harness compris.

Le classement SWE-bench rend cette différence visible en distinguant plusieurs conditions d’évaluation, dont un environnement mini-SWE-agent commun. Votre outil de développement peut proposer d’autres outils, consignes ou limites. Avant d’appliquer ce score à votre workflow, identifiez ce qui fonctionnait autour du modèle.

Quels benchmarks retrouve-t-on dans les annonces de modèles ?

Avant de comparer les scores, rapprochez le benchmark du travail à accomplir. Voici les familles à reconnaître dans les annonces de modèles généralistes, de programmation et vocaux en 2026, ainsi que les tests de contexte qui permettent d’en interpréter les résultats. Chaque nom de benchmark renvoie à la page ou au dépôt de ses auteurs.

Gardez la version avec le nom. HLE-Diamond contient 1,000 questions retravaillées, tandis que la version finalisée du HLE d’origine en contient 2,500. Terminal-Bench 4.0 a modifié les ressources et les tâches. Le dépôt tau actuel documente à la fois de nouvelles modalités et des corrections de notation. Un score récent placé à côté d’un ancien peut correspondre à une épreuve différente, sans que le modèle se soit amélioré.

Quels scores comptent pour votre activité ?

Choisissez la famille qui se rapproche de l’échec que vous devez éviter. Un fondateur qui sélectionne une fonctionnalité d’IA, un CTO qui valide un agent et un responsable opérationnel qui traite des tickets d’assistance n’ont aucune raison d’accorder le même poids à chaque ligne d’un tableau de lancement.

Quels benchmarks LLM pour les agents de programmation ?

Si vous faites évoluer un produit existant, commencez par la correction de problèmes dans un dépôt et le travail en terminal. SWE-bench apporte des éléments utiles sur la résolution de problèmes ; Terminal-Bench, sur l’exécution de tâches dans un shell. LiveCodeBench et HumanEval répondent à des questions de programmation plus ciblées. Aucun ne mesure à lui seul si un correctif sera facile à maintenir dans votre base de code.

Imaginez un développeur indépendant qui demande à un agent de modifier la suppression des comptes. Produire une fonction auxiliaire correcte n’est qu’une partie du travail. L’agent doit retrouver tous les points d’appel concernés, préserver les permissions, mettre à jour les tests et éviter de laisser les données client dans un état incohérent. Votre évaluation doit porter sur cette modification complète, avec les mêmes accès au dépôt et les mêmes outils que ceux prévus en pratique.

La règle pour décider : si le travail touche plusieurs fichiers et plusieurs étapes d’exécution, exigez des résultats sur des tâches d’agent avant de retenir un candidat. Les scores à l’échelle d’une fonction restent des informations complémentaires. Conservez la revue de code dans le processus d’acceptation tant que vos propres cas ne justifient pas d’en réduire la portée.

Comment lire les benchmarks de raisonnement des LLM ?

GPQA, HLE, MMLU-Pro, AIME et ARC-AGI explorent différentes formes de raisonnement. Ils fournissent des pistes utiles, en particulier lorsque la tâche exige de résoudre des problèmes scientifiques ou mathématiques difficiles. Ils remplacent mal des preuves directes du respect de vos règles de fonctionnement.

Les 198 questions de GPQA Diamond forment un ensemble scientifique délibérément sélectionné. Un CTO qui évalue un assistant de recherche interne peut s’appuyer sur ce signal pour présélectionner des candidats, puis les tester sur des questions dont la réponse dépend des documents de l’entreprise. Un responsable du support doit accorder davantage d’attention à l’usage d’outils dans le respect des règles et au transfert vers un interlocuteur compétent.

Pour Humanity's Last Exam, distinguez l’ambition du nom de ce qui est réellement mesuré. Ses auteurs séparent explicitement les performances académiques sur des questions à réponse fermée de la recherche autonome. Répondre à une question difficile dont la solution est connue ne prouve pas qu’un système sait choisir un problème pertinent, recueillir des éléments fiables et reconnaître ses erreurs.

Contexte long et voix : des évaluations spécifiques sont nécessaires

La fenêtre de contexte exprime une capacité : la quantité d’informations qu’un système peut recevoir en entrée. L’évaluation du contexte long examine ce qu’il parvient à en faire. Les tests de recherche d’informations demandent de retrouver des éléments ; les tests de raisonnement exigent de les relier. Les auteurs de RULER montrent pourquoi retrouver un fait caché ne suffit pas à représenter les performances sur des contextes longs.

Pour une personne chargée d’examiner des contrats, le test utile consiste à vérifier si l’assistant relie une exception figurant en annexe à une clause du contrat principal, en citant correctement les deux. Incluez des documents dans lesquels la réponse est absente, n’est plus à jour ou est contredite. Un système qui fusionne avec assurance des versions incompatibles a échoué, même s’il a retrouvé chaque passage.

Pour la voix, séparez la compréhension de la parole, le raisonnement, la production vocale et la gestion de la conversation. FLEURS peut servir à évaluer la transcription ; Big Bench Audio porte sur le raisonnement à partir de questions orales ; VoiceBench couvre des tâches fondées sur des consignes orales. La famille tau actuelle évalue aussi les interactions vocales. Il s’agit de mesures distinctes.

Un pilote d’assistance téléphonique doit inclure du bruit de fond, des noms, des interruptions, des corrections et un transfert à une personne. Écoutez l’échange et vérifiez l’action finale. La transcription peut sembler correcte alors que la conversation est pénible ou que le mauvais compte a été modifié.

Comment évaluer les performances d’un LLM ?

Pour décider d’adopter un système, définissez la performance comme un travail accepté dans les limites de votre workflow. La qualité des réponses, la fiabilité d’exécution et le temps de réponse sont des exigences distinctes. Un benchmark exécuté avec un raisonnement poussé peut être pertinent pour une investigation menée pendant la nuit et mal adapté à une interaction avec le support en temps réel.

L’acheteur doit demander des résultats sur les catégories de tâches requises et sur la configuration réelle du produit. Le responsable opérationnel doit examiner les échecs et la manière dont le système s’en remet. Le développeur doit pouvoir reproduire les paramètres. Si le fournisseur ne peut pas identifier la configuration évaluée, le score ne suffit pas à justifier un engagement en production.

Lire un classement LLM en cinq minutes

Cette lecture en cinq minutes permet de décider si une annonce mérite une évaluation approfondie. C’est une méthode de lecture : ce délai ne suffit pas à établir qu’un modèle est sûr ou utile dans votre application.

1. 1

   Minute 1 : définir votre tâche

   Notez le résultat attendu : corriger des problèmes dans un dépôt, traiter des demandes d’assistance, répondre à partir de documents ou gérer des appels vocaux. Repérez les lignes qui s’en rapprochent. Écartez de votre décision les bons résultats sans rapport avec cet objectif.

2. 2

   Minute 2 : identifier précisément l’épreuve

   Relevez l’édition du benchmark, le sous-ensemble, la langue et la période des tâches. Repérez les mentions comme Diamond, Verified, hors ligne, texte seul ou avec outils. Si l’intitulé est incomplet, consultez la page du benchmark.

3. 3

   Minute 3 : examiner les conditions du test

   Identifiez le harness, les outils, le réglage du raisonnement, le temps accordé et les règles concernant les tentatives. Vérifiez si votre produit fonctionnera dans ces conditions. L’accès à la recherche, l’exécution de code ou davantage de nouvelles tentatives peuvent changer ce que représente le score.

4. 4

   Minute 4 : décoder la métrique

   L’exactitude correspond à la part des réponses jugées correctes. Le score F1 combine la proportion d’éléments renvoyés qui sont corrects et la proportion d’éléments attendus qui ont été retrouvés. Une notation partielle peut récompenser une progression sans que la tâche soit achevée. Pour un taux d’erreur, plus le chiffre est bas, mieux c’est. Lisez la définition avant d’assimiler un pourcentage à une proportion de tâches accomplies.

5. 5

   Minute 5 : retrouver qui a exécuté le test

   Identifiez qui a réalisé l’évaluation : le concepteur du modèle, l’organisateur du benchmark ou un autre évaluateur. Lisez la note associée à chaque ligne au lieu de supposer que tout le tableau suit la même procédure. Conservez la source et les paramètres, puis choisissez un candidat à tester sur vos propres cas.

Vous devez en tirer une courte note de décision : « Famille de tâches pertinente, version actuelle, configuration comprise, mérite un test sur nos cas. » Si vous ne pouvez pas la compléter, consignez l’information manquante avant de modifier un système qui fonctionne.

Exemple commenté : le tableau Gemini 4 Argon de Google

Gemini 4 Argon, le modèle d’IA généraliste de Google, fournit un exemple utile, car son tableau mêle plusieurs familles de tâches et plusieurs règles de notation. Les lignes ci-dessous reprennent les résultats de Google dans sa fiche du modèle d’octobre, consultée le 15 octobre 2026. Ces résultats sont attribués à leur source ; ils n’ont pas été mesurés pour cet article.

Lisez l’intitulé et les notes de chaque ligne avec sa valeur. Ces pourcentages n’ont ni le même dénominateur ni la même signification.

BFS signifie breadth-first search, ou parcours en largeur : les connexions du graphe sont suivies niveau par niveau. Les tokens sont les unités qui servent à mesurer le contexte d’un modèle ; ils ne correspondent pas à des mots.

Lire les notes avant de conclure

La méthodologie d’évaluation de Google indique qu’Argon utilise généralement le réglage de raisonnement le plus élevé et le pass@1, avec des exceptions. Son résultat DeepSWE utilise un harness mini-swe. Google a calculé lui-même son résultat Terminal-Bench, tandis que les résultats de comparaison proviennent du classement officiel. Les résultats GraphWalks sont calculés par Google pour l’ensemble des modèles. OSWorld retient le maximum sur trois exécutions et présente une notation partielle hors ligne.

Plusieurs modalités d’évaluation coexistent donc dans ce tableau ; rien n’indique que toutes les cellules proviennent d’une même expérience contrôlée. Pour le développeur, la question suivante est de savoir si le harness de programmation ressemble à celui de l’agent prévu. Pour l’acheteur, il faut déterminer si la configuration proposée pour l’application correspond aux résultats présentés. Pour le responsable opérationnel, il s’agit de vérifier si la métrique récompense un travail réellement achevé.

Notre calcul : 99.7 moins 84.2 donne un écart de 15.5 points de pourcentage entre les scores F1 publiés pour GraphWalks. Ces lignes portent sur des sous-ensembles de longueurs différentes : la soustraction n’isole donc pas l’effet causal de la longueur sur des questions identiques. Elle montre en revanche pourquoi ne citer que la ligne au contexte le plus court écarterait des éléments utiles pour un workflow de documents longs.

L’interprétation du score d’utilisation d’un ordinateur est tout aussi concrète : ne traduisez pas un score partiel par « l’agent accomplit cette proportion de nos tâches bureautiques ». Une progression partielle peut avoir de la valeur pour un assistant qui rend ensuite la main à une personne. Un processus sans supervision exige des preuves de résultats complets et corrects.

Pour approfondir les critères d’adoption propres à ce modèle, consultez notre décryptage de Gemini 4 Argon et le comparatif Gemini 4 Argon contre Opus 5.5.

Pourquoi un bon score peut-il induire en erreur ?

Un score élevé peut être valide tout en répondant à la mauvaise question métier. La démarche utile consiste à repérer cette limite, puis à déterminer quels éléments permettraient de la lever.

Contamination et optimisation ciblée sur le test

Il y a contamination lorsque des questions ou des réponses de l’évaluation se retrouvent dans les données d’entraînement. Le modèle peut alors tirer parti de cette exposition préalable au lieu de résoudre un problème inédit. Les tests publics peuvent aussi devenir des objectifs d’optimisation : ajuster sans cesse les prompts ou les scaffolds sur les mêmes tâches réduit leur valeur comme épreuve nouvelle.

LiveCodeBench utilise des problèmes datés pour permettre aux évaluateurs de sélectionner des tâches publiées après la date limite des données d’entraînement. C’est un choix de conception utile, pas une raison de supposer que tout résultat portant « Live » dans son nom échappe à la contamination. Vérifiez la période réelle des problèmes. Un bond inhabituel des performances doit inciter à examiner le protocole ; il ne prouve pas une irrégularité.

Pour vos propres évaluations, conservez un jeu de test réservé que vous n’utilisez pas pour ajuster les prompts. Lorsqu’un échec devient un exemple de développement, ajoutez de nouveaux cas à ce jeu de test. Sinon, le système risque de devenir excellent sur vos exemples familiers tout en restant fragile ailleurs.

L’environnement d’exécution peut changer le système comparé

Le dispositif qui exécute le test compte. Un modèle doté de recherche, d’outils de manipulation de fichiers, de nouvelles tentatives et de consignes soigneusement rédigées constitue un système déployé différent du même modèle répondant à un seul prompt. Un meilleur scaffold peut représenter un progrès d’ingénierie réel ; l’erreur consiste à attribuer tout le résultat au modèle sous-jacent.

Utilisez un harness commun pour isoler l’effet d’un changement de modèle. Évaluez le produit complet lorsque vous choisissez entre des produits complets. Ces deux questions peuvent légitimement conduire à des conclusions différentes.

Comment interpréter un résultat publié par le fournisseur ?

Le résultat d’un concepteur de modèles est utile lorsque sa méthode est claire ; celui d’un organisateur de benchmark l’est lorsque sa configuration correspond à la comparaison recherchée. Aucune de ces étiquettes ne dispense de lire le protocole. Distinguez un résultat soumis à un classement d’un résultat reproduit indépendamment dans des conditions communes.

Cherchez le prompt, l’identifiant du modèle, le harness, la méthode de notation, les exclusions et l’incertitude. Un faible écart, sans informations suffisantes sur la variabilité, ne doit pas décider d’une migration. Un résultat absent constitue un manque de données ; ce n’est pas automatiquement un zéro.

Examinez aussi l’agrégation. Une moyenne globale reflète les tâches et les pondérations choisies par l’évaluateur. Votre file de demandes d’assistance peut contenir de nombreux cas d’exception qui influencent à peine cette moyenne. Ne faites pas la moyenne de pourcentages issus de benchmarks sans rapport entre eux pour créer votre propre score d’intelligence.

Un bon évaluateur peut mesurer le mauvais résultat

Tests unitaires, corrigés de référence, modèles juges et préférences humaines ne récompensent pas les mêmes choses. La couverture des tests peut laisser passer un défaut ; un corrigé peut contenir une erreur ; un modèle juge peut préférer une explication bien formulée à une action correcte. Une victoire dans un test de préférence mesure ce que les répondants ont préféré dans le cadre de cette procédure.

Le dépôt tau actuel documente des corrections de tâches et de notation. Ces correctifs améliorent l’évaluation, tout en rendant indispensable le suivi des versions. Un test est un dispositif de mesure qui s’entretient, pas une source de vérité incontestable.

Quand faut-il lancer ses propres évaluations ?

Lancez vos propres évaluations dès que la décision dépend de vos données, de vos règles, de vos outils, de vos utilisateurs ou de votre tolérance aux échecs. Les scores publics suffisent à repérer des candidats plausibles. Ils ne suffisent pas à valider un agent qui modifie des données client ou répond à partir de documents privés.

Passez à l’action si un progrès sur un benchmark pertinent répond à un échec connu de votre système actuel : effectuez une comparaison contrôlée sur cette catégorie d’échecs. Différez la migration si le progrès porte sur des tâches sans rapport avec votre usage ou si la configuration publiée n’est pas disponible dans votre produit. Conservez le système actuel s’il satisfait déjà vos critères d’acceptation et que le nouveau candidat n’a montré aucun progrès pertinent.

Pour l’équipe support d’une entreprise de taille intermédiaire, un pilote de départ pourrait comprendre 50 cas : 20 demandes courantes, 10 exceptions aux règles, 10 entrées manquantes ou contradictoires et 10 cas de permissions ou de transfert à un interlocuteur compétent. Ces effectifs sont des suggestions pour concevoir le test, pas une affirmation selon laquelle cet échantillon suffirait statistiquement à autoriser un déploiement. Fixez la taille finale en fonction des taux d’échec et des écarts que vous devez détecter.

Définissez le résultat attendu avant de tester les candidats. Un cas de remboursement peut exiger une éligibilité correctement établie, le bon compte et le bon montant, aucune action non autorisée et une explication claire. Un cas de transfert doit être considéré comme réussi lorsque l’agent passe correctement le relais, même s’il ne résout pas lui-même la demande.

Exécutez chaque candidat avec les prompts, la recherche d’informations, les outils et les permissions prévus. Examinez l’état final des données et la trace des actions, pas seulement le dernier message. Répétez les cas instables, suivez séparément la latence et analysez les désaccords avant de conclure à une amélioration. Conservez un jeu de test réservé pour la décision finale.

Promptfoo est un outil d’évaluation qui compare des prompts, des modèles et des applications à partir de cas de test et d’assertions. Sa documentation présente le fonctionnement de l’exécution ; notre avis sur Promptfoo explique sa place dans le dispositif et ce qui reste de votre responsabilité.

Utilisez des vérifications déterministes pour les faits contrôlables directement, comme le compte sélectionné ou une action interdite. Pour les qualités qui demandent un jugement, par exemple le caractère complet et étayé d’une explication, définissez une grille d’évaluation et calibrez-la à partir d’annotations humaines. Le guide LLM-as-a-judge traite de cette couche de notation et de ses modes d’échec.

Dès lundi : choisissez un workflow, définissez ses critères d’acceptation, réunissez des cas récents et comparez le système actuel à un candidat dans les mêmes conditions. Décidez du déploiement à partir des résultats et des échecs qui comptent pour vos utilisateurs.

Questions fréquentes sur les tableaux de benchmarks

Quels sont les benchmarks LLM les plus courants ?

Repérez d’abord les familles : SWE-bench et Terminal-Bench pour les agents de programmation, GPQA et Humanity's Last Exam pour les questions académiques, la famille tau pour l’utilisation d’outils en conversation, et des tests distincts pour le contexte long et la parole. Conservez l’édition et les paramètres avec chaque score.

Quel benchmark LLM choisir pour la programmation ?

Choisissez le benchmark le plus proche de la tâche. SWE-bench porte sur la résolution de problèmes dans un dépôt ; Terminal-Bench, sur le travail en terminal ; HumanEval, sur la génération de fonctions ; LiveCodeBench inclut des problèmes de concours datés. Ce sont vos propres modifications de dépôt qui permettent de vérifier si ces résultats s’appliquent à votre travail.

Qu’est-ce que le jeu de données d’un benchmark LLM ?

Le jeu de données fournit les questions ou les tâches. Pour qu’un résultat de benchmark soit comparable, il faut aussi connaître le protocole : prompts, outils, limites, tentatives et notation. Le seul fait d’utiliser le même jeu de données ne suffit pas à rendre deux résultats comparables.

Pour des conseils pratiques sur l’évaluation et l’adoption de l’IA, abonnez-vous à la newsletter.