Le benchmark Real-SWE révèle l’écart entre les scores de codage par IA et le travail en entreprise

Specific Labs a publié le benchmark Real-SWE avec 640 exécutions d’agents, et la configuration la mieux classée n’a résolu que 38,8 % du travail qui lui était attribué.

Ce résultat crée un contraste inconfortable avec les classements publics de codage. Les agents semblent de plus en plus capables de traiter des problèmes à l’échelle d’un dépôt, mais la plupart des tentatives dans Real-SWE ont échoué sur des systèmes de production privés.

La différence ne tient pas simplement au fait que Real-SWE contient des énigmes de programmation plus difficiles. Ses tâches obligent les agents à reconstituer les règles métier, à naviguer dans une architecture inconnue et à coordonner des modifications entre le code et les services connectés.

Cette distinction importe, car les entreprises n’embauchent pas des ingénieurs logiciels pour résoudre des exercices isolés et dépourvus de contexte. Elles ont besoin d’ingénieurs capables de préserver les comportements existants tout en modifiant des systèmes qui traitent déjà des données clients, des autorisations, la facturation et l’infrastructure.

Real-SWE remet donc en question la promesse suggérée par les scores élevés des benchmarks publics. Il demande si un agent peut entrer dans une base de code d’entreprise inconnue et accomplir un travail économiquement utile sans s’appuyer sur des artefacts publics familiers.

La réponse initiale est préoccupante. Le benchmark fournit des éléments montrant que les modèles de codage peuvent produire des correctifs crédibles, mais il ne justifie pas un déploiement sans supervision dans des flux de travail d’entreprise à fort enjeu.

Ce que le benchmark Real-SWE a réellement changé

Real-SWE déplace la cible de l’évaluation, des problèmes de dépôts publics vers des systèmes privés dotés de règles propres à chaque entreprise et de dépendances opérationnelles.

Specific Labs a annoncé le benchmark le 12 septembre 2026. L’entreprise le décrit comme une évaluation de modèles de pointe sur des bases de code de production privées, sous licence auprès d’entreprises en activité.

La version initiale couvre dix tâches et huit configurations associant modèle et environnement d’exécution. Chaque configuration reçoit huit tentatives indépendantes par tâche, soit 640 exécutions évaluées.

Cette conception à tentatives répétées est importante. Un seul correctif réussi peut masquer une forte incohérence, tandis que huit tentatives montrent si un agent résout de façon fiable une même catégorie de problème.

Le classement publié présente le pass@1, c’est-à-dire la probabilité qu’une tentative résolve la tâche. Specific Labs calcule la moyenne de ce résultat sur les huit exécutions attribuées à chaque tâche.

Fable 5.1 avec Claude Code a dominé le classement initial avec 38,8 %. GPT-6 Astra avec Codex CLI suivait avec 33,8 %, tandis que Gemini 3.8 Flash avec Gemini CLI atteignait 31,2 %.

GLM 5.3 avec Claude Code a enregistré 28,8 %. Grok 4.6 et Muse Spark 1.3 ont chacun atteint 23,8 % avec leurs systèmes d’agents respectifs.

Kimi K3 avec Kimi Code a atteint 18,8 %. GPT-5.6 Sol avec Codex CLI a terminé à 16,2 % dans cette évaluation particulière.

Ces résultats évaluent des combinaisons, et non des modèles de langage seuls. Un environnement fournit des outils, contrôle la boucle d’interaction et façonne la manière dont un modèle explore et modifie un dépôt.

Specific Labs indique explicitement avoir utilisé des environnements natifs destinés à refléter les flux de travail actuels de l’ingénierie logicielle. Ce choix améliore la pertinence pratique, mais complique les comparaisons entre modèles.

Un score supérieur peut refléter le raisonnement du modèle, le comportement de l’environnement, la fiabilité des outils ou l’interaction entre ces trois éléments. Le classement ne peut pas isoler clairement ces effets.

Le changement plus profond du benchmark concerne l’exposition des données. Les tests de codage publics utilisent généralement des dépôts open source, des problèmes publics et des historiques de solutions visibles.

