Multisig et Safe : sécuriser à plusieurs signatures

Comprendre le multisig M-sur-N, la différence entre Bitcoin et Safe sur EVM, et vérifier ce que vous signez pour éviter le piratage à 1,5 milliard de 2025.

Sécurité · Avancé · 11 min de lecture · Publié le 28 septembre 2026

L’essentiel

Ce guide est une information générale à visée pédagogique, et non un conseil en investissement, juridique ou fiscal.

Le principe du M-sur-N

Un multisig se décrit avec deux nombres : M, le nombre minimal de signatures requises, et N, le nombre total de clés autorisées. On parle de « 2-sur-3 », « 3-sur-5 », etc.

Dans un wallet classique, une seule clé privée (dérivée de votre seed phrase) suffit à tout dépenser. Si elle est volée, tout est perdu ; si elle est perdue, tout est bloqué. Le multisig répartit ce pouvoir :

Contre le vol : un attaquant qui obtient une seule clé ne peut rien faire dans un 2-sur-3.
Contre la perte : dans un 2-sur-3, perdre une clé n'empêche pas de dépenser avec les deux autres, puis de migrer vers une nouvelle configuration.
Contre l'erreur ou la décision isolée : dans une équipe, aucune personne ne peut déplacer les fonds seule.

Le choix de M et N est un arbitrage. Un M trop bas (1-sur-3) n'apporte presque aucune protection contre le vol. Un M égal à N (3-sur-3) transforme chaque perte de clé en blocage définitif. Les configurations du type 2-sur-3 ou 3-sur-5 sont courantes précisément parce qu'elles tolèrent à la fois une clé compromise et une clé perdue.

Deux familles techniques : Bitcoin et les smart contracts

Le multisig natif de Bitcoin

Sur Bitcoin, le multisig est inscrit dans le script de la transaction. La documentation développeur de Bitcoin décrit le cas standard : un script de rachat (« redeem script ») qui liste les clés publiques et le seuil, par exemple 2 clés sur 3, vérifié par l'instruction OP_CHECKMULTISIG. Aujourd'hui, ce script est encapsulé (P2SH, puis ses variantes SegWit) : l'adresse ne révèle pas la configuration tant que les fonds ne sont pas dépensés.

Points pratiques côté Bitcoin :

Les signataires s'échangent une transaction partiellement signée au format PSBT (Partially Signed Bitcoin Transaction), que chaque hardware wallet signe tour à tour.
Il n'y a pas de contrat à déployer : l'adresse multisig est calculée à partir des clés publiques.
Changer de configuration (ajouter une clé, changer le seuil) signifie créer un nouveau multisig et y transférer les fonds.
Point critique pour la récupération : pour reconstruire le wallet, il faut connaître toutes les clés publiques étendues (xpub) des cosignataires et la configuration exacte, pas seulement M seeds. Deux seeds sur trois ne suffisent pas si vous avez perdu la troisième xpub. D'où l'importance de sauvegarder le « descripteur » du wallet (le fichier qui décrit la configuration) avec chaque seed.

Les smart-contract wallets sur EVM : l'exemple de Safe

Sur Ethereum et les réseaux compatibles EVM, un compte classique (EOA) ne peut avoir qu'une seule clé. Le multisig y est donc implémenté par un smart contract : un programme déployé sur la blockchain qui détient les fonds et applique ses propres règles. Safe (anciennement Gnosis Safe) est l'implémentation la plus répandue, et sert ici d'illustration.

Selon la documentation de Safe, un compte Safe contient :

une liste de propriétaires (« owners »), qui sont des adresses Ethereum ;
un seuil (« threshold ») : le nombre minimal de propriétaires qui doivent confirmer une transaction avant son exécution, réglable entre 1 et le nombre total de propriétaires ;
des modules optionnels, qui ajoutent des fonctionnalités et peuvent exécuter des transactions sans passer par la vérification des signatures ;
des guards optionnels, qui effectuent des contrôles avant et après chaque transaction.

Avantage majeur par rapport à Bitcoin : les propriétaires et le seuil se modifient par une transaction du Safe lui-même, sans déplacer les fonds. En contrepartie, la sécurité dépend aussi du code du contrat, de ses modules et de l'interface web utilisée pour préparer les transactions.

Critère	Multisig Bitcoin	Safe (EVM)
Mise en place	Adresse calculée, pas de déploiement	Contrat à déployer (frais)
Modifier signataires ou seuil	Nouveau wallet + transfert	Transaction du Safe
Surface de risque	Scripts simples, bien éprouvés	Contrat, modules, interface web

