Un tweet à 23 h 41
Le 8 juillet au soir, le compte officiel d’OpenAI publie un message que peu d’éditeurs oseraient écrire : « Nous avons audité SWE-Bench Pro, l’un des benchmarks de codage IA les plus utilisés, et constaté qu’il ne mesure plus de façon fiable la capacité de codage à la frontière. Nous estimons que 30 % de ses tâches sont cassées, et nous rétractons notre recommandation antérieure de l’utiliser comme évaluation de référence. » Le lendemain matin, la même entreprise lançait GPT-5.6, son nouveau modèle de codage.
Il faut savourer la situation dans toute son épaisseur. SWE-Bench Pro n’est pas un benchmark obscur : c’est celui que la presse spécialisée, les tableaux comparatifs et les fils de discussion citent en premier pour départager les agents de codage. C’est aussi celui qu’OpenAI recommandait officiellement depuis février. Et février, justement : c’était déjà la deuxième fois. Cinq mois plus tôt, la même entreprise avait déclaré inutilisable le prédécesseur, SWE-bench Verified, et conseillé de migrer vers Pro. En cinq mois, le principal laboratoire du secteur a donc déclaré cassés, l’un après l’autre, les deux instruments de référence de sa propre discipline, dont celui qu’il avait lui-même intronisé.
La tentation est d’y lire un scandale, des chiffres truqués, une manœuvre. La réalité est plus intéressante et plus inconfortable : c’est une histoire de métrologie. Les benchmarks de code ne sont pas devenus mauvais ; ils se sont périmés sous les progrès de ce qu’ils mesuraient, et une deuxième variable, longtemps ignorée, s’est mise à peser plus lourd que le modèle lui-même. Ce dossier démonte le mécanisme, pièce par pièce, parce qu’il concerne quiconque a déjà choisi un modèle sur la foi d’un tableau de scores.
Comment une tâche de benchmark casse
Commençons par ce que mesure SWE-Bench Pro, parce que le principe est sain. On donne au modèle un vrai dépôt de code et un ticket réel (« ce parseur gère mal tel cas »), il doit produire un correctif, et des tests cachés décident si le correctif est bon. Pas de QCM, pas de puzzle artificiel : du travail d’ingénieur, jugé comme en production. Sur le papier, c’est le meilleur protocole qu’on connaisse.
Le problème est industriel : ces tâches sont fabriquées en chaîne, extraites programmatiquement de changements de code réels. Or un vrai changement de code n’est pas conçu pour devenir un énoncé d’examen. L’audit d’OpenAI classe les casses en quatre familles, et chacune mérite un instant.
La plus grosse : les tests trop stricts. Le ticket demande de corriger un comportement, les tests cachés vérifient en plus des détails d’implémentation que personne n’a spécifiés. Une solution parfaitement correcte échoue parce qu’elle n’est pas la solution historique. Vient ensuite son symétrique, l’énoncé sous-spécifié : des exigences existent bel et bien, mais uniquement dans les tests, invisibles depuis le ticket. L’exemple relevé par l’audit est éloquent : une tâche du projet OpenLibrary montre dans l’énoncé une chaîne avec une espace simple, et le test caché en exige deux. Aucun ingénieur humain ne réussirait ce genre d’épreuve autrement que par hasard. Troisième famille, l’inverse exact : les tests à trop faible couverture, qui laissent passer des correctifs incomplets. Et enfin l’énoncé trompeur, qui aiguille activement vers la mauvaise approche.
Notez ce que ces quatre familles ont en commun : aucune ne parle du modèle. Ce sont des défauts de conception des tâches, énoncés et tests qui ne s’alignent pas. C’est un point important, parce que le diagnostic de février sur Verified, lui, était différent (nous y venons) : les benchmarks de code ne meurent pas tous de la même maladie.
Le plafond de bruit, ou pourquoi un instrument se périme
La formulation d’OpenAI mérite une lecture au mot près : SWE-Bench Pro « ne mesure plus » la frontière de façon fiable. Plus. Il a donc mesuré quelque chose, un temps. Que s’est-il passé entre-temps ? Les modèles ont progressé.
Les chiffres racontent l’histoire mieux qu’un discours : sur le jeu public de 731 tâches, les meilleurs modèles sont passés de 23,3 % de réussite à 80,3 % en huit mois. Or si environ 30 % des tâches sont cassées, le score maximal réellement atteignable par un agent parfait plafonne quelque part autour de 70 %. Tant que les modèles rament à 25 ou 40 %, ce plafond ne gêne personne : les écarts entre modèles se jouent sur les tâches valides, et l’instrument classe correctement. Mais dès que les scores s’approchent du plafond, tout s’inverse. Les points qui restent à gagner sont, pour l’essentiel, des tâches défectueuses ; les départager revient à mesurer quel modèle devine le mieux les caprices de tests mal conçus. Comme un capteur saturé, l’instrument écrase tout ce qui dépasse dans la même zone plate, et les écarts qu’on y lit sont du bruit.
C’est le mécanisme central de ce dossier, et il est général : un benchmark n’est pas vrai ou faux dans l’absolu, il est utilisable dans une plage. La frontière de 2026 est simplement sortie de la plage utile des benchmarks conçus en 2024. Ils ne se sont pas trompés ; ils ont été dépassés, au sens propre.
L’audit lui-même vaut le détour, pour sa méthode et pour son ironie. OpenAI a d’abord fait tourner un pipeline d’analyse sur les tentatives des modèles, leurs traces d’échec et les métadonnées des tâches, avec des agents investigateurs basés sur Codex, capables d’ouvrir les vrais dépôts et de lancer les tests. Ce pipeline a signalé 200 tâches cassées (27,4 %). En parallèle, cinq ingénieurs expérimentés ont mené une campagne d’annotation humaine, qui en a identifié 249 (34,1 %), avec 74 % d’accord entre les deux approches, d’où l’estimation médiane d’environ 30 %. La méthode est sérieuse. L’ironie aussi : ce sont des agents Codex qui ont audité le benchmark chargé d’évaluer Codex. L’outil jugé certifie désormais l’instrument de mesure ; on ne saurait mieux illustrer où en est la discipline.
Trois générations d’instruments, trois morts : la chronologie
Reprenons le fil depuis le début, parce que d’une part les périmètres exacts de chaque chiffre sont précisément ce que la presse écorche le plus, et d’autre part la rétractation de juillet n’est pas le deuxième épisode de cette histoire. C’est le troisième.
| Instrument | Né | Déclaré cassé | Cause principale |
|---|---|---|---|
| SWE-bench (Princeton) | fin 2023 | 2024, par OpenAI | tâches insolubles ou sous-spécifiées |
| SWE-bench Verified (OpenAI) | août 2024, 500 tâches triées à la main | 23 février 2026 | défauts de tests + contamination + saturation |
| SWE-Bench Pro (Scale AI) | septembre 2025, conçu anti-contamination | 8 juillet 2026 | ~30 % de tâches cassées (conception) |
À l’origine, il y a SWE-bench tout court, créé par des chercheurs de Princeton fin 2023 : l’idée fondatrice, brillante, de transformer de vrais tickets GitHub en épreuves d’examen. Dès 2024, OpenAI constate que le benchmark est truffé de tâches insolubles ou sous-spécifiées, et publie le remède : SWE-bench Verified, 500 tâches triées à la main par des développeurs professionnels payés pour relire chaque énoncé. Retenez ce détail, il donne sa vraie profondeur à la suite : Verified n’était pas un benchmark parmi d’autres, c’était déjà la version corrigée, validée par des humains, co-construite par OpenAI lui-même. C’est ce remède qui casse en février 2026. Et SWE-Bench Pro, conçu chez Scale AI justement pour résister au mal suivant (la contamination Présence des données d'un benchmark (énoncés, solutions) dans le corpus d'entraînement d'un modèle. Le score mesure alors la mémorisation, pas la capacité : le modèle reconnaît l'épreuve au lieu de la résoudre. Inévitable à terme pour tout benchmark public construit à partir de dépôts publics. , avec des dépôts sous licences dissuasives et un jeu privé), est le remède du remède. Il aura tenu moins d’un an. Trois générations, trois conceptions de plus en plus soignées, trois péremptions de plus en plus rapides : ce n’est pas une série d’accidents, c’est une course entre les instruments et ce qu’ils mesurent, et les instruments la perdent.
Le 23 février 2026, donc, OpenAI publie « Why we no longer evaluate SWE-bench Verified ». L’audit ne porte pas sur tout le benchmark : il cible les 138 problèmes (sur 500) que son modèle o3 échouait de façon répétée sur 64 tentatives, le sous-ensemble difficile. Verdict : au moins 59,4 % de ce sous-ensemble présente des défauts substantiels, tests ou description, dont 35,5 % de tests trop stricts. Rapporté au benchmark entier, cela fait au moins 16 % de tâches cassées, pas 59 : le chiffre spectaculaire est vrai, mais sur un périmètre qu’il faut citer avec lui. Le symptôme qui avait déclenché l’audit parle de lui-même : la progression des modèles y stagnait, de 74,9 à 80,9 % en six mois, le tassement caractéristique d’un instrument qui arrive en butée.
S’y ajoutait un mal que Pro n’a pas au même degré : la contamination. Un papier accepté à NeurIPS, au titre limpide (« The SWE-Bench Illusion »), avait montré que les meilleurs modèles retrouvaient le fichier à corriger dans 76 % des cas à partir du seul texte du ticket, sans même voir le dépôt, contre 53 % sur des tâches issues de dépôts hors benchmark. Les modèles ne résolvaient pas toujours le problème ; parfois, ils s’en souvenaient.
Le 10 mars, l’institut d’évaluation METR ajoute la pièce qui manquait : même quand les tests passent, le travail est-il bon ? Quatre mainteneurs de projets open source majeurs ont relu 296 correctifs générés par IA et déclarés « résolus » par le correcteur automatique. Leur verdict de fusion est inférieur d’environ 24 points aux scores du benchmark : autour de 72 % de tâches « réussies », environ 48 % de correctifs qu’un mainteneur accepterait réellement. La moitié du vert affiché n’aurait pas passé une revue de code humaine, pour les raisons habituelles : fonctionnalité manquée, régression ailleurs, qualité insuffisante.
Et le 8 juillet, donc, Pro tombe à son tour, pour des raisons de conception de tâches cette fois. Trois diagnostics différents en cinq mois (contamination, écart tests/mergeable, tâches défectueuses), trois angles du même constat : à la frontière, le chiffre affiché et la capacité réelle ont divorcé.
La variable cachée qui vaut une génération de modèle
Il manque encore un étage à l’explication, et c’est le plus contre-intuitif. Admettons un benchmark aux tâches parfaites : le score obtenu mesurerait-il enfin « le modèle » ? Non plus. Car un modèle ne passe jamais un benchmark seul : il le passe dans un harnais, cet attirail d’outils, de prompt système, de boucle d’exécution et de gestion du contexte que nous avons disséqué dans le dossier sur la remontada d’OpenAI. Et l’effet du harnais sur les scores n’est pas un détail de second ordre. C’est un terme du même ordre de grandeur que le progrès d’une génération de modèle.
Les mesures s’empilent :
Un papier de recherche dédié (Claw-SWE-Bench) chiffre jusqu’à 27,4 points d’écart de réussite entre harnais, sur le même modèle et les mêmes 350 tâches. Endor Labs a mesuré GPT-5.5 à 61,5 % dans le harnais natif de Codex et 87,2 % dans celui de Cursor, la même semaine : 25,7 points. Un test indépendant a fait varier Opus de 42 % avec un échafaudage minimal à 78 % avec le harnais complet de Claude Code : 36 points, sans toucher au modèle. LangChain a gagné 13,7 points sur Terminal Bench en ne modifiant que son harnais, modèle strictement identique. La presse spécialisée retient une fourchette de 10 à 20 points d’écart courants sur SWE-bench à modèle constant, et OpenAI en fournit lui-même une démonstration involontaire dans l’annonce de GPT-5.6 : Sol seul obtient 88,8 % sur Terminal-Bench 2.1, et 91,9 % quand son mode « ultra » coordonne quatre agents. Même modèle, plus trois points, il a suffi de changer l’orchestration.
Et même à couple modèle-harnais fixé, il reste la variance ordinaire. Un agent n’est pas déterministe : d’un run à l’autre, il explore différemment, échoue ou réussit des tâches limites. Les protocoles sérieux moyennent plusieurs graines aléatoires (les évaluations cyber d’OpenAI en utilisent cinq par mesure) ; les tableaux de la presse, eux, comparent souvent des runs uniques. Deux ou trois points d’écart entre modèles, sur un run, sans intervalle de confiance : ce n’est pas un classement, c’est un tirage.
La conséquence est brutale pour la façon dont on parle de ces systèmes : « le score du modèle X » n’existe pas. Il n’existe que le score d’un couple modèle-harnais, dans une configuration donnée, à une date donnée, moyenné ou non. Quand deux tableaux donnent des chiffres incompatibles pour « le même modèle », il y a de bonnes chances que les deux soient exacts.
Reste à expliquer pourquoi les instruments se périment de plus en plus vite, et la réponse tient dans une vieille loi de la mesure : quand une métrique devient un objectif, elle cesse d’être une bonne métrique. Un benchmark public de référence n’est pas un thermomètre neutre posé à côté du marché ; il est la cible, explicite ou non, de laboratoires qui pèsent des centaines de milliards et communiquent à coups de points gagnés. Chaque cycle d’entraînement absorbe un peu plus du benchmark, par contamination directe des corpus ou par simple pression de sélection sur ce qui score. Plus l’industrie optimise vite, plus la durée de vie utile d’un étalon public raccourcit. Le SWE-bench originel n’a pas tenu un an avant d’exiger sa version corrigée ; Verified a tenu dix-huit mois ; Pro, moins d’un an. La suite est prévisible.
Ce que les vendeurs publient, et ce qu’il faut en croire
Ce paysage éclaire d’un jour particulier la communication du 9 juillet. Loin de faire l’impasse sur les benchmarks, l’annonce de GPT-5.6 en aligne tout l’éventail : les académiques classiques (GPQA, AIME, MMLU) comme les agentiques. Elle publie même un score sur ce SWE-Bench Pro que l’entreprise venait de déclarer cassé, et sur lequel Sol reste d’ailleurs derrière Fable 5, 64,6 % contre 80 %. Deux ancres, pourtant, appellent la prudence : l’index d’Artificial Analysis, donné comme tiers, est un partenaire de pré-évaluation d’OpenAI, un juge de qualité plus qu’un juge indépendant ; et une note de bas de page précise que les latences et coûts affichés sont simulés hors ligne, pas mesurés en production.
Il faut aussi rapporter la séquence dans son ordre exact, parce qu’elle nourrit une lecture qu’on ne peut ni affirmer ni ignorer. Sur SWE-Bench Pro, les modèles d’Anthropic dominaient nettement : 69,2 % pour Opus 4.8 contre 58,6 % pour GPT-5.5 au printemps. Le benchmark où OpenAI perdait le plus visiblement est celui qu’il a désavoué le 8 juillet, la veille du lancement de son modèle. À décharge, l’annonce du lendemain n’a pas escamoté le chiffre : le score défavorable y figure, désaveu compris. Si manœuvre il y a, elle est donc plus subtile : publier le chiffre et discréditer l’étalon dans le même geste. Voilà les faits datés ; la lecture stratégique reste une hypothèse, et l’honnêteté oblige à dire que la critique méthodologique, elle, est solide, corroborée par des travaux indépendants qui n’ont rien à vendre (le papier NeurIPS sur la contamination, la note METR). Ajoutons l’ironie complète : la rétractation n’épargne personne. Le 69,2 % d’Anthropic repose sur le même instrument déclaré cassé ; les scores brandis dans un sens comme dans l’autre flottent désormais sur les mêmes 30 % de tâches défectueuses. Personne ne sort grandi d’un étalon faussé.
Se mesurer soi-même
Que reste-t-il, alors ? La recommandation d’OpenAI tient en une ligne et elle est exigeante : des benchmarks construits directement par des ingénieurs expérimentés, avec une supervision humaine intégrée dès la conception, et non générés en chaîne puis vérifiés après coup. Concrètement, cela ressemble aux évaluations de type GDPval que l’entreprise met désormais en avant : des tâches rédigées une à une par des professionnels du métier, avec un barème, jugées par des humains, au coût de fabrication assumé. C’est l’aveu que la mesure de qualité ne s’industrialise pas : ce qui rendait SWE-bench séduisant (des milliers de tâches gratuites extraites de GitHub) est précisément ce qui l’a tué. Aucun successeur n’est adoubé pour autant ; la discipline repart de la planche à dessin.
En attendant, deux familles d’outils gardent de la valeur, précisément parce qu’elles ont intégré le problème. Les trackers indépendants, d’abord : Marginlab fait tourner quotidiennement Codex sur un sous-ensemble de tâches résistant à la contamination, cinquante instances par jour, sans harnais personnalisé, avec un test statistique avant de déclarer une dérive ; c’est ce protocole qui a détecté fin mai une dégradation de 8 points de Claude Code, invisible dans les benchmarks statiques. Scale SEAL, que nous citions déjà dans le dossier GLM-5.2, joue le même rôle d’étalon standardisé. Leur valeur ne vient pas de tâches miraculeusement parfaites, mais du protocole : conditions constantes, mesures répétées, seuils de signification. De la métrologie, au sens plein.
La seconde famille, c’est la vôtre. Les équipes qui s’en sortent le mieux ont cessé de lire les tableaux des autres et se sont construit des évaluations internes sur leur propre code : des défauts réels injectés dans leurs propres pull requests, leurs langages, leurs conventions, jugés sur ce qu’un relecteur humain accepterait. À plus petite échelle, le protocole minimal tient en une phrase : avant de changer de modèle ou d’outil, prenez cinq tâches réelles de votre backlog, faites-les tourner en A/B, mesurez le temps de revue et le taux d’erreur, et décidez sur ça. Cinq tâches de votre dépôt valent mieux que sept cents tâches cassées de celui des autres.
Une confession de méthode, pour finir, parce qu’elle illustre le réflexe à installer. Notre dossier GLM-5.2, publié trois semaines avant la rétractation, citait des scores SWE-Bench Pro. Nous les avions étiquetés chiffres constructeur, non répliqués, avec l’index agrégé indépendant comme seule ancre de niveau ; c’est ce qui leur permet de vieillir dignement aujourd’hui : l’étiquette a survécu à l’instrument. C’est exactement le contrat que la mesure des agents de codage impose désormais à tout le monde, éditeurs, presse et lecteurs : chaque chiffre avec son périmètre, sa date, son harnais et son juge. La frontière progresse plus vite que ses instruments ; il n’y a aucune raison que ça s’arrête, et les benchmarks qui remplaceront SWE-Bench Pro se périmeront à leur tour. La mesure n’est plus une lecture, c’est redevenu un travail. Le vôtre, de préférence.
Sources et méthode
Date de gel rédactionnel : 11 juillet 2026. Étiquettes : fait vérifié (source primaire), estimation (analyse tierce), hypothèse (lecture assumée).
La rétractation du 8 juillet
- Fait : OpenAI, Separating signal from noise in coding evaluations (openai.com, 8 juillet 2026) et post officiel @OpenAI sur X (8 juillet, 23 h 41) : 731 tâches, pipeline 200 (27,4 %), revue humaine 249 (34,1 %), accord 74 %, estimation ~30 % ; quatre familles de défauts ; progression 23,3 → 80,3 % en huit mois.
La généalogie des instruments
- Fait : SWE-bench : Jimenez et al., Princeton (arXiv 2310.06770, ICLR 2024). SWE-bench Verified : OpenAI, Introducing SWE-bench Verified (août 2024, 500 tâches validées humainement). SWE-Bench Pro : Scale AI (septembre 2025, conception anti-contamination).
- Fait : OpenAI, Why we no longer evaluate SWE-bench Verified (openai.com, 23 février 2026) : 138/500 problèmes audités, ≥ 59,4 % de ce sous-ensemble défectueux (35,5 % de tests trop stricts), stagnation 74,9 → 80,9 %.
- Fait : The SWE-Bench Illusion (arXiv 2506.12286, Purdue/Microsoft, NeurIPS 2025) : 76 % d’identification du fichier fautif depuis le seul ticket, 53 % hors benchmark, similarité verbatim 35 % contre 18 %.
- Fait : METR, Many SWE-bench-passing PRs would not be merged into main (metr.org, 10 mars 2026) : 296 PR relues par 4 mainteneurs, verdict ~24 points sous le correcteur automatique, baseline « golden » 68 %.
L’effet harnais et la variance
- Fait : Claw-SWE-Bench (arXiv 2606.12344) : jusqu’à 27,4 points entre harnais à modèle constant. Endor Labs : GPT-5.5 à 61,5 % (Codex natif) contre 87,2 % (Cursor), même semaine. LangChain, Improving Deep Agents with harness engineering : +13,7 points à modèle fixe.
- Estimation : Opus de 42 à 78 % selon l’échafaudage (test indépendant publié en avril 2026) ; fourchette « 10-20 points » (presse spécialisée). La fourchette « 5-15 points » qui circule n’a pas de source primaire identifiable : nous ne la reprenons pas.
- Fait : Annonce GPT-5.6 (openai.com, 9 juillet) : SWE-Bench Pro Sol 64,6 % contre Fable 5 80 % ; Terminal-Bench 2.1 à 88,8 % (Sol) contre 91,9 % (mode ultra, 4 agents) ; latences et coûts « simulés » (note 4) ; évaluations cyber à 5 graines par mesure ; Artificial Analysis partenaire de pré-évaluation.
Scores et trackers
- Fait : SWE-Bench Pro : Opus 4.8 à 69,2 %, GPT-5.5 à 58,6 % (billet GPT-5.5 d’avril et trackers) ; Sol à 64,6 % contre 80 % pour Fable 5 (billet GPT-5.6 du 9 juillet, publié avec le désaveu de l’instrument). Marginlab : protocole quotidien, N = 50, p < 0,05, dégradation Claude Code de 8 points détectée fin mai 2026. Scale SEAL : étalon standardisé (cf. dossier GLM-5.2).
Note de méthode. Cet article rapporte la séquence du 8-9 juillet (rétractation la veille du lancement) en faits datés ; toute lecture stratégique est signalée comme hypothèse. Les périmètres des pourcentages (59,4 % sur le sous-ensemble difficile de Verified ; ~30 % sur le jeu public de Pro) sont cités avec chaque chiffre, parce que leur confusion est précisément le mode de déformation que ce dossier documente.
