--- title: "Portefeuille multi-signatures" description: "Découvrez comment un portefeuille multi-signatures M-of-N répartit l'autorité de transaction, les différences entre multisig par script et par contrat intelligent, et les risques persistants liés aux signataires, à l'exécution, aux modules et à la récupération." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Portefeuille multi-signatures > À des fins éducatives uniquement ; ne constitue pas un conseil en investissement, en conservation, juridique ou en sécurité. Un multisig peut encore perdre des fonds ou devenir inutilisable à cause de signataires compromis, de transactions malveillantes, de modules dangereux, de défauts du contrat ou de la perte du quorum. Les transactions d'actifs numériques peuvent être irréversibles. ## Réponse directe Un portefeuille multi-signatures, ou multisig, contrôle un compte ou une sortie dépensable par une règle exigeant au moins M approbations parmi N clés publiques ou comptes propriétaires autorisés. Une règle 2-of-3 accepte par exemple deux autorités valides quelconques sur un ensemble de trois. Une clé privée n'est ainsi plus le seul point de contrôle, mais toute transaction approuvée ne devient pas sûre pour autant. Le multisig conventionnel ne divise pas une clé privée entre les signataires. Chacun contrôle normalement sa propre clé ou son propre compte, et le script ou contrat vérifie plusieurs approbations. Les systèmes de signature à seuil ou MPC peuvent au contraire produire une signature à partir de parts de clé distribuées ; leur apparence on-chain et leur modèle de confiance diffèrent. L'implémentation est déterminante. Bitcoin peut imposer des conditions de dépense multi-signatures dans les scripts de transaction. Sur Ethereum et les réseaux programmables similaires, un multisig courant est un compte de contrat dont le code définit les propriétaires, le seuil, les règles d'exécution et les extensions éventuelles. Contrairement à un compte externe, un compte de contrat est contrôlé par son code, pas par une seule clé privée. Le seuil M-of-N exprime les limites de compromission et de disponibilité. Une configuration 3-of-5 continue de fonctionner si deux autorités sont indisponibles, mais trois autorités valides quelconques peuvent approuver une dépense. Des adresses distinctes ne sont pas indépendantes si une même personne, un administrateur d'appareils, un compte cloud, un lieu de sauvegarde ou un dépositaire peut en contrôler assez. ## Fonctionnement 1. **Vérifier l'autorité avant la proposition.** Confirmez le réseau et le compte ou la sortie, puis inspectez le script ou contrat déployé, les propriétaires, le seuil, les règles de nonce ou de séquence, ainsi que chaque module, guard, fallback handler, voie de récupération et autorité de mise à niveau pouvant exécuter ou bloquer des transactions. 2. **Construire et décoder la demande exacte.** Vérifiez la destination, l'actif, la valeur, les calldata ou le script, le type d'opération, le nonce, les frais et le contenu des lots. Simulez les appels complexes avec des outils fiables et veillez à ce que chaque signataire examine ce que la signature autorise réellement, plutôt qu'un libellé d'interface. 3. **Recueillir les approbations dans des domaines de contrôle indépendants.** Les signataires vérifient le même condensé de transaction sur des appareils de confiance et communiquent par des canaux authentifiés. Aucun processus légitime ne demande une phrase de récupération ou une clé privée. 4. **Exécuter la demande approuvée.** Atteindre le seuil peut seulement rendre la proposition exécutable. Un exécutant doit encore la diffuser ou la soumettre et éventuellement payer des frais réseau. Un nonce obsolète, une proposition concurrente, un changement d'état, des frais insuffisants ou un appel en échec peuvent empêcher l'exécution. 5. **Vérifier l'achèvement depuis l'état de la chaîne.** Attendez la politique de confirmation requise, inspectez le payload exécuté et son résultat, puis confirmez au besoin les soldes, la configuration des propriétaires et les événements. Réévaluez les propositions en attente après toute modification de propriétaire, seuil, module ou politique. ## Exemple Une trésorerie emploie un compte intelligent multisig 3-of-5 avec les propriétaires A, B, C, D et E dans des domaines de contrôle séparés. Pour un paiement de 10,000 USDC, la proposition consigne le bon réseau, le compte, le bénéficiaire, le contrat du jeton, le montant, les calldata, le nonce et la politique de frais. A, C et E décodent indépendamment la même demande avant de l'approuver. Ces approbations seules ne déplacent pas les fonds. Un exécutant soumet la transaction ; après confirmation, l'équipe vérifie son résultat et le solde de la trésorerie, plutôt que de se fier à une notification de l'interface. Proposition, approbations, hachage et preuves de contrôle sont conservés comme piste d'audit. Si la clé de B est ensuite suspectée d'être compromise, le quorum restant non compromis suit la procédure de rotation des propriétaires du compte déployé et vérifie l'ensemble final on-chain. L'équipe contrôle aussi les propositions en attente, modules, allocations, droits de récupération et autres chaînes, car retirer B n'annule pas les transactions passées ni les droits accordés par une autre voie. ## Risques et contrôles - **Conservation corrélée.** Plusieurs clés peuvent échouer ensemble si elles partagent une personne, un appareil, un coffre de mots de passe, un administrateur, un lieu, un fournisseur ou un secret de récupération. Cartographiez les domaines et testez la récupération sans centraliser assez d'autorité pour atteindre le seuil. - **Payload malveillant ou mal compris.** Un quorum valide peut approuver fidèlement une adresse d'attaquant, une autorisation illimitée de jetons, un delegate call ou un lot nuisible. Décodez et vérifiez indépendamment toute la demande ; la simulation est un indice, pas une garantie. - **Perte ou retard du quorum.** Clés perdues, personnes indisponibles, litiges, pannes réseau ou seuil trop élevé peuvent bloquer une urgence ou verrouiller définitivement les actifs. Maintenez des contacts authentifiés, une succession documentée, des sauvegardes testées et une conception explicite de récupération. - **Autorité cachée ou de contournement.** Modules, guards, fallback handlers, session keys, relayers, contrats de récupération et administrateurs de mise à niveau peuvent contourner le seuil ordinaire ou empêcher son exécution. Inventoriez ces voies et traitez tout changement d'autorisation comme une transaction à haut risque. - **Risque de contrat et de déploiement.** Bogues, initialisation dangereuse, erreurs de proxy ou de mise à niveau et déploiement sur le mauvais réseau peuvent ruiner la politique prévue. Vérifiez adresses et code, évaluez les audits dans leur contexte, limitez les extensions et surveillez la configuration. - **Course après compromission et départ incomplet.** Un signataire compromis peut agir avant la confirmation de son retrait, lequel n'annule ni les actions exécutées ni les droits externes. Appliquez un plan d'incident, surveillez l'état en continu et révoquez séparément les accès organisationnels et on-chain. ## Idées reçues - **« Plus de signataires signifie toujours plus de sécurité. »** Un ensemble plus grand peut réduire la concentration, mais augmente les risques de coordination, de phishing et de disponibilité. Choisissez propriétaires et seuil selon le modèle de menace et la capacité opérationnelle. - **« Un portefeuille 3-of-5 est contrôlé par cinq personnes indépendantes. »** La chaîne compte les clés ou comptes propriétaires valides, pas les personnes. Appareils, sauvegardes, administrateurs ou dépositaires partagés peuvent réunir des propriétaires nominalement distincts dans un même domaine. - **« Le multisig équivaut à l'authentification à deux facteurs ou au MPC. »** Ces modèles peuvent tous distribuer le contrôle, mais diffèrent par leurs identifiants, voies de vérification, preuves on-chain et hypothèses de récupération. - **« Dès que le seuil approuve, le transfert est terminé. »** Approbation, caractère exécutable, soumission, inclusion et confirmation sont des états distincts. La demande peut rester en attente ou échouer. - **« Le multisig empêche le vol et les exploits de contrats. »** Il ne limite que les voies d'autorité codées dans son implémentation. Un quorum valide, un module privilégié, un contrat vulnérable ou une récupération dangereuse peut encore causer une perte irréversible. ## Sujets connexes - [Gestion des clés privées](/fr/crypto/private-key-management/) - [Portefeuille MPC](/fr/crypto/mpc-wallet/) - [Rotation des signataires multisig](/fr/crypto/multisig-signer-rotation/) - [Risque des modules multisig](/fr/crypto/multisig-module-risk/) - [Simulation de transaction](/fr/crypto/transaction-simulation/) ## Sources - [BIP 11 : transactions standard M-of-N](https://bips.dev/11/) - Bitcoin Improvement Proposals (consulté le : 2026-08-21) - [Présentation de la technologie blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté le : 2026-08-21) - [Comptes Ethereum](https://ethereum.org/developers/docs/accounts/) - Ethereum.org (consulté le : 2026-08-21) - [Comment fonctionnent les comptes intelligents Safe ?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (consulté le : 2026-08-21) - [Modules Safe](https://docs.safe.global/advanced/smart-account-modules) - Safe Documentation (consulté le : 2026-08-21) - [Guards Safe](https://docs.safe.global/advanced/smart-account-guards) - Safe Documentation (consulté le : 2026-08-21) Source: https://wiki.fcontext.com/fr/crypto/multisig-wallet/index.mdx