Dans une nouvelle étude, Claude Opus 4.7 a bloqué l’exploitation fournie dans 90,2 % des cas, mais seuls 60,7 % de ses correctifs ont réussi les tests des développeurs d’origine. L’écart de 29,5 points est central : supprimer un plantage ne prouve pas que la réparation préserve le comportement attendu.
Dang K Le, Wenxuan Shi et Xinyu Xing, de Northwestern, ont présenté le 7 octobre cette étude de fiabilité des benchmarks, portant sur 112 bogues historiques de 84 projets ouverts en C, C++, Go et Rust. Le préprint concerne des configurations précises de Claude et d’agents, pas un taux universel d’échec des réparations autonomes ou en production.
Des modèles meilleurs, un écart persistant
Les essais contrôlés utilisent OpenCode avec Sonnet 4.0, Sonnet 4.5 et Opus 4.7 sur les mêmes cas. Les agents reçoivent les instructions de compilation et de test, mais initialement pas le contenu du PoC, l’entrée ou la procédure démontrant le défaut.
Sonnet 4.0 réussit 77,7 % des PoC et 43,8 % des tests développeurs ; Sonnet 4.5 atteint 84,8 % et 48,2 %, Opus 90,2 % et 60,7 %. Opus progresse réellement sur les deux mesures. Pourtant, 32,7 % de ses correctifs validés par PoC échouent au test développeur, environ un succès apparent sur trois, comme le souligne l’analyse publique de notation.
Opus passe aussi 94,6 % des tests de régression existants, sans résoudre l’écart. Les anciennes suites contrôlent des exemples connus ; un test ajouté avec le vrai correctif peut exprimer le comportement auparavant absent près de la faille.
Les chercheurs reconstruisent les tests unitaires ou d’intégration ajoutés aux commits correctifs puis les appliquent après l’agent. Ils mesurent le comportement, pas la ressemblance textuelle : une autre implémentation peut réussir. La résolution complète exige compilation, suppression répétée du PoC, régressions et nouveau test développeur.
PHP montre un plantage supprimé pour la mauvaise raison
Un ancien bogue PHP de range() classait mal les types mixtes et pouvait traiter une valeur non textuelle comme une chaîne. Refuser immédiatement les types mixtes supprimait le plantage et pouvait conserver beaucoup d’anciens tests, mais rejetait des combinaisons valides que PHP devait convertir.
Le correctif amont réparait la classification sans perdre ce comportement. Un test sur une entrée voisine valide distinguait réparation et contournement trop restrictif. Une notation limitée au plantage récompenserait les deux.
Une garde peut être une atténuation d’urgence sans réparation complète. Le surajustement aux tests satisfait les exemples plutôt que l’exigence. En sécurité, il masque un symptôme, laisse un autre chemin et crée une assurance trompeuse qui réduit l’examen.
Les tests développeurs sont un meilleur indicateur, pas une acceptation totale. Ils n’épuisent ni performance, compatibilité, lisibilité ou architecture. Une alternative défendable peut changer volontairement un comportement non documenté ; l’échec historique indique donc un désaccord à examiner, pas automatiquement un danger.
Les instructions changent la capacité mesurée
Avec commandes détaillées, Sonnet 4.0 réussit 77,7 % des PoC, contre 74,1 % sans elles. Le test développeur passe de 41,1 % à 43,8 %. Pour C/C++ seulement, les instructions font passer le PoC de 72 % à 92 %, mais les tests développeurs de 28 % à 36 %.
La documentation est une aide légitime, également pour un humain. Mais les scores ne se comparent pas sans budgets d’information. Go et Rust ont souvent des commandes prévisibles ; C/C++ multiplie systèmes, options et enveloppes. L’aide à l’environnement peut déplacer le score avant même l’examen de la réparation.
Dans 62 cas Go, un PoC source fait monter les plantages évités de 69,4 % à 95,2 %, contre 41,9 % à 48,4 % aux tests développeurs. Un harnais lisible révèle API et structure des appels et facilite l’adaptation au test visible.
Dans 25 cas C/C++, montrer une entrée binaire ou textuelle opaque ne change ni 92 % de PoC ni 36 % de tests développeurs. Les deux configurations peuvent annoncer un PoC fourni, mais seule l’une révèle l’intention exécutable. L’information n’est pas équivalente.
Recherche et infrastructure déforment les scores dans les deux sens
Les tâches historiques ont souvent tickets, avis et correctifs publics. L’étude documente un agent trouvant la réparation amont sur le Web et un autre dans un historique Git non nettoyé. Le succès ne mesure alors pas proprement un raisonnement indépendant.
Consulter Web et historique est raisonnable en production. La contamination dépend d’une promesse de raisonnement sans aide. Un test de recherche et d’outils peut l’autoriser explicitement. La mémorisation de corrections historiques limite aussi les taux absolus.
Les défauts du framework peuvent inversement cacher un bon travail ou exposer une réponse secrète. Permissions, délais et collisions de fichiers empêchent compilation ou notent à tort. Des problèmes individuels affectaient environ 5–32 % des cas sur des exécutions complètes, parfois plus que les écarts de classement.
Un score appartient donc à l’ensemble modèle, agent, prompt, outils, source, limites et notation. Les contrôles utilisaient OpenCode avec Claude ; des études de cas employaient aussi Claude Code avec Sonnet 4.5. Ces environnements ne sont pas interchangeables.
Les études voisines exigent plusieurs tests
PVBench examine 209 cas dans 20 projets : plus de 40 % des correctifs acceptés par les contrôles élémentaires échouent aux tests dérivés des réparations développeurs. Données et conception diffèrent ; ce n’est pas un taux Claude directement comparable.
PatchBench constate une inflation moyenne de 1,83 des taux de résolution sur 11 agents avec PoC seul. Rejeu de sécurité, tests unitaires et sorties ramènent les meilleurs d’au-delà de 97 % sur PoC à environ la moitié sous validation combinée.
PatchBench choisit aussi des défauts dont la réparation est hors pile de plantage et les transplante dans des dépôts modifiés pour réduire l’intérêt du rappel historique. Il ne suppose pas que tout succès soit un nouveau raisonnement.
CyberGym-E2E, à Berkeley, couvre 920 vulnérabilités de 139 projets et combine découverte, reproduction et réparation. Les meilleurs réparent environ 80 % avec cible fournie ; l’ensemble baisse lorsqu’ils doivent découvrir la faille. Des gardes superficielles apparaissent encore.
Modèles, tâches et définitions diffèrent, sans classement commun. La méthodologie Cyber Index élargit aussi à audit, découverte, reproduction et réparation sans casser les usages légitimes. Le problème partagé est ce que contient un pourcentage de succès.
Un meilleur oracle n’est pas une preuve de production
L’échantillon Northwestern exige compilation reproductible et tests amont significatifs. Ses 112 défauts sont variés, pas représentatifs de tout. Les données publiques peuvent avoir servi à l’entraînement. Cela limite les taux, sans effacer les effets contrôlés de prompts ou d’oracles.
La production peut être plus sûre avec tests internes, analyse statique, fuzzing, revue et déploiement progressif, mais plus difficile avec tests incomplets, comportements non documentés et dépendances absentes. Ni benchmark propre ni PoC réussi ne justifie à lui seul une mise en production sans contrôle.
Il faudrait publier PoC et intention développeur séparément, droits outils et réseau, nettoyage Git, délais et échecs par étape, puis suivre acceptations, révisions et refus des mainteneurs en production. Autres chemins d’attaque et nouvelles faiblesses comptent aussi ; la similarité textuelle ne remplace pas la validation comportementale.
Une base de connaissances techniques interrogeable peut conserver prompts, traces, correctifs et vérifications, sans rendre le code juste. La conclusion étayée est un progrès réel d’Opus et une surestimation de 29,5 points par le seul plantage. Une réparation générée reste un candidat nécessitant des preuves indépendantes de sécurité et de comportement légitime.