Réentrance non détectée : anatomie chiffrée d'un audit qui tourne au procès

La réentrance (reentrancy) est la vulnérabilité fondatrice du Web3 — celle qui a provoqué le hack historique du DAO en 2016. Le principe est d'une simplicité redoutable. Une fonction de retrait envoie d'abord les fonds à l'appelant, puis met à jour son solde interne. Entre ces deux instructions, le contrat attaquant — appelé via un mécanisme de callback — rappelle la fonction de retrait. Comme le solde n'a pas encore été décrémenté, le contrat croit que l'attaquant a toujours droit à ses fonds, et paie une seconde fois. Puis une troisième. En boucle, jusqu'à épuisement de la trésorerie.

La parade est connue depuis près d'une décennie : le pattern checks-effects-interactions (vérifier, modifier l'état, puis seulement interagir avec l'extérieur), ou l'usage d'un ReentrancyGuard. C'est précisément parce que la parade est si bien documentée qu'un auditeur qui laisse passer une réentrance se trouve en position défensive très inconfortable : il ne pourra pas plaider la faille exotique imprévisible.

Le scénario qui suit est une reconstitution réaliste, à partir de cas réels anonymisés. Les montants et le déroulé sont représentatifs de ce que vit un auditeur indépendant mis en cause.

Semaine 0. Un protocole de prêt décentralisé mandate un auditeur freelance pour réviser ses contrats avant le lancement public. Honoraires : 9 500 €. Délai : huit jours. Le scope couvre quatre contrats Solidity, dont le module de staking qui gère les dépôts et retraits des utilisateurs.

Semaine 1. L'auditeur rend un rapport propre : quelques findings de sévérité basse et moyenne, une recommandation sur la gestion des oracles, aucune faille critique. Le protocole corrige les points mineurs et déploie en production. La TVL grimpe rapidement à plus de 4 millions d'euros.

Semaine 3. Un attaquant repère que la fonction unstake() envoie les tokens à l'utilisateur avant de mettre à jour la variable de solde. Il déploie un contrat malveillant, déclenche la boucle de réentrance, et vide 3,2 M€ en une seule transaction. Les fonds transitent par un mixeur en quelques minutes. Irrécupérables.

Le rapport d'audit mentionnait la fonction unstake() dans le périmètre, mais ne signalait aucun problème d'ordonnancement des opérations. C'est ce silence qui fonde la mise en cause.

Dans les heures qui suivent, l'incident fait le tour des réseaux. Le nom de l'auditeur, listé dans le rapport public, est associé partout au protocole hacké.

Le protocole, soutenu par certains de ses gros déposants, engage une action en responsabilité pour faute professionnelle. L'argumentaire est précis et c'est ce qui le rend dangereux :

• La fonction vulnérable était explicitement dans le périmètre de l'audit ;
• La faille relève du pattern de réentrance, la plus documentée de tout l'écosystème — donc difficile à présenter comme imprévisible ;
• Un outil d'analyse statique standard (Slither, Mythril) signale ce type de schéma : ne pas l'avoir détecté suggère soit un audit superficiel, soit une lecture incomplète des résultats d'outillage.

Face à cela, l'auditeur dispose d'arguments — délai contraint, version auditée différente de la version déployée, responsabilité du client qui n'a pas commandé de re-test après modifications. Mais ces arguments doivent être prouvés et plaidés, ce qui suppose une défense technique et juridique solide. C'est exactement là qu'intervient une RC Pro couvrant la faute, l'erreur d'analyse et l'omission de faille.

On imagine souvent que le risque, c'est de devoir rembourser les 3,2 M€. En pratique, peu d'auditeurs indépendants ont un patrimoine permettant une telle indemnisation, et les plafonds de garantie comme les clauses contractuelles limitent généralement l'exposition finale. Le danger immédiat est ailleurs : les frais de défense, qui démarrent dès la première mise en cause, bien avant tout jugement.

On atteint vite 40 000 à 100 000 € de frais avant même de savoir si la responsabilité sera retenue. Pour un freelance facturant entre 5 000 et 15 000 € par mission, c'est plusieurs années de chiffre d'affaires englouties. Une RC Pro prend ces frais en charge dès le départ, ce qui change tout : vous vous défendez sérieusement au lieu de capituler faute de trésorerie.

Ce sinistre reconstitué livre quatre leçons applicables immédiatement :

1. Documentez votre méthodologie. Indiquez dans le rapport les outils utilisés (Slither, Mythril, Foundry), les patterns vérifiés et les hypothèses. En cas de litige, cette traçabilité démontre votre diligence.
2. Figez et horodatez la version auditée. Le commit hash exact dans le rapport est votre meilleure preuve qu'un redéploiement post-audit a échappé à votre périmètre.
3. Cadrez le délai par écrit. Si un client impose huit jours sur un scope qui en exigerait quinze, mentionnez-le. Un audit bâclé sous contrainte de délai reste votre responsabilité, sauf à l'avoir documenté.
4. Assurez-vous avant la première mission. La RC Pro ne se souscrit pas après le sinistre. Pour un auditeur smart contract, la couverture est accessible dès quelques dizaines d'euros par mois : voir la page assurance auditeur smart contract.

La réentrance ne disparaîtra pas. Tant qu'il y aura des fonctions de retrait mal ordonnées, il y aura des exploits — et des auditeurs mis en cause. La question n'est pas de savoir si vous serez parfait, mais comment vous tiendrez le jour où une faille passera.