Les dépôts privés réduisent la probabilité qu’un modèle ait rencontré le correctif pertinent durant son entraînement. Ils empêchent également un agent de trouver une réponse au moyen d’une recherche publique.

Selon les résultats Real-SWE publiés, chaque tâche provenait d’un travail associé à une véritable base de code privée. Certaines instructions auraient été directement reprises de travaux d’ingénierie réels.

Cette conception rapproche l’évaluation moins d’un examen conçu pour les modèles. Elle la rend davantage comparable à l’intégration d’un nouveau prestataire dans une organisation logicielle inconnue.

Cette distinction modifie aussi le sens de l’échec. Un correctif infructueux peut révéler de faibles capacités de codage, mais aussi une mauvaise découverte des exigences ou une compréhension incomplète du système.

C’est précisément le terrain sur lequel les déploiements en entreprise deviennent risqués. Un correctif peut compiler, réussir des tests évidents et pourtant enfreindre une règle intégrée ailleurs dans l’activité.

Pourquoi le code privé d’entreprise constitue un test différent

Le défi central n’est pas de générer davantage de code. Il consiste à découvrir les comportements dont l’entreprise dépend déjà et à les préserver à travers plusieurs systèmes.

Un exemple de Real-SWE demande à un agent de corriger la taxation des factures. La brève description masque plusieurs conditions relatives à la configuration de l’entreprise, aux exonérations client, aux règles géographiques et aux services fiscaux externes.

L’agent doit déterminer quand utiliser un taux enregistré et quand calculer la taxe selon la destination de l’acheteur. Il doit reconnaître les comptes qui ne perçoivent aucune taxe.

Il doit également préserver les exonérations, enregistrer correctement les totaux de facture et signaler les adresses rejetées sans bloquer la facture. Les transactions finalisées doivent être renvoyées à l’autorité fiscale.

Les transactions européennes ajoutent une autre exigence concernant les immatriculations à la TVA. L’exécution du travail peut impliquer un service TypeScript, des environnements TaxJar et un registre InfluxDB.

Aucune de ces opérations, prise individuellement, ne représente un algorithme exotique. La difficulté vient de leur coordination sans négliger une condition ni endommager le comportement existant.

Ce schéma se retrouve dans l’ensemble des logiciels d’entreprise. Une demande qui semble locale traverse souvent des API, des bases de données, des tâches en arrière-plan, de la configuration, des tests et des outils opérationnels.

Les environnements Real-SWE peuvent exposer des services et outils, notamment Docker, Kubernetes, GitHub, PostgreSQL, MySQL, Redis, Slack, l’e-mail et des systèmes de support client.

Chaque tâche ne reçoit que les services dont son flux de travail a besoin. Malgré cela, un agent doit décider quels systèmes contiennent des éléments pertinents et lesquels constituent des distractions.

Le benchmark fait état d’une longueur médiane d’instructions de 1 742 caractères. C’est plus court qu’une spécification détaillée d’implémentation, ce qui oblige les agents à déduire la structure à partir du code et du contexte disponibles.

Les solutions de référence ont modifié une médiane de 11 fichiers. Les données comparatives du benchmark placent ce chiffre au-dessus des médianes de six fichiers signalées pour FrontierCode et DeepSWE.

Cet écart aide à comprendre pourquoi la navigation dans le dépôt est importante. Un modèle qui trouve un point d’implémentation évident peut encore manquer la validation, la persistance, la configuration ou les consommateurs en aval.

Specific Labs indique que six des dix tâches avaient des taux de résolution inférieurs à 15 %. Aucune configuration testée n’a résolu toutes les tâches.

L’analyse des échecs identifie les exigences manquées comme la catégorie la plus fréquente. Parmi les autres échecs observés figuraient des hypothèses non vérifiées, des erreurs d’intégration, des régressions et des modifications apportées au mauvais fichier.

