Pourquoi Claude devient "plus stupide" à mesure que vous l'utilisez : Le prix caché de "l'économie d'argent" est une facture API 100 fois plus élevée
Pourquoi Claude devient "plus stupide" à mesure que vous l'utilisez : Le prix caché de "l'économie d'argent" est une facture API 100 fois plus élevée
Il y a quelques jours, Stella Laurenzo, directrice IA chez AMD, a signalé un problème technique pointu dans le dépôt officiel de Claude Code : « Claude Code est inutilisable pour les tâches d'ingénierie complexes avec les mises à jour de février. » Ce n'était pas une simple plainte subjective. C'était une analyse post-mortem quantitative basée sur 6 852 sessions, 17 871 blocs de pensée et 234 760 appels d'outils recueillis dans des flux de travail réels. Vous pouvez consulter le rapport original ici : Problème GitHub #42796.
Si vous développez dans la crypto, cela devrait vous intéresser, car "l'ingénierie complexe" est pratiquement le paramètre par défaut du Web3 : les contrats intelligents sont immuables, les surfaces d'attaque sont composables, et une seule modification hallucinée peut devenir une vulnérabilité. Ce qui ressemble à un pépin du produit IA est, en pratique, un risque pour la chaîne d'approvisionnement logicielle — et un piège à coûts.
1) Les données inconfortables : qualité en baisse, coût en hausse (très en hausse)
Le rapport lie une régression de qualité visible à des changements de configuration côté serveur concernant la pensée étendue et la rédaction de pensée (notamment le déploiement étiqueté redact-thinking-2026-02-12). L'affirmation clé n'est pas seulement que les "sorties se sont dégradées", mais que le comportement du modèle est passé mesurablement de la recherche d'abord à l'édition d'abord — exactement la mauvaise direction pour l'ingénierie à haut risque.
Voici un aperçu simplifié basé sur les métriques du fil de discussion :
Source : la télémétrie originale et l'annexe des coûts dans le problème GitHub.
La leçon la plus pertinente pour la crypto est contre-intuitive : la restriction du raisonnement ne réduit pas toujours les dépenses. Dans les tâches de longue durée, un agent plus faible peut déclencher davantage de tentatives, de corrections et d'appels d'outils — augmentant votre facture de plus de 100 fois tout en offrant une fiabilité moindre.
2) Pourquoi cela touche plus durement les équipes blockchain que les équipes logicielles classiques
Les contrats intelligents ne tolèrent pas le "presque correct"
Dans le Web2, une régression peut être corrigée et redéployée. Dans le Web3, une mauvaise hypothèse peut être immortelle.
La documentation d'Ethereum elle-même est franche : le code déployé est difficile à modifier, et les pertes sont souvent irrécupérables — voir la documentation sur la sécurité des contrats intelligents d'Ethereum et les directives de sécurité générales.
Reliez cela maintenant à la télémétrie de Claude Code : moins de lectures de fichiers, des éditions plus hâtives, des arrêts plus prématurés. C'est exactement le schéma qui produit :
- des vérifications incomplètes (autorisation, protection contre les rejeux, séparation des domaines)
- des invariants brisés entre les modules
- la gestion des cas limites manquants autour des décimales de jetons, des frais sur transfert, des arrondis
- des appels externes non sécurisés ou des mises à jour d'état mal placées
Dans la DeFi et l'infrastructure on-chain, "presque correct" est souvent équivalent à exploitable.
Les tendances de complexité 2025-2026 amplifient le rayon d'explosion
Deux évolutions de l'industrie rendent l'histoire de la "régression de l'agent IA" plus dangereuse dans la crypto qu'il n'y paraît :
-
L'abstraction de compte et les comptes intelligents se généralisent, augmentant la quantité de logique critique pour la sécurité qui réside dans les contrats plutôt que dans les EOA (External Owned Accounts). Si votre produit touche à l'AA (Account Abstraction), commencez avec ERC-4337 et la documentation pratique de l'écosystème sur ERC-4337 Documentation.
-
Les escroqueries assistées par IA et l'ingénierie sociale sont en expansion. Chainalysis note que les escroqueries liées aux fournisseurs d'IA rapportent matériellement plus par opération en moyenne ; voir leur article sur les escroqueries dans le Rapport sur la criminalité dans la crypto 2026. Lorsque les utilisateurs finaux demandent de plus en plus à l'IA "Est-ce sûr de signer ?", la fiabilité du modèle devient une question de protection des consommateurs, pas seulement une préférence d'ingénierie.
3) Le véritable enseignement : les LLM sont désormais une dépendance de production — traitez-les comme telles
Les équipes crypto ont déjà appris (à leurs dépens) à versionner les dépendances critiques : versions de compilateurs, fournisseurs RPC, modules de garde, bibliothèques de signature. Les agents LLM appartiennent désormais à cette même catégorie.
Un playbook Web3 pratique :
A) Créez des "tests de régression LLM" comme vous créez des suites de tests de protocole
- Capturez des tâches représentatives : flux de mise à niveau de contrats, messagerie inter-chaînes, remplissages d'indexeurs, refactorisations de calcul de frais.
- Exécutez les mêmes invitations chaque semaine ; comparez les résultats.
- Bloquez les fusions avec des vérifications déterministes : tests unitaires, invariants, simulation et analyse statique.
Si vous déployez Solidity, la page de directives d'Ethereum mentionne explicitement des outils comme les flux d'analyse de type Slither / Echidna — commencez par Smart contract security guidelines.
B) Supprimez "l'acceptation automatique des modifications" des dépôts critiques
Le rapport de problème note des flux de travail où les modifications ont été acceptées automatiquement. C'est un gain de productivité, jusqu'à ce qu'un agent passe silencieusement de prudent à imprudent.
Pour les contrats intelligents, traitez l'IA comme un contributeur junior :
- exigez une revue de code humaine
- exigez la réussite des tests et de la simulation locale
- exigez une approbation explicite pour les changements de permission, les nouveaux appels externes ou les changements de disposition de stockage
C) Fixez un plafond strict pour le gaspillage (le contrôle des coûts est un contrôle de sécurité)
Lorsque la qualité baisse, l'agent compense en faisant plus : plus d'appels d'outils, plus de tentatives, plus de consommation de jetons. Vous avez besoin de disjoncteurs :
- nombre maximum de tentatives par tâche
- nombre maximum d'appels d'outils par session
- croissance maximale du contexte
- alertes sur le "coût par PR fusionné" ou le "coût par ticket résolu"
C'est ainsi que vous évitez que "l'économie de calcul" ne se transforme en une surprise de facture 100 fois plus élevée.
D) Utilisez une modélisation des menaces LLM, pas seulement un modèle de prompt
Si vous développez des agents qui accèdent à des clés de production, des points d'accès RPC ou des flux de signature, alignez-vous sur des cadres de sécurité tels que l'OWASP Top 10 pour les applications basées sur les grands modèles linguistiques, et traitez l'injection de prompt / la mauvaise utilisation des outils comme des risques de première importance.
4) Pour les utilisateurs quotidiens : l'IA peut vous aider à comprendre la crypto, mais elle ne doit pas contrôler vos clés
Alors que les assistants IA deviennent l'interface par défaut pour les portefeuilles, le trading et le support client, le mode de défaillance le plus probable n'est pas la "génération de mauvais code", mais les mauvaises décisions de signature — surtout sous pression de phishing.
Deux exigences non négociables :
- Ne collez jamais de phrases secrètes dans un chat IA, un "bot de support" ou un formulaire de navigateur.
- Séparez les "conseils" de "l'autorisation" : laissez l'IA résumer, mais exigez une confirmation physique pour déplacer des fonds.
C'est exactement dans cette séparation qu'un portefeuille matériel prend toute son importance.
5) La place de OneKey : rendre l'IA facultative, rendre la signature explicite
Si votre flux de travail (ou celui de vos utilisateurs) dépend de plus en plus de l'IA — que ce soit pour des explications de transactions, des interactions de contrats, ou l'automatisation "d'agents" on-chain — l'architecture la plus sûre est :
- L'IA peut proposer
- Votre application peut simuler
- Votre portefeuille matériel doit approuver
La valeur pratique de OneKey dans une pile crypto saturée d'IA est simple : elle permet de garder les clés privées hors ligne et impose une étape de signature explicite, réduisant ainsi la probabilité qu'un modèle dégradé, un prompt empoisonné, ou un message de "support" persuasif trompeur conduise à une perte irréversible on-chain.
Pensée finale : "Une raisonnement moins cher" n'est pas moins cher — surtout dans la crypto
Le rapport AMD est un cadeau rare : il transforme une crainte vague ("le modèle semble moins bon dernièrement") en un comportement système mesurable et une courbe de coûts hard. Dans la blockchain, où la correction est de l'argent et les erreurs sont permanentes, la leçon est simple :
N'optimisez pas pour le coût en jetons par requête. Optimisez pour la correction par décision.
