SWE-bench Verified : pourquoi il ne mesure plus le codage aux frontières

SWE-bench Verified a été, pendant environ un an et demi, la référence la plus citée pour estimer dans quelle mesure un modèle était capable de résoudre des problèmes réels sur les référentiels Python : il part du texte d'un problème et de l'état du dépôt avant le correctif, le modèle produit un patch et « réussit » seulement si toute la suite de tests passe au vert. OpenAI l'avait publié en août 2024 en tant que sous-ensemble organisé du banc SWE, dans le but de supprimer les cas intrinsèquement ambigus ou techniquement impossibles à clôturer avec uniquement les indices présents dans la description du problème.

Cependant, en février 2026, OpenAI a déclaré qu'aux niveaux de performances actuels, SWE-bench Verified avait perdu la capacité de discriminer les améliorations réelles. Les scores évoluent encore (de 74,9% à 80,9% en six mois), mais la corrélation avec la qualité réelle du travail de « l'ingénieur » dans des scénarios non gâtés s'affaiblit. Le benchmark devient de plus en plus sensible à des facteurs externes : qualité des tests et mémoire d’entraînement.

Le premier problème : les tests qui rejettent les correctifs corrects

OpenAI a audité 138 tâches que le modèle o3 n'a pas résolues de manière cohérente sur 64 exécutions. Dans cette revue, chaque cas a été lu par plusieurs ingénieurs (au moins six) et revérifié lorsque des problèmes critiques sont apparus. Le résultat est clair : dans l'échantillon examiné, 59,4 % des tâches présentent des problèmes « matériels » de conception et/ou de description des tests, au point de les rendre extrêmement difficiles ou, en pratique, impossibles à résoudre de manière fiable, même pour un humain compétent.
Le problème n’est pas qu’il y ait un manque de tests, mais que les tests sont mal construits par rapport au contrat implicite du benchmark.

Tests trop étroits

Une part importante (35,5%) relève de tests trop « étroits » : ils contraignent les détails d'implémentation inutiles, rejetant les solutions qui respectent le comportement souhaité.

L'exemple cité par OpenAI (pylint-dev__pylint-4551) est typique : la suite importe une fonction avec un nom spécifique qui n'est pas demandé dans la description, donc un correctif fonctionnellement correct peut échouer à cause d'une simple ImportError.

Tests trop larges

Un autre bloc (18,8%) concerne les tests trop « larges » : ils vérifient également des fonctionnalités supplémentaires non présentes dans la description du problème. Ici, le modèle peut implémenter correctement ce qui est requis, mais échoue parce que le demandes de tirage L'original a résolu plusieurs problèmes ensemble et les tests couvrent l'intégralité du package, tandis que la tâche de référence n'en décrit qu'une partie (exemple : sympy__sympy-18199).
Ces deux modèles conduisent à une conséquence pratique : lorsque la marge d’erreur résiduelle est faible, le score commence à mesurer la fréquence à laquelle un système devine des détails non déclarés, au lieu de mesurer sa capacité à diagnostiquer, modifier le code et respecter les contraintes de régression.

Le deuxième problème : contamination et formation sur le « patch d’or »

Le deuxième sujet est plus délicat, car il concerne la fiabilité comparée entre laboratoires. SWE-bench (et donc Verified) est né de référentiels open source ; Ces mêmes bases de code, problèmes et souvent correctifs sont présents dans le matériel que de nombreux fournisseurs utilisent pour former des modèles et des outils de complétion de code. OpenAI rapporte des preuves dans lesquelles des modèles de différents fournisseurs reproduisent des parties du « patch d'or » (le patch de référence humaine) ou des détails de tâches de manière presque textuelle.
Autrement dit : une partie du jeu de données est entrée, directement ou indirectement, dans le « corps » des modèles. À ce stade, l’évaluation perd la propriété la plus importante d’un benchmark : mesurer la généralisation sur des instances invisibles.
OpenAI prétend avoir trouvé des signes indiquant que l'exposition à la formation augmente la probabilité de réussite, également parce que de nombreuses tâches comportent des tests sous-spécifiés : si vous savez déjà quel détail d'implémentation les tests « aiment », vous avez un avantage. D'où la décision de cesser de publier publiquement les résultats sur SWE-bench Verified et d'inviter d'autres à faire de même.

Ce qui change pour ceux qui utilisent des benchmarks pour de vraies décisions

