À chaque sortie d’un nouveau modèle d’intelligence artificielle, son éditeur publie un tableau de scores destiné à montrer qu’il dépasse la concurrence. Ces chiffres proviennent de benchmarks, des tests standardisés dont le fonctionnement est rarement expliqué. Cet article décrit ce que les benchmarks des modèles d’IA mesurent réellement, les pièges qui peuvent rendre un score trompeur, les capacités que les scores publiés laissent de côté, et pourquoi évaluer un agent est un problème différent. Il s’adresse à toute personne qui doit se forger une opinion sur un modèle à sa sortie sans être spécialiste de l’évaluation. C’est le premier volet d’une série de trois articles.

Voici les sept sections de l’article. Chaque titre est un lien vers la section correspondante.

• Qu’est-ce qu’un benchmark de modèle d’IA ? : ce qu’est un benchmark, ses trois composants et les grandes familles de tests.
• Que mesure exactement un score de benchmark ? : pourquoi un score mesure un système complet, et les sept éléments du protocole de mesure.
• Pourquoi un score peut-il tromper sans qu’il y ait triche ? : les six mécanismes qui rendent un score trompeur sans aucune fraude.
• Quand un écart entre deux scores devient-il significatif ? : comment distinguer une vraie différence de capacité du simple hasard de la mesure.
• Quelles capacités les benchmarks des modèles d’IA laissent-ils de côté ? : les quinze dimensions d’évaluation, et celles que les tableaux de lancement passent sous silence.
• Pourquoi un bon modèle ne fait-il pas automatiquement un bon agent ? : ce qui sépare une question de benchmark d’une tâche d’agent, et pourquoi le coût par tâche devient déterminant.
• Les six questions à poser devant un tableau de scores : une grille de lecture à appliquer devant n’importe quel tableau de scores.

Qu’est-ce qu’un benchmark de modèle d’IA ?

Un benchmark est un examen standardisé pour modèle d’intelligence artificielle. Le plus souvent, il se compose de trois éléments :

• Un ensemble figé de questions ou de tâches, identique pour tous les modèles testés.
• Une réponse de référence pour chaque question, c’est-à-dire la réponse considérée comme correcte.
• Une méthode de notation, qui compare la production du modèle à cette réponse de référence.

Quelques benchmarks fonctionnent autrement et n’ont aucune réponse de référence. Ils présentent à des personnes humaines deux réponses concurrentes et agrègent leurs préférences.

Le résultat est un score unique, en général un pourcentage de réussite. Ce chiffre sert de règle commune : deux modèles ayant passé le même test dans les mêmes conditions deviennent comparables.

Les benchmarks se répartissent en familles, chacune éclairant une compétence étroite. Les six familles ci-dessous sont présentées une par une. Chaque sous-section indique ce que la famille mesure et, quand son intitulé ne suffit pas, précise ce qu’elle contient réellement.

Connaissances et raisonnement

Cette famille couvre la culture générale et les questions scientifiques de niveau doctorat.

Mathématiques

Cette famille réunit deux niveaux très différents sous le même mot : les problèmes de compétition scolaire et les problèmes de recherche. Le premier niveau est celui des compétitions de mathématiques réservées aux élèves et aux étudiants. L’épreuve la plus utilisée pour tester les modèles est l’AIME (American Invitational Mathematics Examination). C’est un concours américain de quinze questions à résoudre en trois heures, réservé aux meilleurs participants des concours AMC (American Mathematics Competitions) 10 et AMC 12, et dont chaque réponse est un nombre entier compris entre 0 et 999 (Mathematical Association of America). Le second niveau est celui de la recherche : des tests comme FrontierMath emploient des énoncés originaux, écrits spécialement pour le test par des mathématiciens professionnels et jamais publiés auparavant, que même un spécialiste met plusieurs heures à résoudre.

Multimodal

Cette famille couvre le raisonnement qui combine plusieurs supports, en pratique surtout le texte et l’image. Les tests couvrant l’audio et la vidéo existent, mais restent rares dans les évaluations standard.

Raisonnement abstrait

Cette famille demande de deviner une règle à partir de quelques exemples, puis de l’appliquer à un cas jamais vu. Elle s’évalue avec des énigmes visuelles. Le test de référence, ARC-AGI, montre au modèle deux à cinq paires de grilles colorées. Dans chaque paire, une grille d’entrée a été transformée en une grille de sortie selon une règle qui n’est écrite nulle part, par exemple « remplacer chaque forme par son image en miroir ». Le modèle doit deviner cette règle à partir des exemples, puis l’appliquer à une grille qu’il n’a jamais vue. Les grilles comptent au plus trente cases de côté et utilisent jusqu’à dix couleurs (Chollet et collègues, ARC-AGI-2).

