La self-custody commence souvent comme une question individuelle : conserver une seed, utiliser un hardware wallet et vérifier ses transactions. Dès que plusieurs personnes doivent gérer un treasury, une infrastructure ou des actifs appartenant à une organisation, le problème change de nature.
La sécurité ne dépend plus uniquement de la protection des clés. Elle dépend de qui peut décider, qui peut exécuter, qui peut contrôler et ce qui se passe lorsque l’organisation change.
À ce stade, la self-custody devient un sujet de gouvernance.
Une clé privée ne définit pas un rôle métier
Une organisation peut disposer d’un multisig 2-sur-3 et rester incapable d’expliquer clairement les responsabilités de chaque signataire.
Détenir une clé peut donner la capacité technique de signer, mais cela ne dit pas :
- qui est autorisé à initier une dépense ;
- quels montants nécessitent une approbation supplémentaire ;
- qui vérifie le bénéficiaire ;
- qui peut ajouter ou retirer un signataire ;
- qui déclenche une procédure d’urgence.
La gouvernance commence lorsque les capacités cryptographiques sont reliées à des responsabilités explicites.
Séparer demande, approbation et signature
Pour une petite équipe, une même personne peut cumuler plusieurs rôles. Mais plus la valeur et le nombre d’intervenants augmentent, plus la séparation devient utile.
Un modèle simple distingue :
- le demandeur, qui explique pourquoi une opération est nécessaire ;
- le préparateur, qui construit la transaction ;
- l’approbateur, qui valide le contexte et les règles ;
- le signataire, qui exerce le pouvoir cryptographique.
Ces fonctions peuvent parfois être regroupées, mais leur distinction permet de savoir où se situe réellement le contrôle.
Un multisig n’assure pas automatiquement cette séparation. Trois personnes peuvent posséder une clé tout en s’appuyant sur la même demande non vérifiée.
Définir des niveaux de risque plutôt qu’une règle unique
Toutes les transactions ne nécessitent pas la même gouvernance.
Une organisation peut définir des seuils :
- opérations courantes de faible montant ;
- transferts inhabituels ;
- mouvements vers une nouvelle adresse ;
- interactions avec un nouveau smart contract ;
- changement de signataire ;
- modification du quorum ;
- opération d’urgence.
Le niveau d’approbation, le nombre de vérifications et le délai peuvent évoluer selon le risque.
Cette approche évite deux extrêmes : une procédure si légère qu’elle n’apporte aucun contrôle, ou un système si lourd que les équipes créent des contournements.
Le quorum est une décision de gouvernance
Choisir 2-sur-3, 3-sur-5 ou un autre seuil n’est pas seulement un paramètre cryptographique.
Le quorum détermine :
- combien de personnes peuvent bloquer une opération ;
- combien de clés peuvent être perdues ;
- combien de personnes doivent coopérer pour détourner les fonds ;
- comment l’organisation fonctionne pendant les congés ou absences ;
- quel niveau de coordination est nécessaire en urgence.
Un quorum très élevé peut réduire le risque d’abus tout en augmentant le risque d’indisponibilité. Un quorum trop faible peut rendre la séparation des pouvoirs théorique.
L’architecture doit donc refléter la réalité opérationnelle de l’organisation.
Prévoir l’arrivée et le départ des signataires
Les équipes changent. Une architecture qui ne sait pas gérer cette évolution accumule progressivement du risque.
Lorsqu’une personne rejoint le dispositif, il faut définir :
- comment sa clé est générée ;
- quelles responsabilités elle reçoit ;
- quelle formation est nécessaire ;
- quelles informations elle doit posséder.
Lorsqu’elle quitte l’organisation, il faut savoir si sa clé doit être retirée, si un nouveau wallet est nécessaire et quelles permissions externes doivent être révoquées.
La rotation des clés doit être considérée comme une capacité du système, pas comme un événement exceptionnel impossible à exécuter.
Les permissions existent au-delà du wallet principal
Une gouvernance crypto sérieuse ne s’arrête pas au treasury.
Il faut inventorier les autres pouvoirs :
- rôles d’administration sur des smart contracts ;
- clés de déploiement ;
- comptes d’exchange ;
- accès aux dashboards et fournisseurs RPC ;
- clés de validator ou d’opérateur ;
- DNS et domaines ;
- dépôts de code et pipelines de déploiement ;
- comptes permettant de modifier les paramètres de sécurité.
Une organisation peut avoir un multisig parfaitement conçu tout en laissant une clé d’administration critique dans un navigateur personnel.
Rendre les décisions auditables sans exposer les secrets
La gouvernance nécessite une trace : qui a demandé l’opération, qui l’a approuvée, quel était le montant, quelle adresse a été vérifiée et quelle règle s’appliquait.
Cette traçabilité ne doit pas contenir les seeds, passphrases ou autres secrets.
Le bon journal décrit les décisions et les preuves de contrôle, pas le matériel permettant de signer.
Cette séparation permet d’analyser un incident, d’améliorer les procédures et de transmettre les responsabilités sans créer une nouvelle copie des clés.
Prévoir un mode d’urgence sans créer de super-clé cachée
Les procédures normales peuvent devenir trop lentes lors d’un incident réel. Il est donc raisonnable de prévoir une gouvernance d’urgence.
Mais une « clé de secours » détenue par une seule personne peut annuler toute la sécurité du modèle normal.
Une procédure d’urgence doit elle aussi définir :
- les conditions de déclenchement ;
- les personnes autorisées ;
- le niveau de quorum ;
- les actions permises ;
- la durée de l’exception ;
- le contrôle effectué après l’incident.
L’urgence doit réduire le temps de décision, pas supprimer toute responsabilité.
Organiser la continuité au-delà des personnes actuelles
Une organisation doit pouvoir continuer si un signataire est absent, si un dirigeant quitte son poste ou si une personne clé devient indisponible durablement.
Cela implique des sauvegardes, mais aussi une documentation du système, des procédures de remplacement et une compréhension partagée des rôles.
Pour les actifs à vocation patrimoniale, cette continuité peut également rejoindre les questions de transmission. La technique doit alors s’articuler avec le cadre juridique approprié sans chercher à le remplacer.
La gouvernance doit rester utilisable
Un système théoriquement parfait mais impossible à exploiter finit généralement par être contourné.
La maturité consiste à trouver un équilibre entre :
- séparation des responsabilités ;
- vitesse opérationnelle ;
- capacité de récupération ;
- niveau de contrôle ;
- simplicité suffisante pour que les règles soient réellement suivies.
La gouvernance crypto n’est donc pas une couche administrative ajoutée après la sécurité. Elle fait partie de la sécurité.
Construire une architecture qui reflète l’organisation
Une architecture de custody devrait représenter les responsabilités réelles de l’organisation, et non forcer l’organisation à s’adapter à un outil choisi par défaut.
GLOV Secure accompagne la structuration technique des accès, sauvegardes, multisigs et procédures dans une logique non-custodial. Pour les projets qui doivent également clarifier leur organisation, leurs responsabilités et leurs choix d’infrastructure, GLOV Consulting peut intervenir sur le cadrage global.
GLOV Solutions ne fournit pas de conseil juridique, fiscal ou financier. L’objectif est de rendre les pouvoirs techniques explicites, contrôlables et transmissibles sans déléguer la custody des actifs.