Le hack du DAO de 2016 expliqué

Le décor : un DAO à 150 M et une base de code connue comme fragile

Un DAO — organisation autonome décentralisée — est une entité on-chain qui détient des fonds et agit via la logique d'un smart contract et les votes des détenteurs de token. The DAO (T majuscule, D majuscule) fut l'exemple précoce le plus ambitieux. Construit par slock.it et lancé sur Ethereum en avril 2016 via une vente publique qui a levé plus de 11,5 millions d'ETH — environ 150 M $ à l'époque, près de 14 % de tout l'ETH existant. Les détenteurs pouvaient voter quelles propositions financer, en supposant que les retours leur reviendraient.

Le smart contract de The DAO était complexe. Plusieurs chercheurs en sécurité avaient publiquement soulevé des inquiétudes sur des motifs spécifiques — en particulier autour de la fonction permettant aux détenteurs de séparer leur part dans un DAO enfant. Le chemin de code concerné effectuait un appel externe avant de mettre à jour le solde interne, motif désormais reconnu comme dangereux : réentrance. Des correctifs ont été proposés mais non déployés avant l'exploit.

Ceci est pédagogique, pas un conseil financier. Le hack du DAO compte parce que les choix faits en réponse ont façonné pour toujours le sens d'« immuable » sur Ethereum.

Ce qui s'est vraiment passé : le drainage et le fork

L'exploit et la réponse se sont déroulés sur des semaines.

• 17 juin 2016. Un attaquant a commencé à exploiter le bug. L'attaque appelait récursivement la fonction split de The DAO avant que le contrat ne mette à jour le solde interne de l'attaquant, permettant des retraits répétés sur le même solde. Environ 3,6 millions d'ETH ont été drainés vers un DAO enfant contrôlé par l'attaquant.
• La particularité des 28 jours. La structure de The DAO imposait que les fonds drainés restent dans le DAO enfant pendant 28 jours avant de pouvoir en sortir. Cela a donné à la communauté Ethereum une fenêtre pour réagir avant que l'attaquant ne puisse dépenser.
• Fin juin 2016 : débat. Deux réponses ont été débattues. Premièrement, un soft fork : changement de règles bloquant les transactions liées aux fonds drainés, gelant l'attaquant. Deuxièmement, un hard fork : changement de règles déplaçant les fonds drainés vers un contrat de remboursement où les détenteurs pourraient retirer leur ETH d'origine.
• Tentative et retrait du soft fork. On a trouvé que la proposition de soft fork avait une vulnérabilité permettant une attaque DoS sur les mineurs Ethereum. Elle a été retirée.
• 20 juillet 2016 : hard fork exécuté. La communauté Ethereum a exécuté un hard fork au bloc 1 920 000. Le fork a déplacé l'ETH drainé vers un contrat de remboursement, permettant aux détenteurs de retirer leur ETH d'origine à taux fixe.
• La scission. Une minorité de mineurs et d'utilisateurs a refusé le fork, arguant que l'immutabilité était la promesse centrale d'une blockchain et qu'intervenir pour annuler un exploit créait un précédent dangereux. Ils ont continué à miner et utiliser la chaîne d'origine. Cette chaîne est devenue Ethereum Classic (ETC). La chaîne forked — celle ayant remboursé — a gardé le nom Ethereum (ETH) et le soutien de la Fondation Ethereum.

L'attaquant, dont l'identité reste formellement non confirmée malgré plusieurs revendications d'enquêtes, s'est retrouvé avec l'ETH drainé sur la chaîne Ethereum Classic, qui n'avait pas remboursé. Le fork n'a pas annulé l'exploit sur ETC ; il a seulement indemnisé les détenteurs de tokens DAO sur ETH.

Les protagonistes

• Contributeurs de The DAO et slock.it. L'équipe qui a construit et promu The DAO. Ils n'étaient pas les attaquants on-chain, mais le bug était dans leur code.
• Vitalik Buterin et la Fondation Ethereum. Ils ont défendu le hard fork comme réponse protégeant le plus grand nombre. Leur prise de position a en pratique fixé la direction de la chaîne Ethereum.
• L'attaquant. Identité formellement non confirmée. Un article d'enquête de Forbes en 2022 a nommé un individu comme suspect, mais l'affirmation est contestée et il n'y a pas eu de condamnation pénale.
• La minorité devenue Ethereum Classic. Un groupe de mineurs, développeurs et utilisateurs qui a refusé le fork par principe, estimant que l'immutabilité l'emporte sur toute récupération. Inclut des développeurs ayant construit et maintenu Ethereum Classic comme chaîne séparée.
• Détenteurs des tokens DAO. Environ 11 000 wallets détenaient des tokens DAO. Après le hard fork, ils ont pu retirer leur ETH d'origine depuis le contrat de remboursement sur ETH.

