Les vols fréquents dans la DeFi, comment prévenir les attaques de hackers à l'ère de l'IA ?

Écrit par : systs

OpenBuild Introduction :

En avril 2026, la DeFi connaît son moment le plus sombre, avec un montant de vols mensuels dépassant 625 millions de dollars, atteignant un record historique, avec seulement deux attaques contre Drift et KelpDAO qui ont englouti près de 580 millions de dollars. L’émergence de l’IA a complètement inversé le paysage de la défense et de l’attaque, car ce qui prenait auparavant des semaines d’efforts humains pour détecter des vulnérabilités dans les protocoles peut désormais être réalisé en quelques heures par de grands modèles, faisant chuter les coûts d’attaque et augmenter considérablement la surface d’attaque, de plus en plus de protocoles devenant des cibles.

Les attaquants professionnels, disposant de ressources importantes et spécialisés dans la stratégie à long terme, scrutent chaque fissure dans les protocoles, tandis que les équipes ordinaires, dispersées et en défense passive, sont vulnérables. Seule une obsession extrême, une préparation anticipée de défenses complètes, un contrôle strict des pertes et des plans d’urgence peuvent permettre de survivre dans cette guerre de défense et d’attaque dominée par l’IA. Voici le contenu original, compilé et organisé par OpenBuild.

Après avoir développé le projet @openforage et étudié de nombreux incidents d’attaques historiques sur des protocoles DeFi, je suis devenu méfiant face aux attaquants de niveau étatique. Ces adversaires sont expérimentés, disposent de ressources abondantes et excellent dans la stratégie à très long terme ; comme des antagonistes de haut niveau, ils scrutent chaque fissure dans votre protocole et votre infrastructure pour exploiter des vulnérabilités. Les équipes de protocoles ordinaires, dispersées, doivent gérer leur activité tout en assurant la sécurité, ce qui est impossible à faire pleinement. Je ne me prétends pas expert en sécurité, mais ayant dirigé des équipes dans des environnements à haut risque (expérience militaire et gestion de fonds importants dans de grandes institutions financières), je possède une expérience pratique mature en plans de gestion des risques et en réponse aux urgences. Je suis convaincu : seul un paranoïaque peut survivre. Aucune équipe ne commence avec une attitude de « sécurité superficielle », mais les attaques restent fréquentes. Nous devons faire mieux.

/ 01 L’ère de l’IA : tout a changé

Les attaques de hackers sont courantes, mais leur fréquence a récemment explosé. Au premier trimestre 2026, le nombre d’attaques de hackers dans la DeFi a atteint un sommet historique, et au second trimestre, alors que celui-ci vient de commencer, on s’attend à dépasser le record du trimestre précédent.

Mon point central est : l’IA a considérablement réduit le coût de la détection et de l’exploitation des vulnérabilités, tout en élargissant la surface d’attaque. Vérifier manuellement la configuration de centaines de protocoles prend des semaines ; avec les derniers grands modèles, cela ne prend que quelques heures. Cela bouleverse la logique fondamentale de la défense et de la réponse aux incidents en matière de sécurité des protocoles. Les protocoles traditionnels, nés avant l’essor de l’IA, utilisant des méthodes classiques, sont désormais exposés à un risque accru d’attaques ciblées.

/ 02 Réflexion sur la surface d’attaque et la défense en couches

Sur le terrain, il n’y a que trois principales voies d’attaque pour les hackers DeFi :

• Équipe opérationnelle du protocole
• Contrats intelligents et infrastructure sous-jacente
• Limites de confiance des utilisateurs (domaines, réseaux sociaux, etc.)

Après avoir identifié ces surfaces d’attaque, on peut construire un système de défense en cinq couches :

Prévention préalable : établir des processus standardisés, strictement appliqués, pour réduire au maximum la probabilité d’être compromis.

Atténuation des pertes : en cas d’échec de la prévention, contrôler rapidement l’ampleur des pertes.

