Quand quelque chose dérape on-chain, la différence entre un incident récupérable et un incident fatal se joue en général dans la première heure. Les équipes qui survivent ont répété ; celles qui improvisent perdent plus de valeur dans la réponse que dans l'exploit lui-même.
Ce qui suit, c'est le playbook de la première heure qu'on déroule quand on est appelés pour une mission de Réponse à incident. Toutes les étapes ne s'appliquent pas à tous les incidents, mais chaque étape existe parce qu'on l'a vue sautée et regrettée.
Minute 0 à 5 : confirmer et contenir
Le premier instinct, c'est toujours de communiquer. Le bon instinct, c'est d'arrêter l'hémorragie.
Confirmez que l'exploit est réel, pas une fausse alerte. Un pic de retraits peut être de la panique, pas un exploit. Une transaction louche peut être de la MEV, pas un drain. Regardez la trace on-chain. Identifiez la fonction appelée, l'adresse qui appelle, et la valeur qui sort.
Mettez en pause si vous pouvez. La plupart des protocoles bien conçus ont une fonction d'urgence détenue par un multi-sig ou un guardian. C'est le moment où elle gagne sa place. Réunissez le seuil de signataires sur un appel et exécutez la pause. Chaque bloc de retard, c'est plus de valeur dehors.
Révoquez si vous ne pouvez pas mettre en pause. Si un wallet est compromis, révoquez les approvals actives, mais seulement après avoir bougé les actifs restants vers une adresse propre, parce qu'une révocation coûte du gas et qu'un drainer essaie souvent de gagner la course.
Si votre équipe ne sait pas qui a l'autorité de mettre en pause, qui détient les clés et combien de temps il faut pour assembler le seuil, vous n'avez pas encore de posture de réponse à incident. On adresse ça pendant une mission Wallet Setup, avant le premier incident.
Minute 5 à 15 : assembler l'équipe
Une liste permanente de qui appeler quand un incident arrive vaut plus que n'importe quel outil.
L'équipe interne :
- Lead engineering (évaluation technique).
- Lead communication (rédige le premier post).
- Conseil juridique (juridiction applicable).
- Représentant board ou investisseur (notification, pas approbation).
L'équipe externe :
- Votre cabinet de réponse à incident. (Si vous n'en avez pas sous retainer, c'est le moment où vous regrettez. Les missions d'urgence sont prises selon la capacité, mais coûtent plus cher et répondent plus lentement.)
- Conseil familier des procédures crypto.
- Votre auditeur (il peut avoir du contexte sur les contrats touchés).
La liste vit dans un document partagé avec des numéros de téléphone, pas juste des emails. Les délais de réponse email ne sont pas des délais de réponse à incident.
Minute 15 à 30 : tracer et documenter
Deux activités tournent en parallèle.
Forensique on-chain :
- Identifiez les adresses attaquantes et notez-les.
- Tracez les fonds volés. Où sont-ils allés au premier hop ? Au second ?
- Identifiez si les fonds sont entrés dans Tornado, Railgun, un exchange centralisé, un bridge, ou une adresse dormante.
- Notez les adresses fundées par la même source que l'attaquant, ce sont peut-être des comptes opérationnels du même acteur.
Ce traçage devient la base de toute recovery, de tout engagement avec les forces de l'ordre, et de toute claim d'assurance. Faites-le bien, tôt.
Documentation interne :
- Ouvrez un canal incident. Restreignez les accès. Toutes les décisions passent par lui.
- Démarrez une timeline. Qui a fait quoi à quelle heure. Ce document sera la base du post-mortem.
- Faites des screenshots de l'état on-chain au moment de l'incident. L'état change après ce point.
Minute 30 à 45 : communiquer
La première communication a trois propriétés : honnête, brève, et n'engage rien que vous ne pouvez pas livrer.
Un premier post dit : nous sommes au courant d'un incident affectant [périmètre]. Nous avons [actions prises]. Nous investiguons. Le protocole est [en pause / pas en pause]. Les utilisateurs doivent [actions spécifiques, ex. révoquer les approvals, ne pas interagir avec le front-end]. Des updates seront postés ici toutes les [X] minutes.
C'est tout. Pas de « nous sommes confiants », pas de « aucun fonds n'est en risque » tant que vous ne savez pas. Une mauvaise communication transforme un incident survivable en incident fatal, en général parce que quelqu'un a dit quelque chose de définitif qui s'est avéré faux.
Dans notre mission Réponse à incident, on rédige ces posts ; l'équipe valide et publie. La rédaction est tactique ; la validation est la vôtre.
Minute 45 à 60 : tendre la main
Les options de recovery hors de votre protocole comptent maintenant.
Exchanges centralisés. Si les fonds vont sur un CEX, ils peuvent geler sur demande, si vous joignez la bonne personne avant que l'attaquant ne retire vers du fiat. La plupart des grands exchanges ont des desks law-enforcement et sécurité ; joignez-les via votre partenaire de réponse à incident si vous n'avez pas de ligne directe.
Émetteurs de stablecoins. USDC et USDT peuvent blacklister des adresses sur demande. Tether est plus rapide que Circle dans notre expérience, mais les deux ont un process. Plus tôt vous les joignez, meilleur le résultat.
Bridges. Certains bridges ont une capacité de pause d'urgence et acceptent de l'utiliser. D'autres non.
Mixers et outils de privacy. Une fois que les fonds entrent dans Tornado Cash ou similaire, les options de recovery se réduisent mais ne disparaissent pas. Le traçage reste utile pour des actions ultérieures.
Autres protocoles affectés. Si votre incident a un risque de spillover sur d'autres protocoles (par exemple si vous êtes l'oracle d'une autre dApp), notifiez-les. Ils vous renverront l'ascenseur quand la situation s'inversera.
Heures 1 à 24 : stabiliser
Au-delà de la première heure, le travail change :
- Une trace on-chain plus poussée, traversant souvent chaînes et mixers.
- Un second post public avec les détails confirmés, ce qui s'est passé, ce qui a été perdu, le plan immédiat.
- Engagement avec les forces de l'ordre, le cas échéant. Le document de trace est l'input.
- Décisions initiales sur la remédiation : hard fork, rollback, indemnisation depuis la trésorerie, vote de gouvernance.
Ce sont des décisions de gouvernance, pas techniques, et c'est là que les projets construisent leur réputation à long terme. Un protocole qui perd 10 % de TVL mais le gère avec transparence peut récupérer la confiance. Un protocole qui perd 10 % de TVL et ment, non.
Ce qu'il vous faut avant l'incident
On ne rédige pas un playbook de première heure dans la première heure. Il vous le faut écrit avant. Le minimum :
- Un chemin de pause détenu par un multi-sig avec des signataires documentés.
- Une rotation de signature, au moins un signataire éveillé dans chaque grand fuseau.
- Une liste de contacts d'incident, interne et externe, avec numéros.
- Un template « nous sommes au courant » rédigé qui n'a besoin que des spécifiques à remplir.
- Un retainer avec un cabinet de réponse à incident pour que la trace et le soutien comm démarrent immédiatement, pas après un appel commercial.
Pour les protocoles DeFi, les exchanges et les trésoreries DAO, cette préparation fait partie du coût d'opérer. Elle est nettement moins chère que de ne pas l'avoir.
Ce qu'on fait, concrètement
Quand un client nous page :
- Incident commander en ligne dans le SLA convenu.
- Forensique on-chain qui tourne en parallèle de l'appel.
- Communications rédigées renvoyées à votre équipe pour validation.
- Coordination avec exchanges, dépositaires et conseil.
- Un post-mortem écrit en fin de course, plus un document interne de lessons-learned.
La première heure est la plus dure. Le travail d'après, c'est là que la réputation du projet se regagne. Les deux sont plus faciles avec une équipe qui l'a déjà fait.