De niveau bombe nucléaire ! Des hackers IA sont en train de dévaliser votre position DeFi, ces 3 « invariants » peuvent-ils vous sauver la vie ?

Je vais te raconter une histoire, ne pense pas que je te fais peur.

Récemment, j'ai consulté des données sur les attaques de hackers en 2026, et le nombre de DeFi piraté a atteint un record historique. Au premier trimestre, c'était déjà une première, et au début du deuxième trimestre, un autre record est sur le point d'être battu. La source est la statistique de DefiLlama, c'est clair comme de l'eau de roche.

Je te donne un signal d'alerte : l'IA a réduit le coût de recherche de vulnérabilités au niveau du plancher. Avant, une équipe humaine mettait plusieurs semaines à analyser la configuration de cent protocoles pour trouver des erreurs, maintenant, le modèle de base le plus récent ne prend que quelques heures.

Les protocoles qui pensent encore que « l'IA n'est pas si intelligente » se font démasquer en une seconde.

Ne me dis pas que tu n'as pas peur des « acteurs étatiques ». Ces super-vilains, très compétents en technologie et dotés de ressources abondantes, jouent à long terme. Ils scrutent chaque recoin de ton protocole et de ton infrastructure pour trouver des vulnérabilités, alors que ton équipe est dispersée sur six ou sept axes d'activité.

Je ne suis pas expert en sécurité, mais j'ai dirigé des équipes à haut risque — dans l'armée et dans la finance avec de gros fonds. Je crois une chose : seul le parano peut survivre.

Laisse-moi te donner une idée de la réponse. La surface d'attaque peut être résumée en trois blocs : l'équipe du protocole, les contrats intelligents et l'infrastructure, la frontière de confiance des utilisateurs (comme les réseaux sociaux).

Pour ces trois blocs, il faut empiler cinq couches de défense : prévention, mitigation, suspension, récupération, restauration. La prévention consiste à bloquer les vulnérabilités dans le processus ; la mitigation limite les dégâts si la prévention échoue ; la suspension coupe immédiatement l'attaque, évitant de prendre des décisions sous pression ; la récupération consiste à abandonner et remplacer un composant compromis ; la restauration prévoit d'avance des partenaires capables de geler des fonds, d'annuler des transactions ou d'aider à l'enquête.

Comment faire concrètement ? Je vais te donner des astuces concrètes.

Utilise massivement l'IA de pointe pour scanner ton code et ta configuration, et réalise des tests de red team. Les attaquants utilisent l'IA, tes scans défensifs découvrent ce qu'ils ont déjà repéré en attaque.

Le temps et la friction sont de bonnes défenses. Ajoute plusieurs étapes et un verrouillage temporel pour toute opération susceptible de causer des dégâts. Autrefois, on s'opposait à cela pour réduire la friction dans l'équipe, mais maintenant, l'IA peut t'aider à passer ces obstacles en arrière-plan, pas de souci.

Les invariants sont essentiels. Écris des « faits » immuables — par exemple, la logique centrale du protocole. Si ces faits sont brisés, tout le protocole s'effondre. Mais ne rédige pas trop, chaque fonction doit faire respecter plusieurs invariants, sinon ça devient ingérable.

Il faut équilibrer le pouvoir. Beaucoup d'attaques viennent de portefeuilles compromis. Tes configurations doivent garantir qu'en cas de compromission d'une multi-signature, tu peux rapidement limiter les dégâts et ramener le protocole à un état gouvernable. La gouvernance décide de tout, la récupération peut restaurer la stabilité, mais ne peut pas remplacer ou renverser la gouvernance elle-même.

Suppose que tu seras forcément piraté. Même toi, aussi intelligent sois-tu, tu ne peux pas y échapper. Les contrats intelligents ou dépendances échoueront, des attaques d'ingénierie sociale surgiront, des mises à jour introduiront des vulnérabilités. En acceptant cette prémisse, les limiteurs de débit et les disjoncteurs du protocole deviennent tes alliés les plus solides. Limite les dégâts à 5-10 %, puis fige tout, et planifie la suite.