Arrêt d’urgence : en situation de forte pression, personne ne peut prendre la meilleure décision. En cas d’attaque, activer immédiatement la coupure d’urgence, geler les actifs pour éviter une aggravation, tout en permettant à l’équipe de réfléchir calmement.

Récupération du contrôle : si un module malveillant ou une composante compromise est hors de contrôle, le déconnecter ou le remplacer directement.

Rétablissement post-incident : récupérer les actifs volés. En amont, collaborer avec des partenaires pour geler les fonds, annuler des transactions, aider à l’enquête et à la traçabilité.

/ 03 Principes fondamentaux

Les principes suivants guident la mise en œuvre de cette défense en couches.

Renforcement par l’IA à la pointe

Utiliser pleinement les modèles avancés pour scanner les vulnérabilités du code et des configurations, mener des tests de pénétration rouge/bleu sur une large surface d’attaque : détecter activement les vulnérabilités front-end, vérifier si elles permettent d’accéder au back-end. Les attaquants feront forcément de même ; la défense peut utiliser des outils comme pashov, nemesis, ainsi que des plateformes de sécurité IA telles que Cantina (Apex) ou Zellic (V12) pour effectuer un premier tri du code avant l’audit officiel.

Le temps et le processus sont eux-mêmes des défenses

Toute opération à risque doit suivre un processus en plusieurs étapes avec un mécanisme de verrouillage temporel. En cas d’anomalie, prévoir une intervention humaine et un gel des actifs. Autrefois, l’industrie résistait à ces verrouillages et processus en plusieurs étapes, trouvant cela trop lourd et nuisible à l’efficacité. Aujourd’hui, la situation a changé : l’IA peut contourner automatiquement ces processus, rendant leur maintien inutile.

Conception d’invariants

Les contrats intelligents peuvent définir des invariants fondamentaux inviolables : si une règle est brisée, tout le protocole devient invalide. @openforage concentre ses invariants sur la solvabilité : actifs dans le coffre + actifs déployés ≥ créances impayées. En général, il suffit de définir quelques invariants clés ; éviter de coder en dur plusieurs vérifications dans chaque fonction, ce qui alourdirait le code et le rendrait difficile à maintenir.

Équilibre des pouvoirs

Beaucoup d’attaques proviennent de la fuite de clés privées ou de la compromission de multi-signatures. Une configuration d’autorisation raisonnable doit permettre, même si la multi-signature est compromise, de limiter rapidement les dégâts et de mettre le protocole en mode stable sous gouvernance. Deux leviers principaux :

• Autorisations de gouvernance : décisions clés du protocole
• Autorisations d’urgence : pour restaurer la stabilité, sans pouvoir supplanter la gouvernance

Prévoir l’inévitable

Il faut établir une conscience de base : aucune équipe, aussi professionnelle soit-elle, n’est à l’abri d’une attaque. Les contrats ou composants peuvent échouer, l’équipe peut être victime d’une ingénierie sociale, une mise à jour peut introduire de nouvelles vulnérabilités. En adoptant cette mentalité, le contrôle des flux, la gestion des risques et l’arrêt d’urgence deviennent indispensables : limiter chaque perte à 5-10 %, geler les fonds, puis élaborer une réponse. En situation critique, éviter les décisions hâtives.

Planifier à l’avance

La meilleure réponse à une attaque est la préparation avant qu’elle ne se produise. Formaliser et documenter autant que possible les plans d’urgence, faire des exercices répétés pour éviter la panique lors de l’incident. À l’ère de l’IA, il faut des outils et des algorithmes capables de rassembler instantanément toutes les informations, générer des résumés synthétiques et détaillés, et les transmettre en temps réel aux décideurs.

La survie est la priorité ultime

Il n’est pas nécessaire de viser la perfection absolue, mais il faut assurer sa survie. Aucun système n’est invulnérable dès sa mise en ligne ; seul un processus de révision et d’amélioration continue permet de devenir une architecture antifragile. Ne pas avoir été attaqué ne signifie pas être sécurisé par nature ; le moment le plus calme est souvent celui où le risque est le plus élevé.

/ 04 Système de prévention préalable

Conception des contrats intelligents

