--- title: "Portefeuille déterministe hiérarchique (HD)" description: "Découvrez comment un portefeuille HD dérive une arborescence de clés à partir d'une seule graine, en quoi les dérivations renforcée et normale diffèrent, et ce qu'une sauvegarde complète et testable doit préserver." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Portefeuille déterministe hiérarchique (HD) > À des fins éducatives uniquement ; ne constitue pas un conseil en investissement. Investir peut entraîner des pertes. ## Réponse directe Un portefeuille déterministe hiérarchique (HD) dérive une arborescence reproductible de paires de clés cryptographiques à partir d'une seule graine racine. BIP-32 définit le mécanisme de l'arborescence : chaque nœud est une clé étendue qui contient une clé ainsi qu'un code de chaîne de `32-byte`, et chaque enfant est sélectionné par un indice. Les mêmes données racines, règles de dérivation et chemin reproduisent les mêmes clés enfants. Le caractère « déterministe » rend la sauvegarde pratique ; il ne rend pas tous les portefeuilles interchangeables. Une phrase mnémonique est une façon possible d'encoder l'entropie et de produire une graine, tandis qu'un chemin de dérivation sélectionne un nœud et qu'une règle d'adresse ou de script transforme sa clé publique en un élément reconnu par une blockchain. Restaurer uniquement les mots peut faire apparaître un portefeuille vide si la phrase secrète, le chemin, le réseau, le type de script ou les règles de découverte des comptes diffèrent. Le caractère « hiérarchique » signifie que l'autorité peut être répartie en sous-arborescences. Une clé publique étendue au niveau du compte peut permettre à un service en lecture seule de dériver des clés publiques descendantes normales sans détenir les clés de dépense. Une clé privée étendue peut dériver la sous-arborescence privée correspondante et doit être protégée comme un ensemble de clés privées, pas comme une seule adresse. Un portefeuille HD est un modèle de gestion des clés, pas un objet de portefeuille sur la blockchain. La blockchain ne stocke ni le mnémonique, ni la graine, ni le chemin, ni les étiquettes, ni la sauvegarde. Ce sont des données hors chaîne conservées par le logiciel de portefeuille et l'utilisateur. ## Fonctionnement ### 1. De l'entropie à la racine BIP-39 est couramment utilisé avant BIP-32, mais ces normes sont distinctes. BIP-39 encode `128-256 bits` d'entropie avec une somme de contrôle sous forme de `12-24 words`, puis applique PBKDF2-HMAC-SHA512 avec `2048` itérations au mnémonique normalisé et à la phrase secrète facultative pour produire une graine de `512-bit`. Chaque phrase secrète produit une graine valide mais différente ; une phrase secrète manquante ou mal saisie n'est donc pas détectée de manière fiable par un message « mot de passe invalide ». BIP-32 utilise HMAC-SHA512 avec la clé `Bitcoin seed` pour convertir les octets de la graine en clé privée maître et en code de chaîne maître. Cette clé privée étendue racine est la source de l'arborescence BIP-32. Tous les portefeuilles déterministes n'utilisent pas BIP-39 ou BIP-32 ; la récupération doit donc identifier le schéma réellement employé au lieu de le déduire de la seule présence de mots de récupération. ### 2. Clés étendues et dérivation des clés enfants Une clé privée étendue BIP-32 associe une clé privée à un code de chaîne ; sa clé publique étendue neutralisée associe la clé publique correspondante au même code de chaîne. La dérivation normale d'un enfant utilise la clé publique du parent, le code de chaîne et l'indice de l'enfant, si bien qu'une clé publique étendue peut dériver des clés publiques enfants normales. Elle ne peut pas dériver leurs clés privées. Les enfants renforcés utilisent des indices allant de `2^31` à `2^32 - 1` et incorporent des données de la clé privée parente. Ils ne peuvent pas être dérivés de la clé publique étendue parente. Les chemins les indiquent généralement par une apostrophe, comme dans `m/84'/0'/0'`. Le renforcement limite les conséquences d'une défaillance particulière de BIP-32 : une clé publique étendue parente associée à l'une des clés privées enfants non renforcées correspondantes permet de retrouver la clé privée étendue parente. ### 3. Les chemins donnent un sens à l'arborescence BIP-44 définit `m / purpose' / coin_type' / account' / change / address_index`. Les `3` premiers niveaux sont renforcés ; `change` et `address_index` sont normaux afin que les clés publiques de compte puissent générer des adresses de réception et de monnaie. Par convention, la branche `0` est externe et la branche `1` sert à la monnaie interne. La découverte BIP-44 analyse l'historique des transactions et applique une limite d'écart de `20` adresses externes inutilisées consécutives. Le chemin est une métadonnée, non un secret ni une garantie universelle. BIP-84 attribue l'objectif `84'` aux comptes SegWit natifs P2WPKH, tandis que d'autres objectifs ou structures propres à un portefeuille produisent d'autres sous-arborescences. Le type de monnaie est une convention d'espace de noms, pas une règle imposée par une blockchain. ### 4. Les clés ne constituent pas tout le portefeuille Une clé publique a encore besoin de règles de réseau, d'adresse ou de script. Pour Bitcoin, la même clé peut participer à différents scripts de sortie ; un portefeuille multisignature a aussi besoin du seuil, des clés des cosignataires, de l'ordre des clés et des origines de dérivation. Les descripteurs de scripts de sortie BIP-380 associent les clés et leurs origines à des expressions de script explicites et peuvent inclure une somme de contrôle. C'est pourquoi une sauvegarde limitée à la graine peut ne pas suffire à recréer ce que le portefeuille d'origine surveillait ou pouvait dépenser. Les étiquettes du portefeuille, les contacts, les notes de transaction, les clés importées, les noms de comptes ainsi que certains paramètres de récupération de contrats ou de comptes intelligents ne sont généralement pas dérivés de façon déterministe. Ils exigent une exportation ou une documentation distincte. ### 5. Sauvegarde et récupération sont des processus testés Consignez l'implémentation du portefeuille, le format du mnémonique ou de la graine, l'existence éventuelle d'une phrase secrète, l'empreinte maître, les chemins pertinents, les réseaux, les indices de comptes ainsi que les descripteurs Bitcoin ou les données de politique équivalentes. Gardez les secrets racines hors ligne et, lorsque c'est possible, séparés des métadonnées publiques de récupération. Un `xpub` ne peut pas dépenser seul, mais il peut révéler les soldes, les relations entre adresses et les futurs descendants normaux. Testez la récupération dans un environnement de confiance avant de compter sur la sauvegarde. Commencez par comparer des adresses ou des descripteurs connus sans déplacer de fonds ; vérifiez ensuite les branches de réception et de monnaie, les comptes ultérieurs, l'historique des transactions et la signature à l'aide d'une petite transaction contrôlée. Ne saisissez jamais un mnémonique, une phrase secrète ou un `xprv` sur un site web ou dans un service d'assistance non fiable. ## Exemple Prenons un compte Bitcoin SegWit natif au chemin `m/84'/0'/0'`. L'objectif `84'` sélectionne la convention BIP-84, `0'` l'espace de noms du type de monnaie Bitcoin, et le dernier `0'` le premier compte. Un système en lecture seule peut recevoir la clé publique étendue du compte et dériver les branches normales sans recevoir la clé privée du compte. La première clé de réception externe se trouve à `m/84'/0'/0'/0/0` ; la suivante à `m/84'/0'/0'/0/1`. La première clé de monnaie interne se trouve à `m/84'/0'/0'/1/0`. Elles descendent toutes du même compte, mais la branche et l'indice sélectionnent des clés différentes. Réutiliser la graine avec `m/44'/0'/0'/0/0` sélectionne une autre sous-arborescence et une autre convention de sortie ; un résultat vide ne prouve pas que la graine est erronée. Pour un dossier complet de récupération Bitcoin, conservez la sauvegarde du secret racine séparément du descripteur ou des métadonnées équivalentes qui indiquent l'empreinte, le chemin, la clé publique étendue, le type de script et la somme de contrôle. Vérifiez plusieurs adresses précédemment utilisées sur les deux branches. Retrouver seulement la première adresse de réception prouve qu'une feuille est correcte, mais pas que chaque compte, sortie de monnaie ou politique du portefeuille a été récupéré. ## Risques - **Concentration sur une racine unique :** la compromission d'une graine racine ou d'une clé privée étendue de niveau suffisamment élevé peut exposer tous les descendants dans son périmètre. - **Perte de la sauvegarde :** perdre l'unique sauvegarde de la graine, ou perdre séparément une phrase secrète BIP-39 non documentée, peut rendre toutes les clés dérivées irrécupérables. - **Fausse confiance dans la phrase secrète :** une phrase secrète BIP-39 erronée crée un portefeuille différent mais valide, qui peut donner l'impression d'une restauration réussie mais vide. - **Incompatibilité du chemin ou du script :** la bonne graine utilisée avec le mauvais objectif, compte, branche, réseau ou type de sortie génère des adresses valides mais sans rapport. - **Sauvegarde incomplète de la politique :** une graine et un chemin seuls peuvent ne pas reconstruire les conditions de dépense multisignatures, à descripteur, de compte intelligent ou propres au portefeuille. - **Fuite de confidentialité par clé publique étendue :** un `xpub` peut révéler un groupe d'adresses et permettre le suivi continu des descendants normaux. - **Compromission du parent BIP-32 :** un `xpub` parent associé à une clé privée enfant non renforcée correspondante qui a fuité peut révéler la sous-arborescence privée parente. - **Outils de récupération non fiables :** sites web, extensions, appareils contrefaits, outils de presse-papiers ou partage d'écran peuvent capturer l'intégralité du secret racine. - **Supports non testés :** papier, métal, fichiers chiffrés ou sauvegardes matérielles peuvent échouer à cause d'une erreur de transcription, de la corrosion, de mots de passe oubliés ou de formats non pris en charge. - **Migration incomplète :** déplacer les fonds visibles tout en laissant des jetons, sorties de monnaie, rôles de contrat, autorisations ou comptes ultérieurs sous l'ancienne racine maintient l'exposition. ## Idées reçues courantes ### Une phrase de sauvegarde contient-elle tous les détails du portefeuille ? Non. Elle peut reproduire les données de clé racine, mais pas nécessairement la phrase secrète, la convention de dérivation, le réseau, les scripts, la politique multisignature, les étiquettes, les clés importées ou l'historique de découverte des comptes. Conservez les métadonnées nécessaires au portefeuille réellement utilisé. ### Peut-on publier un `xpub` en toute sécurité puisqu'il ne peut pas dépenser ? Non. En principe, il ne peut pas signer, mais il peut révéler les adresses descendantes normales passées et futures ainsi que leur historique combiné. Dans la défaillance BIP-32 décrite plus haut, son association avec une clé privée enfant non renforcée correspondante peut également compromettre la sous-arborescence parente. ### Les nouvelles adresses créent-elles des sauvegardes indépendantes ? Non. Les nouvelles adresses limitent la réutilisation des adresses et améliorent la confidentialité, mais les descendants déterministes restent contrôlés par le même ancêtre. La compromission de la racine affecte la sous-arborescence même si chaque paiement a utilisé une nouvelle adresse. ### Restaurer une adresse connue prouve-t-il que le portefeuille est complet ? Non. Cela valide une combinaison de données racines, de chemin et de construction d'adresse. La récupération doit encore couvrir les branches de réception et de monnaie, tous les comptes utilisés, les scripts ou politiques et les réseaux concernés. ## Sujets connexes - [Chemin de dérivation du portefeuille](/fr/crypto/derivation-path/) - [Phrase de récupération](/fr/crypto/seed-phrase/) - [Clés publiques et privées](/fr/crypto/public-private-key/) - [Portefeuille matériel](/fr/crypto/hardware-wallet/) - [Portefeuille froid](/fr/crypto/cold-wallet/) ## Sources - [BIP 32 : Portefeuilles déterministes hiérarchiques](https://bips.dev/32/) - Bitcoin Improvement Proposals (consulté : 2026-08-20) - [BIP 39 : Code mnémonique pour générer des clés déterministes](https://bips.dev/39/) - Bitcoin Improvement Proposals (consulté : 2026-08-20) - [BIP 44 : Hiérarchie multi-compte pour les portefeuilles déterministes](https://bips.dev/44/) - Bitcoin Improvement Proposals (consulté : 2026-08-20) - [BIP 84 : Schéma de dérivation pour les comptes P2WPKH](https://bips.dev/84/) - Bitcoin Improvement Proposals (consulté : 2026-08-20) - [BIP 380 : Fonctionnement général des descripteurs de scripts de sortie](https://bips.dev/380/) - Bitcoin Improvement Proposals (consulté : 2026-08-20) Source: https://wiki.fcontext.com/fr/crypto/hd-wallet/index.mdx