Codage et tâches agentiques

Cette famille demande de corriger des bugs réels, prélevés dans l’historique de logiciels publics et rejoués pour le test, ou de mener à bien une tâche complète dans un environnement informatique simulé.

Préférence humaine

Cette famille fait choisir des personnes humaines entre deux réponses concurrentes. Elle repose sur un dispositif de comparaison par paires. Sur la plateforme LMArena, un utilisateur pose sa propre question. Elle est envoyée à deux modèles dont les noms lui sont cachés. Il lit les deux réponses et désigne celle qu’il préfère, sans savoir quel modèle a produit laquelle. Les noms ne sont révélés qu’après le vote, ce qui évite que la notoriété d’une marque influence le choix. Les millions de votes ainsi collectés sont ensuite convertis en classement par un modèle statistique de comparaison par paires (Chiang et collègues, 2024).

Aucune de ces familles ne mesure « l’intelligence » en général. Un modèle peut exceller sur l’une et décevoir sur l’autre. Le deuxième article de cette série passera ces tests en revue un par un, avec leurs forces et leurs faiblesses.

Que mesure exactement un score de benchmark ?

C’est le point le plus important de cet article. Un score ne mesure pas le modèle seul. Il mesure le résultat produit par un ensemble d’éléments dont le modèle n’est qu’une pièce, lors d’une exécution précise et dans des conditions précises. Changer l’un de ces éléments change le score, sans que le modèle ait changé.

Cet ensemble de conditions porte un nom : le protocole de mesure. Un protocole complet décrit sept éléments, repris un par un ci-dessous. Connaître cette liste sert directement à la lecture d’un tableau de scores, car chaque élément que l’éditeur ne précise pas est une inconnue qui peut expliquer un écart.

Élément 1 : la version du modèle

Un même nom commercial recouvre souvent plusieurs versions successives, aux résultats différents. Un score n’a donc de sens qu’accompagné de la version précise du modèle telle qu’elle existait à la date du test, et non de son seul nom commercial.

Élément 2 : la consigne

La consigne regroupe deux choses. La première est le prompt système, c’est-à-dire le texte d’instructions générales placé avant chaque question, qui fixe au modèle son rôle et le format attendu de sa réponse. La seconde est la présence éventuelle d’exemples de réponses correctes glissés avant la vraie question. Cette technique porte un nom anglais, le few-shot, qui signifie littéralement « quelques exemples » : on montre au modèle deux ou trois questions déjà résolues avant de lui poser celle qui compte. Elle relève les scores. La comparaison est donc faussée si un éditeur l’emploie et l’autre non. Quand aucun exemple n’est fourni, on parle de zero-shot.

Élément 3 : le harnais d’évaluation

Le harnais (en anglais harness) est le logiciel qui fait passer l’examen. Il enchaîne trois tâches. Il pose chaque question au modèle dans un format donné, il récupère la réponse produite, puis il applique la méthode de notation décrite au point suivant. Deux harnais différents peuvent produire deux scores différents pour un même modèle, soit parce qu’ils ne formatent pas les questions de la même façon, soit parce qu’ils n’extraient pas la réponse finale du texte produit de la même façon.

Élément 4 : la méthode de notation

C’est le harnais qui note, mais il peut le faire de quatre manières, qui n’ont ni la même fiabilité ni le même coût.

• La comparaison exacte. La réponse du modèle doit correspondre caractère pour caractère à la réponse de référence. C’est simple mais sévère, car une bonne réponse écrite autrement est comptée fausse.
• La comparaison normalisée. Le harnais nettoie la réponse avant de la comparer, en retirant la ponctuation, en uniformisant les majuscules ou en réécrivant les formules mathématiques. Cette étape de nettoyage varie d’un harnais à l’autre et fait à elle seule bouger les scores.
• L’exécution de tests automatiques. Pour le code, on n’inspecte pas le texte produit : on l’exécute et l’on vérifie qu’il passe une batterie de tests. Le résultat est objectif, à condition que les tests eux-mêmes soient corrects.
• Le modèle juge. Un second modèle décide si la réponse produite équivaut à la réponse de référence attendue. Cette méthode accepte les formulations libres, mais elle introduit les biais du juge dans la mesure.

Les tests de préférence humaine échappent à ces quatre cas, puisque leur notation n’est pas automatique du tout : ce sont des personnes qui votent.

Élément 5 : le nombre de tentatives

Un modèle peut avoir droit à un seul essai par question, ou à plusieurs. Les publications indiquent ce choix avec une notation empruntée à l’évaluation du code, définie en 2021 par les auteurs du modèle Codex (Chen et collègues).

