---
title: "Portefeuilles froids : signature hors ligne, récupération et contrôles opérationnels"
description: "Apprenez à concevoir et vérifier la garde de portefeuilles froids à travers la génération de clés, l'identité du portefeuille, les sauvegardes, la révision des transactions, la signature hors ligne, le multisignature, la récupération et la réponse aux incidents."
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.
# Portefeuilles froids : signature hors ligne, récupération et contrôles opérationnels
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Un portefeuille froid est un système de garde qui garde le matériel de signature secret et l'étape décisive d'approbation en dehors de l'exposition normale des logiciels connectés à Internet. Les actifs restent sur la blockchain ; le système contrôle les clés ou toute autre autorité pouvant autoriser des changements d'état. « Portefeuille froid » est une étiquette opérationnelle, et non une classe d'appareil définie par un protocole, et la froideur est une propriété du flux de travail complet plutôt qu'une marque ou un type de connexion.
Un dispositif de signature matériel peut prendre en charge le stockage à froid tout en étant connecté par USB car la clé privée peut rester isolée, mais le flux de travail est dangereux si l'utilisateur signe une destination non vérifiée ou un appel de contrat opaque. À l'inverse, un ordinateur déconnecté du réseau n'est pas sûr simplement parce qu'il ne dispose pas d'interface réseau : l'entropie compromise, les supports d'installation, les analyseurs de transactions, les supports amovibles, les sauvegardes ou les écrans peuvent encore franchir la frontière. Le stockage à froid réduit l'exposition à l'extraction de clés à distance ; il ne prouve pas l'intention de la transaction, la justesse du logiciel, la récupération, la confidentialité ou la finalité.
La copie de récupération n'est pas « simplement une sauvegarde ». Un mnémonique, une graine brute, une clé privée étendue ou un partage de récupération équivalent peut recréer l'autorité de dépense et doit donc bénéficier d'une protection comparable à celle d'un signataire. Une phrase de passe, un chemin de dérivation, un réseau, un type de script, un descripteur de portefeuille, l'ordre des clés et la politique de seuil peuvent également être nécessaires pour récupérer les adresses attendues. Un portefeuille public en mode lecture seule ne peut normalement pas signer, mais un `xpub` ou un descripteur peut révéler les relations entre adresses et l'historique des transactions, et BIP-32 donne aux clés publiques étendues des implications de sécurité plus fortes que les clés publiques ordinaires.
## Comment concevoir et vérifier le stockage à froid
### 1. Définir l'autorité et le modèle de menace
Enregistrez le réseau exact, l'actif, le compte ou la politique de sortie, les propriétaires, les bénéficiaires, l'autorité de récupération, la fréquence prévue des transactions et l'exposition opérationnelle maximale. Identifiez les logiciels malveillants distants, les applications malveillantes, les compromissions de la chaîne d'approvisionnement, la collusion interne, le vol physique, la coercition, le feu, l'inondation, la perte, l'incapacité et l'héritage comme menaces distinctes. Décidez de ce qui doit rester froid : une seule clé privée, toutes les clés dans un seuil, un quorum de signataires, une clé d'autorisation EIP-712, ou un administrateur capable de modifier le code du portefeuille.
### 2. Initialiser une entropie et des logiciels fiables
Obtenez les appareils et logiciels via des canaux authentifiés, vérifiez l'état d'initialisation, confirmez les versions lorsque cela est pris en charge, et refusez tout mnémonique ou secret pré-généré fourni dans l'emballage ou par un assistant. Générez de l'entropie dans un environnement contrôlé et enregistrez quelle norme et quelle implémentation l'ont créée. BIP-39 encode `128` en `256` bits d'entropie sous forme de mnémonique et dérive une graine `512-bit` à partir du mnémonique plus un mot de passe optionnel ; ce n'est pas une norme pour transformer une phrase mémorable en portefeuille sécurisé.
### 3. Fixer l'identité reproductible du portefeuille
Avant un financement substantiel, enregistrez le réseau, l’empreinte principale, la norme de dérivation et le chemin complet, l’indice du compte, le type d’adresse ou de script, et les premières adresses de réception vérifiées. Pour les politiques Bitcoin, conservez le descripteur de sortie, le checksum, les origines des clés, le seuil, le nombre de signataires, l’ordre des clés et les branches de changement. Pour chaque signataire, confirmez de manière indépendante que sa clé et la politique affichée sont bien celles prévues. Traitez un `xpub` comme des métadonnées sensibles : il peut dériver des descendants publics non durcis, nuire à la confidentialité et, avec une clé privée enfant non durcie correspondante, exposer la clé privée étendue parentale sous BIP-32.
### 4. Sauvegarder et tester la récupération
Protégez chaque entrée de récupération requise, y compris le mnémonique ou les parts, la phrase de passe optionnelle, le descripteur ou la configuration du compte intelligent, le chemin de dérivation et les instructions de récupération. N'inventez pas de schéma en divisant les mots mnémoniques en fragments ad hoc ; utilisez un seuil spécifié ou une conception multisig lorsque aucune copie unique ne doit suffire. Placez les copies dans des domaines de défaillance véritablement indépendants et suivez l'accès sans en exposer le contenu. Sur un signataire de secours fiable ou réinitialisé, répétez la restauration et comparez l'empreinte, la politique et l'adresse de réception attendues avant d'effacer l'environnement de test.
### 5. Construire et vérifier l'intention complète
Un coordinateur en ligne peut obtenir l'état de la chaîne et construire une demande non signée, mais il n'est pas fiable. Pour un Bitcoin `PSBT`, vérifiez le réseau, chaque entrée et le montant UTXO, la sortie destinataire, le montant, les frais, le taux de frais, le locktime, la politique de sighash, et si chaque autre sortie est un changement authentifié. Pour une transaction EVM, vérifiez `chainId`, `nonce`, `to`, `value`, la limite de gaz, les plafonds des frais, et le `data` décodé ; pour EIP-712, vérifiez le domaine, `chainId`, `verifyingContract`, les champs du message, le nonce, et la date limite lorsque cela s'applique. EIP-712 structure les données et sépare les domaines, mais la norme ne fournit explicitement pas de protection contre la relecture par elle-même.
### 6. Signer à travers une frontière de transfert contrôlée
Ne déplacez que la charge utile non signée ou partiellement signée requise via le QR, la carte, le câble ou tout autre canal approuvé. Les écarts physiques et les codes QR ne rendent pas les analyseurs ou les supports fiables : le signataire doit analyser la charge utile, authentifier la politique et le changement, afficher les conséquences matérielles et refuser les champs non supportés. Dans le cas du multisignature, gardez les signataires, opérateurs, emplacements, fournisseurs et chemins de récupération suffisamment indépendants pour correspondre au modèle de menace ; traitez le coordinateur comme remplaçable et incapable de modifier la politique sans être remarqué. Comparez la transaction ou l'opération signée avec l'intention approuvée avant la diffusion.
### 7. Rapprocher, maintenir et préparer la migration
Après la diffusion, faites correspondre l'identifiant de la transaction, la transaction incluse, les sorties ou journaux, les frais réels, la modification, le nonce du compte, les autorisations et les soldes résultants avec l'intention signée, puis attendez la finalité appropriée à la chaîne et au cas d'utilisation. Maintenez un logiciel compatible, des chemins de firmware vérifiés, des sauvegardes lisibles, des descripteurs documentés et des exercices périodiques de récupération sans entrer de secrets de production dans un appareil en ligne. Si un secret de signature ou de récupération peut être exposé, un compte à clé unique simple ne peut pas révoquer cette clé : établissez une nouvelle autorité, migrez les actifs et les rôles, invalidez les permissions restantes là où le protocole le permet, et conservez un enregistrement de l'incident.
## Exemples travaillés
### Allocation et financement par étapes
Un plan de garde limite le portefeuille d'interaction en ligne à `5%` de `100,000 units` de valeur d'actif : `100,000 × 5% = 5,000 units` à chaud et `95,000 units` à froid. La destination froide reçoit d'abord un test de `100-unit`, et le reste du transfert est `95,000 - 100 = 94,900 units`. Après les deux transferts, le solde cible à froid est `100 + 94,900 = 95,000 units` ; le petit test limite une erreur de configuration mais ne valide pas les signatures futures ni la récupération de sauvegarde.
### Bitcoin PSBT frais et changement
Un `PSBT` utilise des entrées de `0.80 BTC` et `0.35 BTC`, pour un total de `1.15 BTC`. Il paie `1.00 BTC` au destinataire et estime `250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC`. Le changement authentifié doit donc être `1.15 - 1.00 - 0.000020 = 0.149980 BTC`. Si le signataire ne peut pas identifier cette sortie de changement à partir de sa politique enregistrée, il ne doit pas signer même si l'arithmétique totale est équilibrée.
### Budget maximum EVM par rapport aux frais réels
Un compte EVM commence par `5 ETH` et approuve un transfert de `1.2 ETH`. Une limite `30,000 gas` et des frais maximaux `50 gwei` impliquent un budget de frais de `30,000 × 50 gwei = 0.001500 ETH`. Si la transaction utilise `21,000 gas` à un prix effectif de `25 gwei`, les frais réels sont de `21,000 × 25 gwei = 0.000525 ETH`, laissant `5 - 1.2 - 0.000525 = 3.799475 ETH`. Le signataire doit examiner les plafonds de frais et `data`, sans supposer que le budget maximal sera prélevé ou qu'une interface apparemment vide prouve un transfert ordinaire.
### Résilience du signataire deux sur trois
Une politique `2-of-3` avec les signataires `A`, `B` et `C` a `3` paires de signatures valides : `AB`, `AC` et `BC`. Si un signataire est indisponible, exactement `1` paire reste ; si un signataire est compromis, ce signataire seul contrôle `0` paires valides ; si deux signataires sont compromis, ils contrôlent `1` paire valide et peuvent effectuer des dépenses. Le design tolère donc une perte ou un compromis isolé, pas deux, et la récupération nécessite toujours le bon descripteur, les données de dérivation et l'ordre des clés.
## Risques et échecs de révision
- **Mauvais réseau ou mauvaise politique :** restaurer une clé valide avec la mauvaise chaîne, le mauvais type d'adresse, script, compte ou règlement de compte intelligent peut produire des adresses différentes ou inutilisables.
- **Entropie insuffisante :** un aléa prévisible, un brainwallet ou un générateur compromis peut rendre une clé devinable même hors ligne.
- **Secret fourni par un tiers :** une phrase mnémonique préimprimée, importée, photographiée ou remise par un assistant peut déjà être contrôlée par l'attaquant.
- **Sauvegarde exposée :** papier, métal, copies cloud, imprimantes, appareils photo, transport ou documents successoraux peuvent révéler toute l'autorité de dépense.
- **Erreur de phrase secrète :** perdre ou mal saisir la phrase secrète BIP-39 peut dériver un autre portefeuille sans signaler d'erreur.
- **Paramètres de dérivation incohérents :** chemins, types de monnaie, index de compte ou conventions manquants peuvent masquer des actifs récupérables.
- **Perte de configuration :** des clés multisig sans descripteur, seuil, type de script, origine et ordre des clés peuvent ne pas reconstruire le portefeuille approvisionné.
- **Fuite de métadonnées publiques :** un `xpub`, un descripteur, l'inventaire d'adresses ou la base du coordinateur peuvent révéler soldes, liens et adresses futures.
- **Chaîne d'approvisionnement compromise :** matériel, micrologiciel, logiciel, emballage ou canaux de mise à jour altérés peuvent remplacer entropie, adresses ou signatures.
- **Substitution par l'hôte :** le coordinateur en ligne peut changer destinataire, montant, frais, monnaie, calldata, message typé ou charge non signée.
- **Affichage insuffisant :** troncature, signature aveugle, scripts non pris en charge ou décodage incomplet peuvent masquer une autorisation importante.
- **Attaque sur l'adresse de rendu :** si le signataire n'authentifie pas la sortie de rendu par rapport à la politique, une transaction Bitcoin peut l'envoyer à l'attaquant.
- **Erreur de frais ou de nonce :** frais excessifs, anciens nonces EVM, locktimes erronés ou modes sighash inattendus peuvent retarder, remplacer ou altérer l'exécution.
- **Autorité contractuelle persistante :** approbations de jetons, permis, modules, délégations et appels administratifs peuvent rester valides après la transaction visible.
- **Attaque du canal de transfert :** QR, USB, cartes, câbles et formats de parseur peuvent transporter des charges malveillantes ou faire fuiter des métadonnées.
- **Seuil corrélé :** signataires au même endroit, seeds partagées ou dépendance à un fournisseur, opérateur ou site de récupération unique réduisent l'indépendance du seuil.
- **Attaque physique :** vol, coercition, surveillance, altération et découverte des secrets restent possibles sans accès réseau.
- **Dommage environnemental :** incendie, inondation, corrosion, vieillissement des supports, coffres inaccessibles, décès ou incapacité peuvent rendre un secret correct indisponible.
- **Compatibilité dégradée :** ancien micrologiciel, dérivations ou scripts non pris en charge et migrations non documentées peuvent empêcher une récupération ou signature future.
- **Réponse à incident incomplète :** consulter le solde sans migrer clés, rôles, approbations et autorité de récupération peut laisser la compromission initiale active.
## Idées reçues
### Un portefeuille froid doit-il rester physiquement déconnecté pour toujours ?
Non. La propriété de sécurité est que l'autorité secrète reste isolée et que la signature se fait via une frontière contrôlée et vérifiable. Un dispositif de signature matériel connecté par câble peut préserver cette propriété ; un ordinateur isolé du réseau avec une configuration compromise ou une inspection du programme malveillant peut ne pas le faire.
### Les pièces sont-elles stockées à l'intérieur du dispositif matériel ?
Non. L'état de la blockchain enregistre les actifs. L'appareil protège ou utilise l'autorité qui peut signer des transactions, et le matériel de récupération compatible peut reproduire cette autorité sur une autre implémentation.
### Une sauvegarde mnémotechnique est-elle moins sensible que le dispositif de signature ?
Non. Un mnémonique complet et la phrase de passe requise peuvent recréer le portefeuille. Une sauvegarde est normalement inactive, mais sa compromission peut être aussi décisive que l'extraction de la clé de signature en direct.
### Est-ce que le multisig supprime le besoin de sauvegardes et d'enregistrements de configuration ?
Non. Les seuils réduisent les points de défaillance uniques sélectionnés, mais chaque clé a besoin d'un plan de récupération et la politique du portefeuille ou le descripteur doit être reproductible. Trop peu de clés survivantes ou une configuration perdue peuvent toujours bloquer les fonds.
### Un test de transfert réussi prouve-t-il que le système de stockage à froid est sûr ?
Non. Cela confirme un chemin limité à un moment donné. Cela ne prouve pas la qualité de l'entropie, la confidentialité de la sauvegarde, la restauration, le décodage des transactions futures, l'indépendance du quorum, les mises à jour logicielles, la sécurité des contrats ou la récupération après incident.
## Sujets liés
- [Portefeuille matériel](/fr/crypto/hardware-wallet/)
- [Phrase de récupération](/fr/crypto/seed-phrase/)
- [Clés publiques et privées](/fr/crypto/public-private-key/)
- [Portefeuille multisignature](/fr/crypto/multisig-wallet/)
- [Simulation de transaction](/fr/crypto/transaction-simulation/)
## Sources
- [Aperçu de la technologie Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté : 2026-08-19)
- [BIP 32 : Portefeuilles déterministes hiérarchiques](https://bips.dev/32/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [BIP 39 : Code mnémonique pour générer des clés déterministes](https://bips.dev/39/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [BIP 44 : Hiérarchie multi-comptes pour portefeuilles déterministes](https://bips.dev/44/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [BIP 174 : Format de transaction Bitcoin partiellement signée](https://bips.dev/174/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [BIP 380 : Fonctionnement général des descripteurs de script de sortie](https://bips.dev/380/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [BIP 129 : Configuration Multisig Sécurisée Bitcoin](https://bips.dev/129/) - Propositions d'amélioration Bitcoin (consulté : 2026-08-19)
- [EIP-712 : Hachage et Signature de Données Structurées Typées](https://eips.ethereum.org/EIPS/eip-712) - Propositions d'amélioration Ethereum (consulté : 2026-08-19)
Source: https://wiki.fcontext.com/fr/crypto/cold-wallet/index.mdx