Le meilleur moment pour planifier, c'est maintenant. Avant d'être piraté, réfléchis à une stratégie. Encode le processus, entraîne ton équipe. À l'ère de l'IA, cela signifie maîtriser des compétences et des algorithmes capables de présenter rapidement des informations, et partager cela avec ton cercle central. Tu n'as pas besoin de perfection, mais tu dois survivre. Aucun système n'est invulnérable dès le départ, mais après plusieurs itérations, tu deviens antifragile. L'absence de preuve de piratage ne signifie pas que tu ne seras pas attaqué. Les moments les plus confortables sont souvent les plus dangereux.

Parmi les mesures de prévention, la conception des contrats intelligents doit se concentrer sur les invariants, en les renforçant par des vérifications en temps d'exécution. Mode FREI-PI : à la fin de chaque fonction touchant à la valeur, vérifie à nouveau que l'invariant de la couronne que cette fonction doit maintenir est toujours respecté. Beaucoup d'attaques par déni de service — sandwich de flash loans, liquidation assistée par oracle, épuisement de la capacité de paiement entre fonctions — peuvent être détectées par ces vérifications en fin de fonction.

Les tests flous d'état doivent générer des séquences d'appels aléatoires sur la surface complète du protocole, en affirmant à chaque étape que l'invariant est respecté. La plupart des vulnérabilités en production sont liées à plusieurs transactions, et ces tests sont presque la seule méthode fiable pour découvrir des chemins d'attaque avant les hackers. Associés à la vérification formelle, ils peuvent prouver que les propriétés tiennent dans tous les états accessibles.

Les oracles et dépendances sont de grands ennemis de la sécurité. Chaque dépendance externe augmente la surface d'attaque. Si tu conçois des primitives, donne le pouvoir de faire confiance à l'utilisateur. Si tu ne peux pas éliminer la dépendance, diversifie-la pour qu'aucun point unique de défaillance ne puisse détruire le protocole. Étends la portée des audits pour simuler l'échec des oracles et dépendances, et limite les catastrophes potentielles. La faille récente de KelpDAO en est un exemple — ils ont hérité de la configuration LayerZero requiredDVNCount=1, hors portée d'audit, et c'est cette faille qui a été exploitée via l'infrastructure hors chaîne.

Les attaques superficielles ont été listées. Vérifie chaque catégorie, demande si cela s'applique à ton protocole, puis mets en place des contrôles. Développe des compétences en red team, et fais en sorte que ton IA identifie activement les vulnérabilités, c'est désormais une exigence de base.

Dispose d'une capacité de sauvetage native. Dans la gouvernance basée sur le vote, le pouvoir est concentré dans la multi-signature de l'équipe, ce qui prend du temps à se diffuser. Déploie un « portefeuille gardien », avec une autorisation stricte : il ne peut que suspendre le protocole, et en cas de seuil >=4/7, il peut, dans des situations extrêmes, remplacer le portefeuille endommagé par un portefeuille de remplacement prédéfini. Le gardien ne peut jamais exécuter une proposition de gouvernance. Ainsi, tu disposes d'une couche de secours, sans pouvoir renverser la gouvernance.

Au niveau des portefeuilles et des clés, la multi-signature doit être au minimum 4/7. Aucun individu ne doit contrôler toutes les 7 clés. Effectue des rotations fréquentes des signataires, discrètement. Les clés ne doivent jamais interagir avec des appareils quotidiens. Si tu utilises un appareil de signature pour naviguer sur Internet, envoyer des mails ou ouvrir Slack, considère que ce signataire est compromis. Utilise plusieurs multi-signatures, pour des usages différents. Suppose qu'au moins une multi-signature complète sera compromise, et planifie à partir de là.

Les primes de bug bounty doivent être généreuses. Si tu as des ressources, fixe une prime élevée par rapport à la TVL du protocole, au moins 7-8 chiffres. Face à des acteurs étatiques, ils ne négocieront peut-être pas, mais tu peux toujours participer à un programme de bug bounty blanc, en autorisant des hackers éthiques à agir en ton nom.

L'audit reste précieux. Un bon auditeur anticipe la courbe. Si tu développes quelque chose de nouveau, les vulnérabilités ne seront peut-être pas dans leur base de données d'entraînement, et augmenter le nombre de tokens n'a pas encore prouvé son efficacité. Tu ne veux pas être le premier à tester une vulnérabilité unique. Engager un auditeur, c'est aussi utiliser leur réputation comme garantie — s'ils approuvent et que tu te fais pirater, ils seront fortement motivés à aider.

