OpenAI remet publiquement en cause l’un des benchmarks de code les plus scrutés de l’industrie de l’IA, en soutenant qu’une part importante des tâches de SWE-Bench Pro pourrait être suffisamment défectueuse pour fausser les comparaisons entre modèles. Dans une nouvelle analyse publiée par OpenAI, l’entreprise indique que son audit a trouvé des preuves qu’environ 30 % des tâches du benchmark sont cassées.

Cette constatation dépasse le cadre d’un seul jeu de données. Les benchmarks de code comme SWE-Bench Pro sont devenus un raccourci pour évaluer les progrès dans le développement logiciel agentique, influençant les priorités de recherche, la communication autour des lancements et, dans certains cas, la perception des entreprises quant au modèle le mieux adapté au travail de codage. Le point central d’OpenAI est que si les tâches sous-jacentes ne sont pas fiables, les scores mis en avant peuvent en dire moins sur les véritables capacités d’ingénierie logicielle que ne l’imaginent de nombreux créateurs et acheteurs de modèles.

Pourquoi OpenAI conteste un benchmark sur lequel l’industrie s’est appuyée

Selon OpenAI, l’entreprise a commencé à examiner SWE-Bench Pro après avoir conclu auparavant que SWE-bench Verified présentait d’importants problèmes de conception et de contamination. À l’époque, OpenAI avait déclaré avoir encouragé la communauté à se tourner vers SWE-Bench Pro comme test plus solide de tâches de codage plus longues et plus réalistes.

Ce nouveau benchmark a exercé une forte influence, en partie parce qu’il semblait montrer des progrès rapides. OpenAI a écrit que, sur la partition publique de 731 tâches, les modèles de pointe étaient passés d’un taux de réussite de 23,3 % à 80,3 % en huit mois. Une telle progression suggérerait normalement des gains majeurs en capacité de codage pratique.

OpenAI soutient désormais que ces résultats doivent être abordés avec plus de prudence. Dans son dernier audit, l’entreprise indique que sa chaîne interne d’analyse de points de données a signalé 200 tâches, soit 27,4 % du jeu de données, comme cassées. Une campagne séparée d’annotation humaine a identifié 249 tâches, soit 34,1 %, comme cassées. Sur la base de ces examens, OpenAI estime qu’environ 30 % des tâches de SWE-Bench Pro sont défectueuses.

La position de l’entreprise n’est pas que chaque tâche est inutilisable, ni qu’aucun signal ne subsiste. Elle avertit plutôt que les résultats du benchmark doivent être interprétés avec précaution, car une part importante du test peut pénaliser des comportements corrects ou récompenser des correctifs incomplets.

Les modes d’échec spécifiques qu’OpenAI dit avoir trouvés

L’analyse d’OpenAI décompose les problèmes en plusieurs catégories familières à quiconque a travaillé sur des évaluations, surtout dans des tâches logicielles où des tests cachés se substituent au jugement humain.

Une catégorie concerne des tests trop stricts. Selon OpenAI, certaines tâches exigent un détail d’implémentation très précis qui n’est pas mentionné dans le prompt. Cela signifie qu’un modèle peut produire une solution fonctionnellement correcte et échouer malgré tout.

Une deuxième catégorie concerne des prompts insuffisamment spécifiés. Dans ces cas, OpenAI affirme que les tests cachés imposent des exigences qui ne peuvent pas être raisonnablement déduites de la description de la tâche. Cela crée un décalage entre ce que le modèle est censé faire et ce sur quoi il est noté.

Un troisième problème est celui des tests à faible couverture. OpenAI indique que certains tests ne vérifient pas suffisamment si la fonctionnalité demandée a réellement été implémentée, permettant à des correctifs partiels ou incomplets de passer. Pour les acheteurs qui évaluent des systèmes de codage par IA, c’est le mode d’échec inverse des tests trop stricts : le benchmark peut surestimer la capacité, et pas seulement la sous-estimer.

OpenAI a également pointé des prompts trompeurs qui orientent les modèles vers un comportement contraire à ce que les tests attendent ensuite. L’entreprise a cité un exemple impliquant le formatage Markdown d’une table des matières, où le prompt visible et les cas de test cachés différaient par un espace initial. Dans ce scénario, un modèle suivant le prompt tel qu’écrit pourrait tout de même être jugé faux.

Cet exemple va au cœur de la critique plus large. De nombreux problèmes logiciels et pull requests proviennent de dépôts réels pour la collaboration humaine, et non de tâches d’évaluation propres et isolées. OpenAI soutient que lorsque ces artefacts sont transformés en benchmark, le prompt, le patch de référence et les tests ne s’alignent pas toujours assez bien pour permettre un score fiable.

