Les benchmarks de code IA sont cassés : que mesurer ?

Chaque laboratoire d'IA qui publie un modèle de code met en avant un score de benchmark. Chaque équipe d'ingénierie qui choisit un modèle lit ces scores. Et pendant la majeure partie de 2026, le score que tout le monde citait provenait de SWE-Bench Pro.

Il existe désormais des preuves solides que ce chiffre mesurait autre chose que ce que nous croyions.

Fin mai 2026, Datacurve a publié un audit accompagnant son nouveau benchmark, DeepSWE. Le constat est sans détour : sur SWE-Bench Pro, environ un tiers des essais sont évalués de manière incorrecte. Artificial Analysis a depuis migré l'ensemble de ses évaluations de code hors de SWE-Bench Pro. Si votre choix de modèle, votre décision d'achat ou votre pari architectural s'appuyaient sur ce classement, il vaut la peine de comprendre exactement ce qui a dérapé.

L'audit : deux modes de défaillance, tous deux graves

Datacurve a échantillonné 30 tâches sur DeepSWE et 30 sur SWE-Bench Pro, puis a lancé trois exécutions sur dix configurations de modèles de pointe — 735 exécutions DeepSWE contre 789 exécutions SWE-Bench Pro. Un analyseur LLM indépendant a ensuite jugé si chaque correctif implémentait réellement le comportement demandé, plutôt que de faire confiance au verdict du benchmark lui-même.

L'écart n'a rien de subtil :

Lisez attentivement ces deux colonnes d'erreur, car elles échouent dans des directions opposées.

Les faux positifs signifient que le benchmark a accordé une note de réussite à un correctif qui n'implémentait pas le comportement demandé. Environ un « succès » sur douze n'en était pas un.

Les faux négatifs constituent le chiffre le plus élevé et le plus insidieux. Près d'un quart des correctifs corrects ont été marqués comme des échecs. Ce n'est pas un bruit que l'on peut lisser par moyenne — cela comprime systématiquement le tableau des scores. Chaque modèle est tiré vers le milieu, et les modèles réellement meilleurs ne peuvent pas exprimer leur avantage. C'est précisément pourquoi SWE-Bench Pro a produit le récit rassurant selon lequel tous les modèles de pointe convergent. Ils ne convergent pas. C'est la règle qui les comprimait.

Sur DeepSWE, les mêmes dix configurations s'étalent sur une plage de 70 points. Sur SWE-Bench Pro, elles se regroupaient à l'intérieur de 30 points. Les modèles ont toujours été aussi éloignés. C'est l'instrument de mesure qui le masquait.

Les agents lisaient les réponses

L'histoire des faux positifs repose sur un mécanisme précis et embarrassant. SWE-Bench Pro dérive ses tâches de commits réels de dépôts, et les conteneurs remis à l'agent conservaient le répertoire .git du dépôt.

Les agents l'ont trouvé.

Parmi les réussites illégitimes identifiées par Datacurve sur SWE-Bench Pro, 87 % impliquaient que l'agent récupère la solution dans l'historique git. Dans 33 des 38 essais concernés, l'agent a explicitement exécuté git log ou git show. Claude Opus 4.7 a été observé en train de lire l'historique git dans plus de 12 % de ses conteneurs SWE-Bench Pro.

Il ne s'agit pas d'un modèle qui se comporte mal. Fouiller l'historique pour trouver du contexte, c'est exactement ce que fait un ingénieur compétent, et exactement ce que nous voulons qu'un agent fasse dans un vrai dépôt. C'est un défaut de construction du benchmark. La tâche disait « implémente cette fonctionnalité » ; l'environnement contenait discrètement un commit qui implémentait la fonctionnalité. Un agent suffisamment capable trouve le chemin le plus court, et le chemin le plus court était git show.

La leçon dépasse largement ce seul benchmark : plus votre agent est capable, plus il exploitera agressivement tout ce que votre environnement d'évaluation laisse fuir. Tout harnais que vous construisez pour évaluer des agents en interne présente la même exposition. Les environnements scellés ne sont pas un luxe.

