Toute crypto-monnaie repose sur une clé privée et une clé publique, et la clé privée n’est qu’un nombre. D’après la documentation pour développeurs de Bitcoin (en anglais), une clé privée Bitcoin est simplement un nombre de 256 bits. Écrit en hexadécimal, pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">il tient en 64 caractères, chiffres de 0 à 9 et lettres de a à f. Il n’y a rien d’autre : ni nom, ni compte, ni inscription. La clé publique, l’adresse que vous donnez à ceux qui vous paient, la signature de chaque paiement que vous envoyez et même les 12 ou 24 mots que votre portefeuille vous a demandé de noter se calculent à partir de ce seul nombre, ou y ramènent.
Le secret qui signe, c’est la clé privée. La clé publique est la valeur associée que n’importe qui peut utiliser pour vérifier ces signatures, et l’adresse en est une empreinte courte. Votre portefeuille tire la clé privée au hasard, personne ne la valide, et le calcul ne se fait ensuite que dans un sens.
Celui qui connaît le nombre contrôle les cryptos. Ses formes dérivées, la clé publique et l’adresse, peuvent être montrées à tout le monde, parce que personne ne sait revenir en arrière. Et si le nombre est perdu sans sauvegarde, personne (ni le réseau, ni le fabricant du portefeuille, ni un juge) ne peut le reconstruire. Voilà pourquoi « perdu, c’est perdu » n’est pas un slogan en crypto, mais une conséquence de l’arithmétique.
Les idées générales (fonctions de hachage, chiffrement, signatures numériques) sont dans la leçon précédente, ce qu’est la cryptographie et comment les blockchains l’utilisent. Ici, un seul outil : la paire de clés. Les mêmes mathématiques protègent le cadenas de votre navigateur et les clés SSH des développeurs, ce qui explique que la recherche « clé privée clé publique » mène souvent vers des tutoriels de serveur. Tout ce qui suit concerne les portefeuilles crypto.
Une clé privée, c’est un très grand nombre tiré au hasard
Bitcoin et Ethereum construisent leurs paires de clés sur la même courbe elliptique, appelée secp256k1. Ses paramètres ont été publiés par le Standards for Efficient Cryptography Group dans SEC 2, version 2.0 (2010) (en anglais), un document que les portefeuilles Bitcoin suivent encore à la lettre. Une clé privée valide est n’importe quel entier compris entre 1 et une limite fixe, juste en dessous, appelée l’ordre de la courbe et notée n.
Cette limite vaut environ 1,158 × 1077, un nombre de 78 chiffres. Elle est si proche de 2256 que l’écart ne change rien pour ce qu’un lecteur fera jamais, d’où l’usage de dire qu’une clé privée est un nombre de 256 bits. En choisir une revient à lancer 256 pièces équilibrées et à noter le résultat.
| Paramètre de secp256k1 | Valeur | Ce que cela signifie |
|---|---|---|
| Équation | y2 = x3 + 7 | la courbe sur laquelle vivent les clés publiques |
| Taille du corps p | 2256 – 232 – 977 | les coordonnées sont des entiers inférieurs à p |
| Ordre n | environ 1,158 × 1077 (78 chiffres) | les clés privées vont de 1 à n – 1 |
| Cofacteur h | 1 | tout point de la courbe s’atteint depuis le point de départ G |
| Niveau de sécurité | 128 bits | la meilleure attaque connue demande environ 2128 opérations |
Source : SEC 2 version 2.0, section 2.4.1 et tableau 1 (Certicom Research, 27 janvier 2010). La taille du corps est le nombre que SEC 2 écrit 2256 – 232 – 29 – 28 – 27 – 26 – 24 – 1.
Qui choisit le nombre ? Votre portefeuille, sur votre appareil, avec son générateur de nombres aléatoires. Aucun serveur ne l’attribue et il n’existe aucune liste de clés déjà prises. Deux personnes pourraient en théorie tirer la même ; les chiffres plus bas montrent pourquoi cela n’arrive pas. Une clé est à vous pour une seule raison : vous êtes le seul à la connaître.
Vous ne trouverez pas d’exemple de clé privée dans cette leçon. Une clé imprimée dans un article cesse d’être secrète au moment où elle est publiée, et n’importe qui pourrait prélever ce qu’on y envoie. Les vraies clés s’écrivent sous deux formes courantes : 64 caractères hexadécimaux, ou le format plus court WIF (Wallet Import Format), qui ajoute un octet de version et une somme de contrôle et s’écrit en Base58, selon le guide pour développeurs Bitcoin. Sur Ethereum, ethereum.org décrit aussi la clé privée comme 64 caractères hexadécimaux. La plupart des gens ne voient jamais ni l’une ni l’autre, car les portefeuilles modernes montrent une phrase de récupération à la place.
Clé privée et clé publique : le rôle de chacune
On calcule la clé publique à partir de la clé privée par une opération fixe sur la courbe. On part d’un point convenu G, le même pour tous les utilisateurs du monde, et on l’« additionne » à lui-même autant de fois que l’indique la clé privée. Le résultat est un autre point de la courbe, un couple de coordonnées (x, y), et ce point est la clé publique. Les ordinateurs ne répètent pas l’addition 1077 fois : ils doublent et additionnent, ce qui prend quelques centaines d’étapes pour un nombre de 256 bits. C’est pourquoi votre téléphone le fait instantanément.
Une clé publique fait 65 octets dans l’ancienne forme non compressée (un préfixe et les deux coordonnées) ou 33 octets dans la forme compressée que presque tous les portefeuilles utilisent aujourd’hui : la coordonnée x et un préfixe, 02 ou 03, qui indique laquelle des deux valeurs de y convient. Le wiki Bitcoin (en anglais) détaille la forme compressée octet par octet.
On compare souvent la clé publique à un cadenas ouvert que tout le monde peut refermer, et la clé privée à la seule clé qui l’ouvre. Cette image décrit le chiffrement, et elle n’est qu’à moitié juste en crypto. Bitcoin ne chiffre pas vos paiements : chaque transaction est publique. La paire de clés sert à signer, et la clé publique se conçoit mieux comme un vérificateur de signature que tout le réseau peut utiliser, attaché aux cryptos qu’il protège.
| Clé privée | Clé publique | Adresse | |
|---|---|---|---|
| Ce que c’est | un nombre aléatoire inférieur à n | un point de la courbe, calculé depuis la clé privée | un hachage de la clé publique, avec une somme de contrôle |
| Taille courante | 32 octets (64 caractères hexadécimaux) | 33 octets compressée, 65 non compressée | 20 octets de hachage sur Bitcoin (format historique) et Ethereum |
| Qui la connaît | vous seul (et votre sauvegarde) | tout le monde, dès que vous dépensez depuis l’adresse (pour la plupart des types d’adresse) | ceux que vous payez ou qui vous paient |
| Sert à | signer les transactions | vérifier les signatures | recevoir des cryptos |
| Peut-on la partager | jamais | oui | oui, au prix d’une part de vie privée |
De la clé privée à l’adresse : un sens unique
La chaîne va de la clé privée à la clé publique, puis à l’adresse. Chaque flèche se calcule en une fraction de seconde. Aucune ne peut se parcourir à l’envers par une méthode connue, et les deux flèches sont à sens unique pour des raisons différentes.
La première flèche, de la clé privée à la clé publique, est la multiplication sur la courbe décrite plus haut. Revenir en arrière suppose de trouver combien de fois G a été additionné pour atteindre un point donné, un problème que les mathématiciens appellent le logarithme discret sur courbe elliptique. Personne n’a trouvé de raccourci pour des courbes comme secp256k1. Les meilleures attaques générales demandent environ la racine carrée du nombre de clés, soit 2128 opérations, ce qui explique que SEC 2 note la courbe à « 128 bits » de sécurité alors que les clés en font 256.
La seconde flèche, de la clé publique à l’adresse, est un hachage. Sur Bitcoin, une adresse classique s’obtient en passant la clé publique dans SHA-256 puis RIPEMD-160, ce qui donne une empreinte de 160 bits, à laquelle on ajoute un octet de version et une somme de contrôle. Sur Ethereum, ethereum.org explique que l’adresse correspond aux 20 derniers octets du hachage Keccak-256 de la clé publique, précédés de 0x. Un hachage ne s’inverse pas au sens habituel : il jette de l’information, donc plusieurs entrées pourraient en théorie donner la même sortie, et en trouver une revient à deviner.
« Sens unique » signifie donc « aucun moyen efficace connu de revenir en arrière », ce qui est plus fort qu’il n’y paraît mais ne constitue pas une preuve d’impossibilité. ethereum.org en donne le résultat pratique : on peut dériver de nouvelles clés publiques depuis une clé privée, mais pas retrouver une clé privée à partir de clés publiques.
Pourquoi ajouter l’étape du hachage ? Elle raccourcit l’adresse par rapport à la clé publique et, sur Bitcoin, elle ajoute un second verrou. Avec le format classique à paiement vers un hachage de clé publique, le guide pour développeurs Bitcoin explique que le réseau ne voit que le hachage de votre clé publique jusqu’à la première dépense depuis cette adresse. À ce moment, vous devez révéler la clé publique complète, avec une signature, pour que les nœuds puissent vérifier. Avant cela, un attaquant devrait casser à la fois le hachage et la courbe. La construction détaillée de chaque format d’adresse, avec ses sept étapes sur Bitcoin, est dans notre leçon qu’est-ce qu’une adresse crypto.