Ces catégories ressemblent davantage à des commentaires ordinaires de revue d’ingénierie qu’à des erreurs de syntaxe. Elles suggèrent que les agents produisent fréquemment des changements locaux plausibles sans construire un modèle complet du système.

Le temps seul ne séparait pas les réussites des échecs. Le benchmark indique que 70 des 98 exécutions de moins de dix minutes ont échoué, soit un taux d’échec de 71,4 %.

Parmi les exécutions plus longues, 398 sur 542 ont échoué, soit 73,4 %. Un temps d’exécution plus long n’a donc pas automatiquement corrigé une exploration insuffisante ou des hypothèses erronées.

La comparaison entre exécutions courtes et longues ne doit pas être considérée comme une preuve qu’un raisonnement supplémentaire n’aide jamais. Les tâches plus difficiles génèrent probablement des tentatives plus longues, ce qui crée un important facteur de confusion.

Le résultat affaiblit néanmoins une explication commode. Ces agents n’ont pas échoué simplement parce que chaque exécution se terminait avant que le modèle puisse achever la saisie d’une solution.

Le mécanisme le plus crédible est une formation incomplète du contexte. Un agent doit identifier les exigences, localiser leur implémentation, suivre les dépendances et vérifier l’ensemble de la modification.

Ce flux de travail bénéficie d’une connaissance durable du dépôt. Les équipes d’ingénierie conservent déjà des notes d’architecture, des historiques d’incidents, des décisions et des documents techniques pour la même raison.

Une base de connaissances d’ingénierie consultable peut réduire le travail de découverte répété pour les humains. Les systèmes d’agents ont de plus en plus besoin d’une couche de contexte équivalente.

Real-SWE n’établit pas qu’une mémoire persistante résoudrait ces tâches. Il montre pourquoi la génération de code sans état constitue un modèle incomplet pour l’ingénierie en entreprise.

Les scores publics de codage face à la réalité du code privé

L’enjeu principal oppose les capacités de codage visibles dans les benchmarks à des performances fiables au sein de systèmes que les modèles n’ont jamais rencontrés.

SWE-bench a transformé l’évaluation du codage en demandant aux modèles de résoudre de véritables problèmes GitHub à partir d’instantanés de dépôts. Il s’agissait d’une amélioration majeure par rapport aux tests isolés de génération de fonctions.

Le benchmark original reliait les descriptions de problèmes, l’état du dépôt et une évaluation fondée sur l’exécution. Il a contribué à orienter le domaine vers des agents capables d’explorer, de modifier et de tester des logiciels.

Cependant, ces dépôts et historiques de problèmes sont publics. À mesure que les modèles s’améliorent et que les données d’évaluation circulent, la contamination devient plus difficile à exclure.

La contamination se produit lorsque les données d’entraînement d’un modèle contiennent des tâches de benchmark, des correctifs pertinents ou des copies proches. Un score élevé peut alors mêler généralisation, reconnaissance et mémorisation.

SWE-bench Verified a tenté d’améliorer la qualité des tâches grâce à une revue humaine. Son jeu de données vérifié a conservé 500 échantillons après examen des descriptions de problèmes et des tests.

Cette revue a elle-même démontré à quel point les évaluations de codage sont difficiles à construire. OpenAI a indiqué que 68,3 % des échantillons examinés avaient été retirés en raison de problèmes de spécification, de test ou connexes.

Le benchmark filtré restait utile, mais il n’éliminait pas l’exposition publique. Les développeurs de modèles pouvaient toujours étudier les dépôts, les tâches, le comportement de notation et les schémas d’échec fréquents.

Des audits plus récents ont renforcé la pression en faveur de nouvelles conceptions d’évaluation. L’audit des benchmarks réalisé par OpenAI en 2026 a fait état de préoccupations liées à la conception et à la contamination dans des évaluations de codage largement utilisées.

L’audit a également estimé qu’environ 30 % des tâches SWE-Bench Pro étaient défectueuses. Les problèmes signalés comprenaient des tests trop stricts, des exigences manquantes, une couverture insuffisante et des consignes trompeuses.