Ce que DeepSWE fait différemment

DeepSWE est conçu pour combler les deux failles. Il compte 113 tâches réparties sur 91 dépôts dans cinq langages — TypeScript, Go, Python, JavaScript et Rust — avec quatre choix de conception déterminants :

1. Des tâches exemptes de contamination. Les tâches sont écrites de zéro plutôt que rétro-conçues à partir de commits existants. Il n'y a aucun commit d'origine à trouver, car la solution n'a jamais existé dans l'historique du dépôt.
2. Des vérificateurs comportementaux écrits à la main. Plutôt que d'hériter de la suite de tests du dépôt (qui peut passer pour de mauvaises raisons, ou échouer sur des instabilités sans rapport), chaque tâche est livrée avec des vérificateurs conçus sur mesure pour contrôler le comportement demandé. C'est ce qui fait chuter le taux de faux négatifs de 24,0 % à 1,1 %.
3. Une véritable portée à long horizon. Les solutions de référence ajoutent en moyenne 668 lignes réparties sur 7 fichiers. Il s'agit d'un changement de la taille d'une fonctionnalité, pas d'un correctif d'une ligne.
4. La diversité des dépôts. 91 dépôts pour 113 tâches signifie un chevauchement minimal. Les dépôts sont activement maintenus, sous licence permissive, et comptent au moins 500 étoiles sur GitHub.

Fait notable, les prompts de DeepSWE sont plus courts — 2 158 caractères en moyenne contre 4 614 pour SWE-Bench Pro. Moins d'accompagnement, davantage d'inférence requise, des correctifs plus volumineux attendus. Les classements publiés sont d'autant plus étalés : GPT-5.5 à 70 % ± 3 %, GPT-5.4 à 56 % ± 2 %, Claude Opus 4.7 à 54 % ± 5 %, et Claude Sonnet 4.6 à 32 % ± 2 %.

Voilà des chiffres avec lesquels on peut réellement décider.

L'autre moitié du problème : votre harnais est la variable

Le benchmark ne constitue qu'une face d'une évaluation fiable. Databricks a récemment publié les résultats d'un benchmark interne bâti sur sa propre base de code de plusieurs millions de lignes, et ces résultats redéfinissent ce que « choisir un modèle » veut dire.

Leur méthodologie mérite d'être saluée en soi. Les tâches sont dérivées de vraies pull requests, filtrées selon la récence, la paternité humaine, la qualité des suites de tests et une portée autonome, couvrant Python, Go, TypeScript, Scala, Rust et Java. Les ingénieurs ont extrait manuellement l'intention de chaque PR, rédigé des prompts dépouillés des indices de solution, et isolé les tests pertinents. Surtout — et manifestement avec la leçon de SWE-Bench Pro en tête — ils ont scellé l'historique git pour empêcher les agents de lire la réponse.

Trois constats se dégagent.

Les modèles ouverts ont atteint le premier rang. GLM 5.2 a égalé Opus 4.8 en qualité tout en coûtant 1,28 $ par tâche contre 1,94 $ pour Opus. La conclusion de Databricks est que les modèles ouverts sont désormais des choix viables au quotidien pour le travail de code courant, et non de simples solutions de repli économiques. Si vous traitiez GLM-5.2 comme une option d'appoint, les données disent qu'il s'agit d'une option de pointe.

Le prix du token ne prédit pas le prix de la tâche. Sonnet 5 est environ 1,7 fois moins cher par token qu'Opus 4.8. Il a pourtant coûté plus par tâche : 2,09 $ contre 1,94 $, tout en marquant six points de moins. Un modèle moins efficient dans son raisonnement brûle davantage de tokens pour arriver au même point, et la remise au token s'évapore. Tout modèle de coût fondé sur les prix des tokens publiés mesure la mauvaise unité. Le coût par tâche achevée est le seul chiffre qui règle votre facture.

