Ce que fait réellement un portefeuille multisig, et pourquoi une seule clé suffit rarement
Un portefeuille crypto standard repose sur une seule clé privée qui signe chaque transaction. Quiconque contrôle cette clé contrôle les fonds, point final. Si vous la perdez, l’argent est perdu ; si elle est volée, l’argent est perdu. Il n’y a pas de service d’assistance, pas de réinitialisation de mot de passe, pas de service antifraude. Pour quelques centaines de dollars d’avoirs personnels, ce compromis est acceptable. Pour la trésorerie d’une DAO, les réserves chaudes d’une plateforme d’échange, le portefeuille opérationnel d’un fonds ou le stockage à froid de long terme d’un family office, il ne l’est pas.
Un portefeuille multisig répartit cette autorité entre N clés indépendantes et exige que M d’entre elles signent toute transaction. Une configuration 3 sur 5, par exemple, nécessite l’approbation de trois signataires parmi cinq avant tout mouvement de fonds. Si deux clés sont perdues, le portefeuille reste utilisable. Si une clé est volée, le voleur ne peut rien déplacer seul. Le concept est plus ancien que la crypto ; on le retrouve dans les comptes séquestres bancaires, les systèmes de trésorerie d’entreprise et même les mécanismes d’authentification à deux facteurs. On-chain, la logique réside dans un smart contract plutôt que dans une banque.
L’idée essentielle est que le multisig n’est pas une fonctionnalité que l’on active ; c’est un système opérationnel que l’on exploite. Le smart contract applique la règle M sur N au niveau du protocole, mais les personnes, appareils, lieux et habitudes que vous mettez autour déterminent s’il vous protège réellement. Un 3 sur 5 où les cinq clés se trouvent sur des appareils dans un même bureau, avec des signatures effectuées par une seule personne qui connaît par hasard les mots de passe de tout le monde, est à peine plus sûr qu’un hot wallet à clé unique. Un 2 sur 3 où les trois signataires sont répartis sur trois continents avec des hardware wallets de trois fournisseurs différents est nettement plus difficile à attaquer, même si les deux portefeuilles réussissent techniquement le test « est-ce du multisig ? ».
Les vrais risques avant de commencer (lisez ceci deux fois)
Le multisig introduit des risques qu’un portefeuille à clé unique n’a pas. Le premier est le risque de verrouillage : si vous configurez un 3 sur 5 et que trois signataires perdent leurs clés simultanément, les fonds sont mathématiquement irrécupérables. Il n’y a pas de porte dérobée. Cherchez « parity wallet frozen » sur le web et vous trouverez un incident de 2017 où un bug dans une bibliothèque multisig a accidentellement verrouillé plus de 500 000 ETH dans un seul contrat. Le bug était une erreur de code, pas un hack, et l’argent est toujours là. La leçon est que le risque lié aux smart contracts est réel, même avec du code audité et largement utilisé.
Le deuxième risque est le facteur humain. Le multisig suppose que vos signataires ne s’entendront pas entre eux, ne seront pas victimes de phishing au même moment et ne se trouveront pas tous dans le même aéroport lorsque les douanes décideront d’imager leurs ordinateurs portables. Si deux de vos trois signataires sont des cofondateurs qui voyagent ensemble, vous avez un 2 sur 3 en théorie et un 1,5 sur 3 en pratique. Le troisième risque est opérationnel : chaque signataire doit suivre la même procédure à chaque fois. Un signataire qui « clique simplement pour passer » les détails de transaction constitue un point de défaillance unique pour l’ensemble du portefeuille.
Le quatrième risque est la possibilité de mise à niveau du contrat. Certaines implémentations multisig, y compris certaines versions de Safe, permettent de mettre à niveau la logique du contrat par un vote des signataires eux-mêmes. C’est pratique pour corriger des bugs, mais cela signifie qu’une majorité hostile de vos signataires peut changer les règles. Si vous voulez l’immutabilité, vous devez vérifier que la version que vous déployez n’est pas évolutive. Le cinquième risque est propre à chaque chaîne : la majeure partie de ce guide s’applique aux chaînes EVM (Ethereum, Arbitrum, Base, Optimism, Polygon, BNB Chain), où Safe domine. Le multisig Bitcoin existe, mais il fonctionne différemment et n’est pas couvert ici. Solana et d’autres chaînes non EVM disposent de leurs propres standards multisig, chacun avec ses particularités.
Étape 1 : définissez qui sont les signataires, où ils se trouvent et ce qu’ils détiennent
Avant d’ouvrir le moindre logiciel, notez sur une seule page la réponse à quatre questions. Premièrement, combien y a-t-il de signataires au total (N) ? Deuxièmement, combien doivent signer chaque transaction (M) ? Troisièmement, où chaque signataire se trouve-t-il physiquement ? Quatrièmement, quel appareil et quel fournisseur chaque signataire utilise-t-il ?
N se situe généralement entre 3 et 7. En dessous de 3, vous avez trop peu de redondance. Au-dessus de 7, la charge de coordination augmente et la probabilité qu’un signataire soit absent à un moment critique augmente aussi. M est le nombre le plus difficile à choisir. Un schéma courant est 3-sur-5, qui tolère deux signataires perdus ou compromis, mais exige tout de même que trois personnes agissent pour les opérations normales. Un 2-sur-3 est plus rapide à utiliser, mais ne tolère qu’une seule défaillance. Un 4-sur-7 est conservateur et courant dans les grandes DAO, mais lent. Les mathématiques sont implacables : avec N clés, vous pouvez perdre jusqu’à N moins M clés et continuer à fonctionner, mais si vous en perdez davantage, vous êtes bloqué pour toujours.
La géographie compte en raison du risque corrélé. Un signataire à Singapour, un signataire à Lisbonne, un signataire à Buenos Aires et un signataire à Toronto ont peu de chances d’être touchés en même temps par le même ouragan, la même coupure d’Internet ou la même action des forces de l’ordre. Le fournisseur du matériel compte pour la même raison : une vulnérabilité découverte dans le firmware d’un fournisseur ne devrait pas compromettre simultanément tous vos signataires. Mélangez Ledger, Trezor, GridPlus et Keystone si vous le pouvez ; ne faites pas fonctionner cinq signataires sur cinq appareils identiques issus du même lot.
Enfin, décidez qui sont réellement les personnes. Pour un wallet personnel, vous pourriez utiliser vos propres clés sur des appareils que vous contrôlez dans différents lieux physiques. Pour une DAO, les signataires sont généralement un sous-ensemble de l’équipe principale, avec éventuellement un conseiller en sécurité. Pour un family office, les signataires peuvent être le principal intéressé, un responsable des opérations de confiance et la clé d’un dépositaire tiers. Quels qu’ils soient, chaque signataire doit comprendre qu’il ne peut pas perdre son appareil, partager sa phrase de récupération ni signer des transactions sans les lire.
Étape 2 : déployez un Safe sur la chaîne que vous comptez utiliser
Safe (anciennement Gnosis Safe) est le multisig le plus largement déployé sur les chaînes EVM. Il est en service depuis 2018, détient des milliards de dollars de fonds de trésorerie pour des milliers de DAO et d’équipes, et a été audité et forké de nombreuses fois. Pour la plupart des utilisateurs EVM, Safe est la référence par défaut. Cela dit, « le plus utilisé » ne signifie pas « sûr pour votre cas précis ». Lisez les rapports d’audit, vérifiez la version actuelle et assurez-vous que l’adresse du contrat depuis laquelle vous déployez correspond à l’adresse officielle publiée par Safe.
Ouvrez l’application officielle Safe à l’adresse app.safe.global (ne faites pas confiance aux liens provenant d’e-mails, de tweets ou d’annonces de recherche). Connectez d’abord un wallet en lecture seule pour parcourir l’interface ; vous n’avez pas besoin de connecter un wallet de signature tant que vous ne déployez pas réellement. Choisissez le réseau souhaité. Le mainnet Ethereum est le plus sécurisé, mais coûteux à configurer ; les réseaux Layer 2 comme Arbitrum, Base et Optimism sont moins chers et héritent tout de même de la sécurité d’Ethereum pour le règlement. Choisissez la chaîne qui correspond à l’endroit où votre trésorerie opère réellement.
Cliquez sur « Create new Safe ». Choisissez votre seuil (M) et ajoutez les adresses de vos N wallets signataires. Ce sont des adresses EVM ordinaires générées par MetaMask, Rabby, Frame, des hardware wallets ou tout autre wallet EVM ; le Safe ne se soucie pas de la manière dont la clé sous-jacente a été créée, seulement de l’adresse qu’elle possède. Confirmez. Signez la transaction de déploiement avec le signataire connecté et payez les frais de réseau. Safe déploiera un nouveau wallet de smart contract à une nouvelle adresse ; cette adresse est votre multisig.
Notez l’adresse du Safe. Envoyez une toute petite transaction de test (un petit montant du token natif, par exemple 0,001 ETH) pour confirmer que l’adresse est correcte. Testez une transaction depuis le Safe vers votre propre adresse. Faites-la signer par le nombre requis de signataires et exécutez-la. Ce n’est qu’une fois ce test de bout en bout réussi que vous devriez envisager d’envoyer de véritables fonds de trésorerie.
Étape 3 : répartissez les clés des signataires entre appareils, fournisseurs et emplacements
Maintenant que le Safe existe, vous devez vous assurer que chaque signataire est réellement prêt. Un signataire n’est pas seulement une adresse ; c’est une personne avec un appareil, une sauvegarde et un processus. Pour chaque signataire, générez la clé sur un hardware wallet (Ledger, Trezor, GridPlus, Keystone ou un autre fournisseur réputé). Notez la phrase de récupération sur papier ou sur métal ; ne la stockez pas dans un gestionnaire de mots de passe, un drive cloud, un e-mail ou une photo. Conservez la sauvegarde dans un lieu physiquement séparé de l’appareil.
La distribution géographique comporte deux niveaux. Le premier niveau est l’endroit où l’appareil se trouve normalement : un coffre à domicile, un coffre au bureau, un coffre bancaire. Le deuxième niveau est l’endroit où se trouve la sauvegarde. Ces deux lieux ne doivent pas être dans le même bâtiment. Un incendie, une inondation ou un cambriolage qui emporte l’appareil ne doit pas aussi emporter la phrase de récupération.
La diversité des fournisseurs est non négociable pour les trésoreries sérieuses. Ne faites pas fonctionner trois appareils Ledger, deux Trezor et un GridPlus, car cela reste trois appareils d’un même fournisseur. L’objectif est de faire en sorte qu’un seul bug de firmware ou une attaque de la chaîne d’approvisionnement ne puisse pas compromettre M de vos N signataires. Deux ou trois fournisseurs constituent un minimum raisonnable. Notez que la diversité des fournisseurs n’est pas seulement de la paranoïa ; c’est aussi une protection contre le jour où l’on découvrirait qu’un fournisseur possède une porte dérobée délibérée, comme certains utilisateurs de Ledger l’ont craint après la fuite de données de 2020 et les débats ultérieurs sur certaines fonctionnalités du produit.
Documentez chaque signataire dans une fiche d’une page : adresse, modèle de hardware wallet et version du firmware, emplacement physique de l’appareil, emplacement physique de la sauvegarde de la seed, contact principal et suppléant désigné sachant comment récupérer ce signataire si le contact principal est injoignable. Stockez ce document dans un emplacement chiffré auquel chaque signataire peut accéder, mais qui ne se trouve pas sur le même appareil qu’un signataire.
Étape 4 : rédigez le plan de récupération avant d’alimenter le Safe
La récupération est la partie que les gens sautent, et c’est celle qui détermine si un multisig est un système de sécurité ou une bombe à retardement au ralenti. Trois scénarios nécessitent des plans explicites : un signataire perd son appareil, la phrase de récupération d’un signataire est compromise, et deux signataires ou plus sont simultanément injoignables.
Pour un seul appareil perdu, la réponse est simple : les N moins 1 signataires restants sont encore au-dessus du seuil, le wallet continue donc de fonctionner. Le signataire perdu doit être remplacé. Cela signifie générer une nouvelle clé sur un hardware wallet neuf, puis ajouter la nouvelle adresse au Safe tout en supprimant l’ancienne. C’est une transaction Safe en soi, signée par M des signataires existants, et c’est l’opération de récupération la plus importante que vous exécuterez. Entraînez-vous sur un Safe de test avant de le faire pour de vrai.
Pour une seule seed compromise, la situation est plus urgente. Déplacez immédiatement les fonds hors du Safe vers un nouveau Safe avec de nouveaux signataires, signé par les signataires non compromis. Le temps compte, car l’attaquant possède désormais l’une des M clés requises. Si votre seuil était 3-sur-5 et qu’un seul signataire est compromis, vous pouvez encore déplacer les fonds, mais vous devez le faire avant que l’attaquant ne réunisse les deux autres. Traitez la compromission d’une seed comme un incendie.
Pour deux signataires ou plus injoignables, vous testez la limite de votre redondance N moins M. Si votre seuil est 3-sur-5 et que deux signataires ont disparu, le wallet fonctionne encore avec les trois restants. Si trois ont disparu, le wallet est bloqué. C’est pourquoi le problème de récupération est en réalité un problème de conception avant lancement. Soit vous avez choisi un M qui vous donne assez de redondance pour survivre à des pertes réalistes, soit ce n’est pas le cas. Aucun logiciel ne peut corriger cela après coup.
Certaines équipes ajoutent une couche de « guardian » ou de récupération sociale par-dessus le multisig, dans laquelle un ensemble distinct de parties de confiance peut aider à récupérer l’accès après un délai. C’est une conception différente qui mérite d’être envisagée pour les wallets personnels, mais pour les trésoreries d’organisation, la discipline du multisig pur l’emporte généralement sur la complexité des schémas hybrides.
Étape 5 : créez un guide opérationnel et entraînez-vous à signer
Le multisig ne vous protège que si vos signataires font réellement ce qu’il faut à chaque fois. Cela nécessite un guide écrit qui couvre : la manière dont une transaction est proposée, la manière dont elle est examinée, la manière dont chaque signataire la vérifie sur son appareil, la manière dont il la signe, la manière dont elle est exécutée et la manière dont le résultat est consigné. Chaque signataire doit lire le guide avant sa première transaction et le relire chaque année.
L’examen des transactions est l’étape la plus sous-estimée. Chaque signataire doit regarder la destination réelle on-chain, le montant réel, le contrat réellement appelé et le sélecteur de fonction réel. La plupart des exploits Safe de ces dernières années n’ont pas été des piratages de protocole ; il s’agissait d’attaques d’ingénierie sociale où un signataire a approuvé une transaction malveillante parce qu’il faisait confiance à la personne qui l’avait proposée ou parce qu’il a survolé l’interface du portefeuille. Les hardware wallets affichent les adresses de destination et les montants sur leurs propres écrans, ce qui constitue la fonctionnalité de sécurité la plus utile pour le multisig : l’appareil lui-même, et non l’ordinateur portable, est la source de vérité.
Organisez des exercices de signature. Proposez une transaction sans effet ou une petite transaction de test chaque trimestre et parcourez tout le flux M-of-N. Cela peut sembler tatillon, mais cela fait apparaître des problèmes que vous découvririez sinon en situation d’urgence : un signataire dont le firmware de l’appareil n’est pas à jour, un signataire qui voyage sans son hardware wallet, un signataire qui n’a jamais appris la procédure. Les exercices créent aussi des réflexes, de sorte que sous pression, lors d’un piratage en cours, d’un krach de marché ou d’une échéance, l’équipe puisse exécuter rapidement sans erreurs.
Checklist avant le lancement : tout ce qui doit être vrai avant d’alimenter le Safe
- Seuil et ensemble de signataires : M et N sont choisis, consignés par écrit et approuvés par chaque signataire.
- Indépendance des signataires : chaque signataire est une personne différente, utilise un fournisseur de hardware différent, se trouve dans un lieu physique différent et dispose de sauvegardes dans un autre bâtiment.
- Stockage de la seed : la seed phrase de chaque signataire est sur papier ou sur métal, et non dans un système numérique, avec au moins une copie hors site.
- Déploiement du Safe : l’adresse du contrat est vérifiée par rapport à la liste officielle de déploiement de Safe pour la chaîne et la version choisies.
- Test de bout en bout : un petit dépôt et un petit retrait ont été signés par les M signataires requis et exécutés avec succès.
- Exercice de récupération : un Safe de test a eu un signataire remplacé via la procédure Safe standard, prouvant que l’équipe peut faire tourner les signataires sans difficulté.
- Guide rédigé : un document unique décrit comment proposer, examiner, signer et exécuter les transactions, et chaque signataire l’a lu.
- Plan en cas de compromission : l’équipe a convenu à l’avance de la manière de réagir à une seed compromise, y compris l’adresse d’un Safe de secours « escape hatch » pré-déployé.
- Canaux de communication : des canaux sécurisés hors bande, Signal, Keybase ou en personne, sont convenus pour la coordination d’urgence, afin qu’un e-mail compromis ne puisse pas être utilisé pour manipuler les signataires par ingénierie sociale.
Comment suivre intelligemment l’actualité du multisig
Les configurations multisig sont conçues pour durer, mais l’écosystème qui les entoure évolue vite : Safe publie des mises à niveau, les fournisseurs de hardware déploient des mises à jour de firmware, de nouvelles vulnérabilités de contrats sont divulguées et les pratiques de gouvernance DAO évoluent. Suivre tout cela manuellement est une bataille perdue. Zippfeed fait remonter les gros titres sur le multisig et la self-custody avec un score de sentiment, bullish, neutral ou bearish, et une note d’importance, afin que vous puissiez repérer les changements de gouvernance, les conclusions d’audit et les exploits majeurs avant qu’ils n’affectent votre trésorerie.
