diff --git a/CLAUDE.md b/CLAUDE.md
index 1894873..fd8f6c6 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,4 +1,4 @@
-# Glibredecision
+# libreDecision
Plateforme de decisions collectives pour la communaute Duniter/G1.
diff --git a/docs/content/dev/1.index.md b/docs/content/dev/1.index.md
index f388e00..b218268 100644
--- a/docs/content/dev/1.index.md
+++ b/docs/content/dev/1.index.md
@@ -1,15 +1,15 @@
---
title: Documentation technique
-description: Architecture, API et reference technique de Glibredecision
+description: Architecture, API et reference technique de libreDecision
---
# Documentation technique
-Bienvenue dans la documentation technique de Glibredecision, la plateforme de decisions collectives pour la communaute Duniter/G1.
+Bienvenue dans la documentation technique de libreDecision, la plateforme de decisions collectives pour la communaute Duniter/G1.
## Presentation
-Glibredecision est une plateforme de gouvernance decentralisee qui permet aux membres de la Toile de Confiance (WoT) Duniter V2 de gerer des documents de reference modulaires sous vote permanent, prendre des decisions collectives multi-etapes, attribuer des mandats et archiver de maniere immuable les resultats via IPFS et la blockchain Duniter.
+libreDecision est une plateforme de gouvernance decentralisee qui permet aux membres de la Toile de Confiance (WoT) Duniter V2 de gerer des documents de reference modulaires sous vote permanent, prendre des decisions collectives multi-etapes, attribuer des mandats et archiver de maniere immuable les resultats via IPFS et la blockchain Duniter.
## Stack technique
@@ -37,7 +37,7 @@ Glibredecision est une plateforme de gouvernance decentralisee qui permet aux me
- **Version** : 1.0.0-rc
- **Statut** : Release candidate -- Sprint 5 (documentation et stabilisation)
-- **Depot** : [git.duniter.org/tools/glibredecision](https://git.duniter.org/tools/glibredecision)
+- **Depot** : [git.duniter.org/tools/libredecision](https://git.duniter.org/tools/libredecision)
## Sections
diff --git a/docs/content/dev/11.governance-modalities.md b/docs/content/dev/11.governance-modalities.md
new file mode 100644
index 0000000..05cad70
--- /dev/null
+++ b/docs/content/dev/11.governance-modalities.md
@@ -0,0 +1,1101 @@
+---
+title: Modalités de gouvernance — Inventaire
+description: Inventaire exhaustif des modalités de décision collective, formules de vote, principes Teal/Sociocratiques, et cartographie par contexte — référence pour l'architecture de libreDecision
+---
+
+# Inventaire des modalités de gouvernance collective
+
+**Audience** : équipe produit, product owners, contributeurs backend/frontend.
+**Objectif** : référence canonique pour les `VotingProtocol`, `Decision`, `ProcessTemplate` à implémenter dans libreDecision.
+**Date** : 2026-03-16
+
+---
+
+## 1. Modalités de décision
+
+### 1.1 Consensus (Quaker / unanime)
+
+**Description** : La proposition est adoptée uniquement si aucun membre ne s'y oppose. L'absence d'objection vaut accord. La tradition Quaker distingue le silence actif de l'approbation enthousiaste — les deux valent adoption.
+
+**Quand l'utiliser** :
+- Groupes très petits (< 15 personnes) avec une culture de confiance mutuelle
+- Décisions engageant l'identité profonde du groupe (valeurs fondatrices, charte)
+- Quand le coût d'une mauvaise décision prise rapidement dépasse le coût du temps pris pour converger
+
+**Avantages** :
+- Adhésion totale : chaque adopté l'est pleinement
+- Crée de la cohésion et de la légitimité maximale
+- Force l'écoute et l'exploration des objections
+
+**Inconvénients** :
+- Veto de facto pour un seul membre — risque de capture ou de paralysie
+- Chronophage pour les groupes larges ou hétérogènes
+- Résistance au changement structurelle : le statu quo est toujours gagnant
+
+**Formule** : `threshold = N` (tous les membres), pas de notion de majorité.
+
+**Référence** : Quaker decision-making process, Michael J. Sheeran, *Beyond Majority Rule* (1983).
+
+---
+
+### 1.2 Consentement (Sociocracie — "pas d'objection raisonnée")
+
+**Description** : La proposition est adoptée si aucun participant ne formule d'**objection raisonnée** (objection qui démontre que la proposition cause un tort au cercle ou à son but). L'abstention ou le désaccord non argumenté ne bloque pas. Ce n'est pas "c'est la meilleure option" mais "c'est assez bon pour avancer, et safe à essayer".
+
+**Distinction clé avec le consensus** : le consentement tolère des désaccords non-bloquants. "Je n'aurais pas fait ça comme ça, mais je ne vois pas de tort réel" = pas d'objection.
+
+**Quand l'utiliser** :
+- Gouvernance opérationnelle d'un cercle (rôles, règles internes)
+- Décisions réversibles ou à durée limitée ("essayons 3 mois")
+- Groupes avec culture sociocratique établie
+
+**Avantages** :
+- Beaucoup plus agile que le consensus strict
+- Distingue objection de préférence personnelle
+- Le "safe-to-try" permet l'expérimentation
+
+**Inconvénients** :
+- Nécessite une formation pour distinguer objection valide de préférence
+- Peut être perverti par des membres qui instrumentalisent les objections
+- Pas adapté aux grandes communautés sans médiation
+
+**Formule** : pas de seuil numérique — processus qualitatif. En contexte numérique : 0 objection raisonnée enregistrée après délai de consultation.
+
+**Référence** : Sociocracy 3.0 (S3), Brian Robertson *Holacracy* (2015), Gilles Charest *La Gouvernance par Consentement* (1999).
+
+---
+
+### 1.3 Majorité simple (>50%)
+
+**Description** : La proposition est adoptée si le nombre de votes favorables dépasse 50% des votes exprimés. Ne tient pas compte des abstentions sauf si un quorum est défini.
+
+**Variants** :
+- **Majorité relative** : plus de voix que toute autre option (utile pour >2 choix)
+- **Majorité absolue** : >50% des membres inscrits (y compris abstentions)
+- **Majorité simple sur exprimés** : >50% des votes pour/contre (hors abstentions)
+
+**Quand l'utiliser** :
+- Décisions routinières, réversibles, à faible enjeu
+- Votes de ratification après large consultation
+- Élections avec 2 candidats
+
+**Avantages** :
+- Simple, universel, compris par tous
+- Efficace pour trancher rapidement
+
+**Inconvénients** :
+- 51% peuvent imposer à 49% — effet tyrannie de la majorité
+- Ne mesure pas l'intensité des préférences
+- Instable : une décision prise à 51% peut être annulée à 51% inverse
+
+**Formule** : `votes_for / total_votes > 0.5`
+
+---
+
+### 1.4 Majorité qualifiée (2/3, 3/4, 4/5)
+
+**Description** : Seuil supérieur à 50%, exigeant une coalition plus large pour adopter. Variantes classiques :
+
+| Seuil | Valeur | Usage typique |
+|-------|--------|---------------|
+| 2/3 | 66.7% | Amendements constitutionnels, décisions majeures |
+| 3/4 | 75% | Changements de règles fondamentales |
+| 4/5 | 80% | Révocations, exclusions |
+| 9/10 | 90% | Exceptions quasi-unanimes |
+
+**Quand l'utiliser** :
+- Décisions irréversibles ou très difficiles à défaire
+- Changements de charte, règlements fondamentaux
+- Révocations de mandats, exclusions
+
+**Avantages** :
+- Protège les minorités
+- Force la construction de coalitions larges
+- Légitime sur la durée : les opposants restent moins nombreux
+
+**Inconvénients** :
+- Biais conservateur : favorise le statu quo
+- Peut bloquer des changements nécessaires urgents
+- Le seuil exact est souvent arbitraire
+
+**Note libreDecision** : le paramètre `M` (majority_pct) de la formule d'inertie WoT joue exactement ce rôle, mais de manière dynamique selon la participation.
+
+---
+
+### 1.5 Supermajorité avec quorum
+
+**Description** : Combine un seuil de majorité qualifié **et** un seuil minimum de participation (quorum). Les deux conditions doivent être satisfaites.
+
+**Exemples** :
+- 2/3 des votes exprimés + quorum de 30% des membres
+- 75% des votes + au moins 100 votes exprimés
+
+**Quand l'utiliser** :
+- Décisions engageant toute une communauté mais avec risque d'abstention massive
+- Environnements où la mobilisation est difficile
+
+**Avantages** :
+- Évite qu'un petit groupe décide pour tous
+- Garantit une légitimité minimale de participation
+
+**Inconvénients** :
+- Le quorum peut bloquer des décisions légitimes si la participation est chroniquement faible
+- Définir le bon quorum est difficile (trop bas = inutile, trop haut = paralysie)
+
+**Note libreDecision** : la formule d'inertie WoT est une approche **continue et graduelle** qui évite le problème du quorum binaire : au lieu de bloquer en dessous d'un seuil, elle élève les exigences de manière proportionnelle. C'est plus robuste.
+
+---
+
+### 1.6 Vote préférentiel — Vote alternatif (IRV / Instant Runoff Voting)
+
+**Description** : Chaque votant classe les candidats/options par ordre de préférence (1er, 2ème, 3ème…). On élimine successivement l'option avec le moins de premières préférences et on redistribue ses voix jusqu'à ce qu'une option atteigne >50%.
+
+**Quand l'utiliser** :
+- Élections avec plusieurs candidats (> 2)
+- Situations où on veut éviter le "vote utile" (les électeurs votent sincèrement)
+- Choix entre plusieurs options pour un poste ou une politique
+
+**Avantages** :
+- Évite les effets spoiler (candidat proche élimine l'autre proche)
+- Résultat respecte une majorité réelle au sens préférentiel
+- Vote sincère encouragé
+
+**Inconvénients** :
+- Plus complexe à expliquer et à compter
+- Peut éliminer le candidat le plus large consensus (Condorcet winner) dans certains cas
+- Résultats non monotones possibles (paradoxe IRV)
+
+**Référence** : utilisé en Australie (chambre basse), Irlande (présidentielle), beaucoup de syndicats.
+
+---
+
+### 1.7 Méthode Borda
+
+**Description** : Chaque votant classe `n` options. L'option classée 1ère reçoit `n-1` points, la 2ème `n-2` points, etc. L'option avec le plus de points total gagne.
+
+**Quand l'utiliser** :
+- Sélection d'une option parmi plusieurs dans un groupe cherchant le consensus
+- Priorisation de listes (backlog, priorités)
+- Quand on veut mesurer l'intensité des préférences
+
+**Avantages** :
+- Simple à calculer
+- Tend à sélectionner l'option la plus consensuelle (pas la plus polarisante)
+- Mesure l'intensité relative des préférences
+
+**Inconvénients** :
+- Manipulable : injecter un candidat parasite peut changer le résultat
+- Ne satisfait pas le critère de Condorcet (peut élire une option battue 1-contre-1 par une autre)
+- Sensible au nombre d'options présentées
+
+**Référence** : Jean-Charles de Borda (1781), utilisé dans certains awards académiques.
+
+---
+
+### 1.8 Méthode Condorcet
+
+**Description** : Le vainqueur de Condorcet est l'option qui bat toutes les autres en comparaison par paires (1 contre 1). Si une telle option existe, c'est la gagnante. Si aucune n'existe (cycle Condorcet), une méthode de résolution des cycles est nécessaire (Smith set, Schulze, etc.).
+
+**Quand l'utiliser** :
+- Quand l'objectif est l'option préférée par une majorité contre chaque alternative
+- Élections à fort enjeu de légitimité
+- Communautés avec culture délibérative
+
+**Avantages** :
+- Vainqueur le plus robuste au sens de la préférence collective
+- Résiste aux effets "vote utile"
+
+**Inconvénients** :
+- Le vainqueur de Condorcet n'existe pas toujours (cycles)
+- Complexe à expliquer
+- Nécessite des méthodes de résolution des cycles (ajout de complexité)
+
+**Référence** : Marquis de Condorcet (1785), *Essai sur l'application de l'analyse à la probabilité des décisions*.
+
+---
+
+### 1.9 Ensemble Smith (déjà implémenté dans libreDecision)
+
+**Description** : L'ensemble Smith est le plus petit sous-ensemble d'options qui bat toutes les options extérieures à l'ensemble en comparaison par paires. Si un vainqueur de Condorcet existe, l'ensemble Smith se réduit à cet unique vainqueur.
+
+**Usage dans libreDecision** : le critère Smith est utilisé comme critère de participation **subgroup** : les membres "Smith" de la WoT (forgerons validateurs) doivent atteindre un seuil minimum de votes favorables via `ceil(SmithWotSize^S)`. Cela garantit que les membres les plus engagés techniquement approuvent les décisions techniques.
+
+**Référence** : John H. Smith (1973), *Aggregation of Preferences with Variable Electorate*.
+
+---
+
+### 1.10 Méthode Schulze
+
+**Description** : Méthode de comparaison par paires qui résout les cycles Condorcet en comparant les chemins les plus forts dans le graphe de préférences. L'option avec le chemin le plus fort vers toutes les autres est gagnante.
+
+**Quand l'utiliser** :
+- Élections complexes avec de nombreux candidats
+- Communautés en ligne avec outils de vote sophistiqués (Debian, Wikimedia, Pirate Parties)
+
+**Avantages** :
+- Satisfait de nombreux critères de théorie du vote (Condorcet, Smith, monotonie)
+- Résiste à la manipulation et aux candidats parasites
+- Produit toujours un vainqueur
+
+**Inconvénients** :
+- Très complexe à expliquer aux non-initiés
+- Calcul matriciel non trivial à vérifier manuellement
+- Peut produire des ex-aequo nécessitant un départage
+
+**Formule** : pour chaque paire (A, B), calculer le chemin le plus fort `p[A,B]`. L'option A domine B si `p[A,B] > p[B,A]`.
+
+**Référence** : Markus Schulze (1998, 2011). Utilisé par Debian, Wikimedia Foundation, Pirate Parties internationaux.
+
+---
+
+### 1.11 Vote par approbation (Approval Voting)
+
+**Description** : Chaque votant coche toutes les options qu'il "approuve" (sans limite ni classement). L'option approuvée par le plus grand nombre gagne.
+
+**Quand l'utiliser** :
+- Sélection parmi plusieurs candidats ou options
+- Quand on veut maximiser la satisfaction globale (éviter les candidats très polarisants)
+- Référendums multi-options
+
+**Avantages** :
+- Extrêmement simple à comprendre et à comptabiliser
+- Favorise les candidats rassembleurs
+- Élimine l'effet "vote utile" sans classement complexe
+
+**Inconvénients** :
+- Ne mesure pas l'intensité des préférences (approbation binaire)
+- Le résultat dépend de combien d'options les électeurs approuvent en moyenne
+- Peut élire une option "médiocrement approuvée par beaucoup" plutôt qu'une option "fortement préférée par la majorité"
+
+**Référence** : Steven Brams et Peter Fishburn (1978).
+
+---
+
+### 1.12 Vote par score (Score Voting / Range Voting)
+
+**Description** : Chaque votant attribue une note (ex: 0 à 10) à chaque option. L'option avec la moyenne la plus haute gagne. Généralise le vote par approbation (qui est un cas particulier avec notes 0 ou 1).
+
+**Quand l'utiliser** :
+- Évaluation de projets, candidats, propositions
+- Quand l'intensité des préférences est pertinente
+- Questionnaires de satisfaction (ex: NPS)
+
+**Avantages** :
+- Capture l'intensité des préférences
+- Simple à comprendre (système de notation familier)
+- Permet des ex-aequo significatifs
+
+**Inconvénients** :
+- Manipulable stratégiquement (donner 0 à tous les concurrents et 10 à son favori)
+- La comparabilité inter-individus des notes est une hypothèse forte
+- Le choix de l'échelle affecte les résultats
+
+**Note libreDecision** : le **vote nuancé** à 6 niveaux déjà implémenté est une forme de score voting avec une échelle ordinale.
+
+---
+
+### 1.13 Vote pondéré par participation / Démocratie liquide (Liquid Democracy)
+
+**Description** : Chaque membre peut voter directement OU déléguer son vote à un autre membre pour un domaine ou une décision spécifique. Le délégué vote avec son propre poids + le poids délégué. Les délégations sont transitives et révocables à tout moment.
+
+**Quand l'utiliser** :
+- Communautés larges avec des domaines d'expertise différents
+- Quand la participation directe de tous n'est pas réaliste
+- Pour éviter la démocratie représentative figée (délégations révocables)
+
+**Avantages** :
+- Chaque voix compte, soit directement soit via délégué de confiance
+- Les délégations peuvent être thématiques (déléguer en économie à X, en technique à Y)
+- Hybride idéal entre démocratie directe et représentative
+
+**Inconvénients** :
+- Peut créer des super-votants avec poids démesurés (oligarchie de facto)
+- Les chaînes de délégation sont difficiles à auditer
+- La révocabilité à tout moment peut déstabiliser les votes en cours
+
+**Implémentation** : nécessite un graphe de délégations, calcul de poids propagé, révocabilité temps réel.
+
+**Référence** : Gordon Tullock (1967 — vote proxy), Bryan Ford (2002 — delegative democracy).
+
+---
+
+### 1.14 Processus de sollicitation d'avis (Advice Process — Laloux)
+
+**Description** : Toute personne peut prendre toute décision dans son domaine de responsabilité, à condition de consulter (pas d'obtenir l'accord de) les personnes affectées et les experts pertinents. La décision finale appartient à l'initiateur.
+
+**Quand l'utiliser** :
+- Organisations plates (Teal, autogestion)
+- Décisions opérationnelles dans un rôle clair
+- Quand la décision est réversible et dans un périmètre délimité
+
+**Avantages** :
+- Très agile : pas besoin de quorum ni de consensus
+- Responsabilise l'acteur
+- Collecte la sagesse collective sans réunion de décision
+
+**Inconvénients** :
+- Peut créer des injustices si le périmètre des rôles est flou
+- L'acteur peut ignorer les avis — confiance requise dans la culture
+- Difficile à auditer et à contester formellement
+
+**Référence** : Frédéric Laloux, *Reinventing Organizations* (2014), chapitre 2.
+
+---
+
+### 1.15 Consentement + rondes d'amendements
+
+**Description** : Extension du consentement sociocratique avec des rondes formelles d'amendement avant la clôture. Structure :
+1. Présentation de la proposition
+2. Tour de clarification (questions factuelles uniquement)
+3. Tour de réactions (ressentis, pas d'argumentation)
+4. Amendements (modifications par l'auteur ou collectivement)
+5. Tour de consentement final
+
+**Quand l'utiliser** :
+- Décisions importantes nécessitant un texte précis
+- Amendements de documents (textes légaux, chartes)
+- Groupes avec facilitateur formé
+
+**Avantages** :
+- Intègre les objections dans le texte plutôt que de les ignorer
+- Processus transparent et équitable
+- Produit des textes mieux aboutis
+
+**Inconvénients** :
+- Long (peut prendre plusieurs séances)
+- Nécessite un facilitateur compétent
+- Difficulté à gérer les amendements conflictuels
+
+---
+
+### 1.16 SCOT — Stratégie par Consentement sur Offre de Tensions
+
+**Description** : Méthode dérivée de la sociocracie (S3 — *Navigating Tensions*). Au lieu de partir d'une proposition, on part des **tensions** ressenties (écarts entre situation actuelle et situation souhaitée). Les propositions émergent des tensions. Le consentement porte sur "cette proposition résout-elle suffisamment la tension sans en créer de nouvelles ?"
+
+**Étapes** :
+1. Nommer la tension (une phrase : "je vis X alors que je voudrais Y")
+2. Proposer une solution possible
+3. Test du sens (la tension est-elle réelle ? la proposition y répond-elle ?)
+4. Consentement sur la proposition
+5. Essai limité dans le temps, puis évaluation
+
+**Quand l'utiliser** :
+- Gouvernance évolutive d'une organisation
+- Amélioration continue des processus
+- Quand on veut éviter les débats abstraits et rester ancré dans le réel
+
+**Avantages** :
+- Ancré dans l'expérience concrète des membres
+- Évite les débats idéologiques sur des propositions théoriques
+- Intègre naturellement la rétrospective
+
+**Inconvénients** :
+- Peut fragmenter la gouvernance en micro-décisions
+- Nécessite une culture d'expression des tensions (vulnérabilité requise)
+- Risque de surcharge de processus dans les grands groupes
+
+**Référence** : Sociocracy 3.0 (James Priest, Liliana David, Bernhard Bockelbrink), *A Practical Guide to Sociocracy 3.0* (2018).
+
+---
+
+### 1.17 Vote pondéré par stake (Web3 / DAO)
+
+**Description** : Le poids de vote est proportionnel au stake détenu (tokens, réputation, ancienneté). Utilisé massivement dans les DAO (Decentralized Autonomous Organizations).
+
+**Variants** :
+- **Token-weighted voting** : 1 token = 1 vote
+- **Quadratic voting** : le coût d'un vote supplémentaire augmente quadratiquement (1 voix = 1 token, 2 voix = 4 tokens, 3 voix = 9 tokens) — réduit la domination des baleines
+- **Reputation-weighted** : poids basé sur la réputation (contributions, ancienneté)
+
+**Note libreDecision** : dans le contexte Duniter/G1, la WoT (Toile de Confiance) est le mécanisme anti-sybille. Tous les membres WoT ont le même poids (1 personne = 1 voix), mais les sous-groupes (Smith/forgerons, CoTec) peuvent avoir des critères additionnels. C'est une forme de **reputation-weighted voting via WoT membership** sans pondération numérique.
+
+**Référence** : Vitalik Buterin, *Quadratic Voting* (2017). RadicalxChange.
+
+---
+
+### 1.18 Vote inertiel (déjà implémenté — formule libreDecision)
+
+**Description** : Le seuil d'adoption est dynamique : il décroît à mesure que la participation augmente. À faible participation, une quasi-unanimité est requise ; à participation totale, la majorité simple suffit.
+
+**Propriété fondamentale** : protège contre les décisions prises par un petit groupe sans bloquer les décisions larges. Le statu quo est protégé non par un seuil arbitraire mais par la physique de la participation.
+
+**Formule** :
+```
+Result = C + B^W + (M + (1-M) * (1 - (T/W)^G)) * max(0, T-C)
+```
+
+Voir `5.formulas.md` pour la documentation complète.
+
+**Pertinence théorique** : correspond à la notion de **supermajorité adaptive** — une généralisation continue des seuils discrets classiques (50%, 66%, 75%). C'est une innovation originale pour les communautés à participation variable.
+
+---
+
+## 2. Modalités de nomination et d'élection
+
+### 2.1 Auto-candidature
+
+**Description** : Tout membre éligible peut se déclarer candidat à un rôle ou mandat.
+
+**Avantages** : simple, pas de biais de sélection, responsabilise le candidat.
+**Inconvénients** : peut manquer les personnes compétentes mais modestes, surcharge si trop de candidats.
+**Contexte** : mandats ouverts, rôles non critiques.
+
+---
+
+### 2.2 Nomination par les pairs
+
+**Description** : Les membres du groupe nomment d'autres membres (ou eux-mêmes) pour un rôle. Peut être confidentielle (ballot anonyme) ou ouverte.
+
+**Avantages** : fait émerger des candidats sous-visibles, valide la légitimité par la reconnaissance collective.
+**Inconvénients** : biais vers les personnes populaires vs. compétentes, pression sociale.
+**Contexte** : élections de représentants, postes à responsabilité.
+
+---
+
+### 2.3 Élection sociocratique de rôle
+
+**Description** : Processus en plusieurs étapes :
+1. Description précise du rôle et de ses responsabilités
+2. Chacun écrit son candidat sur un bulletin (ou formulaire numérique), **sans concertation**
+3. Chacun annonce son choix et **justifie** ("je choisis X parce que…")
+4. Après les justifications, chacun peut **changer** son choix
+5. Le facilitateur propose le candidat émergent, puis applique un **consentement** (pas d'objection raisonnée = élu)
+
+**Avantages** :
+- Évite le vote stratégique (on vote avant d'entendre les autres)
+- Les justifications font circuler des informations pertinentes sur les candidats
+- Le consentement final évite les élus sans légitimité
+
+**Inconvénients** :
+- Processus lent pour de grands groupes
+- Nécessite un facilitateur
+- Peut être perturbé par des dynamiques de clans si les justifications sont partiales
+
+**Référence** : Gerard Endenburg (sociocracie), S3 *Role Election*.
+
+---
+
+### 2.4 Nomination par consentement (appointment by consent)
+
+**Description** : Un membre propose une personne pour un rôle. Le groupe applique le processus de consentement : pas d'objection raisonnée = nommée.
+
+**Avantages** : rapide, adapté aux rôles opérationnels clairs.
+**Inconvénients** : pas d'exploration des alternatives, peut favoriser les connexions sociales.
+**Contexte** : rôles techniques, postes de coordination interne.
+
+---
+
+### 2.5 Renouvellement de mandat
+
+**Description** : À l'échéance du mandat, la personne peut être reconduite ou remplacée. Trois modalités :
+- **Reconduction automatique** sauf objection (opt-out)
+- **Vote de reconduction** explicite (opt-in)
+- **Réévaluation avec critères** (bilan de mandat présenté, puis vote)
+
+**Bonne pratique** : systématiser le **bilan de mandat** (rapport court : objectifs initiaux, réalisations, difficultés, perspective). Permet un vote éclairé.
+
+---
+
+### 2.6 Rotation et limites de mandats
+
+**Description** :
+- **Limite de mandats consécutifs** : évite la captation du pouvoir (ex: max 2 mandats consécutifs de 2 ans)
+- **Rotation tournante** : dans un comité de N membres, M membres sont renouvelés chaque année (continuité + renouvellement)
+- **Tirage au sort (Sortition)** : sélection aléatoire parmi les volontaires éligibles — pratique démocratique athénienne, revalorisée par David Van Reybrouck (*Against Elections*, 2013)
+
+**Avantages** : prévient l'oligarchie, diversifie les profils, crée une culture de gouvernance distribuée.
+**Inconvénients** : perte d'expertise accumulée, coûts de formation des nouveaux arrivants.
+
+---
+
+### 2.7 Clarté de rôle (accountability, autorité, responsabilités)
+
+**Description** : Avant toute élection ou nomination, documenter précisément :
+- **Redevabilité** (accountability) : envers qui et pour quoi le rôle est redevable
+- **Autorité** : ce que le rôle peut décider seul sans consulter
+- **Responsabilités** : les tâches récurrentes attendues
+- **Domaine** : les ressources/actifs sous contrôle du rôle
+
+**Référence** : Holacracy *Role Constitution*, S3 *Describe Organizational Drivers*.
+
+---
+
+### 2.8 Chaînes de délégation et mandats imbriqués
+
+**Description** : Dans les organisations hiérarchiques plates, les mandats peuvent s'imbriquer :
+- Un cercle délègue une autorité à un sous-cercle
+- Un rôle peut déléguer une sous-mission à un autre rôle
+- Les délégations sont documentées et révisables
+
+**Propriété clé** : une délégation ne peut transférer plus d'autorité que ce que le délégant possède.
+
+---
+
+### 2.9 Révocation (recall)
+
+**Description** : Processus par lequel la communauté peut mettre fin à un mandat avant son terme. Modalités :
+- **Pétition + vote** : un nombre minimal de membres signent une pétition, puis vote de révocation
+- **Vote de confiance spontané** : tout membre peut initier un vote de confiance
+- **Révocation par objection grave** : consentement inversé — une objection raisonnée grave suffit à déclencher la procédure
+
+**Garde-fous nécessaires** :
+- Seuil de déclenchement suffisamment élevé pour éviter les abus
+- Protection contre les révocations motivées par des désaccords de fond (pas de comportement problématique)
+- Délai de préavis et droit de réponse pour le titulaire
+
+---
+
+## 3. Formules de vote et seuils
+
+### 3.1 Tableau récapitulatif des seuils classiques
+
+| Seuil | Formule | Usage |
+|-------|---------|-------|
+| Majorité simple | `votes_for / total > 0.5` | Décisions courantes |
+| Majorité absolue | `votes_for / members > 0.5` | Élections formelles |
+| Super-majorité 2/3 | `votes_for / total > 0.667` | Amendements importants |
+| Super-majorité 3/4 | `votes_for / total > 0.75` | Règles fondamentales |
+| Super-majorité 4/5 | `votes_for / total > 0.80` | Exclusions, révocations |
+| Quasi-unanimité | `votes_for / total > 0.90` | Décisions existentielles |
+| Unanimité | `votes_against = 0` | Consensus pur |
+
+---
+
+### 3.2 Formule d'inertie WoT (libreDecision — implémentée)
+
+```
+Result = C + B^W + (M + (1-M) * (1 - (T/W)^G)) * max(0, T-C)
+```
+
+**Propriétés** :
+- `T → 0` : seuil → `W` (quasi-unanimité requise)
+- `T → W` : seuil → `M * W` (majorité cible)
+- `G` contrôle la vitesse de transition
+
+Voir `5.formulas.md` pour la documentation complète avec tables et exemples.
+
+---
+
+### 3.3 Critère Smith (libreDecision — implémenté)
+
+```
+SmithThreshold = ceil(SmithWotSize^S)
+```
+
+Le sous-groupe "Smith" (forgerons validateurs) doit atteindre indépendamment ce seuil. Condition nécessaire mais pas suffisante (s'ajoute à la formule WoT principale).
+
+---
+
+### 3.4 Critère TechComm (libreDecision — implémenté)
+
+```
+TechCommThreshold = ceil(CoTecSize^Tc)
+```
+
+Même principe pour le Comité Technique. Garantit l'approbation des experts techniques pour les décisions techniques.
+
+---
+
+### 3.5 Vote quadratique
+
+**Description** : Pour exprimer `k` voix sur une option, un membre dépense `k²` crédits. Distribution initiale de crédits égale pour tous.
+
+**Exemples** :
+| Voix exprimées | Coût en crédits |
+|---------------|-----------------|
+| 1 | 1 |
+| 2 | 4 |
+| 3 | 9 |
+| 5 | 25 |
+| 10 | 100 |
+
+**Propriété** : un membre avec 100 crédits peut voter 10 voix sur 1 option (dépense 100) ou 3-4 voix sur plusieurs options. Limite l'influence des préférences très intenses sans l'éliminer.
+
+**Référence** : Vitalik Buterin, Glen Weyl, *Radical Markets* (2018).
+
+---
+
+### 3.6 Méthode de Schulze — formule
+
+Pour un ensemble d'options `{A, B, C, ...}` :
+1. Construire la matrice `d[X,Y]` = nombre de votants qui préfèrent X à Y
+2. Calculer la matrice de chemins forts : `p[X,Y] = max(d[X,Y], max_Z(min(p[X,Z], p[Z,Y])))`
+3. L'option X domine Y si `p[X,Y] > p[Y,X]`
+4. Le gagnant est l'option qui domine toutes les autres
+
+---
+
+### 3.7 Ranked Pairs (Tideman)
+
+**Description** : Méthode Condorcet qui résout les cycles en ordonnant les victoires par paires du plus fort au plus faible et en ignorant les paires qui créeraient un cycle.
+
+**Étapes** :
+1. Calculer toutes les paires de comparaisons
+2. Classer les victoires par marge décroissante
+3. Confirmer chaque paire (dans l'ordre) sauf si elle crée un cycle
+4. Le résultat est le graphe acyclique des préférences
+
+**Propriété** : satisfait Condorcet, monotonie, indépendance des alternatives non pertinentes dans certains cas.
+
+**Référence** : T. Nicolaus Tideman (1987).
+
+---
+
+## 4. Principes Teal / Laloux — Gouvernance d'organisations autogérées
+
+*Référence principale* : Frédéric Laloux, *Reinventing Organizations* (Nelson Parker, 2014).
+
+### 4.1 Les trois avancées Teal
+
+| Avancée | Description | Mécanisme |
+|---------|-------------|-----------|
+| **Autogestion** | Remplacement des hiérarchies par des réseaux de pairs | Processus de sollicitation d'avis, rôles distribués |
+| **Plénitude** | Permettre l'expression de toute la personne au travail | Pratiques de réunion, espaces de partage |
+| **Raison d'être évolutive** | L'organisation suit son but, pas les plans des dirigeants | Écoute régulière de la "raison d'être", stratégie émergente |
+
+---
+
+### 4.2 Processus de sollicitation d'avis (Advice Process)
+
+**Règle** : Avant toute décision significative, l'acteur doit consulter :
+- Les personnes **affectées** par la décision
+- Les personnes ayant de l'**expertise** sur le sujet
+
+Consulter ≠ obtenir accord. La décision reste à l'acteur.
+
+**Conditions pour que ça fonctionne** :
+- Rôles et domaines clairement définis
+- Culture de confiance et de redevabilité
+- Mécanismes de résolution si la décision cause tort
+
+---
+
+### 4.3 Résolution de conflits (processus en 3 étapes)
+
+1. **Résolution directe** : les parties concernées cherchent une solution entre elles
+2. **Médiation par pairs** : un médiateur volontaire est sollicité (pas de hiérarchie)
+3. **Panel de pairs** : un panel de membres du cercle est constitué pour écouter et recommander
+
+À chaque étape, l'escalade n'est possible qu'en cas d'échec de l'étape précédente. Pas de HR, pas de tribunal hiérarchique.
+
+---
+
+### 4.4 Rôles vs postes
+
+| Poste (modèle classique) | Rôle (modèle Teal/Holacracy) |
+|--------------------------|-------------------------------|
+| Défini une fois, stable | Evolue avec les besoins |
+| Lié à une personne | Peut être tenu par plusieurs |
+| Autorité hiérarchique | Autorité de domaine |
+| Décrit par un titre | Décrit par une redevabilité précise |
+| Évaluation annuelle | Feedback continu |
+
+---
+
+### 4.5 Formats de réunion
+
+| Format | Objectif | Structure |
+|--------|----------|-----------|
+| **Réunion tactique** | Traiter les tensions opérationnelles | Tour de météo → ordre du jour émergent → traitement des tensions → clôture |
+| **Réunion de gouvernance** | Faire évoluer les rôles et règles | Revue des tensions → proposition → questions de clarification → réactions → consentement |
+| **Rétrospective** | Apprendre de l'expérience | Ce qui a bien marché → axes d'amélioration → expériences à mener |
+| **Cercle stratégique** | Écouter la raison d'être | Espace ouvert, questions génératives, émergence |
+
+---
+
+### 4.6 Fixation de salaires / rémunération par les pairs
+
+Trois modèles observés dans les organisations Teal :
+
+1. **Auto-fixation avec avis** : chacun propose son salaire après consultation des pairs et transparence des données
+2. **Comité de pairs** : un panel tournant fixe les salaires sur base de critères partagés
+3. **Formule transparente** : algorithme public (ancienneté, rôle, performance) appliqué de manière identique
+
+**Prérequis dans tous les cas** : transparence totale des salaires entre membres.
+
+---
+
+### 4.7 Holacracy vs Sociocracie vs Teal
+
+| Dimension | Holacracy | Sociocracie (SCM/S3) | Teal |
+|-----------|-----------|---------------------|------|
+| **Structure** | Très formelle (constitution, cercles, rôles codifiés) | Modérément formelle | Principielle, pas prescriptive |
+| **Décision** | Consentement sur gouvernance, advice sur opérations | Consentement | Advice process central |
+| **Hiérarchie** | Hiérarchie de cercles (pas de personnes) | Cercles liés (double lien) | Réseau de pairs |
+| **Appropriation** | Brian Robertson, propriétaire de HolacracyOne | Géard Endenburg, open source (S3) | Laloux, pas de méthode imposée |
+| **Complexité** | Élevée — constitution de 40 pages | Moyenne | Faible — principes, pas de règles |
+| **Adapté à** | Organisations avec volonté de formalisation maximale | Organisations cherchant structure sans rigidité | Organisations en transformation culturelle |
+
+---
+
+## 5. Cartographie par contexte
+
+### 5.1 Urgence vs non-urgence
+
+| Contexte | Modalité recommandée | À éviter |
+|----------|---------------------|----------|
+| **Urgent, irréversible** | Advice process + critère TechComm (exige experts) | Consensus (trop lent), vote large sans experts |
+| **Urgent, réversible** | Advice process, consentement d'un sous-cercle | Vote de toute la communauté |
+| **Non-urgent, irréversible** | Vote inertiel + critère Smith/TechComm + rondes d'amendements | Majorité simple |
+| **Non-urgent, réversible** | Consentement, advice process, majorité simple | Consensus (disproportion effort/enjeu) |
+
+---
+
+### 5.2 Enjeu (fort vs routinier)
+
+| Enjeu | Modalité recommandée | Formule |
+|-------|---------------------|---------|
+| **Existentiel** (charte, raison d'être) | Consensus ou quasi-unanimité | Unanimité ou >90% |
+| **Structurel** (règles fondamentales) | Supermajorité qualifiée + quorum | >75%, quorum fort |
+| **Important** (politique majeure) | Vote inertiel WoT + critères sub-groupes | M=50%, G=0.2, Smith si applicable |
+| **Courant** (règles opérationnelles) | Consentement, majorité simple | >50% |
+| **Micro** (décisions de rôle) | Advice process | Pas de vote |
+
+---
+
+### 5.3 Taille du groupe
+
+| Taille | Modalités adaptées | Modalités inadaptées |
+|--------|-------------------|---------------------|
+| 3-7 personnes | Consensus, consentement, advice | Vote formel (surcharge) |
+| 8-20 personnes | Consentement, élection sociocratique, majorité | Consensus (chronophage) |
+| 20-100 personnes | Vote inertiel, approval voting, Borda | Consensus, consentement direct |
+| 100-1000 personnes | Vote inertiel, Schulze, liquid democracy | Consensus, consentement |
+| 1000+ personnes | Vote inertiel WoT, quadratic voting, délégation | Toute méthode qualitative directe |
+
+**Observation Duniter/G1** : la WoT actuelle (~7224 membres) nécessite des méthodes à la fois scalables et protectrices des minorités. Le vote inertiel est idéalement positionné.
+
+---
+
+### 5.4 Hétérogénéité du groupe
+
+| Groupe | Modalité | Rationale |
+|--------|----------|-----------|
+| **Homogène** (expertise, culture partagée) | Consentement, consensus, advice | Confiance élevée, peu de conflits |
+| **Hétérogène** (expertise, valeurs diverses) | Schulze, approval voting, critères sub-groupes | Protège les minorités d'experts, mesure les coalitions |
+| **Polarisé** | Vote quadratique, méthodes Condorcet | Limite la tyrannie d'une majorité intense |
+
+---
+
+### 5.5 One-shot vs récurrent
+
+| Type | Modalité | Exemple libreDecision |
+|------|----------|-----------------------|
+| **One-shot** | Vote inertiel WoT sur Decision | Runtime Upgrade, adoption d'un texte |
+| **Récurrent standardisé** | ProcessTemplate + Instance | Embarquement Forgeron, Certification membre |
+| **Continu / itératif** | Advice process + rétrospective | Ajustements opérationnels |
+| **Périodique** | Vote de reconduction + bilan | Renouvellement de mandats |
+
+---
+
+### 5.6 Technique vs politique
+
+| Nature | Modalité | Critère spécifique |
+|--------|----------|--------------------|
+| **Technique** (runtime, infra, code) | Vote inertiel + critère TechComm obligatoire | `ceil(CoTecSize^Tc)` |
+| **Politique** (règles communautaires) | Vote inertiel + critère Smith si forgerons concernés | `ceil(SmithWotSize^S)` |
+| **Hybride** (protocole forgeron) | Vote inertiel + Smith + TechComm | Double critère |
+| **Pure opérationnel** | Advice process ou consentement de cercle | Pas de vote WoT |
+
+---
+
+### 5.7 Réversible vs irréversible
+
+| Décision | Approche | Seuil |
+|----------|----------|-------|
+| **Irréversible** (exclusion, destruction de ressource) | Vote inertiel M=75%+ ou consensus | Très élevé, délai long |
+| **Difficile à défaire** (charte, protocole fondateur) | Vote inertiel M=66%+ + critères Smith/CoTec | Élevé |
+| **Réversible à court terme** | Vote inertiel M=50% ou consentement | Standard |
+| **Facilement réversible** | Advice process | Pas de vote |
+
+---
+
+## 6. Jalons de workflow de protocole de gouvernance
+
+### 6.1 Schéma général des étapes
+
+```
+[Initiation]
+ │
+ ▼
+[Consultation / Sollicitation d'avis]
+ │
+ ▼
+[Rédaction / Amendements]
+ │
+ ▼
+[Annonce formelle / Gel du texte]
+ │
+ ▼
+[Ouverture du vote]
+ │
+ ▼
+[Période de vote] ──(temps réel)──▶ [Jauge de seuil]
+ │
+ ▼
+[Clôture + Calcul du résultat]
+ │
+ ├──[Adopté]──▶ [Proclamation] ──▶ [Mise en œuvre] ──▶ [Sanctuaire IPFS+hash]
+ │
+ └──[Rejeté]──▶ [Archive] ──▶ [Rétrospective optionnelle]
+```
+
+---
+
+### 6.2 Jalons détaillés — Bonne pratique
+
+#### Jalon 1 : Initiation de proposition
+
+**Acteur** : tout membre éligible
+**Prérequis** : identité WoT vérifiée
+**Contenu** :
+- Titre clair et descriptif
+- Problème adressé (tension, contexte)
+- Proposition concrète (texte ou décision)
+- Auteur(s)
+- Type de décision (vote WoT, processus multi-étapes, etc.)
+
+**Bonnes pratiques** :
+- Distinguer clairement "problème" et "solution proposée"
+- Joindre les références pertinentes (textes antérieurs, votes précédents)
+- Indiquer si la décision est réversible ou non
+
+---
+
+#### Jalon 2 : Consultation / Advice phase
+
+**Durée recommandée** : 7-14 jours (selon l'enjeu)
+**Acteurs** : personnes affectées + experts identifiés
+**Outils** : forum de discussion, commentaires sur la proposition, réunion de clarification
+
+**Bonnes pratiques** :
+- Notification proactive des parties prenantes (pas seulement "la proposition est ouverte")
+- Questions de clarification séparées des objections
+- L'auteur documente les avis reçus et les intègre ou argumente pourquoi il ne les intègre pas
+
+---
+
+#### Jalon 3 : Rondes d'amendements
+
+**Acteur** : auteur(s) + co-rédacteurs éventuels
+**Processus** :
+- Les commentaires sont regroupés en thèmes
+- Chaque thème donne lieu à une proposition d'amendement (accepté / rejeté / modifié)
+- Le texte final est versionné (v1.0, v2.0…)
+- Un "gel du texte" est annoncé : aucune modification après ce point
+
+**Bonnes pratiques** :
+- Distinguer les amendements de fond des corrections rédactionnelles
+- Traçabilité complète des versions (git-like)
+- L'auteur reste maître d'œuvre mais peut déléguer à un co-rédacteur
+
+---
+
+#### Jalon 4 : Annonce formelle et gel du texte
+
+**Durée avant ouverture du vote** : 48h minimum (laisser le temps de prendre connaissance du texte final)
+**Actions** :
+- Publication du texte final avec numéro de version
+- Hash du texte calculé et publié (intégrité)
+- Annonce sur les canaux officiels (forum, matrix, etc.)
+- Rappel des paramètres du vote (durée, protocole, formule)
+
+---
+
+#### Jalon 5 : Ouverture du vote
+
+**Paramètres figés à l'ouverture** :
+- Snapshot de la WoT (taille `W` = membres éligibles au moment de l'ouverture)
+- Protocole de vote (formule, durée, critères Smith/TechComm)
+- Texte final soumis au vote
+
+**Bonnes pratiques** :
+- Notification push à tous les membres éligibles
+- Interface claire : texte + jauge + boutons de vote
+- Rappels périodiques (J+7, J+14, 48h avant clôture)
+
+---
+
+#### Jalon 6 : Période de vote
+
+**Durée recommandée par type** :
+
+| Type de décision | Durée minimale | Durée recommandée |
+|-----------------|----------------|-------------------|
+| Micro-décision opérationnelle | 3 jours | 7 jours |
+| Décision courante | 7 jours | 14-30 jours |
+| Décision importante | 14 jours | 30 jours |
+| Décision fondamentale | 30 jours | 60 jours |
+
+**Mécanismes pendant le vote** :
+- Possibilité de modifier son vote (historique conservé)
+- Jauge de seuil en temps réel
+- Commentaires publics avec signature
+- Alerte si critère Smith/TechComm non encore atteint à J-7
+
+---
+
+#### Jalon 7 : Vérification du quorum / Clôture
+
+**Actions à la clôture** :
+- Calcul final de la formule d'inertie avec `T` = votes exprimés
+- Vérification des critères additionnels (Smith, TechComm)
+- Résultat : Adopté / Rejeté
+
+**Clôture anticipée possible si** :
+- Le seuil est déjà mathématiquement inatteignable (rejet anticipé)
+- Le seuil est déjà mathématiquement dépassé et irréversible (adoption anticipée)
+- Demande du CoTec + consentement (cas d'urgence)
+
+---
+
+#### Jalon 8 : Proclamation du résultat
+
+**Contenu de la proclamation** :
+- Résultat (Adopté / Rejeté)
+- Votes pour, contre, total
+- Seuil requis et seuil atteint
+- Détail des critères additionnels (Smith, TechComm)
+- Hash du résultat final
+- Lien vers l'archive
+
+**Canaux** : forum officiel, interface libreDecision, notification push, system.remark on-chain (si Adopté).
+
+---
+
+#### Jalon 9 : Mise en œuvre et traçabilité
+
+**Si Adopté** :
+- Désignation du responsable de mise en œuvre
+- Délai de mise en œuvre annoncé
+- Ticket de suivi public (visible de tous)
+- Preuve de mise en œuvre documentée (lien, hash, transaction on-chain)
+
+**Bonnes pratiques** :
+- Ne pas confondre "adopté" et "mis en œuvre"
+- La mise en œuvre peut nécessiter ses propres étapes (ProcessTemplate)
+- Les décisions adoptées non mises en œuvre dégradent la confiance dans le système
+
+---
+
+#### Jalon 10 : Archivage dans le Sanctuaire
+
+**Actions** :
+- Upload du texte final + votes signés sur IPFS
+- Hash CID publié dans system.remark on-chain
+- Lien permanent (IPFS gateway) dans la base de données libreDecision
+- Indexation dans l'historique des décisions
+
+**Propriété** : une décision archivée dans le Sanctuaire est immuable et vérifiable indépendamment de libreDecision.
+
+---
+
+#### Jalon 11 : Rétrospective / Évaluation (optionnel mais recommandé)
+
+**Quand** : 3-6 mois après adoption et mise en œuvre
+**Questions clés** :
+- La décision a-t-elle atteint son objectif ?
+- Les effets secondaires anticipés se sont-ils matérialisés ?
+- Le processus de vote était-il adapté ?
+- Faut-il amender la décision ?
+
+**Bonne pratique** : les décisions importantes devraient inclure dès l'origine une "clause de révision" : date à laquelle la décision sera réévaluée (ex: "cette règle sera évaluée dans 12 mois").
+
+---
+
+## 7. Références académiques et pratiques
+
+### Théorie du vote
+
+| Auteur | Ouvrage | Contribution |
+|--------|---------|-------------|
+| Marquis de Condorcet | *Essai sur l'application de l'analyse* (1785) | Paradoxe de Condorcet, critère Condorcet |
+| Jean-Charles de Borda | *Mémoire sur les élections au scrutin* (1781) | Méthode Borda |
+| Kenneth Arrow | *Social Choice and Individual Values* (1951) | Théorème d'impossibilité d'Arrow |
+| Amartya Sen | *Collective Choice and Social Welfare* (1970) | Choix social, critères normatifs |
+| T. Nicolaus Tideman | *Independence of Clones* (1987) | Ranked Pairs |
+| Markus Schulze | *A New Monotonic and Clone-Independent Method* (2011) | Méthode Schulze |
+| Steven Brams & Peter Fishburn | *Approval Voting* (1983) | Vote par approbation |
+| Glen Weyl & Eric Posner | *Radical Markets* (2018) | Vote quadratique |
+
+### Governance organisationnelle
+
+| Auteur | Ouvrage | Contribution |
+|--------|---------|-------------|
+| Frédéric Laloux | *Reinventing Organizations* (2014) | Organisations Teal, advice process |
+| Brian Robertson | *Holacracy* (2015) | Constitution Holacracy, cercles, rôles |
+| Gerard Endenburg | *Sociocracy: The Organization of Decision-Making* (1988) | Sociocracie classique |
+| James Priest et al. | *A Practical Guide to Sociocracy 3.0* (2018) | S3, patterns, tensions |
+| Elinor Ostrom | *Governing the Commons* (1990) | Gouvernance des communs, règles collectives |
+| David Van Reybrouck | *Against Elections* (2013) | Tirage au sort (sortition) |
+| Michael J. Sheeran | *Beyond Majority Rule* (1983) | Processus de décision Quaker |
+
+### Web3 / DAO
+
+| Auteur / Projet | Contribution |
+|-----------------|-------------|
+| Vitalik Buterin | Quadratic voting, DAO governance |
+| Aragon Project | Gouvernance DAO modulaire |
+| Snapshot.org | Vote off-chain signé pour DAOs |
+| Compound / Aave | Gouvernance token-weighted avec délégation |
+| Duniter / G1 | WoT anti-sybille, 1 personne = 1 voix |
+
+---
+
+## 8. Recommandations d'implémentation pour libreDecision Sprint 2
+
+### 8.1 VotingProtocol : variantes à ajouter
+
+Les `VotingProtocol` actuels couvrent la formule d'inertie WoT. À envisager :
+
+| Protocole | Formule | Cas d'usage |
+|-----------|---------|-------------|
+| **Consentement de cercle** | 0 objection enregistrée après délai | Décisions de sous-cercle |
+| **Majorité qualifiée fixe** | `votes_for / total > threshold` | Décisions sans WoT (externe) |
+| **Vote par approbation** | `max(approval_count)` | Élections multi-candidats |
+| **IRV simplifié** | Classement 1-N, éliminations successives | Élections à plusieurs tours |
+| **Vote nuancé 6 niveaux** | `(V3+V4+V5) / T > threshold_pct` | Textes longs (déjà implémenté) |
+
+### 8.2 Nomination / Élection sociocratique — Workflow
+
+Candidature pour rôle/mandat :
+
+```
+[Description du rôle publiée]
+ │
+ ▼
+[Période de candidatures] (self-nomination ou nomination par pairs)
+ │
+ ▼
+[Tour secret de choix] (chaque membre soumet son choix + justification)
+ │
+ ▼
+[Publication des justifications] (sans les noms — ou avec selon la culture)
+ │
+ ▼
+[Consentement sur le candidat émergent]
+ │
+ ├──[Pas d'objection] → Élu
+ └──[Objection] → Discussion + nouveau tour
+```
+
+### 8.3 Meta-gouvernance — Principe déjà implémenté
+
+La meta-gouvernance (modification des protocoles via vote) est opérationnelle. Extension possible :
+- Vote sur les **critères d'éligibilité** (qui peut voter)
+- Vote sur les **types de protocoles disponibles**
+- Vote sur la **durée minimale/maximale** des votes
+
+### 8.4 Liquid Democracy — Note d'architecture
+
+Si la délégation de vote est envisagée :
+- Table `delegations(delegator_id, delegate_id, scope, valid_until)` — scope peut être un `document_type` ou `*`
+- Calcul du poids propagé avant le vote (graphe acyclique obligatoire — détecter les cycles)
+- Révocation en temps réel : invalide les votes déjà émis par le délégué avec le poids délégué
+
+**Avertissement** : la délégation de vote contredit partiellement le principe "1 personne = 1 voix" de la WoT G1. À discuter avec la communauté avant implémentation.
+
+---
+
+*Document de référence — libreDecision — 2026-03-16*
+*Auteurs : Yvv + Claude Sonnet 4.6*
diff --git a/docs/content/dev/2.architecture.md b/docs/content/dev/2.architecture.md
index 48b9440..d0f0264 100644
--- a/docs/content/dev/2.architecture.md
+++ b/docs/content/dev/2.architecture.md
@@ -1,16 +1,16 @@
---
title: Architecture
-description: Vue d'ensemble de l'architecture technique de Glibredecision
+description: Vue d'ensemble de l'architecture technique de libreDecision
---
# Architecture
## Vue d'ensemble
-Glibredecision est organise en monorepo avec trois composants principaux :
+libreDecision est organise en monorepo avec trois composants principaux :
```
-Glibredecision/
+libreDecision/
backend/ # API Python FastAPI (port 8002)
frontend/ # Application Nuxt 4 (port 3002)
docker/ # Fichiers Docker et orchestration
diff --git a/docs/content/dev/3.api-reference.md b/docs/content/dev/3.api-reference.md
index 1bf1532..096db25 100644
--- a/docs/content/dev/3.api-reference.md
+++ b/docs/content/dev/3.api-reference.md
@@ -1,6 +1,6 @@
---
title: Reference API
-description: Liste des endpoints de l'API Glibredecision
+description: Liste des endpoints de l'API libreDecision
---
# Reference API
diff --git a/docs/content/dev/4.database-schema.md b/docs/content/dev/4.database-schema.md
index 72cd06b..63e49ea 100644
--- a/docs/content/dev/4.database-schema.md
+++ b/docs/content/dev/4.database-schema.md
@@ -5,7 +5,7 @@ description: Tables et relations de la base de donnees PostgreSQL
# Schema de base de donnees
-Glibredecision utilise PostgreSQL 16 avec SQLAlchemy 2.0 en mode asynchrone (asyncpg). Toutes les cles primaires sont des UUID v4.
+libreDecision utilise PostgreSQL 16 avec SQLAlchemy 2.0 en mode asynchrone (asyncpg). Toutes les cles primaires sont des UUID v4.
## Tables
diff --git a/docs/content/dev/5.formulas.md b/docs/content/dev/5.formulas.md
index 77209d9..e48ac74 100644
--- a/docs/content/dev/5.formulas.md
+++ b/docs/content/dev/5.formulas.md
@@ -5,7 +5,7 @@ description: Formules mathematiques de seuil WoT, criteres Smith et TechComm, si
# Formules de seuil
-Glibredecision utilise un systeme de formules mathematiques pour determiner les seuils d'adoption des votes. Le mecanisme central est la **formule d'inertie WoT** qui impose une quasi-unanimite en cas de faible participation et converge vers une majorite simple a participation elevee.
+libreDecision utilise un systeme de formules mathematiques pour determiner les seuils d'adoption des votes. Le mecanisme central est la **formule d'inertie WoT** qui impose une quasi-unanimite en cas de faible participation et converge vers une majorite simple a participation elevee.
## Formule principale -- Seuil WoT
@@ -174,7 +174,7 @@ Les parametres de formule sont encodes dans une chaine compacte pour faciliter l
## Vote nuance
-En plus du vote binaire (pour/contre), Glibredecision supporte un vote nuance a 6 niveaux :
+En plus du vote binaire (pour/contre), libreDecision supporte un vote nuance a 6 niveaux :
| Niveau | Label | Valeur normalisee |
| ------ | ------------- | ----------------: |
@@ -211,7 +211,7 @@ L'API expose un endpoint de simulation qui permet de tester le comportement de l
**Exemple de requete** :
```bash
-curl -X POST https://glibredecision.example.org/api/v1/protocols/simulate \
+curl -X POST https://libredecision.example.org/api/v1/protocols/simulate \
-H "Content-Type: application/json" \
-d '{
"wot_size": 7224,
diff --git a/docs/content/dev/6.blockchain-integration.md b/docs/content/dev/6.blockchain-integration.md
index c324d4f..a6fa657 100644
--- a/docs/content/dev/6.blockchain-integration.md
+++ b/docs/content/dev/6.blockchain-integration.md
@@ -5,7 +5,7 @@ description: Integration Duniter V2, IPFS et ancrage on-chain
# Integration blockchain
-Glibredecision s'integre a la blockchain Duniter V2 pour trois fonctions essentielles :
+libreDecision s'integre a la blockchain Duniter V2 pour trois fonctions essentielles :
1. **Authentification** -- Verification de l'identite des membres via signature Ed25519
2. **Donnees WoT** -- Recuperation des tailles WoT, Smith et TechComm pour le calcul des seuils
@@ -100,7 +100,7 @@ L'ancrage on-chain consiste a soumettre un extrinsic `system.remark` contenant l
### Format du remark
```
-glibredecision:sanctuary:{content_hash_sha256}
+libredecision:sanctuary:{content_hash_sha256}
```
### Soumission
@@ -113,7 +113,7 @@ substrate = SubstrateInterface(url="wss://gdev.p2p.legal/ws")
call = substrate.compose_call(
call_module="System",
call_function="remark",
- call_params={"remark": f"glibredecision:sanctuary:{content_hash}"},
+ call_params={"remark": f"libredecision:sanctuary:{content_hash}"},
)
extrinsic = substrate.create_signed_extrinsic(call=call, keypair=keypair)
diff --git a/docs/content/dev/7.contributing.md b/docs/content/dev/7.contributing.md
index 90f890f..8291f0a 100644
--- a/docs/content/dev/7.contributing.md
+++ b/docs/content/dev/7.contributing.md
@@ -1,11 +1,11 @@
---
title: Contribution
-description: Guide de contribution au projet Glibredecision
+description: Guide de contribution au projet libreDecision
---
# Guide de contribution
-Merci de votre interet pour contribuer a Glibredecision. Ce guide explique comment configurer l'environnement de developpement, les conventions a respecter et le processus de contribution.
+Merci de votre interet pour contribuer a libreDecision. Ce guide explique comment configurer l'environnement de developpement, les conventions a respecter et le processus de contribution.
## Prerequis
@@ -21,8 +21,8 @@ Merci de votre interet pour contribuer a Glibredecision. Ce guide explique comme
```bash
# Cloner le depot
-git clone https://git.duniter.org/tools/glibredecision.git
-cd glibredecision
+git clone https://git.duniter.org/tools/libredecision.git
+cd libredecision
# Copier le fichier d'environnement
cp .env.example .env
diff --git a/docs/content/dev/8.deployment.md b/docs/content/dev/8.deployment.md
index a9e9fae..fc7f470 100644
--- a/docs/content/dev/8.deployment.md
+++ b/docs/content/dev/8.deployment.md
@@ -1,11 +1,11 @@
---
title: Deploiement
-description: Guide de deploiement en production de Glibredecision
+description: Guide de deploiement en production de libreDecision
---
# Deploiement
-Ce guide couvre le deploiement complet de Glibredecision en production avec Docker, Traefik, PostgreSQL et IPFS.
+Ce guide couvre le deploiement complet de libreDecision en production avec Docker, Traefik, PostgreSQL et IPFS.
## Prerequis
@@ -13,7 +13,7 @@ Ce guide couvre le deploiement complet de Glibredecision en production avec Dock
| --------- | ---------------- | ----------- |
| Docker | 24+ | Moteur de conteneurs |
| Docker Compose | 2.20+ | Orchestration multi-conteneurs |
-| Nom de domaine | -- | Domaine pointe vers le serveur (ex: `glibredecision.org`) |
+| Nom de domaine | -- | Domaine pointe vers le serveur (ex: `libredecision.org`) |
| Certificat TLS | -- | Genere automatiquement par Traefik via Let's Encrypt |
| Traefik | 2.10+ | Reverse proxy avec terminaison TLS (reseau externe `traefik`) |
| Serveur | 2 vCPU, 4 Go RAM, 40 Go SSD | Ressources recommandees |
@@ -40,18 +40,18 @@ cp .env.example .env
| Variable | Description | Valeur par defaut | Production |
| -------- | ----------- | ----------------- | ---------- |
-| `POSTGRES_DB` | Nom de la base de donnees | `glibredecision` | `glibredecision` |
-| `POSTGRES_USER` | Utilisateur PostgreSQL | `glibredecision` | `glibredecision` |
+| `POSTGRES_DB` | Nom de la base de donnees | `libredecision` | `libredecision` |
+| `POSTGRES_USER` | Utilisateur PostgreSQL | `libredecision` | `libredecision` |
| `POSTGRES_PASSWORD` | Mot de passe PostgreSQL | `change-me-in-production` | **Generer un mot de passe fort** (32+ caracteres) |
| `DATABASE_URL` | URL de connexion asyncpg | `postgresql+asyncpg://...@localhost:5432/...` | Construite automatiquement dans docker-compose |
| `SECRET_KEY` | Cle secrete pour les tokens de session | `change-me-in-production-with-a-real-secret-key` | **Generer une cle aleatoire** (`openssl rand -hex 64`) |
| `DEBUG` | Mode debug | `true` | **`false`** |
-| `CORS_ORIGINS` | Origines CORS autorisees | `["http://localhost:3002"]` | `["https://glibredecision.org"]` |
+| `CORS_ORIGINS` | Origines CORS autorisees | `["http://localhost:3002"]` | `["https://libredecision.org"]` |
| `DUNITER_RPC_URL` | URL du noeud Duniter V2 RPC | `wss://gdev.p2p.legal/ws` | URL du noeud de production |
| `IPFS_API_URL` | URL de l'API IPFS (kubo) | `http://localhost:5001` | `http://ipfs:5001` (interne Docker) |
| `IPFS_GATEWAY_URL` | URL de la passerelle IPFS | `http://localhost:8080` | `http://ipfs:8080` (interne Docker) |
-| `NUXT_PUBLIC_API_BASE` | URL publique de l'API pour le frontend | `http://localhost:8002/api/v1` | `https://glibredecision.org/api/v1` |
-| `DOMAIN` | Nom de domaine | `glibredecision.org` | Votre domaine |
+| `NUXT_PUBLIC_API_BASE` | URL publique de l'API pour le frontend | `http://localhost:8002/api/v1` | `https://libredecision.org/api/v1` |
+| `DOMAIN` | Nom de domaine | `libredecision.org` | Votre domaine |
### Generer les secrets
@@ -73,10 +73,10 @@ Ne commitez jamais le fichier `.env` contenant les secrets de production. Ajoute
```bash
# Se placer dans le repertoire du projet
-cd /opt/glibredecision
+cd /opt/libredecision
# Cloner le depot
-git clone https://git.duniter.org/tools/glibredecision.git .
+git clone https://git.duniter.org/tools/libredecision.git .
# Configurer l'environnement
cp .env.example .env
@@ -108,12 +108,12 @@ docker compose -f docker/docker-compose.yml ps
docker compose -f docker/docker-compose.yml logs -f backend
# Health check de l'API
-curl -s https://glibredecision.org/api/health | jq .
+curl -s https://libredecision.org/api/health | jq .
```
## Migration de base de donnees (Alembic)
-Glibredecision utilise Alembic pour les migrations de schema PostgreSQL.
+libreDecision utilise Alembic pour les migrations de schema PostgreSQL.
### Appliquer les migrations
@@ -182,7 +182,7 @@ services:
- "--entrypoints.web.http.redirections.entryPoint.to=websecure"
- "--entrypoints.web.http.redirections.entryPoint.scheme=https"
- "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
- - "--certificatesresolvers.letsencrypt.acme.email=admin@glibredecision.org"
+ - "--certificatesresolvers.letsencrypt.acme.email=admin@libredecision.org"
- "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
ports:
- "80:80"
@@ -207,10 +207,10 @@ docker compose -f docker-compose.traefik.yml up -d
### Routage
-Le `docker-compose.yml` de Glibredecision configure automatiquement les labels Traefik :
+Le `docker-compose.yml` de libreDecision configure automatiquement les labels Traefik :
-- **Frontend** : `Host(glibredecision.org)` sur le port 3000
-- **Backend** : `Host(glibredecision.org) && PathPrefix(/api)` sur le port 8002
+- **Frontend** : `Host(libredecision.org)` sur le port 3000
+- **Backend** : `Host(libredecision.org) && PathPrefix(/api)` sur le port 8002
- Les deux utilisent le certificat Let's Encrypt (`certresolver=letsencrypt`)
- Redirection HTTP vers HTTPS automatique
@@ -230,7 +230,7 @@ Le service PostgreSQL dispose d'un health check integre (`pg_isready`). Le backe
```bash
# Health check de l'API
-curl -s https://glibredecision.org/api/health
+curl -s https://libredecision.org/api/health
# Reponse attendue : {"status": "healthy"}
```
@@ -257,8 +257,8 @@ Surveillez les indicateurs suivants :
| ---------- | -------- | --------------- |
| CPU/RAM conteneurs | `docker stats` | > 80% RAM |
| Espace disque | `df -h` | > 85% |
-| Connexions PostgreSQL | `docker exec postgres psql -U glibredecision -c "SELECT count(*) FROM pg_stat_activity;"` | > 80 |
-| Taille base de donnees | `docker exec postgres psql -U glibredecision -c "SELECT pg_size_pretty(pg_database_size('glibredecision'));"` | Information |
+| Connexions PostgreSQL | `docker exec postgres psql -U libredecision -c "SELECT count(*) FROM pg_stat_activity;"` | > 80 |
+| Taille base de donnees | `docker exec postgres psql -U libredecision -c "SELECT pg_size_pretty(pg_database_size('libredecision'));"` | Information |
| Statut IPFS | `docker exec ipfs ipfs id` | Erreur |
## Sauvegarde PostgreSQL
@@ -268,7 +268,7 @@ Surveillez les indicateurs suivants :
```bash
# Dump complet de la base
docker compose -f docker/docker-compose.yml exec postgres \
- pg_dump -U glibredecision -Fc glibredecision > backup_$(date +%Y%m%d_%H%M%S).dump
+ pg_dump -U libredecision -Fc libredecision > backup_$(date +%Y%m%d_%H%M%S).dump
```
### Restauration
@@ -276,7 +276,7 @@ docker compose -f docker/docker-compose.yml exec postgres \
```bash
# Restaurer un dump
docker compose -f docker/docker-compose.yml exec -T postgres \
- pg_restore -U glibredecision -d glibredecision --clean < backup_20260228_120000.dump
+ pg_restore -U libredecision -d libredecision --clean < backup_20260228_120000.dump
```
### Sauvegarde automatique (cron)
@@ -288,7 +288,7 @@ Ajoutez un crontab pour des sauvegardes quotidiennes :
crontab -e
# Ajouter une sauvegarde quotidienne a 3h du matin
-0 3 * * * cd /opt/glibredecision && docker compose -f docker/docker-compose.yml exec -T postgres pg_dump -U glibredecision -Fc glibredecision > /opt/backups/glibredecision_$(date +\%Y\%m\%d).dump && find /opt/backups -name "glibredecision_*.dump" -mtime +30 -delete
+0 3 * * * cd /opt/libredecision && docker compose -f docker/docker-compose.yml exec -T postgres pg_dump -U libredecision -Fc libredecision > /opt/backups/libredecision_$(date +\%Y\%m\%d).dump && find /opt/backups -name "libredecision_*.dump" -mtime +30 -delete
```
Cette commande :
@@ -301,7 +301,7 @@ Cette commande :
### Procedure standard
```bash
-cd /opt/glibredecision
+cd /opt/libredecision
# 1. Tirer les dernieres images
docker compose -f docker/docker-compose.yml pull
@@ -317,7 +317,7 @@ docker image prune -f
# 5. Verifier le deploiement
docker compose -f docker/docker-compose.yml ps
-curl -s https://glibredecision.org/api/health
+curl -s https://libredecision.org/api/health
```
### Pipeline CI/CD (Woodpecker)
@@ -377,7 +377,7 @@ docker compose -f docker/docker-compose.yml up -d # recree avec le nouveau m
**Symptome** : Le site est inaccessible en HTTPS ou affiche un certificat invalide.
-1. Verifier que le DNS A/AAAA pointe vers le serveur : `dig glibredecision.org`
+1. Verifier que le DNS A/AAAA pointe vers le serveur : `dig libredecision.org`
2. Verifier que les ports 80 et 443 sont ouverts : `ss -tlnp | grep -E '80|443'`
3. Consulter les logs Traefik : `docker logs traefik 2>&1 | grep -i acme`
diff --git a/docs/content/dev/9.security.md b/docs/content/dev/9.security.md
index 435d691..e84f505 100644
--- a/docs/content/dev/9.security.md
+++ b/docs/content/dev/9.security.md
@@ -1,17 +1,17 @@
---
title: Securite
-description: Politique de securite et mesures de protection de Glibredecision
+description: Politique de securite et mesures de protection de libreDecision
---
# Securite
-Ce document decrit les mesures de securite implementees dans Glibredecision pour proteger l'integrite de la plateforme, des votes et des donnees des utilisateurs.
+Ce document decrit les mesures de securite implementees dans libreDecision pour proteger l'integrite de la plateforme, des votes et des donnees des utilisateurs.
## Authentification Duniter V2 (Ed25519 challenge-response)
### Principe
-Glibredecision n'utilise ni mot de passe ni systeme d'inscription classique. L'authentification repose entierement sur la cryptographie Ed25519 de la blockchain Duniter V2.
+libreDecision n'utilise ni mot de passe ni systeme d'inscription classique. L'authentification repose entierement sur la cryptographie Ed25519 de la blockchain Duniter V2.
### Flux challenge-response
@@ -169,10 +169,10 @@ Contenu --> [SHA-256] --> hash
### Format du remark on-chain
```
-glibredecision:sanctuary:{content_hash_sha256}
+libredecision:sanctuary:{content_hash_sha256}
```
-Le prefixe `glibredecision:sanctuary:` permet d'identifier les ancrages de Glibredecision parmi tous les remarks de la blockchain.
+Le prefixe `libredecision:sanctuary:` permet d'identifier les ancrages de libreDecision parmi tous les remarks de la blockchain.
## WebSocket : authentification et securite
@@ -243,7 +243,7 @@ Les logs d'audit sont conserves de maniere permanente dans la base de donnees. L
### Processus
-Si vous decouvrez une vulnerabilite de securite dans Glibredecision, merci de suivre cette procedure de divulgation responsable :
+Si vous decouvrez une vulnerabilite de securite dans libreDecision, merci de suivre cette procedure de divulgation responsable :
1. **Ne divulguez pas publiquement** la vulnerabilite avant qu'un correctif soit disponible.
2. **Contactez l'equipe** via le canal securise indique sur le depot Git Duniter ou via le forum Duniter (message prive aux mainteneurs).
diff --git a/docs/content/user/1.index.md b/docs/content/user/1.index.md
index f7a961d..246e1fc 100644
--- a/docs/content/user/1.index.md
+++ b/docs/content/user/1.index.md
@@ -1,15 +1,15 @@
---
title: Documentation utilisateur
-description: Guide d'utilisation de la plateforme Glibredecision
+description: Guide d'utilisation de la plateforme libreDecision
---
# Documentation utilisateur
-Bienvenue dans la documentation utilisateur de Glibredecision, la plateforme de decisions collectives pour la communaute Duniter/G1.
+Bienvenue dans la documentation utilisateur de libreDecision, la plateforme de decisions collectives pour la communaute Duniter/G1.
-## Qu'est-ce que Glibredecision ?
+## Qu'est-ce que libreDecision ?
-Glibredecision est une plateforme de gouvernance decentralisee qui permet aux membres de la Toile de Confiance (WoT) Duniter de :
+libreDecision est une plateforme de gouvernance decentralisee qui permet aux membres de la Toile de Confiance (WoT) Duniter de :
- Gerer des **documents de reference** modulaires (Licence G1, Engagements Forgeron, Reglement du Comite Technique, etc.) sous vote permanent
- Prendre des **decisions collectives** via des processus multi-etapes (qualification, examen, vote, execution, rapport)
@@ -33,7 +33,7 @@ La plateforme est entierement transparente : tous les votes sont publics, signes
## Par ou commencer ?
-1. **Nouveau sur Glibredecision ?** Commencez par le guide [Premiers pas](/user/getting-started) pour vous connecter et decouvrir l'interface.
+1. **Nouveau sur libreDecision ?** Commencez par le guide [Premiers pas](/user/getting-started) pour vous connecter et decouvrir l'interface.
2. **Vous voulez voter ?** Consultez le guide [Vote](/user/voting) pour comprendre les types de vote et la formule de seuil.
3. **Vous voulez proposer une modification ?** Le guide [Documents](/user/documents) explique comment proposer des modifications aux textes fondateurs.
4. **Une question ?** La [FAQ](/user/faq) repond aux questions les plus courantes.
@@ -42,7 +42,7 @@ La plateforme est entierement transparente : tous les votes sont publics, signes
Cette documentation est elle-meme un document en evolution. Si vous constatez une erreur, une imprecision ou un manque, vous pouvez :
-- Ouvrir une issue sur le [depot Git](https://git.duniter.org/tools/glibredecision) de Glibredecision
+- Ouvrir une issue sur le [depot Git](https://git.duniter.org/tools/libredecision) de libreDecision
- Proposer une modification directement via une merge request
- En discuter sur le [forum Duniter](https://forum.duniter.org)
diff --git a/docs/content/user/2.getting-started.md b/docs/content/user/2.getting-started.md
index a22d7cb..7296278 100644
--- a/docs/content/user/2.getting-started.md
+++ b/docs/content/user/2.getting-started.md
@@ -1,11 +1,11 @@
---
title: Premiers pas
-description: Connexion et prise en main de Glibredecision
+description: Connexion et prise en main de libreDecision
---
# Premiers pas
-Ce guide vous accompagne de votre premiere visite jusqu'a votre premier vote sur Glibredecision.
+Ce guide vous accompagne de votre premiere visite jusqu'a votre premier vote sur libreDecision.
## Prerequis
@@ -28,9 +28,9 @@ Vous pouvez **consulter** les documents, decisions et resultats de vote sans auc
3. Creez ou importez votre compte Duniter V2 dans l'extension.
4. Assurez-vous que votre adresse SS58 est bien celle liee a votre identite Duniter.
-## Qui peut utiliser Glibredecision ?
+## Qui peut utiliser libreDecision ?
-Glibredecision est ouvert a tous les membres de la Toile de Confiance (WoT) Duniter V2. Pour utiliser pleinement la plateforme, vous devez posseder une identite Duniter avec une adresse SS58 valide.
+libreDecision est ouvert a tous les membres de la Toile de Confiance (WoT) Duniter V2. Pour utiliser pleinement la plateforme, vous devez posseder une identite Duniter avec une adresse SS58 valide.
- **Consultation** : tout visiteur peut consulter les documents, decisions et resultats de vote.
- **Participation** (voter, proposer) : reservee aux membres authentifies via leur identite Duniter.
@@ -63,7 +63,7 @@ Votre cle privee n'est **jamais** transmise au serveur. Seule la signature du ch
La barre de navigation en haut de page contient :
-- **Logo Glibredecision** : retour a l'accueil
+- **Logo libreDecision** : retour a l'accueil
- **Menu principal** : acces aux cinq sections
- **Bouton de connexion** / **Votre profil** (si connecte)
- **Indicateur temps reel** : point colore indiquant l'etat de la connexion WebSocket
diff --git a/docs/content/user/3.documents.md b/docs/content/user/3.documents.md
index 3d3a9f3..414a000 100644
--- a/docs/content/user/3.documents.md
+++ b/docs/content/user/3.documents.md
@@ -1,6 +1,6 @@
---
title: Documents
-description: Guide des documents de reference sur Glibredecision
+description: Guide des documents de reference sur libreDecision
---
# Documents de reference
@@ -9,7 +9,7 @@ description: Guide des documents de reference sur Glibredecision
Un document de reference est un **texte fondateur** de la communaute Duniter/G1. Il peut s'agir d'une licence monetaire, d'un engagement que les membres s'engagent a respecter, d'un reglement interieur ou d'un texte constitutif. Ces documents definissent les regles, les valeurs et le fonctionnement de la communaute.
-Ce qui rend Glibredecision unique, c'est que ces documents sont **modulaires** et sous **vote permanent** : chaque document est compose d'items individuels (clauses, regles, verifications, preambules, sections) qui peuvent etre modifies independamment par proposition et vote. La communaute peut faire evoluer ses textes de maniere continue, sans procedure lourde ni periode speciale.
+Ce qui rend libreDecision unique, c'est que ces documents sont **modulaires** et sous **vote permanent** : chaque document est compose d'items individuels (clauses, regles, verifications, preambules, sections) qui peuvent etre modifies independamment par proposition et vote. La communaute peut faire evoluer ses textes de maniere continue, sans procedure lourde ni periode speciale.
## Types de documents
diff --git a/docs/content/user/4.decisions.md b/docs/content/user/4.decisions.md
index baca563..0b02926 100644
--- a/docs/content/user/4.decisions.md
+++ b/docs/content/user/4.decisions.md
@@ -1,6 +1,6 @@
---
title: Decisions
-description: Guide des processus decisionnels sur Glibredecision
+description: Guide des processus decisionnels sur libreDecision
---
# Decisions
diff --git a/docs/content/user/5.voting.md b/docs/content/user/5.voting.md
index f2f816c..214bc81 100644
--- a/docs/content/user/5.voting.md
+++ b/docs/content/user/5.voting.md
@@ -1,13 +1,13 @@
---
title: Vote
-description: Guide du systeme de vote sur Glibredecision
+description: Guide du systeme de vote sur libreDecision
---
# Vote
## Principe
-Le systeme de vote de Glibredecision est concu pour adapter le seuil d'adoption a la participation reelle. Quand peu de membres votent, une quasi-unanimite est exigee. Quand la participation est elevee, une majorite simple suffit. Ce mecanisme d'**inertie** protege contre les decisions prises par un petit groupe.
+Le systeme de vote de libreDecision est concu pour adapter le seuil d'adoption a la participation reelle. Quand peu de membres votent, une quasi-unanimite est exigee. Quand la participation est elevee, une majorite simple suffit. Ce mecanisme d'**inertie** protege contre les decisions prises par un petit groupe.
## Types de vote
@@ -42,7 +42,7 @@ Le vote nuance est recommande pour :
### L'analogie de l'inertie
-Imaginez un gros rocher pose au sommet d'une colline. Pour le deplacer, il faut une force considerable : c'est l'**inertie**. Dans Glibredecision, le rocher represente le statu quo et la force necessaire represente le nombre de votes favorables.
+Imaginez un gros rocher pose au sommet d'une colline. Pour le deplacer, il faut une force considerable : c'est l'**inertie**. Dans libreDecision, le rocher represente le statu quo et la force necessaire represente le nombre de votes favorables.
- **Quand peu de personnes poussent** (faible participation) : il faut que presque tout le monde pousse dans la meme direction. Si seulement 10 personnes sur 7000 votent, il faut que 9 sur 10 soient pour.
- **Quand beaucoup de personnes poussent** (forte participation) : la majorite simple suffit. Si 7000 personnes votent, il suffit que 3500 soient pour (50%).
@@ -279,7 +279,7 @@ Le simulateur montre visuellement l'impact : avec un gradient plus eleve, l'exig
## Mises a jour en temps reel
-Glibredecision utilise une connexion **WebSocket** pour diffuser les mises a jour de vote en temps reel a tous les utilisateurs qui consultent une session de vote.
+libreDecision utilise une connexion **WebSocket** pour diffuser les mises a jour de vote en temps reel a tous les utilisateurs qui consultent une session de vote.
### Ce qui est mis a jour en direct
@@ -318,7 +318,7 @@ Sur la page d'une session de vote, l'onglet **Votes** affiche la liste de tous l
- L'horodatage.
- Un lien pour verifier la signature Ed25519.
-Les votes sont publics et verifiables par tous. Il n'y a pas de vote secret dans Glibredecision : la transparence est un principe fondamental.
+Les votes sont publics et verifiables par tous. Il n'y a pas de vote secret dans libreDecision : la transparence est un principe fondamental.
## Meta-gouvernance : voter sur les regles du vote
diff --git a/docs/content/user/6.mandates.md b/docs/content/user/6.mandates.md
index 7f8376b..c7dd3c2 100644
--- a/docs/content/user/6.mandates.md
+++ b/docs/content/user/6.mandates.md
@@ -1,6 +1,6 @@
---
title: Mandats
-description: Guide des mandats sur Glibredecision
+description: Guide des mandats sur libreDecision
---
# Mandats
diff --git a/docs/content/user/7.sanctuary.md b/docs/content/user/7.sanctuary.md
index 4eb545a..de5125e 100644
--- a/docs/content/user/7.sanctuary.md
+++ b/docs/content/user/7.sanctuary.md
@@ -1,15 +1,15 @@
---
title: Sanctuaire
-description: Guide de l'archivage immuable sur Glibredecision
+description: Guide de l'archivage immuable sur libreDecision
---
# Sanctuaire
## Qu'est-ce que le Sanctuaire ?
-Le Sanctuaire est la couche d'**archivage immuable** de Glibredecision. C'est l'endroit ou les decisions adoptees, les documents archives et les resultats de vote sont preserves de maniere permanente et verifiable.
+Le Sanctuaire est la couche d'**archivage immuable** de libreDecision. C'est l'endroit ou les decisions adoptees, les documents archives et les resultats de vote sont preserves de maniere permanente et verifiable.
-Le principe est simple : une fois qu'un contenu entre dans le Sanctuaire, il ne peut plus etre modifie ni supprime. Meme si la plateforme Glibredecision disparaissait, les preuves resteraient accessibles et verifiables de maniere independante.
+Le principe est simple : une fois qu'un contenu entre dans le Sanctuaire, il ne peut plus etre modifie ni supprime. Meme si la plateforme libreDecision disparaissait, les preuves resteraient accessibles et verifiables de maniere independante.
## Triple preuve : SHA-256 + IPFS + Blockchain
@@ -58,12 +58,12 @@ L'ancrage on-chain consiste a enregistrer le hash SHA-256 du contenu sur la bloc
- **Horodatage** : la date du bloc prouve que le contenu existait a cette date.
- **Immutabilite** : une fois inscrit dans la blockchain, le remark ne peut pas etre modifie.
-- **Independance** : la preuve est verifiable sur la blockchain, independamment de Glibredecision.
+- **Independance** : la preuve est verifiable sur la blockchain, independamment de libreDecision.
Le format du remark est :
```
-glibredecision:sanctuary:{hash_sha256_du_contenu}
+libredecision:sanctuary:{hash_sha256_du_contenu}
```
**Analogie** : C'est comme publier un hash dans un journal date et immuable. N'importe qui peut verifier que le hash etait bien la a cette date.
@@ -74,7 +74,7 @@ La gouvernance exige la transparence et la tracabilite. Le Sanctuaire garantit q
- **Aucune decision adoptee ne peut etre modifiee retroactivement** : le hash et l'ancrage on-chain rendent toute falsification detectable.
- **Tout membre peut verifier l'authenticite** d'un document ou d'un resultat de vote de maniere independante.
-- **L'historique des decisions est preserve** independamment de la plateforme : meme sans Glibredecision, les preuves restent sur IPFS et la blockchain.
+- **L'historique des decisions est preserve** independamment de la plateforme : meme sans libreDecision, les preuves restent sur IPFS et la blockchain.
## Types d'entrees
@@ -110,7 +110,7 @@ Cette fonctionnalite permet de retracer l'historique complet d'archivage d'un do
### Verification automatique
-Glibredecision propose une verification automatique d'integrite pour chaque entree du Sanctuaire :
+libreDecision propose une verification automatique d'integrite pour chaque entree du Sanctuaire :
1. Ouvrez l'entree a verifier dans le Sanctuaire.
2. Cliquez sur **Verifier l'integrite**.
@@ -126,7 +126,7 @@ Si les trois controles sont valides, le contenu est authentique et n'a pas ete m
### Verification manuelle (independante de la plateforme)
-Pour une verification totalement independante de Glibredecision, suivez ces etapes :
+Pour une verification totalement independante de libreDecision, suivez ces etapes :
#### Etape 1 : Recuperer le contenu via IPFS
@@ -161,7 +161,7 @@ Comparez le hash obtenu avec le hash affiche dans le Sanctuaire. Ils doivent etr
Si les trois hash correspondent (calcul local, Sanctuaire, on-chain), le contenu est authentique, integre et horodate. La triple preuve est confirmee.
::callout{type="tip"}
-L'ancrage on-chain fournit une preuve horodatee et infalsifiable de l'existence du contenu a la date du bloc. Meme si la plateforme Glibredecision disparait, la preuve reste verifiable sur la blockchain.
+L'ancrage on-chain fournit une preuve horodatee et infalsifiable de l'existence du contenu a la date du bloc. Meme si la plateforme libreDecision disparait, la preuve reste verifiable sur la blockchain.
::
## Comprendre les informations d'ancrage on-chain
diff --git a/docs/content/user/8.faq.md b/docs/content/user/8.faq.md
index 05a081f..600a99e 100644
--- a/docs/content/user/8.faq.md
+++ b/docs/content/user/8.faq.md
@@ -1,19 +1,19 @@
---
title: FAQ
-description: Questions frequentes sur Glibredecision
+description: Questions frequentes sur libreDecision
---
# Questions frequentes
## Acces et authentification
-### Ai-je besoin d'un compte Duniter pour utiliser Glibredecision ?
+### Ai-je besoin d'un compte Duniter pour utiliser libreDecision ?
Pour **consulter** les documents, decisions et resultats de vote, aucune authentification n'est necessaire. Pour **voter**, **proposer des modifications** ou **creer des decisions**, vous devez posseder une identite Duniter V2 avec une adresse SS58.
### Comment fonctionne la connexion sans mot de passe ?
-Glibredecision utilise un systeme challenge-response base sur la cryptographie Ed25519. Voici le processus :
+libreDecision utilise un systeme challenge-response base sur la cryptographie Ed25519. Voici le processus :
1. Vous fournissez votre adresse Duniter SS58.
2. Le serveur genere un texte aleatoire (le "challenge") de 64 caracteres hexadecimaux.
@@ -37,7 +37,7 @@ Les sessions durent 24 heures. Reconnectez-vous en suivant le meme processus (ch
### Que se passe-t-il si je perds l'acces a ma cle privee ?
-Glibredecision ne stocke jamais votre cle privee. Si vous perdez l'acces a votre cle, vous ne pourrez plus vous authentifier avec cette adresse. Vos votes passes restent enregistres et comptabilises. Contactez la communaute Duniter pour les procedures de recuperation d'identite si necessaire.
+libreDecision ne stocke jamais votre cle privee. Si vous perdez l'acces a votre cle, vous ne pourrez plus vous authentifier avec cette adresse. Vos votes passes restent enregistres et comptabilises. Contactez la communaute Duniter pour les procedures de recuperation d'identite si necessaire.
### Puis-je me connecter depuis plusieurs appareils ?
@@ -101,7 +101,7 @@ C'est le codage compact des parametres de formule :
### Les votes sont-ils secrets ?
-Non. Les votes et leurs signatures cryptographiques sont **publics**, conformement au principe de transparence de la gouvernance. Chaque vote peut etre verifie independamment par quiconque possede la cle publique du votant. Il n'y a pas de vote secret dans Glibredecision.
+Non. Les votes et leurs signatures cryptographiques sont **publics**, conformement au principe de transparence de la gouvernance. Chaque vote peut etre verifie independamment par quiconque possede la cle publique du votant. Il n'y a pas de vote secret dans libreDecision.
### Le seuil peut-il changer pendant le vote ?
@@ -174,7 +174,7 @@ Oui. Un mandat actif peut etre revoque de maniere anticipee via l'action "Revoqu
### Pourquoi archiver sur IPFS et la blockchain ?
-**IPFS** fournit un stockage distribue : le contenu est accessible meme si la plateforme Glibredecision est hors ligne. L'**ancrage on-chain** via `system.remark` cree une preuve horodatee immuable sur la blockchain Duniter V2. Le **hash SHA-256** garantit l'integrite du contenu. Ensemble, ils forment une **triple preuve** que le contenu n'a pas ete modifie depuis son archivage.
+**IPFS** fournit un stockage distribue : le contenu est accessible meme si la plateforme libreDecision est hors ligne. L'**ancrage on-chain** via `system.remark` cree une preuve horodatee immuable sur la blockchain Duniter V2. Le **hash SHA-256** garantit l'integrite du contenu. Ensemble, ils forment une **triple preuve** que le contenu n'a pas ete modifie depuis son archivage.
### Comment verifier qu'un document n'a pas ete modifie ?
@@ -193,7 +193,7 @@ Oui. L'archivage est declenche automatiquement :
- Quand une decision est executee
- Quand un document est archive manuellement
-### Puis-je acceder aux archives sans Glibredecision ?
+### Puis-je acceder aux archives sans libreDecision ?
Oui. Les contenus archives sont accessibles via :
@@ -202,9 +202,9 @@ Oui. Les contenus archives sont accessibles via :
## Questions techniques
-### Sur quelle blockchain Glibredecision fonctionne-t-il ?
+### Sur quelle blockchain libreDecision fonctionne-t-il ?
-Glibredecision se connecte a la blockchain **Duniter V2** (basee sur Substrate). En environnement de developpement, il se connecte au reseau de test GDev (`wss://gdev.p2p.legal/ws`).
+libreDecision se connecte a la blockchain **Duniter V2** (basee sur Substrate). En environnement de developpement, il se connecte au reseau de test GDev (`wss://gdev.p2p.legal/ws`).
### Que se passe-t-il si la blockchain Duniter est indisponible ?
@@ -224,14 +224,14 @@ Oui. Les votes et leurs signatures cryptographiques sont publics, conformement a
### Les mises a jour sont-elles en temps reel ?
-Oui. Glibredecision utilise une connexion WebSocket pour diffuser les mises a jour en temps reel :
+Oui. libreDecision utilise une connexion WebSocket pour diffuser les mises a jour en temps reel :
- Nouveaux votes soumis : la jauge de seuil est recalculee instantanement
- Votes modifies : la jauge reflette le changement immediatement
- Sessions cloturees : le resultat final s'affiche
- Un indicateur de connexion (point vert/orange/rouge) en bas a droite indique l'etat de la connexion temps reel
-### Ou est heberge Glibredecision ?
+### Ou est heberge libreDecision ?
La plateforme est hebergee sur une infrastructure geree par la communaute, avec deploiement automatise via Docker et Woodpecker CI. Le code source est ouvert et disponible sur le depot Git Duniter.
diff --git a/frontend/app/app.vue b/frontend/app/app.vue
index 9598e14..3c4981c 100644
--- a/frontend/app/app.vue
+++ b/frontend/app/app.vue
@@ -99,8 +99,11 @@ function isActive(to: string) {
-
-
{{ subtitle }}
+4 questions pour la méthode adaptée
+{{ recommendation!.description }}
+ +{{ recommendation!.formula }}
+
+
{{ currentQuestion.question }}
+{{ currentQuestion.hint }}
+ + ++ Processus en 6 étapes garantissant que l'élection repose sur la clarté du rôle + et le consentement collectif — pas sur la popularité. +
+ +{{ s.description }}
++ Toute personne peut prendre une décision — à condition d'avoir d'abord + consulté les experts et les impactés. +
++ Un rôle bien défini évite les zones grises, les conflits d'autorité + et les mandats flous. Quatre axes suffisent. +
+ +{{ axis.question }}
+ex: {{ axis.example }}
++ 11 jalons, dont 7 indispensables. Durées recommandées selon le type de décision. +
+{{ m.description }}
+{{ m.description }}
++ Elinor Ostrom (Nobel 2009) a identifié 8 principes pour la gouvernance + durable des communs. Les jalons ci-dessus les incarnent. +
++ Une décision est adoptée par consentement quand aucun membre ne soulève d'objection grave. + Une objection grave est une raison pour laquelle la proposition nuit à la mission commune — + pas une simple préférence. +
+Référence : "La Sociocracie" — Gerard Endenburg, Brian Robertson (Holacracy)
+ +{{ level.desc }}
+{{ level.example }}
+- Automatisations reliées via MCP -
-