Qu’est-ce qu’un portefeuille crypto ?

Un portefeuille crypto est un système qui aide une personne ou un service à interagir avec des comptes et des actifs blockchain. Selon sa conception, il peut découvrir des adresses, afficher des données blockchain, construire des transactions, demander ou créer des signatures et diffuser les données signées vers un réseau.

Les crypto-actifs ne sont pas des fichiers de monnaie stockés dans le portefeuille. Les soldes, les sorties dépensables et l’état des comptes sont enregistrés selon les règles d’une blockchain. Le portefeuille stocke ou consulte les informations et les autorisations nécessaires pour lire cet état ou demander sa modification. Le contrôle de cette autorisation ne tranche pas, à lui seul, toutes les questions juridiques ou contractuelles de propriété.

Les fonctions cachées derrière un même écran de portefeuille

Une seule interface peut réunir plusieurs composants :

1. L’accès au réseau ou aux données obtient les blocs, l’état du compte, l’historique des transactions, les métadonnées des tokens ou les informations sur les frais auprès d’un nœud ou d’un service d’indexation.
2. La découverte des comptes dérive ou importe des adresses et détermine les comptes que l’interface doit surveiller.
3. La construction de transaction transforme l’action demandée en données exactes exigées par le réseau, notamment la destination, le montant, le nonce, les frais et, le cas échéant, les instructions de contrat.
4. L’autorisation crée ou recueille les signatures, approbations ou preuves propres au compte qu’exige le réseau.
5. La diffusion et le suivi du statut soumettent la transaction signée et suivent son inclusion ou son échec.

Ces fonctions ne doivent pas nécessairement s’exécuter dans la même application ou sur le même appareil. Un logiciel peut construire une transaction tandis qu’un appareil matériel la signe. Un portefeuille en lecture seule peut afficher une adresse sans disposer d’aucune autorité de signature. Un service de conservation peut proposer une interface de portefeuille tout en gardant le processus de signature dans des systèmes invisibles pour l’utilisateur. La documentation Bitcoin décrit des configurations distinctes assurant l’ensemble des fonctions, la seule signature ou la seule distribution. Guide du développeur Bitcoin : portefeuilles

Comme la couche de données est distincte de celle d’autorisation, un fournisseur de données incorrect ou indisponible peut produire un affichage incomplet alors que l’enregistrement blockchain reste inchangé. À l’inverse, l’affichage d’une adresse et d’un solde ne prouve pas que l’interface peut autoriser une transaction.

Clés, phrases de récupération et comptes sont liés, mais distincts

Dans un compte conventionnel contrôlé par clé, une clé privée crée une signature et la clé publique correspondante en permet la vérification. Un portefeuille hiérarchique déterministe peut utiliser des données racines pour dériver de nombreuses paires de clés plutôt que de stocker une clé indépendante pour chaque adresse. BIP-32 définit les clés étendues et les arbres de dérivation ; BIP-39 spécifie un processus, couramment utilisé, de conversion d’une phrase mnémonique en graine. Aucune de ces normes n’impose cette architecture à tous les comptes ou portefeuilles blockchain. BIP-32 et BIP-39

Ethereum montre pourquoi réduire un portefeuille à une clé privée est trop étroit. Les comptes détenus en propre sont contrôlés par des paires de clés, tandis que les comptes de contrat sont contrôlés par du code et ne possèdent pas leur propre clé privée. Les comptes intelligents peuvent appliquer plusieurs signataires, des politiques de dépense ou des règles de récupération. L’interface reste appelée portefeuille même lorsque l’autorisation ne se réduit pas à une seule clé stockée localement. Comptes Ethereum et ERC-4337

Lorsqu’elle est utilisée, une phrase de récupération peut reconstruire les données racines déterministes. Un mot de passe ou un code PIN de portefeuille contrôle généralement l’accès local ou déchiffre le stockage local. Réinitialiser l’identifiant d’un service, saisir un PIN et restaurer une phrase de récupération sont donc des opérations différentes aux conséquences différentes.

Conservation, connectivité et format du produit : trois axes différents

Les catégories de portefeuilles mélangent souvent trois questions distinctes :

• Qui contrôle l’autorisation ? Dans une conservation par un tiers, le prestataire contrôle le processus de signature ou les permissions du compte. En auto-conservation, l’utilisateur contrôle les clés ou le dispositif d’autorisation.
• Dans quelle mesure le signataire est-il connecté ? Un système de signature à chaud est aisément accessible à un logiciel en ligne. Un processus à froid maintient les données ou appareils de signature plus longtemps isolés des systèmes en ligne.
• Sous quelle forme l’interface est-elle fournie ? Mobile, navigateur, ordinateur et matériel décrivent le format du produit. Ils n’établissent pas à eux seuls qui contrôle finalement le compte.

Un portefeuille mobile peut être avec ou sans conservation par un tiers. Un portefeuille matériel peut protéger une clé en auto-conservation, mais un appareil matériel peut aussi être un composant d’un système de conservation géré. « Matériel », « à froid » et « non dépositaire » ne sont donc pas synonymes.

