Gouvernance on-chain : comment ça fonctionne et pourquoi c'est un enjeu de sécurité

Introduction

Dans la DeFi, les décisions ne sont pas prises par un PDG derrière des murs de verre. Elles sont votées par les holders de tokens de gouvernance. Uniswap déploie une nouvelle feature ? Vote on-chain. Aave augmente les réserves d'un protocole de collatéral ? Vote de la communauté. Compound change ses facteurs de risque ? Les gouverneurs décident.

C'est révolutionnaire. C'est transparent. C'est aussi l'un des vecteurs d'attaque les moins discutés et les plus lucratifs jamais exploités.

Pendant qu'on parle de sécurité des smart contracts, peu de DAO evaluent vraiment la sécurité de leur gouvernance elle-même. Et pourtant, une attaque de gouvernance peut vider la trésorerie en une transaction, comme l'a montré le hack de Beanstalk en 2022 (182 millions de dollars perdus).

Dans cet article, tu vas comprendre comment fonctionne la gouvernance on-chain, quels sont les vecteurs d'attaque critiques, et surtout : comment évaluer la sécurité réelle d'une DAO avant d'y participer ou d'y investir.

Qu'est-ce que la gouvernance on-chain ?

Deux modèles : on-chain vs off-chain

La gouvernance d'une DAO peut prendre deux formes radicalement différentes.

Gouvernance on-chain (smart contract)

