Guide de sécurité DeFi : comment se prémunir efficacement contre les attaques de pirates informatiques à l’ère de l’IA ?
TechFlow SélectionTechFlow Sélection
Guide de sécurité DeFi : comment se prémunir efficacement contre les attaques de pirates informatiques à l’ère de l’IA ?
Les attaques de pirates informatiques ne cesseront pas ; au fur et à mesure que l’IA deviendra plus intelligente, ces attaques ne feront qu’augmenter.
Dédié à des analyses Web3 approfondiesRédaction : sysls
Traduction : AididiaoJP, Foresight News
Introduction
Après avoir étudié de nombreux cas de piratage de protocoles DeFi, j’ai développé une crainte profonde à l’égard des « acteurs étatiques ». Leurs compétences techniques sont exceptionnelles, leurs ressources abondantes, et ils jouent un jeu extrêmement long. Ces super-vilains se concentrent sur l’analyse minutieuse de chaque recoin de votre protocole et de votre infrastructure afin d’y déceler la moindre faille, tandis que les équipes de protocoles classiques voient leur attention dispersée entre six ou sept axes opérationnels distincts.
Je ne me présente pas comme un expert en sécurité, mais j’ai dirigé des équipes dans des environnements à haut risque (y compris au sein de forces armées et dans le domaine financier impliquant des montants substantiels), ce qui m’a doté d’une solide expérience en réflexion stratégique et en planification de scénarios d’urgence.
Je suis sincèrement convaincu qu’« uniquement les paranoïaques survivront ». Aucune équipe ne commence avec l’intention délibérée de traiter la sécurité de façon négligente ou superficielle ; pourtant, les attaques surviennent bel et bien. Nous devons faire mieux.
L’IA rend cette fois-ci les choses fondamentalement différentes
(Source des données : https://defillama.com/hacks)
Les attaques ne sont pas rares, mais leur fréquence augmente nettement. Le premier trimestre 2026 constitue le trimestre ayant enregistré le plus grand nombre d’attaques DeFi jamais recensé, et le deuxième trimestre, qui vient tout juste de commencer, est déjà susceptible de battre ce précédent record.
Mon hypothèse centrale est la suivante : l’IA a considérablement réduit le coût de recherche des vulnérabilités et élargi de façon spectaculaire la surface d’attaque. Un humain nécessite plusieurs semaines pour analyser la configuration de cent protocoles afin d’y détecter des erreurs de configuration ; les modèles fondamentaux les plus récents accomplissent cette tâche en quelques heures seulement.
Cela devrait transformer radicalement notre manière de concevoir et de répondre aux attaques. Les protocoles anciens, habitués à des mesures de sécurité antérieures à l’ère de l’IA puissante, sont de plus en plus exposés au risque d’être « éliminés en une fraction de seconde ».
Penser en termes de surfaces et de couches
(Source des données : https://defillama.com/hacks)
La surface d’attaque peut effectivement être réduite à trois éléments : l’équipe du protocole, les contrats intelligents et l’infrastructure, ainsi que la frontière de confiance des utilisateurs (DNS, réseaux sociaux, etc.).
Une fois ces surfaces identifiées, il convient d’y superposer des couches de défense :
- Prévention : processus conçus pour réduire au maximum la probabilité d’exploitation, à condition d’être strictement appliqués.
- Atténuation : limitation des dégâts lorsque la prévention échoue.
- Arrêt d’urgence : personne ne peut prendre la meilleure décision sous une pression extrême. Dès la confirmation d’une attaque, déclenchez immédiatement un « interrupteur général ». Le gel permet d’empêcher toute perte supplémentaire et d’obtenir un espace de réflexion…
- Reprise de contrôle : si vous perdez le contrôle d’un composant toxique ou compromis, abandonnez-le et remplacez-le.
- Restauration : récupérez ce que vous avez perdu. Prévoyez à l’avance des partenariats institutionnels capables de geler des fonds, d’annuler des transactions et d’assister aux enquêtes.
Principes directeurs
Ces principes orientent la mise en œuvre concrète des différentes couches de défense.
Utiliser massivement les IA de pointe
Déployez massivement les modèles IA les plus avancés pour analyser votre base de code et vos configurations à la recherche de vulnérabilités, et pour réaliser des tests de type « red team » à grande échelle : cherchez des failles côté interface utilisateur (frontend) et vérifiez si elles peuvent atteindre le serveur (backend). Les attaquants procèdent ainsi. Ce que vous pouvez découvrir via des analyses défensives, leurs analyses offensives l’auront déjà identifié.
Recourez à des outils spécialisés tels que pashov et nemesis, ainsi qu’à des plateformes IA telles que Cantina (Apex) et Zellic (V12), afin de scanner rapidement votre base de code avant même la soumission à un audit complet.
Le temps et la friction constituent une bonne défense
Ajoutez des étapes multiples et des verrous temporels à toute opération pouvant causer des dommages. Vous devez disposer de suffisamment de temps pour intervenir et geler les opérations dès qu’une anomalie est détectée.
Par le passé, les objections contre les verrous temporels et les procédures multi-étapes reposaient sur la friction induite pour les équipes de protocoles. Aujourd’hui, cela ne doit plus vous préoccuper excessivement : l’IA peut aisément franchir ces obstacles en arrière-plan.
Les invariants
Les contrats intelligents peuvent être conçus de façon défensive en formalisant des « faits » immuables : si l’un de ces faits est violé, toute la logique du protocole s’effondre.
Vous ne disposez généralement que d’un petit nombre d’invariants. Il convient donc de les intégrer avec soin au niveau du code ; imposer plusieurs invariants dans chaque fonction devient vite ingérable.
Équilibre des pouvoirs
De nombreuses attaques découlent de portefeuilles compromis. Votre configuration doit permettre de circonscrire rapidement les dégâts même en cas de compromission d’un portefeuille multisignature, et ramener le protocole dans un état où la gouvernance peut reprendre ses décisions.
Cela exige un équilibre entre la gouvernance (qui décide de tout) et les mécanismes de secours (capables de restaurer une stabilité gouvernable, sans toutefois remplacer ou renverser la gouvernance elle-même).
Quelque chose finira toujours par mal tourner
Partez du principe, dès le départ, que peu importe votre intelligence, vous serez victime d’une attaque. Vos contrats intelligents ou vos dépendances peuvent tomber en panne. Vous pouvez subir une attaque par ingénierie sociale, et une nouvelle mise à jour peut introduire des vulnérabilités imprévues.
Dès que vous adoptez cette vision, les limites de dégâts (rate limiting) et les « disjoncteurs » permettant de bloquer le protocole deviennent vos meilleurs alliés. Limitez les pertes à 5–10 %, puis geler le système pour élaborer votre stratégie de réponse. Personne ne prend la meilleure décision sous le feu nourri.
Le meilleur moment pour planifier, c’est maintenant
Anticipez votre réponse avant même d’être attaqué. Automatisez autant que possible les procédures, et entraînez-y régulièrement votre équipe afin d’éviter toute panique au moment critique. À l’ère de l’IA, cela signifie disposer de compétences et d’algorithmes capables de présenter rapidement une grande quantité d’informations, et de les partager — sous forme synthétique ou détaillée — avec votre cercle restreint de collaborateurs de confiance.
Vous n’avez pas besoin de perfection, mais vous devez survivre. Aucun système n’est invulnérable dès son lancement ; grâce à des itérations successives et à l’apprentissage tiré des erreurs, vous deviendrez antifragile.
L’absence de preuve d’attaque ne signifie pas que vous n’en subirez pas. Le point de confort maximal est souvent le point de danger maximal.
Mesures préventives
Conception des contrats intelligents
Une fois les invariants définis, transformez-les en vérifications exécutées au moment de l’exécution (runtime checks). Réfléchissez attentivement à ceux qui méritent véritablement d’être appliqués de façon stricte.
C’est là qu’intervient le modèle FREI-PI (Exigences de fonction, Effets, Interactions, Invariants de protocole) : à la fin de chaque fonction manipulant de la valeur, révérifiez l’invariant « couronne » que ladite fonction s’engage à préserver. De nombreuses attaques de vidage passant par CEI (Checks-Effects-Interactions) — sandwich de prêt flash, liquidations malveillantes assistées par des oracles, vidages transfonctionnels de solvabilité — peuvent être interceptées par une vérification d’invariant à la fin de la fonction.
Tests rigoureux
Le fuzzing étatique génère des séquences aléatoires d’appels ciblant l’ensemble des interfaces publiques du protocole, et vérifie les invariants à chaque étape. La plupart des vulnérabilités observées en production résultent de séquences impliquant plusieurs transactions ; le fuzzing étatique constitue presque la seule méthode fiable pour découvrir ces chemins avant les attaquants.
Utilisez les tests d’invariants pour valider que certaines propriétés tiennent dans toutes les séquences d’appels générées par le fuzzing. Complété par une vérification formelle, cela permet de prouver que la propriété est garantie dans tous les états accessibles. Vos invariants « couronne » doivent absolument faire l’objet d’un tel traitement.
Oracles et dépendances
La complexité est l’ennemie de la sécurité. Chaque dépendance externe élargit la surface d’attaque. Si vous concevez un primitif, laissez à l’utilisateur le choix de qui et de quoi il fait confiance. Si vous ne pouvez supprimer une dépendance, diversifiez-la afin qu’aucun point de défaillance unique ne puisse détruire votre protocole.
Étendez la portée de vos audits afin d’analyser comment les oracles et les dépendances pourraient échouer, et imposez des limites de dégâts (rate limiting) selon la gravité potentielle des catastrophes résultant de cet échec.
Le récent incident survenu chez KelpDAO illustre parfaitement ce point : ils ont hérité de la configuration par défaut de LayerZero, requiredDVNCount=1, une configuration située hors champ de leur audit. C’est finalement l’infrastructure hors chaîne, non couverte par l’audit, qui a été compromise.
Attaques par surface
La plupart des attaques par surface dans le domaine DeFi sont déjà documentées. Parcourez méthodiquement chaque catégorie, demandez-vous si elle s’applique à votre protocole, puis mettez en place des contrôles spécifiques à ce vecteur d’attaque. Développez des compétences de « red team », et dotez vos agents IA de la capacité de rechercher activement des vulnérabilités dans votre protocole ; c’est aujourd’hui une exigence fondamentale.
Capacité native de secours
Dans un cadre de gouvernance basé sur le vote, le pouvoir est initialement concentré dans la multisignature de l’équipe, et sa diffusion prend du temps. Même avec une distribution large des jetons, les délégations tendent à concentrer l’autorité vers un petit nombre de portefeuilles (parfois même un seul, n=1). Lorsque ces portefeuilles sont compromis, la partie est perdue.
Déployez des « portefeuilles gardiens », dotés d’un mandat strictement limité : ils ne peuvent que suspendre le protocole, et, dans des cas extrêmes, remplacer une délégation compromise par un portefeuille de remplacement prédéfini, à condition d’atteindre un seuil de ≥4/7 signatures. Les gardiens ne peuvent jamais exécuter de propositions de gouvernance.
Ainsi, vous disposez d’une couche de secours permanente capable de restaurer une stabilité gouvernable, sans toutefois posséder le pouvoir de renverser la gouvernance. La probabilité qu’un scénario catastrophe impliquant la compromission de ≥4/7 gardiens se produise est extrêmement faible (compte tenu de la diversité de leurs détenteurs), et cette couche peut progressivement être retirée une fois que la gouvernance sera devenue mature et décentralisée.
Topologie des portefeuilles et des clés
Le portefeuille multisignature est une exigence minimale, avec un seuil minimal de 4/7. Aucune personne ne doit détenir l’ensemble des 7 clés. Procédez régulièrement à des rotations discrètes des signataires.
Les clés ne doivent jamais interagir avec des appareils utilisés quotidiennement. Si vous utilisez votre appareil de signature pour naviguer sur Internet, consulter vos e-mails ou utiliser Slack, considérez ce signataire comme déjà compromis.
Disposez de plusieurs multisignatures, chacune affectée à un usage spécifique. Partez du principe qu’au moins une multisignature complète sera compromise, et planifiez en conséquence. Aucune personne ne devrait détenir un pouvoir suffisant pour compromettre le protocole, même dans des scénarios extrêmes (enlèvement, torture, etc.).
Envisagez un programme de primes
Si vous disposez des ressources nécessaires, instaurer une prime importante pour la découverte de vulnérabilités, proportionnelle à la valeur totale verrouillée (TVL) de votre protocole, est fortement recommandé. Même pour un protocole relativement petit, la prime devrait être aussi généreuse que possible (par exemple, un minimum à 7 ou 8 chiffres).
Face à des attaques menées par des acteurs étatiques, ceux-ci pourraient refuser toute négociation, mais vous pouvez toujours participer à un programme de « port d’attache pour white hats », autorisant des experts éthiques à agir en votre nom pour protéger les fonds, moyennant une commission calculée sur le montant de la prime (payée, en pratique, par les déposants).
Choisissez des auditeurs compétents
J’ai précédemment écrit que, à mesure que les modèles de langage deviennent plus performants, la valeur marginale d’engager des auditeurs diminue. Je maintiens cette position, mais mon point de vue s’est nuancé.
Premièrement, les meilleurs auditeurs anticipent les tendances. Si vous développez une innovation, votre code — et ses vulnérabilités potentielles — pourrait ne pas figurer dans leurs données d’entraînement ; augmenter simplement le volume de jetons n’a pas encore démontré son efficacité pour détecter des vulnérabilités inédites. Vous ne souhaitez pas être le premier cas réel d’une vulnérabilité originale.
Deuxièmement, un avantage sous-estimé est le suivant : engager un auditeur revient à solliciter sa réputation comme garantie. S’il appose sa signature d’approbation et que votre protocole est ensuite attaqué, il aura un fort intérêt à vous venir en aide. Tisser des liens avec des professionnels expérimentés en sécurité constitue un avantage considérable.
Mettez en pratique la sécurité opérationnelle
Considérez la sécurité opérationnelle comme un indicateur de réussite. Organisez des exercices de phishing ; engagez une « red team » (de confiance) pour tenter d’effectuer une ingénierie sociale sur votre équipe. Préparez des portefeuilles matériels et des équipements de secours afin de pouvoir remplacer immédiatement toute multisignature si nécessaire. Vous ne voulez pas être contraint de courir acheter ces équipements au jour J.
Mesures d’atténuation
Votre voie de sortie correspond à votre plafond de pertes
La limite supérieure de toute voie permettant de retirer de la valeur du protocole définit la perte théorique maximale en cas d’exploitation d’une vulnérabilité sur cette voie. Autrement dit : une fonction de frappe (minting) sans limite par bloc constitue un chèque en blanc pour toute vulnérabilité permettant une frappe illimitée. Une fonction de rachat (redemption) sans limite hebdomadaire représente un chèque en blanc pour toute corruption du solde des actifs.
Réfléchissez soigneusement aux valeurs numériques précises de vos voies de sortie. Ce chiffre doit représenter un équilibre entre le dommage maximal que vous êtes prêt à accepter et les exigences UX les plus extrêmes des utilisateurs. En cas de problème, c’est ce plafond qui vous évitera la destruction totale.
Listes blanches (et listes noires)
La plupart des protocoles comportent des listes d’éléments pouvant être appelés, échangés ou reçus, ainsi que des listes d’actions strictement interdites aux utilisateurs. Même implicites, ces listes constituent des frontières de confiance qu’il convient de formaliser.
Formaliser ces listes vous permet de mettre en place des setters à deux étapes, créant ainsi une friction significative. L’attaquant doit d’abord être ajouté à la liste blanche (et/ou retiré de la liste noire), puis seulement il pourra agir. Disposer simultanément des deux listes signifie que, pour introduire discrètement un nouveau vecteur d’attaque, l’attaquant doit compromettre deux processus distincts : l’intégration/mise sur le marché doit être autorisée, et l’action ne doit pas être interdite (revue de sécurité).
Reprise de contrôle
Surveillance algorithmique
Un « interrupteur d’arrêt d’urgence » est inutile si personne ne le surveille. Des surveillants hors chaîne doivent surveiller en continu les invariants, et déclencher automatiquement des alertes dès qu’un problème est détecté. Le flux final doit aboutir aux mains humaines de la multisignature des gardiens, avec un contexte suffisant pour leur permettre de prendre une décision en quelques minutes.
Arrêtez-vous pour recalibrer
Si vous êtes touché, commencez par arrêter l’hémorragie, plutôt que de prendre des décisions sous compteur. Pour un protocole, cela signifie un « interrupteur d’arrêt d’urgence » (visible également dans l’interface utilisateur) : un simple bouton permettant de suspendre, en une seule transaction, toutes les voies de transfert de valeur. Préparez un script auxiliaire « tout suspendre », qui énumère tous les composants pouvant être suspendus et les désactive de façon atomique.
Seule la gouvernance peut lever la suspension, donc l’interrupteur d’arrêt d’urgence ne peut pas suspendre le contrat de gouvernance lui-même. Si la couche des gardiens pouvait suspendre le contrat de gouvernance, une couche de gardiens compromise bloquerait définitivement tout processus de restauration.
Activez votre salle de crise
Geler les opérations, stopper l’hémorragie, puis rassemblez immédiatement toutes les personnes de confiance (cercle restreint, convenu à l’avance) dans un canal de communication dédié. Vous souhaitez garder cette surface d’échange la plus petite possible afin d’éviter toute fuite d’information vers les attaquants, le grand public ou des arbitragistes malveillants.
Attribuez des rôles précis à chaque membre de l’équipe : un décideur ; un opérateur compétent dans l’exécution des scripts défensifs et les opérations de suspension ; un expert chargé de reconstruire la vulnérabilité et d’identifier sa cause première ; un communicateur chargé de dialoguer avec les parties clés ; un observateur chargé de consigner les observations, les événements et la chronologie des décisions.
Lorsque chacun connaît son rôle et a déjà pratiqué ces scénarios, vous réagissez selon un processus éprouvé, plutôt que de paniquer au pire moment.
Anticipez les effets en cascade
Supposez que votre attaquant soit très expérimenté. La première vulnérabilité peut n’être qu’un leurre, ou une porte ouverte pour une attaque ultérieure. L’attaque pourrait viser à vous inciter à accomplir une action totalement erronée, déclenchant ainsi la véritable faille.
Toute suspension doit être entièrement étudiée, parfaitement maîtrisée et, en soi, invulnérable. Elle doit concerner le protocole dans son ensemble : vous ne voulez pas être amené à suspendre un composant spécifique, ce qui aurait pour effet d’ouvrir une autre voie d’attaque. Une fois la cause racine et le vecteur d’attaque identifiés, explorez les surfaces adjacentes exposées et les effets en cascade, puis corrigez-les tous d’un seul coup.
Remplacer les successeurs préalablement désignés
Un remplacement n’est sécurisé que si le successeur est connu à l’avance. J’apprécie particulièrement l’idée d’un registre de successeurs préalablement désignés : cela rend plus difficile pour un attaquant de substituer un gardien / portefeuille de gouvernance sain par un portefeuille compromis. Cette approche s’inscrit dans la même logique que celle des « listes blanches / listes noires » présentée dans la section « Mesures d’atténuation ».
Inscrivez une adresse de successeur pour chaque rôle critique. L’unique primitive de remplacement autorisée par la couche d’urgence est « remplacer le rôle X par son successeur ». Cela vous permet également d’évaluer les successeurs en période normale : procédez calmement, effectuez des vérifications approfondies, rendez-vous personnellement avec les personnes concernées.
Testez rigoureusement avant toute mise à jour
Une fois la cause racine et l’étendue des impacts identifiées, vous devrez publier une mise à jour. Il s’agit probablement du code le plus dangereux que vous aurez jamais déployé : rédigé sous pression, destiné à contrer un attaquant qui a déjà prouvé sa capacité à comprendre votre protocole et à y trouver des vulnérabilités.
Retardez la publication si les tests ne sont pas suffisants. En l’absence de temps pour un audit complet, mobilisez vos contacts parmi les white hats, ou organisez, avant déploiement, un concours de 48 heures pour obtenir un examen adversarial frais.
Restauration
Agissez rapidement
Les fonds volés ont une demi-vie : une fois la vulnérabilité exploitée, ils s’engouffrent rapidement dans des canaux de blanchiment. Préparez à l’avance des prestataires d’analyse sur chaîne tels que Chainalysis, afin de marquer en temps réel les clusters d’adresses des attaquants, et d’alerter les bourses lorsqu’ils changent de chaîne, afin qu’elles puissent les identifier et les suivre.
Préparez également à l’avance une liste d’interlocuteurs clés : services de conformité des bourses centralisées, administrateurs de ponts interchaînes, gestionnaires de custodians, et autres tiers disposant des autorisations nécessaires pour geler des messages interchaînes ou des dépôts en cours spécifiques.
Entamez des négociations
Oui, cela peut être douloureux, mais vous devriez tout de même essayer d’entrer en contact avec l’attaquant. De nombreuses situations dans la vie peuvent se résoudre par la négociation. Proposez une prime pour white hat assortie d’un délai, et déclarez publiquement que, si les fonds sont intégralement restitués avant l’échéance, aucune action judiciaire ne sera entreprise.
Face à un acteur étatique, vos chances sont minces, mais vous pourriez faire face à un attaquant moins expérimenté, qui a simplement trouvé une manière d’exploiter votre protocole et souhaite s’en sortir à moindre coût.
Avant toute tentative de négociation, assurez-vous impérativement de disposer d’un conseil juridique compétent.
Conclusion
Les attaques ne cesseront pas, et, à mesure que l’IA deviendra plus intelligente, elles ne feront que s’intensifier. Se contenter de rendre les défenseurs « plus vigilants » ne suffit pas. Nous devons employer les mêmes outils que les attaquants — réaliser des tests de type « red team » sur nos protocoles, assurer une surveillance continue, et fixer des limites strictes aux dégâts — afin de survivre même dans le pire des scénarios.
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
@systematicls
