Que mesurent SWE-bench et les benchmarks de codage ?

Qu’est-ce que SWE-bench et comment est-il noté ?

Un benchmark de codage, c’est une liste fixe de tâches et une règle de notation. Le modèle ou l’agent de codage résout les tâches, la règle marque chaque solution comme réussie ou échouée, et le score est le pourcentage de réussites. Cet article commence par le benchmark dont on parle le plus, SWE-bench, puis lit les autres avec les mêmes quatre questions. Nous avons décrit la structure qui entoure le modèle (le harness) dans l’article sur le harness engineering, et les évaluations notées par un modèle juge dans l’article sur le LLM-as-a-judge.

SWE-bench est un benchmark construit à partir de vraies issues GitHub. D’après sa page, la première version est sortie en octobre 2023 et compte 2 294 tâches tirées des issues et des pull requests de 12 dépôts Python populaires. Chaque tâche vient d’une pull request qui a fermé une issue et a aussi modifié des fichiers de test.

La notation fonctionne ainsi : le modèle reçoit le texte de l’issue et le dépôt tel qu’il était avant la pull request, puis il modifie le code. Quand le modèle a terminé, deux groupes de tests s’exécutent :

• FAIL_TO_PASS : les tests qui échouaient avant la pull request et passent après. Ils montrent que l’issue est vraiment résolue.
• PASS_TO_PASS : les tests qui doivent passer avant comme après. Ils montrent que le changement n’a rien cassé de ce qui marchait déjà.

Si les deux groupes passent, la tâche compte comme résolue. Le score est le pourcentage de tâches résolues ; les classements l’écrivent « % Resolved ».

SWE-bench n’est plus aujourd’hui un seul jeu de tâches, mais une famille. Nous avons lu les chiffres du tableau le 20 octobre 2026, sur la page de chaque jeu :

Source : la page de SWE-bench, l’annonce de Multilingual et la page SWE-bench Pro de Scale AI, 20 octobre 2026. Les résultats du jeu privé de Pro sont publiés dans un classement séparé.

Un détail de plus compte quand on lit le classement. La page de Verified indique que le classement met tous les types de systèmes de codage dans la même liste, des simples boucles d’agent aux systèmes qui font plusieurs tentatives. Pour comparer les modèles entre eux, il existe une vue à part, « Bash Only » : chaque modèle y tourne avec le même petit agent (mini-SWE-agent) et rien d’autre qu’un shell bash.

Pourquoi SWE-bench Verified ne suffit-il plus ?

Verified est sorti avec OpenAI en août 2024. Selon Epoch AI, ses 500 tâches ont été choisies parmi les 2 294 du jeu d’origine par l’examen indépendant de trois experts, pour écarter les tâches qui posaient problème.

Le 3 septembre, Epoch a réexaminé Verified et l’a jugé « défectueux » (Flawed). Il avance trois raisons :

• Les tests rejettent des solutions correctes. Dans un audit publié le 23 février 2026, OpenAI a examiné les tâches que les modèles échouent souvent. Il en a revu 27,6 % et constaté que, dans 59,4 % de celles-ci, le test rejetait une solution qui fonctionnait correctement. Selon Epoch, cela veut dire qu’au moins 16,4 % de toutes les tâches sont cassées. La barre d’Epoch, c’est qu’un tel défaut touche moins de 20 % des questions.
• Les tâches ont fuité dans les données d’entraînement. Verified est un jeu fixe ; toutes ses tâches et toutes ses solutions sont publiques. D’après l’audit d’OpenAI, tous les modèles de pointe testés avaient vu au moins une partie de ces problèmes et de leurs solutions pendant l’entraînement. La conclusion d’OpenAI : les progrès sur Verified ne montrent plus une vraie compétence en développement logiciel, mais à quel point le modèle a vu ce benchmark pendant l’entraînement.
• On peut tromper le score. L’équipe RDI de Berkeley a trouvé un reward hack qui donne un score parfait.