Signer au lieu d’envoyer un mot de passe
Une banque compare votre mot de passe à une copie qu’elle conserve. Une blockchain ne garde aucune copie de quoi que ce soit de secret. Quand vous envoyez des cryptos, votre portefeuille construit la transaction (quelles unités, vers quelle adresse, quel montant, quels frais) et calcule une signature à partir de deux éléments : ces données exactes et votre clé privée. La signature est un couple de nombres que seul le détenteur de la clé pouvait produire pour ces données.
Chaque nœud qui reçoit la transaction fait alors une vérification avec trois éléments qu’il possède ou reçoit : les données de la transaction, la signature et la clé publique. Si la vérification réussit, le propriétaire de la clé a approuvé cette transaction. La clé privée elle-même ne voyage jamais. Sur un portefeuille matériel, elle ne quitte même pas l’appareil : l’ordinateur envoie la transaction non signée, et seule la signature en ressort.
Deux propriétés rendent cela plus sûr qu’un mot de passe. Une signature est liée aux données qu’elle signe : changer un chiffre du montant ou un caractère de la destination la fait échouer. Et la signature d’un paiement ne sert à rien pour un autre, puisque le paiement suivant correspond à d’autres données. Qui copie votre signature sur la blockchain n’a rien copié qu’il puisse réutiliser.
Satoshi Nakamoto voyait aussi un intérêt pour la vie privée dans cette conception. Les clés ne portant aucun nom, la section 10 du livre blanc de Bitcoin (2008, en anglais) recommande d’utiliser une nouvelle paire de clés pour chaque transaction afin d’éviter qu’elles soient rattachées à un même propriétaire. Les portefeuilles modernes le font automatiquement, comme le montre la section sur la phrase de récupération. La façon dont la transaction signée arrive ensuite dans un bloc est expliquée dans comment fonctionnent les transactions crypto.
Ce que l’on peut partager et ce qu’il ne faut jamais partager
La règle découle du sens unique : tout ce qui se trouve en aval de la clé privée peut être montré, tout ce qui y ramène ne le peut pas. En pratique, on vous demandera une adresse tout le temps et une clé publique presque jamais.
| Élément | À partager ? | Pourquoi |
|---|---|---|
| Adresse de réception | Oui | elle est faite pour être donnée ; le prix à payer est la vie privée, puisque n’importe qui peut suivre son historique |
| Clé publique | Oui | elle ne révèle rien qui permette de signer ; les portefeuilles la demandent rarement |
| Identifiant de transaction (hachage) | Oui | il renvoie à un enregistrement public |
| Message que vous avez signé | Oui | il prouve que vous contrôlez une adresse sans déplacer de fonds |
| Clé publique étendue (xpub) | Avec précaution | elle montre toutes les adresses d’un compte ; combinée à une clé privée enfant divulguée, elle peut exposer le reste (BIP32) |
| Clé privée | Jamais | celui qui la détient peut signer et déplacer les cryptos |
| Phrase de récupération | Jamais | elle reconstruit toutes les clés privées du portefeuille |
| Photo ou copie dans le cloud de l’une ou de l’autre | Jamais | une copie vaut la clé ; qui la lit détient les cryptos |
La xpub, ou clé publique étendue, mérite un second regard. C’est la clé publique maîtresse d’un compte du portefeuille, qui permet à des applications en lecture seule ou à des outils de comptabilité de voir toutes vos adresses. BIP32, la norme qui la définit, avertit que connaître une clé publique étendue et une clé privée non durcie qui en dérive équivaut à connaître la clé privée parente. Traitez-la comme une information privée, même si elle ne peut pas signer seule. Les adresses et les clés publiques simples ont un coût moindre : chaque paiement qui y arrive reste lisible, et les paiements peuvent être reliés entre eux puis, via les plateformes, à votre identité.
De l’autre côté du tableau, la règle ne souffre aucune exception. Aucune plateforme, aucun fabricant de portefeuille, aucun conseiller de support, aucun site de distribution gratuite (airdrop) ni formulaire de « validation » n’a jamais besoin de votre clé privée ou de votre phrase de récupération. Qui vous les réclame commet une arnaque, quel que soit le logo du message. Notre guide pour éviter les arnaques crypto en décrit les formes.
La phrase de récupération : une sauvegarde pour tout un arbre de clés
Si une clé privée est un seul nombre, pourquoi les portefeuilles vous donnent-ils 12 ou 24 mots ? Parce que ces mots sauvegardent quelque chose un cran au-dessus : un nombre aléatoire à partir duquel le portefeuille dérive toutes les clés qu’il utilisera. Deux normes nées dans Bitcoin, aujourd’hui utilisées par la plupart des portefeuilles Bitcoin et de nombreuses autres chaînes, en fixent le mécanisme.
Des bits aléatoires aux mots (BIP39)
BIP39 part de 128 à 256 bits aléatoires, appelés entropie, par pas de 32. La norme y ajoute une courte somme de contrôle tirée du hachage SHA-256 de cette entropie, à raison d’un bit de contrôle pour 32 bits. Le total est découpé en groupes de 11 bits, et chaque groupe désigne un mot dans une liste fixe de 2 048 mots (211 = 2 048). Ainsi 128 bits plus 4 bits de contrôle donnent 132 bits, soit 12 mots ; 256 bits plus 8 donnent 264 bits, soit 24 mots. Le dernier mot porte en partie la somme de contrôle, ce qui permet au portefeuille de repérer une faute de frappe à la restauration.
Les mots sont ensuite étirés en une graine de 512 bits par une fonction nommée PBKDF2, exécutée 2 048 fois avec HMAC-SHA512 et le mot « mnemonic » (plus une phrase secrète facultative) comme sel. Cette étape lente rend plus coûteuse toute tentative de deviner une phrase secrète.
D’une graine à de nombreuses clés (BIP32)
BIP32 transforme la graine en clé maîtresse : un nouvel HMAC-SHA512, avec la clé « Bitcoin seed », se scinde en une clé privée maîtresse de 32 octets et un « code de chaîne » de 32 octets. De cette paire, le portefeuille dérive des clés filles, puis des filles de filles, en arbre. Chaque branche peut produire des milliards de clés et d’adresses, ce qui permet à votre portefeuille de vous donner une nouvelle adresse à chaque paiement sans que vous ayez à sauvegarder quoi que ce soit de plus. Les branches « durcies » coupent le lien décrit dans l’avertissement sur la clé publique étendue.
Le guide pour développeurs Bitcoin résume le gain : une graine racine d’au moins 128 bits est la seule donnée que l’utilisateur doit sauvegarder pour dériver toutes les clés qu’un programme de portefeuille crée avec ses réglages. Une seule phrase couvre chaque adresse déjà utilisée et chaque adresse à venir.
Trois détails découlent des normes. Une phrase de 12 mots contient 128 bits d’entropie, donc 2128 phrases possibles, soit le niveau de sécurité que SEC 2 attribue à la courbe elle-même : 12 mots ne sont pas plus faibles en pratique que 24. La phrase secrète facultative, parfois appelée le 25e mot, change tout l’arbre ; BIP39 précise que toute phrase secrète produit une graine valide, si bien qu’une phrase secrète mal saisie ouvre un autre portefeuille, vide, sans le moindre message d’erreur. Enfin, une phrase ne couvre que les clés qui en dérivent : une clé privée importée seule, ou un très ancien fichier de portefeuille, n’est pas dans l’arbre.
La manière de noter la phrase, l’endroit où la garder et les arnaques qui la visent sont traités dans notre guide sur la sécurité de la phrase de récupération. Pour cette leçon, un point suffit : la phrase, ce sont les clés privées sous une forme que l’on peut recopier. Qui la lit peut toutes les reconstruire.
Que vaut 2256 ? Pourquoi la force brute est hors de portée
« Perdu, c’est perdu » repose sur une affirmation : personne ne peut retrouver une clé privée correctement tirée au hasard en essayant des nombres jusqu’à ce que l’un convienne. Les ordres de grandeur sont difficiles à ressentir, alors les voici face au plus grand effort de calcul qui existe, le réseau de minage de Bitcoin.
Le 23 octobre 2026, mempool.space (en anglais) estimait le réseau à environ 1,05 × 1021 hachages par seconde, soit à peu près mille milliards de milliards d’essais de hachage chaque seconde. Supposons, très généreusement, que ces mêmes machines puissent tester une clé privée aussi vite qu’elles calculent un hachage. En réalité, tester une clé coûte une multiplication sur la courbe, bien plus lourde, et les puces de minage ne savent faire que du SHA-256 : elles ne peuvent pas l’exécuter.
| Grandeur | Valeur | Source ou méthode |
|---|---|---|
| Clés privées possibles (ordre n) | environ 1,158 × 1077 | SEC 2 v2.0 (2010) |
| Travail de la meilleure attaque connue sur la courbe | environ 2128, soit 3,4 × 1038 opérations | SEC 2, niveau 128 |
| Phrases de 12 mots possibles | 2128 | BIP39, entropie de 128 bits |
| Puissance de hachage du réseau Bitcoin, 23 oct. 2026 | environ 1,05 × 1021 par seconde | mempool.space |
| Temps pour essayer toutes les clés à ce rythme | environ 3,5 × 1048 ans | notre calcul, une clé par hachage |
| Temps moyen pour tomber sur une clé précise | environ 1,7 × 1048 ans | moitié de la ligne précédente |
| Âge de l’Univers | environ 13,8 milliards d’années | NASA |
| Rapport entre les deux | environ 2,5 × 1038 | notre calcul |
L’Univers ayant environ 13,8 milliards d’années, selon la NASA (en anglais), une recherche exhaustive durerait à peu près 2,5 × 1038 fois son âge, et cela avec les machines imaginaires décrites plus haut.
Une version honnête de l’argument doit aussi utiliser le plus petit des deux nombres. À cause des attaques en racine carrée évoquées plus haut, le travail réel pour casser une clé publique est d’environ 2128 opérations, pas 2256. À une opération par hachage, tout le réseau de minage mettrait environ 10 milliards d’années, proche de l’âge de l’Univers, pour une seule clé, avec un matériel incapable de faire ce calcul. Cette marge de 128 bits est le niveau que SEC 2 attribue à la courbe, et aucun ordinateur existant n’en approche.
Le même calcul répond à la crainte des collisions, deux personnes qui tomberaient sur la même clé. Avec environ 1077 clés possibles, même des milliards de portefeuilles créés chaque jour pendant des millions d’années n’occuperaient qu’une part de l’espace si petite qu’il faudrait des dizaines de zéros pour l’écrire. Nous n’avons trouvé aucun cas documenté de clé aléatoire correctement générée retrouvée par recherche. C’est l’absence de preuve dans nos recherches, pas une démonstration, mais elle concorde avec les chiffres.
Quand les clés ne sont pas aléatoires, on peut les retrouver
Toutes les clés de la section précédente étaient supposées vraiment aléatoires. C’est cette hypothèse qui fait les vols réels. Une clé fabriquée avec une source de hasard faible appartient à un espace bien plus petit, et un petit espace peut être exploré.
En août 2013, bitcoin.org avertissait (en anglais) qu’un composant d’Android chargé de générer des nombres aléatoires sûrs « contient des faiblesses critiques » (traduction), si bien que tout portefeuille créé par une application Android pouvait être exposé au vol. La parade : mettre l’application à jour, créer de nouvelles adresses avec le générateur corrigé, y déplacer les fonds et communiquer les nouvelles adresses à ceux qui payaient les anciennes. L’alerte date du 11 août 2013 et a été mise à jour le 13 août.
Dix ans plus tard, les chercheurs de Milk Sad (en anglais) ont montré que la commande bx seed de Libbitcoin Explorer 3.x tirait sa matière de clé de Mersenne Twister, un générateur conçu pour les simulations, pas pour les secrets. La faille est enregistrée sous la référence CVE-2023-39910, et les chercheurs situent le vol des portefeuilles concernés au 12 juillet 2023.
Ce mois-ci a fourni un cas tout frais. Entre 23 h 42 UTC le 17 octobre et 1 h 26 UTC le 18 octobre 2026, 1 404 portefeuilles du réseau Qubic ont été vidés parce que son portefeuille web open source avait généré les graines avec la fonction Math.random() de JavaScript, jamais conçue pour la cryptographie, comme nous l’avons raconté dans notre article sur le vidage de graines faibles de Qubic. Le projet est passé à un générateur cryptographique le 18 octobre.
Des clés peuvent aussi fuiter après avoir été bien créées. Le 21 octobre 2026, la Polkadot Community Foundation a indiqué que les versions 3.0.1, 3.0.3, 3.0.4 et 3.0.5 de l’extension de navigateur Fearless Wallet envoyaient la clé privée à un serveur d’attaquant lorsque le portefeuille était déverrouillé ; huit utilisateurs avaient signalé des transferts non autorisés de 17 286 DOT à ce stade, comme nous l’avons rapporté dans notre article sur la fuite de Fearless Wallet. Le conseil était de créer une nouvelle clé et d’y déplacer les fonds, car réinstaller l’application ne sert à rien pour une clé déjà sortie.
Dans aucun de ces cas la courbe n’a été cassée. L’arithmétique a tenu à chaque fois, et c’est le logiciel qui a failli : la façon dont le nombre a été choisi, ou l’endroit où il a été envoyé. C’est la raison pratique de ne créer ses clés que dans des portefeuilles ou des appareils matériels très répandus et audités, jamais avec un script maison, un site de « générateur de clés » ou un tirage de dés dont on ne maîtrise pas tout. Les attaques contre les blockchains elles-mêmes, par opposition aux clés des utilisateurs, feront l’objet d’une leçon ultérieure.
Clés perdues dans la vraie vie : un disque verrouillé, une décharge et une plateforme
L’autre façon de perdre ses cryptos est de perdre soi-même la clé, ou de laisser une seule personne en détenir l’unique exemplaire.
Stefan Thomas, programmeur, détient les clés de 7 002 bitcoins qu’il avait reçus il y a plus de dix ans pour une vidéo expliquant Bitcoin, selon le New York Times. Les clés sont sur un IronKey, un disque chiffré qui autorise 10 essais de mot de passe avant de chiffrer définitivement son contenu. En janvier 2021, TechSpot, citant le Times (en anglais), rapportait qu’il avait utilisé huit essais et perdu le papier où figurait le mot de passe. À strictement parler, son problème est un mot de passe oublié qui protège une clé, non une clé perdue : si le disque s’ouvre, les bitcoins sont là.
James Howells, à Newport, au pays de Galles, affirme qu’un disque dur contenant les clés de plus de 7 500 bitcoins a été jeté par erreur en 2013 et s’est retrouvé dans la décharge de la ville. En janvier 2025, le juge Andrew Keyser KC a rejeté sa demande contre le conseil municipal de Newport, qui réclamait 495 millions de livres sterling de dommages et l’accès au site, estimant qu’elle n’avait « aucun fondement raisonnable » (traduction), d’après The Block (en anglais), qui cite la BBC. Ici, l’unique exemplaire de la clé était un objet physique, et il avait disparu.
QuadrigaCX, plateforme canadienne, a fermé en février 2019 après la mort de son fondateur, Gerald Cotten, présenté comme la seule personne à contrôler ses portefeuilles froids. En décembre 2022, le syndic, Ernst & Young, a déclaré que les clés privées de ces portefeuilles n’avaient pas été localisées malgré un examen détaillé, rapporte Decrypt (en anglais), au moment où environ 104 bitcoins sortaient de cinq portefeuilles liés à la plateforme. EY a précisé ne pas avoir initié ces transferts. D’après Decrypt, des enquêtes officielles ont conclu plus tard que l’essentiel de l’argent des clients n’avait jamais atteint le stockage à froid. Le point sur les clés demeure : une seule personne, aucune sauvegarde.
Dans les trois cas, les cryptos n’ont pas disparu. Elles restent inscrites sur la blockchain, visibles de tous, et personne ne peut les déplacer sans la clé. On ignore combien de bitcoins sont perdus de cette façon. Les estimations comptent les unités immobiles depuis des années, ce qui ne prouve pas une perte, et elles varient beaucoup selon la définition retenue.

