DeepSWE v1.1 : ce que mesure un patch qui passe son vérificateur, et quand son pass@1 ne prouve plus que l’agent a résolu la tâche

Le chiffre n’appartient pas au seul modèle

Un score DeepSWE v1.1 ne décrit pas une propriété isolée d’un modèle de langage. Il décrit le résultat d’une configuration expérimentale complète : un modèle servi par un fournisseur, un niveau d’effort de raisonnement lorsque cette option existe, un harnais d’agent, un ensemble d’outils, des limites de contexte et de temps, des instructions, une politique d’arrêt et un système d’évaluation. L’unité observée est le patch commité par cette configuration face à une tâche donnée, et non une réponse textuelle du modèle ou une capacité générale mesurée hors de cet environnement.

Cette distinction est particulièrement importante lors de la lecture du leaderboard DeepSWE. Le site officiel indique que les modèles sont exécutés avec mini-SWE-agent afin de rechercher une certaine cohérence, mais cette décision n’élimine pas toutes les variables. Une même famille de modèles peut apparaître avec différents niveaux de raisonnement ou fournisseurs ; en outre, une mise à jour du harnais, du prompt, des outils ou de l’infrastructure peut modifier le résultat sans changer le modèle sous-jacent. Une comparaison directe exige donc de vérifier que les deux lignes emploient des conditions équivalentes et la même version d’évaluation.

Le terme pass@1 ne doit pas non plus être lu comme une garantie que l’agent résoudra le prochain ticket d’un dépôt interne. Dans l’article méthodologique de DeepSWE, le pass@1 est défini comme la moyenne, par tâche, du taux de succès observé dans les exécutions. C’est une agrégation des performances constatées dans cette collection et avec ce protocole. Elle résume des résultats expérimentaux, mais n’identifie pas à elle seule la cause de chaque succès, de chaque échec ou d’un écart entre configurations.

Ce que DeepSWE cherche à mesurer

DeepSWE se présente comme un benchmark pour des agents d’ingénierie logicielle travaillant sur des tâches originales de longue haleine. La documentation des auteurs décrit 113 tâches réparties dans 91 dépôts. Chaque tâche associe un contexte de dépôt à une demande de changement et à des mécanismes programmatiques destinés à vérifier le comportement attendu. L’objectif affiché n’est pas de retrouver une correction déjà publiée, mais de produire une solution nouvelle à la tâche soumise.

Selon la présentation de Datacurve, les solutions de référence ont été écrites à partir de zéro et n’ont été ni copiées ni adaptées d’une pull request, d’un commit ou d’un patch public existant. Certaines tâches peuvent être motivées par des problèmes non résolus, mais cette motivation ne signifie pas qu’une solution upstream exploitable existe comme référence. Il s’agit d’une affirmation de conception des créateurs : elle est importante car elle vise à réduire le recouvrement avec les benchmarks bâtis à partir d’incidents historiques, mais elle ne suffit pas à démontrer l’absence de contamination dans les données d’entraînement ou les outils externes.

Le format public du dépôt officiel est utile à l’audit, car il documente notamment les métadonnées, le prompt, le Dockerfile, les tests ou le vérificateur et la solution de référence. Il devient alors possible d’inspecter une tâche donnée au lieu d’inférer sa difficulté à partir du nom du dépôt. La disponibilité des artefacts ne rend toutefois pas automatiquement chaque conclusion reproductible : pour répéter une ligne, il faut aussi le commit, les images ou dépendances réellement utilisées, les identifiants et versions des outils, ainsi que les journaux d’exécution pertinents.

Le patch, le conteneur propre et le vérificateur

Pour v1.1, Datacurve décrit une procédure dans laquelle seul le patch commité est évalué dans un conteneur de vérification distinct et propre. Le dépôt officiel documente également l’extraction du commit sous forme de patch, puis son application dans un environnement vierge à partir de cette version. Cette conception cherche à séparer le résultat final d’effets transitoires ayant pu survenir pendant la trajectoire de l’agent, tels que des modifications non commitées ou des manipulations du processus de test dans son environnement de travail.

La documentation v1.1 affirme que le rapport CTRF enregistre par leur nom les tests qui définissent chaque tâche. Dans cette approche, supprimer des tests ou forcer une sortie anticipée devrait produire des résultats manquants ou échoués, et non une réussite. Des changements destinés à corriger la dérive des dépendances et les tests instables sont également présentés. Ces améliorations sont cohérentes avec l’objectif d’évaluer un patch transportable, mais elles restent des décisions d’implémentation du benchmark : tout système de notation contient des hypothèses sur les fichiers à restaurer, les commandes à exécuter et les preuves qui comptent comme résultat.

