Self-custody : quand vous faites tout correctement, mais que la chaîne casse quand même

Bitcoin n’a pas été cassé

Commençons par le plus important : cet incident ne signifie pas que Bitcoin aurait été compromis.

Le protocole n’a pas été forcé. La blockchain n’a pas été réécrite. Les règles de consensus n’ont pas été contournées. Ce qui semble avoir cédé, c’est une étape beaucoup plus en amont : la génération de certaines phrases de récupération, ces fameuses seeds qui permettent de retrouver l’accès à un portefeuille.

Dans un portefeuille Bitcoin, la sécurité dépend d’un point presque banal en apparence : le hasard.

Quand une seed est générée correctement, elle doit être tellement imprévisible qu’il devient pratiquement impossible de la deviner. Pas difficile. Pas coûteux. Pas improbable. Impossible à l’échelle humaine, avec les moyens informatiques actuels.

Mais si ce hasard est insuffisant (mauvais aléatoire), tout change.

Dans le cas Coldcard, les analyses disponibles pointent un bug d’intégration présent depuis 2021 : au lieu d’utiliser correctement le générateur matériel d’aléa prévu, certaines versions du firmware auraient utilisé un générateur pseudo-aléatoire logiciel de repli, fondé notamment sur des éléments comme le numéro de série de la puce et des données d’horloge. Coinkite a estimé l’entropie effective autour de 40 bits sur certains modèles, et autour de 72 bits sur d’autres, au lieu du niveau attendu pour une seed correctement générée.

Cette différence n’est pas cosmétique. C’est le passage d’un secret pratiquement impossible à deviner à un secret potentiellement attaquable par un acteur motivé, équipé et patient.

Le coffre peut être solide. Le protocole peut être robuste. L’utilisateur peut être prudent. Si la combinaison initiale du coffre a été tirée dans un espace de possibilités trop petit, un attaquant peut finir par la reconstruire.

C’est la brutalité de ce type de faille : elle n’a pas besoin que l’utilisateur fasse une erreur visible. Elle exploite une faiblesse invisible dans la fabrication même du secret.

Les victimes n’ont pas forcément échoué à être souveraines

Le réflexe paresseux, dans ce genre d’affaire, consiste à dire : “Il fallait mieux sécuriser”.

Mais sécuriser quoi, exactement ?

Si un utilisateur achète un hardware wallet réputé, génère sa seed sur l’appareil, conserve sa phrase hors ligne, ne la partage avec personne et ne tombe pas dans un phishing, on peut difficilement parler d’imprudence. Il a précisément suivi la doctrine que l’écosystème Bitcoin répète depuis des années : not your keys, not your coins.

Le problème, c’est que ce slogan est vrai mais incomplet.

Ne pas posséder ses clés expose à un risque évident : dépendre d’un exchange, d’une banque, d’un dépositaire, d’un administrateur, d’une plateforme qui peut geler, perdre, prêter, bloquer ou faire faillite.

Mais posséder ses clés expose à une autre famille de risques : dépendre de la manière dont ces clés sont générées, stockées, sauvegardées, transmises, restaurées et migrées.

La self-custody ne transforme pas un actif risqué en actif magique. Elle remplace une dépendance institutionnelle par une chaîne de dépendances techniques.

Et dans cette chaîne, certains maillons ne sont pas directement observables par l’utilisateur.

Vous pouvez vérifier que votre seed est bien écrite sur une plaque métallique. Vous pouvez vérifier que personne ne l’a photographiée. Vous pouvez vérifier que votre wallet est rangé hors ligne.

Mais pouvez-vous vérifier, au moment exact où elle est créée, que l’entropie utilisée pour générer cette seed est réellement suffisante ? Pour la majorité des gens, non.

C’est là que ça se complique : il existait des pratiques capables de réduire ce risque, comme ajouter de l’entropie par des lancers de dés ou utiliser une passphrase BIP-39. Coinkite documente depuis longtemps l’usage des dés pour ne pas dépendre uniquement du générateur aléatoire du wallet. Des analyses de l’incident indiquent aussi que les utilisateurs ayant ajouté suffisamment d’entropie externe ou une passphrase n’étaient pas exposés de la même manière.

