Au cours du dernier mois, certains utilisateurs ont continué à signaler une baisse de la qualité des réponses de Claude. Après enquête, Anthropic a confirmé que trois changements distincts affectant Claude Code, le Claude Agent SDK et Claude Cowork en étaient la cause. L’API elle-même n’a pas été touchée, et l’entreprise a indiqué que tous les problèmes avaient été résolus au 20 avril 2026 (v2.1.116). Ce post-mortem présente l’origine des problèmes, les correctifs apportés et les mesures prises pour éviter qu’ils ne se reproduisent.
Les trois causes de l’incident et leur chronologie
- Abaissement de la valeur par défaut de l’effort de raisonnement (
reasoning effort) (4 mars) : la valeur par défaut de l’effort de raisonnement de Claude Code a été modifiée dehighàmedium. Cette mesure visait à réduire des temps d’attente si longs que l’interface semblait parfois figée, mais les utilisateurs ont perçu une dégradation de la qualité des réponses. Le changement a finalement été annulé le 7 avril. Actuellement, la valeur par défaut estxhighpour Opus 4.7 ethighpour les autres modèles. - Suppression de l’historique de raisonnement à cause d’un bug d’optimisation du cache (26 mars) : lors de la reprise d’une session restée inactive plus d’une heure, une fonctionnalité conçue pour nettoyer une seule fois l’historique de raisonnement antérieur (
thinking) l’a, à cause d’un bug, supprimé de manière répétée à chaque tour de conversation suivant. Claude ne parvenait alors plus à se souvenir des raisons de certaines actions, ce qui a provoqué chez les utilisateurs les symptômes de « trou de mémoire », de réponses répétitives et de choix d’outils anormaux. Descache missrépétés ont aussi eu pour effet secondaire d’épuiser les quotas d’utilisation plus vite que prévu. Le problème a été corrigé le 10 avril. - Instruction de concision excessive dans le system prompt (16 avril) : pour réduire les sorties verbeuses d’Opus 4.7, Anthropic a ajouté au system prompt l’instruction « entre les appels d’outils, le texte doit rester dans la limite de 25 mots, et la réponse finale dans la limite de 100 mots ». Aucun problème n’avait été détecté dans les tests internes, mais il a été confirmé que cela nuisait à la qualité réelle du code produit ; l’instruction a donc été retirée le 20 avril.
Pourquoi le problème a été détecté tardivement
- Les trois changements ont été déployés à des moments différents et sur des périmètres de trafic différents, donnant l’impression d’une baisse de qualité globale mais incohérente, ce qui a compliqué l’identification des causes individuelles.
- Il existait des écarts entre l’environnement de test interne et l’environnement réel des utilisateurs. Dans le cas du bug de cache, une expérience distincte alors en cours en interne ainsi que des différences d’affichage dans l’interface ont rendu la reproduction du problème difficile.
- La suite d’évaluation existante (
eval suite) n’était pas suffisamment large. Ce n’est qu’après avoir exécuté des évaluations plus variées qu’une baisse de performance de 3 % liée à la modification du system prompt a été mise en évidence.
Mesures pour éviter une récidive
- Obliger les employés en interne à utiliser les builds publics, afin de réduire l’écart avec les builds de test internes.
- Renforcer le contrôle des modifications du system prompt. Pour chaque changement, Anthropic effectuera de larges évaluations par modèle, analysera individuellement l’impact de chaque ligne (
ablation) et mettra en place un déploiement progressif accompagné d’une période de validation suffisante (soak period). - Améliorer les outils de code review. Constatant que le bug de cache avait pu être identifié lorsque l’intégralité du dépôt de code concerné avait été fournie comme contexte à Opus 4.7, l’entreprise va élargir la portée des dépôts consultables lors des revues de code.
- Ouvrir un canal de communication avec les utilisateurs (@ClaudeDevs) afin de partager de manière transparente le contexte des décisions produit.
À propos de l’affirmation « il n’y a pas eu de dégradation intentionnelle de la qualité »
- Anthropic affirme n’avoir jamais volontairement dégradé le modèle et confirme que l’API et la couche d’inférence (
inference layer) n’ont pas été affectées. En revanche, il est vrai que des changements de configuration et des bugs au niveau de la couche produit (Claude Code) ont conjointement dégradé la qualité perçue par les utilisateurs. L’entreprise a également annoncé une réinitialisation des quotas d’utilisation pour tous les abonnés.
13 commentaires
Comment se fait-il que les trois causes de la panne soient toutes directement liées à la réduction des coûts, lol ?
On dirait qu’ils sont vraiment en grosse pénurie de ressources GPU, au point de dégrader les performances.....
C’est la bonne réponse, mais les excuses sont un peu longues lol
Ils ont écrit un long texte pour dire qu’ils ont déployé une build publique sans même la tester, et qu’ils n’ont pas testé non plus après le déploiement. J’ai moi-même rencontré le bug dès le 26 mars, alors est-ce qu’ils trouvent vraiment normal qu’il faille trois semaines en interne rien que pour le confirmer…
Dès que le correctif a été déployé, le quota de 5 heures, qui tenait auparavant 3 à 4 heures d’utilisation, a commencé à être épuisé en seulement 30 minutes. Mais comme les comptes employés n’avaient pas de quota de 5 heures, ou du moins n’étaient pas assez limités pour obliger à surveiller
/usageen permanence pendant le travail, j’imagine que cela a pris un bon moment avant d’être repéré.Sur le benchmark quotidien SWE-Bench-Pro (jeu de données curé), il y a quelque chose d’intéressant quand on regarde claude code
Sur la période du 10/04 au 20/04, le runtime a été divisé par deux (653s→345s), les tool calls aussi (3.3K→1.8K), les tokens ont baissé de 18 %, alors que le pass rate a au contraire progressé de +16 points. Voir ces quatre indicateurs évoluer tous en même temps dans le bon sens, ce n’est pas un schéma courant
Les trois incidents survenus pendant ce processus correspondent au postmortem du 23/04, et quand on regarde, ils ont tous été causés par des tentatives de réduction des tokens et de la latence
À l’inverse, codex (gpt-5.4-xhigh) a très peu bougé sur la même période. Le pass rate reste pratiquement figé autour de 56 %, et les tokens/runtime/tool calls restent à peu près au double du niveau de claude code
N’est-ce pas plutôt un post-mortem de réduction des coûts qu’un post-mortem d’incident ?
En obligeant les employés en interne à utiliser les véritables builds publics, ils réduisent l'écart avec les builds destinés aux tests internes.
mdrrrr
On dirait qu’on a appris YAGNI à Opus 4.7. À chaque fois, il justifiait ses décisions d’architecture en invoquant YAGNI et des modifications progressives, donc je me disais que c’était sans doute pour ça, mais au final, ça a fini par provoquer un incident. Avec une mémoire qui n’est déjà pas très longue, le voir prendre l’habitude de remettre les choses à plus tard, c’est vraiment inquiétant.
Suis-je le seul à penser qu’au début, ils insistaient en disant qu’il n’y avait aucun problème, puis que maintenant que l’affaire a pris trop d’ampleur pour être étouffée, ils la rendent publique ?
On a aussi l’impression que l’ergonomie de claude.ai s’est un peu dégradée par petites touches… J’ai même désactivé la mémoire pour économiser des tokens.
J’ai l’impression que cette annonce me fait encore moins confiance à Anthropic.
Il y a deux articles liés ci-dessus, et ces deux textes ont 7 mois d’écart. Les problèmes sont exactement les mêmes, au nombre de trois.
Post-mortem de trois récents problèmes de dégradation de la qualité de Claude 2025-09-19
Mise à jour concernant les récents signalements sur la qualité de Claude Code 2026-04-24
Je suis énervé à hauteur de 5 $ de crédits !!
Quelle langue bien pendue...