Real-SWE traite une partie de ce problème en gardant privés les dépôts et les solutions sous-jacents. Les modèles ne peuvent pas récupérer un correctif public exact si ce correctif n’a jamais été publié.

Mais les données privées introduisent un compromis différent. Les chercheurs extérieurs ne peuvent pas inspecter librement chaque dépôt, reproduire chaque tâche ni auditer les tests cachés.

Cela réduit la transparence précisément lorsqu’un benchmark avance des affirmations commercialement significatives. Les lecteurs doivent faire confiance à l’opérateur du benchmark pour les licences, l’anonymisation, la construction des tâches et le processus de notation.

Real-SWE fournit des exemples de tâches, des résultats agrégés, des intervalles de confiance et une taxonomie des échecs. Ces informations aident, mais elles ne valent pas une évaluation ouvertement reproductible.

La taille de dix tâches constitue une autre limite. Les exécutions répétées mesurent la régularité entre les tentatives, mais la répétition ne crée pas une couverture plus large des tâches.

Un benchmark de dix tâches peut être sensible à la sélection des tâches. Une seule architecture, un seul mélange de langages ou un seul domaine métier peut influencer matériellement les classements.

L’association modèle-harnais ajoute une incertitude supplémentaire. Claude Code apparaît avec plus d’un modèle, tandis que Codex CLI apparaît lui aussi avec plusieurs modèles.

Cette variation fournit des informations utiles sur le déploiement. Elle ne produit pas une comparaison contrôlée dans laquelle chaque modèle reçoit une structure et une politique d’outils identiques.

L’interprétation correcte est donc plus limitée qu’un classement universel des modèles. Ces scores montrent comment des configurations nommées ont performé sur cette version de Real-SWE, dans le cadre de sa configuration documentée.

Ils ne prouvent pas que le meilleur modèle convient à toutes les entreprises. Ils n’établissent pas non plus que la configuration la moins bien classée ne dispose d’aucune capacité utile de programmation.

Le benchmark met plutôt en garde contre le transfert direct de scores publics vers des attentes de déploiement privées. Cet avertissement s’inscrit dans le réexamen plus large mené dans le domaine de l’évaluation.

METR établit une distinction connexe dans sa méthodologie des tâches. Ses tâches autonomes donnent intentionnellement aux modèles des critères de réussite clairs et une dépendance limitée à l’historique organisationnel.

METR observe que le travail réel dépend souvent de conversations antérieures, de connaissances tacites et d’une familiarité avec une base de code existante. Sa méthodologie compare davantage les agents à des prestataires disposant de peu de contexte.

Real-SWE va plus loin dans ce problème de faible contexte. Il conserve une évaluation exécutable tout en introduisant des conventions propres à l’entreprise et des relations opérationnelles.

C’est le renversement le plus important du benchmark. De bonnes performances sur des tickets publics ne constituent plus une preuve suffisante d’une autonomie fiable en entreprise.

Le classement met autant de pression sur les acheteurs que sur les fournisseurs de modèles

Real-SWE met les équipes d’évaluation en entreprise sous pression, car les scores des fournisseurs ne peuvent pas remplacer des tests menés dans l’environnement propre de l’acheteur.

Une entreprise qui évalue des agents de programmation fait généralement face à une asymétrie d’information. Les fournisseurs connaissent leurs modèles, tandis que les acheteurs connaissent leurs dépôts, leurs workflows et leur tolérance au risque.

Les classements publics donnent aux deux parties une référence commune. Ils simplifient la comparaison, mais cette simplicité devient dangereuse lorsque l’environnement de déploiement diffère de celui du benchmark.

Real-SWE rend ce décalage visible. Même sa configuration la plus performante a échoué dans plus de six tentatives sur dix sur l’ensemble de tâches évalué.

Un acheteur ne devrait pas convertir directement ce chiffre en taux de défaillance attendu en production. Dix tâches de benchmark ne peuvent pas représenter tous les dépôts ni toutes les organisations d’ingénierie.