L'après : deux chaînes, un vocabulaire et un champ de recherche

L'impact du hack du DAO s'est étendu bien au-delà de juin 2016.

• Deux chaînes. Ethereum (ETH) et Ethereum Classic (ETC) ont continué d'opérer depuis 2016. Leurs valorisations et écosystèmes ont divergé radicalement — Ethereum est des centaines de fois plus gros en capitalisation en 2026 — mais ETC existe encore comme expérience continue d'immutabilité stricte.
• Un champ de sécurité des smart contracts. La réentrance est devenue un exemple fondateur dans l'éducation à la sécurité des smart contracts. Les motifs d'OpenZeppelin, les reentrancy guards de Solidity, les outils de vérification formelle et la pratique des bug bounties remontent conceptuellement à l'incident DAO.
• Le débat sur l'immutabilité. Le hard fork a rendu explicite ce qui était implicite : à conséquence suffisante, la communauté Ethereum pouvait et allait modifier la chaîne en réponse à des considérations off-chain. Selon la perspective, c'est une caractéristique (le réseau peut se rétablir) ou un bug (le réseau n'est pas vraiment immuable).
• Le rapport DAO de la SEC (juillet 2017). La SEC a publié un Section 21(a) Report concluant que les tokens DAO étaient des securities selon le Howey Test. Ce rapport a en pratique défini le cadre réglementaire de la bulle ICO 2017.
• Expériences ultérieures de gouvernance on-chain. Toute tentative ultérieure — MakerDAO, gouvernance Compound, OlympusDAO, Gitcoin, l'Optimism Collective moderne — a dû naviguer la même tension entre code immuable, jugement humain et protection des parties prenantes que l'incident DAO a révélée.

Les leçons

Le hack du DAO est l'un des incidents les plus étudiés en crypto. Leçons honnêtes :

• Les smart contracts sont des programmes, et les programmes ont des bugs. The DAO détenait plus de valeur que la plupart des logiciels financiers en production, écrit par une petite équipe sous pression, audité mais pas formellement vérifié. Le bug spécifique (réentrance) était décrit dans la littérature ; utiliser à grande échelle des motifs connus comme dangereux a rendu la perte possible.
• L'immutabilité est un choix de la communauté, pas une propriété du substrat. Le hard fork a démontré qu'à conséquence suffisante, le réseau interviendrait. Les chaînes suivantes ont varié dans la rigueur. Ethereum Classic existe en partie pour maintenir que l'immutabilité n'est pas négociable.
• Les décisions de récupération créent des précédents. Le fork du DAO a été cité dans des crises ultérieures — récupérations après hacks, exploits de ponts, dé-pegs de stablecoins — comme précédent d'intervention communautaire. Certaines chaînes l'ont rejeté ; d'autres adopté ; presque toutes l'ont dû raisonner.
• Les audits sont nécessaires mais pas suffisants. The DAO avait été audité. Les auditeurs avaient soulevé des préoccupations. L'exploit a quand même eu lieu. La sécurité réelle dépend de plusieurs défenses — vérification formelle, bug bounties, processus de mise à jour conservateurs, contrôles à time-lock — pas d'un seul audit.
• La gouvernance est une couche qui demande du design. La gouvernance par détenteurs de tokens de The DAO était nouvelle et insuffisamment spécifiée. Toute DAO sérieuse ultérieure a dû concevoir la gouvernance avec bien plus de soin : quorum, pondérations, périodes de délai, procédures d'urgence. The DAO est le cas qui a rendu ces préoccupations concrètes.

Soyons clairs sur ce que le hack du DAO ne prouve pas. Cela ne prouve pas que tous les smart contracts sont dangereux ni que les organisations on-chain ne peuvent fonctionner. Cela prouve que les smart contracts détenant beaucoup de valeur doivent être conçus et audités avec le sérieux d'un logiciel financier en production — et que la communauté élargie doit avoir réfléchi, à l'avance, à ce qu'elle fera en cas de problème.

Surveillez où démarrent les prochains incidents de smart contracts

Les incidents de smart contracts continuent à chaque cycle — exploits de ponts, drainages de protocoles de prêt, attaques de gouvernance. Les motifs — chemins de code connus comme dangereux, déploiements sous pression, réponses contestées — se répètent. Zippfeed suit les titres sécurité DeFi et smart contracts sur de nombreuses sources avec scoring de sentiment et d'importance, pour voir incidents et réponses se dérouler — et apprendre avant que l'exposition ne devienne perte. Ceci est pédagogique, pas un conseil financier.