IOSG : La DeFi traverse actuellement sa période la plus critique ; les véritables vulnérabilités ne résident pas dans le code.
TechFlow SélectionTechFlow Sélection
IOSG : La DeFi traverse actuellement sa période la plus critique ; les véritables vulnérabilités ne résident pas dans le code.
La plus grande menace pour la DeFi ne provient plus des failles de code, mais d’un dysfonctionnement au niveau opérationnel, notamment au niveau des clés et des validateurs.
Dédié à des analyses Web3 approfondiesRédaction : Darko, IOSG Ventures
Le 1er avril 2026 à 16h05:18 UTC, un attaquant a soumis une transaction au protocole Drift. Une seconde plus tard, une autre transaction l’a approuvée.
Douze minutes plus tard, 285 millions de dollars avaient disparu. Dix-sept jours après, un validateur compromis du pont interchaînes de KelpDAO a, seul, frappé 292 millions de dollars de jetons non soutenus, provoquant, en 48 heures, un retrait de près de 8,5 milliards de dollars sur Aave et d’environ 4,5 milliards de dollars sur d’autres protocoles DeFi.
Douze jours supplémentaires se sont écoulés, puis un attaquant détenant la clé privée d’un déploieur compromis a retiré 4,5 millions de dollars du protocole Wasabi sur quatre chaînes.
Aucun de ces incidents n’a résulté d’une exploitation de vulnérabilité dans un contrat intelligent.
Pendant près d’une décennie, le DeFi a cru fermement que la sécurité était un problème de code. Audits, vérification formelle, primes pour la découverte de failles — toute l’industrie s’est organisée autour d’une hypothèse fondamentale : tant que la logique des contrats intelligents est rigoureuse, le protocole est sécurisé. Les mathématiques font loi. Avril 2026 fut le mois où cette hypothèse s’est effondrée sous les yeux du public.
En un seul mois, plus de 625 millions de dollars ont été volés lors d’environ 30 incidents — selon les données de DefiLlama, il s’agit du mois le plus pillé de l’histoire de la cryptographie en nombre d’incidents — et chaque perte majeure remonte à des clés privées d’administrateurs, à des validateurs de ponts interchaînes, à des zones aveugles d’oracles ou à des attaques d’ingénierie sociale : autant d’éléments constitutifs opérationnels que les audits n’ont jamais été conçus pour couvrir.
Cet article traite de cette transition. Nous décomposerons trois graves attaques survenues en avril en trois manifestations différentes d’un même échec fondamental, reconstituerons comment une mauvaise configuration d’un pont interchaînes d’un protocole a déclenché un retrait de 13,2 milliards de dollars sur un protocole vingt-cinq fois plus important, et examinerons franchement la véritable nature actuelle du DeFi — une infrastructure ouverte dotée d’un levier opérationnel de confiance, même si ce n’est pas ainsi qu’elle est présentée sur le plan marketing. Le problème ne réside pas dans les mathématiques.
Il réside dans le « modèle mental » qui les entoure.
Les mathématiques ne sont pas défectueuses. Ce qui est défectueux, c’est le modèle mental qui leur est superposé — et le coût de ce décalage oblige désormais l’industrie à reconsidérer ce que signifie réellement la « décentralisation ».
Le déficit de modèle mental
Pendant la majeure partie de l’histoire du DeFi, la culture dominante de la sécurité reposait sur Solidity. Les audits examinaient la logique des contrats. Les primes pour la découverte de failles étaient versées pour les réentrances, les dépassements d’entiers ou les erreurs de modificateurs d’accès. La vérification formelle prouvait des invariants pour le code sur chaîne. L’hypothèse implicite était la suivante : tout ce qui se trouve en dehors des contrats — multisignatures, clés privées des déploieurs, validateurs de ponts interchaînes, infrastructures de relais (Relayer), canaux de communication de l’équipe — relevait soit d’un périmètre hors portée, soit d’un problème relevant d’autrui.
Cette hypothèse n’était valable que tant que les attaquants exploitaient des vulnérabilités Solidity.
Les attaques d’avril 2026 partagent une caractéristique structurelle que les rapports d’audit ne peuvent décrire : aucun des contrats intelligents concernés n’était vulnérable. Selon la reconstitution effectuée par des chercheurs indépendants spécialisés dans la chaîne, le code de Drift avait été audité deux fois — en 2022 par Trail of Bits, puis en février 2026 par ClawSecure — et les deux audits avaient été jugés conformes.
Aucun de ces audits n’avait couvert la configuration multisignature de Drift, la logique de gestion des « durable nonce », ni le champ d’attaque d’ingénierie sociale lié à son Conseil de sécurité (Security Council). L’adaptateur LayerZero de KelpDAO utilisait le modèle standard OFT (Omnichain Fungible Token) ; le contrat lui-même ne comportait aucune anomalie. L’erreur résidait dans la configuration de déploiement — or celle-ci tombe généralement hors du périmètre habituel des audits Solidity.
Le contrat Vault de Wasabi était conçu pour être mis à jour ; cette conception même constituait la vulnérabilité.
Ce qui s’est effondré en avril, ce n’était pas les mathématiques, mais le socle opérationnel sur lequel elles reposent.
Trois cas décortiqués : trois visages d’un même échec
Les trois graves attaques d’avril 2026 — Drift, KelpDAO et Wasabi — représentent trois types distincts d’« échecs non liés au code ».
Prises ensemble, elles couvrent la majorité des nouvelles surfaces d’attaque et partagent une caractéristique structurelle commune : dans chacun de ces cas, un ou deux individus ou infrastructures compromis ont déclenché un effet domino affectant l’ensemble du protocole.
Drift : la multisignature humaine (285 millions de dollars)
L’attaque contre Drift était une opération de renseignement, non une exploitation de vulnérabilité. Selon les analyses menées conjointement par TRM Labs, Elliptic et l’équipe de Drift elle-même avec l’aide de SEAL 911, l’attaquant a été identifié comme le groupe nord-coréen Lazarus Group, plus précisément son sous-groupe UNC4736, déjà associé par Mandiant à l’attaque contre Radiant Capital en octobre 2024.
L’opération avait été planifiée pendant environ six mois. L’ingénierie sociale avait débuté à l’automne 2025, lors de conférences sectorielles, tandis que les préparatifs sur chaîne avaient commencé seulement trois semaines avant l’incident.
Le 11 mars 2026, l’opération a été lancée avec une transaction de 10 ETH issue de Tornado Cash. Le lendemain, aux alentours de 9h00 heure de Pyongyang, ces fonds ont été utilisés sur Solana pour déployer le jeton CarbonVote Token (CVT). L’attaquant a créé un petit pool de liquidité sur Raydium, puis effectué des transactions croisées (wash trades) sur CVT afin d’ancrer artificiellement son cours autour de 1 dollar, avant de mettre en place un oracle de prix contrôlé, alimentant ainsi Drift avec ce prix factice.
La présence de transactions croisées visait à rendre la sortie de l’oracle « légitime en apparence » — toute vérification aléatoire aurait montré que le cours du marché correspondait exactement à la valeur fournie par l’oracle.
Parallèlement, l’attaquant s’était fait passer pour une institution de trading quantitatif, établissant progressivement une relation de confiance avec des contributeurs de Drift sur plusieurs semaines. L’objectif n’était pas d’extraire des informations, mais de préparer à l’avance un climat de confiance pour un moment précis.
Ce moment dépendait d’une fonctionnalité spécifique de Solana, appelée « durable nonces » (nonces persistants) : un mécanisme légal permettant de « signer aujourd’hui, exécuter plus tard ». Entre le 23 et le 30 mars, l’attaquant avait obtenu des signatures « durable nonce » auprès d’au moins deux membres du Conseil de sécurité à cinq personnes de Drift.
Du point de vue des signataires, ils approuvaient une transaction courante. Du point de vue du réseau, ces signatures constituaient des justificatifs d’autorisation valides, en sommeil mais pleinement efficaces.
Le 26 mars, Drift a pris une décision désastreuse en rétrospective : migrer vers une nouvelle multisignature de type « 2-sur-5 » pour son Conseil de sécurité, avec un délai de verrouillage (timelock) nul. Cette migration a supprimé la fenêtre de délai initialement prévue, qui aurait pu permettre de détecter ou d’interrompre l’attaque.
Le 1er avril à 16h05:18 UTC, l’attaquant a soumis sa première transaction pré-signée utilisant un « durable nonce » — une proposition visant à transférer le contrôle administratif vers l’adresse H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL. Une seconde plus tard, à 16h05:19 UTC, une deuxième transaction pré-signée l’a approuvée et exécutée. Drift était tombé entre les mains de l’attaquant.
Ce qui a suivi n’a pris que douze minutes. L’attaquant a listé le CVT sans valeur comme collatéral, bénéficiant d’un montant d’emprunt quasi illimité, puis a déposé 500 millions de CVT au prix manipulé fourni par l’oracle, avant de retirer 285 millions de dollars d’actifs réels depuis trois coffres principaux — JLP, USDC, SOL, cbBTC, wBTC et ETH. La valeur totale verrouillée (TVL) de Drift est passée de 550 à environ 250 millions de dollars. Deux signataires, un protocole, des contrats intelligents fonctionnant parfaitement selon leur conception. La faille résidait dans « l’humain ».
Une particularité de la réponse post-incident de Drift mérite d’être soulignée, car elle fixe une norme à laquelle les prochains protocoles victimes devront répondre : la transparence exceptionnelle de la divulgation faite par Drift.
Dans les cinq jours suivant la découverte de la faille, l’équipe a publié une analyse détaillée de l’attaque par ingénierie sociale — incluant notamment les faits suivants : les contributeurs avaient été contactés à plusieurs reprises durant les six mois précédents ; deux d’entre eux avaient probablement été compromis via le clonage du dépôt de code et une version bêta de portefeuille TestFlight ; les conversations Telegram avec l’attaquant avaient été supprimées avant et après l’attaque ; la décision prise six jours avant l’incident de migrer vers une multisignature sans timelock avait éliminé la dernière fenêtre de détection possible.
L’équipe a également rendu publique, avec un niveau de confiance modéré, l’attribution de l’attaque (UNC4736 / Citrine Sleet), coordonné ses actions avec SEAL 911, et partagé des détails opérationnels utiles pour aider d’autres protocoles à identifier cette même tactique.
Les protocoles victimes se retranchent souvent derrière des précautions juridiques et des formulations imprécises ; Drift a choisi de publier une narration riche en éléments probants, capable de transformer un incident isolé en intelligence collective sur les menaces pour l’ensemble du secteur. L’incident reste bien sûr une attaque, et la faille sous-jacente de gouvernance demeure une faille. Mais le fait d’accepter de rendre publique « comment fonctionne l’ingénierie sociale » constitue précisément ce qui distingue les protocoles contribuant activement à l’apprentissage collectif du secteur de ceux qui absorbent silencieusement leurs pertes.
KelpDAO : un unique validateur (292 millions de dollars)
Dix-sept jours plus tard, le 18 avril, le même profil d’acteurs malveillants a orchestré une attaque structurellement différente. KelpDAO est un protocole de ré-staking de liquidité émettant rsETH — un jeton représentant les dépôts des utilisateurs routés via EigenLayer pour générer des rendements supplémentaires.
En avril 2026, la TVL de rsETH dépassait 1 milliard de dollars et le jeton était déployé sur plus de vingt chaînes via le standard OFT (Omnichain Fungible Token) de LayerZero.
Le contrat n’était pas fautif. C’était la configuration qui l’était.
Le pont interchaînes de KelpDAO fonctionnait sur un réseau de validateurs décentralisé (DVN, Decentralized Verifier Network) configuré en « 1-sur-1 » — c’est-à-dire avec un seul validateur. Un seul nœud suffisait donc à approuver un message interchaînes. « Décentralisé » était un mot, pas une architecture.
L’attaque s’est déroulée en plusieurs phases. L’attaquant a d’abord compromis le nœud RPC interne utilisé par le validateur pour lire l’état de la chaîne source, puis a lancé une attaque DDoS coordonnée contre les nœuds externes, forçant le système à revenir sur l’infrastructure contaminée. Une fois la source de données sous son contrôle, il a falsifié un message interchaînes ordonnant au contrat Ethereum principal de KelpDAO de frapper rsETH à partir d’une destruction « jamais survenue sur aucune chaîne source ».
À 17h35 UTC, le contrat a libéré 116 500 rsETH — d’une valeur d’environ 292 millions de dollars, soit environ 18 % de l’offre en circulation — vers une adresse contrôlée par l’attaquant. En quelques minutes, ces rsETH ont été déposés comme collatéral sur Aave, évalués à environ 2 500 dollars pièce.
L’attaquant a emprunté des WETH, USDC et wBTC réels contre ce collatéral non soutenu, retirant finalement plus de 82 600 ETH (soit environ 191 millions de dollars) avant que KelpDAO ne suspende ses contrats à 18h21 UTC.
Deux tentatives ultérieures, à 18h26 et 18h28 UTC, visaient chacune à retirer 40 000 rsETH supplémentaires, mais ont toutes deux été annulées. La suspension a empêché toute perte supplémentaire, mais n’a pas empêché le retrait initial.
Pas de vulnérabilité de réentrée, pas de vérification d’accès manquante, aucune manipulation d’oracle intégrée dans la logique propre de Kelp. L’invariant comptable définissant le pont interchaînes — les actifs libérés sur la chaîne de destination doivent égaler les actifs détruits sur la chaîne source — a été violé au niveau du système, et non au niveau des transactions. Un seul nœud, des centaines de millions de dollars perdus.
Ce qui a suivi fut un débat public : qui était réellement responsable ? Le rapport initial post-incident de LayerZero attribuait directement la faute à Kelp, arguant que ce dernier avait enfreint les recommandations en choisissant une configuration DVN « 1-sur-1 ». Dans sa note de réplique publiée le 5 mai, Kelp dessinait un autre tableau : à ce moment-là, 47 % des applications OApp actives sur LayerZero — environ 1 250 applications, totalisant une capitalisation boursière supérieure à 4,5 milliards de dollars — fonctionnaient toutes avec cette même configuration à validateur unique.
Kelp affirmait que les guides de démarrage rapide (OFT Quickstart), les exemples GitHub et les modèles de développeurs fournis par LayerZero lui-même avaient, dès leur sortie, désigné le DVN de LayerZero Labs comme validateur obligatoire, sans proposer d’alternative. Il produisait également des captures d’écran Telegram provenant de collaborateurs de LayerZero, attestant qu’ils avaient dit à l’équipe de Kelp, à huit reprises au cours de discussions d’intégration étalées sur deux ans et demi, que « l’utilisation des valeurs par défaut était sans risque ».
Le chercheur en sécurité Sujith Somraaj (ancien auditeur de LayerZero) avait soumis sur Immunefi un rapport de prime pour découverte de vulnérabilité décrivant précisément ce mode d’attaque, mais celui-ci avait été rejeté par LayerZero au motif que « le choix du réseau de validateurs relevait de la configuration au niveau applicatif ».
La réponse de LayerZero à la note de Kelp fut la suivante : cette formulation était trompeuse. L’exclusion de la « configuration au niveau applicatif » des primes pour découverte de vulnérabilités constituait une frontière standard entre « plateforme » et « application » (selon un porte-parole de LayerZero, sinon « toute application pourrait se désigner comme DVN unique et percevoir frauduleusement des récompenses ») ; la valeur par défaut pour presque tous les chemins d’exécution était en réalité un DVN multi-validateur ; quant aux modèles affichant une configuration « 1-sur-1 », le DVN unique y pointait vers un contrat fictif nommé « DeadDVN », qui rejetait systématiquement tous les messages, forçant ainsi les développeurs à configurer leur pile de sécurité avant la mise en production.
Concernant Kelp, LayerZero indiquait que ce dernier avait initialement déployé un DVN multi-validateur, puis avait volontairement réduit sa configuration à « 1-sur-1 » — ce n’était donc pas « l’utilisation des valeurs par défaut ».
La frontière entre « plateforme » et « application » est effectivement un point de désaccord réel, et des ingénieurs rationnels peuvent diverger sur la question de savoir si une plateforme dont les modèles peuvent être configurés de manière dangereuse doit assumer la responsabilité de la configuration concrète déployée par ses utilisateurs.
Ce qui est nettement moins contesté, c’est la deuxième partie de la réponse finale de LayerZero. Le 8 mai, trois semaines après la publication de son premier rapport post-incident, LayerZero a fait marche arrière et présenté ses excuses : « Nous avons commis une erreur en autorisant notre DVN à fonctionner comme DVN “1-sur-1” dans des transactions à haute valeur. Nous n’avons pas défini de limites à la protection offerte par notre propre DVN. »
Le protocole a cessé de prendre en charge les configurations « 1-sur-1 » au sein de son écosystème DVN, a migré sa valeur par défaut vers « 5-sur-5 », a relevé le seuil de sa multisignature interne de « 3-sur-5 » à « 7-sur-10 », et a annoncé le lancement d’une nouvelle plateforme de surveillance des émetteurs (Console).
Que la configuration défectueuse relève de la faute de Kelp, de celle de LayerZero, ou — le scénario le plus probable — d’un échec partagé entre une plateforme pouvant être configurée par défaut de manière dangereuse et un intégrateur ayant volontairement réduit sa configuration, les réponses finales des deux parties convergent vers la même conclusion : la validation « 1-sur-1 » n’est pas sécurisée à grande échelle, et l’industrie n’aurait pas dû payer 292 millions de dollars pour l’apprendre.
Wasabi : la clé privée d’administrateur (4,5 millions de dollars)
L’incident de Wasabi, survenu le 30 avril, était d’un ordre de grandeur inférieur aux deux autres, ce qui le rendait d’autant plus embarrassant. Il s’agissait d’un « piratage banal ».
Un EOA (Externally Owned Account) de déploieur — l’adresse 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8 — détenait le rôle ADMIN_ROLE au sein du gestionnaire de contrats à terme perpétuels de Wasabi, déployé sur Ethereum, Base, Blast et Bera. Aucune multisignature. Le cadre contractuel supportait initialement un timelock, mais sa valeur avait été réglée à zéro.
L’attaquant s’est emparé de cette clé privée — par hameçonnage, infiltration d’appareil ou attaque de la chaîne d’approvisionnement, Wasabi n’a pas fourni de conclusion définitive. Une fois en possession du rôle ADMIN_ROLE, il l’a attribué à un contrat auxiliaire malveillant, puis a procédé à une mise à niveau proxy UUPS du contrat Vault, vidant ainsi les collatéraux et les soldes des pools. La perte globale interchaînes s’élève à 4,5–5,5 millions de dollars.
Wasabi n’a recouru à aucune technologie nouvelle. Cette vulnérabilité, en tant qu’anti-modèle du DeFi, est signalée depuis des années : concentration excessive des pouvoirs de gestion, absence de séparation des pouvoirs, absence de délai de verrouillage. Il s’agit du même défaut contre lequel le DeFi se heurte depuis 2020, qu’il documente régulièrement dans ses rapports post-incident, mais qu’il ne corrige jamais concrètement.
Lier les trois incidents : au fond, ils constituent un même type d’attaque. Que l’accès privilégié soit obtenu par manipulation de signataires, infiltration de nœuds validateurs ou vol de clé privée de déploieur, la surface d’attaque est identique — une concentration de pouvoir, insuffisamment protégée, située en dehors de la couche des contrats intelligents. Ce schéma est aussi un avertissement : dans chaque cas, un ou deux entités compromises déclenchent une chaîne de dominos que même la plus solide des sécurisations Solidity ne peut arrêter.
Le domino asymétrique
L’incident impliquant KelpDAO dépasse en importance sa perte financière propre, car ce qui s’est produit ensuite — la première véritable mise à l’épreuve de la composable du DeFi face à un échec opérationnel — constitue également le cas le plus parlant illustrant « à quel point la propagation mathématique peut être grotesquement asymétrique ».
Pour bien mesurer l’ampleur : au moment de l’incident, la TVL de rsETH chez KelpDAO avoisinait 1 milliard de dollars ; l’actif sous gestion (AUM) d’Aave sur l’ensemble des chaînes dépassait 25 milliards de dollars. Un protocole dont la taille représente environ 4 % d’Aave a réussi, en une seule opération, à en retirer 8,45 milliards de dollars sur Aave en 48 heures — ce chiffre atteignant 15,1 milliards de dollars en trois jours et demi — tandis que la TVL globale du DeFi baissait de 13,21 milliards de dollars durant cette même fenêtre de 48 heures. L’asymétrie est ici le véritable sujet.
Un petit protocole ayant mal configuré son pont interchaînes a déclenché une ruée bancaire sur un protocole bien plus important, qui fonctionnait « strictement selon spécifications » selon tous ses propres indicateurs contractuels.
Lorsque l’attaquant a frappé les rsETH non soutenus et les a déposés sur Aave, les contrats d’Aave ont simplement exécuté les règles prévues. Son oracle, pendant la brève fenêtre d’emprunt de l’attaquant, continuait à lire rsETH comme étant presque égal à 1:1. Le pool de prêt a délivré des WETH réels contre un collatéral qui semblait « valide » à tous les systèmes sur chaîne.
La réaction du marché a été immédiate. En quelques heures, rsETH a commencé à s’échanger sur les DEX avec une forte décote, reflétant une incertitude réelle — le reste de l’offre, soit 82 %, était-il encore pleinement soutenu ? Aave V3 et V4 ont gelé le marché rsETH ; Fluid, Compound, Euler et Morpho ont suivi en quelques heures (SparkLend avait déjà retiré rsETH dès janvier).
Les détenteurs de rsETH sur Arbitrum, Base, Mantle, Linea, Blast et Scroll se sont alors retrouvés incapables de garantir qu’ils pourraient convertir leurs jetons 1:1 en ETH sur la chaîne principale d’Ethereum.
Le retrait subséquent de fonds ne résultait pas d’un piratage d’Aave, mais de l’incapacité des déposants à déterminer si le collatéral garantissant leurs prêts conservait encore sa capacité de remboursement.
Quelques semaines avant l’incident, Aave avait accumulé une position importante en rsETH, car les utilisateurs utilisaient ce jeton pour amplifier leurs stratégies de ré-staking ; le protocole en tirait des frais, sans avoir fixé de plafond à cet engagement. Cette propagation n’était donc pas purement le fruit d’un « spectateur innocent » — Aave avait volontairement assumé le risque de contrepartie — mais l’événement déclencheur se trouvait en dehors de ses propres contrats, et également hors de portée de sa gouvernance.
La réponse d’Aave à cet incident mérite une mention particulière, car elle établit une référence contre laquelle d’autres grands protocoles de prêt seront évalués. En quelques heures suivant la divulgation, l’administrateur d’urgence du protocole avait gelé le marché rsETH sur toutes les chaînes concernées, tant sur V3 que sur V4, et avait fixé le taux de prêt (LTV) à zéro, bloquant ainsi toute perte supplémentaire.
En 48 heures, le prestataire de services d’Aave publiait sur le forum de gouvernance un rapport détaillé sur l’incident, modélisant publiquement deux scénarios de pertes — si Kelp socialisait la perte entre tous les détenteurs de rsETH, les pertes seraient de 123,7 millions de dollars ; si la perte était isolée aux déploiements sur les chaînes de niveau 2, elles atteindraient 230,1 millions de dollars — accompagné d’une ventilation par chaîne, précisant quels marchés devraient supporter quels déficits.
Stani Kulechov, fondateur d’Aave, s’est personnellement engagé à fournir 5 000 ETH pour la récupération ; une alliance baptisée DeFi United, pilotée par le prestataire de services d’Aave et incluant Lido, EtherFi, LayerZero et Mantle, a mobilisé plus de 300 millions de dollars de promesses pour combler le déficit rsETH. Il s’agit de la plus grande intervention inter-protocole jamais réalisée dans le secteur.
Les critiques sont plus circonscrites et doivent être examinées séparément de la réponse : l’attitude d’Aave a connu une légère dérive à mesure que la fourchette de pertes se précisait. L’engagement initial selon lequel sa réserve Umbrella couvrirait le déficit a été adouci en « exploration des voies possibles pour combler le déficit ». Cette dérive narrative, bien que mineure, est notable — une assurance protocolaire au niveau du protocole, qui semble ferme dans un contexte abstrait, devient un élément négociable dès que les chiffres sont précisés.
Le traitement opérationnel d’Aave était adéquat, mais cela ne change pas le fait structurel suivant : les déposants ayant placé des USDC dans le protocole prennent un risque de contrepartie sur un jeton dont ils ignorent probablement jusqu’à l’existence, tandis que la force contraignante finale de son mécanisme d’assurance s’avère bien plus faible que ce que ses documents laissent entendre.
Voilà le problème structurel le plus profond. La conception monopool d’Aave, qui lui confère une liquidité profonde et une expérience utilisateur fluide, signifie également qu’un seul mauvais collatéral listé peut produire un rayon d’explosion à l’échelle de tout le protocole. Même si la gouvernance d’Aave est diligente et ses contrats robustes, le protocole reste exposé aux échecs de sécurité d’un contrepartie bien plus petite — une exposition suffisante pour mettre sous pression des fonds de déposants à neuf chiffres et déclencher le gel des marchés sur neuf protocoles différents.
La composable, moteur de la croissance du DeFi, en est aussi le canal de propagation. Avril 2026 marque la première fois que cette facture est réglée à grande échelle. Aucune réforme radicale n’est visible. La composable, qui a jadis alimenté la croissance du DeFi, est désormais devenue le canal de transmission par lequel « l’échec opérationnel d’un protocole devient une ruée bancaire sur un autre protocole ».
La vérité de l’OpenFi
Nous abordons maintenant une conversation que le secteur a longtemps évitée.
Appelons-la OpenFi : une infrastructure financière accessible sans permission, auditée sur chaîne, mais qui, aux points critiques où « l’argument décentralisé original prétendait éliminer les intermédiaires », repose encore opérationnellement sur des tiers de confiance. Selon cette définition, la majeure partie de ce qui est aujourd’hui commercialisé sous le nom de DeFi est en réalité de l’OpenFi. Un Conseil de sécurité disposant du pouvoir de transférer le contrôle administratif.
Un pont interchaînes doté d’un seul validateur. Un EOA de déploieur détenant un rôle ADMIN_ROLE interchaînes. Un jeton de gouvernance concentré au point qu’une minorité patiente puisse capturer la trésorerie, à l’instar de Nouns. Chacun de ces éléments constitue une « couture privilégiée » cousue à la va-vite dans un système censé être transparent.
Il convient de rappeler l’argument originel. Le « calcul minimisant la confiance » de Szabo, l’infrastructure « neutre de confiance » de Buterin, l’insistance des Cypherpunks sur le fait que « la vie privée et la liberté exigent l’élimination — non l’audit — des intermédiaires » — rien de tout cela ne concerne la « transparence ». La transparence est nécessaire, et facile à obtenir. L’affirmation véritablement difficile — celle qui justifie tous les coûts de faire fonctionner une machine à états globale sur des dizaines de milliers de nœuds redondants — est que « personne dans le système ne peut être contraint, capturé, corrompu ou infiltré pour modifier les règles ».
Un registre public que vous pouvez examiner mais non influencer est une chose. Un registre public dont la clé privée d’administrateur repose dans le portefeuille matériel d’une personne, enfermé dans un coffre-fort, en est une autre. L’OpenFi respecte la première moitié de cette transaction, mais abandonne discrètement la seconde.
Les protocoles dépendent de types de confiance différents, et leurs modes d’échec varient également.
Donner un nom à chacun d’eux est utile : confiance de garde (quelqu’un conserve vos actifs réels, vous ne commercez que sur des droits de réclamation — ponts interchaînes, jetons « wrapped ») ; confiance de mise à jour (quelqu’un peut modifier le comportement du contrat après votre dépôt — administrateurs proxy, Conseil de sécurité) ; confiance d’oracle (quelqu’un fournit des données que le contrat ne peut produire lui-même — alimentation des prix) ; confiance d’activité (le bon fonctionnement du système dépend de la gestion continue par quelqu’un — ordonnanceurs (sorters), relais (Relayer), gardiens (Keeper)) ; confiance de gouvernance (les détenteurs de jetons, ou la petite minorité capable de rassembler le quorum requis en cas de vote litigieux).
La plupart des protocoles dépendent simultanément de trois à quatre de ces types. La plupart des textes marketing les regroupent tous sous le terme unique de « décentralisation », laissant le lecteur deviner le reste.
Le problème plus grave est que certaines de ces hypothèses sont totalement dissimulées. Dans ses excuses de mai, LayerZero a reconnu qu’il y a trois ans et demi, l’un de ses signataires multisignature avait utilisé un portefeuille matériel en environnement de production pour réaliser une transaction personnelle. Cette erreur avait été corrigée en interne, mais jamais divulguée aux utilisateurs ; elle n’a refait surface que dans le cadre d’une annonce de renforcement, présentée comme une réorganisation routinière plutôt que comme une confession franche. Les utilisateurs du système de confiance n’avaient aucun moyen de connaître cet incident, ni de chiffrer le risque qu’il représentait réellement.
Le secteur utilise une expression euphémique pour qualifier ce déficit : « roulettes d’apprentissage ». Le discours commercial insiste sur le caractère temporaire des clés privées d’administrateurs et des Conseils de sécurité — présents aujourd’hui, mais destinés à disparaître une fois que le protocole aura acquis suffisamment de maturité pour marcher seul. En pratique, ces roulettes ne sont presque jamais retirées. Elles sont rebaptisées, reconditionnées, prolongées ou discrètement transférées au nom de la fondation.
Le cadre « Stage 0 / Stage 1 / Stage 2 » de L2Beat constitue la seule exception remarquable, une preuve existentielle que « ce secteur est capable, s’il le souhaite, de décrire honnêtement ses hypothèses réelles de confiance ». Presque aucun protocole n’adopte spontanément l’expression de L2Beat dans sa communication commerciale — ce fait même est la preuve que « le manque de franchise est structurel, non ponctuel ».
Il s’agit d’une réalité technique, façonnée à chaque niveau par les incitations concrètes auxquelles sont confrontés les concepteurs. Si vous souhaitez lancer rapidement un produit complexe, pouvoir répondre à une vulnérabilité sans nécessiter un fork du protocole, supporter de nouveaux types de collatéral, ou vous intégrer à d’autres composants de l’écosystème, vous avez besoin d’un levier opérationnel.
Des contrats absolument immuables, sans accès privilégié, sont certes robustes, mais aussi fragiles — toute modification exige une migration complète, toute vulnérabilité devient permanente, toute nouvelle fonctionnalité impose aux utilisateurs de choisir à nouveau d’adopter le nouveau déploiement. Outre les facteurs techniques, une réalité supplémentaire s’impose : les calendriers des fonds de capital-risque n’autorisent pas des cycles de vérification formelle de trois ans, et les protocoles lancés en premier capturent la liquidité.
La composable amplifie encore le problème : un protocole immuable ne peut pas intégrer un nouvel oracle, ne peut pas supporter une nouvelle chaîne, ne peut pas corriger une vulnérabilité identifiée, sauf à obliger tous les utilisateurs et intégrateurs à migrer.
Le résultat est le suivant : pour toute équipe individuelle, le choix rationnel est « lancer avec une clé privée d’administrateur, en promettant de la retirer plus tard » ; pour tout utilisateur individuel, le choix rationnel est d’accepter ce compromis, car les alternatives soit n’existent pas, soit manquent de liquidité. L’OpenFi n’est pas un échec moral isolé de certains concepteurs. C’est l’équilibre de Nash du domaine.
La formulation honnête est la suivante : le DeFi a presque universellement choisi d’échanger une partie de sa décentralisation contre une faisabilité opérationnelle. Ce choix est défendable. Ce qui n’est pas honnête, c’est de ne pas nommer explicitement ce compromis, tout en continuant à commercialiser le protocole comme « décentralisé », alors que son modèle de sécurité réel repose sur quelques signataires, un seul validateur, ou une multisignature vulnérable à l’ingénierie sociale.
L’avenir ressemble davantage à une « divulgation » qu’à une « révolution » : obligation d’étiquetage des hypothèses de confiance selon le modèle de L2Beat ; délais suffisamment longs pour permettre aux utilisateurs de sortir avant qu’une opération privilégiée ne soit finalisée ; marchés d’assurance tarifant le « risque opérationnel » plutôt que le « risque purement codé » imaginaire ; et distinction claire entre « les parties du système qui nécessitent effectivement un chemin de mise à jour » et « celles qui sont simplement rendues modifiables par habitude architecturale ». Avril 2026 n’a pas prouvé que l’OpenFi est inviable.
Il a prouvé que commercialiser un système OpenFi comme un système DeFi laisse ses utilisateurs totalement dépourvus de préparation face à ses modes d’échec réels. Pour sécuriser un tel système, la première étape consiste à reconnaître honnêtement que c’est bien cela que nous construisons.
La double face de la centralisation
Le compromis central de l’OpenFi devient visible à l’œil nu dans l’incident de gel d’Arbitrum. Trois jours après l’exploitation de la vulnérabilité de KelpDAO, le Conseil de sécurité d’Arbitrum a voté le gel de 30 766 ETH — environ 71 millions de dollars — transférés par l’attaquant sur Arbitrum One. Ce gel a été coordonné avec les autorités chargées de l’application de la loi et, selon la plupart des critères, constitue un bon résultat : les fonds volés ont été empêchés de blanchir, les canaux secondaires de l’attaquant ont été coupés, et une partie des pertes subies par les utilisateurs pourrait être récupérée.
Mais notez ce qui a rendu ce gel possible : Arbitrum dispose d’un Conseil de sécurité habilité à « intervenir directement dans les transferts sur chaîne ». Ce n’est pas une caractéristique d’une infrastructure décentralisée. C’est un interrupteur de centralisation intégré par conception — défendable au motif de « réponse d’urgence », utilisé précisément de la façon dont les critiques le craignaient — pas nécessairement mauvais, mais certainement aux conséquences importantes.
Le même mécanisme qui a permis à Arbitrum de jouer le rôle du « gentil » après l’incident Kelp est exactement le même qui a permis à Drift d’être compromis — une poignée de signataires de confiance détenant le pouvoir d’effectuer des opérations au niveau du protocole, ne différant que par « la force des contraintes pesant sur ce pouvoir ». Une fois, ce pouvoir a été légitimement utilisé pour geler des fonds volés ; une autre fois, il a été détourné par ingénierie sociale pour vider les dépôts des utilisateurs. Le levier coupe dans les deux sens.
L’« interrupteur de coupure » peut échouer par au moins cinq canaux différents — ingénierie sociale (Ronin, Drift), infiltration d’un employé interne (Multichain), coercition souveraine, contrainte légale (Tornado Cash, USDC), ou prise de contrôle de la gouvernance (Beanstalk, Mango Markets). Chacun de ces cas constitue une attaque différente, nécessitant des défenses différentes ; dire simplement que « le Conseil a échoué » masque tout cela. Nommer précisément le canal d’échec est la première étape pour commencer à le défendre.
C’est la « double face de la centralisation » dans le DeFi, et c’est aussi la chose la plus importante à comprendre sur l’état actuel du secteur : chaque levier opérationnel capable de produire un « bon résultat » en situation d’urgence est aussi une surface d’attaque — il produira un mauvais résultat dans un autre incident.
Le problème plus profond est que, dans le cas d’Arbitrum, le terme « bon résultat » porte un poids excessif. La légitimité est une construction sociale, et ce même type de levier a déjà été actionné dans des contextes où le consensus était loin d’être aussi clair. Le fork DAO d’Ethereum en 2016 reste un exemple classique : la moitié de la communauté soutenait que l’annulation de cette vulnérabilité de 60 millions de dollars constituait l’usage le plus évident et légitime du consensus social ; l’autre moitié estimait que cela constituait une trahison fatale du principe « le code est la loi », et a procédé à un fork, donnant naissance à Ethereum Classic.
Circle et Tether gèlent régulièrement des adresses USDC et USDT, parfois en réponse à des sanctions de l’OFAC, parfois uniquement sur simple soupçon, sans offrir aux utilisateurs concernés aucune voie de recours — ce gel est présenté comme une mesure de conformité, mais il s’agit fondamentalement d’un exercice de pouvoir discrétionnaire. Le gel d’Arbitrum a fonctionné. Le fork DAO, d’une certaine façon, a aussi fonctionné.
Le gel d’USDC fonctionne quotidiennement. La question honnête n’est pas « l’interrupteur de coupure peut-il produire un bon résultat », mais « qui décide ce qu’est un bon résultat » — et dans quelle mesure les utilisateurs du protocole ont-ils été informés de ce processus décisionnel.
Aucune version de ce compromis ne permet de « n’en prendre qu’un ». Soit vous avez un interrupteur de coupure, et vous possédez donc quelque chose qui peut être capturé, manipulé ou attaqué par ingénierie sociale ; soit vous n’en avez pas, et vous devez alors accepter que certains incidents soient définitifs et irrémédiables.
Ces leviers ne sont pas non plus interchangeables. Le Conseil de sécurité d’Arbitrum peut transférer rapidement des fonds via une procédure d’urgence à seuil bas — la combinaison « vitesse + étendue » rend le gel possible, mais la même combinaison rend aussi catastrophique le mode d’échec si le Conseil lui-même est compromis.
Le levier de THORChain est plus étroit : il peut suspendre les opérations et se recapitaliser via une émission de RUNE, mais ne peut pas saisir ni rediriger les actifs des utilisateurs. L’administrateur d’urgence d’Aave peut geler des marchés et ajuster les paramètres de risque, mais ne peut pas transférer les soldes des utilisateurs. La fermeture d’urgence de MakerDAO est une sortie unidirectionnelle, non un outil de confiscation. Leurs formes diffèrent, leurs compromis aussi, mais on les désigne toutes par le même terme : « interrupteur de coupure ». Un protocole souhaitant traiter honnêtement son propre modèle de confiance doit à ses utilisateurs non pas une catégorie, mais une description précise de la forme.
Le secteur tend aussi à éviter une autre distinction : celle entre « levier actionné uniquement dans des cas extrêmes » et « levier opérant dans le rythme courant ».
Bitcoin et Ethereum possèdent théoriquement tous deux un interrupteur de coupure — une coordination suffisante entre nœuds, mineurs, validateurs et plateformes d’échange pourrait, demain, déclencher un fork sur n’importe quelle chaîne. Ces deux chaînes sont néanmoins considérées comme fidèles et minimisant la confiance, parce que ce levier a presque jamais été actionné, et que chaque activation entraîne un clivage communautaire permanent.
Le fork DAO date de dix ans, et demeure à ce jour l’événement le plus controversé de l’histoire d’Ethereum. Bitcoin n’a jamais connu de fork similaire.
Le levier existe, mais il est crédiblement promis comme « inactif » dans les affaires courantes — c’est précisément cette longue histoire de retenue qui confère au système sous-jacent une fiabilité que ses caractéristiques techniques seules ne sauraient lui accorder.
En revanche, le Conseil de sécurité d’Arbitrum fonctionne dans le rythme courant. Il vote régulièrement sur des mises à jour. Il a déjà mené des actions d’urgence avant le gel de Kelp, et en mènera d’autres par la suite. Ce n’est pas une capacité de réserve endormie, mais un organe de gouvernance actif. La critique de l’OpenFi s’applique avec beaucoup plus de force aux « leviers actifs » qu’aux « leviers endormis », car la retenue inhérente au levier endormi est elle-même un signal — la confiance accordée à un opérateur dont le seuil d’utilisation est extrêmement élevé est une confiance que le levier lui-même ne peut pas accorder. Les leviers actifs ne possèdent pas ce signal. Ils ne peuvent être évalués que sur la base de leurs propres contrôles, lesquels se sont révélés à maintes reprises insuffisants.
Après avoir subi une vulnérabilité en 2021, THORChain a adopté la voie « sans levier », ce qui lui a valu de nombreuses critiques pour son absence d’outils d’intervention. Arbitrum a choisi la voie de l’« interrupteur de coupure » et a reçu des éloges. Les deux choix sont défendables. Aucun n’est gratuit. Le secteur doit cesser de feindre qu’il peut avoir les deux — et doit dire honnêtement aux utilisateurs quel compromis précis chaque protocole a effectivement retenu.
Un dernier rebondissement : ce compromis ne fera qu’empirer avec le temps. Dès qu’un protocole peut geler des fonds, les régulateurs et les tribunaux seront de plus en plus enclins à statuer qu’il « doit » le faire. La capacité de gel d’USDC, initialement conçue comme un outil d’urgence de conformité, est devenue aujourd’hui une réponse de facto obligatoire aux notifications de l’OFAC et aux listes croissantes d’entités ciblées par les autorités locales.
La décision de « lancer avec un interrupteur de coupure » est aussi celle d’« hériter d’une liste d’obligations d’utilisation qui ne fera que s’allonger au fil du cycle de vie du protocole », dont beaucoup ne correspondent pas aux orientations que la communauté du protocole elle-même soutiendrait. La posture « sans levier » de THORChain est donc non seulement un choix technique, mais aussi une posture réglementaire — en excluant d’emblée la possibilité de « conformité », elle exclut aussi d’emblée l’obligation de « conformité ».
La viabilité de cette posture sous une pression réglementaire continue reste une question ouverte, mais l’asymétrie est réelle : un protocole doté d’un levier peut être contraint de l’utiliser ; un protocole qui n’en possède pas ne le peut pas.
Pour les institutions observant le secteur depuis l’extérieur, cette honnêteté compte bien plus que le marketing. Un interrupteur de coupure opérationnel clairement divulgué, assorti d’une gouvernance, d’une gestion des clés et d’une réponse aux incidents dûment documentées — voilà un dispositif que toute équipe de gestion de fonds ou compagnie d’assurance peut assurer. Un protocole prétendant minimiser la confiance tout en fonctionnant sur une multisignature « 2-sur-5 » sans timelock n’est pas assurable. Le premier est un choix technique légitime. Le second est un risque que personne ne saurait chiffrer.
Que va-t-il se passer ?
L’habitude des cycles sectoriels est d’oublier. Chaque cycle quadriennal réinvente les institutions que le DeFi était censé remplacer, essuie une défaite, se souvient brièvement pourquoi les principes existent, puis oublie à nouveau. Ce qui s’est produit en avril n’était pas sans précédent. C’est l’état final prévisible d’un secteur qui échange la commodité contre les principes, sans jamais nommer explicitement ce compromis.
Trois décisions se présentent aujourd’hui au secteur, et aucune ne peut être repoussée davantage.
Centralisation. Chaque protocole doit choisir publiquement quels leviers opérationnels il détient, et expliquer ce choix à ses utilisateurs. La version honnête du DeFi n’est pas un DeFi qui se présente comme « décentralisé » tout en fonctionnant sur une multisignature « 2-sur-5 » sans timelock, mais un DeFi qui divulgue publiquement la composition de sa multisignature, son seuil, son timelock, et les conditions d’activation de chaque levier. Nommer explicitement le compromis est la seule façon de le rendre viable.
Sécurité. L’audit n’est pas une ligne de démarcation. Les protocoles capables de survivre au prochain cycle traiteront la sécurité opérationnelle — gestion des clés, signataires, ponts interchaînes, configurations, réponse aux incidents — comme une discipline de premier plan, aussi importante que l’audit Solidity. La plupart des équipes la considèrent encore comme une tâche logistique. Cette attitude ne tiendra plus dès que les gestionnaires de trésorerie commenceront à poser, aux départements de distribution des fonds, les mêmes questions qu’ils posent aujourd’hui.
Allocation des fonds. Ce sont les fonds destinés au prochain cycle — ceux des caisses de retraite, des gestionnaires souverains, des trésoreries d’entreprises et des bilans d’assurances — qui attendent, observant le secteur. Ils n’ont pas besoin d’une minimisation absolue de la confiance. Ils ont besoin d’un risque opérationnel assurable. Les protocoles ressemblant davantage à des infrastructures critiques qu’à des expériences attirent ce flux de capitaux. Les autres protocoles continueront de compter sur leurs fonds traditionnels issus des particuliers, regardant impuissants la vague institutionnelle les contourner.
Avril 2026 n’était pas une crise de sécurité. C’était le moment où le modèle mental du secteur s’est totalement fracturé — et le moment où les protocoles capables de survivre commencent à se distinguer clairement de ceux qui ne le seront pas.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