La sécurité opérationnelle doit être un indicateur de succès. Organise des exercices de phishing, embauche une red team pour tester l'ingénierie sociale de ton équipe. Prépare des portefeuilles matériels et des dispositifs de secours pour remplacer tout le multi-signature.

En termes de mitigation, ton plan de sortie doit limiter la perte. La limite maximale de valeur pouvant sortir du protocole doit être fixée. Une fonction de mint sans limite par bloc, c'est un chèque en blanc pour une émission infinie. Une fonction de rachat sans limite hebdomadaire, c'est un chèque en blanc pour un solde d'actifs corrompu. Réfléchis soigneusement à une valeur claire pour la sortie, en équilibrant la perte maximale et l'expérience utilisateur optimale.

Les listes blanches et noires doivent être formalisées. Mets en place un processus à deux étapes pour les setters, pour créer de la friction. L'attaquant doit d'abord ajouter à la liste blanche, puis retirer de la liste noire pour agir. Avoir les deux implique que l'attaquant doit compromettre deux processus.

Les mesures de récupération doivent être surveillées par des algorithmes. Des moniteurs hors chaîne doivent suivre en permanence les invariants, et en cas de problème, déclencher une alerte automatisée. La dernière étape doit revenir à la multi-signature de gardien, avec suffisamment de contexte pour que les humains puissent décider en quelques minutes.

En cas de compromission, il faut arrêter le saignement. Prépare un script « pause tout », qui énumère tous les composants pouvant être suspendus et les met en pause de façon atomique. Seule la gouvernance peut lever la suspension, la clé d'arrêt ne doit pas pouvoir suspendre la gouvernance elle-même. Si la couche de gardien peut suspendre la gouvernance, un gardien compromis peut bloquer à jamais le processus de récupération.

Lance une salle de crise. Fige, arrête tout, rassemble les personnes de confiance dans un cercle restreint, pour éviter que l'information ne fuite aux attaquants, au public ou aux arbitrages malveillants. Rôles : un décideur, un opérateur chargé de l'exécution, une personne pour reconstruire la vulnérabilité, un communicant, une personne pour enregistrer la chronologie des événements.

Prends en compte la réaction en chaîne. La première vulnérabilité peut être un leurre, pour préparer la suite. La suspension doit être bien étudiée, totalement contrôlable. La suspension doit figer tout le protocole, pour éviter qu'une suspension d'un composant n'ouvre une autre faille. Une fois la cause fondamentale identifiée, explore les surfaces exposées adjacentes et la réaction en chaîne, et répare tout en une seule fois.

Planifie la rotation des successeurs préalablement engagés. La rotation ne sera sûre que si tu connais à l'avance le successeur. Enregistre une adresse de successeur pour chaque rôle critique. La seule opération de rotation autorisée en urgence est « remplacer le rôle X par son successeur ».

Teste prudemment avant la mise à jour. Une fois que tu as défini la portée, publie la mise à jour avec précaution. C'est le code le plus risqué : écrit sous pression, ciblant des attaquants déjà identifiés. Si tu n'as pas le temps d'auditer, fais appel à des relations avec des white hats, ou organise une course de 48 heures.

Les actions de restauration doivent être rapides. Les fonds volés ont une demi-vie, et une fois qu'ils sont en circulation, ils entrent rapidement dans des circuits de blanchiment. Prépare à l'avance des fournisseurs d'analyse on-chain comme Chainalysis, pour marquer en temps réel les adresses des attaquants, et avertir les exchanges. Prépare aussi une liste de tiers : départements conformité, gestionnaires de ponts cross-chain, administrateurs de custodians, etc.

La négociation est indispensable. Essaie de dialoguer avec l'attaquant. Offre une prime blanche limitée dans le temps, et déclare publiquement qu'en cas de restitution totale avant la date limite, aucune action légale ne sera engagée. Face à des acteurs étatiques, tu risques de ne pas négocier, mais face à des attaquants moins expérimentés, ils veulent sortir à moindre coût. Mais, toujours, consulte un conseiller juridique en amont.

La conclusion est dure : les attaques ne cesseront pas, et plus l'IA devient intelligente, plus il y en aura. Se contenter de rendre la défense « plus fine » ne suffit pas. Tu dois utiliser les mêmes outils que les attaquants, faire du red team sur ton protocole, surveiller en continu, et imposer des limites strictes aux dégâts, pour survivre dans le pire des cas.

Ta position, c'est toi qui la pèses.