Vous sauvegardez une feuille de papier — douze ou vingt-quatre mots — et vous repartez convaincu que vos cryptos sont en sécurité. Pourtant, cette feuille ne protège pas un seul compte : elle protège tous les comptes sur toutes les blockchains prises en charge par votre portefeuille. Dans Zelcore, cela représente plus de 80 chaînes à la fois. Comprendre précisément pourquoi il en est ainsi et ce que cela implique pour vos décisions de conservation constitue le fondement de tout le reste en matière de sécurité de l’auto-conservation.

Comment une phrase de récupération encode un univers de clés

Une phrase de récupération ressemble à une suite de mots aléatoires, mais elle constitue un encodage précis d’entropie brute. BIP-39 — la proposition d’amélioration de Bitcoin qui a normalisé ce format — définit une liste de exactement 2 048 mots anglais. Chaque mot encode 11 bits d’information : aucun mot n’est là pour faire joli. Chaque mot de la phrase contient une donnée précise. Une phrase de 12 mots encode 128 bits d’entropie ; une phrase de 24 mots en encode 256.

La phrase mnémonique elle-même n’est pas la seed cryptographique. Avant de dériver la moindre clé, le portefeuille fait passer la phrase mnémonique dans PBKDF2-HMAC-SHA512 — une fonction de dérivation de clé coûteuse en calcul — avec 2 048 itérations. Le résultat est une valeur binaire de 512 bits : la seed proprement dite. Ce renforcement rend les attaques par force brute impraticables, même si un attaquant devine une partie des mots.

Une conséquence essentielle : si vous ajoutez une phrase secrète facultative (parfois appelée le 25e mot), la fonction PBKDF2 l’intègre et produit une seed de 512 bits complètement différente. Les mêmes douze mots associés à une autre phrase secrète ouvrent un portefeuille entièrement distinct. Il n’existe aucun lien entre les deux ; si vous oubliez la phrase secrète, les fonds sont perdus à jamais.

L’arbre de dérivation : une seed, une infinité de comptes

La seed de 512 bits est la racine d’un arbre de portefeuille déterministe hiérarchique (HD), défini par BIP-32. Le portefeuille transmet les octets de la seed à HMAC-SHA512 (en utilisant la chaîne littérale « Bitcoin seed » comme clé), qui divise la sortie de 512 bits en deux moitiés égales : une clé privée principale de 256 bits et un code de chaîne principal de 256 bits. Chaque clé enfant, clé petit-enfant et adresse du portefeuille est dérivée de ces deux valeurs au moyen d’opérations HMAC-SHA512 répétées.

BIP-44 normalise la façon de parcourir l’arbre en définissant un chemin de dérivation au format m/purpose'/coin_type'/account'/change/index. Chaque segment a un rôle précis :

purpose vaut toujours 44' pour les portefeuilles BIP-44.
coin_type identifie la chaîne ; sa valeur est attribuée à chaque blockchain dans un registre appelé SLIP-0044. Bitcoin correspond à 0, Ethereum à 60, Solana à 501, Litecoin à 2, Dogecoin à 3, Cardano à 1815.
account distingue les comptes indépendants sur une même chaîne.
change et index produisent des adresses individuelles.

Les apostrophes indiquent une dérivation renforcée — une opération à sens unique qui empêche, par calcul, d’utiliser une clé enfant compromise pour dériver des clés sœurs ou la clé parente. C’est pourquoi les clés de votre compte Ethereum ne peuvent pas révéler celles de votre compte Bitcoin, même si les deux proviennent de la même clé principale.

Dans Zelcore, une seule phrase de récupération contrôle simultanément BTC, ETH, SOL, ADA et des dizaines d’autres actifs — chacun dans son propre sous-arbre coin_type, et tous dérivés de manière déterministe de la même racine de 512 bits.

Fonctionnement de cette attaque : un point de défaillance pour toutes les chaînes

