Imaginez un instant que votre exchange crypto gèle soudainement ses comptes après une alerte de sécurité, puis découvre quelques jours plus tard des mouvements de fonds inattendus. C’est exactement ce qui s’est produit avec Unocoin, l’un des acteurs historiques du marché indien. Le 13 novembre 2026, BitGo a publié une mise au point ferme : ses propres systèmes n’ont pas été compromis. Les transactions sortantes ont été signées avec des clés détenues par le client. Cette précision change profondément la lecture de l’affaire et soulève des questions essentielles sur la responsabilité dans les montages de self-custody.
Un gel de compte qui a fonctionné, mais des transferts qui ont eu lieu
Tout commence le 6 novembre 2026. Unocoin détecte une activité suspecte sur son infrastructure. L’équipe demande immédiatement le gel de ses comptes auprès de deux prestataires de garde : Fireblocks à 11 h 24 UTC, puis BitGo à 11 h 29 UTC. Les deux confirmations arrivent. Sur le papier, la procédure de protection est enclenchée. Pourtant, des transferts sortants depuis une adresse Ethereum liée à l’infrastructure BitGo de l’exchange sont identifiés le 12 novembre.
BitGo a réagi le lendemain avec une déclaration claire. Le gel a fonctionné comme prévu. Aucune clé détenue par BitGo n’a été utilisée pour signer les transactions. Les signatures provenaient exclusivement de la clé utilisateur et de la clé de secours, toutes deux sous le contrôle d’Unocoin. Les transactions ont ensuite été diffusées directement sur la blockchain, sans passer par les serveurs de BitGo.
Cette distinction technique est capitale. Elle explique pourquoi le fournisseur de services de garde affirme que ses systèmes n’ont pas été violés et que les autres clients restent totalement à l’abri. La responsabilité se déplace vers la manière dont les clés locales ont été gérées et protégées côté exchange.
Le modèle 2-sur-3 expliqué simplement
Dans l’architecture proposée par BitGo pour les portefeuilles en self-custody, trois clés existent. Deux d’entre elles suffisent pour autoriser un mouvement de fonds. Unocoin détenait la clé utilisateur et la clé de secours. BitGo conservait uniquement la troisième.
En fonctionnement normal, les opérations quotidiennes utilisent la clé utilisateur combinée à la clé BitGo. La clé de secours sert de filet de sécurité. Elle permet de récupérer les actifs si le prestataire devient indisponible. C’est précisément ce mécanisme de récupération qui est aujourd’hui sous le feu des projecteurs.
La documentation de BitGo décrit clairement la procédure. Le client génère ses propres clés de son côté. Il fournit ensuite une version chiffrée de la clé utilisateur et la clé publique de secours. BitGo n’a jamais accès aux clés privées utilisateur ou backup. Les instructions de récupération montrent même comment créer une transaction entièrement signée hors de la plateforme, puis la diffuser via un explorateur de blocs. Pour Ethereum et les tokens ERC-20, il faut fournir l’adresse du contrat de portefeuille et, le cas échéant, celle du token.
Point technique essentiel : dans un schéma 2-sur-3, la possession de deux clés par le client crée une autonomie forte, mais transforme aussi ces deux clés en cible privilégiée pour un attaquant qui aurait réussi à s’introduire dans l’infrastructure de l’exchange.
Ce que dit Unocoin dans sa mise à jour
L’exchange a confirmé avoir reçu les clarifications demandées à BitGo. Il reconnaît que le gel semble avoir opéré correctement et que les transactions ont été signées et diffusées en dehors de la plateforme du prestataire. Unocoin évoque désormais l’hypothèse d’une exploitation du mécanisme de sauvegarde. L’enquête porte sur la façon dont ce mécanisme a pu être accessible, sur l’éventuelle perte de cryptomonnaies et sur une possible exposition d’informations privées.
Le récit de l’incident a évolué au fil des jours. Le 12 novembre, Unocoin expliquait que l’accès gelé l’empêchait de consulter l’historique complet des transactions via l’interface BitGo. L’équipe avait demandé des informations détaillées après avoir repéré des mouvements depuis une adresse ETH servant à alimenter des tokens ERC-20.
Ni BitGo ni Unocoin n’ont nommé de responsable ni publié de chiffre définitif de perte à ce stade. Cette prudence est compréhensible : une enquête technique sérieuse prend du temps, surtout lorsqu’il s’agit de retracer l’origine exacte de l’accès aux clés.
Chronologie des événements clés
Pour y voir plus clair, voici le déroulé tel qu’il ressort des déclarations publiques :
- 6 novembre 2026 : détection d’activité suspecte. Demandes de gel Fireblocks et BitGo dans un intervalle de cinq minutes.
- 9 novembre 2026 : nouvelle activité non autorisée identifiée. Suspension de tous les services et désactivation des connexions clients.
- 12 novembre 2026 : identification de transferts sortants depuis une adresse Ethereum liée à BitGo. Site web en erreur 504.
- 13 novembre 2026 : déclaration de BitGo confirmant l’absence d’utilisation de sa clé et l’absence de compromission de ses systèmes. Mise à jour d’Unocoin évoquant une possible exploitation du mécanisme de backup.
Entre le gel et la découverte des transferts, plusieurs jours se sont écoulés. Ce délai soulève des interrogations légitimes sur la surveillance des adresses on-chain et sur la rapidité de détection des mouvements anormaux une fois les comptes gelés côté prestataire.
Les déclarations antérieures sur l’accès serveur
Avant la clarification de BitGo, Unocoin avait déjà annoncé avoir désactivé les connexions clients après un accès non autorisé à ses serveurs, révélé le 9 novembre. Le site affichait une erreur 504 Gateway Time-out le 12 novembre. Des observations on-chain avaient alors montré des soldes nuls sur un grand nombre d’adresses associées à l’exchange, sans que cela ne signifie nécessairement un vol total.
Dans sa première communication, Unocoin avait indiqué qu’aucune perte de fonds clients n’était constatée. Plus de 90 % des cryptomonnaies des utilisateurs se trouvaient en cold storage. L’exchange estimait avoir besoin de quatre à cinq jours ouvrés pour reconstruire et sécuriser son infrastructure serveur avant de pouvoir reprendre les services, sous réserve de contrôles de sécurité supplémentaires.
Cette distinction entre hot wallets et cold storage reste un point central. Les fonds en cold storage sont généralement beaucoup plus difficiles à atteindre. Les mouvements suspects semblent concerner des adresses opérationnelles utilisées pour les flux quotidiens.
Pourquoi le mécanisme de backup devient le point sensible
Le design des portefeuilles self-custody de BitGo vise précisément à éviter qu’un client se retrouve bloqué si le prestataire disparaît ou devient inaccessible. La clé de secours offre une voie de sortie autonome. Mais cette autonomie a un prix : elle place deux des trois signatures nécessaires entre les mains du client.
Si un attaquant parvient à obtenir la clé utilisateur et la clé de secours, ou à compromettre les systèmes qui les stockent et les utilisent, il peut signer des transactions sans jamais toucher aux systèmes de BitGo. C’est exactement le scénario que décrit aujourd’hui le prestataire.
Unocoin indique qu’il enquête sur la manière dont ce mécanisme a pu être exploité. Les questions restent ouvertes : fuite de mots de passe, accès à des fichiers chiffrés, compromission d’un environnement de récupération, ou autre vecteur encore non public. Tant que l’enquête n’est pas terminée, toute conclusion définitive serait prématurée.
« Les transactions récentes sortantes ont été signées à l’aide des clés utilisateur et de secours détenues par Unocoin et diffusées de manière externe on-chain, sans participation de BitGo. »
— Déclaration BitGo du 13 novembre 2026
Les implications pour les exchanges et leurs clients
Cette affaire met en lumière une réalité souvent mal comprise par les utilisateurs. Confier ses fonds à un exchange qui utilise un prestataire de garde ne signifie pas automatiquement que les clés sont entièrement hors de portée de l’exchange. Dans un modèle 2-sur-3 self-custody, une partie significative du pouvoir de signature reste locale.
Pour les plateformes, cela implique des obligations de sécurité particulièrement strictes autour de la génération, du stockage et de l’utilisation des clés utilisateur et backup. Les procédures de récupération doivent être aussi robustes que les procédures de transaction normales. Un environnement de recovery mal isolé peut devenir le maillon faible.
Pour les utilisateurs, l’épisode rappelle l’importance de diversifier les risques. Même lorsqu’un exchange annonce que la majorité des fonds est en cold storage, les adresses opérationnelles restent exposées. La transparence sur les montages de garde et sur les procédures de gel devient un critère de choix de plus en plus important.
Ce que change la déclaration de BitGo pour la suite
En affirmant que sa clé n’a jamais été utilisée et que ses systèmes n’ont pas été atteints, BitGo se positionne clairement hors du périmètre de la compromission. L’enquête se concentre désormais sur l’environnement Unocoin. Cette clarification protège la réputation du prestataire auprès de ses autres clients, qui peuvent constater que le modèle multiclé a fonctionné comme prévu côté BitGo.
Elle place aussi Unocoin dans une situation où il doit démontrer qu’il a pris toutes les mesures raisonnables pour protéger les deux clés qu’il détenait. L’issue de l’enquête technique et les éventuelles communications futures sur le montant exact des fonds concernés seront déterminantes pour la confiance des utilisateurs indiens et internationaux.
À ce stade, aucun chiffre officiel de perte n’a été communiqué. Les observations on-chain antérieures montraient des soldes nuls sur un grand nombre d’adresses, mais cela peut refléter des transferts internes, des consolidations ou d’autres mouvements légitimes en plus d’éventuels détournements. Seule une analyse forensique complète permettra de trancher.
Les leçons pour la sécurité des portefeuilles multiclé
Plusieurs enseignements se dégagent déjà de cet incident, même avant la fin de l’enquête.
Premier point : le gel de compte côté prestataire ne bloque pas nécessairement les transactions signées localement avec des clés client. Une fois les signatures obtenues, la diffusion on-chain peut se faire de façon autonome. La surveillance des adresses publiques devient donc critique.
Deuxième point : la clé de secours, conçue comme un outil de résilience, peut se transformer en vecteur d’attaque si elle n’est pas protégée avec le même niveau de rigueur que les autres éléments critiques. Les procédures de recovery doivent être testées, isolées et auditées régulièrement.
Troisième point : la communication transparente et rapide entre prestataire et exchange est essentielle. BitGo a publié sa position dès le 13 novembre. Unocoin a intégré ces éléments dans sa mise à jour. Cette coordination limite la propagation de rumeurs et permet aux utilisateurs de disposer d’informations factuelles.
À retenir : dans un schéma 2-sur-3 où le client détient deux clés, la sécurité dépend en grande partie de la solidité des systèmes et des processus du client lui-même. Le prestataire ne peut pas empêcher une signature locale une fois les clés compromises.
Le contexte plus large des incidents de garde crypto
Les affaires de ce type ne sont pas isolées. L’industrie de la garde crypto a connu plusieurs épisodes où la frontière entre responsabilité du prestataire et responsabilité du client a été au centre des débats. Chaque incident contribue à affiner les bonnes pratiques et les attentes réglementaires.
En Inde, le marché crypto reste particulièrement attentif à ces sujets. Unocoin fait partie des plateformes historiques. Toute atteinte à la confiance a des répercussions sur l’ensemble de l’écosystème local. La reprise des services, annoncée comme nécessitant plusieurs jours de reconstruction et de validation, sera observée de près.
Les utilisateurs, de leur côté, continuent d’apprendre. Beaucoup réalisent aujourd’hui que « self-custody » ne signifie pas toujours que les clés sont entièrement hors de portée de l’exchange. Comprendre le nombre de signatures requises et qui les détient devient un réflexe de plus en plus répandu.
Ce qu’il faut surveiller dans les prochaines heures et jours
Plusieurs éléments restent attendus. Unocoin doit préciser, si possible, le montant des fonds concernés et l’origine exacte de l’accès aux clés. BitGo pourrait communiquer davantage de détails techniques sur la façon dont le gel a été appliqué et sur les contrôles effectués. Les analyses on-chain indépendantes continueront d’apporter des éléments de contexte.
La reprise progressive des services d’Unocoin constituera un test de crédibilité. La plateforme a indiqué qu’elle procéderait à des contrôles de sécurité avant de rouvrir les accès. La clarté de ces contrôles et la communication autour d’eux seront déterminantes.
Enfin, d’autres exchanges utilisant des montages similaires pourraient revoir leurs procédures de protection des clés de secours. Les audits internes et les tests de scénarios de compromission locale risquent de se multiplier dans les semaines à venir.
Une affaire qui redéfinit les contours de la responsabilité
Au-delà des détails techniques, cet incident pose une question de fond : où s’arrête la responsabilité d’un prestataire de garde et où commence celle de l’exchange client ? La réponse de BitGo est nette. Tant que sa clé n’est pas utilisée et que ses systèmes restent intacts, la compromission des clés client ne lui est pas imputable.
Cette position est cohérente avec le modèle self-custody. Elle rappelle cependant que le choix d’un montage 2-sur-3 transfère une part importante du risque opérationnel vers le client. Les exchanges qui optent pour cette architecture doivent en assumer pleinement les conséquences en matière de sécurité interne.
Pour les utilisateurs finaux, le message est double. D’un côté, le gel de compte a fonctionné côté BitGo. De l’autre, des transferts ont malgré tout eu lieu parce que deux clés étaient détenues localement. La diversification des plateformes et la compréhension fine des montages de garde restent les meilleurs outils de protection.
L’enquête d’Unocoin se poursuit. Les prochaines communications apporteront sans doute des éléments nouveaux. En attendant, l’affaire illustre avec force à quel point la sécurité crypto repose sur une chaîne de responsabilités partagées, où chaque maillon doit rester solide.
Perspectives pour l’industrie de la garde
Les prestataires de services de garde vont probablement renforcer leurs recommandations concernant la protection des clés client. Les documentations techniques, déjà précises, pourraient être enrichies de check-lists de sécurité plus détaillées sur la gestion des environnements de recovery.
Les régulateurs, notamment en Inde, suivront l’évolution de l’affaire avec attention. Les exigences en matière de résilience opérationnelle et de protection des actifs clients pourraient s’affiner à la lumière de ces événements.
Les utilisateurs, enfin, gagneront à poser davantage de questions à leurs plateformes : qui détient quelles clés ? Comment le gel fonctionne-t-il concrètement ? Quelles sont les procédures de surveillance on-chain après un gel ? Ces interrogations, autrefois réservées aux experts, deviennent de plus en plus légitimes.
BitGo a joué la carte de la transparence en publiant rapidement sa position. Unocoin a intégré ces éléments dans sa communication. Cette dynamique d’information factuelle est positive. Elle permet à chacun de se forger une opinion sur la base d’éléments concrets plutôt que de spéculations.
L’histoire n’est pas terminée. Les résultats de l’enquête technique d’Unocoin et les éventuelles mesures correctives qui en découleront constitueront le prochain chapitre. Pour l’instant, une chose est claire : les systèmes de BitGo n’ont pas été atteints, et les signatures ont été produites avec des clés détenues par l’exchange. Cette précision redessine les contours de l’incident et invite l’ensemble de l’écosystème à revoir ses pratiques autour des clés de secours.
Dans un secteur où la confiance se construit lentement et se perd rapidement, chaque clarification technique compte. Celle de BitGo, le 13 novembre 2026, apporte une pièce essentielle au puzzle. Reste maintenant à Unocoin de compléter le tableau avec les conclusions de son investigation interne.
Les prochains jours diront si des fonds clients ont effectivement été impactés et dans quelles proportions. Ils diront aussi si les procédures de reconstruction de l’infrastructure d’Unocoin permettent un retour à la normalité dans les délais annoncés. Pour les observateurs du marché crypto indien et international, cet épisode restera un cas d’école sur les forces et les limites des modèles de self-custody multiclé.
