Un jour de 2023, une équipe de chercheurs de Princeton a posé une question qui allait secouer tout le petit monde de l’intelligence artificielle. Le titre de leur article, « Can Language Models Resolve Real-World GitHub Issues? », claque comme un défi. Traduction pour les non-initiés : une machine peut-elle vraiment réparer des bugs comme un développeur en chair et en os ? SWE-bench est la réponse, ou plutôt l’épreuve conçue pour trancher la question. Et depuis, ce benchmark est devenu le juge de paix de tous les modèles qui prétendent savoir coder.
D’où sort ce fameux benchmark
Carlos Jimenez, John Yang et leurs collègues signent en 2024 le papier fondateur (référencé arXiv:2310.06770 pour les curieux). Leur idée a arrêter de tester les IA sur des exercices de style artificiels et les confronter à la vraie vie du code. Pas des puzzles inventés en laboratoire. Des bugs authentiques, extraits de dépôts GitHub que des millions de développeurs utilisent tous les jours.
Le mot SWE-bench se décompose ainsi. « SWE » pour Software Engineering, l’ingénierie logicielle. « Bench » pour benchmark, ce banc d’essai standardisé qui permet de comparer les concurrents sur un pied d’égalité. Le principe s’inspire des courses automobiles où chaque bolide affronte le même circuit dans les mêmes conditions.
La matière première de ce test provient de 12 dépôts open-source écrits en Python. Des vraies bibliothèques, comme scikit-learn, utilisées par des chercheurs et des ingénieurs sur toute la planète. Au total, la version complète du benchmark aligne 2 294 instances, autant de problèmes réels qui ont un jour fait suer un humain.
Le fonctionnement, rouage par rouage
Chaque tâche démarre avec ce que les concepteurs appellent le « problem statement ». En clair, la description du bug telle qu’un utilisateur agacé l’a rédigée sur GitHub. L’agent IA reçoit ce texte, plus l’accès au codebase entier (des milliers de fichiers parfois), et doit produire un « patch », c’est-à-dire une modification du code censée régler le problème.
La vérification tient de l’implacable. Deux batteries de tests unitaires jugent le travail. Les tests FAIL_TO_PASS échouaient avant la correction et doivent réussir après. Les tests PASS_TO_PASS, eux, vérifient que la machine n’a rien cassé ailleurs dans le programme (un piège classique du codeur). Il faut valider les deux pour empocher le point.
Détail délicieusement sadique, l’agent ne voit jamais les tests qu’il devra passer. Il navigue à l’aveugle, exactement comme un développeur qui découvre un ticket sans savoir précisément ce qu’on attend de lui. Pour couronner le tout, chaque épreuve se déroule dans un conteneur Docker isolé, une bulle logicielle propre qui garantit que tout le monde joue dans le même bac à sable.
La note finale s’exprime par la métrique « % Resolved », le pourcentage d’issues effectivement résolues. Un chiffre brut, sans échappatoire. Vous avez réparé le bug ou vous ne l’avez pas réparé.
Pourquoi ce test a changé les règles du jeu
Avant SWE-bench, on mesurait les IA sur des tâches de coding avec des exercices de programmation compétitive ou des fonctions à compléter. Charmant, mais aussi éloigné du métier réel qu’un examen de code de la route l’est d’un rallye sous la pluie. Ce benchmark a fait basculer l’évaluation dans le concret du développement quotidien.
L’astuce réside dans le sourcing où chaque problème vient d’une pull request qui a réellement résolu l’issue à l’époque. Les chercheurs disposent donc d’une solution de référence validée par de vrais humains, ainsi que des tests qui l’accompagnaient. Impossible de tricher sur ce qu’est une « bonne » correction, la communauté GitHub l’avait déjà tranché.
SWE-bench évalue en réalité deux choses en même temps, à savoir le modèle de fondation lui-même et le « harness » agentique qui l’entoure, c’est-à-dire la tuyauterie qui permet à l’IA d’exécuter des commandes et de manipuler des fichiers. Pour comparer proprement les modèles, Vals.ai par exemple, leur donne un seul outil, bash, et les force à se débrouiller avec les commandes du terminal (grep, find, sed…). La performance dépend alors de la seule intelligence du modèle, pas d’un échafaudage sophistiqué.
Quand les IA butent contre le mur
Les chiffres des débuts avaient de quoi calmer les enthousiastes. En août 2024, les meilleurs agents plafonnaient à 20% sur la version complète de SWE-bench et 43% sur la variante Lite. Ce qui veut dire que quatre bugs sur cinq résistaient encore aux machines dans la version intégrale.
Mais OpenAI a découvert que le benchmark était parfois injuste, sous-estimant les capacités réelles des modèles. Trois défauts revenaient. Des tests unitaires trop pointilleux qui rejetaient des solutions pourtant valables. Des descriptions de bugs mal spécifiées, laissant l’agent deviner l’attendu. Des environnements de développement capricieux qui faisaient échouer les tests indépendamment de la qualité du travail.
L’exemple du dépôt scikit-learn reste édifiant. Un test exigeait que la solution déclenche un avertissement précis (DeprecationWarning) avec un message exact, forgé lors d’une discussion à laquelle l’agent n’avait aucun accès. Résoudre correctement ce cas relevait presque de la voyance. Une IA irréprochable était condamnée à échouer pour une raison qui n’avait rien à voir avec sa compétence.
Reste une ombre au tableau que les concepteurs reconnaissent eux-mêmes. Les grands modèles pré-entraînés sur des téraoctets de données internet ont probablement déjà croisé ces dépôts GitHub publics. Personne ne peut être sûr à 100% qu’un modèle n’a pas déjà mémorisé une partie des réponses, ce qui peut forcément biaiser le résultat et l’aspect inédit des tests « aux yeux » des modèles.
La grande famille des variantes
Pour purger ces injustices, OpenAI a lancé en août 2024 une opération d’orfèvre. 93 développeurs expérimentés en Python ont passé au crible chaque échantillon, chacun relu 3 fois par des annotateurs différents. Le verdict fut sévère puisque 68,3% des échantillons ont été éliminés pour cause de spécification bancale ou de tests inéquitables. Il en est sorti SWE-bench Verified, 500 tâches nettoyées, validées, incontestables.
L’effet fut spectaculaire et GPT-4o, qui résolvait 16% des problèmes sur la version originale, a bondi à 33,2% sur Verified. Le score avait doublé sans que le modèle change d’un iota. La preuve que l’ancien benchmark bridait injustement les performances.
Autour de ce noyau gravitent plusieurs déclinaisons taillées pour des usages précis.
Le corpus Verified propose même un tri par difficulté. Le lot « easy » rassemble 196 corrections de moins de 15 minutes pour un développeur chevronné. Le lot « hard », lui, aligne 45 tâches réclamant plus d’une heure de réflexion. De quoi mesurer où exactement les modèles décrochent.
Vers quoi tout cela se dirige
Le benchmark ne cesse de muter pour rester à la hauteur et tester les modèles de manière équitable et surtout les pousser dans leurs rentranchements. En mai 2025 sortait SWE-smith, un outil permettant d’entraîner ses propres modèles d’agents logiciels. La communauté ne se contente plus de mesurer mais fabrique les concurrents de demain.
Novembre 2025 a vu débarquer CodeClash, une nouvelle génération d’évaluation. Le glissement conceptuel fait qu’on passe d’agents « orientés tâche » (résous ce bug précis) à des agents « orientés objectif » (atteins ce but comme un développeur autonome le ferait). L’ambition grimpe donc d’un cran vers l’imitation du raisonnement humain.
Les concepteurs eux-mêmes prêchent tout de même l’humilité. Un benchmark bâti sur des données figées vieillit vite, se fait contaminer, et finit toujours par être saturé quand les modèles progressent. La course entre l’épreuve et les candidats ne s’arrête jamais, chaque génération de tests devant redoubler d’exigence pour rester pertinente.
La véritable question n’est plus de savoir si l’IA sait coder, nous savons qu’elle le fait, et les modèles les plus puissants rivalisent déjà avec la majeure partie des développeurs humains. L’enjeu s’est déplacé puisque les scores frôlent aujourd’hui la saturation du referentiel SWE-bench Verified, le véritale défi est donc d’anticiper la suite. Le jour où une IA y affichera un score parfait de 100 %, il nous faudra déjà avoir inventé le prochain test pour mesurer ses réelles capacités d’autonomie.