Mais cette nuance ne transforme pas les victimes en coupables.

La procédure par défaut d’un hardware wallet est censée être sûre. Un utilisateur qui suit le chemin standard recommandé par l’appareil ne devrait pas devoir deviner qu’un bug profond dans la génération d’aléa rend sa seed moins robuste que prévu.

La vraie leçon n’est donc pas : “Les utilisateurs ont été négligents.” La vraie leçon est plus inconfortable : “Même les bonnes pratiques reposent parfois sur des hypothèses techniques que l’utilisateur ne peut pas vérifier seul.”

Le hardware wallet n’est pas le coffre. La seed est le coffre.

Il y a une confusion fréquente autour des hardware wallets : on croit que l’objet est le coffre.

Ce n’est pas tout à fait vrai.

Le boîtier est important. Il peut isoler les clés, signer des transactions hors ligne, limiter l’exposition à un ordinateur compromis, réduire certains risques de malware. C’est déjà beaucoup.

Mais le vrai coffre, c’est la seed.

Si quelqu’un possède votre phrase de récupération, il n’a pas besoin de voler votre appareil. Il peut restaurer le portefeuille ailleurs. Si quelqu’un peut deviner votre seed, le hardware wallet ne sert plus à grand-chose. Il protège une porte dont la combinaison a déjà été reconstruite.

C’est ce qui rend l’incident Coldcard particulièrement violent sur le plan symbolique.

On ne parle pas d’un utilisateur qui aurait mal conservé sa phrase. On ne parle pas d’un exchange qui aurait été vidé. On ne parle pas d’un smart contract bancal. On parle d’un possible défaut dans le moment fondateur de la souveraineté Bitcoin : la création du secret.

Or c’est précisément le moment que l’utilisateur délègue presque toujours à l’outil.

Quand le wallet affiche douze ou vingt-quatre mots, l’utilisateur ne voit pas le hasard. Il voit une phrase. Il la note. Il la protège. Il croit avoir accompli le geste de souveraineté.

Mais si le hasard derrière cette phrase était insuffisant, le geste était déjà compromis avant même la première sauvegarde.

La liberté financière repose toujours sur une infrastructure

C’est là que cette histoire dépasse largement Coldcard.

Le Fuck You Money, ce n’est pas seulement un montant. Ce n’est pas seulement un actif. Ce n’est pas seulement une ligne dans un portefeuille.

C’est une capacité : pouvoir dire non, tenir un choc, refuser une dépendance, partir, attendre, négocier, survivre à une crise sans supplier ceux qui contrôlent l’accès à votre argent.

Bitcoin peut jouer un rôle dans cette logique. Parce qu’il permet de détenir un actif numérique rare sans dépendre directement d’une banque ou d’un dépositaire. Parce qu’il est transportable. Parce qu’il est vérifiable. Parce qu’il est difficile à confisquer quand il est correctement détenu.

Mais “correctement détenu” est une expression plus lourde qu’elle n’en a l’air.

Elle suppose une infrastructure complète :

• un protocole robuste ;
• un logiciel fiable ;
• un appareil sain ;
• une génération de seed réellement aléatoire ;
• une sauvegarde durable ;
• une procédure de transmission ;
• une capacité de réaction en cas d’alerte ;
• une compréhension minimale des scénarios de perte.

La liberté financière n’est donc pas uniquement individuelle. Elle repose sur une architecture.

C’est vrai pour Bitcoin. C’est vrai pour l’or physique. C’est vrai pour le cash. C’est vrai pour les actions. C’est vrai pour l’immobilier.

Aucun actif ne vous rend libre par essence. Chaque actif vous expose à une configuration différente de risques, de frictions et de dépendances.

La différence avec Bitcoin, c’est que cette configuration est souvent vendue avec un vocabulaire absolu : souveraineté, confiscation resistance, self-custody, bearer asset, hard money.

