Anatomie d'un exploit : quand une faille de smart contract vide une trésorerie en 12 secondes

Imaginons un scénario réaliste, inspiré des familles de vulnérabilités les plus documentées du web3. Vous avez livré il y a trois mois un contrat de staking pour un client. Le code a été testé, la démo était impeccable, le client ravi. Le contrat gère aujourd'hui l'équivalent de 480 000 € déposés par ses utilisateurs.

À 14h03, un attaquant repère une faille de reentrancy : une fonction de retrait qui envoie les fonds avant de mettre à jour le solde interne. Il déploie un contrat malveillant qui rappelle la fonction en boucle, dans la même transaction, avant que le solde ne soit décrémenté.

En l'espace de quelques blocs — une douzaine de secondes — le contrat est vidé. Aucun humain n'a eu le temps de réagir. Quand l'alerte tombe sur le canal du client, les fonds sont déjà dispersés.

Ce qui caractérise le sinistre web3, c'est cette vitesse. Là où une fuite de données classique peut être contenue en colmatant un serveur, un exploit on-chain est irréversible à l'instant où il s'exécute. Il n'y a pas de « rollback » sur une chaîne publique.

Le réflexe est de chiffrer le sinistre à la valeur dérobée. C'est très en dessous de la réalité. Voici la décomposition réaliste d'un tel événement :

Pour un développeur freelance ou une petite structure, ces montants n'ont aucune proportion avec l'honoraire facturé. Vous avez peut-être touché 15 000 € pour la mission ; vous êtes mis en cause sur un préjudice de plusieurs centaines de milliers d'euros. C'est exactement le type de déséquilibre que l'assurance professionnelle existe pour corriger.

Le sort assurantiel de ce sinistre dépend de sa qualification. Et c'est là qu'intervient la distinction clé entre RC Pro et Cyber.

• Si le sinistre est une faute de conception — la faille de reentrancy résulte d'une erreur de programmation, d'un pattern vulnérable connu non corrigé — on est dans le champ de la responsabilité civile professionnelle. Le client vous reproche un livrable défectueux. La RC Pro couvre les dommages immatériels qui en découlent et vos frais de défense.
• Si le sinistre relève d'une intrusion exploitant la sécurité — clé privée compromise, accès administrateur détourné, attaque sur l'infrastructure — on entre dans le champ de la garantie Cyber, qui couvre l'incident de sécurité lui-même, la remise en état et la gestion de crise.

Dans la vie réelle, les deux dimensions se mélangent souvent : une faille de conception est exploitée par un attaquant. D'où l'intérêt de coupler les deux couvertures. Notre décryptage du « code is law » détaille pourquoi la qualification juridique est rarement évidente — et pourquoi laisser un trou entre vos garanties est risqué.

Une particularité du métier aggrave encore l'exposition : le décalage temporel entre votre intervention et le sinistre. Vous avez livré le contrat il y a trois mois, vous êtes passé à d'autres missions, et le code que vous pensiez derrière vous gère désormais une trésorerie qui a grossi. La faille dormait, l'attaquant l'a trouvée.

Sur le plan assurantiel, c'est un point à surveiller de près. La plupart des contrats RC Pro fonctionnent en base réclamation : ce qui compte n'est pas seulement la date de la faute, mais la date à laquelle la réclamation vous est adressée, dans la période de validité du contrat (et de sa garantie subséquente). Concrètement, il est essentiel de rester couvert tant que vos anciens livrables sont en production — et en web3, un contrat immuable peut rester actif des années.

Arrêter votre assurance parce que « la mission est finie » est une erreur classique : le smart contract, lui, continue de tourner. Le risque ne s'éteint pas avec la facture.

C'est aussi pourquoi documenter chaque livraison (date, version déployée, périmètre, avertissements transmis) protège votre capacité à rattacher un sinistre tardif à une période où vous étiez bien assuré.

Tous les sinistres web3 ne viennent pas du code. Une part importante vient de la gestion des accès et des clés — l'un des risques propres à votre métier. Un scénario fréquent : la clé privée d'un wallet de déploiement ou d'un rôle administrateur du contrat fuite (phishing, dépôt accidentel dans un repo, machine compromise).

L'attaquant n'a alors pas besoin de trouver un bug : il possède la clé. Il appelle les fonctions privilégiées comme s'il était vous, retire les fonds, modifie les paramètres. Le contrat se comporte exactement comme conçu — le problème est en amont, dans la chaîne de sécurité.

Ce type d'incident illustre pourquoi la sécurité opérationnelle fait partie intégrante de votre responsabilité professionnelle, au même titre que la qualité du code. Et c'est typiquement le terrain de la garantie Cyber, qui couvre les conséquences d'un accès frauduleux et accompagne la remise en sécurité.

Reprenons notre sinistre à 480 000 € sans aucune couverture. Concrètement, voici ce que vous affrontez seul :

1. Le coût immédiat de la défense. Dès la première mise en demeure, il faut un avocat spécialisé et souvent une contre-expertise technique. Ces frais tombent avant même qu'un juge ait tranché quoi que ce soit.
2. Le risque de condamnation. Si votre responsabilité est retenue, même partiellement, l'indemnité peut dépasser de très loin la capacité financière d'un indépendant ou d'une TPE.
3. Le temps et l'énergie. Une procédure de ce type mobilise des mois, pendant lesquels vous ne développez pas. Le coût d'opportunité est réel.

Avec une couverture adaptée, le scénario change radicalement : l'assureur prend la main sur la défense, mobilise les experts, et porte l'indemnisation dans la limite des garanties. Vous passez du statut de « débiteur potentiel d'un demi-million » à celui de « professionnel assuré qui gère un incident ». C'est tout l'écart entre une activité qui survit à son premier gros sinistre et une activité qui s'arrête.

Pour limiter en amont la probabilité d'en arriver là, consultez notre checklist d'audit avant déploiement.