Comment l’audit a été mené, et où subsiste l’incertitude

Les faits les plus solides de cette histoire proviennent de la méthodologie publiée par OpenAI elle-même, mais il s’agit toujours de constats rapportés par le fournisseur plutôt que d’un examen indépendant du benchmark par un tiers.

OpenAI explique avoir mis en place une chaîne d’assurance qualité qui a examiné les instructions des tâches, les tentatives des modèles, les métadonnées et les traces d’échec afin d’identifier les cas problématiques probables. L’entreprise dit qu’un premier filtre automatisé a signalé 286 tâches potentiellement cassées pour un examen plus approfondi.

À partir de là, OpenAI a utilisé deux voies de revue parallèles. L’une impliquait des agents enquêteurs basés sur Codex avec accès au dépôt et à l’environnement d’exécution, leur permettant d’inspecter les fichiers, d’exécuter les tests et d’analyser les échecs des modèles. L’autre était une campagne d’annotation humaine menée par des ingénieurs logiciels expérimentés. OpenAI a indiqué que chaque tâche signalée dans ce processus de revue avait été examinée par cinq ingénieurs, les désaccords étant remontés.

OpenAI rapporte que les relecteurs humains étaient en général plus susceptibles que la chaîne d’agents de qualifier les tâches de cassées. L’entreprise ajoute également que le chevauchement des catégories entre les jugements des relecteurs et la chaîne d’agents était de 74 % pour les tâches signalées, et qu’aucune tâche signalée n’a eu « non cassée » comme étiquette humaine la plus fréquente.

Ces détails renforcent l’argument de l’entreprise selon lequel les problèmes ne se limitent pas à quelques cas isolés. Mais il y a aussi des limites à ce que l’on peut conclure à partir du matériel publié. Les éléments de preuve disponibles n’incluent pas de réponse externe des mainteneurs de SWE-Bench Pro, ni de réévaluation comparative des grands modèles sur une version corrigée du jeu de données. Ainsi, même si OpenAI apporte un argument substantiel montrant que le benchmark est bruité, l’impact exact sur le classement des modèles reste flou au vu des preuves fournies.

Pourquoi cela compte pour les créateurs de modèles et les acheteurs d’entreprise

Pour les laboratoires d’IA, l’implication immédiate est que les victoires sur les benchmarks de codage peuvent être moins durables qu’elles n’en ont l’air. Si près d’un tiers des tâches comportent des défauts, les écarts au classement peuvent refléter des décalages entre prompt et test, des hypothèses d’implémentation ou une couverture de tests faible plutôt que de réelles différences de compétence du modèle.

Cela est particulièrement important pour les équipes qui développent des agents IA pour le travail logiciel. SWE-Bench Pro a été présenté comme un test pertinent du comportement de codage à plus long terme, plus proche de ce que font les systèmes agentiques en production. Si ses tâches sont matériellement défectueuses, les développeurs ont alors besoin de suites d’évaluation plus larges, incluant des tests spécifiques au dépôt, des revues humaines, des analyses de régression et de vraies métriques de déploiement, plutôt qu’un simple score public.

Pour les acheteurs d’IA d’entreprise, l’avertissement d’OpenAI rappelle qu’il ne faut pas confondre taux de réussite sur benchmark et préparation à la production. Un modèle performant sur SWE-Bench Pro peut malgré tout peiner en matière de fiabilité, d’ambiguïté ou d’exhaustivité des tests dans une base de code réelle. À l’inverse, un modèle qui paraît plus faible sur le benchmark peut être pénalisé par les défauts des tâches elles-mêmes.

C’est aussi une question de gouvernance. OpenAI a explicitement lié la qualité des benchmarks aux décisions de sécurité et de déploiement dans le cadre de son Preparedness Framework. L’argument est simple : si les évaluations surestiment ou sous-estiment la capacité, elles peuvent fausser à la fois les choix de lancement de produits et les évaluations des risques. Ce point dépasse OpenAI et dépasse les benchmarks de codage. À mesure que les modèles sont davantage évalués sur leur comportement agentique, la mauvaise hygiène des benchmarks devient un problème stratégique, pas seulement académique.

L’accent mis par l’entreprise sur l’audit assisté par agents est également notable. OpenAI soutient en pratique que la même classe de systèmes testés peut aussi aider à déboguer les tests. La question de savoir si cette approche deviendra la norme dépendra de l’acceptation, par les chercheurs extérieurs, du fait qu’une revue basée sur des agents peut améliorer la qualité d’un jeu de données sans introduire une nouvelle couche de biais dépendant du modèle.

