Régression de qualité de Claude Code : ce qui s'est vraiment passé

Claude Code s'est dégradé de façon mesurable entre mars et avril 2026. Pas à cause des modèles. Trois modifications distinctes au niveau produit, empilées les unes sur les autres, ont dégradé la qualité du raisonnement pendant six semaines avant qu'Anthropic publie un post-mortem complet le 23 avril.

L'API brute n'a pas été touchée. Les dégâts ont frappé le CLI Claude Code, le Claude Agent SDK, et Claude Cowork. Les trois causes sont désormais corrigées dans la v2.1.116.

Trois changements, pas un seul

Chaque problème avait sa propre chronologie, sa propre portée, et sa propre date de correction. Ils se sont chevauchés, ce qui les a rendus difficiles à reproduire.

La dégradation de l'effort de raisonnement est arrivée en premier. Les évaluations internes indiquaient que medium offrait "une intelligence légèrement inférieure avec une latence nettement réduite pour la majorité des tâches" — un compromis qui semblait acceptable jusqu'à l'arrivée des données terrain. Le bug de cache a suivi trois semaines plus tard et a amplifié les dégâts : Claude réfléchissait moins et perdait le fil de ce qu'il avait déjà fait. Le cap de verbosité a frappé en dernier, effet secondaire des préparatifs du lancement d'Opus 4.7. Les tests d'ablation ont montré une baisse de 3 % de la qualité du code pour Opus 4.6 et 4.7 rien que pour ce prompt.

Les données AMD : à quoi ressemble un effondrement de 70 % du raisonnement

Le signal le plus clair est venu de l'extérieur d'Anthropic. Stella Laurenzo, Senior Director of AI chez AMD, a ouvert la GitHub issue #42796 le 2 avril après que son équipe ait détecté quelque chose d'anormal. L'analyse portait sur 6 852 fichiers de session, 234 760 appels d'outils, et 17 871 blocs de réflexion.

Le ratio lecture/modification est l'empreinte comportementale la plus claire. Un agent de code qui fonctionne bien lit le code environnant avant de le toucher. Ce ratio est passé de 6,6 lectures par modification (du 30 janvier au 12 février) à 2,0 entre le 8 et le 23 mars. Une chute de 70 %. Le modèle modifiait sans comprendre le contexte.

La profondeur de réflexion a suivi la même tendance. La médiane estimée de profondeur de réflexion a chuté d'environ 67 %, passant de 2 200 à 720 caractères environ, fin février — avant que la rédaction des réflexions ne rende la mesure directe plus difficile.

Les violations de stop-hook racontent l'histoire en termes de production :

L'effort humain est resté stable (environ 5 600 prompts chaque mois). Les coûts sont passés de 12 $ à 1 504 $ par jour sans gain de productivité. Ce n'est pas une dégradation lente. C'est un effondrement.

BridgeBench (NS3.AI) a mesuré indépendamment la chute de précision d'Opus 4.6 de 83,3 % à 68,3 % sur la même période, avec son classement passant de la 2e à la 10e place parmi les modèles de code en production. L'équipe AMD a migré vers un autre fournisseur d'IA après ces mesures.

La GitHub issue se termine par une section intitulée "A Note from Claude". Opus 4.6 a lui-même rédigé l'analyse, en analysant ses propres logs de session. Dernière ligne : "I cannot tell from the inside whether I am thinking deeply or not."

Pourquoi Anthropic ne l'a pas détecté plus tôt

Trois facteurs ont ralenti la détection.

Chaque modification ciblait un segment de trafic différent sur un calendrier différent. La dégradation de l'effort de raisonnement affectait les longues sessions de réflexion. Le bug de cache affectait le contexte multi-tours. Le cap de verbosité affectait la longueur des sorties. Aucune évaluation unique n'a capté les trois à la fois.

Deux expériences internes sans lien étaient en cours simultanément pendant la fenêtre du bug de cache. Elles ont activement brouillé la reproduction : toute tentative d'isoler le bug tombait sur l'une des expériences, produisant du bruit qui ressemblait à de l'incohérence plutôt qu'à un défaut systématique.

L'écart entre modèles joue aussi un rôle. Opus 4.7 (avec le contexte complet du dépôt chargé) a trouvé le bug de cache pendant l'enquête. Opus 4.6, non. Un modèle qui tourne avec un contexte dégradé ne peut pas auditer de façon fiable si son propre contexte est dégradé.

Il y avait aussi un écart structurel : les équipes internes d'Anthropic n'utilisaient pas toutes le même build que les abonnés publics. Le post-mortem nomme cela directement comme un point à corriger.

Ce que le post-mortem ne répond pas complètement