• Exemple : Uniswap (UNI), Compound (COMP), Aave (AAVE)
• Fonctionnement : Les votes sont enregistrés directement sur la blockchain via une transaction
• Coût : Tu paies du gas pour voter (quelques euros à quelques dizaines d'euros selon la congestion du réseau)
• Exécution : Le résultat est automatiquement exécutable par le smart contract (via un timelock — on va en parler)
• Sécurité : Tout est transparent et enregistré de manière immuable
• Centralisation : Moins risquée (en théorie), mais coûteuse pour les petits holders

Gouvernance off-chain (Snapshot)

• Exemple : Snapshot.org utilisé par 1000+ protocoles
• Fonctionnement : Tu signes simplement un message (pas de transaction) pour voter. Aucun gas
• Coût : Gratuit (juste une signature)
• Exécution : Le résultat est appliqué manuellement par une multisig (portefeuille contrôlé par plusieurs signataires)
• Sécurité : Plus accessible mais moins décentralisé (il faut faire confiance aux signataires pour exécuter le vote)
• Utilisation : Idéale pour les votes non-critiques ou les sondages

Tableau comparatif : on-chain vs off-chain

Qu'est-ce qu'une DAO ?

Une DAO (Decentralized Autonomous Organization) est une organisation dont les règles sont encodées dans des smart contracts.

Au lieu d'une hiérarchie classique (CEO → directeurs → employés), une DAO fonctionne comme un système de votes :

• Les holders de tokens de gouvernance = actionnaires/votants
• Les propositions = les décisions à prendre
• Les smart contracts = l'exécution automatique

Exemples :

• Uniswap DAO : ~380k adresses possèdent UNI et peuvent voter
• Aave DAO : ~130k adresses avec des droits de vote
• MakerDAO : ~80k adresses avec du MKR

Ce que la gouvernance d'une DAO peut décider

La plupart des protocoles DeFi laissent leur gouvernance décider de :

• Mises à jour du protocole : changement d'algorithme, ajout de features
• Allocation de la trésorerie : subventions, primes de liquidité, développement
• Paramètres de risque : frais d'emprunt, facteurs de collatéral, limites de dépôt
• Ajout de nouveaux pools : nouvelles paires de trading, nouveaux marchés d'emprunt
• Changements de frais : frais de trading, frais d'emprunt, frais de compensation

Niveau de sécurité : Plus une décision est critique, plus il faut exiger de protections (timelock long, quorum élevé, délégation contrôlée).

Les mécanismes techniques de la gouvernance

Token de gouvernance

Le token de gouvernance est le fondement du droit de vote dans une DAO.

Caractéristiques clés :

• Proportionnalité : 1 token = 1 vote. Si tu possèdes 1% des tokens UNI en circulation, tu as 1% des votes
• Non-transfert de vote : Ton droit de vote est attaché au token. Si tu vends tes UNI, tu perds tes votes
• Immuabilité du solde : Le système capture un "snapshot" de ton solde à une hauteur de bloc donnée pour éviter les manipulations

Exemples majeurs :

• UNI (Uniswap) : 1 milliard de tokens, ~380k holders actifs
• COMP (Compound) : 10 millions de tokens, quorum de 65k COMP (~3.2% de la supply)
• MKR (MakerDAO) : 1 million de tokens, très concentré (~70% détenus par les top 10)
• AAVE (Aave) : ~16 millions de tokens, plus décentralisé que MakerDAO

Délégation de votes

Problème : Tu possèdes des tokens de gouvernance mais tu n'as pas le temps de voter sur chaque proposition ? T'es pas expert en smart contracts ? Tu peux déléguer tes votes.

Comment ça marche :

1. 1Tu appelles la fonction delegate() du smart contract du token
2. 2Tu fournis l'adresse d'une personne (ou entité) à qui tu délègues tes votes
3. 3À partir de ce moment, tes votes comptent pour elle automatiquement
4. 4Tu peux retirer la délégation à tout moment

Exemples de délégués populaires :

• Organisations de recherche (Consensys, OpenZeppelin)
• Figures publiques reconnues (Vitalik pour Ethereum governance)
• Multisigs communautaires
• Protocoles partenaires (Lido délègue à certains validateurs Ethereum)

Risque : Si tu délègues à quelqu'un d'incompétent ou malhonnête, il peut voter contre tes intérêts. Choisis ton délégué en fonction de :

• Son historique de votes
• Sa réputation communautaire
• Son transparence (fait-il des rapports sur ses votes ?)

Quorum

Le quorum est le seuil minimum de votes nécessaire pour qu'une proposition soit valide.

Pourquoi c'est important :

Si le quorum est trop bas, une minorité organisée peut contrôler la gouvernance. Si le quorum est trop élevé, aucune proposition ne passera jamais.

Exemples :

• UNI (Uniswap) : Quorum de 4% de la supply (~40 millions UNI)
• COMP (Compound) : 65,000 COMP (≈3.2% de la supply)
• MKR (MakerDAO) : 50,000 MKR (≈5% de la supply)

Règle empirique : Un quorum entre 3% et 10% est un bon équilibre. En dessous de 3%, la gouvernance devient capturable par une petite coalition.

Timelock

Le timelock est un délai obligatoire entre l'adoption d'une proposition et son exécution.

Exemple d'une proposition avec timelock de 48h :

1. 1Mercredi 10h : La proposition est votée et adoptée
2. 2Mercredi 10h → Vendredi 10h : Période d'attente (48h)
3. 3Vendredi 10h : Le contrat peut enfin exécuter la proposition

Pourquoi c'est critique pour la sécurité :

• Temps de réaction : Si tu remarques qu'une proposition malveillante va être exécutée, tu as 48h pour :

- Alerter la communauté

- Arrêter les fonds critiques

- Fork le protocole si nécessaire

• Prévention des flash loan attacks : Un attaquant ne peut pas emprunter des tokens de gouvernance, voter, et exécuter en une seule transaction si le timelock > 1 bloc

Normes de sécurité :

• Propositions critiques (changements du protocole, accès aux fonds) : 7 jours minimum
• Propositions modérées (paramètres, frais) : 48h minimum
• Propositions triviales (changements cosmétiques) : 24h

Governor Bravo et OpenZeppelin Governor

Governor Bravo est le standard de gouvernance on-chain créé par Compound et adopté par Uniswap.

OpenZeppelin Governor est sa version modernisée et modulaire, utilisée par les nouveaux protocoles.

Les deux permettent :

• Créer et voter des propositions
• Déléguer les votes
• Exécuter automatiquement les résultats
• Timelock intégré

Code exemple (OpenZeppelin Governor) :

contract GovernanceToken is ERC20Votes {
    // Token de gouvernance avec droits de vote
}

contract Governor is GovernanceGovernor {
    function votingDelay() public pure override returns (uint256) {
        return 1; // 1 bloc avant de pouvoir voter
    }

    function votingPeriod() public pure override returns (uint256) {
        return 50400; // 7 jours (50400 blocs)
    }

    function quorumNumerator() public view override returns (uint256) {
        return 4; // 4% de quorum
    }

    function proposalThreshold() public pure override returns (uint256) {
        return 65000e18; // 65k tokens pour proposer
    }
}

Les risques de centralisation et les vecteurs d'attaque

Concentration des tokens : le risque numéro 1

Problème : Si 5 wallets contrôlent 51% des votes, la "décentralisation" est une illusion.

Vérifier la concentration :

Pour chaque protocole, tu dois vérifier :

• Top 10 holders détiennent combien % ?
• Top 100 holders détiennent combien % ?
• Y a-t-il du staking ou du lock-up qui crée une concentration artificielle ?

Exemples concrets :

• UNI (Uniswap) : Top 10 holders = ~15% (relativement décentralisé)
• MKR (MakerDAO) : Top 10 holders = ~72% (très centralisé, risqué)
• AAVE : Top 10 holders = ~28% (modérément centralisé)

Drapeau rouge : Si un protocole a plus de 40% détenus par les top 10 holders, la gouvernance n'est pas vraiment décentralisée.

Governance attack via flash loan : Beanstalk 2022

C'est l'attaque de gouvernance la plus spectaculaire : 182 millions de dollars perdus en une transaction.

Contexte

Beanstalk était un protocole de stablecoin algorithmique qui gardait sa gouvernance on-chain. N'importe qui pouvait proposer une décision s'il avait suffisamment de tokens BEAN.

Les 5 étapes du hack

Étape 1 : Flash loan massif

• L'attaquant emprunte 80 millions d'USD de USDC via Aave (flash loan)
• Convertit en 80 millions de tokens BEAN via la courbe d'échange du protocole
• Coût : essentiellement 0$ (juste quelques centimes de frais de flash loan)

Étape 2 : Accumulation instantanée de votes

• Le smart contract de gouvernance capture le solde au bloc courant
• L'attaquant dispose maintenant de 80 millions de BEAN = 80 millions de votes
• Contrairement à une blockchain traditionnelle, il n'a pas besoin d'attendre 1 bloc pour "enregistrer" son solde

Étape 3 : Proposition malveillante

• L'attaquant crée une proposition permettant au soi-disant "Beanstalk Farms" de transférer 180M$ de USDC de la trésorerie
• Soumet une autre proposition pour se déclarer lui-même "Beanstalk Farms"
• Coût : quelques milliers de gas

Étape 4 : Vote et adoption

• Puisqu'il contrôle 80M de votes (plus que le quorum), la proposition passe instantanément
• Timelock était très court (0 blocs pour une proposition d'urgence)

Étape 5 : Exécution et vol

• Le smart contract exécute la proposition
• 180M$ sont transférés vers l'adresse de l'attaquant
• L'attaquant rembourse le flash loan (quelques centimes de frais)
• Profit net : ~180M$

Graphique du déroulement temporel

Bloc N : Emprunter 80M USDC (flash loan)
         ↓ Convertir en BEAN
         ↓ Voter 2 propositions malveillantes
         ↓ Exécuter propositions
         ↓ Transférer 180M$ de trésorerie
         ↓ Rembourser flash loan
         ↓ Attaquant conserve 180M$

Tout en une seule transaction (13 secondes).

Contre-mesures essentielles

Pour éviter un hack Beanstalk :

1. 1Timelock ≥ 7 jours : Même si tu empruntes des tokens, tu ne peux pas exécuter avant une semaine
2. 2Excluder les flash loans : Le smart contract note le bloc précédent comme "référence" pour compter les votes, pas le bloc courant
3. 3Proposer avec du BEAN stacké : Nécessiter que le proposant bloque ses tokens pour proposer (pénalité économique)
4. 4Threshold de proposition : Exiger un minimum de 65k tokens (ex: Compound) pour simplement créer une proposition

Beanstalk aurait probablement survécu avec juste un timelock de 48h.

Voter apathy : le risque silencieux

Problème : Beaucoup de DAOs fixent des quorums si élevés que peu de propositions atteignent le seuil. Résultat : les votes qui passent sont ceux d'une minorité très organisée.

Exemple réel :

• Quorum requis : 10% de la supply
• Taux de participation historique : 3% seulement
• Résultat : Aucune proposition normale n'a jamais passé, sauf celles soutenues par des whales
• Les petits holders sont démoralisés et arrêtent de voter

Comment détecter ce problème :

• Vérifier le taux de participation moyen des votes
• Voir si seulement 1–2 adresses votent régulièrement
• Analyser si les propositions proviennent toujours des mêmes sources

Centralisation des clés admin multisig

Beaucoup de "DAO" gardent secrètement des clés multisig (portefeuille à signatures multiples) qui peuvent override les votes de la gouvernance.

Exemple :

• Aave a une multisig "Aave Governance Guardian" contrôlée par 6 signataires
• Cette multisig peut temporairement bloquer une proposition considérée comme "dangereuse"
• Est-ce bon ? Oui, pour prévenir les attaques de gouvernance catastrophiques
• Est-ce décentralisé ? Non, clairement pas

Questions à poser :

• Y a-t-il une multisig qui peut override les votes ?
• Qui sont les signataires (liste publique ?)
• Quel est le multisig threshold (3 sur 5 ? 5 sur 9 ?)
• Y a-t-il une rotation prévue des signataires ?

Proposition malveillante graduée

L'attaquant ne propose pas directement une attaque massive. Il procède graduellement :

1. 1Mois 1 : Propose une petite augmentation de frais (+0.1%). Vote passe sans débat
2. 2Mois 2 : Propose une nouvelle feature anodine. Vote passe
3. 3Mois 3 : Propose l'ajout d'une adresse en tant que "administrateur temporaire". Vote passe
4. 4Mois 4 : Cet administrateur propose le vol de 50M$. Trop tard, il a accès direct

Défense :

• Lire activement le forum de gouvernance
• Challenger les propositions suspectes
• Avoir une communauté engagée qui pose des questions

Participer à la gouvernance : comment et pourquoi

Où voter ?

Pour les votes on-chain :

• Interface native du protocole : uniswap.org/governance, aave.com/governance
• Tally (tally.xyz) : agrégateur de gouvernance multi-protocoles. Meilleur UX
• Snapshot : Pour les votes off-chain

Pour les votes off-chain (Snapshot) :

• Snapshot.org : directement dans l'interface
• Parfois via une dapp du protocole

Évaluer une proposition avant de voter

Ne vote jamais aveuglément. Voici le processus en 5 étapes :

Étape 1 : Lire la discussion de forum

Avant même qu'une proposition soit votée on-chain, elle est débattue sur :

• Discourse (protocoles Ethereum mainstram)
• Commonwealth (multi-chaîne)
• Snapshot Discord (community votes)

Tu trouveras :

• L'intention du proposant
• Les objections techniques
• Les analyses de risque

Étape 2 : Identifier les conflits d'intérêts

Qui a proposé cette décision ?

• Est-ce un dev du protocole (bias vers l'expansion) ?
• Est-ce un grand holder (bias vers la valeur du token) ?
• Est-ce une personne sans holdings (bias vers les intérêts techniques) ?

Étape 3 : Analyser l'impact technique

Pour une proposition de paramètres ou de smart contract :

• Un audit externes' a-t-il été mené ?
• Y a-t-il des risques identifiés d'exploit ?
• Le timelock est-il suffisant pour rollback si ça casse ?

Exemple : Proposal de réduire le facteur de collatéral d'une DAO d'emprunt de 70% à 50%.

• Risque : Les positions existantes deviennent liquidables plus vite
• Bénéfice : Plus de capital utilisable pour le protocole
• Vérification : Y a-t-il eu une simulation de crise ?

Étape 4 : Vérifier le précédent et la cohérence

• Ce genre de proposition a-t-il déjà été faite ?
• Comment les votes précédents se sont-ils déroulés ?
• Est-ce cohérent avec la "constitution" informelle du protocole ?

Étape 5 : Voter ou déléguer

Si tu es confiant :

• Vote directement (on-chain)
• Ou délègue à quelqu'un qui partage ta vision

La délégation active : meilleure que l'inactivité

Statistique sombre : En moyenne, seulement 5–10% des holders de tokens de gouvernance participent aux votes.

C'est à peu près la participation électorale d'une dictature.

Ce que tu devrais faire :

Si tu n'as pas le temps ou l'expertise pour voter :

1. 1Choisis un délégué réputé
2. 2Suis ses votes régulièrement
3. 3Retire la délégation si la personne commence à voter contre tes intérêts

Bien mieux que de ne rien faire.

Bonnes pratiques pour évaluer la gouvernance d'un protocole

Avant d'investir ou de participer à une DAO, tu dois vérifier sa "santé gouvernementale". Voici une checklist complète.

Checklist d'évaluation de gouvernance

• [ ] Timelock ≥ 48h : Les propositions critiques ont-elles un délai d'attente d'au moins 48 heures ? (Préféré : 7 jours)

• [ ] Concentration des tokens < 50% : Les top 10 holders contrôlent-ils moins de 50% des votes ? (Préféré : < 30%)

• [ ] Quorum réaliste : Le quorum est-il entre 3% et 10% ? (Vérifier que les votes atteignent régulièrement ce seuil)

• [ ] Flash loans exclus : Le smart contract utilise-t-il le bloc précédent comme "snapshot" pour empêcher les flash loan attacks ?

• [ ] Forum communautaire actif : Y a-t-il un espace de discussion pré-vote (Discourse, Commonwealth) avec des échanges techniques ?

• [ ] Historique de propositions transparent : Peux-tu voir les votes précédents, les résultats, et les explications ? (Tally rend cela facile)

• [ ] Multisig avec rotation documentée : S'il y a une multisig "guardian", ses signataires sont-ils publics et en rotation prévue ?

• [ ] Threshold de proposition raisonnable : Faut-il 65k tokens pour proposer ou seulement 1000 ? (Plus bas = plus accessible, plus haut = moins de spam)

• [ ] Bug bounty couvrant la gouvernance : Y a-t-il un programme de bounty qui couvre les exploits de gouvernance ? (Essentiellement, il ne devrait pas)

• [ ] Délégation accessible : Le système est-il facile à utiliser pour les petits holders de déléguer ? (Ex: Snapshot est plus facile que Governor Bravo)

Tableau des attaques de gouvernance connues

Analyse :

• Beanstalk et Curve partagent le même problème : timelock insuffisant + voter apathy
• SushiSwap et Yearn ont eu des problèmes de centralisation des clés
• Tous ont été "corrigés" sauf Beanstalk (qui s'est reformulé)

Exemple d'analyse : Uniswap

Uniswap est considéré comme un bon modèle de gouvernance. Pourquoi ?

• ✅ Timelock : 7 jours
• ✅ Quorum : 4% (~40M UNI)
• ✅ Top 10 holders : ~15% (très décentralisé)
• ✅ Snapshot au bloc N-1 : Les flash loans ne comptent pas
• ✅ Forum actif : Governance.uniswap.org avec centaines de discussions
• ✅ Bug bounty : Couvre la gouvernance
• ✅ Historique transparent : Tally affiche tous les votes

Bémol :

• Les petits holders paient du gas pour voter (10–100$)
• Taux de participation : ~5% (faible mais normal)

Conclusion : La gouvernance est une forme de sécurité

Résumé clé :

1. 1Deux modèles existent : on-chain (décentralisé, coûteux) et off-chain (gratuit, moins décentralisé)

1. 1Les risques sont réels : Flash loans, voter apathy, concentration des tokens. Beanstalk a perdu 182M$ en une transaction.

1. 1Ton rôle d'investisseur : Évaluer la gouvernance avec la même rigueur que tu évaluerais un audit de smart contract.

1. 1Bonne nouvelle : Il existe des normes (timelock 7j, quorum 4–10%, snapshot au bloc-1) qui rendent la gouvernance sûre.

Tu as maintenant les outils pour :

• Identifier une DAO avec une gouvernance cassée
• Évaluer les risques d'une proposition
• Participer ou déléguer ta voix intelligemment

Prochaines étapes :

• Lis le forum de gouvernance de ton protocole préféré
• Délègue ton droit de vote à quelqu'un d'actif
• Crée une alerte pour les nouvelles propositions (Tally le fait automatiquement)

Pour apprendre la sécurité technique des smart contracts que ces DAOs déploient, tu peux lire notre guide complet sur [l'audit smart contract](/securite/audit-smart-contract).

Et pour mieux comprendre comment protéger une multisig qui pourrait garder des clés critiques, découvre nos ressources sur [la sécurité multisig et la recovery](/securite/assurance-multisig-recovery).

Enfin, si tu construis ta propre DAO, assure-toi que la gouvernance est décentralisée dès le départ. Une fois qu'une minorité contrôle les votes, c'est quasi-impossible de le corriger sans fork.

Article mis à jour le 7 avril 2026. Ressources CRYPTOBOOST connexes : [DeFi risques systémiques](/risques/defi-systemic), [Audit smart contract](/securite/audit-smart-contract), [Assurance multisig et recovery](/securite/assurance-multisig-recovery), [Staking governance risks](/risques/staking-governance), [DAO treasury security](/securite/dao-treasury-security)