Après avoir défini les invariants fondamentaux, les intégrer dans la logique de vérification en temps réel, en sélectionnant soigneusement les règles réellement nécessaires. Recommandation : suivre le modèle FREI-PI (Fonction - Impact - Interaction externe - Invariant du protocole) : toutes les fonctions impliquant des actifs doivent vérifier leurs invariants clés à la fin de leur exécution. De nombreuses attaques exploitant des arbitrages flash, des manipulations d’oracles ou des défaillances de capacité de paiement entre fonctions peuvent être bloquées par cette vérification en fin de fonction.

Systèmes de test robustes

Fuzzing avec état : générer des séquences d’appels aléatoires à toutes les interfaces publiques du protocole, en vérifiant chaque étape contre les invariants. La majorité des attaques on-chain sont des attaques combinant plusieurs transactions ; le fuzzing avec état est la seule méthode fiable pour découvrir ces vulnérabilités avant les attaquants. Écrire des tests d’invariants pour garantir leur validité dans toutes les séquences générées, couplés à une vérification formelle pour prouver leur invariance dans tous les états accessibles. Les invariants clés doivent faire l’objet d’une vérification formelle.

Oracles et dépendances externes

La complexité est l’ennemi de la sécurité. Chaque couche supplémentaire d’interdépendance externe augmente la surface d’attaque. Si vous développez des composants fondamentaux, confiez la confiance à l’utilisateur ; si vous ne pouvez pas supprimer la dépendance, utilisez une décentralisation multi-source pour éviter un point de défaillance unique. L’audit doit couvrir les scénarios de défaillance des oracles et dépendances externes, avec des limites de quota pour limiter les dégâts en cas d’anomalie. L’attaque de KelpDAO récente illustre ce point : le projet utilisait la configuration LayerZero default requiredDVNCount=1, non auditée, ce qui a permis une faille exploitée par des infrastructures hors audit.

Cartographie complète de la surface d’attaque

Les vecteurs d’attaque connus dans la DeFi sont déjà bien documentés. Vérifier chaque point pour voir s’il s’applique à votre protocole, et mettre en place des mesures de contrôle correspondantes. Développer une capacité interne de red/blue teaming, en forçant l’IA à rechercher activement des vulnérabilités dans le protocole ; c’est désormais une exigence minimale dans l’industrie.

Autorisations d’urgence intégrées

Dans un modèle de gouvernance par vote, le pouvoir est initialement concentré dans la multi-signature de l’équipe, puis progressivement décentralisé. Même avec une distribution large de tokens, les permissions sont souvent concentrées dans quelques portefeuilles, voire un seul. Si ce portefeuille est compromis, le protocole s’effondre. Il est conseillé de déployer un portefeuille de gardiens, avec des permissions strictement limitées : seul le suspendre le protocole, et en cas extrême, nécessiter une majorité 4/7 pour transférer les permissions d’urgence vers un portefeuille de secours préconfiguré. Les gardiens ne peuvent pas initier ou voter des propositions de gouvernance.

Ainsi, le protocole dispose d’une couche d’urgence indépendante : capable de restaurer la stabilité, sans pouvoir supplanter la gouvernance native. La probabilité que plus de 4/7 des gardiens soient compromis simultanément est faible, étant donné la dispersion des adresses. Une fois la gouvernance mature et décentralisée, cette couche d’urgence pourra être progressivement désactivée.

Architecture des portefeuilles et clés

Les portefeuilles multi-signatures sont la norme, avec au minimum une configuration 4/7, personne ne contrôlant seul les 7 clés. Effectuer des rotations discrètes des signataires. Les clés doivent être utilisées exclusivement pour leur fonction : si un appareil de signature sert aussi à la navigation, emails ou bureautique, il est considéré compromis. Utiliser plusieurs portefeuilles multi-signatures, chacun avec un rôle précis. Prévoir qu’au moins un portefeuille sera éventuellement compromis, et élaborer des plans en conséquence. En cas de menace ou de coercition, aucun individu ne doit pouvoir seul compromettre le protocole.

