Je suis exactement le client pour qui on a inventé la connexion avec Google. Donnez-moi une phrase de récupération sur un bout de papier, et j’aurai tout perdu en moins d’un mois. Pas besoin de pirate.
Je comprends donc pourquoi un portefeuille crypto permet de s’inscrire avec son compte Google ou Apple. Mais en novembre 2026, ce confort a produit l’une des histoires les plus étranges que j’aie lues sur ce marché : un vol, puis un sauvetage mené par la porte même du voleur, puis un sauvetage qu’internet a d’abord présenté comme un second vol. Les fonds sont peut-être à l’abri. Les questions juridiques, elles, ne le sont pas.
Ce qui est arrivé aux portefeuilles Keplr
Keplr, un portefeuille très utilisé dans l’écosystème Cosmos, permet de créer un portefeuille avec une connexion Google ou Apple. Derrière cette connexion se trouve Web3Auth, un prestataire d’infrastructure de portefeuilles qui appartient à Consensys depuis juin 2025 et qui est aujourd’hui commercialisé sous le nom de MetaMask Embedded Wallets. L’utilisateur ne voit jamais de phrase de récupération, mais il y a toujours une clé privée derrière le portefeuille. La connexion remplace la paperasse. Elle ne remplace pas la clé.
Selon Keplr et Web3Auth, une faille dans l’infrastructure de Web3Auth a exposé les clés privées de certains de ces portefeuilles à connexion sociale. Les portefeuilles créés avec une phrase de récupération ou un portefeuille matériel (hardware wallet) n’étaient pas concernés. Google et Apple n’ont pas été piratés : la défaillance se situait chez le prestataire placé derrière la connexion. Le cofondateur de Keplr a estimé qu’environ 20 % de ses comptes à connexion sociale étaient exposés.
L’histoire se déroule ensuite en trois actes.
Premier acte : le vol. Selon la société d’analyse on-chain Bitquery, le premier vol a eu lieu le 1er novembre. Au 12 novembre, elle attribuait à l’attaquant au moins 1,82 million de dollars, pris dans 7 842 portefeuilles Cosmos, 52 portefeuilles Ethereum et 13 comptes Hyperliquid, et elle qualifiait ce chiffre de minimum, l’attaquant étant toujours actif.
Deuxième acte : le sauvetage. Le 6 novembre, Web3Auth a suspendu son service de portefeuilles. Il a ensuite commencé à vider les portefeuilles exposés que l’attaquant n’avait pas encore atteints, en empruntant, selon ses propres termes, le même chemin que l’attaquant initial. Bitquery a compté au moins 44 041 portefeuilles sur sept chaînes Cosmos, plus plusieurs milliers sur Injective, dont les fonds ont été transférés vers les adresses de récupération de Web3Auth : environ 6 millions de dollars au total. Le 8 novembre, Web3Auth a publié douze adresses de récupération, sur lesquelles la presse a trouvé environ 5,6 millions de dollars.
Troisième acte : la confusion. Avant la publication de cette liste, le sauvetage ressemblait exactement à un vol. Les huit adresses que Bitquery avait d’abord attribuées au voleur figuraient toutes sur la liste de récupération de Web3Auth. Pour l’utilisateur non plus, aucune différence : il ouvrait son portefeuille et son solde avait disparu. Keplr a dû expliquer à ses utilisateurs qu’un portefeuille vide pouvait signifier que leur argent avait été sauvé, et non volé.
Et l’affaire n’est pas terminée. Le 13 novembre, MANTRA, l’un des réseaux de l’écosystème Cosmos, a suspendu pendant sept jours les nouvelles demandes de déblocage des jetons placés en staking, après que des attaquants ont utilisé les clés exposées pour débloquer les jetons des victimes. Web3Auth a indiqué que son enquête se poursuivait et qu’un rapport complet suivrait. À ce jour, je n’ai trouvé aucune annonce selon laquelle chaque jeton sauvé aurait été rendu à son propriétaire.
Trois chiffres faciles à confondre
Les premiers chiffres provenaient du suivi on-chain du 7 novembre, avant que Web3Auth ne publie ses adresses de récupération : plus de 6 millions de dollars sortis de plus de 44 000 portefeuilles, que les premiers articles ont lus comme un vol. Bitquery a corrigé sa propre analyse dès la publication de la liste. La confusion était compréhensible : vus de l’extérieur, un sauvetage et un vol se ressemblent exactement. Mais il y a ici trois chiffres différents : les portefeuilles sauvés, les portefeuilles volés et l’argent perdu. Les 44 041 portefeuilles et les 6 millions de dollars correspondent pour l’essentiel au sauvetage. Le vol porte sur au moins 1,82 million de dollars, pris dans moins de 8 000 portefeuilles.
Il y a là une leçon qui dépasse largement Keplr. Une blockchain montre que des actifs ont bougé. Elle ne dit pas qui avait le droit de les déplacer, pourquoi, ni ce que la personne qui les détient maintenant vous doit. La transparence des mouvements n’est pas la transparence des droits.
Quel droit s’applique ?
Avant qu’un juriste ne s’enflamme, une précaution. Les conditions d’utilisation publiées par Keplr désignent le droit panaméen et un arbitrage au Panama. Celles de Consensys désignent le droit du Texas, le droit anglais ou le droit irlandais selon le lieu de résidence de l’utilisateur. Le droit suisse n’est pas le droit de cette affaire.
Mais beaucoup de mes clients créent des portefeuilles, des services de conservation et des activités crypto en Suisse. La question utile pour eux est donc celle-ci : si le même sauvetage avait lieu sous le droit suisse, comment l’analyserions-nous ?
Y avait-il un mandat ?
La première question est contractuelle : les utilisateurs avaient-ils déjà autorisé ce type d’intervention ?
Les conditions de Keplr lui permettent de restreindre ou de suspendre l’accès, notamment pour des raisons de sécurité. Celles de Consensys permettent de suspendre immédiatement le service en cas de risque de sécurité. Mais suspendre un service est une chose. Signer des transactions et transférer les actifs des clients vers ses propres adresses en est une autre. Les conditions de Keplr présentent même le portefeuille comme non-custodial et affirment que Keplr n’a aucune capacité de récupérer ou de transférer son contenu. Dans les conditions publiques que j’ai examinées, je n’ai trouvé aucune clause autorisant expressément un prestataire à utiliser un accès compromis pour transférer les actifs des utilisateurs vers des portefeuilles qu’il contrôle.
Cela ne prouve pas qu’il n’existait aucun fondement juridique. Nous n’avons ni l’accord privé entre Keplr et Web3Auth, ni chaque version des conditions acceptée par chaque utilisateur. En droit suisse, un contrat existant pourrait imposer un devoir de protéger le client et, si la relation relevait du mandat, l’article 397 du Code des obligations permet au mandataire de s’écarter des instructions lorsqu’il ne peut pas demander l’autorisation à temps et que le mandant aurait vraisemblablement consenti.
La gestion d’affaires sans mandat
À défaut d’autorisation suffisante, le droit suisse dispose d’un outil précis pour cette situation : la gestion d’affaires sans mandat des articles 419 et suivants du Code des obligations.
La règle est simple à énoncer. Celui qui intervient doit agir dans l’intérêt du maître de l’affaire et conformément à ses intentions présumables (article 419). Il répond de sa négligence, mais sa responsabilité est appréciée moins sévèrement s’il a agi pour prévenir un dommage imminent (article 420). Si l’intervention était justifiée, il peut se faire rembourser les dépenses nécessaires et utiles qu’il a engagées (article 422). C’est un droit au remboursement de frais, pas un droit à une prime de sauvetage. Et si le maître ratifie ensuite l’intervention, les règles du mandat s’appliquent (article 424), ce qui n’équivaut pas à une renonciation à toute prétention.
Sur les faits publiés, les arguments en faveur de l’intervention sont solides. Si un voleur peut vider un portefeuille à tout instant, et que demander l’accord de 44 000 utilisateurs un par un lui laisserait le temps de finir, mettre les fonds à l’abri correspond probablement à ce qu’un propriétaire raisonnable aurait voulu. Mais une bonne intention ne répond pas à toutes les questions. Quels portefeuilles étaient réellement exposés ? Pourquoi la destination était-elle plus sûre ? Quelque chose a-t-il été converti ou mis en risque au passage ? Comment la part de chaque propriétaire a-t-elle été enregistrée ? Et quel était le plan pour lui rendre le contrôle ?
Le sauvetage n’efface pas la faille
Il y a ici deux dossiers distincts. Un prestataire peut prendre la bonne décision dans l’urgence et rester responsable de la défaillance qui a créé l’urgence. À l’inverse, le succès d’une attaque ne prouve pas, à lui seul, une négligence. La réponse dépend de la sécurité promise par le prestataire, de la cause de la faille, des signaux d’alerte disponibles et de la rapidité de sa réaction.
Les clauses de limitation de responsabilité mériteraient aussi un examen attentif. En droit suisse, l’article 100 du Code des obligations interdit d’exclure d’avance sa responsabilité pour dol ou faute grave, et l’article 101 rend responsable du fait de ses auxiliaires. Une clause qui affirme « non-custodial » ne règle pas toutes les questions de responsabilité.
Swiss VASP : le sauveteur est devenu dépositaire
C’est, à mes yeux, le point le plus important, et celui que la plupart des commentateurs ont manqué.
Avant l’incident, Web3Auth était un prestataire technique pour des portefeuilles présentés comme non-custodial. Après le sauvetage, il détenait environ 6 millions de dollars appartenant à des dizaines de milliers de portefeuilles, sur des adresses qu’il contrôle. Quelle que soit l’étiquette, c’est de la conservation (custody).
En Suisse, détenir des cryptoactifs pour des tiers avec un pouvoir d’en disposer constitue de l’intermédiation financière au sens de la loi sur le blanchiment d’argent (LBA). Un prestataire de services d’actifs virtuels (PSAV), en anglais Swiss VASP, qui exerce cette activité doit s’affilier à un organisme d’autoréglementation, un OAR (en anglais SRO), reconnu par la FINMA, ou détenir une autorisation de la FINMA. La conservation n’est pas un sous-produit d’un service technique. C’est une activité réglementée, avec ses propres obligations.
Vient ensuite la question que tout utilisateur devrait poser : si le dépositaire fait faillite avant d’avoir rendu les actifs, est-ce que je récupère mes jetons, ou est-ce que je rejoins la file des créanciers ? Depuis 2021, l’article 242a de la loi sur la poursuite pour dettes et la faillite (LP) permet de distraire de la masse en faillite d’un dépositaire les cryptoactifs détenus pour ses clients, mais seulement si le dépositaire s’est engagé à les tenir en tout temps à leur disposition et s’ils sont attribués individuellement au client ou détenus dans une communauté où sa part est clairement déterminée. Appeler une adresse « portefeuille de récupération » ne remplit pas ces conditions. Les registres, si. C’est la même leçon que pour l’or alloué et non alloué, que j’ai expliquée dans Or tokenisé en Suisse : le lingot compte plus que le jeton.
La FINMA a fait le même constat dans sa Communication sur la surveillance 01/2026 relative à la conservation de cryptoactifs, publiée le 12 janvier 2026 : dépendance envers le dépositaire, risque de contrepartie et difficultés juridiques supplémentaires de la conservation à l’étranger, notamment en cas de faillite. Un sauvetage ne suspend pas ces risques. Il les concentre.
Rendre les actifs, c’est la partie difficile
La restitution pose un problème d’abord technique, puis immédiatement juridique. Lorsqu’une clé privée a été compromise, une signature faite avec cette clé ne prouve plus qui vous êtes : le propriétaire et le voleur peuvent tous deux la produire. La procédure de restitution a donc besoin d’un autre moyen de vérifier chaque demande.
Les questions sont concrètes. Quelle preuve faudra-t-il fournir ? Qui tranchera entre deux personnes qui réclament le même portefeuille ? Qu’en est-il des portefeuilles de sociétés, des titulaires décédés ou des utilisateurs qui ont perdu l’accès à leur compte Google ? Les jetons seront-ils rendus en nature, avec les récompenses de staking qu’ils auraient produites ? Des frais seront-ils déduits, et sur quelle base ? Et demandera-t-on aux utilisateurs de renoncer à leurs prétentions liées à la faille initiale en échange de la restitution de leurs actifs ? Je ne dis pas que Web3Auth imposera de telles conditions. Je dis que ce sont les questions qu’un utilisateur devrait poser avant de signer quoi que ce soit.
Et le « white hat » ?
Le qualificatif white hat n’est pas une autorisation juridique. En droit pénal suisse, l’accès indu à un système informatique protégé s’examine au regard de l’article 143bis du Code pénal, et le seul fait de signer une transaction sur une blockchain publique ne suffit pas à établir cette infraction. Même si un acte réunissait les éléments d’une infraction, l’état de nécessité de l’article 17 du Code pénal pourrait s’appliquer : un danger imminent, aucun autre moyen de l’écarter, et la sauvegarde d’intérêts prépondérants. L’intention compte. L’autorisation, la nécessité, la proportionnalité et la suite aussi.
Une dernière précaution. La possibilité d’exploiter une faille exceptionnelle ne prouve pas que le prestataire disposait normalement d’un contrôle illimité sur chaque portefeuille. Affirmer l’existence d’une porte dérobée permanente exigerait des preuves qui n’ont pas été publiées.
Un sauvetage peut justifier de prendre le contrôle dans l’urgence. Il crée aussi le devoir d’expliquer ce qui a été fait et d’ouvrir un chemin légal de retour vers le propriétaire. Pour le client, le sauvetage n’est terminé que lorsque le contrôle lui a été rendu en toute sécurité.
Comment FintechLex peut vous aider
Cette affaire est un test de résistance pour tous les services de portefeuille et de conservation. Si vous en créez ou en exploitez un, les questions ci-dessus doivent trouver leur réponse dans votre structure et vos contrats avant un incident, pas après. Nous vous aidons à :
- déterminer si votre portefeuille est réellement non-custodial ou si vous détenez des actifs pour des tiers, et ce que cela implique pour votre licence ;
- obtenir l’affiliation à un OAR (SRO) pour un Swiss VASP, ou acquérir une société prête à l’emploi déjà affiliée à un OAR ;
- organiser la conservation pour que les cryptos des clients puissent être distraites en cas de faillite selon l’article 242a LP, avec des registres séparés et une attribution claire ;
- rédiger des conditions d’utilisation qui disent qui peut intervenir en cas d’urgence, où vont les actifs et comment ils reviennent.
Si vous voulez aller vite, nous proposons un SRO (OAR) clé en main sur une société prête à l’emploi, prêt à porter une activité de Swiss VASP. Les mots qui comptent dans cette histoire, de la conservation (custody) à la finalité (finality), sont expliqués dans notre Glossaire des stablecoins, et toute la mécanique qui les entoure dans mon livre What Nobody Tells You About the Plumbing of Crypto.
Écrivez-nous à insight@fintechlex.com ou sur WhatsApp +41 787 983 770.
Rene-Philippe
Sources : Bitquery, enquête sur l’incident des portefeuilles Keplr (mise à jour le 12 novembre 2026) ; The Block, article sur les adresses de récupération de Web3Auth (8 novembre 2026) ; déclarations publiques de Keplr et de Web3Auth (6 au 12 novembre 2026) ; annonce de MANTRA sur la suspension du déblocage (13 novembre 2026) ; conditions d’utilisation de Keplr (en vigueur au 10 août 2026) ; conditions d’utilisation de Consensys (juin 2026) ; Code des obligations, articles 100, 101, 397 et 419 à 424 ; loi sur la poursuite pour dettes et la faillite, article 242a ; Code pénal, articles 17 et 143bis ; loi sur le blanchiment d’argent, article 2 ; FINMA, Communication sur la surveillance 01/2026, Conservation de cryptoactifs (12 janvier 2026). Fondé sur les informations publiques disponibles au 14 novembre 2026.
Cet article est fourni à titre d’information générale et ne constitue pas un conseil juridique. L’analyse en droit suisse est hypothétique et ne détermine pas la responsabilité selon les droits effectivement applicables à cet incident.