La séparation entre le conteneur de l’agent et celui de vérification a une conséquence pratique. Un patch peut fonctionner pendant une trajectoire donnée puis échouer lors de sa réapplication propre ; dans ce cas, l’échec exprime une absence de reproductibilité du changement final selon le protocole. À l’inverse, un changement conforme à l’intention de la tâche peut échouer si la restauration, le remplacement de fichiers ou la détection des résultats interfèrent avec le comportement à vérifier. Distinguer ces deux cas exige de conserver assez d’artefacts pour examiner le verdict.

Ce que notent pass@1 et pass@4, et ce qui doit être déclaré

L’article DeepSWE définit le pass@1 comme la moyenne par tâche du taux de succès, et le pass@4 comme la fraction des tâches résolues dans au moins une de quatre tentatives. La différence est importante : le pass@1 renseigne sur le rendement d’une tentative individuelle dans la distribution d’exécutions utilisée ; le pass@4 reflète le bénéfice de plusieurs tentatives. Ces mesures ne sont pas interchangeables et un classement selon l’une peut ordonner les configurations différemment de l’autre.

Les auteurs documentent environ quatre rollouts par tâche et des intervalles de confiance à 95 %. Ces intervalles aident à ne pas surinterpréter de petits écarts, notamment lorsque des configurations proches se recouvrent. Un intervalle ne corrige toutefois pas une incompatibilité méthodologique. Si deux résultats proviennent de vérificateurs, politiques de réessai, délais d’exécution ou critères d’exclusion différents, leur incertitude statistique ne résout pas le changement de l’objet mesuré.

Une fiche de résultat responsable doit au minimum déclarer la version de DeepSWE, le modèle et le fournisseur, la version de mini-SWE-agent, le niveau de raisonnement, le nombre de rollouts, la politique d’arrêt, les limites de temps et de contexte, la date ou version de l’infrastructure et le traitement des erreurs. Elle doit aussi séparer le score calculé des cas exclus. Sans cela, le lecteur ne peut savoir si une différence vient de la capacité de résolution, de la disponibilité du service, de choix de budget ou de changements de l’évaluateur.

Échecs comptés, erreurs exclues et biais de sélection

La méthodologie publiée par les auteurs indique que les timeouts comptent comme des échecs. Elle précise également que les erreurs de fournisseur, de réseau ou du vérificateur peuvent être exclues. La distinction est opérationnellement raisonnable : une interruption externe à l’agent n’équivaut pas nécessairement à une incapacité à résoudre le problème. Mais l’exclusion impose une obligation de transparence, car la classification d’un événement détermine le dénominateur employé dans le score publié.

Un timeout peut révéler une limite réelle du système que l’on envisage de déployer, même s’il ne révèle pas une limite sémantique du modèle. Une évaluation utile devrait donc afficher à la fois le taux principal selon ses règles, le nombre et la nature des exécutions exclues, ainsi que les artefacts justifiant chaque décision. Regrouper sous le terme « infrastructure » une erreur reproductible de préparation de tâche empêcherait des tiers d’évaluer s’il s’agit d’un défaut du benchmark ou d’une condition exceptionnelle de l’environnement.

Il faut également demander si une exclusion est décidée avant l’inspection du patch et si la règle s’applique de la même manière à tous les modèles. Une politique rétrospective ou peu documentée peut avantager involontairement une configuration. Les sources fournies ici n’apportent pas d’élément permettant d’affirmer que cela se produit dans DeepSWE ; il s’agit d’une condition d’audit à vérifier avant d’utiliser le score pour des achats, une sélection de fournisseurs ou des décisions de déploiement.

Pourquoi v1 et v1.1 ne doivent pas être mélangées sans réexécution

Datacurve affirme que v1.1 conserve les mêmes tâches, mais modifie l’exécution et l’évaluation. Parmi les changements décrits figurent la vérification du patch commité dans un conteneur propre, le rapport CTRF et des corrections relatives aux dépendances et aux tests instables. Même si l’ensemble des énoncés demeure identique, une modification de l’environnement de notation peut changer les patchs qui réussissent ou échouent.

Il n’est donc pas possible de traiter un chiffre de v1 et un autre de v1.1 comme deux points d’une même série sans avertissement clair. Il ne serait pas valide d’attribuer toute différence à une amélioration ou une régression du modèle si la manière de reconstruire l’environnement ou de vérifier les tests a aussi changé. La comparaison la plus solide entre versions consiste à réexécuter la même configuration sous chaque protocole et à publier les résultats par tâche, avec les changements de verdict.

La même prudence vaut pour les comparaisons au sein de v1.1 si le leaderboard évolue. Une table publique est un registre précieux d’exécutions déclarées, non une preuve suffisante d’équivalence historique. Toute personne devant prendre une décision à fort impact devrait figer un commit du benchmark et du harnais, conserver les images de conteneur et exécuter une matrice contrôlée de configurations.

Le conflit sur les modifications de tests

