Pourquoi les agents de codage ont encore du mal avec le code des entreprises privées

Les benchmarks de codage publics évaluent des compétences utiles, mais ils en disent peu sur ce qui se passe dans le code de production privé d’une entreprise. Un benchmark appelé Real-SWE teste ce second type d’évaluation. Ses créateurs, une petite startup soutenue par Y Combinator nommée Specific Labs, ont obtenu sous licence du code privé de vraies entreprises, extrait dix tâches déjà terminées par leurs ingénieurs, et les ont confiées à huit assistants en codage. Le meilleur d’entre eux a réussi 38,8 % des tâches.

L’une des tâches commence par une urgence de facturation : les factures émises par le service sont envoyées sans aucun impôt, et la facturation reprendra lundi. Au total, les assistants ont tenté soixante-quatre fois de résoudre ce problème, et deux tentatives ont fonctionné. Cette tâche s’appelle « Tax jurisdiction » et fait partie des dix évaluées.

Pourquoi ce code reste caché

Les fondateurs ont publié ce benchmark récemment, et il a fait son apparition sur la page d’accueil de Hacker News avec quelques centaines de points et plus d’une centaine de commentaires. Real-SWE évalue huit combinaisons de modèles et d’agents sur dix tâches, avec huit tentatives par tâche. Cela donne 640 essais notés, et le score principal correspond à la proportion d’essais qui ont réussi.

Les projets sous-jacents ressemblent à des logiciels commerciaux ordinaires : une application de gestion d’événements utilisée par plus de 200 000 personnes et figurant parmi les 100 meilleures applications d’App Store, un produit fintech ayant traité plus de 100 000 relevés bancaires, ainsi qu’une plateforme de vente destinée aux entreprises. Les agents disposent de Docker et Kubernetes, de trois bases de données (Postgres, MySQL, MongoDB), de Redis, de GitHub et d’un cloud Amazon simulé, bien que chaque tâche ne mette en œuvre que les services nécessaires à son propre flux de travail.

Certains environnements intègrent Slack, Intercom, Google Drive, ClickUp ainsi qu’un serveur MCP Linear, qui permet à un agent de lire les tickets directement depuis Linear. Lorsqu’un détail n’a jamais été inclus dans le ticket, l’agent doit le retrouver dans un fil de discussion ou un document, tout comme le ferait l’ingénieur de l’équipe lui-même.

Seule la tâche liée aux taxes fait appel à un service NestJS en TypeScript, à deux instances de la même autorité fiscale externe (un environnement de test et le système en production qui soumet réellement les déclarations), ainsi qu’à un registre InfluxDB où sont enregistrées les ventes achevées.

Les tâches utilisent le format Harbor, et la vérification reste cachée jusqu’au moment de l’évaluation. Cela vise à réduire les risques qu’un agent s’adapte à un test exposé plutôt qu’aux exigences réelles. Les outils de vérification proviennent de suites de tests déjà utilisées par ces entreprises, parfois mot pour mot.

Les auteurs expliquent leur motivation par une affirmation frappante : 99 % des tokens dans les entreprises réelles restent cachés aux modèles Frontier. Comme ces tâches proviennent de logiciels privés et non de projets publics sur GitHub, les modèles n’ont pas pu voir le code ou ses secrets pendant l’entraînement.

Les chiffres du benchmark lui-même montrent une longueur moyenne des instructions de 1 742 caractères, ce qui est inférieur à celui de FrontierCode (2 056) ou DeepSWE (1 975). Cependant, dans le cas médian, la correction de référence concerne 11 fichiers, contre 6 pour ces deux derniers.

Les résultats varient fortement d’une tâche à l’autre

Un seul score global masque deux groupes très différents : les tâches que les agents résolvent encore et encore, et celles qu’ils échouent à chaque fois. La méthode Multi-region Sweep a permis de résoudre 67,2 % des cas, les clés API et les environnements 65,6 %, les lignes de dépassement des droits d’accès 50 % et la migration de l’identité client 40,6 %.

La situation à la fin de la liste est préoccupante. La juridiction fiscale atteint 3,1 % et le balayage linéarisable 4,7 %, avec des valeurs similaires pour la mesure du stockage S3 (10,9 %), le comptage des tokens API (12,5 %) et la migration du calendrier de facturation (14,1 %). Pour le réducteur de flux analytique, personne n’a obtenu de résultat : zéro réussite en soixante-quatre tentatives.