La réaction la plus courante, dans ces cas, est de considérer l’affaire comme un différend académique sur des ensembles de données. En réalité, l'impact est opérationnel : de nombreuses entreprises et équipes produits utilisent SWE-bench Verified pour choisir des modèles, définir des KPI internes ou justifier des investissements dans des agents de codage. Si le nombre commence à être corrélé avec la « familiarité » du modèle avec ce type de matériau, le risque est de prendre des décisions sur un signal déformé.
Du côté des éditeurs, le problème est de réputation : lorsqu’un indicateur devient un objectif public, l’écosystème a tendance à l’optimiser. Le résultat est une course qui produit des progrès mesurables sur le benchmark et beaucoup plus difficiles à trouver dans les vrais retards, avec base de code contraintes privées, organisationnelles et tests non écrits « pour le benchmark ».

Pourquoi OpenAI pousse SWE-bench Pro

En l'absence d'alternatives immédiatement « privées » et vierges, OpenAI recommande d'utiliser SWE-bench Pro (en particulier la division publique) comme référence temporaire. Le fait n’est pas que Pro soit immunisé, mais que, comme l’observe OpenAI, la contamination serait moins fréquente et moins grave ; dans leur configuration, aucun modèle n'aurait complètement reconstruit une pièce d'or de cette manière textuellement comme cela arrive dans Vérifié.
Pour ceux qui lisent les rapports de référence, le conseil pratique est simple : considérez SWE-bench Pro comme mesure principale et traitez SWE-bench Verified comme des données historiques, utiles pour les rétrospectives mais moins adaptées pour mesurer les progrès marginaux en 2026.

Indications pratiques pour les évaluateurs d'agents de codage en entreprise

1) Séparez la « qualité du modèle » de la « qualité du système ». Les résultats des benchmarks publics tendent à récompenser l’échafaudage, la chaîne d’outils et la récupération. Si vous évaluez un agent, indiquez explicitement ce qu'il y a à l'intérieur de la pile (IDE, outils de recherche, accès à la documentation, journal, exécuteur de test, politique d'écriture).

2) Apporter l'évaluation aux artefacts propriétaires. Tout ce dont vous avez besoin, c'est de 20 à 50 problèmes réels issus de votre backlog, choisis selon des critères reproductibles (type, criticité, zone de code, couverture des tests). La valeur réside dans la stabilité de l'ensemble dans le temps et dans la traçabilité des erreurs, plutôt que dans le nombre absolu.

3) Audit des tests et des tâches. L'analyse d'OpenAI nous rappelle qu'un benchmark est un système socio-technique : si les tests et les descriptions sont incohérents, vous mesurez la mauvaise chose. Avant d'attribuer un « échec » au modèle, vérifiez si le contrat de tâche est clair et si la suite de tests n'impose pas de détails arbitraires.

4) Mesurez également les coûts et les modes de défaillance. En plus du « pass/fail », suivez le temps, le nombre d'itérations, la taille du patch, les régressions introduites, et surtout le type d'erreur (API hallucinée, incompréhension des exigences, rétrocompatibilité rompue). Ce sont des mesures plus proches de la réalité de l’ingénierie.

5) Établir un protocole anti-contamination. Si vous utilisez des exemples publics à des fins de formation interne ou de réglage fin, gardez les ensembles d'évaluation strictement séparés. Au niveau organisationnel, la même règle s'applique que pour les tests scolaires : ce qui est inclus dans le matériel de préparation ne doit pas être réutilisé comme examen.

Un regard plus large : ce que nous apprend cette histoire

Le problème ne concerne pas uniquement le banc SWE. Toute référence basée sur du matériel public, surtout lorsqu'elle devient une « lingua franca » dans des versions connues, a tendance à entrer en collision avec la dynamique de formation et la pression de montrer des progrès. Cela n’invalide pas les critères ; Cependant, il pousse dans deux directions : plus de soin dans la conception des tests (ni trop étroits, ni trop larges) et davantage d'investissements dans des évaluations privées, créées ad hoc, coûteuses mais moins contournables.
OpenAI mentionne, parmi les approches futures, des tâches »auteur privé » et une notation plus globale par des évaluateurs qualifiés. C'est une voie coûteuse, mais cohérente avec le fait que, pour les modèles frontières, les 10 % restants de « taux de réussite» n’est souvent pas un problème de génération de code, mais d’alignement entre exigences, tests et contexte.