La revue indépendante d’Epoch AI soulève une limite précise de DeepSWE v1.1. Selon cette revue, ses auteurs ont confirmé manuellement au moins 23 faux négatifs parmi les 113 tâches. Ils expliquent que 18 de ces cas sont liés à des agents ayant modifié des tests existants, puis à une préparation ultérieure du vérificateur qui restaure ou remplace des fichiers. Le résultat signalé est qu’un agent peut avoir produit un changement fonctionnellement correct au regard de l’intention de la tâche et recevoir néanmoins un échec du fait de l’interaction entre son patch et le protocole d’évaluation.

Cette constatation doit être attribuée à Epoch AI et lue dans le périmètre qu’elle déclare. La revue indique s’être arrêtée après avoir dépassé son seuil pour considérer le benchmark comme défectueux ; elle ne fournit donc pas une estimation définitive du taux total de faux négatifs et ne démontre pas que chaque résultat DeepSWE est invalide. Elle ne permet pas non plus d’inférer, à partir de ce seul chiffre, dans quelle mesure les positions du leaderboard changeraient : pour cela, il faudrait répéter les cas concernés sous une version corrigée et publier la réattribution des verdicts par configuration.

Il existe en outre une tension réelle entre deux objectifs. L’évaluateur veut empêcher qu’un agent obtienne une réussite en altérant les tests de la tâche. Mais une règle qui restaure ou remplace des fichiers doit distinguer une manipulation qui contourne le contrôle d’une modification de test faisant partie d’un changement légitime, ou interagissant de façon imprévue avec le vérificateur. La documentation officielle de v1.1 soutient que le rapport de tests détecte les absences et sorties anticipées. L’audit suggère que cette sauvegarde n’évite pas tous les faux négatifs identifiés. Avec les sources disponibles, ces deux affirmations portent sur des niveaux différents : la conception prévue et un ensemble de comportements observés en revue.

Ce qu’un score élevé permet de conclure

Un score élevé dans DeepSWE v1.1 constitue la preuve qu’une configuration concrète a réussi à produire des patchs acceptés par le protocole sur une collection de tâches originales d’ingénierie logicielle. Lorsque le résultat s’accompagne d’artefacts et de conditions reproductibles, il offre un signal utile pour présélectionner des agents destinés à des tâches autonomes de correction et de développement, impliquant dépôts, commandes et tests.

Le signal est plus informatif qu’une évaluation limitée à des extraits de code isolés parce qu’il inclut la navigation dans un dépôt, des modifications de plusieurs fichiers, l’usage d’outils et une vérification fonctionnelle. Il peut aussi aider à distinguer en pratique des configurations qui semblent similaires sur des benchmarks plus saturés. Sa valeur reste néanmoins conditionnelle : elle dépend du fait que la population de tâches, les contraintes du harnais et le vérificateur ressemblent au cas d’usage sur lequel une décision sera prise.

La conclusion prudente n’est pas que l’agent « sait maintenir un logiciel en production », mais qu’il a montré une capacité mesurée à résoudre une fraction des tâches de ce benchmark selon un protocole défini. Cette formulation préserve l’information utile et évite de transposer un résultat expérimental vers des domaines que DeepSWE n’observe pas directement.

Ce qu’il ne permet pas de conclure, et comment lire une ligne du leaderboard

Le benchmark n’établit pas à lui seul la fiabilité dans un dépôt interne, la sécurité des changements, la qualité d’une revue de conception, la compatibilité avec les politiques internes ou la capacité à déboguer des systèmes connectés à la production. Il ne mesure pas non plus complètement le coût opérationnel : un score comparable peut exiger un nombre différent de tokens, de temps écoulé, de tentatives ou de supervision humaine. L’autonomie en entreprise suppose aussi des permissions, de l’isolation, un contrôle des dépendances, de la revue, de l’observabilité et des procédures de retour arrière.

Une ligne ne prouve pas davantage que l’agent n’a pas trouvé une solution exploitant une lacune du vérificateur, ni que chaque échec traduit une incapacité à satisfaire l’exigence. La revue d’Epoch AI rend cette dernière réserve particulièrement pertinente dans les cas qu’elle a examinés. Inversement, un audit partiel de faux négatifs ne permet pas de conclure que le benchmark est sans valeur. L’interprétation correcte est que l’erreur de mesure et le désaccord entre intention et verdict doivent faire partie de l’analyse de risque.

Pour comparer Grok 4.6, DeepSeek V4.1 Flash ou d’autres systèmes dans DeepSWE, un acheteur technique devrait d’abord filtrer les lignes par même version, même harnais et conditions d’inférence équivalentes. Il doit ensuite examiner les intervalles, les erreurs exclues et les artefacts des tâches limites. Enfin, il devrait compléter cette présélection par une évaluation interne sur des dépôts représentatifs, avec des politiques de sécurité et des coûts proches du déploiement envisagé. DeepSWE peut être une entrée dans cette décision, pas son substitut.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.