Claude Opus 5 obtient 24 % sur SlopCodeBench, le benchmark qui piège tous les modèles de code

Ce qu’il faut retenir :

• Claude Opus 5 a validé 4 checkpoints sur 17 lors d’un test SlopCodeBench, soit 24 % de réussite stricte.
• Aucun des trois modèles testés n’a terminé un seul problème sans laisser de défauts ouverts.
• Le benchmark mesure la capacité à faire évoluer une base de code sans casser l’existant.

Claude Opus 5 a validé 4 checkpoints sur 17 lors d’un passage sur SlopCodeBench, soit un taux de réussite stricte de 24 %, contre 6 % pour Opus 4.8 et Sonnet 5. Le modèle d’Anthropic termine premier de ce comparatif tout en échouant sur les trois problèmes proposés, sans jamais boucler un exercice complet sans défaut.

Qu’est-ce que SlopCodeBench et en quoi diffère-t-il des autres benchmarks ?

Le benchmark vient du laboratoire de Gabe Orlanski, à l’université du Wisconsin-Madison. Sa particularité : il ne dévoile pas l’énoncé complet au départ. Les tests de référence habituels comme SWE-bench, qui fournit une issue GitHub et une base de code, ou LiveCodeBench, qui sert un exercice de type LeetCode, posent le problème en entier dès la première ligne. Le modèle n’a donc aucune raison d’écrire du code facile à modifier plus tard, puisque la spécification ne bouge jamais.

SlopCodeBench découpe chaque défi en checkpoints successifs et révèle les exigences au fil de l’eau. Le critère de réussite est impitoyable : à chaque étape, tous les tests de non-régression des étapes précédentes doivent encore passer. Une erreur au checkpoint 4 fait tomber les checkpoints 5 à 8, sauf réparation accidentelle en cours de route.

Le test n’était pas saturé à sa sortie. Les meilleurs modèles disponibles alors, GPT-5.4 et Opus 4.6, plafonnaient à 11 % et 17 % de réussite stricte.

Quatre checkpoints validés sur dix-sept

Le protocole a opposé trois modèles Claude, Opus 4.8, Sonnet 5 et Opus 5, sur trois problèmes totalisant 17 checkpoints : un simulateur de circuits classé facile en 8 étapes, un outil de migration de base de données en 5 étapes, et une API de service de configuration dynamique classée difficile en 4 étapes. Chaque modèle disposait d’une fenêtre de contexte neuve à chaque checkpoint, avec des prompts identiques, dans le harnais Claude Code.

Pendant les deux premières heures de ce marathon de six heures, Opus 5 a été le seul modèle à enregistrer des réussites strictes, en enchaînant les trois premiers checkpoints du simulateur de circuits. Le reste du parcours a été moins flatteur : trois de ses quatre validations proviennent de ce seul début de problème. Sur l’API de configuration dynamique, la plus difficile, les trois modèles se sont effondrés.

La courbe des défauts raconte l’essentiel

Le taux de réussite final dit moins de choses que l’accumulation des défauts au fil des étapes. Sur le problème du simulateur de circuits, Opus 4.8 a empilé les anomalies dès le premier checkpoint, passant de 1 à 10. Sonnet 5 est resté à un niveau bas mais constant. Opus 5 a ouvert avec quatre checkpoints propres, avant de voir des défauts apparaître aux étapes 4 et 5, sans jamais les résorber.

Le scénario reproduit ce que vivent les équipes en production. Le modèle pose une architecture initiale propre. Les exigences bougent ensuite un peu, des signaux passent d’un bit unique à des vecteurs, une logique à deux valeurs devient une logique à trois valeurs, et la conception d’origine cède. Le modèle rafistole au lieu de refactorer, et chaque rustine rend la modification suivante plus coûteuse.

Plus de code, mais mieux rangé

Opus 5 a produit 29 065 lignes de code source sur les trois problèmes, environ trois fois le volume d’Opus 4.8 ou de Sonnet 5. La moitié de ce total, 51 %, relève du code de test : en production, l’écart tombe à 1,8 fois.

Le modèle a aussi écrit cinq fois plus de fonctions que ses prédécesseurs, avec un détail qui compte : seulement 14,9 % de ses fonctions ne sont appelées qu’une fois, contre 49,1 % pour Opus 4.8 et 71,5 % pour Sonnet 5. Beaucoup de petites fonctions réutilisables, donc, plutôt qu’un empilement de blocs monolithiques, au prix d’un volume de tokens considérable.

Aucun modèle n’a traversé les épreuves sans augmenter sa complexité cyclomatique, cette mesure du nombre de chemins d’exécution possibles dans une fonction. Opus 5 affiche la moyenne la plus basse, mais sur près de 2 000 fonctions. Opus 4.8 a fait le choix inverse, celui de grossir chaque fonction plutôt que de restructurer : sa complexité moyenne a bondi de 70 % en huit étapes et sa pire fonction a terminé à 93, quand la plupart des guides de style recommandent de refactorer au-delà de 10. Sa duplication de code est passée de 4,6 % à 16,8 %, avec un point d’inflexion au troisième checkpoint, précisément là où les nouvelles exigences commencent à contredire la conception initiale. Opus 5 est resté stable sur ce terrain, de 2,41 % à 2,64 %.

Les limites de l’exercice

Les métriques de SlopCodeBench restent perfectibles. Presque tout le code produit déclenche au moins une règle de détection de slop : 98 % pour Opus 4.8, 93 % pour Opus 5, 89 % pour Sonnet 5. La part de lignes jugées verbeuses grimpe de 65 % au premier checkpoint à environ 80 % au huitième, pour tous les modèles. Certaines règles paraissent trop agressives, les détecteurs pensés pour Python ayant signalé des lignes d’un monorepo TypeScript à un rythme 11,6 fois supérieur à celui d’une revue humaine.

Une évaluation plus fine se dessine, la métrique dite de passation. Le principe : un modèle de pointe construit les checkpoints 1 à N, puis un modèle plus faible reprend la base de code pour le checkpoint suivant. S’il y parvient sans rien casser, le code était maintenable. S’il échoue, le code relevait du slop. Un signal plus honnête que n’importe quelle analyse statique.

Et maintenant ?

Trois enseignements pour quiconque construit des pipelines de développement pilotés par des agents. Anticiper la dégradation, d’abord, avec des garde-fous automatisés sur la complexité, des seuils de couverture de tests et des revues de code. Tester la passation entre modèles ensuite, quand plusieurs interviennent à des étapes différentes. Mesurer la bonne chose enfin : le taux de réussite stricte sur des checkpoints incrémentaux prédit mieux la tenue en production qu’un score obtenu en une seule passe.

“On ne peut pas compter sur les modèles actuels pour tourner sans pilotage”, résume un observateur cité dans l’analyse. Les performances sur les benchmarks statiques comme HumanEval ne disent rien de la capacité à entretenir une base de code sur plusieurs mois. C’est pourtant cette compétence que réclament les usages agentiques en cours de déploiement.