Comme la dérivation est déterministe et normalisée, quiconque possède votre phrase de récupération peut régénérer toutes vos clés privées sur chaque chaîne prise en charge. Ce n’est pas une faille de conception : c’est le principe même du système. Le modèle de sécurité part du principe que personne d’autre ne voit jamais la phrase de récupération.

La conséquence concrète est sévère. Une phrase de récupération divulguée ne révèle pas seulement vos Bitcoin. L’attaquant peut dériver votre adresse Ethereum, votre adresse Solana, votre adresse Cardano et celles de tous vos autres actifs, le tout simultanément. Vos avoirs en Solana sont compromis dès que quelqu’un photographie votre phrase de récupération Bitcoin. Cette personne peut même ignorer que vous détenez des SOL.

La perte de la phrase de récupération pose le problème inverse : il n’existe ni solution de secours propre à une chaîne, ni récupération de compte, ni recours auprès du service client. L’entropie qui a généré la seed ne peut pas être inversée mathématiquement. Perdre la feuille, c’est perdre d’un coup l’accès à toutes les chaînes.

C’est pourquoi les portefeuilles matériels génèrent la phrase de récupération dans un élément sécurisé et ne la communiquent jamais à l’ordinateur connecté. La seed est produite hors ligne et y reste.

Métadonnées propres aux chaînes que la seed ne conserve pas

La restauration à partir d’une phrase de récupération régénère les clés privées et les chemins de dérivation standard, mais ne préserve pas tout. Plusieurs catégories de données se trouvent hors de portée de ce que la seed peut reconstituer :

Métadonnées hors chaîne : les libellés de transaction, les entrées du carnet d’adresses et les notes personnalisées sont stockés par l’application de portefeuille, et non sur la blockchain.
Chemins de dérivation non standard : certains anciens portefeuilles et certaines chaînes (Solana et Cardano ont historiquement utilisé des conventions de chemin différentes de celles de la norme BIP-44) peuvent faire apparaître un solde nul après une restauration dans une autre application de portefeuille, même si les fonds existent bien sur la blockchain. Les clés sont là ; le logiciel consulte simplement la mauvaise adresse.
Soldes de tokens : les tokens ERC-20 sur Ethereum et les tokens SPL sur Solana sont enregistrés par des contrats intelligents sur la blockchain, mais un outil de récupération minimal peut n’afficher que le solde de la cryptomonnaie native. Les tokens sont en sécurité ; il faut simplement que le portefeuille interroge les contrats concernés.
Positions DeFi et NFT : elles ne sont visibles que si le portefeuille sait quels contrats de protocole interroger et quel point de terminaison RPC utiliser.

Recommandation pratique : consignez non seulement votre phrase de récupération, mais aussi le logiciel de portefeuille et les chemins de dérivation utilisés. Quelques mois ou quelques années plus tard, la phrase de récupération seule ne fournit pas toujours assez de contexte pour une restauration.

Réutilisation des adresses et identité inter-chaînes

La segmentation coin_type de BIP-44 signifie qu’une adresse Bitcoin et une adresse Ethereum dérivées de la même seed ne sont pas liées mathématiquement : elles partagent une racine, mais pas une clé publique. En revanche, les chaînes compatibles avec EVM — Ethereum, BNB Chain, Polygon, Avalanche C-Chain, Base et d’autres — utilisent toutes coin_type = 60. La même adresse 0x... apparaît donc sur chaque chaîne EVM.

C’est intentionnel, mais cela crée un lien entre vos identités sur différentes chaînes. Toute personne qui connaît votre adresse Ethereum peut consulter votre activité sur chaque chaîne EVM en recherchant cette même adresse. Si la confidentialité vous importe, il vaut mieux le savoir avant de regrouper vos actifs.