• pass@1 : le modèle produit une seule réponse par question, et cette réponse doit être juste. C’est la mesure la plus proche d’un usage réel.
• pass@k : la question est comptée réussie dès qu’au moins une des k réponses est correcte, quelle que soit sa place parmi les k. On ne choisit pas la meilleure réponse : on vérifie automatiquement chacune des k réponses, ce qui est possible parce que la bonne réponse est connue (en mathématiques) ou parce que le code produit est passé à une batterie de tests, et il suffit que l’une d’elles réussisse. Un score pass@10 est donc supérieur ou égal au pass@1 du même modèle, parce que sa condition de réussite est plus facile à remplir. En contrepartie, cette mesure ne dit rien de la fiabilité : un modèle qui ne réussit qu’une fois sur dix est compté réussi au même titre qu’un modèle qui réussit dix fois sur dix.
• Vote majoritaire, noté maj@k ou cons@k : le modèle produit k réponses et l’on retient la plus fréquente.

Trois conséquences pour la lecture. Un score pass@k ne se compare qu’à un autre score pass@k de même k. Un score publié sans mention de notation est le plus souvent un pass@1, mais rien ne le garantit. Enfin, un score obtenu avec soixante-quatre réponses par question coûte soixante-quatre fois plus de calcul qu’un pass@1, ce que le tableau ne dit jamais.

Élément 6 : le budget de calcul

C’est la quantité de calcul que le modèle a le droit de dépenser pour répondre. Elle s’exprime de deux façons. La première est un niveau d’effort de raisonnement réglé par l’éditeur, par exemple bas, moyen ou élevé. La seconde est une limite de texte intermédiaire. Le texte intermédiaire est le raisonnement que le modèle rédige pour lui-même avant de donner sa réponse finale : il y détaille ses étapes, teste des pistes, se corrige, et cette production n’est en général pas montrée à l’utilisateur. Plus ce budget est large, plus le score monte et plus la réponse coûte cher.

Élément 7 : les outils autorisés

Certains protocoles autorisent le modèle à utiliser des outils pendant l’épreuve, comme exécuter du code, consulter le web ou lire des fichiers. D’autres l’interdisent et n’admettent que le texte produit de mémoire. Un même benchmark existe donc parfois en deux versions dont les scores ne sont pas comparables. Cet élément est rarement précisé dans un tableau de scores, alors qu’il pèse souvent plus lourd que tous les autres.

Un exemple : trois scores pour un même modèle

Un exemple publié par OpenAI illustre l’ampleur de l’effet. Sur son modèle o1, évalué sur l’AIME 2024 (l’épreuve de mathématiques décrite plus haut), l’éditeur a publié trois scores très différents, obtenus en changeant deux conditions seulement, le nombre de tentatives et la manière de sélectionner la réponse finale parmi ces tentatives. Le détail figure dans la présentation de leurs modèles de raisonnement.

• La première mesure retenait la seule réponse produite par le modèle, et donnait 74 % de réussite.
• La deuxième retenait la réponse majoritaire parmi soixante-quatre réponses générées, un vote majoritaire noté maj@64, et montait à 83 %.
• La troisième faisait sélectionner, parmi mille réponses générées, celle qu’un modèle de notation entraîné pour cela jugeait la meilleure, et atteignait 93 %.

Le score croît d’une mesure à l’autre, et il croît fortement. Aucun de ces trois chiffres n’est faux, mais les trois ne décrivent pas la même chose.

Ce qu’il faut en conclure pour comparer deux scores

Deux scores ne se comparent que si leurs protocoles sont alignés, élément par élément. Toute différence de version, de consigne, de harnais, de méthode de notation, de nombre de tentatives, de budget de calcul ou d’outils autorisés doit être considérée comme une explication possible de l’écart, au même titre que la différence de capacité entre les modèles.

Un score publié devrait donc toujours être accompagné de la description de son protocole complet, c’est-à-dire des sept éléments listés ci-dessus, et non du seul harnais. Sans cette description, le chiffre n’est ni vérifiable ni reproductible par un tiers.

La réciproque mérite d’être dite. Même quand le protocole déclaré est identique des deux côtés, la comparaison peut rester imparfaite. Le harnais peut en effet convenir mieux à un modèle qu’à l’autre, par exemple parce qu’il formate les questions d’une manière proche de celle que l’un des deux a rencontrée pendant son entraînement.

Pourquoi un score peut-il tromper sans qu’il y ait triche ?

Un score peut induire en erreur alors que personne n’a fraudé. Six mécanismes distincts produisent cet effet. Chacun est établi par des cas publics, dont les sources sont citées au fil des paragraphes qui suivent.

