Claude Opus 4.6 : 6 852 sessions analysées, un ratio lecture/édition divisé par 3, et une confiance en miettes
Alexandre
··
Durée de lecture : 11 min
6 852 fichiers de session. 234 760 appels d'outils. 17 871 blocs de thinking. Et un ratio de lecture avant édition (le fameux read-before-edit, le nombre de fichiers que l'agent lit avant de modifier du code) qui passe de 6,6 à 2,0 entre fin janvier et début avril 2026. Ces chiffres viennent d'un utilisateur avancé de Claude Code, pas d'un audit officiel d'Anthropic. Ils ont suffi à faire exploser un thread Hacker News à plus de 1 300 points.
Le 5 février 2026, Anthropic présentait Claude Opus 4.6 comme son modèle le plus solide pour les gros codebases, les tâches agentiques longues et le contexte à 1 million de tokens. Deux mois plus tard, les issues GitHub, les tweets et les discussions HN racontaient tous la même chose : il allait plus vite au mauvais endroit, lisait moins avant d'éditer, et donnait l'impression de finir une tâche avant de l'avoir comprise.
Décryptage.
Pourquoi le procès en dégradation a explosé d'un coup
Entre fin février et début avril 2026, la plainte contre Claude Opus 4.6 a émergé simultanément sur GitHub, Hacker News, X et des pipelines automatisés en production. Quand les mêmes symptômes (moins de lecture, plus de raccourcis, analyses confiantes mais fausses) apparaissent partout en parallèle, ce n'est plus du bruit de timeline.
Le premier signal vraiment sale, c'est l'issue #30027, ouverte le 2 mars. L'auteur y décrit plus de 50 sessions Claude Code sur 15 jours avec le même pattern : des analyses techniques très confiantes, pas vérifiées, puis correction seulement quand l'humain conteste. L'issue ne parle pas d'un bug unique. Elle parle d'un comportement qui use.
Quatre jours plus tard, l'issue #31480 décrit un pipeline de prod qui tournait depuis deux semaines avec claude-opus-4-6 et qui s'est mis à ignorer des règles critiques, des fichiers de style et des contraintes de schéma, sans changement côté prompts ni infra. Là c'est plus du ressenti, c'est du travail cassé.
Puis l'issue #42796, ouverte le 2 avril, finit propulsée sur Hacker News. Plus de 1 300 points, plus de 700 commentaires. C'est pas une preuve scientifique, mais ça dit vraiment quelque chose quand autant de devs viennent raconter les mêmes galères : Claude qui saute des étapes, qui appelle des fixes "simples" qui sont faux, ou qui boucle sur des corrections qu'il a lui-même créées.
Cliquer pour agrandir
Sur X, même tonalité. Dave Kennedy écrit qu'il a senti le problème quatre semaines plus tôt, que ça s'est aggravé progressivement, et qu'il a coupé son abonnement Claude pour repartir sur Cursor, Codex et Kimi. Jerónimo Palacios raconte un cas très concret : Opus 4.6 avait des problèmes de types et s'est contenté de remplacer des appels par type: any. Le genre de rustine qui te fait gagner dix minutes sur le moment et perdre une matinée le lendemain.
Quand plusieurs devs décrivent la même paresse structurelle sur des projets différents, c'est pas du théâtre. C'est un vrai signal.
Les chiffres qui ont fait sortir le sujet de la zone grise
Le débat a changé de dimension quand des métriques concrètes ont commencé à circuler : volume de sessions, profondeur de thinking, ratio lecture avant édition, interruptions utilisateur. Pas un papier académique, mais suffisamment précis pour obliger Anthropic à répondre autrement qu'avec un simple "vous tenez mal l'outil".
Le document le plus cité reste l'analyse attachée à l'issue #42796. Son auteur dit avoir analysé 6 852 fichiers de session, 234 760 appels d'outils et 17 871 blocs de thinking entre le 30 janvier et le 1er avril. Les chiffres qui ont marqué tout le monde sont simples : une profondeur médiane de thinking qui tomberait d'environ 2 200 caractères à 560-600, un ratio lecture avant édition qui passe de 6,6 à 2,0, et 173 violations d'un stop hook en 17 jours après le 8 mars, contre zéro avant.
Ces chiffres ne viennent pas d'un audit public d'Anthropic. Ce sont des données d'un utilisateur avancé, pas la vérité absolue. Mais ils collent avec les symptômes racontés partout ailleurs. Du coup, même imparfaits, ils sont utiles.
Le ratio read-before-edit est hyper parlant. Un agent qui lit six fichiers avant d'éditer, ça ressemble à un collègue prudent. Un agent qui en lit deux avant de réécrire ton code, ça ressemble à un stagiaire pressé. Ce truc-là, tu ne le vois pas dans un benchmark propre. Tu le vois dans tes diffs Git à 23h40.
Le tweet de Hesamation a bien marché parce qu'il condense exactement ça. Pas une grande théorie. Juste des points de friction mesurables : moins de thinking, plus de retries, moins de lecture, plus de contradictions, et une qualité pire aux heures où la charge GPU serait la plus forte. Pour un sujet aussi mouvant, c'était suffisant pour sortir du flou.
Je me méfie toujours des analyses faites après coup sur des logs maison. Mais c'est comme ça que les power users détectent une régression avant tout le monde. Ils la sentent, ils vont fouiller, et parfois ils ont raison avant le fournisseur. C'est ce genre de veille que je capture dans Waku, mon PKM visuel iOS : l'info au moment où elle circule, pas trois semaines après quand tout le monde a déjà tranché.
Ce qu'Anthropic a reconnu (et ce qu'Anthropic a laissé dans le brouillard)
Anthropic n'a jamais publié de billet disant "oui, Opus 4.6 a été nerfé". Mais l'équipe a reconnu plusieurs changements de comportement produit qui expliquent une partie du choc utilisateur : rédaction du thinking visible, effort par défaut abaissé à medium, et cas où l'adaptive thinking (le mécanisme qui laisse le modèle décider combien de tokens il consacre au raisonnement) sous-alloue effectivement la réflexion.
Dans le commentaire épinglé de l'issue #42796 puis sur Hacker News, Boris Cherny de l'équipe Claude Code explique deux choses. Premièrement, le flag redact-thinking-2026-02-12 masque le thinking dans l'UI, mais ne le réduit pas en soi. Deuxièmement, le 3 mars 2026, Anthropic a changé le niveau d'effort par défaut pour Opus 4.6 vers medium effort (85), avec l'idée de réduire latence et coût pour la majorité des utilisateurs.
Dit autrement : une partie des gens a vécu un vrai "Claude est devenu moins profond" parce que, littéralement, le réglage par défaut le faisait raisonner moins longtemps. Ce n'est pas une conspiration. C'est un arbitrage produit. Et c'est là que le problème devient sérieux : quand tu touches à la profondeur de raisonnement d'un outil que des devs paient pour du travail complexe, tu dois sur-communiquer, pas glisser ça au milieu du produit sans prévenir.
Cliquer pour agrandir
La documentation settings de Claude Code confirme plusieurs points utiles. showThinkingSummaries change ce que tu vois, pas ce que le modèle génère. effortLevel existe, accepte low, medium, high, xhigh (ajouté avec Opus 4.7) et max (Opus 4.6 uniquement), et persiste entre les sessions. Quand tu connais le sujet, c'est logique. Quand tu le découvres après une mauvaise semaine à te demander pourquoi Claude bâcle tout, c'est vraiment la galère.
Cliquer pour agrandir
Capture du thread de Jaime Medina, l'un des meilleurs résumés publics sur effortLevel, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING et MAX_THINKING_TOKENS.
Le passage le plus révélateur est venu dans le thread HN. Après avoir lu plusieurs feedback IDs, Boris Cherny dit que certains tours envoyés avec effort=high montraient quand même une sous-allocation de raisonnement par l'adaptive thinking, avec zéro reasoning émis sur les tours qui fabriquaient des choses. S'il y a des tours où le système décide de moins réfléchir et que ce sont justement ceux où il hallucine, le problème n'est plus psychologique. C'est un vrai défaut d'allocation.
Pendant que tout ça se passait, Anthropic publiait Project Glasswing avec des benchmarks où Mythos Preview dépassait largement Opus 4.6, par exemple 77,8 % contre 53,4 % sur SWE-bench Pro (le benchmark de référence pour le coding agentique, mesurant la capacité d'un modèle à résoudre des bugs réels sur des repos open-source) et 82,0 % contre 65,4 % sur Terminal-Bench 2.0. En gros, Anthropic dit "on sait que 4.6 galère, mais regardez ce qu'on a en interne". Sauf que quand tu paies ton outil au prix fort et que le truc meilleur est inaccessible, ça ne rassure pas vraiment.
L'imprévisibilité coûte plus cher qu'une vraie baisse de QI
Quand tu bosses seul, le vrai coût d'une régression ce n'est pas la qualité moyenne. C'est l'imprévisibilité. Un outil un peu moins bon mais stable, tu t'adaptes. Un outil qui est excellent le lundi et approximatif le mardi sans raison claire, ça te ruine le rythme.
Je le vis sur Waku avec Claude Code. Mon usage n'a rien de folklorique. Gros CLAUDE.md, conventions de projet, étapes de review, tests, aller-retour entre frontend, backend et logique produit. Dans ce genre d'environnement, tu n'as pas besoin d'un agent "créatif". Tu as besoin d'un truc méthodique, presque ennuyeux, qui lit avant de toucher et qui ne te vend pas un raccourci quand il n'a pas compris la contrainte.
Le vrai danger n'est pas le petit bug de plus. C'est le moment où tu commences à relire chaque sortie avec une méfiance permanente. Parce que là, le gain de vitesse s'évapore. Si tu dois vérifier que la logique métier n'a pas été subtilement tordue, que le type: any n'est pas revenu par la fenêtre, que le modèle n'a pas contourné ton instruction en racontant une histoire plausible, tu reviens à une forme de supervision lourde. Et la supervision lourde, quand tu es seul, c'est brutal.
J'en parlais déjà dans mon retour sur l'architecture des agents de code : un agent autonome ne vaut quelque chose que si tu peux lui faire confiance sur la durée. Sinon tu passes ton temps à reviewer au lieu de produire. Du coup, davantage de commits intermédiaires, plus de garde-fous, moins de confiance dans les séances longues. Pour un outil vendu comme le copilote qui tient les tâches longues, c'est quand même un sacré problème.
La concurrence n'a même pas besoin d'être meilleure partout
La séquence Opus 4.6 donne un cadeau à Cursor, OpenAI et tous les challengers : ils n'ont pas besoin de prouver qu'ils dominent Opus 4.6 sur tous les benchmarks. Ils ont seulement besoin d'apparaître comme des options plus stables, ou au moins plus transparentes, au moment où la confiance vacille.
Dave Kennedy résume bien le risque pour Anthropic. En substance : Opus 4.6 était magique au lancement, puis inutilisable, donc il est parti ailleurs. Quand un utilisateur intensif quitte un produit non pas pour une révolution concurrente, mais parce qu'il n'a plus envie de négocier avec l'humeur du modèle, c'est un problème de rétention, pas de feature.
OpenAI comprend très bien ce moment. Leur nouveau palier à 100 dollars et la montée en puissance de Codex arrivent dans un contexte parfait. Cursor aussi. Même si Claude Code reste vraiment bon quand il est dans un bon jour, la concurrence profite du moindre doute. Les parts de marché se grignotent par lassitude, pas par démonstration éclatante.
Pour Waku et Koda, je ne vais pas changer d'outil principal tous les trois jours. Ce serait idiot. Mais je regarde le marché autrement qu'il y a deux mois. Avant, j'évaluais surtout la puissance brute. Maintenant, j'ajoute une question : est-ce que je comprends pourquoi le modèle a bien ou mal travaillé aujourd'hui ? Si la réponse est non, j'ai un problème de dépendance fournisseur. C'est le sujet que je creuse le plus en ce moment, et j'en parle en détail dans mon workflow avec Claude Code.
La vitesse à laquelle la perception se retourne est dingue. En février, Anthropic vendait une machine capable de mieux planifier, de mieux tenir les grandes bases de code et de mieux se corriger. En avril, les devs discutent de effortLevel, de budgets de thinking et de workaround pour retrouver l'ancien comportement.
Ce qu'Anthropic devrait faire (et ce qu'ils ont commencé à faire depuis)
Anthropic peut reprendre la main, mais pas avec trois commentaires dispersés et une doc que seuls les utilisateurs obsessionnels finissent par lire. Il faut du versioning clair, des métriques visibles, et une comm directe quand un réglage change l'expérience.
La première chose, des snapshots de modèle utilisables en prod. Si une équipe a construit un pipeline autour d'un comportement donné, elle doit pouvoir le pinner. L'issue #31480 le demande explicitement. On ne peut pas vendre l'automatisation sérieuse et en même temps changer le modèle en douce.
La deuxième, rendre l'effort visible tout le temps. Pas dans un coin, pas après un callout. Si l'agent tourne en medium, tu dois le savoir direct. Si un subagent est sur un autre niveau, pareil. Ça évite des heures de faux diagnostics.
La troisième, des métriques simples de raisonnement. Pas besoin de montrer toute la chaîne de pensée. Mais des compteurs honnêtes : budget utilisé, effort effectif, tours où l'adaptive thinking s'est fortement contracté. Quand tu caches tout, tu crées exactement le vide que les tweets viraux viennent remplir à ta place.
Enfin, parler comme à des adultes. Dire : "on a baissé le défaut pour un meilleur compromis latence/coût". Dire : "on observe des tours où l'allocation se rate". Dire : "voici le correctif, voici la date, voici l'impact attendu". C'est sec, mais ça répare.
Depuis la publication originale de cet article, Anthropic a sorti Opus 4.7 le 16 avril 2026 avec le niveau d'effort xhigh, une auto-vérification des sorties et une meilleure cohérence sur le long contexte. Puis Opus 4.8, avec un adaptive thinking refondu qui remplace définitivement le vieux budget_tokens. Le problème n'a pas disparu, mais la trajectoire va dans le bon sens. L'enjeu reste le même : il ne suffit pas de livrer un meilleur modèle, il faut prévenir les gens quand le modèle qu'ils utilisent change de comportement.
Les 3 trucs à retenir
1. La confiance compte plus que la puissance
Un agent brillant mais inconstant, ça coûte plus cher qu'un agent juste correct. Quand tu dois vérifier chaque sortie, le gain de productivité s'annule. Le read-before-edit qui passe de 6,6 à 2,0, en gros c'est la différence entre un collègue prudent et un stagiaire pressé.
2. L'effort level doit faire partie de ton workflow
Pas un truc qu'on découvre après une mauvaise semaine. effortLevel dans CLAUDE.md, vérifié en début de session, adapté au type de tâche. J'ai détaillé ça dans mon guide pour diviser la conso de tokens par 2.
3. Il faut un plan B
Pas par manque de loyauté. Par pragmatisme. Quand un fournisseur peut changer le comportement de ton outil sans te prévenir, garder un deuxième modèle sous la main c'est juste du bon sens.
Conclusion
Claude Opus 4.6 s'est-il vraiment dégradé ? Oui. Il y a eu une dégradation perçue massive, et elle ne sort pas de nulle part. Une partie vient de changements de réglages par défaut. Une autre vient de vrais cas de sous-allocation du raisonnement. Et le reste vient d'un truc plus simple : Anthropic a laissé ses utilisateurs découvrir seuls que leur outil ne se comportait plus pareil.
Claude n'est pas "fini". Mais un agent de code, c'est plus un gadget. C'est un outil sur lequel des devs construisent tous les jours. Quand tu touches au raisonnement sans prévenir, tu touches au rythme de travail de gens qui comptent dessus.
Je continue à utiliser Claude Code. Mais avec moins de foi, plus de vérifications, et une attention beaucoup plus forte à la concurrence. Et toi, est-ce que tu as senti un vrai décrochage sur Opus 4.6, ou juste un changement de réglage qui a fait beaucoup de bruit ? Envoie-moi un message sur X ou en commentaire.
Alex
À retenir
Le débat sur la dégradation d'Opus 4.6 n'est pas né d'un benchmark viral, mais d'issues GitHub, de pipelines cassés et de retours terrain concordants sur plusieurs plateformes.
L'analyse la plus citée parle de 6 852 sessions, 234 760 appels d'outils et d'un read-before-edit qui tombe de 6,6 à 2,0. Pas une preuve absolue, mais trop précis pour être balayé.
Anthropic a reconnu un changement de niveau d'effort par défaut début mars et des cas où l'adaptive thinking sous-allouait le raisonnement. Le problème n'est pas imaginaire.
Un agent brillant mais inconstant coûte parfois plus cher qu'un agent juste correct. La prévisibilité, c'est ce sur quoi repose le travail en solo.
Anthropic peut reprendre la main avec des snapshots de modèle, un effort visible en permanence, des métriques de raisonnement et une communication nette quand l'expérience change.
