Pourquoi les bancs d’essai de programmation en IA sont-ils si difficiles à comparer en 2026?

Un banc d’essai (benchmark) est un ensemble fixe de tâches accompagné d’une façon automatique de noter les réponses. En programmation, les tâches sont généralement de vrais bogues ou de vraies fonctions dans de vrais projets, et la note dépend de la réussite des tests du projet après coup. L’idée est solide. Le problème, en 2026, c’est que les chiffres des annonces de lancement sont rarement mesurés deux fois de la même façon.

Même les laboratoires le disent. Dans son annonce de Claude Opus 5.5, Anthropic écrit qu’au niveau de capacité actuel, les écarts sur ses bancs d’essai sont devenus un moins bon indicateur des différences réelles qu’avant. Voici pourquoi, avec des exemples que vous pouvez vérifier.

Raison 1 : chaque laboratoire choisit ses tests

Anthropic met en tête de son tableau pour Opus 5.5 Terminal-Bench 4.0, FrontierCode et CursorBench. Le billet de SpaceXAI sur Grok 4.7 utilise CursorBench, DeepSWE, Terminal-Bench et un test de génie électrique. OpenAI met de l’avant DeepSWE et des tests de flux de travail d’entreprise pour GPT-6.1 Sol. Chaque entreprise montre les tests où son modèle paraît bien, et un test qu’un laboratoire passe sous silence est souvent un test que son modèle trouve difficile.

Les versions ajoutent une couche. Terminal-Bench 2.1 et Terminal-Bench 4.0 sont des ensembles de tâches différents, et des fiches de modèles ouverts comme celle de Qwen3.8-27B rapportent encore l’ancien. Un 73 % sur la version 2.1 et un 66 % sur la version 4.0 ne se comparent pas du tout.

Raison 2 : un même modèle, des scores différents

Un même modèle, sur un même test, peut porter deux chiffres. Anthropic indique 55,8 % pour Claude Fable 5.1 sur Terminal-Bench 4.0. Le tableau de SpaceXAI pour Grok 4.7 indique 57,9 % pour Fable 5.1 sur ce même test. Aucun des deux n’a nécessairement tort : les laboratoires ont pu utiliser des réglages d’effort, des limites de temps, des nouvelles tentatives ou des logiciels d’agent différents.

Raison 3 : les réglages et les harnais changent le résultat

Trois choix font bouger les scores de plusieurs points :

• L’effort. La plupart des modèles vous laissent régler la durée de leur réflexion. Le chiffre d’Anthropic sur Terminal-Bench pour Opus 5.5 est à l’effort « xhigh », son chiffre pour GPT-6 Astra est à l’effort « high », et chacun est le meilleur résultat de ce modèle. SpaceXAI marque un des scores de Grok 4.7 comme obtenu à effort élevé et les autres à « xhigh ».
• Le harnais. Le harnais (harness) est le logiciel d’agent qui entoure le modèle : il lui remet les fichiers, lance les commandes et décide quand s’arrêter. Les exécutions publiques de Terminal-Bench citées par Anthropic utilisent le harnais de Claude Code. L’Android Bench de Google fait rouler les modèles Claude dans Claude Code, les modèles GPT dans Codex et Gemini dans la trousse d’agent de Google. Un meilleur harnais peut faire monter un modèle plus faible.
• Les modèles de repli de sécurité. Anthropic précise que lorsque les mesures de protection d’Opus 5.5 sont intervenues, un modèle plus ancien a terminé la tâche, ce qui a probablement abaissé ses scores.

Raison 4 : petits échantillons, grandes marges d’erreur

Les bancs d’essai sont des échantillons, et les échantillons sont bruyants. Anthropic donne une erreur type d’environ 2,6 points pour Opus 5.5 sur Terminal-Bench 4.0 : une nouvelle exécution pourrait facilement tomber quelques points plus loin. L’Android Bench de Google ne compte que 30 longues tâches. Son meneur, Claude Sonnet 5.5, en résout 40,0 %, mais Google donne une fourchette probable de 24,0 % à 56,0 %. Le modèle en sixième place, Gemini 4 Argon à 21,3 %, a une fourchette qui monte jusqu’à 33,3 %. La plupart des six premiers pourraient changer de place à une autre exécution.

Raison 5 : le coût manque à la plupart des manchettes

Un score sans prix cache la moitié de l’histoire. Sur l’Android Bench, une exécution complète a coûté environ 99,5 $ US avec GPT-6.1 Sol et environ 1 574,9 $ US avec Claude Sonnet 5.5 à l’effort maximal. Les laboratoires tracent de plus en plus la précision en fonction du coût par tâche, ce qui est bien plus utile qu’un chiffre isolé.

Comment tester un modèle de programmation sur votre propre travail?

Bâtissez un petit examen à partir de votre propre historique. Choisissez de cinq à dix tâches fermées dans un projet que vous connaissez : des bogues que vous avez corrigés, des fonctions que vous avez ajoutées, chacune avec un test qui prouve qu’elle fonctionne. Récupérez le code tel qu’il était avant chaque correction, pour que le modèle parte d’où vous êtes parti.

Faites ensuite travailler chaque modèle de la même façon : même outil d’agent, mêmes consignes, même réglage d’effort. Un prompt court et fixe garde le tout équitable :

Voici un ticket de ce dépôt : [colle le texte du ticket]. Corrige-le. Lance la suite de tests avant de terminer. Ne modifie ni ne supprime aucun test existant. À la fin, énumère les fichiers que tu as changés et pourquoi.

Notez chaque essai sur une feuille simple : les tests ont-ils réussi, combien de lignes avez-vous dû corriger, combien de temps cela a-t-il pris, et combien cela a-t-il coûté ou quelle part de l’allocation de votre forfait a été utilisée. Faites chaque tâche deux fois, parce que les modèles varient d’une exécution à l’autre.

Dix tâches ne diront pas quel modèle est le meilleur en général, et ce n’est pas le but. Elles vous disent quel modèle fonctionne le mieux sur votre code, avec vos habitudes, à un prix que vous pouvez assumer. Refaites l’examen à chaque nouveau modèle, et vous aurez rarement besoin de croire un chiffre de manchette.