L’IA ne suffit pas pour éviter la catastrophe

Hat-trick pour Moonwell, la plateforme du marché des prêts Secteur DeFi qui en seulement 5 mois a subi la beauté de 3 astucesdans tous les cas en raison d'une mauvaise gestion et configuration de l'oracle qui fournit les flux de prix. Le dernier incident s'est produit le 15 février et a entraîné une perte de 1,78 million de dollars due à la formation de créances irrécouvrables.

Le plus incroyable dans cette histoire est que dans le dernier exploit, l'erreur à l'origine du problème provenait d'un commit cosigné par un assistant IA, ce qui a fait beaucoup de bruit dans la communauté. En réalité, cependant, ce n’est pas vraiment la responsabilité de l’intelligence artificielle, mais plutôt le manque de supervision externe et de protections contre d’éventuelles failles de ce type. Regardons de plus près ce qui s'est passé.

Moonwell : énième hack pour le protocole DeFI, formation de créances douteuses

Moonwell est un classique Marché monétaire DeFic’est-à-dire une plateforme qui permet d’emprunter des actifs cryptographiques en échange de garanties fournies pour garantir les opérations. Tous les hacks que le projet a subis proviennent de la formation de« créances irrécouvrables»c'est-à-dire une dette causée par une mauvaise évaluation interne des actifs fournis pour la liquidité et par le fait qu'à un moment donné quelqu'un a pu emprunter plus de valeur que ce que la garantie déposée était réellement capable de couvrir.

C’est l’une des vulnérabilités majeures auxquelles doivent faire face les protocoles de prêt, notamment en période de forte volatilité des prix des actifs (un événement qui pourrait bouleverser tous les calculs internes). L'ensemble du système repose en fait surfiabilité des flux de prix utilisé pour évaluer la garantie et le montant de dette pouvant être généré sur la base de la métrique LTV : si cette valeur est incorrecte, la plateforme pourrait par conséquent fournir plus de crédit que la normale et provoquer d'importantes créances irrécouvrables, donc des pertes pour la plateforme et les utilisateurs.

Si vous souhaitez approfondir ce sujet, nous vous recommandons d’examiner comment évoluent généralement les principaux protocoles DeFi : nous expliquons ici comment Aave se couvre normalement contre le risque de créances irrécouvrables

3 hacks en 5 mois : erreurs de configuration et gestion des risques

Les 3 hacks subis par Moonwell partent de la même hypothèse, c'est-à-dire d'un erreur de tarification d'Oracle qui fournit des données de tarification au protocole, ce qui lui permet de former par erreur des créances irrécouvrables. En pratique, les incidents ont été déclenchés par différents catalyseurs, dans des conditions de marché différentes, et rendus possibles grâce à un mauvaise surveillance et des paramètres de risque inadéquats. Quoi qu’il en soit, le protocole a brûlé des millions de dollars. En procédant par ordre chronologique

• 10 octobre 2025: date que nous connaissons tous, à laquelle il y a eu une vente très violente de tous les actifs cryptographiques, avec un une volatilité qui a plongé de nombreux systèmes Oracle dans une chute librey compris celui utilisé par Moonwell qui fournissait des flux de jetons tels que AERO, VIRTUAL et MORPHO. L'erreur, cependant, dans ce cas a été d'offrir un LTV très élevé (environ 85 %) sur les jetons volatils, qui a été exploité avec des prêts flash répétés. 1,7 million de dollars de pertes

• 4 novembre 2025: pas même un mois plus tard, en raison d'un exploit parallèle sur Balancer qui a provoqué un fort désalignement du token rsETH (également utilisé comme référence par Moonwell), quelqu'un a emprunté une valeur bien supérieure à la garantie fournie, puis l'a fait liquider et générer 3,7 millions de dollars de créances irrécouvrables. Le problème ici n’était pas d’avoir un flux réaliste, basé uniquement sur le prix du dérivé et non sur la valeur de conversion.

• 15 février 2026: l'épisode le plus banal de tous, où une configuration incorrecte du prix du coin cbETH et de la formule qui explique sa contre-valeur a provoqué des pertes pour 1,78 millions de dollars. Un utilisateur a exploité la faille via prêt flashen cours de liquidation pour plus de 1000 cbETH.

L'importance d'avoir un flux de prix véridique et un contrôle de sécurité dans DeFi

Au-delà de la cause déclenchant les différents hacks de Moonwell, le vrai problème se situe en amont. Dans la gestion d'un protocole de prêt, qui risque de s'épuiser si les flux de prix oracle ne fournissent pas de références précises, il faut être très attentif et opter pour des paramétrages de sécurité.

En particulier, La volatilité est le premier ennemi des marchés monétaires: Si les prix évoluent trop rapidement, même un oracle sérieux et fiable comme Chainlink pourrait fournir des prix incorrects. Dans ce cas, le bouclier est appliquer des LTV faibles aux jetons volatils et disposer d’un coussin de liquidité pour compenser les événements extrêmes.

Ensuite, pour le reste le seul véritable souci est de fixer une formule correcte qui permette à l'oracle de renvoyer une valeur la plus proche possible de la réelle, même en cas de manipulation de sources externes. Le fait est que dans certains cas, il est nécessaire mettre quelques « contrôle de santé mentale »ou mécanismes de sécurité qui permettent de suspendre l'émission de crédit si les valeurs fournies par l'oracle sont disproportionnées par rapport aux moyennes historiques.

Dans le cas Moonwell, on a parlé de problèmes avec l'oracle, alors qu'en réalité l'erreur réside dans le paramétrage et la gestion des risques de la plateforme. On a aussi effectivement parlé de responsabilité de l’IA, puisque le dernier hack vient d'un changement de code effectué par Claude Opus 4.6.

L'un des premiers cas de piratage de code assisté par l'IA

Ce qui a suscité de nombreuses discussions à propos du dernier hack de Moonwell, c'est le fait queL'IA a aidé à écrire le codesans détecter le problème dans la configuration tarifaire. Dans le détail, l’erreur consistait à fixer le prix du cbETH en fonction du ratio cbETH/ETH, sans ensuite expliquer la valeur de chaque unité d’ETH.

Des problèmes techniques qui sont par ailleurs assez simples pour ceux qui naviguent dans ces environnements, et qu'une IA aurait au moins dû mettre en évidence. Le problème est que intelligence artificielle ne connaît pas le contexte des demandes qui vous sont faites e ne sait pas si la formule fournie est adéquate du point de vue de la gestion des risques, à moins que tout soit spécifié en premier dans l'invite.

L'erreur ne vient clairement pas de l'IA, qui aurait probablement grandement simplifié le travail du développeur, qui en l'absence de Claude aurait dû passer de nombreuses heures supplémentaires à écrire manuellement chaque ligne de code. Le fait est que tout le code doit ensuite être revérifié en détail du développeur, implémentant également les paramètres de sécurité.

D’autant plus que lorsque l’on gère des millions de dollars (d’autres utilisateurs), il est encore plus indispensable d’effectuer une double vérification stricte et de ne pas laisser une IA vous dire si la logique économique du protocole est correcte. Sinon, il serait plus approprié de parler de carence artificielle.