{"id":547,"date":"2026-09-11T22:27:05","date_gmt":"2026-09-11T22:27:05","guid":{"rendered":"https:\/\/hoge.gg\/fr\/post-mortem-hack-liquid-exploit-elements-2026\/"},"modified":"2026-09-11T22:27:05","modified_gmt":"2026-09-11T22:27:05","slug":"post-mortem-hack-liquid-exploit-elements-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/fr\/post-mortem-hack-liquid-exploit-elements-2026\/","title":{"rendered":"Post-mortem : anatomie du hack Liquid \u00e0 265 millions d’euros"},"content":{"rendered":"

Le 6 septembre 2026 \u00e0 15 h 53 UTC, un attaquant a fait na\u00eetre pr\u00e8s de 4 000 L-BTC qui n’existaient pas une seconde plus t\u00f4t, puis les a convertis en bitcoins natifs. En quelques heures, l’\u00e9quivalent d’environ 265 millions d’euros (quelque 320 millions de dollars au moment des faits) a quitt\u00e9 la r\u00e9serve f\u00e9d\u00e9r\u00e9e du Liquid Network, la sidechain Bitcoin op\u00e9r\u00e9e par Blockstream et utilis\u00e9e par des dizaines de plateformes d’\u00e9change, comme l’a document\u00e9 CoinDesk<\/a>. Au cours du week-end, la sidechain a cess\u00e9 de produire des blocs, une correction d’urgence a \u00e9t\u00e9 d\u00e9ploy\u00e9e, et une partie des fonds est revenue. \u00c0 premi\u00e8re vue, un braquage on-chain de plus dans une ann\u00e9e 2026 d\u00e9j\u00e0 lourde.<\/p>

Sauf que cette affaire sort du lot pour deux raisons. La premi\u00e8re : il ne s’agit pas de cl\u00e9s vol\u00e9es, mais d’un vrai bug de code, une esp\u00e8ce devenue rare dans une ann\u00e9e o\u00f9 l’essentiel des pertes provient de la compromission d’humains et de signatures. La seconde : ce que l’industrie retiendra n’est pas tant le hold-up que le document cens\u00e9 le suivre, le post-mortem, et la bataille publique qui s’est nou\u00e9e autour de lui.<\/p>

Un post-mortem d’exploit n’est pas un communiqu\u00e9 de presse. C’est un rapport d’incident qui r\u00e9pond \u00e0 trois questions : qu’est-ce qui a cass\u00e9, qu’est-ce qui a \u00e9t\u00e9 perdu, et qu’est-ce qui va changer. Bien fait, il fait progresser tout l’\u00e9cosyst\u00e8me. B\u00e2cl\u00e9, trop lisse ou publi\u00e9 trop tard, il devient un exercice de relations publiques. L’affaire Liquid, avec son diff\u00e9rend ouvert sur la divulgation, sa querelle s\u00e9mantique autour du \u00ab white hat \u00bb et son refus assum\u00e9 de payer une ran\u00e7on, offre un cas d’\u00e9cole pour comprendre ce qui s\u00e9pare un vrai post-mortem d’un habillage.<\/p>

\u00ab Post-mortem \u00bb : ce que le mot veut vraiment dire<\/h2>

Emprunt\u00e9 \u00e0 la m\u00e9decine l\u00e9gale, le terme \u00ab post-mortem \u00bb d\u00e9signe l’autopsie d’un incident. Dans la culture de l’ing\u00e9nierie, il vient des \u00e9quipes de fiabilit\u00e9 (les SRE) qui, apr\u00e8s chaque panne, r\u00e9digent un compte rendu d\u00e9taill\u00e9 pour \u00e9viter la r\u00e9cidive. La crypto a h\u00e9rit\u00e9 de cette pratique, avec une contrainte suppl\u00e9mentaire : ici, la panne se chiffre souvent en dizaines de millions, et le rapport est lu par des attaquants autant que par des d\u00e9veloppeurs.<\/p>

Un post-mortem digne de ce nom contient plusieurs briques : un r\u00e9sum\u00e9 de l’incident, une chronologie horodat\u00e9e (en UTC, pour lever toute ambigu\u00eft\u00e9), une cause racine nomm\u00e9e sans d\u00e9tour, les facteurs aggravants, un chiffrage de l’impact, les mesures d’urgence prises, puis un plan de rem\u00e9diation avec des actions dat\u00e9es et un responsable pour chacune. Le m\u00e9dia sp\u00e9cialis\u00e9 rekt.news<\/a>, qui diss\u00e8que les exploits depuis des ann\u00e9es, rappelle une r\u00e8gle simple : un rapport qui n’aboutit \u00e0 aucune action concr\u00e8te n’est pas un post-mortem, c’est une consolation.<\/p>

La deuxi\u00e8me exigence est culturelle : le post-mortem doit \u00eatre \u00ab blameless \u00bb, c’est-\u00e0-dire sans recherche de bouc \u00e9missaire. L’id\u00e9e, import\u00e9e des grandes \u00e9quipes d’infrastructure, est que punir l’erreur humaine pousse les gens \u00e0 la cacher, alors que documenter chaque erreur pour la transformer en garde-fou technique am\u00e9liore le syst\u00e8me. Pour chaque faute humaine identifi\u00e9e, un vrai post-mortem propose une barri\u00e8re automatique correspondante. C’est pr\u00e9cis\u00e9ment sur ce point, on le verra, que l’affaire Liquid s’est tendue.<\/p>

Chronologie : du 1er au 11 septembre<\/h2>

La force d’un post-mortem tient d’abord \u00e0 sa chronologie. Voici celle de l’incident Liquid, reconstitu\u00e9e \u00e0 partir du rapport d’incident publi\u00e9 par le r\u00e9seau et des analyses techniques ind\u00e9pendantes.<\/p>

Horodatage (UTC)<\/th>\u00c9v\u00e9nement<\/th><\/tr><\/thead>
1 sept. 2026<\/td>Le correctif du bug de cache est fusionn\u00e9 publiquement dans le d\u00e9p\u00f4t Elements, sous un intitul\u00e9 descriptif<\/td><\/tr>
6 sept., 15 h 53<\/td>Exploitation au bloc Liquid 4 050 336 ; cr\u00e9ation d’environ 3 998 L-BTC frauduleux<\/td><\/tr>
6 sept. (soir\u00e9e)<\/td>L’attaquant proc\u00e8de \u00e0 un peg-out et convertit les jetons en BTC natifs<\/td><\/tr>
7 sept., 01 h 09<\/td>Blockstream d\u00e9ploie un correctif d’urgence sur les n\u0153uds de la f\u00e9d\u00e9ration ; le r\u00e9seau est fig\u00e9<\/td><\/tr>
7 sept., 16 h 09<\/td>L’attaquant renvoie environ 3 400 BTC \u00e0 la f\u00e9d\u00e9ration<\/td><\/tr>
8 sept.<\/td>Publication du rapport d’incident officiel<\/td><\/tr>
9 sept.<\/td>Sortie d’Elements v23.3.4, corrigeant durablement la faille<\/td><\/tr>
10 sept.<\/td>Reprise de la production de blocs ; les peg-outs restent suspendus par pr\u00e9caution<\/td><\/tr>
11 sept.<\/td>Blockstream refuse la ran\u00e7on pour les ~598,5 BTC manquants<\/td><\/tr><\/tbody><\/table><\/figure>

Ce tableau, en apparence anodin, contient d\u00e9j\u00e0 le n\u0153ud de l’affaire : la ligne du 1er septembre. Cinq jours avant le vol, le correctif existait, publiquement, dans le code source. Nous y reviendrons, car c’est cette ligne qui a mis le feu aux poudres.<\/p>

La faille : une collision de cl\u00e9 de cache<\/h2>

Pour valider une transaction confidentielle, Liquid s’appuie sur des \u00ab rangeproofs \u00bb, des preuves cryptographiques (des bulletproofs) qui garantissent qu’un montant cach\u00e9 est bien positif, sans en r\u00e9v\u00e9ler la valeur. V\u00e9rifier ces preuves co\u00fbte cher en calcul. Comme la plupart des logiciels de n\u0153ud, Elements met donc en cache les r\u00e9sultats de v\u00e9rification : une preuve d\u00e9j\u00e0 valid\u00e9e n’est pas recalcul\u00e9e si elle se repr\u00e9sente. Cette optimisation est banale et, en principe, sans danger.<\/p>

Le probl\u00e8me tenait \u00e0 la fa\u00e7on dont le logiciel construisait la cl\u00e9 d’entr\u00e9e de ce cache. Selon l’analyse de SlowMist<\/a>, cette cl\u00e9 \u00e9tait un hash sal\u00e9 calcul\u00e9 sur la simple concat\u00e9nation de plusieurs champs : la preuve, l’engagement (commitment), le g\u00e9n\u00e9rateur d’actif et le scriptPubKey, sans aucun d\u00e9limiteur de longueur. Or deux de ces champs sont de taille variable et se trouvent aux extr\u00e9mit\u00e9s oppos\u00e9es du flux. En d\u00e9pla\u00e7ant la fronti\u00e8re entre eux, un attaquant pouvait faire en sorte que deux ensembles de donn\u00e9es pourtant diff\u00e9rents produisent exactement la m\u00eame suite d’octets, donc la m\u00eame cl\u00e9 de cache.<\/p>

La cons\u00e9quence est vertigineuse : une preuve valide, d\u00e9j\u00e0 mise en cache, pouvait \u00ab couvrir \u00bb une preuve invalide entrant en collision avec elle. Le n\u0153ud consultait son cache, y trouvait un verdict \u00ab valide \u00bb et laissait passer une transaction qui aurait d\u00fb \u00eatre rejet\u00e9e. C’est ce que CertiK<\/a> d\u00e9crit comme une collision de cl\u00e9 de cache : la faille n’\u00e9tait pas dans la cryptographie des bulletproofs elle-m\u00eame, r\u00e9put\u00e9e solide, mais dans la plomberie d’optimisation autour d’elle. R\u00e9sultat, l’attaquant a pu forger des preuves accept\u00e9es \u00e0 tort et cr\u00e9er pr\u00e8s de 3 998 L-BTC \u00e0 partir de rien, avant de les \u00e9changer contre du bitcoin r\u00e9el via une plateforme approuv\u00e9e du r\u00e9seau, incapable de distinguer les jetons frauduleux des authentiques.<\/p>

Le correctif, sobrement intitul\u00e9 \u00ab sigcache: harden range proof cache keys \u00bb, durcit le calcul de cette cl\u00e9 et ajoute une option permettant de d\u00e9sactiver enti\u00e8rement le cache de rangeproofs. Il a \u00e9t\u00e9 publi\u00e9 dans Elements v23.3.4 le 9 septembre, comme l’indiquent les notes de version sur GitHub<\/a>. Un correctif d’une simplicit\u00e9 d\u00e9concertante pour une faille \u00e0 neuf chiffres.<\/p>

Un bug de code dans un monde de cl\u00e9s vol\u00e9es<\/h2>

Ce qui rend l’incident Liquid presque anachronique, c’est sa nature. En 2026, le code n’est plus le maillon faible. Selon les donn\u00e9es compil\u00e9es par CertiK et reprises par crypto.news<\/a>, la DeFi a perdu au moins 1,3 milliard de dollars sur les huit premiers mois de l’ann\u00e9e, et la majorit\u00e9 de cette somme provient de cl\u00e9s priv\u00e9es ou d’acc\u00e8s administrateurs compromis, pas de bugs de contrat intelligent.<\/p>

Le cofondateur de CertiK, Ronghui Gu, r\u00e9sume la bascule sans d\u00e9tour : \u00ab A protocol can pass a flawless code audit and still lose millions because of a compromised admin key \u00bb (un protocole peut r\u00e9ussir un audit de code sans faute et perdre malgr\u00e9 tout des millions \u00e0 cause d’une cl\u00e9 d’administration compromise). Autrement dit, la surface d’attaque a migr\u00e9 vers le haut de la pile : les signataires, la gouvernance, les humains.<\/p>

Vecteur (2026)<\/th>Pertes estim\u00e9es<\/th>Exemple embl\u00e9matique<\/th><\/tr><\/thead>
Cl\u00e9s \/ acc\u00e8s admin compromis<\/td>~575 M$<\/td>Drift, Kelp DAO<\/td><\/tr>
D\u00e9fauts de v\u00e9rification de bridge<\/td>~363 M$<\/td>Incidents multiples<\/td><\/tr>
Bug de firmware \/ entropie<\/td>~130 M$<\/td>Coldcard<\/td><\/tr>
Attaque de gouvernance<\/td>~8,5 M$<\/td>Term Labs<\/td><\/tr>
Bug de code de protocole<\/td>~319 M$<\/td>Liquid Network<\/td><\/tr><\/tbody><\/table><\/figure>

Les quatre premi\u00e8res lignes de ce tableau proviennent du d\u00e9compte de crypto.news ; la cinqui\u00e8me, c’est Liquid. Dans ce paysage, la sidechain fait figure d’exception : un vrai bug de code, dans un logiciel open source audit\u00e9, revu et \u00e9prouv\u00e9 depuis des ann\u00e9es. C’est aussi ce qui rend son post-mortem si int\u00e9ressant, parce qu’il ne peut pas se cacher derri\u00e8re \u00ab on nous a vol\u00e9 nos cl\u00e9s \u00bb. Le fautif est ici une ligne de code, et il porte un nom, un num\u00e9ro de commit et une date.<\/p>

La f\u00e9d\u00e9ration 11 sur 15 : la multisig n’a rien vu venir<\/h2>

Liquid n’est pas une blockchain ouverte comme Bitcoin. C’est une sidechain f\u00e9d\u00e9r\u00e9e : un consortium de membres (plateformes d’\u00e9change, teneurs de march\u00e9, soci\u00e9t\u00e9s d’infrastructure) op\u00e8re le r\u00e9seau. La garde des bitcoins mis en r\u00e9serve repose sur un ensemble de n\u0153uds signataires, les \u00ab functionaries \u00bb, et sur une multisig o\u00f9 onze signatures sur quinze sont n\u00e9cessaires pour autoriser un peg-out, c’est-\u00e0-dire un retrait vers la cha\u00eene Bitcoin principale.<\/p>

On pourrait croire qu’une telle multisig prot\u00e8ge d’un vol. Elle prot\u00e8ge d’un type de vol : celui o\u00f9 un attaquant s’empare d’une cl\u00e9, ou m\u00eame de plusieurs. Elle ne prot\u00e8ge pas d’un bug de consensus. Dans l’incident du 6 septembre, les onze functionaries ont sign\u00e9 un peg-out qui leur paraissait parfaitement l\u00e9gitime, parce que leurs propres n\u0153uds, ex\u00e9cutant le code vuln\u00e9rable, consid\u00e9raient les L-BTC frauduleux comme authentiques. La multisig a fonctionn\u00e9 exactement comme pr\u00e9vu ; c’est la r\u00e9alit\u00e9 qu’elle validait qui \u00e9tait fauss\u00e9e.<\/p>

C’est une le\u00e7on r\u00e9currente des post-mortems de d\u00e9positaires : la s\u00e9curit\u00e9 d’une r\u00e9serve ne vaut que celle du logiciel qui d\u00e9cide ce qui est vrai. Multiplier les signataires ne sert \u00e0 rien si tous consultent la m\u00eame v\u00e9rit\u00e9 corrompue. Le sujet rejoint un d\u00e9bat plus large sur la garde institutionnelle, \u00e0 l’heure o\u00f9 les plus gros mouvements on-chain sont le fait de d\u00e9positaires<\/a> et non plus de baleines individuelles. Quand la valeur se concentre derri\u00e8re quelques cl\u00e9s partag\u00e9es, le point de d\u00e9faillance se d\u00e9place du portefeuille vers le code qui l’orchestre.<\/p>

Le patch qui n’\u00e9tait pas silencieux<\/h2>

Revenons \u00e0 la ligne du 1er septembre. La correction du bug de cache n’a pas \u00e9t\u00e9 d\u00e9couverte par l’attaquant au prix d’un travail de reverse engineering : elle \u00e9tait d\u00e9j\u00e0 publique, fusionn\u00e9e dans le d\u00e9p\u00f4t Elements sur GitHub, cinq jours avant l’exploitation. Pire, elle portait un intitul\u00e9 descriptif qui pointait pr\u00e9cis\u00e9ment la nature du probl\u00e8me.<\/p>

C’est le sc\u00e9nario du cauchemar en s\u00e9curit\u00e9 open source : le \u00ab N-day \u00bb. Un correctif publi\u00e9 avant d’\u00eatre d\u00e9ploy\u00e9 partout est une carte routi\u00e8re offerte aux attaquants. Ceux qui surveillent les commits des logiciels critiques, et ils sont nombreux, lisent chaque changement de code comme un indice. Un correctif de s\u00e9curit\u00e9 annonc\u00e9 comme tel, sans coordination de d\u00e9ploiement, revient \u00e0 publier la combinaison du coffre en promettant de changer la serrure \u00ab bient\u00f4t \u00bb.<\/p>

La bonne pratique, dans ce cas, est la divulgation coordonn\u00e9e : on pr\u00e9pare le correctif en priv\u00e9, on donne aux op\u00e9rateurs de n\u0153uds le temps de se mettre \u00e0 jour, puis on publie les d\u00e9tails. Le fait que le correctif Liquid ait \u00e9t\u00e9 visible, d\u00e9crit et non d\u00e9ploy\u00e9 pendant cinq jours est, du strict point de vue du post-mortem, la question la plus importante de toute l’affaire. Comment un patch de s\u00e9curit\u00e9 critique a-t-il pu rester expos\u00e9 si longtemps sans mise \u00e0 jour coordonn\u00e9e des functionaries ? C’est l\u00e0 que le r\u00e9cit officiel et celui de ses d\u00e9tracteurs divergent.<\/p>

White hat ou voleur ? La bataille s\u00e9mantique<\/h2>

L’attaquant s’est pr\u00e9sent\u00e9 comme un \u00ab white hat \u00bb, un hacker \u00e9thique. Il a communiqu\u00e9 avec Blockstream par messages inscrits directement sur la cha\u00eene Bitcoin, avec une offre conditionnelle : \u00ab Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix \u00bb (corrigez d’abord le bug ; la cha\u00eene est en danger ; assurez-vous que chaque n\u0153ud est patch\u00e9 ; ensuite nous renverrons l’argent en toute s\u00e9curit\u00e9), rapporte CoinDesk.<\/p>

Il a tenu parole \u00e0 85 %. Le 7 septembre, environ 3 400 BTC sont revenus dans le portefeuille de la f\u00e9d\u00e9ration. Restaient environ 598,5 BTC, soit pr\u00e8s de 40 millions d’euros (environ 47 millions de dollars), que l’attaquant proposait de conserver au titre d’une \u00ab prime \u00bb de 10 %.<\/p>

Blockstream a refus\u00e9 net. Dans une d\u00e9claration reprise par The Block<\/a>, l’entreprise tranche : \u00ab Taking assets without authorization and withholding their return is a crime, not responsible disclosure. It is not white-hat activity. It is theft \u00bb (prendre des actifs sans autorisation et retenir leur restitution est un crime, pas une divulgation responsable ; ce n’est pas du white-hat, c’est du vol). L’argument de fond : c\u00e9der reviendrait \u00e0 instaurer un pr\u00e9c\u00e9dent o\u00f9 des d\u00e9veloppeurs open source doivent payer des ran\u00e7ons sup\u00e9rieures \u00e0 leur propre participation \u00e9conomique au projet.<\/p>

La fronti\u00e8re entre white hat et ma\u00eetre chanteur est effectivement t\u00e9nue. La r\u00e8gle commun\u00e9ment admise dans la s\u00e9curit\u00e9 offensive est simple : un white hat ne prend pas les fonds. Il d\u00e9montre la faille, alerte, et laisse l’argent en place. Pr\u00e9lever d’abord, n\u00e9gocier ensuite, puis conserver une part \u00ab en r\u00e9compense \u00bb rel\u00e8ve d’une autre cat\u00e9gorie, quel que soit le vocabulaire employ\u00e9. Ce d\u00e9bat n’est pas neuf ; il ressurgit \u00e0 chaque gros exploit dit \u00ab amiable \u00bb, et il empoisonne syst\u00e9matiquement la r\u00e9daction sereine d’un post-mortem.<\/p>

Le diff\u00e9rend sur la divulgation<\/h2>

C’est ici que le post-mortem cesse d’\u00eatre un document et devient un champ de bataille. Un collectif de s\u00e9curit\u00e9 b\u00e9n\u00e9vole, la Bitcoin Red Team, affirme avoir pr\u00e9venu Blockstream avant le hack. Son colead, connu sous le pseudonyme Calle, a r\u00e9sum\u00e9 sa position d’une formule cinglante : \u00ab Turns out it only costs you 600 BTC to ignore an email from the red team \u00bb (il s’av\u00e8re qu’il ne co\u00fbte que 600 BTC d’ignorer un e-mail de la red team), rapporte Bitcoin.com News<\/a>.<\/p>

Blockstream conteste. Samson Mow, ancien directeur de la strat\u00e9gie de l’entreprise, a ni\u00e9 tout e-mail ignor\u00e9 et estim\u00e9 que les insinuations de la Red Team \u00ab diminuaient le professionnalisme \u00bb du collectif. De son c\u00f4t\u00e9, le fondateur de Blockstream, Adam Back, a attribu\u00e9 le bug \u00e0 \u00ab an incorrect bug fix, to an AI-found bug which was also a non-critical bug \u00bb (un correctif erron\u00e9, apport\u00e9 \u00e0 un bug d\u00e9tect\u00e9 par IA et jug\u00e9 non critique). Calle a r\u00e9torqu\u00e9 que ces d\u00e9clarations \u00e9taient inexactes et incompl\u00e8tes, et promis de publier son propre r\u00e9cit d\u00e9taill\u00e9 du processus de divulgation une fois que Blockstream aurait publi\u00e9 son post-mortem complet.<\/p>

Peu importe, \u00e0 ce stade, qui a raison sur les dates : le simple fait que la chronologie de la divulgation soit contest\u00e9e en public illustre pourquoi la transparence est la colonne vert\u00e9brale d’un bon post-mortem. Quand chaque partie raconte une histoire diff\u00e9rente, l’\u00e9cosyst\u00e8me n’apprend rien ; il choisit un camp. Un post-mortem \u00ab blameless \u00bb et v\u00e9rifiable, avec les horodatages des courriels et des commits d\u00e9pos\u00e9s noir sur blanc, aurait \u00e9teint la pol\u00e9mique au lieu de l’alimenter. C’est le paradoxe : plus un incident est technique, plus sa r\u00e9solution finit par se jouer sur la confiance.<\/p>

Qui paie l’ardoise ?<\/h2>

Restait la question la plus concr\u00e8te : qui absorbe les quelque 40 millions d’euros manquants ? Adam Back a r\u00e9pondu que Blockstream couvrirait la parit\u00e9 1 pour 1 entre le L-BTC et le bitcoin, \u00e9pongeant le d\u00e9ficit pour que les d\u00e9tenteurs de L-BTC soient rendus entiers, selon Crypto Times<\/a>. \u00c0 l’heure o\u00f9 nous \u00e9crivons, le bitcoin s’\u00e9change autour de 66 000 euros (CoinGecko<\/a>), ce qui laisse la ligne comptable ouverte tant que les 598,5 BTC restent dans la nature.<\/p>

C’est un choix lourd de sens. Dans un syst\u00e8me f\u00e9d\u00e9r\u00e9, la promesse implicite est que le peg tient : un L-BTC vaut toujours un BTC. Laisser le d\u00e9ficit aux utilisateurs aurait cass\u00e9 cette promesse et, avec elle, la raison d’\u00eatre de la sidechain. En couvrant le trou, Blockstream prot\u00e8ge la confiance, mais transforme un bug technique en perte d’entreprise.<\/p>

C’est la m\u00eame logique \u00e9conomique que l’on retrouve partout o\u00f9 un interm\u00e9diaire garantit un actif adoss\u00e9 : la question n’est jamais seulement \u00ab qui a \u00e9t\u00e9 pirat\u00e9 \u00bb, mais \u00ab qui a promis de rendre entier \u00bb. On la retrouve, sous d’autres formes, dans l’\u00e9conomie des ETF Bitcoin, o\u00f9 les frais r\u00e9mun\u00e8rent pr\u00e9cis\u00e9ment la garde et la garantie op\u00e9rationnelle<\/a>. Un post-mortem honn\u00eate devrait toujours r\u00e9pondre \u00e0 cette question de l’ardoise, car elle conditionne la survie de la confiance bien plus que le d\u00e9tail cryptographique.<\/p>

Anatomie compar\u00e9e : Bybit, Coldcard, Drift, Liquid<\/h2>

Pour mesurer ce qui fait un bon post-mortem, il faut comparer. Voici quatre incidents majeurs r\u00e9cents, tr\u00e8s diff\u00e9rents par leur vecteur, et le retour d’exp\u00e9rience qui a suivi.<\/p>

Incident<\/th>Date<\/th>Montant<\/th>Vecteur<\/th>Cause racine<\/th><\/tr><\/thead>
Bybit<\/td>f\u00e9vr. 2025<\/td>~1,4 Md$<\/td>Infrastructure<\/td>Poste d\u00e9veloppeur Safe compromis, JavaScript malveillant inject\u00e9 sur l’interface (groupe Lazarus)<\/td><\/tr>
Coldcard<\/td>juil.-ao\u00fbt 2026<\/td>~116 M$<\/td>Firmware \/ entropie<\/td>G\u00e9n\u00e9rateur pseudo-al\u00e9atoire faible depuis mars 2021, graines brute-for\u00e7ables hors ligne<\/td><\/tr>
Drift<\/td>avr. 2026<\/td>~285 M$<\/td>Ing\u00e9nierie sociale<\/td>Op\u00e9ration DPRK de six mois, prise de contr\u00f4le du Security Council via durable nonce<\/td><\/tr>
Liquid<\/td>sept. 2026<\/td>~319 M$<\/td>Bug de code<\/td>Collision de cl\u00e9 dans le cache de v\u00e9rification des rangeproofs<\/td><\/tr><\/tbody><\/table><\/figure>

Chacun raconte une histoire diff\u00e9rente. Le post-mortem de Bybit, publi\u00e9 par l’\u00e9diteur du portefeuille Safe avec le concours de Mandiant, est souvent cit\u00e9 en exemple : il retrace pr\u00e9cis\u00e9ment comment le groupe Lazarus a d\u00e9tourn\u00e9 des jetons de session AWS d’un d\u00e9veloppeur pour injecter du JavaScript malveillant sur l’interface app.safe.global, en ciblant sp\u00e9cifiquement les signataires de Bybit, d\u00e9taille Cointelegraph<\/a>. Le cas Coldcard, analys\u00e9 par TRM Labs<\/a>, montre une faille de 2021 refaisant surface cinq ans plus tard : un g\u00e9n\u00e9rateur d’al\u00e9a affaibli ramenait l’entropie de certaines graines de 128 \u00e0 parfois 40 bits, les rendant brute-for\u00e7ables sans jamais toucher l’appareil. Quant \u00e0 Drift, son post-mortem d\u00e9taille une infiltration patiente de six mois attribu\u00e9e \u00e0 la Cor\u00e9e du Nord, o\u00f9 les attaquants ont jou\u00e9 le r\u00f4le d’un fonds de trading cr\u00e9dible pendant des mois avant de frapper.<\/p>

Ces quatre r\u00e9cits ont un point commun : les meilleurs post-mortems ne se contentent pas de d\u00e9crire le \u00ab comment \u00bb, ils exposent le \u00ab pourquoi \u00e7a a mis si longtemps \u00bb. C’est le test d\u00e9cisif de l’honn\u00eatet\u00e9.<\/p>

Ce que 2026 nous apprend : les cl\u00e9s, pas le code<\/h2>

Mis bout \u00e0 bout, ces incidents dessinent une ann\u00e9e charni\u00e8re. TRM Labs a recens\u00e9 plus de 200 attaques sur le premier semestre 2026, pour pr\u00e8s d’un milliard de dollars d\u00e9rob\u00e9s ; CertiK avance un chiffre plus \u00e9lev\u00e9, autour de 1,32 milliard. Surtout, la r\u00e9partition a chang\u00e9 : les compromissions d’infrastructure repr\u00e9sentent une minorit\u00e9 d’incidents mais l’\u00e9crasante majorit\u00e9 des montants perdus.<\/p>

Le message pour les \u00e9quipes est double. D’abord, auditer le code ne suffit plus ; il faut auditer les humains, les processus de signature, la cha\u00eene d’approvisionnement logicielle et les acc\u00e8s. Ensuite, la qualit\u00e9 de la r\u00e9ponse compte autant que la pr\u00e9vention. Un protocole qui publie vite un post-mortem honn\u00eate, coordonne le d\u00e9ploiement d’un correctif et communique clairement limite la contagion. \u00c0 l’inverse, l’opacit\u00e9 nourrit la panique et la sp\u00e9culation.<\/p>

Le fait que des soci\u00e9t\u00e9s d’audit comme CertiK soient elles-m\u00eames entr\u00e9es en bourse et scrut\u00e9es par Wall Street<\/a> ne fait qu’augmenter la pression sur la rigueur de ces analyses. Un rapport d’incident b\u00e2cl\u00e9 n’est plus seulement une faute morale ; c’est un risque r\u00e9putationnel, parfois boursier. Paradoxalement, cette exposition pourrait pousser l’industrie vers de meilleurs post-mortems, \u00e0 condition que la transparence ne devienne pas un simple argument marketing.<\/p>

Audit\u00e9, et quand m\u00eame pirat\u00e9<\/h2>

L’incident Liquid rappelle une v\u00e9rit\u00e9 inconfortable : un logiciel peut \u00eatre open source, audit\u00e9 et \u00e9prouv\u00e9, et receler malgr\u00e9 tout une faille latente pendant des ann\u00e9es. Le cache de rangeproofs n’\u00e9tait pas un morceau de code obscur ; c’\u00e9tait une optimisation de performance dans un projet scrut\u00e9 par certains des cryptographes les plus pointus du secteur. La faille n’\u00e9tait pas dans la cryptographie \u00ab difficile \u00bb, mais dans la plomberie \u00ab facile \u00bb qui l’entoure. Le diable, comme toujours, s’\u00e9tait log\u00e9 dans un d\u00e9tail d’impl\u00e9mentation.<\/p>

C’est une le\u00e7on que les investisseurs et les utilisateurs devraient graver : le label \u00ab audit\u00e9 \u00bb n’est pas un talisman. Il r\u00e9duit le risque, il ne l’annule pas. Cette confusion entretient d’ailleurs tout un march\u00e9 de la r\u00e9assurance de fa\u00e7ade, jusqu’aux faux audits, o\u00f9 un badge de s\u00e9curit\u00e9 usurp\u00e9 sert d’app\u00e2t<\/a>. Un vrai audit est une photographie \u00e0 un instant t ; un vrai post-mortem, lui, est la vid\u00e9o de ce qui s’est pass\u00e9 quand la photographie a menti.<\/p>

Et l’AMF dans tout \u00e7a ?<\/h2>

Pour un lecteur francophone, une question se pose : qu’aurait \u00e0 dire un r\u00e9gulateur comme l’Autorit\u00e9 des march\u00e9s financiers (AMF)<\/a> sur un tel \u00e9pisode ? Liquid, en tant que protocole, n’est pas un acteur r\u00e9gul\u00e9 en France. Mais les plateformes qui l’utilisent, elles, peuvent l’\u00eatre. Depuis l’entr\u00e9e en application du r\u00e8glement MiCA fin 2024 et du r\u00e8glement DORA (r\u00e9silience op\u00e9rationnelle num\u00e9rique) le 17 janvier 2025, les prestataires de services sur crypto-actifs et les entit\u00e9s financi\u00e8res agr\u00e9\u00e9es doivent maintenir une gestion des risques informatiques et notifier les incidents majeurs \u00e0 leur autorit\u00e9 de tutelle.<\/p>

Il faut distinguer deux objets que l’on confond souvent. Le post-mortem technique, public, sert l’\u00e9cosyst\u00e8me : il explique la faille pour que d’autres ne la r\u00e9p\u00e8tent pas. La notification r\u00e9glementaire, elle, est confidentielle et obligatoire : elle vise \u00e0 prot\u00e9ger les clients et la stabilit\u00e9 du march\u00e9. Les deux convergent, mais ne se substituent pas l’un \u00e0 l’autre. Un acteur fran\u00e7ais expos\u00e9 \u00e0 Liquid via ses r\u00e9serves aurait d\u00fb, en th\u00e9orie, d\u00e9clencher une notification DORA en interne bien avant qu’un rapport public ne circule.<\/p>

Cette exigence de tra\u00e7abilit\u00e9 s’inscrit dans un calendrier r\u00e9glementaire europ\u00e9en charg\u00e9, que nous suivons dans notre compte \u00e0 rebours de la semaine d\u00e9cisive de septembre 2026<\/a>. La tendance de fond est claire : la culture du post-mortem, longtemps informelle et volontaire, se rapproche peu \u00e0 peu d’une obligation r\u00e9glementaire. Pour les acteurs europ\u00e9ens, bien documenter un incident n’est plus seulement une bonne pratique ; cela devient une condition de conformit\u00e9.<\/p>

La checklist du bon post-mortem<\/h2>

Que retenir, concr\u00e8tement ? Pour une \u00e9quipe, un bon post-mortem se reconna\u00eet \u00e0 quelques signes. Il arrive vite, mais pas trop vite : les faits d’abord, les conclusions ensuite. Il nomme la cause racine sans jargon d\u00e9fensif. Il distingue ce qui a \u00e9t\u00e9 perdu de ce qui a \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9. Il propose des actions dat\u00e9es et attribu\u00e9es, pas des intentions vagues. Et il assume les erreurs humaines en les convertissant en garde-fous techniques.<\/p>

  • Un r\u00e9sum\u00e9 clair et une chronologie horodat\u00e9e en UTC.<\/li>
  • Une cause racine unique, nomm\u00e9e, distincte des facteurs aggravants.<\/li>
  • Un impact chiffr\u00e9 : fonds perdus, fonds r\u00e9cup\u00e9r\u00e9s, utilisateurs touch\u00e9s.<\/li>
  • Des mesures d’urgence et un plan de rem\u00e9diation avec responsables et \u00e9ch\u00e9ances.<\/li>
  • Une posture \u00ab blameless \u00bb : chaque erreur humaine devient une barri\u00e8re automatique.<\/li>
  • Une divulgation coordonn\u00e9e du correctif, pour \u00e9viter le sc\u00e9nario du N-day.<\/li><\/ul>

    Pour un utilisateur, les enseignements sont plus simples encore. Ne jamais confondre \u00ab audit\u00e9 \u00bb et \u00ab s\u00fbr \u00bb. Se m\u00e9fier des sidechains et des ponts, qui concentrent la valeur et multiplient les surfaces d’attaque. Et lire les post-mortems : ils sont, avec les rapports on-chain, la meilleure \u00e9ducation gratuite qui soit sur les risques r\u00e9els d’un actif. Le cas Liquid restera comme un rappel que m\u00eame le camp le plus rigoureux de Bitcoin n’est pas \u00e0 l’abri d’une ligne de code trop optimiste, et que la mani\u00e8re dont on raconte la catastrophe compte presque autant que la catastrophe elle-m\u00eame.<\/p>

    Frequently Asked Questions<\/h2>

    Qu’est-ce qu’un post-mortem d’exploit en crypto ?<\/h3>

    Un post-mortem d’exploit est un rapport d’incident publi\u00e9 apr\u00e8s un piratage. Il d\u00e9crit ce qui a cass\u00e9, la cause racine, le montant perdu, les mesures prises et le plan pour \u00e9viter la r\u00e9cidive. Un bon post-mortem est \u00ab blameless \u00bb, horodat\u00e9 en UTC et assorti d’actions dat\u00e9es et attribu\u00e9es.<\/p>

    Combien le Liquid Network a-t-il perdu en septembre 2026 ?<\/h3>

    L’attaquant a cr\u00e9\u00e9 pr\u00e8s de 3 998 L-BTC frauduleux, puis retir\u00e9 environ 4 000 BTC de la r\u00e9serve f\u00e9d\u00e9r\u00e9e, soit \u00e0 peu pr\u00e8s 265 millions d’euros au cours du moment. Environ 3 400 BTC ont \u00e9t\u00e9 renvoy\u00e9s ; il restait pr\u00e8s de 598,5 BTC, quelque 40 millions d’euros, que Blockstream a refus\u00e9 de racheter.<\/p>

    Le hack de Liquid venait-il de cl\u00e9s vol\u00e9es ?<\/h3>

    Non. Contrairement \u00e0 la majorit\u00e9 des vols de 2026, il ne s’agissait pas de cl\u00e9s priv\u00e9es compromises mais d’un bug de code : une collision de cl\u00e9 dans le cache de v\u00e9rification des rangeproofs du logiciel Elements, qui laissait passer des preuves invalides.<\/p>

    Pourquoi Blockstream a-t-il refus\u00e9 de payer la \u00ab prime \u00bb du hacker ?<\/h3>

    Parce que pr\u00e9lever des fonds puis exiger un paiement pour les rendre rel\u00e8ve, selon l’entreprise, du vol et non de la divulgation responsable. Blockstream a jug\u00e9 qu’accepter cr\u00e9erait un pr\u00e9c\u00e9dent dangereux et a pr\u00e9f\u00e9r\u00e9 couvrir lui-m\u00eame la parit\u00e9 L-BTC\/BTC pour ses utilisateurs.<\/p>

    Comment reconna\u00eetre un bon post-mortem ?<\/h3>

    Il arrive rapidement, nomme une cause racine sans jargon d\u00e9fensif, chiffre l’impact, s\u00e9pare les pertes des fonds r\u00e9cup\u00e9r\u00e9s et propose des actions concr\u00e8tes avec responsables et \u00e9ch\u00e9ances. Il privil\u00e9gie une divulgation coordonn\u00e9e du correctif pour ne pas offrir de carte aux attaquants.<\/p>