Tout cela peut être vrai. Mais seulement si la chaîne tient.

L’open source n’est pas une assurance tous risques

L’un des aspects les plus inconfortables de cette affaire, c’est la place de l’open source.

Dans la culture Bitcoin, l’ouverture du code est souvent présentée comme un gage de sécurité. Et sur le fond, l’argument est solide : un code visible peut être inspecté, testé, critiqué, reproduit. Il ne repose pas uniquement sur la parole d’un fabricant.

Mais “peut être inspecté” ne veut pas dire “a été inspecté correctement”.

C’est toute la différence.

Un dépôt public n’est pas un audit permanent. Une communauté n’est pas une garantie. Un code ouvert peut contenir une faille pendant longtemps si personne ne regarde le bon endroit avec la bonne compétence, la bonne motivation et le bon niveau d’attention.

L’open source augmente la vérifiabilité. Il ne garantit pas la vérification.

Le directeur sécurité de Kraken, Nick Percoco, a justement résumé le problème comme un angle mort du test des hardware wallets : vérifier qu’un composant existe ne suffit pas si l’on ne vérifie pas qu’il est effectivement appelé dans le bon chemin de production.

Dans un monde idéal, les failles seraient découvertes par les mainteneurs, les auditeurs, les chercheurs, les utilisateurs avancés, puis corrigées avant d’être exploitées. Dans le monde réel, une faille peut aussi être découverte par celui qui a le plus fort intérêt économique à ne rien dire.

Si une vulnérabilité peut rapporter plusieurs dizaines de millions de dollars, le premier auditeur vraiment motivé n’est pas forcément un bénévole bienveillant.

C’est brutal, mais c’est rationnel.

La sécurité a un coût. Quand personne ne paie ce coût suffisamment tôt, quelqu’un finit souvent par payer la faille.

L’IA change l’économie de la chasse aux vieux bugs

Il faut être prudent sur ce point.

L’hypothèse d’un usage de l’intelligence artificielle dans la découverte ou l’exploitation de cette faille circule, et certaines sources rapportent que Coinkite aurait elle-même évoqué des outils assistés par IA. D’autres traitements médiatiques restent plus prudents et présentent ce rôle comme non confirmé. Il serait donc imprudent d’écrire que “l’IA a trouvé la faille” comme un fait établi.

Mais l’idée générale, elle, est difficile à ignorer.

Les modèles d’IA et les outils automatisés changent l’économie de la recherche de vulnérabilités. Ils permettent de relire du vieux code, de comparer des versions, de repérer des motifs faibles, d’automatiser une partie des tests, d’assister des attaquants comme des défenseurs.

Ce qui était techniquement visible mais économiquement peu intéressant peut devenir exploitable. Ce qui dormait dans une vieille version peut redevenir actif. Ce qui avait échappé à l’attention humaine peut être scanné à grande échelle.

Pendant longtemps, une faille ancienne pouvait rester non exploitée simplement parce qu’elle demandait trop d’effort, trop de compétence ou trop de temps. Ce n’est plus un confort sur lequel il faut compter.

L’open source ne devient pas mauvais pour autant. Mais il entre dans une nouvelle époque.

Avant, le code ouvert signifiait : “Tout le monde peut vérifier.” Demain, cela signifiera aussi : “Tout le monde peut attaquer la surface visible avec des outils plus puissants.”

La bonne réponse n’est pas forcément de refermer le code. Ce serait une conclusion trop simple, et probablement dangereuse. La bonne réponse est de comprendre que la transparence doit s’accompagner d’un vrai budget de défense : audits sérieux, tests reproductibles, bug bounties, procédures de réponse, communication rapide, redondance des méthodes de génération, culture de la migration.

Une société qui vend de la souveraineté ne vend pas seulement un objet. Elle vend une promesse opérationnelle.

Et cette promesse doit être entretenue.

La réaction de Coinkite ne suffit pas à effacer le problème