Ce chiffre modifie néanmoins la discussion autour des achats. Les équipes ont besoin de preuves de fiabilité sur leur propre code, et pas seulement de performances sur des historiques de tickets publics.

Cela implique de construire des évaluations internes à partir de travaux représentatifs déjà terminés. Les tâches pertinentes peuvent inclure des corrections de bugs, des migrations, des modifications de permissions et des travaux d’intégration dont les résultats sont connus.

La solution de référence ne doit pas devenir la seule implémentation acceptable. Les relecteurs doivent distinguer la correction fonctionnelle de la simple ressemblance avec le patch original d’un ingénieur.

Les tests cachés doivent également être examinés avec attention. Un benchmark peut pénaliser une alternative valide si son vérificateur encode des détails d’implémentation non énoncés.

Les audits de benchmarks d’OpenAI montrent à quel point cela arrive fréquemment. La qualité de l’évaluation exige que des ingénieurs expérimentés comparent les instructions, les tests, les modifications de référence et les traces des agents.

Les organisations doivent aussi tester les configurations complètes. La décision de Real-SWE d’évaluer des paires modèle-harnais reflète la manière dont les agents de programmation fonctionnent en pratique.

La recherche dans les dépôts, l’accès au shell, l’exécution des tests, la gestion du contexte et les politiques de reprise peuvent modifier matériellement les performances. Mesurer uniquement le modèle sous-jacent ignore ces dépendances.

La sécurité doit faire partie de la même évaluation. L’accès à du code source privé soulève des questions de conservation des données, de contrôles du fournisseur, d’exposition de secrets, de journalisation et de permissions.

Un agent qui résout davantage de tâches peut tout de même être inadapté s’il reçoit un accès plus étendu que celui que l’organisation peut accorder en toute sécurité. Les capacités et le risque de déploiement doivent être évalués ensemble.

La charge de relecture fournit une autre mesure essentielle. Un patch qui finit par fonctionner peut exiger tellement d’investigation humaine qu’il procure peu de bénéfice en productivité.

Les équipes devraient noter la fréquence à laquelle un agent manque des exigences, crée des régressions ou nécessite des consignes correctives. Ces mesures correspondent étroitement aux catégories d’échec de Real-SWE.

Elles devraient aussi suivre la variance. Une démonstration réussie dit peu de chose sur la capacité de l’agent à reproduire le résultat lors de la tentative suivante.

La discussion sur le benchmark sur Hacker News a illustré les deux aspects de cette question. Certains participants ont salué les essais répétés en pass@1 parce qu’ils révèlent la cohérence.

D’autres ont soutenu que les outils actuels fonctionnent toujours mieux dans le cadre d’une collaboration étroite avec un humain. Selon cette approche, l’opérateur qualifié reste une partie du système évalué.

Ce modèle de « centaure » associe un humain à un agent IA. L’humain apporte jugement, contexte et relecture, tandis que l’agent s’occupe de l’exploration, de la rédaction et des changements mécaniques.

Real-SWE ne compare pas les agents autonomes aux équipes expert-agent. Ses résultats ne doivent donc pas être interprétés comme une preuve que les assistants de programmation n’ont aucune valeur pratique.

Ils indiquent quelque chose de plus précis. Les configurations testées ne remplacent pas de manière fiable le travail de contextualisation et de vérification effectué par des ingénieurs expérimentés.

Cette différence compte pour les affirmations de déploiement. Assister un ingénieur et prendre de manière autonome en charge une modification en entreprise correspondent à des seuils de capacité distincts.

Les acheteurs devraient exiger que les fournisseurs précisent quel seuil est étayé par leurs preuves. Un score public ne peut pas répondre à lui seul à cette question.

Ce que les chiffres de Real-SWE ne prouvent pas

Le benchmark fournit un avertissement significatif, mais son petit échantillon privé ne peut pas étayer des conclusions générales sur tous les modèles ou toutes les bases de code d’entreprise.

Premièrement, les tâches de Real-SWE proviennent d’entreprises sélectionnées par Specific Labs. Les exemples publiés comprennent une application grand public, une plateforme fintech et un logiciel de vente destiné aux entreprises.

