Les passkeys et la récupération sociale sont souvent évoquées ensemble à propos des portefeuilles, alors qu’elles traitent de parties différentes du contrôle d’un compte. Une passkey peut contribuer à prouver l’accès, tandis que la récupération sociale peut définir qui est habilité à autoriser une modification de cet accès après un événement de perte. Leurs conséquences dépendent de la logique de validation du compte, des parties susceptibles d’influencer la récupération et des services dont dépend chaque conception.
L’accès, la récupération et l’autorité sont des questions différentes
La conception d’un portefeuille soulève au moins deux questions liées : quelles preuves sont acceptées pour l’accès ordinaire, et quelle autorité peut modifier ces preuves lorsque cet accès n’est plus disponible. Ces questions peuvent être mises en œuvre ensemble, mais elles ne sont pas identiques. Un compte peut accepter un justificatif particulier pour la validation au quotidien tout en utilisant une politique distincte pour remplacer, ajouter ou révoquer ce justificatif après un événement de récupération.
L’expression *passkey crypto wallet explained* n’est utile que si elle sépare ces couches. Dans les termes de WebAuthn, une passkey est un justificatif à clé publique utilisé lors d’une cérémonie d’authentification avec une partie de confiance (*relying party*). Dans le contexte d’un portefeuille, cette partie de confiance et la logique du compte déterminent ce qui se passe après la cérémonie. Une preuve validée peut constituer une entrée pour la validation d’un compte sans être, à elle seule, une règle universelle permettant de modifier le contrôle d’un compte on-chain.
La récupération sociale part d’une autre question : si l’accès normal n’est pas disponible, les preuves de qui ont autorité pour initier ou approuver une modification ? La réponse s’exprime sous la forme d’une politique de récupération plutôt que d’un unique justificatif détenu par l’utilisateur. C’est pourquoi la comparaison fonctionne mieux comme une cartographie des autorités et des chemins de défaillance, et non comme une concurrence entre deux étiquettes.
Ce qu’une passkey prouve réellement
WebAuthn définit une paire de clés de justificatif limitée à une partie de confiance donnée. L’authenticator conserve la clé privée du justificatif et produit une assertion cryptographique après la cérémonie requise ; la partie de confiance vérifie cette assertion avec la clé publique enregistrée. Le protocole décrit donc une relation entre un authenticator, un environnement client et une partie de confiance nommée, plutôt qu’une affirmation transportable selon laquelle une personne contrôle tous les comptes associés à une adresse.
La vérification de l’utilisateur est locale au processus de l’authenticator. Un contrôle biométrique ou le déverrouillage d’un appareil peut autoriser l’emploi d’un justificatif sans transmettre les données biométriques à la partie de confiance. C’est pertinent pour le chemin d’accès, mais cela ne tranche pas le chemin de récupération. Un portefeuille ne peut traiter l’assertion obtenue comme une preuve pour une action précise du compte que si son logiciel et ses règles de validation sont conçus pour la reconnaître.
Les passkeys distinguent aussi les arrangements de justificatifs liés à un appareil et les arrangements synchronisés. Un justificatif lié à un appareil reste attaché à l’authenticator qui l’a créé, alors qu’un arrangement synchronisé introduit un chemin de synchronisation et de récupération de compte géré par un fournisseur entre les appareils de son écosystème. Aucune de ces descriptions ne répond à toutes les questions relatives à un portefeuille. Elles identifient plutôt les systèmes et justificatifs pertinents lorsqu’un appareil est indisponible ou que l’accès à un compte de synchronisation change.
Ce que modifie la récupération sociale fondée sur des guardians
L’explication de la récupération d’un portefeuille par guardians commence avec une autorité de récupération déléguée. Une politique de guardians peut désigner des identités dont les approbations valides sont prises en compte par une règle, par exemple un seuil ou une politique comportant plusieurs catégories d’autorité. Les guardians ne doivent pas être décrits uniquement comme des personnes : une interface technique peut modéliser des comptes on-chain, d’autres identités vérifiables ou des mécanismes de vérification désignés. L’élément important est que l’autorité de récupération est répartie entre les participants et les vérificateurs de la politique.
Cette répartition déplace la question de « où se trouve le justificatif ? » vers « quelle combinaison de preuves modifie l’état de contrôle du compte ? ». Une politique de récupération peut séparer l’autorité d’initier une récupération, de l’approuver, de l’annuler ou de finaliser le remplacement du contrôleur ordinaire. L’existence de ces rôles et leurs interactions relèvent de l’implémentation, mais leur distinction compte car ils créent des chemins différents pour une récupération légitime et pour une modification de contrôle non autorisée.
Les guardians n’éliminent pas la confiance ; ils la déplacent et la structurent. La politique peut dépendre de la disponibilité, de l’indépendance, de la vérification d’identité et de la volonté de ses guardians. Elle peut également dépendre d’un module de contrat ou d’un vérificateur qui interprète correctement leurs preuves. Le résultat n’est pas une garantie générale contre la perte ou la compromission, mais une répartition explicite de l’autorité de récupération au niveau du compte.
Les comptes intelligents transforment la politique en logique de compte
Les comptes externes traditionnels reposent sur la validation, définie par le protocole, d’une signature à clé privée. Les comptes intelligents peuvent à la place employer du code de contrat pour définir la logique de validation. ERC-4337 décrit un modèle dans lequel un compte de contrat intelligent valide une `UserOperation`, tandis que le chemin d’exécution environnant comprend un `EntryPoint` et des *bundlers*. Cette programmabilité peut accueillir différents schémas de signature et politiques de récupération, mais elle implique aussi que le code concret du compte définit les règles pertinentes.
Un portefeuille orienté passkey peut donc être compris comme une conception où une preuve de type WebAuthn est reliée à la validation du compte par du logiciel supplémentaire et de la logique de contrat. Un portefeuille orienté guardians peut être compris comme une conception où les preuves de récupération sont vérifiées par rapport à une politique de compte. Ces descriptions peuvent coexister dans un même compte intelligent : une passkey peut faire partie de l’accès normal, tandis que les guardians régissent les changements exceptionnels d’autorité d’accès.
Cette même souplesse rend les limites d’implémentation importantes. Les mises à niveau de contrat, modules de validation, vérificateurs off-chain et interfaces applicatives peuvent chacun affecter la manière dont un compte interprète une demande d’accès ou de récupération. Décrire une fonction uniquement par son libellé d’interface laisse de côté les composants qui déterminent réellement ses limites d’autorité.
La perte d’un appareil est un scénario, pas une défaillance unique
Lorsqu’un appareil est perdu, la question immédiate pour un arrangement de passkey est de savoir si un autre justificatif accepté, ou un chemin de synchronisation des justificatifs et de récupération de compte, demeure disponible. WebAuthn ne définit pas lui-même de protocole permettant de sauvegarder ou partager des clés privées de justificatifs entre authenticators. Les documents FIDO distinguent les justificatifs liés à un appareil des passkeys synchronisées précisément parce que la perte et la restauration sont traitées par des mécanismes et des dépendances différents.
Pour une conception de récupération sociale, le même événement soulève une autre question : l’autorité de récupération définie peut-elle modifier le contrôleur ordinaire du compte, et le compte peut-il appliquer la politique qui régit cette modification ? La perte d’un appareil n’implique pas automatiquement une action de récupération sociale, et la présence de guardians ne rend pas une passkey indisponible. Les deux modèles peuvent se croiser, mais leurs conditions de déclenchement et leurs sources de preuve restent conceptuellement distinctes.
L’expression *crypto account recovery without seed phrase* décrit un objectif possible côté utilisateur, et non une méthode technique uniforme. Une conception peut dépendre de la récupération de compte d’un fournisseur de justificatifs ; une autre peut dépendre de preuves de guardians validées par un compte intelligent ; une autre encore peut combiner les deux avec une logique de politique supplémentaire. Ce qui est absent de l’interface utilisateur ne supprime pas la nécessité d’identifier où résident réellement l’autorité de récupération, la vérification des preuves et la modification d’état.
La collusion et la dépendance aux services créent des limites différentes
La collusion concerne la politique de récupération, car plusieurs guardians peuvent combiner leur autorité lorsqu’une règle compte leurs approbations. Un seuil peut empêcher un guardian unique d’agir seul, mais il ne rend pas impossible une action coordonnée des guardians. Le modèle de menace pertinent examine qui peut satisfaire la politique ensemble, si ces identités sont réellement indépendantes et si un autre rôle peut modifier la politique ou ses conditions de vérification.
La dépendance aux services apparaît dans les deux conceptions, mais à des endroits différents. L’utilisation d’une passkey dépend de l’origine et du flux d’authentification d’une partie de confiance, d’un environnement client et d’un authenticator ; les passkeys synchronisées impliquent en outre l’écosystème de synchronisation et de récupération de compte d’un fournisseur. La récupération sociale peut dépendre de guardians, de vérificateurs d’identité ou de preuves, d’interfaces applicatives, de modules de contrat et de la disponibilité du chemin réseau transportant des actions de récupération valides. La dépendance est une propriété architecturale, pas un verdict sur une conception.
Ces limites peuvent aussi évoluer dans le temps. Si un compte autorise des mises à niveau ou des changements de politique, l’autorité capable de les mettre en œuvre devient partie intégrante de son modèle de récupération et d’accès. Une explication précise distingue donc le contrôle du justificatif, le contrôle de la politique de récupération et le contrôle du code qui interprète les deux.
Une grille de modèle de menace, plutôt qu’un classement de sécurité
Les passkeys et la récupération par guardians peuvent être comparées en demandant quel événement est examiné. Le vol d’un justificatif, la perte d’un appareil, la perte d’un compte de synchronisation, l’indisponibilité ou la collusion de guardians, la compromission d’une application, la défaillance d’un vérificateur et les défauts de logique du compte mettent chacun à l’épreuve des parties différentes du système. Une réponse qui les traite comme un seul problème risque de négliger quelle autorité est opérante dans le scénario considéré.
Cette grille explique également pourquoi un classement universel de sécurité serait trompeur. Un arrangement de passkey peut concentrer l’accès ordinaire autour d’hypothèses concernant l’authenticator et la partie de confiance, tandis qu’un arrangement de récupération sociale peut répartir l’autorité exceptionnelle entre une politique et ses participants. Une conception combinée de compte intelligent peut ajouter simultanément davantage de chemins et de contrôles. La comparaison qui a du sens est l’ensemble des hypothèses, non l’affirmation qu’une étiquette surmonte chaque menace.
En bref, les passkeys concernent la manière dont un compte peut accepter une preuve cryptographique d’accès, et la récupération sociale concerne la manière dont un compte peut autoriser le remplacement ou la modification de cet accès après présentation des preuves prévues. Les considérer comme des couches distinctes mais connectables facilite l’analyse de la perte d’appareil, de la collusion et de la dépendance aux services sans prétendre qu’une conception de portefeuille serait objectivement la plus sûre.
Articles associés
Autres articles Bitbase sur ce sujet :
- Sui Wallet, l'ancien nom de Slush
- Portefeuille chaud ou portefeuille froid : quelle différence ?
- Qu'est-ce qu'un portefeuille en lecture seule ? Voir sans dépenser
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] W3C: Web Authentication Level 3 w3.org
[2] FIDO Alliance: Authentication for Moderate Assurance Use Cases fidoalliance.org
[3] ERC-4337: Account Abstraction Using Alt Mempool eips.ethereum.org
[4] ERC-7093: Social Recovery Interface eips.ethereum.org
