Qu’est-ce que la conservation de crypto-actifs ?
La conservation de crypto-actifs est un dispositif de contrôle et de protection des clés, fragments de clés ou autres mécanismes d’autorisation servant à gérer des crypto-actifs. Les actifs restent représentés selon les règles d’une blockchain. La conservation concerne l’identité des parties capables d’autoriser une transaction, la protection et la récupération de ce pouvoir, ainsi que la manière dont un service enregistre et gouverne son utilisation.
Il s’agit d’une définition opérationnelle, pas d’une conclusion juridique. La qualification juridique d’un dispositif, la propriété de l’actif, le rang des créances des clients et les règles applicables peuvent dépendre de la juridiction, du contrat et de la structure du compte.
La conservation commence par une cartographie des autorisations
De nombreuses blockchains acceptent les signatures numériques comme preuve qu’une action contrôlée par clé a été autorisée. D’autres comptes emploient plusieurs clés, des règles de contrat intelligent ou des rôles de récupération. Une architecture de conservation doit donc cartographier explicitement :
- le compte onchain ou la condition de dépense qui contrôle l’actif ;
- les clés, fragments, rôles ou contrats capables de satisfaire cette condition ;
- le nombre d’approbations requises et la politique applicable ;
- les personnes capables de modifier la politique, remplacer des signataires ou lancer une récupération ;
- les systèmes capables de construire, approuver, signer et diffuser une transaction.
L’interface du portefeuille n’est qu’un composant. La personne capable de consulter un solde ou de préparer un retrait ne contrôle pas forcément l’autorité de signature. À l’inverse, un prestataire peut contrôler la signature sans jamais montrer les clés au client. Le NIST IR 8202 décrit le rôle des clés privées et signatures dans l’autorisation des transactions, tandis que le NIST IR 8301 distingue les modèles de conservation directe, par un tiers et partielle. NIST IR 8202 et NIST IR 8301
De l’instruction du client à la transaction onchain
Un processus de conservation gérée peut comprendre :
- la création ou l’attribution d’adresses de dépôt ;
- la génération de clés ou de fragments et l’enregistrement de leurs rôles d’autorisation ;
- l’attribution des dépôts aux comptes clients ou internes ;
- le contrôle d’une instruction de retrait au regard des politiques d’accès et de transaction ;
- la construction et la vérification indépendante de la destination, du réseau, du montant et des frais ;
- la collecte des approbations ou fragments requis ;
- la signature et la diffusion de la transaction ;
- le rapprochement du résultat blockchain avec les enregistrements internes.
Ces étapes peuvent être réparties entre des employés, des services et des environnements isolés. Un système en ligne peut recevoir une demande, un moteur de règles l’approuver et un signataire distinct n’autoriser que l’empreinte de transaction obtenue. Cette séparation peut limiter l’autorité d’un composant, mais elle n’est efficace que si les identifiants, canaux d’approbation et parcours de récupération sont également séparés.
Un prestataire peut tenir un registre interne des droits des clients tout en contrôlant une ou plusieurs adresses onchain. Un transfert interne entre clients peut mettre ce registre à jour sans transaction onchain immédiate. Le solde interne, le solde des adresses onchain et les droits contractuels du client sont des enregistrements distincts qui doivent être rapprochés ; aucun ne peut être entièrement déduit d’un autre.
Auto-conservation, conservation par un tiers et contrôle réparti
Auto-conservation
Dans l’auto-conservation, l’utilisateur contrôle les clés ou le dispositif d’autorisation du compte au lieu de confier ce pouvoir à un service. Cela réduit la dépendance envers un dépositaire pour l’approbation des transactions, mais les responsabilités de sauvegarde, récupération et vérification restent à la charge de l’utilisateur ou de la configuration choisie. La perte de toutes les données requises d’autorisation et de récupération peut rendre le compte inaccessible.
Conservation par un tiers
Dans la conservation par un tiers, un prestataire contrôle le processus de signature ou une autre autorité nécessaire pour agir sur un compte et traite les instructions du client. Celui-ci peut utiliser un identifiant de service sans recevoir les clés blockchain. L’accès et les retraits dépendent alors des contrôles, enregistrements, disponibilités et conditions contractuelles du prestataire.
Conservation partagée ou partielle
L’autorité peut être répartie entre le client, le prestataire et d’autres parties. L’étiquette « partagée » est incomplète sans les règles de seuil et de récupération. Une configuration 2 sur 3, par exemple, se comporte différemment selon les détenteurs de chaque signataire, la capacité d’une partie à en remplacer une autre et les approbations requises pendant la récupération.
Ces modèles décrivent le contrôle, pas le format du produit. Une interface mobile peut se connecter à chacun d’eux, et un signataire matériel peut être utilisé en auto-conservation ou comme composant d’un processus institutionnel.
Multisignature, signature à seuil et comptes intelligents
Plusieurs mécanismes permettent de répartir l’autorité :
- Multisignature onchain : exige plusieurs signatures ou approbations vérifiables indépendamment selon les règles du compte ou du script. La blockchain peut souvent observer la structure d’autorisation.
- Cryptographie à seuil : répartit la capacité de signature entre des fragments qui produisent conjointement une signature. Selon le schéma, la blockchain peut ne voir qu’une clé publique et une signature ordinaires plutôt que chaque fragment.
- Comptes de contrats intelligents : appliquent dans le code une logique d’autorisation et de récupération. Ils peuvent prendre en charge des gardiens, limites de dépense, clés de session ou autres politiques sans clé privée permanente unique.
Ces approches ont des propriétés d’échec et d’audit différentes. Un seuil indique combien de fragments sont mathématiquement nécessaires, pas s’ils sont détenus par des personnes, appareils ou organisations indépendants. Une politique multisignature peut conserver une voie de récupération faible. Un compte intelligent peut introduire des dépendances au contrat, à sa mise à niveau ou à sa gouvernance. Le nom du mécanisme ne suffit pas à établir une séparation des tâches.
Chaud et froid décrivent les voies d’accès, pas le détenteur de la conservation
Le stockage chaud ou froid décrit la facilité avec laquelle l’autorité de signature est reliée aux systèmes en ligne :
- Signature à chaud : maintient une voie d’autorisation accessible aux services en ligne, ce qui réduit les délais opérationnels mais augmente l’exposition aux compromissions logicielles, d’identifiants et de réseau.
- Signature à froid : maintient les clés ou appareils plus longtemps isolés, ce qui réduit certaines expositions en ligne tout en ajoutant des procédures d’accès physique, de transfert, de vérification et de récupération.
Une plateforme de conservation peut associer une voie chaude limitée pour le traitement courant à une voie plus isolée pour d’autres transactions. Le stockage à froid ne prouve pas que la réception des demandes, la vérification des adresses, les mises à jour logicielles, les sauvegardes ou la récupération sont sûres. Le stockage à chaud ne précise pas non plus qui contrôle juridiquement ou opérationnellement le compte.
Le NIST SP 800-57 traite la génération, le stockage, l’utilisation, la sauvegarde, la récupération, la révocation et la destruction comme des étapes distinctes du cycle de vie d’une clé. Le guide Bitcoin illustre un modèle où un système en ligne prépare les transactions et un portefeuille hors ligne les signe. NIST SP 800-57 Partie 1 et Guide du développeur Bitcoin : portefeuilles
Où un dispositif de conservation peut-il échouer ?
La conservation redistribue les risques, elle ne les supprime pas :
- Échec de génération ou de sauvegarde : un aléa insuffisant, des sauvegardes incomplètes ou la perte de fragments requis peuvent rendre l’autorité vulnérable ou indisponible.
- Compromission de l’autorisation : un attaquant ou initié disposant d’assez d’identifiants, fragments ou privilèges peut autoriser une transaction non voulue.
- Substitution de transaction : un processus d’approbation légitime peut signer le mauvais réseau, destinataire, montant ou appel de contrat si la vérification est incomplète.
- Contournement des règles et de la récupération : les procédures d’urgence, de remplacement ou de récupération peuvent devenir une voie plus faible que la signature ordinaire.
- Défaillance logicielle ou d’infrastructure : les erreurs de portefeuille, nœud, moteur de règles ou rapprochement peuvent retarder, dupliquer ou mal acheminer les opérations.
- Divergence des enregistrements : les droits internes peuvent diverger des actifs onchain contrôlés si dépôts, retraits, frais ou événements de chaîne sont mal comptabilisés.
- Dépendance au service : pannes, insolvabilité, blocages ou restrictions contractuelles peuvent affecter l’accès même si les clés blockchain existent toujours.
Aucun signal public unique ne prouve le bon fonctionnement de tout le système. Un pourcentage de stockage à froid ne décrit pas les contrôles de récupération. Une adresse multisignature ne montre pas l’indépendance des signataires. Un résultat de preuve de réserves, pris isolément, n’établit ni l’exhaustivité des engagements envers les clients, ni la ségrégation juridique des actifs, ni les droits de retrait de chacun. Ces questions exigent des enregistrements, un périmètre et des hypothèses supplémentaires.
Ce que la conservation ne détermine pas
La conservation ne se confond ni avec le logiciel de portefeuille, ni avec la propriété sur blockchain, ni avec la ségrégation des actifs :
- une application peut afficher un compte sans le contrôler ;
- un service peut contrôler la signature tout en regroupant les actifs dans des adresses utilisées pour plusieurs clients ;
- des adresses distinctes n’établissent pas, à elles seules, une ségrégation juridique des actifs ;
- le contrôle d’une clé ne tranche pas toutes les questions contractuelles ni celles relatives à la propriété effective.
C’est pourquoi l’architecture technique, la comptabilité interne et les conditions juridiques doivent être évaluées séparément.
FAQ
Un dépositaire stocke-t-il les crypto-actifs hors chaîne ?
L’état blockchain enregistre les actifs et les transactions onchain. Le dépositaire contrôle des clés ou d’autres mécanismes d’autorisation et peut tenir un registre interne distinct. Selon le dispositif, certains transferts entre clients peuvent être inscrits en interne avant ou sans transaction onchain immédiate.
Un portefeuille dépositaire est-il toute interface de portefeuille hébergée ?
Non. La question pertinente est de savoir qui contrôle l’autorité de signature ou les permissions du compte. Une interface hébergée peut afficher un compte sans détenir ses clés, tandis qu’un prestataire peut contrôler la signature au moyen de systèmes invisibles dans l’interface.
Le stockage à froid supprime-t-il le risque de conservation ?
Non. L’isolation peut réduire certaines voies d’attaque en ligne, mais la sécurité physique, la vérification des transactions, l’accès des employés, les sauvegardes, l’intégrité logicielle et les procédures de récupération restent importants.
Ressources associées
Consultez les portefeuilles crypto, les clés privées, les clés publiques, les phrases de récupération, les portefeuilles chauds et les portefeuilles froids, ou revenez au glossaire crypto.
Pour comparer plus largement les modes de fourniture et les catégories de stockage, consultez l’article OKX Learn Types of crypto wallets, disponible en anglais. Il s’agit d’une lecture complémentaire, pas d’une source faisant autorité pour la définition ci-dessus.
Sources
- NIST IR 8301 : Blockchain Networks — Token Design and Management Overview — portefeuilles, gestion des clés et modèles de conservation directe, par un tiers et partielle.
- NIST IR 8202 : Blockchain Technology Overview — clés privées, signatures numériques et enregistrements blockchain.
- NIST SP 800-57 Partie 1 Rév. 5 : Recommendation for Key Management — cycle de vie, protection, sauvegarde et récupération des clés.
- Guide du développeur Bitcoin : portefeuilles — séparation de la préparation en ligne, de la signature hors ligne et de la sauvegarde.