Piège 1 : l’auto-déclaration

La plupart des scores publiés à la sortie d’un modèle sont produits par son fabricant, qui a un intérêt commercial à présenter les chiffres les plus favorables. Rien ne l’oblige à publier les résultats qui le desservent, ni à faire vérifier ses mesures par un tiers indépendant.

Piège 2 : la sélection des tests présentés

Le fabricant choisit les benchmarks qu’il met en avant, en privilégiant naturellement ceux où il gagne. Un test réputé, absent d’un tableau de lancement, est donc une information en soi.

Piège 3 : les conditions de mesure

Ce piège consiste à exploiter les marges laissées par le protocole décrit à la section précédente. Un fabricant qui teste son modèle avec le budget de calcul maximal et plusieurs tentatives par question obtient mécaniquement de meilleurs chiffres qu’un concurrent testé en une seule tentative et avec un budget réduit. Les deux chiffres sont exacts pris séparément. C’est leur rapprochement qui est trompeur, d’autant que cette différence de conditions n’est pas toujours signalée.

Piège 4 : la contamination des données d’entraînement

Il arrive que les questions d’un test se retrouvent, avec leurs réponses, dans les données qui ont servi à entraîner un modèle. Le modèle a alors déjà rencontré le sujet et son corrigé pendant son apprentissage, et son score mesure sa mémoire plutôt que sa capacité de raisonnement.

Trois méthodes existent, de deux natures : deux préviennent la contamination en amont, la troisième la détecte après coup.

• Le marqueur caché. Les concepteurs du test insèrent dans leurs fichiers une chaîne de caractères unique, accompagnée d’une mention interdisant l’usage de ces données pour l’entraînement. Un éditeur honnête recherche ce marqueur dans ses données et écarte les documents qui le contiennent. La méthode a une limite évidente : elle ne fonctionne que si tout le monde joue le jeu (Search-Time Data Contamination, 2025).
• Le jeu de questions privé. Une partie des questions n’est jamais publiée et l’évaluation officielle se fait sur cette partie. C’est le choix d’ARC-AGI, qui conserve un ensemble privé de cent tâches réservé aux classements (Chollet et collègues, ARC-AGI-2).
• Les questions neuves. C’est la seule des trois qui détecte la contamination après coup, au lieu de la prévenir. On écrit un jeu de questions entièrement nouveau, de difficulté équivalente au test d’origine, puis l’on compare les deux scores. L’étude GSM1k a appliqué cette méthode à un test d’arithmétique très répandu : certaines familles de modèles perdent jusqu’à huit points sur les questions neuves, ce qui trahit un apprentissage partiel des anciennes (Zhang et collègues, 2024).

La contamination est l’une des deux raisons pour lesquelles OpenAI a cessé d’utiliser le benchmark de codage SWE-bench Verified en février 2026. L’éditeur invoque à la fois cette contamination et une proportion élevée de cas de test défectueux, qui rejettent des solutions pourtant correctes : 59,4 % des tâches échouées auditées étaient dans ce cas.

Piège 5 : les erreurs dans les questions elles-mêmes

Les jeux de test comportent des erreurs, et parfois beaucoup. En juin 2026, Epoch AI a corrigé son benchmark FrontierMath après avoir trouvé des erreurs dans 42 % des problèmes. Une étude indépendante estime qu’environ 6,5 % des questions du célèbre test MMLU sont défectueuses, le plus souvent parce que la réponse de référence est fausse ou parce que l’énoncé est ambigu. Un modèle qui répond juste à une question mal posée est compté en échec.

Piège 6 : la saturation du test

Quand tous les bons modèles frôlent le score parfait, le test ne distingue plus rien. Les écarts qui subsistent portent alors sur les quelques questions les plus douteuses du jeu, celles-là mêmes qui relèvent du piège précédent. Le test reste utile pour repérer un modèle faible, mais il devient inutilisable pour départager les meilleurs.

Ce que ces six pièges ont en commun, et ce qui les sépare

Quatre de ces six pièges relèvent d’un même principe, la loi de Goodhart, selon laquelle une mesure qui devient un objectif cesse d’être une bonne mesure. Dès qu’un score devient un argument de vente, les fabricants optimisent pour ce score, et le score perd de sa valeur d’information. L’auto-déclaration, la sélection des tests, les conditions de mesure et la contamination décrivent tous ce comportement : un acteur ajuste sa façon de mesurer ou de communiquer parce que le score est devenu un enjeu commercial.

Les deux autres pièges ont une origine différente et ne mettent en cause aucun comportement. Les erreurs dans les questions relèvent d’un défaut de fabrication du test. La saturation relève d’une usure liée aux progrès des modèles.