Peut-on retrouver une clé privée perdue ?
Seulement à partir d’une copie. Si vous avez encore la phrase de récupération, une sauvegarde du fichier de portefeuille avec son mot de passe, un second appareil contenant le même portefeuille ou une copie écrite de la clé, vous pouvez tout reconstruire en quelques minutes dans n’importe quel portefeuille compatible. Sans aucune copie, non. On ne peut pas deviner la clé, comme le montrent les chiffres ci-dessus, et aucune entreprise, aucun mineur, aucun développeur n’en garde un double.
Un mot de passe oublié est un problème différent, plus modeste. Si la clé se trouve dans un fichier ou un appareil chiffré, l’espace à explorer est le mot de passe, pas la clé. Des mots de passe courts ou prévisibles peuvent parfois être trouvés en essayant des candidats, ce qui explique qu’on ait proposé son aide à Stefan Thomas. Les appareils qui comptent les tentatives, comme son IronKey, limitent cette voie.
Méfiez-vous de quiconque propose de « récupérer » un portefeuille perdu contre paiement. Un vrai service de récupération ne peut agir que sur un problème de mot de passe, et seulement avec vos fichiers. Celui qui prétend retrouver une clé privée à partir d’une adresse ou d’une clé publique décrit une chose qu’aucune méthode connue ne permet, et ces offres sont une arnaque courante. Les ordinateurs quantiques n’y changent rien aujourd’hui.
Ordinateurs quantiques et clés : où l’on en est en octobre 2026
Un ordinateur quantique assez grand, exécutant l’algorithme de Shor, pourrait en principe résoudre le problème du logarithme discret sur courbe elliptique et dériver une clé privée à partir d’une clé publique. C’est la seule question sérieuse à long terme pour ce sens unique. Les clés les plus exposées seraient celles dont la clé publique est déjà visible sur la chaîne, par exemple sur des adresses qui ont déjà dépensé.
Une telle machine n’existe pas. Google Quantum AI a publié le 30 mars 2026 un article sur le risque quantique pour les crypto-monnaies à courbe elliptique et annoncé un nouveau résultat matériel le 15 octobre 2026, que notre compte rendu sur le résultat de Willow lit comme ne mettant aucun bitcoin en danger aujourd’hui. Les développeurs de Bitcoin discutent de propositions de sorties résistantes au quantique, comme BIP 360. Pour un lecteur d’aujourd’hui, le conseil pratique ne change pas : le risque pour vos clés vient de logiciels faibles et de gens qui vous les demandent.
Clés perdues et conservation : l’angle des lecteurs en France
Les autorités européennes de supervision (ABE, ESMA et AEAPP) disent les choses sans détour. Dans la version révisée de leur avertissement sur les crypto-actifs, hébergée par l’ABE et datée d’octobre 2025, elles écrivent que la perte de clés privées sur des crypto-actifs entraîne une perte permanente et irréversible d’accès à ces crypto-actifs. Le même document recommande de tenir à jour ses appareils et ses logiciels pour réduire les failles de sécurité.
La conservation change la personne qui porte ce risque. Quand une plateforme détient vos cryptos, elle détient les clés, et votre protection tient à sa propre sécurité et aux règles qu’elle respecte. En France, c’est le cadre du règlement MiCA, que nous détaillons dans notre guide sur le règlement MiCA. Dans un communiqué du 6 juillet 2026, l’AMF rappelle que MiCA prévoit une autorisation obligatoire pour offrir des services sur crypto-actifs dans l’Union et incite les clients à se tourner exclusivement vers les prestataires autorisés. L’exemple de QuadrigaCX montre ce que peut coûter la dépendance à un seul détenteur de clés.
Quand vous détenez vous-même les clés, en auto-conservation, personne ne peut les geler ou les perdre à votre place, et personne ne peut vous les rendre non plus. Côté impôts, nous n’avons pas trouvé de texte de l’administration fiscale française qui traite de la perte d’accès à une clé privée. Avant d’en tirer une conséquence dans une déclaration, demandez conseil à un professionnel : ce guide donne des informations générales, pas un avis fiscal.
Cinq choses à retenir avant votre prochain portefeuille
- Une clé privée est un nombre aléatoire ; celui qui le connaît possède les cryptos qu’il commande.
- La clé publique et l’adresse s’en calculent, et personne ne sait revenir en arrière : vous pouvez les partager, au prix d’un peu de vie privée.
- Une phrase de récupération reconstruit toutes vos clés privées d’un coup ; elle mérite donc la même protection que les clés elles-mêmes.
- La force brute ne trouve pas une clé correctement tirée au hasard ; ce sont les générateurs faibles, les fuites et l’absence de sauvegarde qui font perdre des clés dans les faits.
- Aucun interlocuteur légitime ne demande votre clé privée ou votre phrase de récupération, et personne ne peut récupérer une clé sans copie.
La prochaine leçon de ce parcours de cryptographie compare le chiffrement symétrique et asymétrique ; les suivantes iront plus loin sur les courbes elliptiques, les schémas de signature, les chemins de dérivation des portefeuilles et la question quantique. Pour l’instant, le test est simple : devant n’importe quelle donnée que montre votre portefeuille, vous devez savoir dire si elle se trouve avant ou après le sens unique.