Les fabricants de modèles en ont tiré les conséquences. D’après l’article de Cursor, OpenAI a complètement cessé de publier ses résultats sur Verified après avoir vu que les modèles de pointe pouvaient reproduire de mémoire les solutions de référence. La carte système d’Opus 5 d’Anthropic, datée du 24 juillet, rapportait encore Verified : 96,0 %, la moyenne de cinq essais. Dans la carte d’Opus 5.5, datée du 22 septembre, Verified n’apparaît plus ; il n’y a que Pro, Multilingual et Multimodal. Dans l’annonce du même modèle, Anthropic écrit aussi qu’à ce niveau de capacité, les écarts sur les benchmarks indiquent de façon moins fiable les différences en usage réel.

Un benchmark où tout le monde frôle le plafond ne peut plus départager les modèles. Ceux qui construisent les benchmarks le voient aussi. Aider a remplacé son ancien benchmark d’édition par un jeu plus difficile quand les scores ont dépassé 80 %. Terminal-Bench 4.0 a jugé « saturées » les tâches que tous les modèles les plus récents résolvaient 5 fois sur 5, et les a retirées du jeu. La page de DeepSWE écrit aussi que les modèles de tête se tassent dans une bande de scores étroite et que les intervalles de confiance de configurations voisines se chevauchent souvent.

La même semaine, Epoch a rendu le même verdict pour deux autres benchmarks de codage. Il juge un benchmark « défectueux » quand des défauts peuvent toucher 20 % du score ou plus :

Source : les examens d’Epoch AI. Pour Verified, Epoch s’appuie sur l’audit d’OpenAI. Les tâches de Terminal-Bench viennent de la communauté ; Epoch a compté les problèmes signalés publiquement dans son dépôt. Pour BFCL, il a tiré un échantillon au hasard parmi 5 088 éléments.

Voici à quoi ressemble un défaut, avec un exemple tiré de BFCL. Dans la tâche « What is the current time in Sydney, Australia? », le modèle reçoit une fonction nommée get_local_time(location). Le corrigé classe la tâche comme « non pertinente ». Seul un modèle qui n’appelle aucune fonction obtient la note maximale ; un modèle qui appelle correctement la fonction obtient zéro.

Que mesurent les autres benchmarks de codage ?

SWE-bench regarde un seul type de travail : un patch qui ferme une issue dans un dépôt. Ce qu’on attend d’un agent de codage est plus large ; chaque benchmark en mesure donc une autre partie. Nous avons lu les informations du tableau le 20 octobre 2026, sur la page de chaque benchmark :

Source : la page ou l’annonce de chaque benchmark, 20 octobre 2026. « Non précisé sur sa page » : sur la page que nous avons lue ce jour-là, nous n’avons trouvé aucune phrase qui le dise. Les avis de Cognition et de Cursor viennent des articles où ils présentent leurs propres benchmarks.

Les classements ne sont pas non plus aussi frais les uns que les autres. Le classement d’Aider a été mis à jour pour la dernière fois le 20 novembre 2025, celui de BFCL le 12 avril 2026. La version la plus récente dans le dépôt de LiveCodeBench (release_v6) couvre 1 055 problèmes publiés entre mai 2023 et avril 2025. Si un modèle manque dans un tel classement, cela peut vouloir dire que le classement est ancien, et non que le modèle est mauvais.

Le plus ancien nom absent de la liste est HumanEval : un jeu publié par OpenAI en 2021, qui fait écrire du code à partir d’une docstring. Son dépôt est aujourd’hui marqué « Deprecated and unmaintained ». L’équipe de LiveCodeBench a aussi constaté que certains modèles qui réussissent bien sur HumanEval pourraient être surajustés à ce jeu.

Les outils de revue de code ont eux aussi leurs benchmarks. GitHub a publié ReviewBench le 5 octobre ; un modèle juge y décide si un commentaire est un constat juste, et GitHub a aussi publié le prompt du juge. Nous avons expliqué comment lire un benchmark noté par un modèle juge dans l’article sur le LLM-as-a-judge.

Un code qui passe les tests est-il mergé ?

Le score de SWE-bench vient d’un correcteur automatique : si les tests passent, la tâche compte comme résolue. Dans une étude publiée le 10 mars 2026, METR a mesuré à quel point ce chiffre correspond à la revue d’un vrai mainteneur. 4 mainteneurs actifs de 3 dépôts de Verified (scikit-learn, Sphinx, pytest) ont lu au total 296 PR écrites par une IA comme lors d’une vraie revue, et ont décidé s’ils les mergeraient. Ils ne savaient pas qui avait écrit la PR.

