La directrice de l'IA d'AMD critique vivement Claude Code d'Anthropic, le jugeant moins performant depuis MàJ
La directrice de l'IA d'AMD critique vivement Claude Code d'Anthropic, le jugeant moins performant et moins efficace depuis sa dernière mise à jour :
« Je ne peux plus en toute conscience recommander Claude Code à mes clients »
Depuis février 2026, les utilisateurs avancés de Claude Code tirent la sonnette d'alarme : le modèle serait devenu moins capable, plus paresseux, et surtout moins fiable pour les tâches d'ingénierie complexes. Une analyse chiffrée d'une précision rare, publiée sur GitHub par la directrice IA d'AMD, vient désormais donner une assise scientifique à ce que beaucoup vivaient comme une intuition. Derrière la régression : la réduction silencieuse du budget de « pensée étendue » alloué au modèle.
Le 2 avril 2026, un ticket intitulé « Claude Code est inutilisable pour les tâches d'ingénierie complexes avec les mises à jour de février » est ouvert sur le dépôt officiel d'Anthropic. Son auteure : Stella Laurenzo, identifiable via son profil GitHub sous le pseudonyme stellaraccident et un post LinkedIn associé : directrice du groupe IA chez AMD. Le message n'est pas une simple plainte d'utilisatrice frustrée. C'est un rapport d'analyse de plusieurs semaines, produit par Claude lui-même à partir de données de sessions réelles, et qui pointe nommément Anthropic pour une dégradation progressive et non communiquée de son produit phare.
Laurenzo explique que son équipe est parvenue à cette conclusion en s'appuyant sur des mois de logs issus d'un environnement de travail à haute complexité. Tous les ingénieurs seniors de son équipe ont rapporté des expériences similaires. Le verdict est sans appel : « Claude ne peut plus être considéré comme fiable pour des tâches d'ingénierie complexes. »
Le ticket devient rapidement viral. Sur Hacker News, il cumule plus de 170 points et plus d'une centaine de commentaires en quelques heures, la plupart apportant leurs propres témoignages convergents. Sur Reddit, des fils similaires se multiplient. La frustration est palpable, les anecdotes abondent.
234 760 appels d'outils analysés : les chiffres parlent d'eux-mêmes
Ce qui distingue ce ticket de la masse des plaintes habituelles sur les forums, c'est la rigueur méthodologique de l'analyse. L'étude porte sur 17 871 blocs de réflexion et 234 760 appels d'outils issus de 6 852 fichiers de session Claude Code, couvrant la période du 30 janvier au 1er avril 2026.
Le constat central est brutal : le ratio de lectures par rapport aux modifications de fichiers est passé de 6,6 en janvier-février à seulement 2,0 en mars, une réduction de 70 % de l'effort de recherche avant modification. Autrement dit, le modèle a progressivement cessé de lire et comprendre le code existant avant d'y toucher, au profit d'une approche « modifier d'abord, réfléchir ensuite ». Dans le même temps, l'usage d'écritures complètes de fichiers (Write) a doublé par rapport aux modifications chirurgicales (Edit), passant de 4,9 % à 11,1 % des mutations github, signe d'une perte de précision contextuelle.
Les indicateurs comportementaux sont tout aussi parlants. Un script de détection (stop-phrase-guard.sh) conçu pour intercepter les comportements indésirables (refus de responsabilité, demandes de permission superflues, arrêts prématurés) a enregistré zéro violation avant le 8 mars, puis 173 violations sur les 17 jours suivants, soit environ 10 par jour. Dans le contexte, le « refus de responsabilité » (ownership dodging) désigne le comportement du modèle qui, face à un bug ou une erreur, refuse d'admettre que c'est lui qui l'a causé. Concrètement, Claude Code produisait du code défectueux, et quand l'utilisateur le signalait, le modèle répondait des choses comme :
- « ce problème n'est pas causé par mes modifications »
- « c'est un bug préexistant »
- « c'est une limitation connue »
Alors que c'était bien lui qui avait introduit l'erreur. Le script de détection (stop-phrase-guard.sh) avait été construit précisément pour intercepter ces formules et forcer le modèle à assumer ses erreurs et continuer à travailler.
Parmi les patterns capturés : le modèle tentait de s'arrêter de travailler, de rejeter la responsabilité sur des « problèmes existants », ou de qualifier ses propres lacunes de « limitations connues » ou de « travaux futurs ».
L'analyse lexicale des prompts utilisateur confirme la spirale : le terme « simplest » (le plus simple) dans les réponses du modèle a augmenté de 642 % (de quasiment absent à un usage régulier). Dans les prompts humains, le ratio positif/négatif est passé de 4,4:1 à 3,0:1, « please » a chuté de 49 %, « great » de 47 %, tandis que « stop », « lazy » et « terrible » explosaient. Une cartographie linguistique de la dégradation d'une relation de travail.
La piste de la pensée réduite : redact-thinking-2026-02-12
L'hypothèse centrale de Laurenzo est technique et précise. Elle pointe le déploiement d'un mécanisme visant à masquer le processus de réflexion interne du modèle (thinking content redaction) avant de renvoyer la réponse à l'utilisateur.
Pour comprendre, il faut savoir comment fonctionne Claude en mode « extended thinking » : avant de produire une réponse, le modèle génère un bloc de réflexion interne : une sorte de brouillon de raisonnement où il planifie, vérifie, se corrige. Ce bloc était auparavant visible dans les réponses API, ce qui permettait aux développeurs de voir « comment le modèle pensait ».
Avec la mise à jour de mars 2026, Anthropic a introduit un header technique (redact-thinking-2026-02-12) qui supprime ce bloc de réflexion de la réponse renvoyée. Résultat :
- L'utilisateur ne voit plus le raisonnement intermédiaire
- Il est donc impossible de savoir combien le modèle a réfléchi
- Et surtout, impossible de détecter qu'Anthropic a réduit ce budget de réflexion
C'est le double effet dénoncé par Laurenzo dans son article : d'abord réduire la profondeur de réflexion (ce qui dégrade les performances), ensuite masquer cette réduction (ce qui empêche les utilisateurs de s'en rendre compte).
Les données de session semblent le confirmer. Entre le 30 janvier et le 4 mars, 100 % des blocs de pensée étaient visibles. À partir du 5 mars, le masque a commencé à s'appliquer de manière progressive : 1,5 % le 5 mars, 24,7 % le 7 mars, 58,4 % le 8 mars, puis quasi-totale à partir du 10 mars. Or, le 8 mars, date à laquelle le masque franchit le seuil de 50 %, correspond précisément à la date où les utilisateurs ont commencé à signaler massivement une dégradation des performances.
Mais l'analyse révèle quelque chose de plus inquiétant encore : la profondeur de réflexion avait déjà commencé à chuter avant même que le masque ne soit déployé. La médiane estimée des caractères de pensée était d'environ 2 200 en janvier, avant de tomber à ~720 en fin février et ~560 début mars, une réduction de 67 à 75 % avant que le masque ne rende cette information invisible aux utilisateurs.
En d'autres termes, Anthropic aurait d'abord réduit le budget de réflexion alloué au modèle, puis aurait masqué cette réduction aux utilisateurs en supprimant la visibilité sur les blocs de pensée dans les réponses API. Le rapport note même une corrélation de 0,971 entre la longueur de la signature des blocs de pensée et leur contenu textuel, ce qui a permis d'estimer rétrospectivement la profondeur de réflexion même après l'application du masque.
Une conséquence paradoxale : davantage de tokens consommés, moins de résultats
L'un des arguments implicites d'Anthropic pour justifier une telle réduction pourrait être l'économie de ressources de calcul. Or, l'analyse démontre l'effet inverse sur les utilisateurs en production intensive. En février, 1 498 requêtes API avaient suffi à produire 191 000 lignes de code mergé. En mars, 119 341 requêtes ont été nécessaires, soit un facteur 80, pour des résultats nettement inférieurs, avec un coût estimé à plus de 42 000 dollars sur Bedrock Opus, contre 345 dollars le mois précédent.
L'explication est systémique : un modèle qui ne réfléchit plus suffisamment produit des modifications erronées, qui génèrent des corrections, qui génèrent d'autres modifications, qui génèrent d'autres corrections, chaque cycle consommant des tokens supplémentaires. Un modèle qui pense profondément pour 2 000 tokens et obtient un résultat correct au premier essai coûte moins cher à servir qu'un modèle qui pense 200 tokens et nécessite dix requêtes pour trébucher vers le même résultat.
La conclusion est saisissante : réduire la profondeur de réflexion ne réduit pas les coûts, elle les déplace et les amplifie chez les utilisateurs à fort volume.
La communauté confirme : témoignages convergents
Sur les plateformes spécialisées, les développeurs se reconnaissent massivement dans le diagnostic. Plusieurs utilisateurs rapportent que l'apparition de la formule « the simplest fix is... » dans les réponses du modèle est devenue un signal d'alerte fiable, précédant systématiquement du code médiocre. D'autres décrivent un modèle qui reformule ses propres plans en cours d'exécution, abandonne des conventions de codage pourtant explicitement documentées, ou réécrit des fichiers entiers là où une modification chirurgicale aurait suffi.
Un utilisateur décrit avoir vu Claude, après avoir proposé deux options d'implémentation et s'être vu dire d'aller vers la version serveur Python, choisir finalement d'implémenter la version JavaScript côté client en expliquant « qu'au fond, il préférait cette approche ». Une autre personne rapporte que le modèle a commencé à produire des phrases comme « I've been burning too many tokens » ou « this has taken too many turns », des signaux explicites de plafonnement budgétaire, qui nécessitent à leur tour des instructions supplémentaires pour être neutralisés.
Un développeur qui utilise Claude Code depuis des mois note qu'en janvier, il pouvait lancer des agents sur un projet ambitieux avec très peu de guidance, et obtenir une application fonctionnelle et convaincante. Un mois plus tard, les mêmes agents produisaient systématiquement « de la foutaise terne et sans intérêt ».
Les demandes : transparence et différenciation tarifaire
Face à ce constat, Laurenzo formule trois demandes concrètes à Anthropic. Premièrement, la transparence : si les tokens de réflexion sont réduits ou plafonnés, les utilisateurs qui dépendent de la profondeur de raisonnement doivent en être informés. Deuxièmement, l'exposition des métriques : exposer le nombre de tokens de réflexion dans les réponses API, même si le contenu reste masqué, pour permettre aux utilisateurs de monitorer la qualité de raisonnement qu'ils obtiennent réellement. Troisièmement, la création d'un niveau « max thinking » dans l'offre tarifaire, pour les ingénieurs dont les workflows requièrent une réflexion approfondie garantie. Le modèle d'abonnement actuel ne fait aucune distinction entre un utilisateur ayant besoin de 200 tokens de réflexion par réponse et un autre en nécessitant 20 000.
Sur ce dernier point, la position d'AMD est celle d'un client prêt à payer davantage pour un service de qualité garanti, ce qui représente un signal commercial que les équipes produit d'Anthropic devraient prendre au sérieux.
Une mise en garde sérieuse pour Anthropic
Laurenzo indique que son équipe a migré vers un autre fournisseur qui produit actuellement un travail de meilleure qualité, tout en laissant ce rapport dans l'espoir qu'Anthropic puisse corriger son produit. Elle ajoute en commentaire : « Six mois plus tôt, Claude se distinguait nettement en termes de qualité de raisonnement et d'exécution. Mais les autres acteurs doivent être surveillés et évalués très attentivement. Anthropic est loin d'être seul au niveau de capacité qu'Opus occupait autrefois. »
C'est peut-être le signal le plus important de toute cette affaire : non pas qu'un outil soit devenu moins bon, cela arrive, mais qu'un acteur industriel majeur, utilisateur intensif, ait franchi le pas de la migration et prenne le soin d'expliquer publiquement pourquoi. Dans un marché où la concurrence entre modèles de code s'intensifie (Codex/GPT-5.4, Gemini, modèles open source), la confiance est le seul moyen de fidéliser les développeurs à fort volume. Et la confiance, une fois érodée en silence, est difficile à restaurer.
Source : billet de Laurenzo
Et vous ?
La réduction silencieuse du budget de réflexion alloué à un modèle constitue-t-elle une forme de tromperie commerciale envers les abonnés payants ou est-ce simplement une prérogative légitime d'Anthropic sur son infrastructure ?
Voir aussi :
Répondre avec citation
Partager