Anatomie d'un hack par réentrance : comment 1,8 M€ remontent jusqu'au développeur

Prenons un cas représentatif, reconstitué à partir de schémas d'attaque récurrents dans l'écosystème. Un studio Web3 confie à un développeur Solidity freelance la conception d'un contrat de staking : les utilisateurs déposent des tokens, accumulent des récompenses, et peuvent retirer leur capital augmenté des gains à tout moment.

Le développeur livre un contrat fonctionnel, testé sur les cas nominaux. La fonction de retrait, au cœur du futur drame, suit une logique qui paraît anodine : elle calcule le solde dû, envoie les fonds à l'utilisateur, puis met à jour le solde interne à zéro. L'ordre des opérations semble naturel — on paie, puis on solde le compte. C'est précisément cet ordre qui ouvre la porte.

Le contrat passe une revue interne légère, sans audit externe complet faute de budget. Il est déployé sur le mainnet. Pendant quelques semaines, tout fonctionne. La TVL grimpe à plus de deux millions d'euros d'équivalent. Puis un attaquant repère le défaut.

La faille de réentrance exploite une règle fondamentale de l'EVM : lorsqu'un contrat envoie des fonds à une adresse, si cette adresse est elle-même un contrat, son code peut s'exécuter avant que la transaction initiale ne soit terminée. L'attaquant en fait une arme.

Voici le déroulé de l'attaque :

1. L'attaquant déploie un contrat malveillant et stake un petit montant légitime, pour disposer d'un solde non nul.
2. Il appelle la fonction de retrait. Le contrat de staking calcule son solde, et envoie les fonds au contrat attaquant.
3. La réception de ces fonds déclenche automatiquement la fonction de repli (fallback) du contrat malveillant. Or, à cet instant précis, le contrat de staking n'a pas encore remis le solde à zéro.
4. Depuis sa fonction de repli, l'attaquant rappelle immédiatement la fonction de retrait. Le contrat, croyant le solde toujours dû, paie une seconde fois. Puis une troisième. Puis une quatrième.
5. La boucle se répète jusqu'à épuisement des fonds du contrat ou de la limite de gas.

En quelques transactions, 1,8 M€ d'équivalent quittent le contrat vers l'attaquant, puis transitent par un mixeur. Les fonds sont irrécupérables. La cause technique tient en une phrase : la mise à jour d'état devait précéder l'appel externe, conformément au pattern checks-effects-interactions. Elle l'a suivi.

Une seule ligne déplacée — passer le solde à zéro avant l'envoi des fonds plutôt qu'après — aurait rendu l'attaque impossible. C'est l'écart minuscule entre un code sûr et un sinistre à sept chiffres.

Une fois l'hémorragie constatée, le studio active deux chantiers en parallèle : limiter la casse réputationnelle auprès de ses utilisateurs, et identifier les responsabilités. Le développeur freelance est rapidement dans le viseur.

Le reproche est précis et techniquement étayé : le pattern checks-effects-interactions est documenté depuis des années, enseigné dans toute formation Solidity sérieuse, et signalé par les outils d'analyse statique standard. Le studio soutient qu'un développeur diligent aurait dû ordonner correctement les opérations, et qu'une revue minimale aurait détecté la faille. Il invoque donc un manquement à l'obligation de moyens.

La réclamation chiffre le préjudice bien au-delà des seuls fonds volés. Voici sa décomposition typique :

Pour un freelance individuel, ce chiffre n'a aucun rapport avec sa capacité financière. Sans mécanisme assurantiel, il est purement et simplement insolvable face à une telle demande — ce qui n'empêche ni la procédure, ni l'atteinte durable à sa réputation dans un écosystème où tout se sait.

C'est ici que l'assurance RC Pro change la trajectoire du sinistre. Loin d'être une formalité administrative, elle devient la seule structure capable d'encaisser le choc à la place du développeur.

Son intervention se déploie sur plusieurs niveaux :

• La prise en charge immédiate de la défense. Dès la réclamation, l'assureur mobilise avocats et experts techniques. Dans un dossier où la preuve se lit dans des transactions on-chain et du bytecode, cette expertise est décisive et coûteuse.
• La contestation du quantum. La défense ne se contente pas de constater la faille : elle discute le périmètre de la mission, l'absence d'audit imposé par le client, le défaut de revue interne du studio, et toute négligence partagée de nature à réduire la part du développeur.
• L'indemnisation dans la limite du plafond. Si une part de responsabilité est retenue, c'est l'assureur qui indemnise, dans la limite du plafond souscrit. D'où l'importance, pour un développeur DeFi, de calibrer ce plafond sur les encours réels des protocoles servis.

Sans cette couverture, le développeur affronte seul une réclamation à sept chiffres, avec à la clé une probable insolvabilité et la fin de son activité. Avec elle, le sinistre redevient un litige gérable, où c'est sa part réelle de responsabilité — et non la totalité du préjudice — qui se discute.

Ce scénario, aussi spécifique soit-il, condense des enseignements valables pour toute mission de développement de smart contract. Ils tiennent autant à la méthode qu'à la protection.

1. Appliquez systématiquement checks-effects-interactions. Mettez à jour l'état avant tout appel externe. Cette discipline, combinée aux verrous de réentrance, neutralise la classe d'attaque entière.
2. Documentez votre revue. Conservez vos tests, vos rapports d'analyse statique, vos hypothèses. Ils prouvent votre diligence si votre code est mis en cause.
3. Pesez le défaut d'audit. Si le client renonce à un audit externe par contrainte budgétaire, tracez-le par écrit : ce choix lui appartient et pèsera dans le partage des responsabilités.
4. Souscrivez avant le premier déploiement, pas après. Une RC Pro ne couvre pas un sinistre déjà survenu. Elle doit être en place avant que votre code ne gère le moindre euro on-chain.

Pour évaluer le plafond et les garanties adaptés à vos missions blockchain, consultez notre page assurance développeur Solidity. Un sinistre par réentrance n'arrive jamais au moment où l'on s'y attend — il arrive au pire moment, et la seule variable que vous maîtrisez à l'avance, c'est votre couverture.