Résultat : les mainteneurs n’auraient pas mergé environ la moitié des PR qui passaient les tests. Comme la décision d’un mainteneur peut varier d’une personne à l’autre, METR a aussi fait lire aux mêmes mainteneurs des PR humaines réellement mergées dans le dépôt ; ils en ont approuvé environ 68 %. Une fois les scores ramenés à cette base, le correcteur automatique se situe en moyenne 24,2 points au-dessus de la décision des mainteneurs. Sans cette mise à l’échelle, l’écart est de 34,9 points.

Les mainteneurs ont rejeté pour trois types de raisons : le changement ne résout pas vraiment le problème, il touche du code sans rapport et le casse, ou le code ne respecte pas les standards du dépôt. METR expose aussi clairement ses limites : les agents n’ont pas eu l’occasion de corriger leur travail après un retour, et l’étude n’a porté que sur une partie d’un seul benchmark et sur un seul agent. Le résultat ne dit donc pas que les modèles en sont incapables. Ce qu’il dit, c’est ceci : lu seul, un score fait paraître un agent plus utile qu’il ne l’est.

FrontierCode est un benchmark qui fait entrer ces questions dans le score. Cognition a préparé 150 tâches avec les mainteneurs de 36 dépôts open source ; dans chaque dépôt, ce sont les mainteneurs qui ont fixé les critères pour qu’un changement soit jugé mergeable. À côté des tests unitaires, il y a un contrôle du périmètre : le changement ne touche-t-il que les fichiers autorisés, et le diff dépasse-t-il une taille donnée ? Les tests écrits par l’agent sont aussi exécutés sur l’ancien code, celui qui est cassé ; un test qui n’y échoue pas ne vérifie rien.

Le propre rapport d’Anthropic montre l’effet de la pénalité de périmètre. D’après la carte système d’Opus 5, aux niveaux d’effort au-dessus de high, le modèle faisait plus de changements que la tâche n’en demandait, et son score FrontierCode baissait. Quand une courte consigne lui demandant de rester dans le périmètre de la tâche a été ajoutée au prompt, le score est revenu sur la plupart de ces tâches. C’est un résultat que le fournisseur rapporte pour Opus 5 ; la carte ne dit pas combien de points sont revenus.

C’est exactement dans cet écart que travaille la revue de code : le test montre que le changement produit le comportement voulu ; la revue demande si le changement a sa place là. Dans diffox, ce sont des agents spécialisés qui posent cette question. L’un compare les lignes modifiées, règle par règle, aux règles du fichier de règles du dépôt (AGENTS.md, CLAUDE.md) ; une règle qui n’est pas écrite dans le fichier ne compte pas. Un autre cherche un test qui ne vérifie pas ce que son nom annonce, ou une assertion qui ne peut jamais échouer ; un test manquant, en revanche, n’est pas un constat pour lui. Nous avons expliqué comment voir si un test vérifie vraiment quelque chose dans l’article sur la revue du code généré par l’IA.

Comment lire un score de benchmark ?

Quand vous tombez sur un score, posez ces six questions. Si deux scores diffèrent sur l’une d’elles, ils ne mesurent plus la même chose :