Coinkite a publié des alertes de sécurité, des firmwares correctifs et des consignes de migration. Le point essentiel est que mettre l’appareil à jour ne suffit pas pour les seeds déjà générées avec une entropie insuffisante : il faut créer une nouvelle seed sûre et transférer les fonds vers ce nouveau portefeuille.

C’est une précision importante.

Quand le problème se situe dans la génération initiale du secret, le correctif logiciel protège surtout l’avenir. Il ne rend pas rétroactivement imprévisible une seed déjà créée avec un mauvais aléa.

C’est pour cela que ce type de faille est aussi brutal : elle ne demande pas seulement une mise à jour. Elle demande une migration. Elle demande de comprendre l’alerte, d’agir vite, de ne pas se tromper dans le transfert, de ne pas laisser dormir des fonds sur une ancienne seed compromise.

Autrement dit, elle transforme une question technique invisible en urgence opérationnelle.

Et c’est précisément là que l’écart se creuse entre la promesse de souveraineté et sa réalité quotidienne.

Être souverain, ce n’est pas seulement détenir ses clés. C’est aussi savoir quoi faire quand la confiance placée dans la génération de ces clés vient de se fissurer.

Le risque le plus dur à accepter : avoir tout bien fait

Ce qui rend ce type d’incident moralement difficile, c’est qu’il ne suit pas la morale habituelle du risque.

Dans beaucoup d’histoires financières, la perte vient d’un excès : trop de levier, trop de confiance, trop de rendement promis, trop d’avidité, trop de négligence.

Ici, le récit est plus dérangeant.

Les victimes potentielles n’étaient pas nécessairement des spéculateurs inconscients. Certaines étaient peut-être des personnes qui accumulaient patiemment du bitcoin depuis des années, en pensant justement se protéger des plateformes, des intermédiaires et des risques de confiscation.

Elles avaient choisi l’autonomie. Elles avaient choisi la prudence. Elles avaient choisi la responsabilité personnelle.

Et malgré cela, la chaîne a pu casser.

Ce point est essentiel. Il ne faut pas le balayer sous le tapis pour défendre Bitcoin, ni l’exagérer pour attaquer Bitcoin.

La bonne lecture est plus inconfortable : la souveraineté personnelle ne garantit pas l’invulnérabilité personnelle.

On peut faire les bons choix généraux et subir quand même la défaillance d’un outil. On peut refuser la banque et dépendre d’un fabricant. On peut fuir le risque de dépositaire et rencontrer le risque de firmware. On peut quitter une chaîne de confiance visible pour entrer dans une chaîne de confiance plus technique, plus opaque, plus difficile à auditer soi-même.

C’est exactement ce que beaucoup de discours sur la liberté financière oublient.

Dire non au système bancaire ne suffit pas. Il faut aussi savoir à quoi on dit oui.

La self-custody doit devenir une procédure, pas une posture

La conclusion pratique n’est pas : “N’utilisez jamais de hardware wallet.”

Ce serait absurde.

La conclusion n’est pas non plus : “Gardez tout sur un exchange.”

Ce serait remplacer un risque par un autre, souvent plus grossier.

La vraie conclusion a plus d'exigeance : si Bitcoin fait partie d’un capital de liberté, alors sa conservation doit être pensée comme une procédure, pas comme une posture identitaire.

Posséder un hardware wallet ne suffit pas. Avoir une seed ne suffit pas. Dire “not your keys, not your coins” ne suffit pas.

Il faut penser en termes de chaîne complète.

Comment la seed a-t-elle été générée ? Avec quelle source d’entropie ? Le firmware était-il à jour au moment de la création ? Existe-t-il une alerte de sécurité sur l’appareil utilisé ? La procédure de migration est-elle connue avant la panique ? Les fonds sont-ils tous dépendants d’un seul secret ? Faut-il répartir le risque entre plusieurs dispositifs ou envisager un multisig ? La succession est-elle prévue ? La liquidité de court terme est-elle séparée du stockage long terme ? Le capital de rupture est-il vraiment disponible en cas de choc ?