Quand un écart entre deux scores devient-il significatif ?

Devant un écart de deux ou trois points entre deux modèles, le chiffre seul ne suffit pas à conclure. La bonne question est de savoir si cette différence est assez solide pour se reproduire, ou si elle peut venir du simple hasard de la mesure. Trois éléments aident à répondre : le nombre de questions du test, le détail des questions où les modèles diffèrent, et la stabilité des scores d’une exécution à l’autre.

La taille du test : un premier repère

Le premier repère est le nombre de questions du test. Sur l’AIME, qui n’en compte que quinze, une seule bonne réponse de plus déplace le score de 6,7 points : un écart de cette ampleur ne pèse donc qu’une question, et une seule réponse chanceuse suffit à le produire. Sur HLE, qui compte 2 500 questions de même poids, chaque question ne vaut que 0,04 point, et un écart de deux points correspond à une cinquantaine de réponses. La règle est simple : moins un test comporte de questions, plus l’écart doit être grand pour vouloir dire quelque chose. Mais le nombre de questions ne règle pas tout. Même sur un test qui en compte des milliers, il ne suffit pas à lui seul à établir qu’un écart est réel.

Regarder les questions où les modèles diffèrent

Pour aller plus loin, il faut se rappeler que les deux modèles passent exactement les mêmes questions. On peut donc comparer leurs réponses question par question, et ce sont les questions sur lesquelles ils diffèrent qui portent l’information. Deux situations peuvent donner le même écart final de cinquante réponses. Dans la première, les deux modèles ne se distinguent que sur cinquante questions, et l’un les remporte toutes : l’avantage est net. Dans la seconde, ils se distinguent sur 1 350 questions, l’un en gagnant 700 et l’autre 650 : l’écart final est le même, mais il se noie dans un grand nombre de désaccords qui se compensent presque, et il est bien plus fragile.

Deux méthodes statistiques exploitent ce raisonnement, et il suffit d’en connaître le principe. Le test apparié compare les deux modèles réponse par réponse sur les mêmes questions, au lieu de comparer leurs deux scores d’ensemble, et il mesure si l’avantage sur les questions de désaccord est trop régulier pour être mis sur le compte du hasard. Le rééchantillonnage, lui, rejoue la comparaison des centaines de fois, à chaque fois sur un tirage au sort des mêmes questions : si le même modèle l’emporte dans la grande majorité de ces tirages, l’avantage est solide ; s’il l’emporte environ une fois sur deux, il est fragile.

Les modèles ne sont pas déterministes

Une seconde source d’incertitude tient au fonctionnement même des modèles : ils ne sont pas déterministes. Soumis deux fois à la même question, un modèle peut donner deux réponses différentes, si bien que le même test, rejoué, ne rend pas exactement le même score (Thinking Machines Lab, 2025). Il faut donc exécuter un modèle plusieurs fois pour mesurer l’ampleur de cette variation, et se méfier d’un score obtenu en une seule fois, comme l’est presque toujours un score publié sans indication du nombre d’exécutions.

Publier l’écart, pas seulement les deux scores

Tout cela a une conséquence sur la façon de présenter les résultats. Publier le score de chaque modèle, par exemple 82 % pour l’un et 80 % pour l’autre, laisse le lecteur faire lui-même la soustraction et juger à vue si deux points comptent. Il est plus utile de publier directement l’écart entre les deux, soit deux points, en indiquant à quel point ce chiffre est incertain.

Deux notions se distinguent ici. L’incertitude est l’idée générale qu’un score mesuré n’est jamais exact, parce qu’il dépend de l’échantillon de questions posées et des aléas d’exécution. L’intervalle de confiance est la façon de chiffrer cette incertitude : c’est la fourchette dans laquelle la vraie valeur se situe très probablement. Dire « 80 %, à plus ou moins 3 points près » revient à donner la fourchette qui va de 77 % à 83 %.

L’écart entre deux modèles se chiffre lui aussi avec sa propre fourchette. Reprenons nos deux modèles : A obtient 82 %, B obtient 80 %, l’écart est donc de 2 points. Mais ce 2 n’est pas plus exact que les deux scores dont il provient : il a lui aussi une marge d’incertitude.

Comment obtient-on cette marge ? Par la méthode des tirages répétés décrite plus haut, le rééchantillonnage. On connaît la réponse de chaque modèle à chacune des questions du test. On fabrique alors un faux test de même taille, en tirant ses questions au sort parmi les vraies, avec le droit de piocher plusieurs fois la même, et l’on recalcule l’écart des deux scores sur ce faux test. On répète ce tirage des centaines de fois, ce qui donne des centaines de valeurs d’écart légèrement différentes. La fourchette est l’intervalle qui rassemble la grande majorité de ces valeurs : si elles tombent presque toutes entre 0,5 et 3,5 points, la marge d’incertitude de l’écart est cette fourchette de 0,5 à 3,5 points. On ne l’obtient donc pas en soustrayant les fourchettes des deux scores, mais en recalculant l’écart lui-même un grand nombre de fois, sur des tirages différents des mêmes questions.

