50 %. C’est la proportion de code généré par intelligence artificielle qui, bien qu’il passe les tests automatisés du benchmark le plus respecté de l’industrie, se ferait recaler par les développeurs qui maintiennent réellement les projets. Derrière ce chiffre, publié le 10 mars par l’organisation de recherche METR, se cache une question qui concerne tous ceux qui misent sur l’IA pour coder : les progrès spectaculaires affichés par les labos sont-ils aussi réels qu’ils le prétendent ?
Le benchmark star remis en question
SWE-bench Verified est devenu, ces deux dernières années, la référence incontournable pour évaluer les agents IA en programmation. Le principe est simple : on soumet à l’IA de vrais bugs issus de projets open source populaires (scikit-learn, pytest, Sphinx), puis un système automatisé vérifie si le correctif proposé passe les tests unitaires. Anthropic, OpenAI et leurs concurrents s’en servent régulièrement pour afficher les progrès de leurs modèles.
Le problème, selon l’équipe de METR composée de Parker Whitfill, Cheryl Wu, Joel Becker et Nate Rush : passer un test automatisé et produire du code que des humains accepteraient d’intégrer dans un vrai projet, ce sont deux choses très différentes.
Quatre mainteneurs, 296 correctifs, un verdict sans appel
Pour mesurer cet écart, les chercheurs ont recruté quatre développeurs actifs qui maintiennent au quotidien trois des projets utilisés dans SWE-bench. Ces mainteneurs ont passé en revue 296 correctifs générés par cinq modèles d’IA : quatre versions de Claude (3.5 Sonnet, 3.7 Sonnet, 4 Opus et 4.5 Sonnet) ainsi que GPT-5. Les réviseurs ne savaient pas si le code venait d’un humain ou d’une machine.
Résultat : en moyenne, le taux d’acceptation par les mainteneurs est inférieur de 24 points de pourcentage au score SWE-bench. Concrètement, un modèle affiché à 60 % sur le benchmark tourne en réalité autour de 36 % quand un vrai développeur regarde le code de près. METR précise que cette différence est statistiquement significative.
Le code passe les tests mais ne résout pas le problème
Les raisons du rejet se répartissent en trois catégories. La première, et la plus préoccupante : des erreurs fonctionnelles pures. L’IA produit un correctif qui fait passer les tests automatisés, mais ne corrige pas réellement le bug sous-jacent. C’est un peu comme répondre juste à un QCM sans comprendre la question.
Deuxième cause : le code modifie des parties du projet qui n’ont rien à voir avec le problème, provoquant des effets de bord. Troisième motif : une qualité de code insuffisante, du style au non-respect des conventions du projet.
Détail intéressant relevé par The Decoder : la progression entre Claude 3.5 Sonnet et Claude 3.7 Sonnet a fait grimper les scores sur le benchmark, mais elle a aussi augmenté le nombre de rejets pour erreurs fonctionnelles. En clair, le modèle plus récent était meilleur pour tromper les tests, pas nécessairement pour résoudre les vrais problèmes.
Un écart qui se creuse dans le temps
Les chercheurs ont aussi converti ces résultats en « horizon temporel », un indicateur qui mesure la complexité des tâches qu’un modèle peut accomplir avec 50 % de chances de succès. Selon le benchmark automatisé, Claude 4.5 Sonnet atteint un horizon d’environ 50 minutes. Mais selon les mainteneurs, cet horizon tombe à 8 minutes, soit un écart d’un facteur sept.
Le taux d’amélioration annuel chute aussi : les chercheurs estiment qu’il est inférieur de 9,6 points par an quand on mesure les progrès via le jugement humain plutôt que via les tests automatisés. METR reconnaît toutefois que cette estimation sur la tendance est moins robuste statistiquement.
Ce que ça change pour le « vibe coding »
Ces résultats tombent en pleine euphorie autour du « vibe coding », cette pratique qui consiste à laisser l’IA écrire le code pendant que le développeur se contente de valider. Des startups comme Lovable, qui a levé 100 millions en un mois selon Y Combinator, surfent sur la promesse que l’IA peut remplacer une grande partie du travail de programmation. Cursor, valorisé à plusieurs milliards, construit tout son modèle économique autour de cette idée.
L’étude METR ne dit pas que ces outils sont inutiles. Mais elle suggère que les métriques utilisées pour mesurer leur progression surestiment systématiquement leur utilité réelle. Un score de 60 % sur SWE-bench ne signifie pas que l’IA résout 60 % des vrais problèmes de développement. C’est plus proche de 35 % quand un humain vérifie sérieusement.
Les limites assumées de l’étude
Les chercheurs de METR sont transparents sur plusieurs biais. D’abord, les agents IA n’avaient droit qu’à une seule tentative, sans possibilité d’itérer après un retour. Un développeur humain, lui, peut corriger son code après une revue. Ensuite, les mainteneurs n’avaient pas accès aux outils d’intégration continue habituels, et les exigences de tests avaient été relâchées pour avantager les modèles IA.
Pour calibrer le bruit inhérent aux jugements humains, l’équipe a aussi soumis aux mainteneurs 47 correctifs écrits par des humains et déjà intégrés dans les projets. Seuls 68 % ont été ré-approuvés, ce qui montre que même entre humains, l’accord n’est pas parfait. Tous les résultats sont normalisés par rapport à cette « ligne de base dorée ».
Joel Becker, co-auteur de l’étude, nuance lui-même la portée de ses conclusions sur le réseau social X. Son argument : avec des capacités qui doublent tous les trois à six mois dans le domaine, même un écart d’un facteur sept peut se combler rapidement. L’étude ne pointe pas un plafond fondamental, mais un problème de mesure qui fausse notre perception des progrès réels.
Les modèles les plus récents n’ont pas été testés
Une nuance importante : l’étude a été réalisée avec des modèles datant de mi-2024 à fin 2025. Les modèles les plus récents et les plus performants en programmation, comme GPT-5.2-Thinking ou Claude Opus 4.5, n’ont pas été inclus. Epoch AI, qui a fourni les données de test via son Benchmarking Hub, pourrait combler cette lacune dans de futures évaluations.
En attendant, la leçon pour l’industrie est claire : les benchmarks restent un outil de comparaison utile entre modèles, mais les prendre au pied de la lettre pour estimer la capacité réelle de l’IA à remplacer des développeurs conduit à des conclusions trop optimistes. Anthropic et OpenAI, qui citent régulièrement SWE-bench dans leurs communiqués, devront composer avec cette réalité au moment où les entreprises commencent à mesurer le retour concret de leurs investissements dans le code assisté par IA.