Plan de récompense pour vulnérabilités

Je partage l’avis de Nascent sur les programmes de bug bounty. Les protocoles disposant de ressources financières importantes devraient offrir des récompenses proportionnelles à leur TVL, voire très élevées (au moins sept chiffres). En cas d’attaques par des acteurs étatiques, la négociation de récompenses est souvent inefficace ; mais il est possible de lancer un programme de « safe harbor » pour les white hats : autoriser des white hats à sécuriser les fonds volés, en leur versant une partie en récompense, financée par les déposants.

Sélectionner des auditeurs de qualité

Je pensais que la montée en puissance des grands modèles diminuerait la valeur ajoutée des audits traditionnels, mais je modère cette opinion :

Les meilleurs auditeurs restent à la pointe. Si le protocole utilise une conception innovante, le code et ses vulnérabilités potentielles ne seront pas dans les données d’entraînement du modèle, et la puissance de calcul seule ne suffit pas à découvrir de nouvelles vulnérabilités logiques. Personne ne veut être le premier à subir une nouvelle méthode d’attaque.

Un point souvent négligé : la réputation de l’auditeur. Après un audit, si le protocole est piraté, l’auditeur a une forte motivation à aider à analyser et limiter les pertes. Établir une collaboration à long terme avec une équipe de sécurité spécialisée est une ressource précieuse.

Sécurité opérationnelle

Intégrer la sécurité opérationnelle dans les indicateurs clés de performance. Organiser régulièrement des exercices de phishing ; engager des red teams externes crédibles pour tester la résistance sociale de l’équipe. Disposer de portefeuilles matériels et appareils de secours, pouvant remplacer rapidement toute la configuration multi-signature, pour éviter la précipitation lors d’un incident.

/ 05 Atténuation des pertes

Limite maximale de pertes à la sortie des fonds

Toutes les voies de sortie des actifs doivent avoir une limite de quota ; le maximum de pertes théoriques en cas d’exploitation doit être fixé. En clair : une fonction de mint sans limite de bloc est comme un chèque en blanc pour un mint infini ; une fonction de retrait sans limite hebdomadaire permettrait de manipuler le solde. Fixer prudemment des limites strictes pour chaque canal de sortie, en équilibrant la perte maximale acceptable et une expérience utilisateur optimale. En cas de brèche, ces limites empêchent la disparition totale du protocole.

Listes blanche et noire

La plupart des protocoles disposent de listes implicites pour les interfaces, actifs ou adresses autorisées, ou de règles explicites interdisant certains comportements. Même si ces règles sont implicites, elles doivent être formalisées. Avec des listes blanche/noire clairement établies, on peut mettre en place une double étape pour changer les permissions, augmentant la friction pour l’attaquant. Celui-ci doit d’abord modifier la liste blanche ou supprimer la restriction noire, puis effectuer l’opération malveillante. Avec cette double sécurité, il doit franchir deux barrières : validation préalable (intégration / mise en ligne) et contournement des règles de sécurité (revue de risque).

/ 06 Récupération du contrôle

Surveillance automatisée par algorithme

Disposer d’un bouton d’arrêt d’urgence sans surveillance est inutile. Mettre en place un système de surveillance hors chaîne, 24/7, pour suivre en temps réel les invariants clés, avec une alerte automatique en cas d’anomalie. Les alertes doivent remonter directement aux responsables de la multi-signature, avec tout le contexte, pour une décision en quelques minutes.

Arrêt préalable, puis analyse

En cas d’attaque, la priorité est de stopper la fuite. Sur le protocole, cela signifie activer le bouton d’arrêt d’urgence (affiché en front). Préparer un script « tout arrêter en un clic » pour parcourir automatiquement tous les modules pouvant être suspendus, et exécuter l’arrêt de façon atomique. La gouvernance ne peut pas être arrêtée ; si la couche de garde peut suspendre la gouvernance, une intrusion dans cette couche verrouillera définitivement le processus de récupération.

Lancement d’un centre de réponse d’urgence

