L'évolution de la conservation crypto
Wallet-as-a-Service permet de gérer les clés cryptographiques en toute sécurité sans risque de perte physique, tout en préservant la pleine fonctionnalité des applications DeFi.
1. L'auto-conservation : De la promesse à la réalité opérationnelle
Les cryptomonnaies reposent sur une promesse centrale : l'auto-conservation (Self-Custody). Sans intermédiaire, sans banque, sans dépendance. Dans la pratique, ce modèle se heurte souvent à des obstacles opérationnels.
La perte d'une clé privée (Private Key) entraîne une perte irrémédiable des actifs. Il n'existe pas de service client ni d'options de récupération. Sécuriser la phrase de récupération (Seed Phrase) — la suite de mots permettant d'accéder au portefeuille — nécessite une protection contre la perte, les incendies, les vols et l'erreur humaine.
La solution pratique la plus fréquente : le stockage dans un coffre-fort bancaire. Ainsi, la promesse d'indépendance par rapport au système bancaire s'achève exactement là où elle a commencé.
2. Omni-Wallets : La conservation par les banques et les bourses
Les banques et bourses proposant des offres crypto résolvent le problème de la conservation grâce aux Omni-Wallets : un portefeuille commun pour les fonds de tous les clients, segmenté de manière comptable en interne.
Avantages :
- Des frais de transaction réduits (les transferts internes ne nécessitent pas de transaction sur la blockchain).
- Une diminution de la charge opérationnelle.
Risque structurel :
Les actifs appartiennent au client uniquement dans les registres du fournisseur, et non sur la blockchain. En cas d'insolvabilité, les fonds sont intégrés à la masse de la faillite.
L'étude de cas FTX (Novembre 2022) :
- Les actifs des clients n'étaient pas séparés sur la blockchain (On-Chain).
- Lors de la procédure de faillite, les crypto-actifs ont été considérés comme faisant partie intégrante de la masse.
- Les clients se sont retrouvés créanciers de dernier rang.
3. Wallet-as-a-Service : Fonctionnement
Le Wallet-as-a-Service (WaaS) allie le niveau de sécurité de la conservation institutionnelle à l'ergonomie des applications décentralisées. Il s'affranchit de la structure des Omni-Wallets sans imposer l'auto-conservation.
Le principe de base (Multi-Party Computation / MPC) :
La clé privée n'existe jamais en son entier au même endroit. Elle est fragmentée (Key-Shards), et ces fragments sont stockés sur des systèmes distincts : chez le fournisseur, chez l'utilisateur et parfois auprès de tiers de confiance indépendants.
Une transaction ne s'exécute qu'à condition d'avoir réuni suffisamment de fragments. Aucune partie ne peut accéder seule aux actifs. De plus, la clé n'est jamais intégralement reconstituée ; elle sert exclusivement au processus de signature.
L'interface reste identique à celle d'un portefeuille conventionnel pour l'utilisateur. Les protocoles DeFi, les contrats intelligents (Smart Contracts) et les transferts de jetons sont pleinement utilisables, la signature sur la blockchain (On-Chain) étant identique à celle d'un portefeuille auto-géré.
4. Les trois risques majeurs
4.1. Perte d'accès en cas de défaillance du fournisseur
Si le fournisseur WaaS cesse de fonctionner, l'accès aux actifs repose entièrement sur la procédure de récupération prévue au contrat. La question clé : L'utilisateur peut-il retrouver l'accès à ses actifs indépendamment de son fournisseur ?
Ce scénario n'est souvent pas documenté chez de nombreux fournisseurs, ce qui constitue le risque opérationnel le plus important.
4.2. Insolvabilité du fournisseur
Contrairement aux Omni-Wallets, une plateforme WaaS avec une architecture de portefeuille dédiée attribue directement les actifs à l'utilisateur sur la blockchain. Cela renforce considérablement la position juridique en cas d'insolvabilité.
Toutefois, cela n'offre pas une protection automatique. Le cadre juridique et contractuel prévaut sur la seule technologie.
4.3. Accès abusif par le fournisseur
Le recours à l'architecture MPC ne garantit pas automatiquement que le fournisseur n'a pas d'accès. Si ce dernier contrôle un nombre suffisant de ses fragments de clés (Key-Shards), il pourrait théoriquement signer des transactions sans l'approbation de l'utilisateur.
L'enjeu véritable : Combien de fragments sont détenus par le fournisseur et combien sont sous le contrôle de l'utilisateur ou d'un tiers indépendant ?
5. Tour d'horizon du marché
Le tableau comparatif suivant évalue les fournisseurs selon leur cible, leur flexibilité opérationnelle, l'utilisation de la DeFi et leur comportement en cas d'attaque.
| Critère | Fireblocks | Tangany | Dfns / Web3Auth | Privy |
|---|---|---|---|---|
| Public cible | Gestionnaires d'actifs, banques | Acteurs réglementés de l'UE | Développeurs, Fintechs | Consommateurs, utilisateurs dApp |
| Utilisation DeFi | Oui, via la Policy Engine | Limitée (focus conservation) | Oui, complétement intégrable | Oui, pour des interactions basiques |
| Structure du Wallet | Dédiée par utilisateur | Dédiée par utilisateur | Configurable | Spécifique par utilisateur |
| Contrôle des clés | MPC, fragments répartis | Le fournisseur conserve les clés | MPC, répartition configurable | Connexion sociale, clés chez le fournisseur |
| Protection ingénierie sociale | Policy Engine, liste blanche, délais | Processus réglementés, vérification manuelle | Dépend de l'implémentation | Faible (connexion sociale = vecteur d'attaque) |
| Comportement lors d'un piratage | Fragments isolés, aucun point d'accès central | Cadre réglementé, responsabilité engagée | Dépend de la configuration | Risque plus élevé via l'authentification centralisée |
Acteurs institutionnels
Fireblocks s'impose en leader pour les gestionnaires d'actifs, banques et bourses. Son architecture MPC, son moteur de règles de transaction (Policy Engine) et sa certification SOC 2 Type II s'accompagnent de forts volumes minimaux requis.
Les protocoles DeFi sont exploitables par le prisme de la Policy Engine. Les validations nécessitent des listes blanches (destinataires pré-approuvés), l'application de plafonds et des procédures d'autorisation à plusieurs niveaux. Dans le cadre d'une attaque d'ingénierie sociale, la combinaison du Policy Engine et de la répartition des Key-Shards permet d'éviter les transactions frauduleuses.
SOC 2 Type II est une norme de certification de l'American Institute of Certified Public Accountants (AICPA). Elle garantit le maintien de stricts contrôles de la sécurité, de la disponibilité et de la confidentialité des données pendant au moins six mois de fonctionnement continu. À l'inverse de la norme Type I qui vérifie l'existence des contrôles à un instant T, la norme Type II jauge leur efficacité réelle en pleine exploitation.
Conservation réglementée et services WaaS
Ciblant les acteurs européens contraints à la réglementation MiCA, Tangany détient une licence de dépositaire de crypto-actifs (Custodian) en qualité de prestataire de services financiers réglementés.
L'utilisation de la DeFi s'avère restreinte. L'orientation stratégique privilégie la conservation sécurisée et le transfert réglementé au détriment de l'interaction avec les contrats intelligents. Face à une tentative d'ingénierie sociale, ce sont de stricts processus avec une validation manuelle des transactions complexes qui sont appliqués. En cas de piratage, le dépositaire en assume la responsabilité.
Fintech et développeurs
Dfns et Web3Auth accompagnent les entreprises souhaitant doter leurs propres infrastructures d'un module WaaS, se distinguant par une vocation technologique plutôt qu'une conservation exclusive.
La compatibilité DeFi est totale, mais le réel niveau de sûreté reste l'apanage de l'implémentation client. La protection contre l'ingénierie sociale ou la résilience face au piratage échoient donc à l'entreprise intégratrice. En l'absence d'une Policy Engine et de mécanismes rigides, le risque s'intensifie logiquement.
Le segment Consommateur
Si Privy cible la vulgarisation des applications décentralisées (dApps) en dépit d'un bagage technique, il ne s'inscrit nullement dans la dimension institutionnelle. Il reste néanmoins intéressant d'en analyser sa portée globale.
Il facilite les utilisations simples de la DeFi via la connexion sociale (E-mail, Google, Apple). Malgré son accessibilité évidente, ce mode opératoire offre de fait un boulevard aux vecteurs d'attaque de type ingénierie sociale : il suffira de nuire au compte générique de connexion pour exécuter en catimini d'importantes transactions monétaires. In fine, le véritable contrôle reste ancré au niveau exclusif du fournisseur.
6. Liste de contrôle "Due Diligence" pour le secteur financier
Il est primordial d'examiner attentivement cinq points clés avant toute convention avec un fournisseur WaaS :
- La structure du portefeuille : Un portefeuille strictement dédié à l'utilisateur, ou une structure en Omni-Wallet ? Est-elle vérifiable directement sur la blockchain ?
- La souveraineté des clés : Selon quelle répartition le fournisseur assure-t-il la conservation exclusive des fragments de clés face à l'utilisateur ? Peut-il exécuter en toute indépendance de telles signatures de transactions ?
- Le processus de recouvrement : Quelle est l'alternative de recours en cas de liquidation judiciaire, ou au pire d'arrêt fonctionnel continu ? Comment ces process de relève sont-ils concrètement définis au cœur des réglementations et de l'aspect technologique ?
- Le cadre réglementaire : Quelle accréditation protège formellement l'utilisateur vis-à-vis d'un dépositaire officiellement agrée versus un exploitant de solutions technologiques ? Un distinguo indispensable quant à la question de responsabilité exécutive.
- Indépendance de l'audit interne : L'exigence inéluctable quant au maintien de certifications pointues (SOC 2 Type II a minima). Ces rapports analytiques d'intrusion (Pen-test) font-il appels à de parfaits sous-traitants d'audit externe et indépendant de toute relation ?
7. Conclusion
Si l'auto-conservation ou la dimension des prestataires en Omni-Wallets divergent ouvertement selon ces deux courants structurels, les prestataires en "Wallet-as-a-Service" rééquilibrent judicieusement la donne sans nécessairement concéder de lourdes contraintes face aux différents avantages conjoints.
Aucune des entités professionnelles en jeu ne s'exempt complétement des facteurs inhérents aux risques de la relation de contrepartie. Le sérieux structurel, associé à l'assurance de détenir une wallet privative couverte par de récents standards technologiques d'isolement fragmentaire des éléments de chiffrement, sans occulter formellement un véritable protocole de recours pour sécuriser ces avoirs en cas de faillite exécutive ; reste foncièrement aux acteurs et entités de références le modèle de transition fonctionnelle optimal à l'usage ciblé.
Plus rationnel indéniablement qu'un lourd dispositif logistique autour de la classique archive "Seed phrase", l'intégrité globale du modèle WaaS permet donc d'anticiper la structure des avoirs loin du simple préambule comptable des Omni-Wallets.
Il en résulte que ces approches demeurent logiquement assujetties aux détails formalisés de son contrat d'agréement bien plus qu'à son format purement technologique et de ses promesses sécuritaires.