En ce qui concerne la juridiction fiscale, les seules deux réussites proviennent de deux modèles différents, et chacun de ces modèles a échoué lors des sept autres tentatives sur la même tâche. Pour le balayage multi-régions, la tâche la plus simple, trois modèles ont réussi les huit tentatives, tandis que deux autres l’ont réussie deux fois. Une moyenne de 67,2 % masque un groupe qui n’a jamais échoué et un autre qui a presque toujours échoué.

L’un des auteurs a déclaré sur Hacker News que ces faibles taux reflètent des tâches « sur lesquelles de vrais ingénieurs ont travaillé pendant des semaines ».

Le classement complet :

Résolu 1 Fable 5.1 avec Claude Code 38,8% 2 GPT-6 Astra avec Codex CLI 33,8% 3 Gemini 3.8 Flash avec Gemini CLI 31,2% 4 GLM 5.3 avec Claude Code 28,8% 5 (ex-aequo) Grok 4.6 23,8% 5 (ex-aequo) Muse Spark 1.3 23,8% 7 Kimi K3 18,8% 8 GPT-5.6 Sol avec Codex CLI 16,2%

Un score ne suffit pas à expliquer l’échec

Chaque déploiement échoué porte l’une de cinq étiquettes, empruntées à la taxinomie de DeepSWE :

• Hypothèse non vérifiée. Au lieu de vérifier l’environnement de travail, l’agent suppose le comportement du système.

Exigence non respectée. Un élément demandé dans les instructions n’apparaît jamais dans la modification.

Erreur d’intégration. La méthode est valide, mais elle est connectée de manière incorrecte au système environnant.

Régression. La modification endommage quelque chose qui fonctionnait auparavant.

Fichier incorrect. La modification est apportée dans du code que l’application en cours d’exécution ne consulte jamais, comme par exemple un script temporaire.

Chaque pourcentage utilise les propres essais échoués du modèle comme dénominateur.

Grok 4.6 a présenté 61 échecs, dont deux tiers (67,2 %) correspondaient à des exigences non respectées. Gemini 3.8 Flash a enregistré 55 échecs, dont 49,1 % étaient des erreurs d’intégration. Chez GPT-5.6 Sol, le plus grand groupe d’échecs provient d’hypothèses non vérifiées, soit 43,3 % des 67 échecs, tandis que chez Fable 5.1, les 49 échecs sont répartis de manière plus équilibrée : environ 37 % correspondent à des exigences non respectées et environ 35 % à des erreurs d’intégration.

Deux modèles, Grok 4.6 et Muse Spark 1.3, ont atteint un niveau de 23,8 %, mais présentent des échecs de nature différente. Chez Grok, les échecs sont principalement dus à des exigences non respectées, tandis que chez Muse Spark, ce sont les erreurs d’intégration qui représentent 41 % des échecs. Les régressions ne dépassent jamais 10,9 % et sont nulles pour trois des huit configurations. La catégorie des fichiers incorrects n’apparaît que deux fois : GLM 5.3 (7 %) et Kimi K3 (3,1 %).

Une prudence s’impose. Les étiquettes ont bien été publiées, mais le processus qui les a générées n’est pas suffisamment décrit pour que ces pourcentages puissent être considérés comme des preuves définitives. La description publique ne précise pas si c’est des ingénieurs humains, un modèle automatisé ou une combinaison des deux qui ont effectué la classification.

Des essais plus longs ne signifiaient pas plus de fiabilité

Ces essais ont également été classés en fonction du temps écoulé. En moins de dix minutes, 70 sur 98 ont échoué, soit 71,4 pour cent. À dix minutes ou plus, 398 sur 542 ont échoué, soit 73,4 pour cent.

L’utilisation de tokens raconte une histoire similaire. Grok 4.6 atteint en moyenne de 3 000 à 20 000 tokens de sortie sur huit des dix tâches, mais il produit 261 000 tokens lors de la tâche de balayage linéarisable et 315 000 tokens lors de la tâche de réduction de flux analytique, les deux tâches ayant les scores les plus bas. Une utilisation élevée de tokens peut être un signe d’alerte, surtout lorsqu’elle dépasse considérablement la valeur de référence normale d’un système. Lorsqu’une exécution génère plusieurs fois plus de résultats que prévu, il convient d’examiner l’évolution ou d’intervenir, plutôt que de laisser une tentative bloquée consommer inutilement des ressources.

L’agent le plus cher n’était pas toujours le meilleur

Le coût estimé pour une seule exécution varie de 2,50 $ (Gemini 3.8 Flash) à 6,96 $ (Fable 5.1), et cet ordre de prix ne correspond pas vraiment au classement des meilleurs résultats. GPT-5.6 Sol coûte 2,65 $ et se classe en dernier, tandis que l’option la moins chère, Gemini 3.8 Flash, occupe la troisième place. Il s’agit de estimations de référence et non d’un classement des prix universel, car les dépenses réelles dépendent des tarifs, des paramètres, de la durée de la tâche, des tentatives de réexécution et de l’utilisation des outils.