Specific Labs affirme que l’une des applications représentées sert plus de 200 000 utilisateurs. Une autre plateforme traiterait plus de 100 000 relevés bancaires.

Ces détails établissent une pertinence commerciale, mais les entreprises restent anonymes. Les lecteurs ne peuvent pas évaluer indépendamment leur qualité d’ingénierie, leur architecture ou la complexité de leur domaine.

Deuxièmement, la confidentialité du benchmark empêche une réplication publique complète. Cette confidentialité protège le code sous licence et réduit la contamination directe, mais elle concentre l’autorité de validation.

Les évaluateurs indépendants ont besoin d’un accès contrôlé pour confirmer la provenance des tâches, la qualité des vérificateurs, la parité des environnements et la notation. Sans cet examen, une certaine incertitude demeure inévitable.

Troisièmement, le classement combine différents modèles avec différents harnais natifs. Cela ressemble à l’utilisation réelle des produits, mais affaiblit les conclusions sur l’intelligence des modèles sous-jacents.

Une configuration peut échouer parce que sa stratégie de recherche ne fonctionne pas, que ses appels d’outils échouent ou que sa gestion du contexte écarte des éléments pertinents. Ce sont des échecs de produit, mais ils ne sont pas identiques.

Quatrièmement, le benchmark utilise la résolution automatisée comme résultat principal. Réussir un vérificateur est nécessaire, bien que l’acceptabilité en entreprise puisse exiger davantage.

La revue en production peut prendre en compte la maintenabilité, l’observabilité, la sécurité, la sûreté des migrations, le style et la charge opérationnelle future. Un succès binaire ne peut pas entièrement saisir ces dimensions.

Inversement, un patch valide peut échouer face à un vérificateur imparfait. L’historique des audits de SWE-bench montre que les tests cachés peuvent rejeter des solutions raisonnables ou ne pas détecter des solutions incomplètes.

Real-SWE indique que le comportement requis doit être explicitement énoncé ou raisonnablement découvrable. Cette norme est pertinente, mais le caractère « raisonnablement découvrable » requiert toujours un jugement.

Cinquièmement, des tâches commerciales anonymes peuvent favoriser les modèles ou harnais dont les schémas d’exploration correspondent au benchmark. Une structure de dépôt différente pourrait inverser certains classements.

Les intervalles de confiance à 95 % affichés sur le classement reconnaissent la variation d’échantillonnage entre les exécutions. Ils n’éliminent pas l’incertitude liée à la sélection de seulement dix tâches.

Sixièmement, la page de lancement affirme largement que la plupart des tokens d’entreprise restent cachés aux modèles de pointe. Cette affirmation soutient la motivation du benchmark, mais manque de détails de mesure publics.

Elle doit être considérée comme le cadrage de l’entreprise, et non comme une statistique établie indépendamment. La conclusion la plus prudente est qu’une part importante du contexte d’entreprise reste privée.

Enfin, un faible taux de résolution autonome n’équivaut pas à un faible impact sur la productivité. Un agent peut faire gagner du temps grâce à l’investigation, à la génération de tests, à la documentation ou à des brouillons de patchs, sans finaliser le travail indépendamment.

L’inverse est également vrai. Un patch achevé peut engendrer des coûts de relecture ou des risques subtils qui compensent sa rapidité apparente.

Ces limites ne rendent pas Real-SWE non pertinent. Elles définissent les conditions dans lesquelles ses résultats sont utiles.

Le benchmark est plus solide comme preuve d’un écart de déploiement. Il est moins solide comme classement définitif des modèles ou comme prévision de l’emploi en ingénierie.

Specific Labs est aussi un acteur commercial des données et de l’évaluation en entreprise. Son profil d’entreprise décrit une activité fondée sur des environnements et des jeux de données d’entreprise réalistes.

Cela n’invalide pas le travail. Cela rend plus importantes la réplication indépendante et une méthodologie transparente.