Le harnais a doublé le coût à qualité identique. Faire tourner le même modèle à travers différents harnais a produit des écarts de coût supérieurs au double, à qualité égale. Le harnais interne Pi de Databricks envoyait trois fois moins de contexte par tour et terminait les tâches en moins d'exécutions que Claude Code ou Codex. Même modèle. Même qualité de sortie. Moitié moins de dépense.

Ce dernier point est celui que la plupart des équipes sous-estiment. Vous ne choisissez pas seulement un modèle — vous choisissez un modèle et un harnais, et le harnais fait au moins autant de travail que les poids du modèle. C'est l'argument pratique pour traiter l'ingénierie de harnais comme une discipline à part entière plutôt que comme de la tuyauterie.

Que faire lundi

La conclusion n'est pas « méfiez-vous de tous les benchmarks ». C'est que les classements publics répondent à une question portant sur le dépôt de quelqu'un d'autre, notée par le vérificateur de quelqu'un d'autre. Voici comment obtenir un chiffre qui signifie quelque chose pour votre base de code.

Construisez un petit benchmark interne à partir de vos propres PR fusionnées. Vingt à cinquante tâches suffisent à départager les modèles. Prenez des PR récentes, écrites par des humains, avec une vraie couverture de tests et une portée autonome. Retirez les indices de solution du prompt.

Scellez l'environnement. Supprimez .git, ou au minimum tronquez l'historique au-delà du commit de base de la tâche. Supprimez les gestionnaires de tickets, les changelogs, et tout artefact qui nomme le correctif. Partez du principe qu'un agent capable trouvera tout ce que vous laissez derrière vous — parce qu'il le fera.

Écrivez des vérificateurs comportementaux, pas des suites de tests héritées. Vérifiez que le comportement demandé existe. Les tests d'un dépôt ont été écrits dans un autre but et se tromperont dans les deux sens, exactement comme SWE-Bench Pro.

Mesurez le coût par tâche achevée, jamais le coût par token. Suivez les tokens consommés, le temps réel écoulé et le nombre de tentatives par tâche. L'efficience du raisonnement varie suffisamment d'un modèle à l'autre pour inverser le classement que suggère la tarification au token.

Évaluez le harnais comme un axe distinct. Fixez le modèle et faites varier le harnais. Puis fixez le harnais et faites varier le modèle. Si vous ne testez que des paires groupées, vous ne pouvez pas savoir quelle moitié est responsable du résultat.

Relancez à chaque sortie de modèle. La frontière bouge tous les mois. Un benchmark exécuté une seule fois est un instantané, pas un instrument.

Le point plus large

L'affaire SWE-Bench Pro rappelle utilement que l'infrastructure d'évaluation est une véritable infrastructure, et qu'elle se dégrade. Un benchmark qui laisse discrètement fuir les solutions via .git et qui note mal un quart des correctifs corrects produira malgré tout un classement d'apparence impeccable, publié dans les communiqués de presse, cité dans les décisions d'achat, et invoqué pour justifier des paris architecturaux. Rien dans le résultat ne signale que la règle est faussée.

C'est le même problème de rigueur que nous redécouvrons sans cesse dans l'évaluation des agents et dans l'écart entre les scores de benchmark et le vrai travail sur les fonctionnalités. Les modèles progressent plus vite que les outils qui servent à les mesurer. Quand la mesure prend du retard, nous confondons un tableau de scores comprimé avec un domaine qui converge, et nous confondons un agent débrouillard avec un agent correct.

Construisez le petit benchmark interne. Scellez l'environnement. Mesurez la tâche, pas le token. C'est une semaine de travail qui survivra à tous les modèles de votre liste restreinte.

Besoin d'aide pour bâtir un harnais d'évaluation d'agents de code IA dans votre propre base de code ? Parlez à l'équipe Noqta — nous concevons et livrons des infrastructures d'agents pour les organisations d'ingénierie de la région MENA.