1. Quel jeu ou quel sous-ensemble ? « SWE-bench » tout court ne dit rien : Verified, le jeu public de Pro et un sous-ensemble choisi par une entreprise sont des chiffres distincts. La documentation d’Anthropic indique que les scores sur le sous-ensemble de 482 problèmes qu’Anthropic a choisi dans Pro ne sont pas comparables au classement public. Ils ne le sont pas non plus aux résultats Pro de la carte système de la même entreprise, car ceux-ci ont été mesurés sur un autre jeu de problèmes et en effort max.
2. Dans quel agent ? Un score n’appartient pas au modèle, mais au couple formé par le modèle et l’agent qui le fait tourner. Selon Epoch, les résultats sur Verified dépendent fortement de l’agent utilisé ; dans le classement de Terminal-Bench, chaque ligne est un modèle et un agent. Les réglages peuvent différer même sur un même benchmark : Epoch a noté que, sur Terminal-Bench, les entrées Codex relancent les refus de sécurité alors que le réglage par défaut ne le fait pas. Artificial Analysis écrit aussi que ses résultats appartiennent à des configurations précises et non à des noms de produits, et que le modèle, les réglages et la façon de l’exécuter peuvent changer sensiblement le résultat. Epoch compte aussi une mauvaise gestion du contexte par l’agent comme un problème de mise en place qui fait baisser le score ; nous avons expliqué ce que font les agents de codage quand le contexte est plein dans l’article sur l’auto-compact.
3. À quel niveau d’effort ? Les classements montrent souvent un modèle au niveau où il fait le mieux. Les résultats de l’annonce d’Opus 5.5 par Anthropic ont été mesurés en effort max, sauf mention contraire ; la ligne Terminal-Bench est au niveau qui a donné à chaque modèle son meilleur score. FrontierCode exécute lui aussi chaque modèle 5 fois à chaque niveau d’effort et rapporte le meilleur niveau. Si vous utilisez l’outil au niveau par défaut, vous ne verrez peut-être pas le résultat du tableau.
4. Combien d’exécutions, quelle incertitude ? La même configuration peut donner des scores différents d’une exécution à l’autre. Le classement de Terminal-Bench montre la moyenne de 5 exécutions avec un intervalle de confiance à 95 % ; Epoch recommande au moins 5 exécutions par modèle pour les barres d’erreur. Un écart qui ne dépasse pas le bruit n’est pas un écart ; nous avons décrit le bruit entre deux exécutions dans nos propres mesures dans l’article sur le LLM-as-a-judge.
5. Qui a mesuré ? Le tableau d’un fabricant de modèles est mesuré dans des conditions qu’il a choisies. Les mesures indépendantes essaient de faire tourner chaque modèle avec les mêmes règles : DeepSWE fait tourner tous les modèles avec le même petit agent. Dans les deux cas, regardez les détails : Artificial Analysis laisse un autre modèle finir quand un modèle refuse une tâche, et compte aussi cet essai ; Anthropic écrit de son côté que, quand ses garde-fous de sécurité sont intervenus, d’autres modèles ont accompli une partie des tâches d’Opus 5.5.
6. Le jeu est-il saturé, contaminé, à jour ? Un jeu où tout le monde frôle le plafond ne départage pas les modèles ; un jeu dont les tâches et les solutions sont publiques peut aussi mesurer la mémoire. Regardez la date de publication des tâches (LiveCodeBench la garde pour chaque problème), demandez si le jeu a une partie fermée et vérifiez quand le classement a été mis à jour pour la dernière fois.

Un exemple qui montre l’effet de l’effort sur le même modèle et les mêmes tâches se trouve dans le document d’Anthropic sur le coût et l’intelligence. Seul le niveau d’effort change :

Sur le même modèle, quand seul l’effort change, le score bouge de 9,3 points, et le coût par tâche passe de $0,11 à $0,74. Dans un tableau qui compare deux modèles, regardez d’abord à quel niveau chacun a été mesuré : si l’un l’a été en max et l’autre à son niveau par défaut, l’écart peut venir du réglage et non du modèle.

Quel benchmark regarder pour quel travail ?

Choisir un benchmark, c’est choisir ce que vous attendez de l’agent. Le tableau ci-dessous associe des travaux courants au benchmark qui en est le plus proche :

Source : les tableaux de cet article et la page de chaque benchmark, 20 octobre 2026.

Aucun ne remplace le travail dans votre propre dépôt. La documentation d’Anthropic recommande elle aussi d’essayer le réglage d’effort sur votre propre charge de travail. La mesure la plus fiable consiste à exécuter plusieurs fois quelques vraies tâches de votre dépôt, avec le même agent et au même niveau d’effort.

Aucun ne mesure non plus si un changement devrait être mergé. FrontierCode s’en approche le plus, mais là aussi, la décision revient à des critères que les mainteneurs ont écrits à l’avance. Dans votre dépôt, c’est la revue qui prend cette décision.

Questions fréquentes

Qu’est-ce que SWE-bench ?

SWE-bench est un benchmark qui mesure si les modèles d’IA et les agents de codage savent résoudre de vraies issues GitHub. Le modèle reçoit le texte de l’issue et le dépôt dans l’état où il était à ce moment-là, puis il modifie le code. Si le changement passe les tests FAIL_TO_PASS, qui montrent que l’issue est résolue, et les tests PASS_TO_PASS, qui montrent que rien n’a été cassé, la tâche compte comme résolue. La première version contient 2 294 tâches issues de 12 dépôts Python ; il existe des sous-ensembles et des jeux voisins comme Verified, Pro et Multilingual.

