IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 recommander Claude Code à mes clients »

Le , par Stéphane le calme

26PARTAGES

9  0 
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 :...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 08/04/2026 à 21:45
Et oui ma bonne dame, "devenir de moins en moins efficace" est en réalité la destiné de tous les modèles d'IA à terme.

Et pourquoi?

Parce qu'après s'être "nourri" de toutes les données d'origine humaine à leur disposition, les IA finissent par "apprendre" à partir de données elles-mêmes fabriquées par des IA... Et la c'est le syndrome de la photocopie que l'on photocopie... A chaque nouvelle opération, la photocopie obtenue est de moins bonne qualité que celle qui a servi de modèle
0  0