Les trois causes sont documentées. Ce que le post-mortem aborde moins directement, c'est une préoccupation plus large que la communauté a soulevée : le harness lui-même.

Un post détaillé sur r/ClaudeAI soutient que le vrai problème est que le harness de Claude Code auto-injecte plus de 40 rappels système, a livré plus de 158 versions de prompt système depuis la v2.0.14, contient des instructions contradictoires entre ces versions, et inclut des prompts qui demandent à Claude de cacher leur existence aux utilisateurs. Chaque nouvelle injection réduit le budget de raisonnement effectif, avant même que les trois régressions d'avril n'entrent en jeu.

Un point de données appuie cette inquiétude : un utilisateur utilisant un harness personnalisé minimal appelé "Euler" a signalé zéro impact des trois régressions. La surcharge du harness n'était tout simplement pas là pour amplifier les dégâts.

Les engagements d'Anthropic portent sur la gouvernance des changements de prompts à l'avenir. Ils ne décrivent pas de plan pour réduire la surface de prompts existante. Cette question reste ouverte.

Ce qu'il faut surveiller si tu construis sur Claude Code

La régression était invisible pour la plupart des utilisateurs jusqu'à ce que les coûts explosent ou que la qualité des sorties se dégrade de façon notable en production. Quelques pratiques l'auraient révélée plus tôt.

Surveille le ratio lecture/modification. Les données AMD montrent que c'est le signal comportemental avancé. Si ton agent commence à modifier plus qu'il ne lit, quelque chose a changé en amont. Pas besoin de savoir pourquoi pour savoir que quelque chose ne va pas.

Les quality gates détectent les échecs de sortie même quand elles n'en identifient pas la cause. Dans un workflow Build This Now, chaque feature passe les vérifications TypeScript, lint, et un build propre avant d'être marquée comme terminée. Pendant la régression, un agent qui modifie sans lire le contexte produit des builds cassés et des erreurs de types plus vite que dans des conditions normales. La gate échoue, tu vois plus de boucles d'itération. Ce n'est pas de la prévention — un code syntaxiquement valide mais logiquement faux peut passer un type check. Mais c'est une couche de détection qui remonte les problèmes avant qu'ils ne soient livrés.

La variabilité selon l'heure est réelle. Les données de session AMD montrent que la profondeur de réflexion est la plus faible aux alentours de 17h PST. Si tu lances des tâches coûteuses ou complexes, plus tôt dans la journée donne des résultats plus cohérents avec l'infrastructure publique actuelle.

Épingle ta version. La v2.1.101 a corrigé le bug de cache. La v2.1.116 contient les trois corrections. Si tu as des workflows automatisés, épingle une version connue comme bonne et teste avant de mettre à jour. La régression est arrivée silencieusement entre des versions mineures.

L'API brute n'a pas été affectée. Si tu rencontres des problèmes qui ressemblent à des problèmes de profondeur de raisonnement, teste le même prompt directement contre l'API sans le harness Claude Code. Si le résultat de l'API est nettement meilleur, le problème vient de la couche produit, pas des poids du modèle.

Corrigé depuis la v2.1.116

Les trois causes sont résolues. Anthropic a réinitialisé les limites d'utilisation de tous les abonnés le 23 avril, reconnaissant que le comportement de cache-miss du bug de cache avait vidé les limites plus vite que prévu.

Les engagements du post-mortem :

• Une plus grande part des équipes internes doit utiliser exactement le build public (fermeture de l'écart interne/public)
• Des suites d'évaluations par modèle plus larges couvrant chaque modification du prompt système
• Des ablations de prompt mesurant l'impact ligne par ligne avant déploiement
• De nouveaux outils pour auditer les changements de prompts
• Les changements spécifiques à un modèle limités au modèle cible prévu
• Des périodes de soak et des déploiements progressifs pour tout changement qui échange de l'intelligence contre une autre métrique
• Lancement de @ClaudeDevs sur X comme canal de transparence pour la communication continue avec les développeurs

Le post-mortem est public sur anthropic.com/engineering/april-23-postmortem. La GitHub issue AMD est la #42796 dans le dépôt anthropic/claude-code. Les deux valent la peine d'être lus ensemble : le compte rendu officiel couvre ce qui s'est passé et les changements prévus ; les données de la communauté montrent ce que ça ressemblait de l'extérieur.

Pages liées

• Claude Sonnet 4.6 pour les spécifications actuelles du modèle intermédiaire recommandé
• Claude Opus 4.7 pour le modèle phare actuel
• Tous les modèles Claude pour la chronologie complète des modèles
• Guide de sélection des modèles pour choisir entre Sonnet et Opus dans les workflows d'agents