Preuves, affirmations et ce qui est rapporté par le fournisseur

L’affirmation centrale de cette histoire est rapportée par le fournisseur : OpenAI dit qu’environ 30 % des tâches de SWE-Bench Pro sont cassées, sur la base de son audit interne et d’une campagne de revue humaine qu’elle a organisée.

OpenAI rapporte également que les modèles de pointe sont passés de 23,3 % à 80,3 % sur la partition publique de 731 tâches du benchmark en huit mois. Dans cet article, ce chiffre doit être lu comme une tendance du benchmark citée par OpenAI, et non comme une mesure de marché vérifiée indépendamment.

Les détails méthodologiques sont plus concrets. OpenAI dit que son filtre automatisé a signalé 286 tâches, que sa chaîne d’analyse de points de données a jugé 200 tâches cassées, et que sa campagne d’annotation humaine en a jugé 249 cassées. Elle affirme aussi que cinq ingénieurs expérimentés ont examiné chaque tâche signalée et que les jugements des relecteurs ont recoupé la chaîne d’agents dans 74 % des cas signalés.

Ce qui reste non vérifié au vu des preuves disponibles, c’est la manière dont les mainteneurs du benchmark ou d’autres laboratoires classeraient les mêmes tâches, si des tâches réparées modifieraient sensiblement l’ordre des classements de modèles, et si des taux d’erreur similaires apparaissent dans des benchmarks de codage voisins, au-delà de SWE-bench Verified et SWE-Bench Pro.

Ce qu’il faut surveiller ensuite

Le premier signal à suivre est de savoir si les mainteneurs de SWE-Bench Pro publient une réponse, un jeu de données révisé ou une réfutation formelle. S’ils s’accordent sur une part importante des constats d’OpenAI, le benchmark pourrait être mis à jour rapidement. S’ils contestent les conclusions, le secteur pourrait avoir besoin d’un processus d’arbitrage indépendant.

Ensuite, il faut observer si les grands laboratoires changent la manière dont ils rapportent les performances en codage. Si les futurs lancements de modèles mettent moins l’accent sur SWE-Bench Pro et davantage sur des suites d’évaluation privées, des tests au niveau du dépôt ou des études de complétion de tâches, cela indiquerait une confiance affaiblie dans les classements publics de codage.

Troisièmement, surveillez si OpenAI publie davantage d’outils ou de méthodologies autour de l’audit de benchmark à l’aide de Codex ou d’agents enquêteurs similaires. Une chaîne d’audit reproductible pourrait influencer la manière dont l’industrie valide non seulement les jeux de données de codage, mais aussi les évaluations des agents IA plus largement.

Enfin, la grande question est de savoir si l’inflation des benchmarks est désormais un schéma récurrent dans les catégories de modèles qui évoluent rapidement. OpenAI a déjà critiqué SWE-bench Verified, et soulève maintenant des problèmes avec SWE-Bench Pro. Si la prochaine génération d’évaluations de codage rencontre des difficultés similaires, le marché pourrait se tourner vers des preuves mixtes : benchmarks publics, télémétrie client et tests contrôlés de flux de travail réels plutôt que des classements à chiffre unique.

Point de vue de Creati.ai

L’analyse d’OpenAI est importante moins parce qu’elle attaque un benchmark que parce qu’elle met au jour un problème structurel dans la mesure de l’IA. L’industrie veut des chiffres propres et comparables pour les modèles de codage, mais les tâches logicielles sont désordonnées. Lorsque les prompts, les tests cachés et les patchs de référence sont tirés de dépôts réels, de petites incohérences peuvent silencieusement transformer l’évaluation en bruit. C’est un problème pour les créateurs qui cherchent à optimiser les modèles et pour les entreprises qui veulent acheter en toute confiance.

L’enseignement pratique n’est pas d’arrêter d’utiliser SWE-Bench Pro, SWE-bench Verified ou d’autres benchmarks publics. Il s’agit plutôt de les faire passer de verdicts finaux à des signaux d’orientation. Pour les équipes qui déploient des agents IA, la maîtrise des benchmarks fait désormais partie du travail produit : comprendre ce qu’un score mesure réellement, ce qu’il manque et à quel point il peut être fragile. Les laboratoires qui gagneront la confiance dans le codage seront ceux qui associeront de bons résultats publics à une conception d’évaluation transparente, à des preuves de workflows réels et à la volonté d’auditer leurs propres instruments de mesure.