Sécurité et gouvernance blockchain : des règles de contrôle pour garder la maîtrise des décisions sensibles.
Qui peut changer une règle, et qu'est-ce qui l'empêche de le faire seul ?
Privilèges, approbations, délais, procédures d'urgence, traçabilité : nous concevons les mécanismes qui encadrent l'administration et l'évolution de vos composants blockchain, selon vos risques et vos responsabilités.
Illustration en six étapes. 1. Une opératrice, rôle « proposant », propose de porter le plafond par opération de la plateforme fictive Coffre Atlas de 50 000 à 80 000 unités. 2. Son autorisation de proposer est vérifiée ; elle ne peut ni approuver ni exécuter sa proposition. 3. L'approbatrice A puis l'approbateur B approuvent : deux approbations sur deux requises ; l'approbateur C n'est pas sollicité. 4. L'exécutant vérifie les conditions : approbations réunies, délai prévu écoulé, valeur dans la limite autorisée. 5. Son autorisation d'exécuter est vérifiée, la modification est exécutée : le plafond passe à 80 000 unités. Jusque-là, il restait à 50 000. 6. Le résultat est inscrit au registre des décisions : ancienne et nouvelle valeur, auteurs, dates.
Une décision sous contrôle, en six étapes
Un contrat déployé garde souvent des pouvoirs, et chacun doit avoir un responsable identifié.
Un contrat ne se résume pas à son code. Il peut prévoir qu'une adresse modifie un plafond, suspende des opérations, change une source de données ou remplace une partie de la logique. Ces pouvoirs permettent de corriger, d'adapter, de réagir. Ils sont aussi une cible : une clé dérobée, une erreur de manipulation ou une décision prise seul peuvent avoir les mêmes effets qu'une faille.
Modifier un paramètre
Ce qu'il permet : Plafond, frais, seuil, durée de validité.
Ce qu'il faut décider : Qui propose, qui approuve, dans quelles limites ?
Changer une adresse
Ce qu'il permet : Destination des fonds, contrat associé, source d'une donnée transmise par un oracle.
Ce qu'il faut décider : Quelles vérifications avant d'appliquer, et quel délai ?
Suspendre des opérations
Ce qu'il permet : Arrêter des dépôts, des transferts, une émission.
Ce qu'il faut décider : Qui peut suspendre, quoi exactement, et qui peut reprendre ?
Attribuer ou retirer un rôle
Ce qu'il permet : Désigner un nouvel approbateur, retirer un accès, ou geler un actif émis par tokenisation.
Ce qu'il faut décider : Qui contrôle ceux qui distribuent les pouvoirs ?
Remplacer une logique
Ce qu'il permet : Mettre à jour un contrat, si un mécanisme de remplacement a été prévu à la conception.
Ce qu'il faut décider : Avec quelles approbations, quel délai, quelle vérification ?
Nous recensons ces pouvoirs avec vous, dès l'architecture, puis nous décidons qui peut les exercer, à quelles conditions, et ce qui reste visible de chaque décision. Les droits de vos collaborateurs dans vos applications relèvent d'une autre discipline : l'authentification et la gestion des accès.
Qui peut modifier quoi ? Une règle de gouvernance ne se résume pas à un nombre de signatures.
La même modification, le plafond par opération de Coffre Atlas, sous quatre configurations. Choisissez-en une, simulez les approbations et, le cas échéant, la situation après le délai : voyez ce qui reste bloquant et qui doit intervenir ensuite. Scénario fictif : aucune clé, aucune signature, aucune transaction réelles.
SimulerActivez ou retirez les approbations pour simuler la décision des approbateurs.
Statut de l'opération
En attente d'approbations
- Qui peut proposer
- L'opératrice, rôle « proposant »
- Qui peut approuver
- Trois approbateurs désignés : A, B et C
- Approbations nécessaires
- 2 sur 3 · aucune obtenue
- Conditions satisfaites
- proposition déposée rôle « proposant » vérifié
- Conditions bloquantes
- approbations insuffisantes
- Exécution possible
- ✕ Non : il manque 2 approbations
- Qui doit intervenir ensuite
- Un autre approbateur
- Plafond en vigueur
- 50 000 unités : rien n'a été exécuté
- Ce qui est enregistré
- La proposition et son autrice
Ce que ce modèle apporte
Une décision qui ne dépend plus d'une seule personne : une approbation ne suffit pas, il en faut deux sur trois.
Ce qu'il ne garantit pas
Que les signataires soient indépendants, ni que leur décision soit la bonne. Une approbation n'est pas une exécution.
Les quatre modèles, et ce qu'ils permettent :
A. Une seule personne habilitée
- Exécutable immédiatement par la personne habilitée, dans la limite autorisée, sans aucun contrôle par un tiers.
- Ce que ce modèle apporte : La simplicité et la rapidité, adaptées à un composant peu sensible, à une phase de test, ou à une responsabilité clairement assumée par une personne.
- Ce qu'il ne garantit pas : Aucun contrôle par un tiers : une erreur ou une clé compromise suffit à modifier le paramètre.
B. Multisignature
- Exécutable seulement avec deux approbations sur trois ; une seule ne suffit pas. Une approbation n'est pas une exécution.
- Ce que ce modèle apporte : Une décision qui ne dépend plus d'une seule personne : une approbation ne suffit pas, il en faut deux sur trois.
- Ce qu'il ne garantit pas : Que les signataires soient indépendants, ni que leur décision soit la bonne. Une approbation n'est pas une exécution.
C. Multisignature et délai
- Deux approbations sur trois, puis le délai prévu, qui ne commence qu'une fois les approbations réunies.
- Ce que ce modèle apporte : Un temps de réaction : pendant le délai, la modification annoncée peut être examinée, et annulée si le mécanisme le prévoit.
- Ce qu'il ne garantit pas : Un délai ne remplace pas les approbations, et ne sert que si quelqu'un examine les modifications annoncées.
D. Opération non autorisée
- Refusée avant toute approbation : aucune approbation ni aucun délai ne la rendent exécutable.
- Ce que ce modèle apporte : Une séparation nette : un compte sans rôle ne peut ni proposer, ni approuver, ni exécuter.
- Ce qu'il ne garantit pas : Que les rôles soient bien attribués : une permission mal donnée reste une permission.
Plusieurs façons de décider, à choisir selon vos risques et vos responsabilités.
Certains mécanismes sont techniques et s'appliquent sur la chaîne ; d'autres relèvent de l'organisation ou du contrat. Ils se combinent, et aucun ne s'impose à tous les projets.
Mécanismes techniques, sur la chaîne
Un rôle d'administration unique
Ce qu'il apporte : Simple, rapide, cohérent avec une responsabilité clairement attribuée.
Ses limites : Tout repose sur une personne et sur la protection de sa clé.
Approbations multiples (multisignature)
Ce qu'il apporte : Aucune opération sensible n'est possible avec une seule clé.
Ses limites : Ne garantit ni l'indépendance des signataires, ni la justesse de leur décision ; plus lent en urgence.
Délai avant application
Ce qu'il apporte : Laisse le temps de voir une décision annoncée et d'y réagir.
Ses limites : Ne remplace pas les approbations ; retarde aussi les corrections urgentes.
Vote d'une communauté (DAO)
Ce qu'il apporte : Ouvre la décision aux détenteurs d'un droit de vote.
Ses limites : Pas toujours nécessaire, pas automatiquement démocratique : le poids des votes dépend de leur répartition. Elle ajoute ses propres risques.
Gouvernance organisationnelle et contractuelle
Procédures et responsabilités internes
Ce qu'il apporte : Qui détient quelle clé, qui la remplace, qui décide en cas d'incident : écrit et connu des équipes.
Ses limites : N'empêche rien techniquement à lui seul.
Engagements entre partenaires
Ce qu'il apporte : Rattache les décisions prises sur la chaîne à des engagements contractuels.
Ses limites : Se définit avec vos conseils ; ne remplace pas un contrôle technique.
Un projet n'a pas besoin de tous ces mécanismes. Le bon dispositif est celui que vos équipes peuvent tenir dans la durée. Les signatures de vos utilisateurs, elles, relèvent des wallets et intégrations Web3 ; les pouvoirs d'administration d'une application décentralisée se décident ici.
Faire évoluer un contrat se prévoit avant son déploiement, pour garder une marge de correction sans fragiliser l'ensemble.
Ce qui peut évoluer après le déploiement, et à quelles conditions, se décide à la conception. Après, il est souvent trop tard.
Ce qui peut changer
Les paramètres prévus pour l'être, et la logique si un mécanisme de remplacement a été conçu pour cela. Le reste ne change pas : la façon dont ces mécanismes s'écrivent relève du développement de smart contracts.
Ce que chaque mécanisme crée
Un pouvoir supplémentaire : quelqu'un le détient, avec ou sans approbations, avec ou sans délai. Il doit être protégé comme tel.
Renoncer à modifier
C'est aussi un choix : des règles figées inspirent confiance, mais une correction impose alors de déployer un nouveau contrat et d'organiser la migration.
Vérifier une évolution
Chaque mise à jour est relue, testée sur un réseau de test, approuvée selon la règle prévue, puis inscrite avec sa justification.
Prévoir l'incident avant qu'il arrive, pour réagir sans improviser des pouvoirs qui n'existent pas.
En cas d'incident, on ne peut utiliser que les mécanismes prévus. Ce qui n'a pas été conçu ne peut pas être ajouté dans l'urgence.
Suspension d'urgence
Qui peut suspendre, quoi exactement, ce qui reste possible pendant la pause, comme les retraits, et qui décide de la reprise.
Clé perdue
Avec une seule clé d'administration, le pouvoir peut être perdu définitivement. Avec plusieurs approbateurs, les autres peuvent en remplacer un, si la règle le prévoit.
Clé compromise
Des plafonds et des délais limitent ce qu'un attaquant peut faire ; la remplacer suppose une procédure décidée à l'avance. Rien ne garantit de tout récupérer.
Traçabilité
Chaque proposition, approbation, exécution ou refus laisse une trace consultable : qui, quoi, quand, avec quelle justification.
La surveillance des opérations et la réponse aux incidents font partie du périmètre convenu, jamais d'une option implicite.
Préparer l'audit d'un smart contract, pour faire vérifier aussi qui peut le modifier.
Nous ne réalisons pas d'audit, et aucun n'est inclus d'office. Lorsque votre projet en justifie un, nous documentons ce que l'auditeur doit pouvoir examiner au-delà du code : les rôles et les privilèges, les opérations sensibles, les règles d'approbation et de délai, les mécanismes d'évolution et les procédures d'urgence. L'audit est mené par un cabinet spécialisé indépendant, dans un périmètre distinct.
La relecture du code et la répartition des rôles autour d'un audit sont décrites avec la méthode de sécurité des smart contracts. L'audit d'applications web et d'API est une autre démarche : l'audit de sécurité web.
- Inventaire des rôles et des privilèges
- Opérations sensibles et règles d'approbation
- Mécanismes d'évolution et procédures d'urgence
Questions fréquentes
Ce que l'on nous demande avant de décider qui pourra administrer et faire évoluer une solution blockchain.
Pourquoi prévoir une gouvernance pour un projet blockchain ?
Parce que la plupart des projets conservent des pouvoirs après le déploiement : modifier un paramètre, suspendre des opérations, désigner un responsable. Sans règle écrite, ces pouvoirs reposent sur une personne ou une clé. Une gouvernance dit qui peut les exercer, avec quelles vérifications, et ce qui en reste visible.
À quoi sert une multisignature ?
À exiger plusieurs approbations avant une opération sensible : avec une règle de deux sur trois, une seule clé ne suffit pas. Elle ne garantit pas que les signataires soient indépendants ni que leur décision soit la bonne, et elle ralentit les réactions en urgence. Elle n'est pas nécessaire pour tous les composants.
Qui doit pouvoir décider d'une évolution d'un contrat déjà déployé ?
Ceux que la règle désigne avant le déploiement : une personne qui propose, d'autres qui approuvent, parfois un délai avant l'application. L'évolution n'est possible que si un mécanisme l'a prévue ; ce point technique relève du développement de smart contracts. La gouvernance, elle, fixe qui décide et comment la décision est vérifiée.
Comment limiter les pouvoirs d'un administrateur ?
En séparant proposer, approuver et exécuter, en fixant des plafonds et des délais, en réduisant le périmètre d'une suspension d'urgence et en inscrivant chaque décision. Sur la chaîne, un privilège ne se retire pas comme un compte d'application : il se prévoit dans le contrat.
Que se passe-t-il si une clé d'administration est perdue ou compromise ?
Cela dépend de ce qui a été prévu. Si plusieurs approbateurs existent, les autres peuvent remplacer la clé selon la règle ; des plafonds et une suspension limitent les dégâts. Sans procédure prévue, le pouvoir peut être perdu ou détourné. Aucune récupération n'est garantie.
Faut-il créer une DAO pour gouverner son projet ?
Pas nécessairement. Une DAO convient quand une communauté doit réellement décider. Elle n'est pas automatiquement démocratique, car le poids des votes dépend de leur répartition, et elle ajoute ses propres risques. Beaucoup de projets n'ont besoin que de rôles clairs et d'approbations multiples pour les opérations sensibles.
Avant de déployer vos contrats, nous définissons les pouvoirs, pour qu'une décision sensible reste vérifiable.
Le cadrage des pouvoirs
Qui décide ?
ce qu'il faut protéger
- Composants administrables
- Quels contrats, quels services peuvent encore être modifiés, et lesquels sont figés ?
- Paramètres critiques
- Plafonds, adresses, frais, listes : lesquels ont des conséquences sensibles ?
Qui contrôle ?
les personnes et les rôles
- Rôles habilités
- Qui propose, qui approuve, qui exécute, et qui ne doit jamais cumuler ces rôles ?
- Approbations
- Combien d'approbations, par qui, et pour quelles opérations ?
Qui exécute ?
et sous quelles conditions
- Conditions de modification
- Délais, limites, vérifications : que faut-il réunir avant d'exécuter ?
- Procédures d'urgence
- Qui peut suspendre ou limiter, quoi exactement, et comment reprendre ?
Comment vérifier ?
dans la durée
- Traçabilité des décisions
- Que garde-t-on de chaque proposition, approbation et exécution ?
- Évolutions et maintenance
- Comment remplacer un accès, faire évoluer un contrat, ou décider de ne plus rien modifier ?
Le premier échange sert à établir qui décide, qui contrôle, qui exécute, et comment une décision peut être vérifiée.
Le cadrage précède le déploiement : une fois un contrat en service, ses règles de gouvernance ne se changent que si elles ont été prévues. Le dispositif retenu dépend de vos risques, de vos responsabilités et du périmètre convenu.
Étudions la gouvernance de votre projetUn audit spécialisé, s'il est nécessaire, se mène dans un périmètre distinct, par un intervenant indépendant.
Les mêmes questions se posent pour un actif tokenisé dans l'immobilier ou pour un protocole de finance décentralisée.