Des configurations adaptées à chaque situation

Un particulier seul

Un 2-sur-3 avec trois hardware wallets, idéalement de marques différentes, conservés à des endroits distincts (domicile, second lieu sûr, coffre). Vous signez au quotidien avec deux appareils ; le troisième sert de secours. Chaque seed est sauvegardée séparément de son appareil, et chaque sauvegarde est accompagnée de la configuration complète (xpubs ou adresses de tous les signataires).

Une famille

Un 2-sur-3 où une clé est détenue par vous, une par un proche de confiance, une conservée dans un lieu sûr. Cette structure facilite la transmission (voir le guide sur l'héritage) : le proche ne peut rien faire seul, mais pourra, avec la clé de secours, accéder aux fonds le moment venu. Rédigez une procédure écrite compréhensible par quelqu'un qui n'est pas technicien.

Une équipe ou une association

Un 3-sur-5 (ou plus) où chaque signataire utilise son propre hardware wallet dédié, jamais partagé. Définissez par écrit qui propose, qui vérifie et qui exécute, et prévoyez le départ d'un membre : la première action après un départ doit être de retirer son adresse et, si nécessaire, d'ajuster le seuil.

Règle commune à toutes ces configurations : aucune personne et aucun lieu ne doivent détenir M clés à la fois. Deux seeds dans le même tiroir transforment un 2-sur-3 en simple wallet.

Vérifier avant de signer : les leçons du piratage de février 2025

Ce qui s'est passé

Le 21 février 2025, un grand exchange centralisé s'est fait dérober environ 1,5 milliard de dollars d'actifs, un vol attribué par le FBI à la Corée du Nord (activité désignée « TraderTraitor »). Les fonds se trouvaient dans un « cold wallet » Ethereum protégé par un Safe multisig.

Selon l'analyse technique de NCC Group, les signataires pensaient approuver un transfert de routine vers un hot wallet. En réalité, l'interface web utilisée pour préparer la transaction avait été compromise et leur présentait une version trompeuse. La transaction signée utilisait une opération delegatecall (qui exécute le code d'un autre contrat dans le contexte du Safe) vers un contrat malveillant. Ce contrat a remplacé l'adresse du code utilisé par le Safe par celle d'un contrat contrôlé par l'attaquant, qui a ensuite vidé le wallet : plus de 400 000 ETH, en plus d'autres actifs. L'analyse souligne que les signataires ont signé à l'aveugle, en faisant confiance à ce qu'affichait l'application web plutôt qu'à ce que montrait leur appareil.

La fondation Safe a indiqué que l'origine était la compromission de la machine d'un de ses développeurs, et que les audits externes n'avaient pas révélé de faille dans ses smart contracts.

Ce qu'il faut en retenir

Le multisig n'a pas été « cassé » : tous les signataires requis ont bel et bien signé. Le point faible était la vérification. Si chaque signataire fait confiance au même écran, la compromission de cet écran suffit.

La vérification du hash, étape par étape

Chaque transaction Safe est résumée par un hash (une empreinte cryptographique unique, calculée selon le standard EIP-712 à partir d'un « domain hash » qui identifie le Safe et le réseau, et d'un « message hash » qui décrit la transaction). C'est ce hash, ou ses composantes, que la plupart des hardware wallets affichent au moment de signer.

Obtenez les détails de la transaction proposée : destinataire, montant, données (« calldata »), type d'opération, nonce.
Recalculez le hash de façon indépendante, sur une autre machine ou avec un autre outil que l'interface qui a proposé la transaction. Des outils open source existent pour cela, comme le script safe-tx-hashes-util, qui calcule les trois hashes à partir des paramètres.
Comparez le hash recalculé avec celui affiché sur l'écran du hardware wallet, caractère par caractère sur au moins le début et la fin.
Vérifiez le type d'opération : un delegatecall vers un contrat que vous ne connaissez pas doit bloquer la signature.
Vérifiez le nonce : il doit correspondre à la prochaine transaction attendue, sans saut ni doublon.
Décodez les données : un « transfert » dont les données appellent une autre fonction, ou un changement de propriétaires inattendu, est un signal d'alerte.

Idéalement, au moins deux signataires font cette vérification de façon indépendante, avec des ordinateurs différents.

Les coûts d'un multisig

Bitcoin : une transaction multisig contient plusieurs signatures et le script, elle est donc plus volumineuse et coûte plus cher en frais qu'une dépense simple. Il n'y a en revanche pas de frais de création.
Safe : selon le centre d'aide de Safe, créer un Safe est gratuit mais son activation (le déploiement du contrat) nécessite de payer des frais en actif natif sur chaque réseau. Chaque exécution de transaction coûte ensuite du gas, plus qu'un simple transfert depuis un compte classique. Sur Ethereum mainnet, ces frais peuvent peser pour de petites sommes ; sur un layer 2, ils sont généralement bien plus faibles.
Coût humain : chaque opération demande de coordonner plusieurs personnes et appareils. C'est voulu, mais cela rend le multisig peu adapté aux petites dépenses fréquentes.

Récupération et migration

Une clé perdue dans un 2-sur-3 : sur Safe, les deux autres signataires remplacent immédiatement l'adresse perdue. Sur Bitcoin, les deux autres signent un transfert vers un nouveau multisig. N'attendez pas : tant que la clé n'est pas remplacée, vous n'avez plus de marge d'erreur.
Une clé potentiellement compromise : même procédure, en urgence, avant que l'attaquant n'obtienne une deuxième clé.
Multi-réseaux sur Safe : un Safe peut avoir la même adresse sur plusieurs réseaux, mais il doit être déployé sur chacun. Le centre d'aide de Safe avertit que certains réseaux, comme zkSync Era, ne permettent pas d'obtenir la même adresse : des fonds envoyés sur ce réseau vers l'adresse d'un Safe existant ailleurs seraient perdus. Vérifiez toujours que votre Safe existe bien sur le réseau de destination avant un envoi.
Testez la récupération : faites un essai avec un petit montant, en reconstruisant le wallet depuis vos sauvegardes sur un appareil vierge.

Exemple concret

Claire veut protéger une épargne en bitcoins et en ETH. Elle choisit un 2-sur-3 avec trois hardware wallets de deux marques différentes.

Appareil A chez elle, appareil B chez sa sœur, appareil C dans un coffre bancaire. Chaque seed est notée sur un support séparé de son appareil, dans un lieu différent.
Côté Bitcoin, elle exporte le descripteur du wallet (les trois xpubs et la configuration 2-sur-3) et en range une copie avec chaque seed. Elle vérifie sur l'écran de chaque appareil que la première adresse de réception est identique.
Côté Ethereum, elle crée un Safe sur un layer 2 avec les trois adresses et un seuil de 2, puis envoie d'abord un petit montant de test.
Pour chaque sortie de fonds, elle prépare la transaction, recalcule le hash sur un second ordinateur, compare avec l'écran de l'appareil A puis de l'appareil B, et ne signe que si tout correspond.

Six mois plus tard, l'appareil B est perdu lors d'un déménagement. Claire utilise A et C pour remplacer B par un nouvel appareil sur le Safe, et transfère ses bitcoins vers un nouveau multisig 2-sur-3.

Les erreurs à éviter

Stocker M seeds au même endroit : cela annule tout l'intérêt du multisig.
Oublier de sauvegarder les xpubs (Bitcoin) : sans la configuration complète, même les bonnes seeds peuvent ne pas suffire.
Signer à l'aveugle : faire confiance à l'interface web au lieu de lire l'écran du hardware wallet et de recalculer le hash.
Accepter un delegatecall inconnu ou un changement de propriétaires que personne n'a annoncé.
Utiliser le même ordinateur pour tous les signataires : une seule machine compromise suffit alors à tromper tout le monde.
Ajouter des modules sans les comprendre : sur Safe, un module peut exécuter des transactions sans les signatures des propriétaires.
Envoyer des fonds sur un réseau où le Safe n'est pas déployé, ou sur un réseau qui ne permet pas la même adresse.
Ne jamais tester la récupération avant d'en avoir besoin.

À retenir

Un multisig M-sur-N exige M signatures parmi N clés ; le 2-sur-3 tolère à la fois une clé volée et une clé perdue.
Sur Bitcoin, le multisig est natif et simple, mais toute modification impose un nouveau wallet ; sauvegardez toutes les xpubs.
Sur EVM, Safe est un smart contract : signataires et seuil sont modifiables, mais le contrat, les modules et l'interface ajoutent des risques.
Le vol de février 2025 (1,5 milliard de dollars) a exploité une interface compromise et une signature à l'aveugle, pas une faille du principe multisig.
Recalculez le hash de chaque transaction de façon indépendante et comparez-le à l'écran de votre hardware wallet avant de signer.
Répartissez clés et sauvegardes dans des lieux distincts, et testez la récupération avec un petit montant.

Sources

Comparer les services liés à ce sujet

Meilleur wallet crypto : comparatif