Un actif de liberté doit être jugé non seulement sur sa promesse théorique, mais sur sa résistance opérationnelle. Que se passe-t-il quand un fabricant communique mal ? Quand une faille sort en plein été ? Quand il faut migrer vite ? Quand le détenteur est en voyage ? Quand ses héritiers ne comprennent rien au dispositif ? Quand un appareil autrefois réputé devient soudain suspect ?

La liberté ne se mesure pas quand tout va bien. Elle se mesure quand le plan doit fonctionner sous stress.

Le bon niveau de paranoïa

Fuck You Money ne veut pas dire vivre dans un bunker mental.

La paranoïa financière permanente est une autre forme de servitude. Si chaque actif devient une menace, chaque outil une trahison possible, chaque institution une conspiration et chaque bug une apocalypse, on ne devient pas libre. On devient captif de son propre système de défense.

Le bon objectif n’est pas d’éliminer tous les risques. C’est impossible.

Le bon objectif est de savoir quels risques on accepte, lesquels on refuse, lesquels on diversifie et lesquels on surveille.

Bitcoin peut réduire certains risques : gel bancaire, dépendance à un dépositaire, dilution monétaire, contrôle des capitaux dans certains contextes. Mais il en introduit ou en concentre d’autres : perte irréversible, erreur opérationnelle, mauvaise génération des clés, mauvaise sauvegarde, mauvaise transmission, traçabilité, fiscalité, volatilité.

Un lecteur sérieux ne doit pas choisir Bitcoin parce qu’il croit que c’est sans risque. Il doit éventuellement le choisir parce qu’il préfère certains risques à d’autres.

C’est toute la différence entre une doctrine de liberté et une croyance magique.

La vraie question : où voulez-vous placer votre confiance ?

L’incident Coldcard rappelle une chose désagréable : même quand on cherche à sortir du système, on ne sort jamais totalement du problème de la confiance.

On choisit simplement sa forme.

Faire confiance à une banque, c’est accepter une structure juridique, réglementaire et politique. Faire confiance à un exchange, c’est accepter un risque de dépositaire privé. Faire confiance à un ETF, c’est accepter une chaîne financière, administrative et réglementaire. Faire confiance à un hardware wallet, c’est accepter une chaîne technique : composants, firmware, entropie, audits, mises à jour, réputation.

Aucune option n’est pure.

La question sérieuse n’est donc pas : “Comment ne faire confiance à personne ?” La question sérieuse est : “Quelle confiance est la plus acceptable pour mon objectif de liberté ?”

Pour certains, la réponse inclura Bitcoin en self-custody. Pour d’autres, elle inclura de l’or physique. Pour d’autres, du cash, des actifs productifs, une mobilité géographique, plusieurs banques, plusieurs juridictions, plusieurs sources de revenus.

Le Fuck You Money n’est pas une religion d’actif unique. C’est une architecture de sortie.

Bitcoin peut être une pièce importante de cette architecture. Mais il ne dispense pas de penser l’architecture elle-même.

Le plus dur, dans cette histoire, n’est pas de comprendre le bug. C’est d’accepter la leçon.

Les utilisateurs touchés n’ont pas forcément été imprudents. Certains ont probablement fait ce que l’écosystème leur disait de faire : retirer leurs bitcoins des plateformes, utiliser un hardware wallet, conserver leur seed, penser long terme.

C’est précisément pour cela que l’affaire est si violente.

Elle rappelle que la souveraineté financière n’est pas un état que l’on achète dans une boîte. C’est une discipline. Une chaîne. Une procédure. Une capacité à comprendre ses dépendances, même quand elles sont cachées derrière un objet rassurant.

Bitcoin n’est pas cassé. La self-custody n’est pas morte. L’open source n’est pas disqualifié.

Mais l’idée d’une liberté financière simple, automatique et sans compétence vient de prendre un coup.

Le “fuck you money” n’est pas l’argent que personne ne peut vous prendre. C’est l’argent dont vous avez compris toutes les façons dont il peut quand même disparaître.