Le modèle UTXO de Bitcoin incite traditionnellement à générer une nouvelle adresse pour chaque transaction — les portefeuilles HD le font automatiquement. Avec le modèle par compte d’Ethereum, la rotation des adresses est peu courante ; la plupart des utilisateurs gardent la même adresse pour chaque compte indéfiniment. Réutiliser une adresse Bitcoin pour de nombreuses transactions réduit la confidentialité, car il devient plus facile de relier les entrées à un propriétaire commun.

Pour conserver des actifs de grande valeur, envisagez de les séparer en fonction de leur seed : utilisez une phrase de récupération distincte pour vos activités de trading plus risquées et vos avoirs à long terme, ou un appareil isolé d’Internet (qui n’a jamais été connecté à une machine ayant accès à Internet) pour vos positions importantes.

Comment vous protéger : défendre ce point de défaillance unique

La phrase de récupération est à la fois votre outil de récupération le plus puissant et votre point de défaillance unique le plus dangereux. Voici des mesures concrètes pour la protéger :

Gravez-la sur du métal, pas sur du papier. Les plaques de sauvegarde en acier inoxydable ou en titane résistent au feu et aux inondations. Le papier, lui, n’y résiste pas.
Ne la numérisez jamais. Pas de capture d’écran, pas de note dans le cloud, pas de gestionnaire de mots de passe, pas de copie saisie au clavier. Dès qu’une phrase de récupération est enregistrée sur un appareil connecté à un réseau, la surface d’attaque s’élargit considérablement.
Vérifiez la récupération avant d’y déposer des sommes importantes. Restaurez le portefeuille sur un appareil vierge en utilisant uniquement la phrase de récupération, afin de confirmer qu’elle fonctionne et permet de retrouver les adresses attendues.
Envisagez le partage de secret de Shamir (SLIP-39). SLIP-39 est une norme qui divise une phrase de récupération en N parts, dont M suffisent à la reconstituer. Vous pouvez ainsi les répartir en différents lieux : une part dans un coffre-fort à domicile, une chez une personne de confiance, une autre dans le coffre d’une banque, sans qu’aucun lieu ne détienne le secret complet.
Comprenez le compromis lié à la phrase secrète. Une phrase secrète robuste (le « 25e mot ») permet de nier de manière plausible détenir des fonds : un petit montant leurre se trouve dans le portefeuille sans phrase secrète, tandis que les avoirs réels ne sont accessibles qu’avec celle-ci. Le risque est symétrique : oublier la phrase secrète est aussi irréversible que perdre la phrase de récupération.

Pour les utilisateurs de portefeuille crypto qui détiennent des actifs sur de nombreuses chaînes dans Zelcore, ce dernier point est particulièrement important : un seul test de récupération devrait couvrir toutes les chaînes que vous utilisez activement, pas seulement la plus évidente.

Points clés à retenir

Une phrase de récupération de 12 mots encode 128 bits d’entropie ; une phrase de 24 mots en encode 256. Aucune des deux ne peut être récupérée si elle est perdue.
BIP-32 et BIP-44 dérivent un sous-arbre de clés distinct pour chaque blockchain (coin_type), mais tous les sous-arbres descendent de la même clé maîtresse : si la phrase de récupération est compromise, toutes les chaînes le sont en même temps.
La prise en charge de plus de 80 chaînes par Zelcore signifie qu’une seule phrase de sauvegarde contrôle un portefeuille vaste et diversifié ; la sécurité physique de cette sauvegarde compte autant que sa longueur.
Les chaînes EVM (Ethereum, BNB Chain, Polygon et autres) partagent coin_type = 60 et donc le même espace d’adresses : la même adresse 0x apparaît sur chacune d’elles.
Une restauration à partir de la seule phrase de récupération peut ne pas faire apparaître les soldes de tokens ni les positions DeFi ; consignez le logiciel de portefeuille et les chemins de dérivation utilisés.
Les sauvegardes sur métal, la répartition géographique via SLIP-39 et l’ajout d’une phrase secrète sont les trois mesures concrètes qui réduisent sensiblement le risque lié à un point de défaillance unique.