Fable 5.1 coûte 2,78 fois plus cher que Gemini 3.8 Flash et produit des résultats 7,6 points de pourcentage meilleurs. Le fait que cela en vaille la peine dépend du coût d’une tâche échouée. Dans ce contexte, une échec correspond à une erreur de facturation, à un client taxé alors qu’il était exempté, ou à un dossier qui ne s’aligne pas à la fin du trimestre. Pour une simple modification de l’interface, les montants sont complètement différents.

Une grande partie de cette différence provient du volume de tokens générés. GLM 5.3 atteint en moyenne 117 000 tokens de sortie par exécution, tandis que GPT-6 Astra en génère 24 000, soit une différence de près de cinq fois supérieure pour les mêmes dix tâches. Les auteurs du benchmark mettent en garde concernant deux modèles : Grok 4.6, au prix de 3,44 $, et Kimi K3, à 3,90 $, ne disposent que de certains données d’utilisation, ce qui signifie que le coût réel pourrait être plus élevé. Il convient de considérer ces valeurs comme des minimums.

Même outil, dix-sept points de différence

Chaque entrée associe un modèle aux outils fournis par son propre fournisseur, c’est pourquoi le benchmark décrit les résultats comme des "combinaisons modèle-outil plutôt que des modèles isolés". Cependant, deux outils apparaissent à deux reprises, permettant une comparaison approximative. Avec Codex CLI, GPT-6 Astra atteint 33,8 % de performance contre 16,2 % pour GPT-5.6 Sol, soit une différence de 17,6 points. Avec Claude Code, Fable 5.1 atteint 38,8 % et GLM 5.3 28,8 %, soit une différence de dix points.

Néanmoins, dix tâches et huit configurations constituent un tableau restreint, et chaque score est accompagné d’une intervalle de confiance publié. Chaque modèle a été testé 80 fois : ainsi, les 38,8 % de Fable 5.1 correspondent à 31 réussites, tandis que les 16,2 % de GPT-5.6 Sol représentent 13 réussites. Si une seule tâche change de résultat pour un modèle, son score varie de plusieurs points. Personne ne devrait choisir un fournisseur en se basant sur un tableau de cette taille, et les auteurs ne le demandent à personne non plus. Ce que cet exercice montre, c’est que les scores publics peuvent être un guide incomplet pour évaluer les performances dans une base de code privée, et il associe cinq catégories pratiques d’échecs à cette différence.

Testez les cinq catégories sur votre propre code

C’est la taxinomie qui est transmissible ; vous pouvez l’appliquer à votre propre répertoire quand vous le souhaitez.

Prenez les vingt dernières demandes de fusion ouvertes par un agent, et attribuez à chacune qui a échoué ou a fait l’objet de modifications importantes une seule des cinq catégories. Comptez-les. La répartition obtenue constitue le résultat, et elle ne correspondra pas au modèle dont vous avez lu cette semaine, car elle dépend autant de votre base de code et de vos habitudes de rédaction des tickets que du modèle lui-même. La catégorie qui se révèle être la plus fréquente fera l’objet d’une restriction correspondante.

Si des hypothèses non vérifiées dominent, il est nécessaire de tenir un journal de lecture. Demandez à l’agent d’enregistrer les fichiers qu’il a ouverts avant de modifier quoi que ce soit, et rejetez la modification si la liste omet le fichier où se trouve le comportement concerné. Les exigences manquantes remontent généralement au ticket correspondant. Transformez l’instruction en une liste de critères d’acceptation et cochez-les un par un, car une instruction contenant cinq exigences dissimulées dans un long paragraphe est à l’origine des 67,2 % de cas rencontrés par Grok. Les erreurs d’intégration signifient que les tests réussissent au niveau unitaire mais échouent dans la chaîne d’appels, il faut donc tester le parcours suivi par l’application en production, en partant de son point d’entrée. Une erreur liée au mauvais fichier est suffisamment rare pour qu’un seul cas mérite d’être investigué : assurez-vous que chaque fichier modifié puisse être atteint depuis le code réellement invoqué par l’application.

Dès lors, il suffit de suivre un seul indicateur : la proportion des demandes de modification soumises par les agents qui sont approuvées dès la première révision, ventilée selon la catégorie d’échec. Cet indicateur varie lorsque les contrôles s’assouplissent ou se renforcent, ainsi que lorsqu’il y a des modifications dans le modèle sous-jacent.