Dernièrement, le monde des cryptomonnaies a subi une autre devastating lesson sur la fragilité de la finance décentralisée.
BunniDEX, un échange décentralisé prometteur construit sur l’architecture innovante de hooks d’Uniswap v4, a vu des attaquants vider 8,4 millions $ de ses pools de liquidité sur Ethereum et Unichain. En quelques heures, un protocole qui avait attiré 60 millions $ en valeur totale bloquée est devenu pratiquement insolvable, sa trajectoire de croissance brisée par une simple vulnérabilité au niveau de la logique.
L’attaque elle‑même a été d’une précision chirurgicale. Selon blockchain security firm Halborn, l’exploiteur a utilisé une attaque sophistiquée par flash loan combinée à une manipulation minutieuse de la fonction de distribution de liquidité (Liquidity Distribution Function) de Bunni. L’attaquant a emprunté des USDT, les a échangés contre des USDC pour déplacer le tick de prix spot, puis a exploité des erreurs d’arrondi dans le pool afin de réduire de façon disproportionnée la liquidité tout en retirant bien plus d’actifs que ce à quoi il avait droit. Dans un pool, la liquidité disponible est passée de 28 wei à seulement 4 wei – une baisse de 85,7 % qui a permis des retraits massifs non autorisés.
Ce qui rend cet incident particulièrement inquiétant est que Bunni avait, en apparence, tout fait correctement. Le protocole avait été audité par deux sociétés de sécurité réputées : Trail of Bits et Cyfrin. Pourtant, toutes deux ont manqué la faille critique. Comme l’équipe Bunni l’a reconnu plus tard, le bug était une « faille de logique plutôt qu’une erreur d’implémentation » – le genre de défaut qui échappe aux audits de code classiques mais se révèle catastrophique en production. L’erreur d’arrondi dans la fonction de retrait agissait à l’inverse des attentes des développeurs : au lieu d’augmenter le solde inactif comme prévu, elle le diminuait, créant les conditions de l’exploitation.
Au 23 octobre 2025, Bunni a annoncé sa fermeture définitive. L’équipe ne pouvait pas se permettre les six à sept chiffres nécessaires pour un relancement sécurisé, incluant des audits complets et des systèmes de monitoring. Dans leur déclaration de fermeture, ils ont écrit : « Le récent exploit a stoppé net la croissance de Bunni, et pour relancer le protocole de manière sécurisée, nous devrions payer 6–7 chiffres rien qu’en frais d’audit et de monitoring – un capital que nous n’avons tout simplement pas. »
Cela soulève une question fondamentale qui hante tout l’écosystème DeFi en 2025 : si un protocole bien audité, techniquement sophistiqué, construit par des développeurs passionnés, peut être mis à terre par une seule erreur de logique, quel espoir existe‑t‑il pour une finance décentralisée réellement sécurisée ? Et pourquoi, après des années d’exploits dévastateurs et de milliards de pertes, ces attaques continuent‑elles de se produire ?
L’ampleur de la crise
La disparition de Bunni n’est pas un incident isolé, mais fait partie d’un schéma inquiétant qui fait de 2025 l’une des années les plus dangereuses pour les cryptomonnaies. Selon le Hacken's 2025 Web3 Security Report, l’industrie crypto a perdu plus de 3,1 milliards $ rien que sur le premier semestre 2025 à cause de hacks et de fraudes. Ce chiffre stupéfiant dépasse déjà le total des pertes de 2,85 milliards $ pour toute l’année 2024.
La concentration des attaques sur les échanges décentralisés est particulièrement frappante. CertiK's Q3 2025 analysis a révélé que, bien que les pertes globales en crypto aient diminué de 37 % au troisième trimestre pour atteindre 509 millions $, les projets DeFi et les échanges sont restés des cibles privilégiées. Les échanges centralisés ont subi la plus grande part avec 182 millions $ volés, mais les protocoles DeFi suivent de près avec 86 millions $ de pertes sur le seul troisième trimestre.
Les statistiques dressent le tableau troublant d’un écosystème assiégé. Hacken's researchers ont constaté que les exploits liés au contrôle d’accès représentaient environ 59 % de toutes les pertes au premier semestre 2025 – soit environ 1,83 milliard $. Les vulnérabilités des smart contracts ont contribué pour 8 % supplémentaires, soit 263 millions $ volés. Cela fait du premier semestre 2025 la période la plus coûteuse pour les attaques sur contrats intelligents depuis le début de 2023.
Peut‑être plus inquiétante encore est l’accélération de la fréquence des incidents. Septembre 2025 a enregistré un nombre record d’exploits supérieurs au million de dollars : 16 attaques dépassant 1 million $ chacune, le plus grand nombre mensuel jamais enregistré. Malgré la mise en place de meilleures mesures de sécurité par certains protocoles, les attaquants continuent de trouver de nouvelles vulnérabilités à un rythme alarmant.
Comparée aux années précédentes, 2025 reflète à la fois des progrès et un danger persistant. L’année record pour les exploits DeFi reste 2022, avec plus de 3,7 milliards $ volés. Le secteur a connu des améliorations en 2023 et 2024, les pertes baissant dans la fourchette de 2–3 milliards $ par an. Cependant, les 3,1 milliards $ déjà perdus en seulement six mois de 2025 suggèrent que la tendance pourrait s’inverser.
Le coût humain va bien au‑delà de ces chiffres abstraits. Chaque exploit représente de vraies personnes – fournisseurs de liquidité, traders et investisseurs – qui perdent leurs fonds. Les 2,367 affected users in the KyberSwap exploit illustrent à eux seuls comment des attaques concentrées se répercutent sur des communautés entières, détruisant confiance et moyens de subsistance.
Anatomie des exploits : études de cas d’échecs de code
Pour comprendre pourquoi la sécurité DeFi reste si insaisissable, il faut examiner les mécanismes précis par lesquels les protocoles échouent. Les études de cas suivantes révèlent des schémas récurrents – flash loans, manipulation d’oracle, réentrance, défaillances de contrôle d’accès et erreurs de logique – qui définissent le paysage des vulnérabilités.
Bunni DEX (8,4 M $, septembre 2025)
Comme indiqué plus haut, Bunni's exploit provient d’un bug de direction d’arrondi dans la logique de retrait. L’attaquant a combiné des flash loans, des micro‑retraits et des attaques sandwich. La fonction innovante de distribution de liquidité du protocole, conçue pour optimiser les rendements des fournisseurs de liquidité, est devenue son talon d’Achille. L’exploit a montré comment une innovation DeFi de pointe peut introduire des vecteurs d’attaque imprévus lorsque les hypothèses mathématiques se révèlent incorrectes.
Curve Finance (69 M $, juillet 2023)
Le Curve Finance exploit constitue l’une des attaques techniquement les plus fascinantes de l’histoire de la DeFi. La vulnérabilité ne se trouvait pas dans le code de Curve, mais dans le compilateur Vyper lui‑même. Les versions 0.2.15, 0.2.16 et 0.3.0 de Vyper contenaient un bug critique où les verrous de réentrance fonctionnaient mal, permettant aux attaquants d’appeler plusieurs fonctions simultanément.
L’ironie est profonde : Vyper a été créé précisément pour être plus sûr que Solidity. Pourtant, comme l’explique Hacken's analysis, ce bug au niveau du compilateur est resté indétecté pendant près de deux ans après son introduction en juillet 2021. La vulnérabilité n’a été corrigée que dans Vyper 0.3.1, publié en décembre 2021, mais personne ne s’est rendu compte que les anciennes versions présentaient des risques catastrophiques avant l’attaque de juillet 2023.
L’attaque contre Curve a affecté plusieurs protocoles DeFi, dont JPEG'd, Metronome et Alchemix. Security firm CertiK noted que 69 millions $ ont été drainés de différents pools, l’exploit représentant 78,6 % des pertes liées aux attaques par réentrance en 2023. L’incident a déclenché des retraits paniques qui ont fait plonger la valeur totale bloquée de Curve de près de 50 %, à 1,5 milliard $, en une journée.
Ce qui rend cet exploit particulièrement instructif, c’est sa classification comme vulnérabilité « spécifique au langage » – des défauts dans le langage de programmation lui‑même plutôt qu’une erreur de développeur. Cela introduit une perspective terrifiante : même une implémentation de code parfaite peut être compromise par des failles dans les outils sous‑jacents.
KyberSwap (48 M $, novembre 2023)
Doug Colkitt, créateur de l’exchange Ambient, a qualifié le KyberSwap exploit de « facilement l’exploit de smart contract le plus complexe et le plus soigneusement conçu que j’aie jamais vu ». L’attaque exploitait la fonctionnalité de liquidité concentrée de KyberSwap Elastic via ce que Colkitt a appelé un « glitch d’argent infini ».
La vulnérabilité résidait dans un écart entre l’estimation cross‑tick et le calcul final du prix dans le mécanisme de swap de KyberSwap. According to Halborn's analysis, lorsque le montant échangé était égal à amountSwapToCrossTick moins un, une erreur d’arrondi entraînait un mauvais prix de pool. Cela violait l’hypothèse selon laquelle nextPrice serait inférieure ou égale à targetPrice, menant à un doublement inattendu de la liquidité.
L’attaquant a commencé par manipuler le prix du pool ETH/wstETH vers une zone pratiquement sans liquidité. Il a ensuite minté une petite quantité de liquidité dans une fourchette de prix étroite et exécuté deux swaps cruciaux. Le premier a vendu 1 056 wstETH contre très peu d’ETH, faisant chuter le prix. Le second a inversé l’opération, rachetant 3 911 wstETH – bien plus que la quantité initialement vendue. Le pool a comptabilisé deux fois la liquidité de la position de LP d’origine, rendant ce vol possible.
KyberSwap avait implémenté un mécanisme de sécurité dans sa fonction computeSwapStep précisément pour empêcher ce type d’exploit. Pourtant, comme l’ont découvert des blockchain security researchers, l’attaquant a méticuleusement conçu ses transactions pour rester juste en dehors de la plage qui aurait déclenché ce garde‑fou. cette protection. Cette ingénierie de précision souligne à quel point les attaquants sont devenus sophistiqués.
Euler Finance (197 M$, mars 2023)
L’attaque par prêt flash contre Euler Finance constitue le plus grand exploit DeFi de 2023. Euler, un protocole de prêt sans permission sur Ethereum, a été victime d’une vulnérabilité dans sa fonction donateToReserves qui ne comportait pas de vérifications de liquidité adéquates.
La séquence d’attaque était élaborée. L’exploiteur a d’abord emprunté 30 millions de DAI via un prêt flash depuis Aave. Il a déposé 20 millions de DAI sur Euler, recevant environ 19,6 millions de jetons eDAI. En utilisant la fonction mint d’Euler, il a emprunté de manière récursive 10 fois son dépôt – une fonctionnalité conçue pour un levier efficace mais exploitable lorsqu’elle est combinée à la mécanique de donation.
L’étape cruciale consistait à donner 100 millions d’eDAI aux réserves d’Euler sans que le protocole vérifie correctement que cela créait une dette sur‑collatéralisée. Lorsque l’attaquant a liquidé sa propre position, il a obtenu 310 millions de dDAI et 259 millions d’eDAI. Après avoir retiré 38,9 millions de DAI et remboursé le prêt flash avec les intérêts, il a réalisé un bénéfice d’environ 8,9 millions de dollars rien que sur le pool DAI. Ce schéma a été répété sur plusieurs pools, aboutissant au butin total de 197 millions de dollars.
L’analyse de l’incident par CertiK a identifié deux défaillances majeures : l’absence de vérifications de liquidité dans donateToReserves, qui a permis la manipulation des jetons de dette et de capitaux propres, et un mécanisme de notation de santé qui a involontairement permis à des comptes insolvables d’obtenir des garanties sans s’acquitter de leurs dettes. Sherlock, une société d’audit qui avait examiné le code, a admis sa responsabilité et a accepté de compenser Euler à hauteur de 4,5 millions de dollars pour ne pas avoir détecté la vulnérabilité.
Dans un retournement de situation surprenant, l’attaquant a finalement rendu tous les fonds et s’est excusé via des messages chiffrés on‑chain. Cette résolution inhabituelle ne diminue toutefois pas la défaillance de sécurité fondamentale qui a rendu l’exploit possible.
GMX v1 (40 M$, juillet 2025)
L’exploit de GMX v1 en juillet 2025 a montré que même les protocoles de première génération restent vulnérables des années après leur lancement. L’attaque a ciblé le pool de liquidité de GMX sur Arbitrum, exploitant une faille de conception dans la manière dont la valeur des jetons GLP était calculée.
L’analyse de SlowMist a révélé la cause racine : le design de GMX v1 mettait immédiatement à jour les prix moyens globaux des positions short lorsque des shorts étaient ouverts. Cela avait un impact direct sur le calcul des actifs sous gestion (AUM), créant des opportunités de manipulation. Grâce à une attaque de réentrance, l’exploiteur a établi d’énormes positions short pour manipuler les prix moyens globaux, gonflant artificiellement le prix du GLP au sein d’une seule transaction, puis en profitant via la rédemption.
La faille de réentrance – décrite par l’expert blockchain Suhail Kakar comme « l’astuce la plus vieille du livre » – s’est révélée être une faiblesse fondamentale plutôt que superficielle. L’attaquant a pu tromper le contrat en lui faisant croire qu’aucun retrait n’avait eu lieu, frappant de nouveaux jetons à plusieurs reprises sans collatéral adéquat.
La réponse de GMX s’est révélée innovante. Plutôt que de se limiter aux recours juridiques, ils ont offert à l’attaquant une prime de chapeau blanc de 10 % – 5 millions de dollars – pour qu’il rende 90 % des fonds volés dans les 48 heures. Le pari a fonctionné. L’exploiteur a accepté via un message on‑chain : « Ok, funds will be returned later. » En quelques heures, les fonds ont commencé à revenir. Au final, GMX a récupéré la totalité du montant, légèrement plus en raison de la hausse des prix du Bitcoin et de l’Ethereum pendant l’incident.
Ce cas illustre une tendance émergente : les protocoles traitent de plus en plus les exploiteurs sophistiqués comme des chapeaux blancs potentiels plutôt que comme de simples criminels, en s’appuyant sur les incitations économiques plutôt que sur les menaces juridiques.
Balancer (août 2023, 2,8 M$ à risque)
L’incident de Balancer en août 2023 offre une perspective différente – une quasi‑catastrophe plutôt qu’une perte totale. Lorsque Balancer a découvert une vulnérabilité critique, les développeurs ont immédiatement averti les utilisateurs et travaillé à la mitigation des risques. Ils ont réussi à sécuriser 95 % des pools de liquidité affectés, mais 2,8 millions de dollars (0,42 % de la valeur totale verrouillée) sont restés à risque.
Malgré des avertissements agressifs et des instructions détaillées de retrait, des attaquants ont fini par exploiter la vulnérabilité pour environ 900 000 dollars. L’exploit a utilisé des prêts flash pour attaquer les pools non mitigés. PeckShield a signalé que les pertes dépassaient 2,1 millions de dollars si l’on comptait toutes les adresses affectées.
La gestion de la crise par Balancer a été saluée par la communauté crypto. Le chercheur Laurence Day l’a qualifiée d’« exemple parfait de divulgation de vulnérabilité critique menée correctement ». Pourtant, l’incident a tout de même mis en évidence une vérité inconfortable : même avec une communication exemplaire et une réponse rapide, une protection complète reste impossible une fois qu’une vulnérabilité existe.
Autres exploits notables
Le schéma se répète dans de nombreux autres incidents :
Cetus (223 M$, 2025) : Comme l’a rapporté Hacken, Cetus a subi le plus grand exploit DeFi isolé de 2025 – 223 millions de dollars drainés en seulement 15 minutes à cause d’une vulnérabilité de vérification de dépassement dans les calculs de liquidité. Cette attaque à elle seule a représenté une part significative des 300 millions de dollars de pertes DeFi au deuxième trimestre.
Cork Protocol (12 M$, 2025) : Selon la même analyse de Hacken, l’exploit de Cork est issu de la modification par les développeurs des permissions par défaut de la fonction beforeSwap de Uniswap V4. Les attaquants ont exploité des vérifications insuffisantes des droits d’accès pour injecter des données malveillantes et drainer 12 millions de dollars.
Orbit Chain (80 M$, décembre 2023) : Cet échec d’intégration de pont cross‑chain et de DEX a mis en lumière les risques cumulés lorsque les protocoles s’étendent sur plusieurs blockchains. Des portefeuilles multisignatures compromis ont permis un vol massif de fonds.
SushiSwap Router (3,3 M$, avril 2023) : Une mauvaise utilisation d’une fonction publique a permis un accès non autorisé à la logique de routage, démontrant comment même de petites négligences en matière de contrôle d’accès peuvent coûter cher.
Uranium Finance, Radiate Capital, KokonutSwap : Ces protocoles plus modestes ont subi des sorts similaires – défauts de logique dans la gestion de la liquidité, validation d’entrée inadéquate et contrôles d’accès inappropriés qu’ont exploités des attaquants pour des pertes cumulées de plusieurs millions.
Pourquoi les audits continuent de manquer les vraies menaces
L’exploit de Bunni cristallise l’un des paradoxes les plus frustrants de la DeFi : la manière dont des protocoles ayant subi plusieurs audits professionnels échouent pourtant de façon catastrophique. Pour le comprendre, il faut examiner ce que les audits font réellement – et surtout, ce qu’ils ne peuvent pas faire.
Les audits de smart contracts traditionnels se concentrent principalement sur les vulnérabilités syntaxiques : risques de réentrance, dépassements/débordements d’entiers, fonctions non protégées, optimisation du gas et conformité aux bonnes pratiques. Les auditeurs examinent le code ligne par ligne, à la recherche de modèles de vulnérabilités courants documentés dans des bases comme le Smart Contract Weakness Classification Registry. Ce processus, bien que précieux, opère au niveau de l’implémentation.
Les vulnérabilités sémantiques – des failles logiques comme l’erreur d’arrondi de Bunni – se situent à un niveau conceptuel plus élevé. Ces bogues surviennent lorsque le code s’exécute exactement comme écrit, mais produit des conséquences non voulues dans des scénarios spécifiques. L’arrondi dans la fonction withdraw de Bunni fonctionnait parfaitement du point de vue de l’exécution du code. Il opérait simplement à l’inverse des hypothèses du modèle économique des développeurs.
Trail of Bits et Cyfrin, les sociétés qui ont audité Bunni, sont des leaders respectés de la sécurité blockchain. Trail of Bits a audité de grands protocoles comme Uniswap, Compound et Maker. Leur incapacité à détecter la faille de Bunni n’est pas de l’incompétence – elle reflète les limites fondamentales de la méthodologie d’audit.
Plusieurs facteurs restreignent l’efficacité des audits :
Contraintes de temps et de ressources : Les audits complets coûtent généralement entre 40 000 et 100 000 dollars et durent 2 à 4 semaines. Pour des protocoles complexes comme Bunni avec des fonctionnalités innovantes, tester réellement de façon exhaustive tous les cas extrêmes nécessiterait des mois et des coûts dépassant le budget de la plupart des projets. Les auditeurs doivent faire des compromis pratiques entre profondeur et viabilité économique.
Défis liés aux architectures nouvelles : Bunni s’appuyait sur le nouveau système de hooks d’Uniswap v4, introduit fin 2024. Le manque de tests en conditions réelles pour les protocoles basés sur des hooks signifiait que les auditeurs manquaient de modèles de vulnérabilités établis auxquels se référer. L’innovation augmente intrinsèquement le risque en s’aventurant en territoire inconnu.
Ambiguïté des spécifications : Les auditeurs ne peuvent vérifier que la conformité du code aux spécifications. Si les spécifications comportent elles‑mêmes des erreurs logiques ou des définitions incomplètes des cas extrêmes, les auditeurs peuvent valider des conceptions fondamentalement défectueuses. La fonction de distribution de liquidité de Bunni était spécifiée pour optimiser les rendements, mais la spécification ne tenait apparemment pas pleinement compte du comportement de l’arrondi dans des conditions extrêmes.
Le problème de la composabilité : Les protocoles DeFi s’intègrent à de nombreux systèmes externes – oracles de prix, autres protocoles, mécanismes de gouvernance. Les auditeurs évaluent généralement les contrats de façon isolée, et non l’ensemble des scénarios d’interaction possibles. Les vulnérabilités émergent souvent de combinaisons inattendues de fonctions pourtant légitimes.
Cette limitation se manifeste dans ce que les initiés de l’industrie appellent le « théâtre de l’audit » – des projets qui affichent en avant leurs badges d’audit à des fins marketing tout en abritant des failles exploitables. D’après les données d’Immunefi, environ 60 % des exploits majeurs surviennent dans des protocoles ayant subi au moins un audit. La présence d’un audit apporte un faux sentiment de sécurité plutôt qu’une protection réelle.
Les incitations économiques aggravent ces problèmes. La DeFi opère dans un environnement hautement concurrentielEnvironnement de « course au marché ». Les projets subissent une pression intense pour lancer rapidement avant leurs concurrents. Chaque semaine de retard dans le développement coûte une part de marché potentielle et du total value locked. Des revues de sécurité longues et exhaustives entrent en conflit avec cette urgence.
Considérez l’asymétrie des incitations : les audits peuvent coûter 100 000 $, tandis que les pertes moyennes dues aux exploits dépassent 10 à 30 millions de dollars. D’un point de vue d’acteur rationnel, les projets devraient investir massivement dans la sécurité. Pourtant, l’économie comportementale raconte une autre histoire. Les fondateurs présentent un biais d’optimisme, se convainquant que leur code est spécial, que les attaques ne les cibleront pas, ou qu’une itération rapide vaut mieux qu’une préparation approfondie.
La vulnérabilité de Vyper qui a détruit Curve illustre une autre dimension : la sécurité de la chaîne d’approvisionnement. Même si les développeurs de protocoles écrivent un code parfait et que les auditeurs l’examinent en profondeur, des vulnérabilités dans les compilateurs, les bibliothèques ou les outils de développement peuvent invalider tous ces efforts. Cela crée un faux sentiment de sécurité où développeurs et auditeurs croient que le code est sûr parce que leurs domaines spécifiques sont validés.
The Economics of Insecurity
Comprendre les échecs de sécurité persistants de la DeFi nécessite d’examiner les forces économiques sous-jacentes qui incitent à adopter des pratiques de développement risquées.
La mentalité « move fast and farm TVL » domine la culture DeFi. Le total value locked sert de principal indicateur du succès d’un protocole, influençant directement les prix des tokens, la confiance des utilisateurs et le positionnement concurrentiel. Les protocoles se livrent une course pour attirer la liquidité via des rendements élevés, des fonctionnalités innovantes et un marketing agressif. La sécurité, en revanche, reste invisible jusqu’à la catastrophe. Les projets qui consacrent six mois à des tests rigoureux pendant que leurs concurrents lancent et capturent des parts de marché subissent une pression existentielle les poussant à compromettre la sécurité.
Cette dynamique crée des effets pervers de sélection. Les protocoles prudents qui privilégient la sécurité peuvent ne jamais atteindre le TVL nécessaire pour survivre à long terme, tandis que les projets plus risqués qui « bougent vite et cassent des choses » captent l’enthousiasme des premiers utilisateurs. Le marché punit effectivement la prudence et récompense la témérité – du moins jusqu’à ce qu’un exploit se produise.
La composabilité, plus grande force de la DeFi, devient son talon d’Achille dans cet environnement. Les protocoles modernes intègrent des oracles de prix externes comme Chainlink, empruntent de la liquidité à Aave ou Compound, transitent par Uniswap et interagissent avec des dizaines d’autres systèmes. Chaque point d’intégration multiplie les surfaces d’attaque potentielles. Une vulnérabilité dans n’importe quel protocole connecté peut se propager à l’ensemble de l’écosystème.
The Euler exploit's impact on Balancer, Angle, and Idle Finance a démontré ce risque de contagion. Le pool Euler Boosted USD de Balancer a perdu 11,9 millions de dollars – 65 % de son total value locked – alors même que le code propre à Balancer était sûr. Angle avait 17,6 millions de dollars en USDC bloqués dans Euler, et Idle Finance a perdu 4,6 millions de dollars. La vulnérabilité d’un protocole a infecté tout le graphe DeFi.
Les développeurs font face à des arbitrages impossibles. Construire en isolation signifie renoncer aux bénéfices de la composabilité et limiter les fonctionnalités. S’intégrer largement signifie assumer les risques de chaque protocole connecté. Il n’existe pas de voie sûre, seulement des degrés de danger.
L’asymétrie économique entre défenseurs et attaquants est frappante. Les protocoles doivent se défendre contre tous les vecteurs d’attaque possibles, à travers des millions de lignes de code et des interactions complexes. Les attaquants n’ont besoin de trouver qu’une seule faiblesse exploitable. Les défenseurs supportent en continu des coûts substantiels (temps de développement, frais d’audit, systèmes de surveillance). Les attaquants, eux, investissent un effort ponctuel pour des gains potentiellement énormes.
Les flash loans, disponibles sur des plateformes comme Aave et dYdX, abaissent drastiquement la barrière de capital pour les attaques. Historiquement, les exploits exigeaient que les attaquants possèdent ou empruntent au préalable de grandes quantités de crypto-monnaies. Les flash loans fournissent des millions de capital au sein d’une seule transaction pour un coût minime. Tant que le prêt est remboursé avant la fin de la transaction, les attaques deviennent en pratique gratuites à tenter.
According to Halborn's Top 100 DeFi Hacks Report, les attaques par flash loan ont explosé en 2024, représentant 83,3 % des exploits éligibles. L’année 2025 poursuit cette tendance. La technologie a transformé l’exploitation de failles, d’une opération professionnelle nécessitant beaucoup de capital, en quelque chose que tout développeur compétent muni d’une vulnérabilité astucieuse peut tenter.
Le calcul de valeur attendue favorise massivement les attaquants. Considérez : les coûts d’audit sont en moyenne de 40 000 à 100 000 dollars. Les pertes moyennes liées aux exploits sont de 10 à 30 millions de dollars. Pourtant, de nombreux protocoles peinent à se payer même des audits basiques. Pendant ce temps, les attaquants qui réussissent peuvent voler des dizaines de millions en quelques minutes avec un investissement initial minimal.
Ce déséquilibre reflète une défaillance plus large du marché. La sécurité est un bien public : tout le monde bénéficie de protocoles robustes, mais chaque acteur individuel a peu d’incitations à payer pour la sécurité collective. Les protocoles qui investissent massivement dans la sécurité subventionnent les passagers clandestins qui copient leur code sans engager de coûts similaires. Cela crée une tragédie des communs, où un sous-investissement systémique dans la sécurité persiste malgré des pertes globales catastrophiques.
The Flash Loan Paradox
Les flash loans représentent peut-être l’élément le plus paradoxal de la sécurité DeFi : une technologie essentielle au fonctionnement de l’écosystème qui permet simultanément nombre de ses pires exploits.
Fondamentalement, les flash loans sont des prêts non collatéralisés qui doivent être empruntés et remboursés au sein d’une seule transaction on-chain. Si le remboursement échoue, toute la transaction est annulée comme si le prêt n’avait jamais eu lieu. Cela élimine le risque de défaut pour les prêteurs tout en offrant aux emprunteurs un accès temporaire à un capital énorme.
Les cas d’usage légitimes sont convaincants. Les arbitragistes utilisent les flash loans pour corriger les inefficiences de prix entre plateformes, améliorant l’efficacité des marchés. Les traders peuvent refinancer des positions, en déplaçant des collatéraux d’une plateforme de prêt à une autre offrant de meilleures conditions. Les développeurs peuvent tester des mécanismes de liquidation ou des stress tests de protocoles sans risquer leurs fonds personnels. Ces applications renforcent la composabilité et l’efficacité du capital en DeFi.
Pourtant, les mêmes propriétés qui rendent les flash loans utiles en font des outils parfaits pour l’exploitation de failles. Considérez un schéma typique d’attaque par flash loan :
Étape 1 – Emprunter : l’attaquant contracte un flash loan de plusieurs millions en tokens depuis Aave ou dYdX, en ne payant qu’une petite commission (souvent 0,09 % ou moins).
Étape 2 – Manipuler : grâce au capital emprunté, l’attaquant manipule un protocole cible – par exemple en faussant un oracle de prix, en vidant un pool de liquidité ou en exploitant un bug de réentrance.
Étape 3 – Extraire : cette manipulation permet des retraits non autorisés ou des swaps avantageux qui profitent à l’attaquant.
Étape 4 – Rembourser : l’attaquant rend le montant initial du prêt plus les frais, en empochant la différence issue de l’exploit.
Temps total : tout cela se produit en une seule transaction, souvent en quelques secondes. Si une étape échoue, toute la séquence est annulée, ce qui signifie que les attaquants ne prennent aucun risque.
L’exploit de Bunni illustre parfaitement ce schéma. The attacker used flash loans to borrow tokens, a exécuté des swaps pour manipuler les prix des pools, réalisé de nombreux micro-retraits pour exploiter des erreurs d’arrondi, puis remboursé les prêts et est reparti avec 8,4 millions de dollars. La finance traditionnelle n’a aucun équivalent : imaginez avoir accès gratuitement à 30 millions de dollars pour tenter un braquage de banque, avec la garantie qu’en cas d’échec, toute la tentative est simplement comme si elle n’avait jamais eu lieu.
Chainalysis research sur l’attaque Euler montre comment les flash loans rendent possibles des exploits autrement irréalisables. L’attaquant avait besoin de 30 millions de dollars de capital temporaire pour manipuler les ratios de prêt d’Euler. Sans flash loans, acquérir un tel capital exigerait soit une richesse personnelle substantielle, soit un blanchiment complexe des produits de hacks précédents. Les flash loans ont ramené la barrière d’entrée à presque zéro.
Le paradoxe est le suivant : interdire ou fortement restreindre les flash loans saperait les principes fondamentaux de la DeFi et éliminerait leurs usages légitimes. Les flash loans permettent l’arbitrage atomique qui maintient l’efficacité des marchés DeFi. Ils permettent au capital de circuler instantanément vers ses usages les plus productifs. Les supprimer fragmenterait la liquidité et réduirait la composabilité – précisément les caractéristiques qui rendent la DeFi innovante.
Pourtant, autoriser les flash loans revient à accepter que toute vulnérabilité, aussi exigeante en capital soit-elle pour être exploitée, devienne accessible à n’importe quel attaquant suffisamment compétent techniquement. La technologie démocratise à parts égales l’innovation et la capacité d’attaque.
Certains protocoles ont tenté des solutions intermédiaires. Des délais sur les flash loans, obligeant les emprunteurs à garder les fonds pendant plusieurs blocs, empêcheraient les attaques atomiques mais élimineraient aussi les opportunités d’arbitrage. Des listes blanches d’emprunteurs approuvés par la gouvernance préservent la fonctionnalité pour des acteurs connus, mais contredisent l’ethos permissionless de la DeFi. Des coupe-circuits qui mettent les pools en pause lors de volatilités extrêmes peuvent limiter les dégâts mais risquent de produire de faux positifs, nuisant à l’expérience utilisateur.
Aave's documentation décrit les flash loans comme un « outil puissant » qui « doit être utilisé avec prudence ». Ce cadrage prudent reconnaît le dilemme : l’outil en lui-même est neutre, mais ses applications vont du bénéfique au destructeur selon les intentions des utilisateurs. La DeFi ne peut pas désinventer les flash loans, et ce ne serait pas souhaitable au vu de leur utilité légitime. Les protocoles doivent plutôt être conçus en partant du principe que toute opération possible avec un capital illimité sera, tôt ou tard, tentée.
Attempts to Reinvent DeFi Security
Consciente de vulnérabilités persistantes, l’industrie DeFi a commencé à expérimenter de nouvelles approches de sécurité qui vont au-delà des audits traditionnels.
Real-Time Threat Monitoring
Forta Network représente le fer de lance de la surveillance continue. Plutôt que d’auditer le code une fois avant le déploiement,Forta utilise un réseau décentralisé de robots de sécurité qui surveillent les transactions blockchain en temps réel à la recherche de schémas suspects. Lorsqu’une activité inhabituelle se produit – par exemple un flash loan suivi d’une vidange rapide d’un pool – les robots de Forta déclenchent des alertes à destination des équipes de protocole et des utilisateurs.
Cette approche part du principe que des vulnérabilités existeront toujours et se concentre sur la détection et la réponse rapides. Si les exploits peuvent être identifiés en quelques secondes ou minutes plutôt qu’en heures, les protocoles peuvent mettre leurs opérations en pause et limiter les dégâts. Plusieurs protocoles intègrent désormais la surveillance Forta comme couche de sécurité standard.
La difficulté consiste à distinguer l’activité malveillante de l’usage légitime mais atypique. Les faux positifs qui entraînent une pause inutile des opérations d’un protocole érodent la confiance des utilisateurs et la fonctionnalité. Le calibrage des algorithmes de détection exige un affinage continu à mesure que les attaquants font évoluer leurs techniques.
Disjoncteurs et fonctions de pause
Les smart contracts modernes intègrent de plus en plus des fonctions de « pause » qui gèlent les opérations lorsqu’une anomalie survient. Ces disjoncteurs peuvent être déclenchés manuellement par les équipes du protocole ou automatiquement sur la base de seuils prédéfinis – volumes d’échange inhabituels, variations rapides de liquidité, ou reconnaissance de schémas indiquant une attaque.
La réponse de GMX à son exploit a consisté à mettre immédiatement en pause les fonctionnalités affectées après détection. Bien que cela n’ait pas empêché la perte initiale, cela a stoppé les dégâts supplémentaires et donné à l’équipe le temps de négocier avec l’attaquant. Les disjoncteurs transforment les exploits de faillites complètes de protocole en incidents circonscrits.
L’inconvénient est la centralisation. Les fonctions de pause nécessitent des rôles de confiance dotés de l’autorité pour arrêter les opérations, ce qui contredit l’idéal sans confiance (trustless) de la DeFi. Si les privilèges de pause sont compromis, des acteurs malveillants peuvent geler des protocoles pour manipuler les marchés ou extorquer les utilisateurs. L’équilibre entre sécurité et décentralisation demeure une tension non résolue.
Détection d’anomalies basée sur l’IA
L’intelligence artificielle et le machine learning offrent des perspectives prometteuses pour la sécurité. En entraînant des modèles sur des données historiques d’exploits et sur les schémas de comportement normal des protocoles, les systèmes d’IA peuvent identifier des transactions suspectes que des analystes humains ou des systèmes basés sur des règles pourraient manquer.
Hacken's 2025 report a relevé une augmentation de 1 025 % des exploits liés à l’IA, mais a également mis en avant le potentiel défensif de l’IA. L’IA peut analyser les interactions de contrats à grande échelle, simuler des milliers de cas limites, et apprendre de chaque nouvel exploit pour améliorer la détection.
Cependant, la sécurité basée sur l’IA fait face à ses propres défis. Le machine learning adversarial permet aux attaquants de concevoir des exploits spécifiquement destinés à contourner la détection par IA. Les biais dans les données d’entraînement peuvent créer des angles morts. Et la nature de « boîte noire » de certaines décisions d’IA rend difficile la compréhension des raisons pour lesquelles certaines transactions déclenchent des alertes.
Cadres d’audit continus
Plutôt que des audits uniques avant le lancement, des projets comme OpenZeppelin et Certora préconisent une révision de sécurité continue. La plateforme Defender d’OpenZeppelin fournit une surveillance continue et des opérations de sécurité automatisées. Certora propose des services de vérification formelle qui prouvent mathématiquement la correction du code.
La vérification formelle représente le standard ultime. En exprimant le comportement d’un contrat sous forme de spécifications mathématiques et en utilisant des prouveurs de théorèmes pour vérifier que le code respecte ces spécifications, la vérification formelle peut identifier des classes entières de bugs impossibles à trouver par des tests. La vulnérabilité Vyper de Curve, par exemple, aurait été détectée par une vérification formelle du comportement du verrou de réentrance.
La limite réside dans le coût et la complexité. La vérification formelle exige une expertise spécialisée et peut coûter des centaines de milliers de dollars. La plupart des projets DeFi ne peuvent pas se permettre des processus aussi poussés. De plus, la vérification formelle prouve seulement que le code correspond aux spécifications – si les spécifications contiennent des erreurs (comme dans le cas de Bunni), la vérification donne un faux sentiment de sécurité.
Évolution des programmes de bug bounty
Les bug bounties ont beaucoup évolué. Immunefi, la principale plateforme de bug bounty Web3, a versé plus de 100 millions de dollars aux chercheurs en sécurité à partir de 2025. Les primes pour les vulnérabilités critiques dépassent désormais régulièrement 1 à 2 millions de dollars, certains protocoles offrant jusqu’à 10 millions de dollars pour les découvertes les plus graves.
Le cas GMX illustre une tendance émergente : les protocoles offrent rétroactivement des primes aux exploitants eux‑mêmes. Plutôt que de poursuivre les attaquants par la voie judiciaire – coûteuse, lente, et souvent vaine compte tenu de la nature pseudonyme des cryptomonnaies – les protocoles proposent des accords « white hat ». Rendre 90 % des fonds volés, conserver 10 % comme prime, ne faire face à aucune conséquence légale.
Cette approche pragmatique part du constat que la récupération de fonds par les moyens traditionnels réussit rarement. Chainalysis data montre qu’environ seulement 10 % des crypto volées sont récupérées par les forces de l’ordre. Traiter les attaquants sophistiqués comme des chasseurs de bugs plutôt que comme des criminels améliore significativement les taux de récupération.
Les critiques soutiennent que cela incite à l’exploitation. Pourquoi chercher des bugs à signaler pour des primes modérées quand on peut voler des millions et négocier la restitution contre 10 % ? Le contre‑argument est que les attaquants sophistiqués peuvent déjà exploiter des vulnérabilités et blanchir les fonds via des mixers comme Tornado Cash. La prime ne fait qu’offrir une porte de sortie qui profite aux deux parties.
La Blockchain Security Alliance
La coordination industrielle par le biais de groupes comme la Blockchain Security Alliance vise à partager le renseignement sur les menaces et les bonnes pratiques entre protocoles. Lorsqu’un protocole subit un exploit, la diffusion rapide des détails de l’attaque permet aux autres de vérifier si des vulnérabilités similaires existent dans leur code.
Cette approche collective considère la sécurité de la DeFi comme un bien commun nécessitant coopération plutôt que compétition. Toutefois, la coordination reste limitée. Les protocoles retiennent souvent les détails des exploits par crainte d’attaques par imitation ou de dommages réputationnels. Construire un niveau de confiance suffisant pour un partage d’information réellement ouvert entre protocoles concurrents s’avère difficile.
L’effet Uniswap V4 : hooks personnalisés, risques personnalisés
Le lancement d’Uniswap V4 fin 2024 a représenté un changement de paradigme dans l’architecture des DEX – et dans les considérations de sécurité. The introduction of hooks permet une personnalisation infinie des pools de liquidité, en autorisant les développeurs à injecter une logique personnalisée à des moments clés du cycle de vie d’un pool : avant les swaps, après les swaps, avant l’ajout de liquidité, après le retrait de liquidité, et plus encore.
Ce pouvoir libère d’immenses possibilités. Les développeurs peuvent créer des structures de frais dynamiques qui s’ajustent en fonction de la volatilité. Ils peuvent implémenter des courbes de prix personnalisées, des ordres à cours limité, des market makers à moyenne temporelle pondérée, des optimisations de liquidité concentrée, et des stratégies complexes auparavant impossibles dans les teneurs de marché automatisés. Chaque pool devient programmable, pas seulement configurable.
Bunni illustrait ce potentiel. Construit sur les hooks d’Uniswap V4, le Liquidity Distribution Function de Bunni tentait d’optimiser automatiquement les rendements pour les fournisseurs de liquidité en allouant dynamiquement le capital aux plages de prix à fort volume. L’innovation était réelle – Bunni's technology attracted $60 million in TVL avant l’exploit – mais la complexité s’est révélée fatale.
Security firm Hacken's analysis of hooks identifie plusieurs catégories de vulnérabilités introduites par cette architecture :
Risques de configuration : Une mauvaise configuration des permissions des hooks peut conduire à des swaps échoués, des conditions de déni de service ou des comportements inattendus. Les hooks doivent spécifier correctement les points du cycle de vie qu’ils gèrent. Des erreurs peuvent empêcher les utilisateurs d’accéder aux pools ou permettre des accès non autorisés.
Gestion des deltas : Uniswap V4 utilise un mécanisme de comptabilité personnalisé où les hooks renvoient des « deltas » – des changements de solde qui affectent l’exécution du swap. Des calculs de delta incorrects peuvent entraîner une mauvaise allocation des fonds, permettre le vol via manipulation ou faire échouer les swaps. La précision mathématique requise dépasse le développement de smart contracts habituel.
Hooks asynchrones : Certains hooks prennent la pleine garde des actifs pendant les opérations plutôt que de simplement modifier des paramètres. Ces « hooks asynchrones » introduisent des risques de garde – si le contrat du hook est compromis, les fonds sont directement accessibles. Uniswap traditionnel maintenait la garde des utilisateurs tout au long des swaps. Les hooks peuvent rompre cette propriété de sécurité.
Contrôle d’accès : Les hooks peuvent inclure des fonctions privilégiées – pause, upgrade, modification de paramètres. Si les contrôles d’accès sont faibles ou si les clés sont compromises, des attaquants peuvent injecter une logique malveillante ou voler des fonds. The CertiK analysis note que les hooks évolutifs détenant des fonds d’utilisateurs créent un risque particulier si les autorités de mise à niveau sont compromises.
Explosion de composabilité : Les hooks peuvent interagir avec des contrats externes, créant des chaînes de dépendances. Une vulnérabilité dans n’importe quel système externe peut se propager via le hook jusqu’au pool de base. La surface d’attaque se multiplie avec chaque point d’intégration.
L’échec de Bunni provenait de la complexité de la gestion des deltas dans sa logique personnalisée de distribution de liquidité. L’erreur d’arrondi dans le calcul des retraits représentait précisément le type d’erreur mathématique subtile qui devient catastrophique à grande échelle. L’audit traditionnel a eu du mal à détecter cela car les hooks représentent de nouveaux schémas de code sans bases de données de vulnérabilités établies comme référence.
Uniswap Foundation's V4 documentation met en avant les considérations de sécurité, mais reconnaît que les développeurs de hooks sont responsables de leurs implémentations. Les contrats cœur d’Uniswap V4 ont fait l’objet de neuf audits indépendants et d’un programme de bug bounty de 15,5 millions de dollars. La couche de base est sécurisée. Mais les hooks construits au‑dessus, comme Bunni, doivent atteindre leur propre niveau de sécurité – un défi pour lequel de nombreuses équipes manquent de ressources.to meet.
La prolifération des protocoles basés sur des hooks crée une longue traîne de petits projets, chacun avec une logique personnalisée nécessitant un audit individuel. Cela fragmente l’attention portée à la sécurité sur des dizaines voire des centaines d’implémentations au lieu de la concentrer sur quelques protocoles centraux. Cette diversité permet l’innovation mais multiplie les risques.
Certains chercheurs en sécurité prévoient que les hooks déclencheront une nouvelle vague d’exploits en 2025 et 2026, à mesure que les développeurs apprendront à leurs dépens les leçons d’une bonne mise en œuvre. D’autres estiment que la standardisation de modèles de hooks courants – via des bibliothèques comme les implémentations de hooks d’OpenZeppelin – finira par créer des briques sécurisées qui réduiront le risque lié à l’innovation.
Dimensions juridiques, assurantielles et politiques
À mesure que les pertes en DeFi s’accumulent, des mécanismes de régulation et de transfert de risque émergent, même si leur efficacité reste incertaine.
Pression réglementaire
Le règlement européen sur les marchés de crypto-actifs (MiCA), pleinement entré en vigueur en 2024, établit des exigences d’agrément et des normes opérationnelles pour les prestataires de services en crypto-actifs. Bien que MiCA vise principalement les plateformes d’échange centralisées et les dépositaires, ses dispositions relatives à la résilience opérationnelle et aux normes de sécurité créent une pression indirecte sur les protocoles DeFi.
Le Groupe d’action financière (GAFI/FATF) a mis à jour ses recommandations en insistant sur le fait que les protocoles DeFi présentant des éléments de contrôle centralisés – comme des clés d’admin ou des switches de frais – devraient être régulés de manière similaire aux intermédiaires financiers traditionnels. Cela crée une insécurité juridique pour les projets qui tentent de concilier sécurité (nécessitant un certain contrôle administratif) et évitement réglementaire (nécessitant une décentralisation totale).
Les régulateurs américains ont été moins cohérents, la SEC et la CFTC se disputant la juridiction tout en fournissant peu de clarté sur les exigences de conformité. Cette ambiguïté réglementaire décourage paradoxalement l’investissement dans la sécurité : si le statut légal d’un protocole est incertain, les fondateurs hésitent à investir dans la conformité et la sécurité alors que le modèle économique lui-même pourrait être jugé illégal.
Assurance on-chain
Nexus Mutual, Sherlock Protocol et Risk Harbor ont été pionniers de l’assurance décentralisée pour les risques liés aux smart contracts. Les utilisateurs peuvent acheter une couverture contre des exploits spécifiques de protocoles. En cas d’exploit, les indemnisations sont payées à partir de pools d’assurance financés par les primes et les apports en capital.
Ces protocoles d’assurance font face à leurs propres défis. Tarifer précisément le risque dans un environnement en évolution rapide, avec peu de données historiques, s’avère difficile. Les ratios de pertes de Nexus Mutual ont été volatils – certaines périodes avec peu de sinistres, d’autres avec des indemnisations massives mettant à rude épreuve les réserves des pools.
Le modèle de Sherlock tente de résoudre ce problème en faisant miser du capital par des experts en sécurité agissant comme assureurs. Les experts auditent les protocoles et engagent leurs propres fonds, pariant sur la justesse de leur évaluation. S’ils manquent des vulnérabilités qui mènent à des exploits, leur mise sert à couvrir les sinistres. Cela aligne les incitations, comme le démontre le paiement de 4,5 millions de dollars de Sherlock à Euler – les stakers de Sherlock ont supporté la perte pour avoir manqué la vulnérabilité lors de l’audit.
Cependant, l’assurance reste un marché de niche. Selon les données de DeFi Llama, la valeur totale verrouillée dans les protocoles d’assurance DeFi n’est que d’environ 500 millions de dollars – moins de 0,1 % de la TVL totale de la DeFi. La plupart des utilisateurs restent non assurés, par ignorance, par coût, ou parce qu’ils pensent que les exploits ne les toucheront pas.
Questions de responsabilité juridique
Une question philosophique et juridique plane : les protocoles DeFi doivent-ils être tenus légalement responsables de négligence ? Les institutions financières traditionnelles font face à des poursuites et à des sanctions réglementaires en cas de défaillances de sécurité. Les développeurs qui déploient un code audité mais finalement vulnérable devraient-ils faire face à une responsabilité similaire ?
Les arguments en faveur de la responsabilité incluent la protection des utilisateurs et l’incitation à investir dans la sécurité. Si les développeurs ne subissent aucune conséquence pour une conception négligente, ils externalisent les risques sur les utilisateurs. La responsabilité juridique internaliserait ces coûts, encourageant des pratiques de sécurité plus rigoureuses.
Les arguments contre incluent le risque de freiner l’innovation et de contredire les principes de l’open source. Les protocoles DeFi déclinent souvent explicitement toute responsabilité via des conditions d’utilisation avertissant les utilisateurs des risques. Rendre les développeurs responsables de vulnérabilités involontaires pourrait détourner les talents du Web3. De plus, de nombreux protocoles sont véritablement décentralisés, sans entité juridique claire à tenir responsable.
L’affaire Bunni illustre cette tension. L’équipe de six personnes a passé des années à développer le protocole, a réalisé des audits professionnels et a perdu son propre capital investi lors de l’exploit. Doit-elle faire face à des conséquences juridiques pour une erreur de logique que plusieurs experts ont manquée ? Ou bien tenter de les tenir responsables d’une erreur honnête, tout en opérant à la frontière de la technologie, revient-il simplement à punir l’innovation ?
Ces questions restent largement sans réponse, les systèmes juridiques peinant à adapter des cadres vieux de plusieurs siècles aux réseaux décentralisés.
L’avenir de la sécurité on-chain
Pour l’avenir, plusieurs tendances pourraient remodeler la sécurité DeFi au cours de la prochaine décennie :
Normes de sécurité vérifiables
Le secteur s’oriente vers la « correction prouvable » – l’usage de la vérification formelle et de preuves mathématiques pour garantir le comportement des contrats plutôt que de se fier uniquement aux tests. Runtime Verification et Certora développent des outils qui rendent la vérification formelle accessible à davantage de projets.
On peut imaginer un futur où les contrats embarquent des preuves cryptographiques de certaines propriétés de sécurité. Les utilisateurs pourraient vérifier ces garanties avant d’interagir, un peu comme les certificats SSL qui prouvent l’identité d’un site Web. Les protocoles dépourvus de telles preuves feraient face au scepticisme du marché, créant une pression pour adopter des méthodes de vérification rigoureuses.
Cela exige une standardisation des propriétés de sécurité et des méthodologies de vérification. Des organisations comme la Fondation Ethereum travaillent sur ces standards, mais une adoption généralisée reste à plusieurs années.
Couches de sécurité décentralisées
Une « couche de sécurité DeFi » – un méta-protocole surveillant d’autres protocoles – a été proposée pour fournir une supervision systématique. Au lieu que chaque protocole implémente sa propre sécurité, une infrastructure partagée détecterait les anomalies, coordonnerait les réponses et faciliterait le partage d’informations.
On peut la comparer à l’infrastructure de gestion des risques de la finance traditionnelle : agences de notation, auditeurs, régulateurs et assureurs fournissant des fonctions de sécurité superposées. La DeFi a besoin de défenses multi-couches similaires, adaptées à son contexte décentralisé.
Les défis incluent le fait de s’assurer que cette couche de sécurité ne devienne pas un point de défaillance unique, de maintenir la décentralisation tout en offrant une supervision efficace, et de créer des modèles économiques viables pour une telle infrastructure.
Sécurité évolutive par la concurrence
Les forces du marché pourraient, au final, améliorer la sécurité plus efficacement que la régulation. À mesure que les utilisateurs se sophistiquent et que les pertes liées aux exploits augmentent, le capital devrait se diriger vers les protocoles avec des historiques de sécurité solides. Les protocoles qui investissent massivement dans la sécurité gagnent un avantage concurrentiel pour attirer une liquidité soucieuse du risque.
Ce processus est déjà visible. Aave, qui a évité les exploits majeurs grâce à des pratiques de sécurité rigoureuses, détient une TVL significativement plus élevée que des concurrents au passif de sécurité plus chargé. Les utilisateurs consultent de plus en plus les rapports d’audit et les évaluations de sécurité avant d’engager leur capital.
Cependant, ce processus est lent et douloureux, nécessitant de nombreux échecs catastrophiques pour ancrer les leçons. L’industrie pourrait ne pas survivre à un exploit vraiment massif – un événement unique effaçant des milliards et détruisant la confiance du grand public dans la viabilité de la DeFi.
Défense alimentée par l’IA
L’intelligence artificielle jouera probablement un rôle croissant aussi bien dans l’attaque que dans la défense. L’IA peut analyser le code des contrats pour y déceler des vulnérabilités, simuler des scénarios d’exploitation, surveiller les transactions à la recherche de schémas suspects et même corriger automatiquement certaines classes de vulnérabilités.
Inversement, les attaquants utiliseront l’IA pour découvrir des vulnérabilités et concevoir des exploits. Cela crée une course aux armements où les deux camps utilisent des outils de plus en plus sophistiqués. L’équilibre pourrait ne jamais se stabiliser, oscillant au gré des nouvelles capacités d’IA déployées tour à tour par les défenseurs et les attaquants.
Transition vers une conception consciente du risque
Le changement le plus fondamental nécessaire est peut-être culturel : accepter que la sécurité parfaite est impossible et concevoir des systèmes résilients face aux défaillances inévitables.
Cela implique :
- Limiter le rayon d’explosion : si un pool est exploité, les autres doivent rester intacts
- Dégradation progressive : les protocoles doivent échouer de manière sûre plutôt que catastrophique
- Mécanismes de reprise rapide : procédures pour dégeler des fonds gelés ou redistribuer les pertes
- Communication transparente du risque : les utilisateurs ont besoin de comprendre clairement ce qu’ils risquent
L’éthos DeFi a eu tendance à considérer « trustless » comme « sécurisé par défaut ». Une approche plus mature voit « trustless » comme « transparent sur les hypothèses de confiance ». Les utilisateurs peuvent alors prendre des décisions informées sur les risques qu’ils acceptent.
Leçons de Bunni et au‑delà
La fermeture du DEX Bunni représente plus qu’une entrée supplémentaire dans la longue liste des échecs DeFi. Elle symbolise l’écart persistant entre l’ambition et l’exécution qui caractérise la finance décentralisée en 2025.
L’histoire du protocole contient plusieurs leçons édifiantes. Premièrement, innovation et risque sont indissociables. La fonction de distribution de liquidité (Liquidity Distribution Function) de Bunni représentait un véritable progrès dans la conception des teneurs de marché automatisés. La complexité qui la rendait innovante la rendait aussi vulnérable. Il n’existe pas de voie claire vers l’innovation sans accepter un risque accru – une vérité que l’industrie doit reconnaître ouvertement plutôt que de la masquer derrière des badges d’audit.
Deuxièmement, les audits offrent une protection limitéeprotection. Trail of Bits et Cyfrin sont des sociétés respectées qui ont sécurisé des milliards de valeur à travers de nombreux protocoles. Leur incapacité à détecter la vulnérabilité de Bunni ne reflète pas de l’incompétence, mais les limites fondamentales de la méthodologie d’audit. Les bugs sémantiques au niveau logique continueront d’échapper aux audits traditionnels. L’industrie a besoin de couches de sécurité supplémentaires au-delà des audits.
Troisièmement, l’économie de la sécurité DeFi reste brisée. Bunni ne pouvait pas se permettre les six à sept chiffres nécessaires pour relancer en toute sécurité. Pourtant, l’industrie perd collectivement des milliards à cause des exploits. Ce décalage suggère une défaillance systémique du marché, où les projets individuels sous‑investissent dans la sécurité même lorsque les pertes agrégées justifieraient des investissements massifs. Les solutions nécessiteront probablement une forme d’action collective – infrastructure de sécurité partagée, assurance mutualisée ou exigences réglementaires.
Quatrièmement, les facteurs humains dominent les facteurs techniques. L’équipe de Bunni était talentueuse et animée de bonnes intentions. Elle a suivi les bonnes pratiques et investi dans des audits. L’échec ne relève ni de la malveillance ni de l’incompétence, mais de la difficulté inhérente à construire des systèmes complexes sans erreurs. Blâmer des individus manque la cible – le système lui‑même génère des vulnérabilités plus vite que les humains ne peuvent les identifier et les corriger.
As Doug Colkitt noted about the KyberSwap exploit, certains attaques atteignent un tel niveau de sophistication qu’il peut être impossible de les prévenir sans changements fondamentaux d’architecture. L’attaquant de KyberSwap a démontré une expertise rivalisant avec celle des développeurs du protocole. Quand attaquants et défenseurs possèdent des compétences équivalentes, les défenseurs font face à un désavantage asymétrique – ils doivent anticiper toutes les attaques possibles tandis que les attaquants n’ont besoin de trouver qu’un seul angle négligé.
Le schéma plus large des exploits de 2025 révèle plusieurs thèmes récurrents :
Les flash loans comme multiplicateurs de force : Pratiquement chaque exploit majeur a utilisé des flash loans pour démultiplier l’impact. Tant que la DeFi n’aura pas développé de meilleurs mécanismes pour empêcher l’abus des flash loans sans éliminer les usages légitimes, ce vecteur d’attaque persistera.
La composabilité comme risque composé : Les protocoles qui s’intègrent avec de nombreux systèmes externes héritent de toutes leurs vulnérabilités. La contagion Euler affectant Balancer, Angle et Idle Finance a montré comment une DeFi interconnectée amplifie les pertes. De meilleures formes d’isolation entre protocoles et des modes de défaillance plus robustes sont nécessaires.
Le problème de confiance dans le compilateur : La vulnérabilité de Vyper sur Curve a montré que même un code de protocole parfait peut échouer si les outils sous‑jacents contiennent des bugs. L’industrie doit investir dans la sécurisation de toute la pile – compilateurs, bibliothèques, frameworks de développement – et pas seulement des contrats applicatifs.
La réponse rapide compte : La récupération réussie de GMX via une prime de white hat et la divulgation proactive de vulnérabilités par Balancer ont démontré que des réponses rapides et transparentes peuvent limiter les dégâts et maintenir la confiance des utilisateurs. Les protocoles ont besoin de procédures de gestion de crise et de stratégies de communication préparées à l’avance.
La mémoire du marché est courte : Malgré les exploits répétés, la DeFi continue de croître. Total value locked recovered to over $90 billion by mid-2025 malgré des milliards de pertes. Cela suggère soit que les utilisateurs acceptent le risque comme inhérent à l’écosystème, soit que la plupart des participants manquent de conscience historique des échecs passés. Les deux possibilités sont préoccupantes pour la santé à long terme de l’écosystème.
En cherchant à établir des repères, le tableau est mitigé. Hayden Adams, le fondateur d’Uniswap, a souligné que la sécurité doit devenir une « préoccupation de première classe » plutôt qu’une réflexion a posteriori. Pourtant, sa propre architecture V4, bien qu’amplement auditée, introduit de nouvelles surfaces d’attaque via les hooks. Innovation et risque restent couplés.
Samczsun, probablement le chercheur en sécurité le plus respecté du Web3, a répété que la complexité de la DeFi a dépassé son infrastructure de sécurité. Son travail de découverte de vulnérabilités dans de grands protocoles montre à la fois l’ampleur des problèmes et à quel point des chercheurs en sécurité hautement qualifiés sont devenus essentiels.
La question ultime reste sans réponse : la DeFi peut‑elle un jour être vraiment sûre, ou son ouverture est‑elle fondamentalement incompatible avec la sécurité ? La finance traditionnelle atteint la sécurité par le filtrage, la régulation et le contrôle centralisé. La DeFi aspire à l’ouverture, au caractère permissionless et à la décentralisation. Ces objectifs peuvent être mathématiquement contradictoires – à mesure que les systèmes deviennent plus ouverts et composables, ils deviennent nécessairement plus vulnérables.
La vraie question n’est peut‑être pas « La DeFi peut‑elle être rendue sûre ? » mais plutôt « Quel niveau d’insécurité est acceptable pour les bénéfices que la DeFi apporte ? » En 2025, les utilisateurs continuent de choisir la DeFi malgré les risques connus parce qu’ils valorisent la résistance à la censure, l’accès mondial et de nouveaux primitifs financiers. Ils prennent la décision consciente (ou parfois inconsciente) d’accepter une certaine vulnérabilité comme prix de ces avantages.
Pour que la DeFi mûrisse, les utilisateurs ont besoin d’informations plus claires sur ce qu’ils acceptent. Les protocoles devraient afficher des métriques de sécurité de façon visible : rapports d’audit, temps écoulé depuis le dernier examen de sécurité, TVL en risque selon les cas limites connus, couverture d’assurance disponible. Les marchés pourraient alors fixer le prix du risque de manière appropriée plutôt que de considérer tous les protocoles comme également sûrs.
Les développeurs doivent accepter que la sécurité parfaite est impossible et concevoir en intégrant l’échec. Les coupe‑circuits, l’isolation des fonds, les voies de mise à jour et les mécanismes de récupération doivent être des fonctionnalités standard, pas des options. La question se déplace de « Comment empêcher tous les exploits ? » vers « Comment minimiser les dégâts lorsque les exploits se produisent inévitablement ? »
Conclusion : Ce qui doit vraiment changer
Les 3,1 milliards de dollars perdus au premier semestre 2025 représentent plus que des chiffres – ils représentent des vies bouleversées, une confiance détruite et une innovation étouffée. Chaque exploit éloigne un peu plus l’adoption grand public et renforce les arguments en faveur d’une régulation lourde qui pourrait tuer l’innovation.
Pour les utilisateurs, la prescription est claire mais frustrante : supposer qu’il existe des vulnérabilités dans chaque protocole, diversifier les avoirs sur plusieurs plateformes, rester conscient de l’historique des exploits, utiliser une assurance lorsque disponible et ne jamais risquer des fonds que vous ne pouvez pas vous permettre de perdre. Dans son état actuel, la DeFi s’adresse aux utilisateurs tolérants au risque qui comprennent qu’ils participent à une expérimentation continue.
Pour les développeurs, le défi est d’accepter que la sécurité ne peut pas être une réflexion secondaire. Les protocoles doivent allouer des budgets substantiels – peut‑être 20 à 30 % du coût total de développement – aux mesures de sécurité. Cela inclut des audits multiples et indépendants, la vérification formelle lorsque c’est possible, la surveillance continue, des capacités de réponse rapide et des mises à jour de sécurité régulières. Les projets qui ne peuvent pas se le permettre devraient se demander s’ils doivent exister.
Pour l’industrie dans son ensemble, la coordination est essentielle. Une infrastructure de sécurité partagée, des méthodologies d’audit standardisées, une communication ouverte sur les vulnérabilités et des mécanismes d’assurance mutualisés aideraient à résoudre les défaillances de marché qui laissent les projets individuels sous‑investir dans la sécurité. Une certaine centralisation des fonctions de sécurité peut être nécessaire pour obtenir une finance décentralisée qui fonctionne réellement.
Pour les régulateurs, la tentation d’imposer à la DeFi la régulation de la finance traditionnelle doit être tempérée par la reconnaissance qu’un certain niveau de risque est nécessaire à l’innovation. Une régulation intelligente se concentrerait sur les exigences de transparence, la compréhension des risques par les utilisateurs et un cadre de responsabilité lorsque la négligence est avérée. Une interdiction brutale pousserait simplement la DeFi vers des juridictions non réglementées, aggravant les choses.
La déclaration finale de l’équipe Bunni résume la tragédie : « Nous sommes une petite équipe de 6 personnes passionnées par la construction en DeFi et le fait de faire avancer l’industrie. Nous avons passé des années de nos vies et dépensé des millions de dollars pour lancer Bunni, parce que nous croyons fermement que c’est l’avenir des AMM. » Leur conviction est peut‑être juste – les automated market makers traiteront peut‑être un jour des trillions de valeur. Mais pour aller d’ici à là, il faudra résoudre des défis de sécurité qui continuent d’échapper aux esprits les plus brillants de l’industrie.
À mesure que nous avançons dans le reste de 2025 et vers 2026, la question est de savoir si la DeFi peut mûrir assez vite pour empêcher des exploits de plus en plus sophistiqués de submerger l’écosystème. La technologie qui permet une finance trustless crée simultanément de nouvelles vulnérabilités que les systèmes centralisés n’ont jamais affrontées. C’est peut‑être un compromis inévitable. Ou peut‑être que des percées dans la vérification formelle, la défense assistée par IA et l’infrastructure de sécurité finiront par faire pencher la balance vers la sûreté.
Ce qui est certain, c’est que la trajectoire actuelle – des milliards de pertes annuelles alors que la sécurité reste une réflexion secondaire – est intenable. La DeFi doit évoluer ou devenir sans importance. Le choix appartient aux développeurs, aux utilisateurs et aux investisseurs qui déterminent collectivement si la finance décentralisée représente l’avenir financier de l’humanité ou simplement une autre expérience ratée de construction de systèmes sans confiance dans un monde où la confiance compte encore.