Ce que signe un portefeuille

Un portefeuille ne signe pas simplement la phrase affichée à l’écran. Il signe des données encodées propres au réseau. Celles-ci peuvent représenter un transfert, un appel de contrat, un message typé, une approbation ou une opération de compte. Avant la signature, le logiciel peut simuler le résultat ou décoder certains champs, mais la qualité et l’exhaustivité de cette présentation varient.

Une signature valide prouve que la condition d’autorisation applicable a été satisfaite pour les données signées ; elle ne prouve ni que l’action était avantageuse, ni que la destination était voulue, ni que l’interface en a expliqué toutes les conséquences. Un logiciel malveillant peut substituer une adresse, un contrat peut se comporter de façon inattendue et une approbation étendue de token peut autoriser des actions ultérieures. Garder une clé secrète et comprendre l’autorisation demandée sont deux contrôles distincts.

Pour les applications Ethereum, EIP-1193 normalise une interface par laquelle un fournisseur peut exposer des méthodes RPC et des événements. Le fournisseur peut relier une application à un compte, mais la norme n’exige pas que l’application détienne elle-même la clé privée. EIP-1193

La récupération dépend de l’architecture du portefeuille

Il n’existe aucune méthode universelle de récupération :

• un service de conservation peut proposer une procédure de récupération de compte selon ses conditions ;
• un portefeuille HD peut dépendre d’une phrase de récupération, d’une phrase secrète et de paramètres de dérivation compatibles ;
• un portefeuille à clé indépendante nécessite une sauvegarde de la clé concernée ;
• un compte multisignature ou intelligent peut utiliser les signataires restants, des gardiens ou une récupération définie par contrat ;
• une clé protégée par un appareil peut être non exportable et dépendre d’un dispositif de récupération distinct.

La restauration des clés ne restaure pas forcément les étiquettes, contacts, comptes importés, configurations multisignatures ou autres métadonnées d’application. De même, changer de logiciel ne déplace pas les actifs blockchain : un logiciel compatible peut parfois accéder au même compte, tandis que des chemins de dérivation ou paramètres réseau incompatibles peuvent d’abord afficher d’autres adresses.

Échecs d’affichage et de transaction

Des défaillances courantes peuvent survenir à différentes couches :

• un portefeuille connecté au mauvais réseau peut afficher un autre état de compte ou construire une transaction inutilisable ;
• une panne RPC ou d’indexeur peut masquer une activité récente sans la supprimer de la blockchain ;
• des métadonnées de token non prises en charge peuvent empêcher l’affichage automatique d’un actif ;
• une destination ou instruction de contrat erronée peut tout de même être signée avec succès ;
• des frais insuffisants, des conflits de nonce ou l’annulation d’un contrat peuvent empêcher la modification d’état recherchée ;
• la perte des données d’autorisation peut rendre un compte inaccessible alors que son solde reste publiquement visible.

Le diagnostic approprié dépend donc de la couche concernée : affichage des données, construction de la transaction, signature, acceptation par le réseau ou récupération.

FAQ

Un seul portefeuille peut-il prendre en charge toutes les blockchains ?

Pas nécessairement. Les réseaux emploient des formats d’adresse, encodages de transaction, schémas de signature et interfaces d’application différents. La compatibilité doit être vérifiée pour le portefeuille, le réseau et l’actif concernés.

Importer une adresse permet-il d’en prendre le contrôle ?

Non. Une adresse seule permet éventuellement la surveillance. Le contrôle exige la clé privée ou un autre mécanisme d’autorisation accepté par les règles du compte.

Le fournisseur d’un portefeuille en est-il toujours le dépositaire ?

Non. Une entreprise peut publier un logiciel de portefeuille sans contrôler les clés des utilisateurs, tandis qu’un autre service peut contrôler la signature derrière une interface hébergée. La question concrète est de savoir qui peut autoriser les transactions et récupérer ou modifier cette autorité.

Ressources associées

Découvrez les clés privées, les clés publiques, les phrases de récupération, les portefeuilles non dépositaires et la conservation de crypto-actifs, ou revenez au glossaire crypto.

Pour une présentation plus générale destinée aux débutants, consultez l’article OKX Learn What is a crypto wallet?, disponible en anglais. Il s’agit d’une lecture complémentaire, pas d’une source technique principale pour ce terme.

Sources

• Guide du développeur Bitcoin : portefeuilles — fonctions, dérivation déterministe et séparation des fonctions réseau et de signature.
• Ethereum : portefeuilles — interfaces, accès aux comptes et formats courants.
• Ethereum : comptes — contrôle des comptes détenus en propre et des comptes de contrat.
• BIP-32 — arbres hiérarchiques déterministes et clés étendues.
• BIP-39 — méthode de conversion mnémonique-graine employée par les portefeuilles compatibles.
• EIP-1193 — interface de fournisseur Ethereum entre applications et fonctions de portefeuille.
• ERC-4337 — opérations de comptes intelligents, validation et autorisation extensible.