Après avoir gelé les actifs et stoppé la fuite, rassembler les membres clés préalablement désignés, créer un canal de communication dédié. Restreindre strictement la diffusion d’informations pour éviter qu’elles ne soient exploitées par des attaquants ou des acteurs malveillants. Prévoir des rôles fixes et des exercices :

• Responsable décisionnel : gestion globale
• Opérateur : exécuter scripts de défense, arrêter, etc.
• Analyste en vulnérabilités : analyser la chaîne d’attaque, identifier la cause
• Contact externe : collaborer avec partenaires
• Scribe : documenter chaque étape, décision, chronologie

Clarté des responsabilités, entraînements réguliers, pour agir selon le plan lors de l’incident, sans panique.

Anticiper les risques en chaîne

Supposer que l’attaquant possède un niveau expert : la première vulnérabilité peut n’être qu’un leurre ou une étape dans une attaque en série. L’incident peut aussi être une diversion pour induire en erreur, déclenchant une vulnérabilité plus profonde. La coupure doit faire l’objet d’une évaluation rigoureuse, en boucle fermée, sans laisser de vulnérabilités exploitables. Le protocole doit être globalement gelé, en évitant de ne couper qu’un seul module, ce qui pourrait exposer d’autres failles. Après avoir identifié la cause et la vecteur d’attaque, il faut analyser toutes les surfaces d’attaque connexes et risques en chaîne, puis tout corriger en une seule fois.

Mécanisme de rotation des successeurs préconfigurés

Les permissions doivent être remplacées uniquement par des adresses de succession préenregistrées. Je recommande un registre de successeurs préconfigurés : cela rend difficile pour un attaquant de remplacer discrètement le gardien ou le portefeuille de gouvernance par une adresse malveillante. La logique est similaire à celle des listes blanche/noire. Tous les rôles clés doivent avoir leur successeur enregistré à l’avance. La seule opération autorisée en urgence est de remplacer le rôle X par son successeur préenregistré. En temps normal, il faut soigneusement sélectionner et vérifier ces successeurs, pour éviter toute décision précipitée lors d’une crise.

Test préalable avant mise à jour

Après avoir identifié la cause et l’impact, il faut déployer un correctif. C’est souvent la phase la plus risquée : déployer rapidement sous pression, avec des attaquants qui connaissent déjà la logique du protocole. Ne pas sauter l’étape de test. En cas de manque de temps pour un audit complet, faire appel à des white hats ou lancer une course aux bugs de 48h avant la mise en production, pour bénéficier d’un regard externe.

/ 07 Rétablissement après incident

Action rapide

Les fonds volés ont une demi-vie de blanchiment : ils sont rapidement divisés, transférés entre chaînes pour dissimuler leur origine. Collaborer avec Chainalysis ou autres services d’analyse on-chain pour suivre en temps réel les adresses multi-chaînes des attaquants, alerter les exchanges, suivre les transferts. Préparer une liste : départements conformité des exchanges centralisés, opérateurs de ponts cross-chain, gestionnaires de custodians, et tous les partenaires capables de geler ou d’intercepter les fonds en transit.

Négociation et médiation

Malgré la frustration, il est conseillé d’entrer en contact avec les attaquants. Tout peut se négocier. Publier une offre de bug bounty limitée dans le temps, en promettant de rembourser intégralement si les fonds sont restitués, en renonçant à toute poursuite légale. Si l’attaquant est un acteur étatique, la négociation est souvent vouée à l’échec ; mais beaucoup d’attaquants ne cherchent qu’un profit discret, et peuvent accepter une négociation. Toujours faire intervenir un juriste.

/ 08 La menace des attaques de hackers ne disparaîtra pas. Avec l’évolution de l’IA, la fréquence des attaques ne fera qu’augmenter. La défense ne peut pas se contenter de s’améliorer seule ; il faut utiliser des outils IA similaires à ceux des attaquants, pratiquer une red team/red blue régulière, une surveillance continue en temps réel, et fixer des limites strictes de pertes pour résister aux risques extrêmes et traverser les cycles du secteur.