Cette fourchette de l’écart livre directement la réponse, par une seule question : contient-elle la valeur zéro ? Un écart de zéro voudrait dire que les deux modèles sont à égalité. Si la fourchette va de 0,5 à 3,5, elle ne descend jamais jusqu’à zéro : même dans le cas le moins favorable à A, l’écart reste de 0,5 point en sa faveur, donc A est réellement devant. Si au contraire elle allait de −1 à 3, elle contiendrait zéro, l’égalité resterait possible, et l’on ne pourrait rien conclure.

On aurait tort, pour trancher, de simplement regarder si les fourchettes des deux scores se chevauchent. Elles se chevauchent ici, celle de A (79 % à 85 %) et celle de B (77 % à 83 %) partageant la zone de 79 % à 83 %, ce qui laisserait croire à une égalité. Ce critère est trompeur, car exiger que les deux fourchettes ne se touchent pas revient à exiger que le pire score possible de A, 79 %, dépasse encore le meilleur score possible de B, 83 %. C’est une condition beaucoup trop sévère : elle suppose que les deux modèles auraient au même moment leur pire malchance, chacun dans le sens qui le dessert. La bonne mesure reste donc la fourchette calculée directement sur l’écart, jugée sur une seule question : contient-elle zéro ou non ?

Significatif ne veut pas dire important

Enfin, un écart jugé statistiquement significatif ne veut pas dire pour autant qu’il compte en pratique, ni qu’un modèle est globalement supérieur. Il indique seulement que, sur ce test précis et dans les conditions du protocole utilisé, l’avantage observé s’explique difficilement par le seul hasard de la mesure. Il reste ensuite à juger si cet écart est assez grand, et le test assez représentatif de votre usage réel, pour peser sur une décision.

Quelles capacités les benchmarks des modèles d’IA laissent-ils de côté ?

Les scores mis en avant au lancement d’un modèle donnent une image incomplète de ce qu’il faudrait évaluer. Le recensement mené pour cet article identifie quinze dimensions d’évaluation. Les tableaux publiés au lancement d’un modèle n’en couvrent le plus souvent que six ou sept. Les quinze dimensions sont reprises ci-dessous, chacune avec ce qu’elle mesure et sa présence habituelle dans les communications de lancement des éditeurs.

Capacité 1 : les connaissances académiques

Cette dimension mesure l’étendue des connaissances du modèle à travers un grand nombre de disciplines, de l’histoire à la médecine. Elle s’évalue par des questionnaires à choix multiples couvrant plusieurs dizaines de matières. Elle est présente dans presque toutes les communications de lancement.

Capacité 2 : le raisonnement expert

Cette dimension mesure la capacité à résoudre des questions scientifiques de niveau doctorat, écrites par des spécialistes et conçues pour qu’une simple recherche documentaire ne suffise pas à répondre. Elle est présente dans presque toutes les communications de lancement.

Capacité 3 : les mathématiques

Cette dimension mesure la résolution de problèmes mathématiques, depuis les concours pour élèves jusqu’aux énoncés de recherche décrits plus haut. Elle est présente dans presque toutes les communications de lancement, car elle produit des chiffres spectaculaires.

Capacité 4 : le raisonnement abstrait

Cette dimension mesure la capacité à découvrir une règle inédite à partir de quelques exemples, puis à l’appliquer correctement à un cas nouveau. Elle est fréquemment présente dans les communications de lancement, mais avec un protocole rarement détaillé.

Capacité 5 : la compréhension multimodale

Cette dimension mesure le raisonnement sur des contenus qui mêlent le texte et l’image, par exemple lire un graphique, interpréter un schéma technique ou analyser une capture d’écran. Elle est fréquemment présente dans les communications de lancement.

Capacité 6 : la préférence humaine

Cette dimension mesure ce que des utilisateurs préfèrent réellement, en leur faisant comparer deux réponses à leur propre question. Elle est fréquemment mise en avant, car elle est la seule à refléter directement le ressenti d’usage.

Capacité 7 : le code et le comportement agentique

Cette dimension mesure la résolution de tâches logicielles qui demandent plusieurs étapes, comme corriger un bug dans un vrai dépôt de code. Elle est présente dans presque toutes les communications de lancement depuis 2024, année où les tests de codage sur dépôts réels, en particulier SWE-bench, se sont imposés comme mesure de référence.