Quelle différence entre SWE-bench Verified et SWE-bench Pro ?

Verified est un sous-ensemble de 500 tâches du jeu d’origine, revu par des humains ; ses tâches et ses solutions sont publiques. Pro est le jeu plus difficile de Scale AI, avec 1 865 tâches tirées de 41 dépôts : les solutions font en moyenne 107,4 lignes et 4,1 fichiers. Les tâches de Pro viennent de dépôts sous licence copyleft et du code fermé d’entreprises, et les résultats d’une partie d’entre elles ne sont jamais publiés. Epoch AI a jugé Verified défectueux en septembre 2026 ; la dernière carte de modèle d’Anthropic rapporte d’ailleurs Pro plutôt que Verified.

À partir de quel pourcentage un score SWE-bench est-il bon ?

Il n’y a pas de seuil unique. Un score dépend du jeu, de l’agent et du niveau d’effort auxquels il appartient : sur le propre sous-ensemble d’Anthropic, le même modèle bouge de 9,3 points rien qu’avec le niveau d’effort, et Anthropic écrit que ces scores ne sont pas comparables au classement public. Ne comparez deux scores que s’ils ont été mesurés sur le même jeu, avec le même agent et des réglages proches ; ne regardez pas un chiffre isolé, mais son écart avec d’autres modèles mesurés dans les mêmes conditions.

Que mesure Terminal-Bench ?

Terminal-Bench mesure si un agent sait mener à bien des tâches de bout en bout dans le terminal : logiciel, science, ML, exploitation, sécurité, matériel et médias. Chaque tâche a son propre vérificateur. Avec la version 4.0, il est devenu un benchmark mis à jour en continu ; il retire du jeu les tâches saturées, les tâches refusées et celles dont la solution est devenue publique. Le classement montre, pour chaque couple modèle et agent, la moyenne de 5 exécutions avec un intervalle de confiance à 95 %. Le 4 septembre, Epoch AI a relevé un défaut de notation signalé publiquement dans 30 des 66 tâches.

Quelle différence entre LiveCodeBench et SWE-bench ?

LiveCodeBench s’appuie sur des problèmes tirés des concours LeetCode, AtCoder et Codeforces pour évaluer la capacité d’un modèle à écrire du code, corriger son propre code, exécuter du code et prédire la sortie d’un test ; une tâche est un seul problème. SWE-bench, lui, demande un changement qui ferme une vraie issue dans un dépôt. Comme LiveCodeBench date chaque problème, vous pouvez mesurer un modèle sur des problèmes parus après sa date de coupure d’entraînement ; le modèle ne peut alors pas avoir vu la solution pendant l’entraînement.

Jusqu’où peut-on se fier à un score de benchmark ?

Un score répond à la question étroite que pose le benchmark. Avant de vous y fier, vérifiez six choses : quel jeu, quel agent, quel niveau d’effort, combien d’exécutions et quel intervalle de confiance, qui a mesuré, et si le jeu est saturé ou contaminé. C’est pourquoi les audits indépendants comptent : en septembre 2026, Epoch AI a jugé SWE-bench Verified, Terminal-Bench 4.0 et BFCL v4 défectueux ; METR a mesuré qu’environ la moitié des PR de SWE-bench qui passent les tests ne passeraient pas la revue des mainteneurs.

Sur quel benchmark diffox est-il mesuré ?

diffox est un outil de revue de code par IA ; il se mesure donc sur des benchmarks de revue de code, pas sur des benchmarks de codage. Nous avons exécuté nous-mêmes le benchmark open source de revue de code de Martian et publié le résultat avec ses preuves : chaque review est une pull request publique, la notation a été faite par le code du benchmark lui-même, et vous pouvez reconstruire le tableau sur votre propre machine avec les commandes du dépôt de preuves. Cet article indique aussi de combien d’exécutions vient chaque ligne : nous avons réalisé l’exécution publique avec le réglage de sensibilité Élevée de l’époque, et les lignes Moyenne et Faible sont la moyenne de plusieurs exécutions internes.