Un écosystème de benchmarks crédible a besoin de plusieurs opérateurs, de tâches privées renouvelées et d’audits menés par des tiers. Aucun classement unique ne devrait devenir l’autorité finale.

Trois signaux qui détermineront l’importance de Real-SWE

Real-SWE ne deviendra conséquent que si son signal de code privé résiste à l’élargissement, à un examen indépendant et à des sorties répétées de modèles.

Le premier signal est l’augmentation de l’ensemble de tâches. Dix tâches peuvent révéler des modes d’échec, mais une collection plus vaste doit couvrir davantage de langages, d’architectures et de domaines métiers.

Cette expansion devrait préserver la provenance privée tout en publiant suffisamment de métadonnées pour que les lecteurs comprennent la diversité des tâches. Elle devrait également distinguer les échantillons adossés à des dépôts des autres formats de tâches.

Si les classements restent similaires sur un ensemble de tests plus large, l’affirmation d’un écart persistant en entreprise gagnera en force. D’importants changements de rang montreraient que la sélection a façonné les résultats du lancement.

Le deuxième signal est l’évaluation indépendante. Des chercheurs externes ou des fournisseurs de modèles doivent disposer d’un accès contrôlé pour auditer les tâches, les vérificateurs et les environnements d’exécution.

Un audit utile examinerait si les prompts contiennent suffisamment d’informations, si les tests cachés acceptent des implémentations alternatives et si les solutions de référence représentent un véritable travail de production.

L’accord d’évaluateurs indépendants renforcerait la confiance dans les taux de résolution rapportés. Des défauts de test découverts restreindraient ou réviseraient les conclusions du benchmark.

Le troisième signal est le progrès au fil de versions répétées. Les benchmarks privés perdent de leur valeur si les tâches fuient, deviennent des cibles d’entraînement ou restent statiques tandis que les systèmes d’agents s’adaptent.

Specific Labs devra disposer de nouvelles tâches tenues à l’écart et d’un versionnage clair. Les résultats devraient distinguer les améliorations provenant des modèles, des harnais, des reprises et de l’exposition aux tâches.

Une hausse rapide des scores sur de nouvelles tâches privées indiquerait une meilleure généralisation. Des gains limités aux anciennes tâches suggéreraient une optimisation autour du benchmark lui-même.

Les entreprises devraient surveiller la composition des échecs en parallèle du taux de réussite global. Moins d’exigences manquées et d’hypothèses non vérifiées compteraient davantage que des patchs générés plus esthétiques.

La cohérence devrait également s’améliorer. Un modèle qui résout occasionnellement une tâche reste difficile à croire lorsque le même prompt produit souvent une régression.

Les comparaisons humain-agent ajouteraient une autre couche utile. Mesurer le temps de relecture et le temps total de réalisation pourrait montrer où les agents créent déjà de la valeur sans autonomie complète.

Real-SWE a placé la bonne question devant les développeurs et acheteurs de modèles. Un agent peut-il modifier en toute sécurité un logiciel dont l’historique, les conventions et la logique métier n’ont jamais été publics ?

Ses premiers résultats indiquent que les systèmes actuels n’y parviennent souvent pas. La meilleure configuration a résolu moins de quatre tentatives sur dix, tandis que les exigences non respectées dominaient les échecs observés.

Cette conclusion devrait encourager de meilleures évaluations, et non un rejet général. Les agents de programmation peuvent rester utiles lorsque les ingénieurs contrôlent le périmètre, fournissent le contexte et vérifient les conséquences.

L’étape pratique suivante consiste à tester un travail interne représentatif avant d’élargir les autorisations. Les équipes devraient comparer les configurations, répéter chaque tâche et étudier pourquoi des correctifs apparemment raisonnables échouent.

Le benchmark Real-SWE importe s’il fait évoluer les comportements d’achat : ne plus faire confiance aux scores publics, mais exiger des preuves privées. Votre prochain essai d’agent de programmation mesurera-t-il le code généré, ou le travail achevé que votre entreprise peut accepter en toute sécurité ?