Capacité 8 : le suivi d’instructions

Cette dimension mesure le respect de contraintes de format explicites, par exemple répondre uniquement en JSON, ne pas dépasser cent mots ou n’employer aucune formule de politesse. Elle est rarement publiée, alors qu’elle conditionne directement la fiabilité du modèle et sa mise en production dans une chaîne applicative.

Capacité 9 : la factualité

Cette dimension mesure la capacité à répondre juste, et surtout à s’abstenir plutôt qu’à inventer une réponse quand l’information manque. Elle est rarement publiée dans les communications de lancement.

Capacité 10 : le contexte long

Cette dimension mesure la capacité à retrouver une information précise dans un très long document, et à relier entre elles des informations éloignées les unes des autres. Elle apparaît occasionnellement, en général sous la forme d’un test de recherche d’une phrase isolée.

Capacité 11 : le multilingue

Cette dimension mesure la performance du modèle dans les langues autres que l’anglais. Elle est rarement publiée, ce qui constitue une lacune sérieuse pour un usage francophone, puisque rien ne garantit qu’un score obtenu en anglais se retrouve en français.

Capacité 12 : la robustesse

Cette dimension mesure la stabilité du score quand on reformule les questions sans en changer le sens. Elle est presque toujours absente des communications de lancement, alors qu’elle indique si un score reflète une capacité réelle ou un ajustement au libellé du test.

Capacité 13 : la calibration

Cette dimension mesure l’adéquation entre la confiance qu’affiche le modèle et son exactitude réelle. Elle est presque toujours absente des communications de lancement, alors qu’elle conditionne l’usage professionnel : un modèle exact à 70 % qui signale correctement ses 30 % d’incertitude est plus utilisable qu’un modèle exact à 75 % qui affirme tout avec la même assurance, car on sait dans quels cas le vérifier.

Capacité 14 : la sûreté

Cette dimension mesure les comportements dangereux, ainsi que les refus excessifs ou au contraire insuffisants. Elle n’apparaît pas dans les tableaux de scores mais dans un document séparé, publié en même temps que le modèle.

Capacité 15 : l’efficience

Cette dimension mesure le coût, la latence et la consommation de calcul nécessaires pour atteindre le score annoncé. Elle est presque toujours absente, alors qu’un score obtenu avec un budget de calcul dix fois supérieur n’est pas comparable à un score obtenu en une seule passe. Le coût par tâche est pourtant le premier critère de décision dans un projet réel.

Le deuxième article de cette série reprend une par une les dimensions couvertes par les benchmarks publics, avec les tests correspondants et leur gouvernance.

Pourquoi un bon modèle ne fait-il pas automatiquement un bon agent ?

Depuis 2024, on n’utilise plus seulement un modèle pour répondre à une question : on le place au cœur d’un agent. Un agent est un modèle inséré dans une boucle logicielle qui lui permet de planifier une tâche, d’utiliser des outils comme lire un fichier, exécuter du code ou appeler un service, d’agir en plusieurs étapes et de garder la mémoire de ce qu’il a fait.

Or une tâche d’agent ne ressemble pas à une question de benchmark statique, c’est-à-dire à la forme classique décrite plus haut : un énoncé, une réponse de référence, une notation. Le tableau suivant compare les deux formes, critère par critère. Il oppose volontairement deux situations extrêmes, un benchmark entièrement statique d’un côté et une tâche d’agent complète de l’autre. Beaucoup de tests réels se situent entre les deux. Un benchmark de codage donne par exemple au modèle l’accès à des outils, comme une tâche d’agent, tout en conservant une notation automatique, comme un benchmark statique.

Critère de comparaison	Benchmark statique	Tâche d’agent
Durée	Un seul tour	Des dizaines d’étapes
Réponse	Connue à l’avance	Un livrable jugé sur critères
Outils	Aucun, par construction	Terminal, navigateur, code, fichiers
Causes fréquentes d’échec	Ignorance, mauvaise lecture, erreur de format	Perte du fil, absence de rattrapage après une erreur
Coût	Une seule réponse produite	Des dizaines d’appels successifs au modèle

La ligne des causes d’échec mérite une nuance. Sur un benchmark statique, l’ignorance n’est pas la seule cause d’erreur : un modèle peut aussi mal lire un énoncé ambigu, ou donner la bonne réponse dans un format que le harnais ne sait pas reconnaître, et le score le comptera en échec dans les deux cas.

Cette différence de nature entre un benchmark statique et une tâche d’agent a une conséquence arithmétique, que l’on peut illustrer par un calcul volontairement simplifié. Imaginons une tâche qui exige vingt étapes successives, et un modèle qui réussit chaque étape dans 95 % des cas. Ces deux chiffres sont choisis pour l’exemple et ne sont pas mesurés : ils représentent une tâche d’agent de longueur courante et un modèle très fiable à chaque étape. Pour que la tâche aboutisse, les vingt étapes doivent toutes réussir. La probabilité de succès est donc 0,95 multiplié vingt fois par lui-même, soit environ 36 %. Autrement dit, un modèle qui réussit chaque étape dans 95 % des cas échoue tout de même la tâche complète près de deux fois sur trois, sa probabilité de succès tombant à environ 36 %.

Ce calcul théorique suppose qu’aucune erreur ne peut être rattrapée, ce qui n’est pas le cas d’un agent réel. Celui-ci peut vérifier ses résultats, revenir en arrière, réessayer une étape ou demander une intervention humaine, ce qui atténue la dégradation sans l’annuler. La qualité de la planification devient déterminante, et le coût par tâche, négligeable sur une question isolée, devient un critère de premier plan.

Les quinze capacités décrites plus haut restent une base de départ utile pour décider quoi tester chez un agent : un agent qui code, par exemple, mobilise le code, le suivi d’instructions, la factualité et le raisonnement. Mais elles ne suffisent pas ; il faut les traduire dans le contexte de la tâche visée, puis y ajouter ce qui est propre à l’agent, à savoir la fiabilité sur une longue suite d’étapes, l’usage correct des outils et la capacité à se rattraper après une erreur.

Pour un agent, le harnais pèse si lourd qu’il fait partie du produit évalué : un même modèle affiche des scores différents selon l’échafaudage d’agent employé. Le troisième article de cette série le montrera concrètement sur un cas réel, et une série d’articles distincte, consacrée à l’évaluation des agents en situation, prolongera ensuite ce sujet au-delà des benchmarks.

Les six questions à poser devant un tableau de scores

De tout ce qui précède découle une grille de lecture simple. Devant un tableau de scores publié au lancement d’un modèle, posez ces six questions dans l’ordre.

1. Qui a produit le chiffre ? Le fabricant lui-même, ou un évaluateur indépendant ?
2. Sur quelle version du test, et à quelle date le chiffre a-t-il été relevé ? Un même nom de benchmark peut recouvrir des jeux de questions différents, et un classement vivant change en quelques jours.
3. Avec quel protocole ? Les sept éléments décrits plus haut, et en particulier le nombre de tentatives, le budget de calcul et les outils autorisés.
4. L’écart dépasse-t-il le bruit de mesure ? Sur un test de deux cents questions, il faut plusieurs points pour que l’écart soit autre chose que du hasard.
5. L’écart se retrouve-t-il sur plusieurs familles de tests ? Un modèle en tête sur un seul test a peut-être été préparé pour ce test.
6. Le test mesure-t-il votre usage ? Un questionnaire académique ne prédit pas une tâche d’agent. Les quinze capacités listées plus haut vous donnent la liste de ce qu’il faudrait idéalement vérifier, à rapporter à votre usage réel.

Un score de benchmark reste utile, à condition de le lire comme le résultat d’une expérience et non comme une propriété du modèle. Cette lecture a un coût de vérification, et c’est ce coût qui explique pourquoi les communications de lancement continuent de fonctionner comme argument commercial : presque personne ne remonte jusqu’au protocole. Les six questions ci-dessus ramènent ce travail à quelques minutes par tableau.

Le prochain article passe en revue les benchmarks du marché un par un. Pour chaque test, il dit qui le gère et dans quelle version il existe. Il précise surtout la confiance que l’on peut accorder à ses scores. En attendant, vous pouvez poursuivre la discussion sur mon profil LinkedIn.

Bibliographie et sources

• Mathematical Association of America, épreuves sur invitation dont l’AIME.
• Chollet et collègues, « ARC-AGI-2: A New Challenge for Frontier AI Reasoning Systems ».
• Chiang et collègues, « Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference ».
• Chen et collègues, « Evaluating Large Language Models Trained on Code », qui définit la notation pass@k.
• OpenAI, « Learning to reason with LLMs ».
• OpenAI, « Why we no longer evaluate SWE-bench Verified ».
• Zhang et collègues, « A Careful Examination of Large Language Model Performance on Grade School Arithmetic », étude GSM1k.
• « Search-Time Data Contamination », sur les marqueurs cachés et la contamination.
• Epoch AI, FrontierMath v2.
• Gema et collègues, « Are We Done with MMLU? ».
• Thinking Machines Lab, « Defeating Nondeterminism in LLM Inference ».