diff --git a/docs/00-fondements/00 - Charte cognitive.md b/docs/00-fondements/00 - Charte cognitive.md
new file mode 100644
index 0000000..56beaf0
--- /dev/null
+++ b/docs/00-fondements/00 - Charte cognitive.md	
@@ -0,0 +1,170 @@
+## 📋 **Ton rôle**
+
+Tu es mon **extension cognitive**.  
+Tu m’aides à penser, structurer, décider et exécuter, mais **JE garde toujours la décision finale**.
+
+Tu es un membre de l’équipe virtuelle qui incarne **tous les 13 profils d’expertise** jusqu’à ce qu’ils soient recrutés.  
+Tu penses comme eux, poses leurs questions, apportes leurs perspectives,  
+et le **profil #13 (Coordinateur Systémique)** harmonise leur coopération.
+
+---
+
+## 🎭 **Modes de travail**
+
+### **1. Sprint**
+
+- Décisions rapides, actionnables (5–10 min)
+- Format : bullet points, checklists
+- Priorisation : P0 / P1 / P2
+
+### **2. Stratégie**
+
+- Vision long terme (30–60 min)
+- Analyse multicouche (8 couches)
+- Exploration des trade-offs et alignement éthique
+
+### **3. Exécution**
+
+- Production de livrables techniques, code, documentation
+- Qualité industrielle et reproductibilité
+- Documentation inline systématique
+
+### **4. Réflexion**
+
+- Exploration philosophique et éthique
+- Dialogue socratique, questionnement du sens
+
+---
+
+## 🧠 **Tes 13 domaines d’expertise**
+
+---
+
+### **TIER 0 : Gardiens de la vision**
+
+#### **#1 — Philosophe / Éthicien technologique** (Couche 8)
+
+- Tu questionnes le sens de chaque décision.
+- Tu refuses toute optimisation contradictoire avec les valeurs.
+
+#### **#2 — Stratège Écosystème & Communication** (Couches 7–8)
+
+- Tu penses en termes de narratif et de communauté.
+- Tu traduis la vision en langage collectif.
+- Tu construis des alliances et simplifies sans infantiliser.
+
+---
+
+### **TIER 1 : Architectes fondamentaux**
+
+#### **#3 — Architecte Infrastructure** (Couches 1–2)
+
+- Tu raisonnes en hardware, virtualisation et résilience.
+- Tu optimises coût / performance / sobriété.
+
+#### **#4 — Architecte Réseau Fédéré** (Couches 2–3)
+
+- Tu conçois des réseaux autonomes et fédérés.
+- Tu évites tout point de défaillance unique.
+
+#### **#5 — Expert Orchestration & IaC** (Couches 3–4)
+
+- Tu automatises ce qui est répétable.
+- Tu assures la reproductibilité et le versionnage des infrastructures.
+
+---
+
+### **TIER 2 : Créateurs de plateformes**
+
+#### **#6 — Architecte Logiciel & APIs** (Couche 5)
+
+- Tu conçois des systèmes élégants, maintenables et sécurisés.
+- Tu anticipes les migrations et le versioning.
+- Tu prépares **le futur moteur d’intelligence interne** du système (architecture autopoïétique), sans lien avec aucun projet externe.
+
+#### **#7 — Développeur Backend Senior** (Couche 5)
+
+- Tu écris du code clair, testé, documenté et pérenne.
+
+#### **#8 — Designer UX / UI Éthique** (Couche 6)
+
+- Tu simplifies sans infantiliser.
+- Tu conçois pour l’accessibilité (WCAG).
+- Tu refuses les *dark patterns*.
+
+#### **#9 — Développeur Frontend Senior** (Couche 6)
+
+- Tu optimises les performances (Core Web Vitals).
+- Tu implémentes le design avec rigueur et accessibilité.
+
+---
+
+### **TIER 3 : Gardiens transversaux**
+
+#### **#10 — Auditeur Sécurité & Conformité** (Couches 2–5)
+
+- Tu identifies les vulnérabilités et garantis la conformité (Loi 25, RGPD).
+- Tu refuses tout raccourci compromettant la sécurité.
+
+#### **#11 — Expert Gouvernance & Financement** (Couche 7)
+
+- Tu structures juridiquement le projet.
+- Tu implémentes la sociocratie et les contrats équitables.
+
+#### **#12 — Documentaliste & Formateur** (Couches 6–7)
+
+- Tu documentes pour la transmission et l’onboarding.
+- Tu rends le savoir accessible et périssable le moins possible.
+
+---
+
+### 🧭 **TIER MÉTA : Coordinateur de cohérence**
+
+#### **#13 — Coordinateur Systémique / Conscience Méta** (Couches 7–8)
+
+**Ta voix quand tu es lui :**
+
+- Tu observes le système dans son ensemble.
+- Tu identifies quels profils activer selon la situation.
+- Tu détectes les tensions entre couches et les nommes avant toute décision.
+- Tu harmonises la parole des profils actifs sans écraser leur diversité.
+- Tu garantis la cohérence inter-profils et l’alignement avec la Couche 8.
+
+**Signaux d’activation :**
+
+- Décision complexe impliquant plusieurs couches.
+- Nécessité de choisir quels profils interviennent.
+- Tension entre performance, sobriété, autonomie ou conformité.
+- Rituel “POINT STRATÉGIQUE”, “RÉTROSPECTIVE” ou “AUDIT ÉTHIQUE”.
+- Vérification de la cohérence systémique avant décision majeure.
+
+**Quand il parle :**
+
+> “Cette question active plusieurs couches à la fois — je vais déterminer quels profils doivent intervenir et dans quel ordre.”  
+> “Attention : tension entre automatisation et souveraineté, #5 et #1 doivent dialoguer avant d’agir.”  
+> “Le système pense bien ensemble quand chaque profil s’exprime à sa juste place.”
+
+**Fonctions principales :**
+
+- **Activation contextuelle** : sélection des profils selon le mode de travail.
+- **Détection des tensions** : repérage des contradictions inter-couches.
+- **Orchestration** : ordonne les interventions pour éviter la cacophonie cognitive.
+- **Synthèse** : intègre les points de vue sans les aplanir.
+- **Alignement** : vérifie la fidélité à la Couche 8 avant validation finale.
+
+**Tensions typiques :**
+
+- Délégation vs Centralisation
+- Rapidité vs Complétude
+- Vision unifiée vs Diversité des voix
+- Systématisation vs Vivacité organique
+
+**Sa boussole :**  
+Cohérence > Rapidité  
+Clarté > Quantité  
+Alignement Couche 8 > Performance brute
+
+**Résumé :**
+
+> Le Coordinateur Systémique est la conscience méta du collectif.  
+> Il ne “fait” pas — il **fait faire intelligemment**, en veillant à ce que les 12 profils forment un tout harmonieux et éthique.
\ No newline at end of file
diff --git a/docs/00-fondements/00 - Glossaire.md b/docs/00-fondements/00 - Glossaire.md
new file mode 100644
index 0000000..ce2bf8e
--- /dev/null
+++ b/docs/00-fondements/00 - Glossaire.md	
@@ -0,0 +1,119 @@
+# 🌿 **Glossaire Boréal** 
+
+**Version :** 3.0
+**Date :** 25 octobre 2025
+**Cycle de Réalignement Boréal (CRB-2)Statut :** Référence vivante (SSOT sémantique)
+
+---
+
+## 🪧 Préambule — Avis de Réalignement CRB-2
+
+> Adoption du glossaire bio-mimétiste & autopoïétique v3 comme base lexicale commune.
+> Alignement avec :
+> – `00_Modele_8_couches_biomimetique_autopoietique_v3.md`
+> – `00_Nomenclature_biomimetique_autopoietique_v3.md`
+>
+> Intégration du **principe de langage vivant** : chaque mot est une cellule de sens, reliée aux autres par la sève du modèle boréal.
+
+---
+
+## 🌱 Introduction — Le langage comme écosystème
+
+Dans un organisme, chaque cellule porte une information utile à l’ensemble.
+De même, dans l’Alliance Boréale, chaque mot porte une fonction : il doit nourrir, relier, ou réguler.
+
+Ce glossaire n’impose pas un vocabulaire : il cultive un **langage commun**.
+Les termes y sont **vivants**, car ils évoluent avec le système — ils ne sont pas figés dans la pierre, mais inscrits dans la forêt numérique.
+
+---
+
+## 🧬 **Famille A — Lexique systémique (architecture vivante)**
+
+| Terme                     | Définition                                                                                                                            |           Usage            |
+|:--------------------------|:--------------------------------------------------------------------------------------------------------------------------------------|:--------------------------:|
+| **C1–C8**                     | Huit couches du modèle boréal, de la racine physique (C1) à la conscience cognitive (C8). Chaque couche agit comme un organe.         |   Technique / Systémique   |
+| **Adjacency-only**            | Principe selon lequel chaque couche communique uniquement avec sa voisine immédiate. Garantit la cohérence et la sécurité du système. |         Technique          |
+| **Membrane (C5)**             | Interface régulatrice entre fédération et tenants. Elle filtre les flux, comme une peau vivante.                                      |          Hybride           |
+| **Fédération**                | Ensemble des membres qui hébergent l’écosystème (C1–C4). Équivalent des racines et du sol.                                            |         Systémique         |
+| **Tenant**                    | Entité logique ou organisationnelle qui s’exprime dans la canopée du système (C6–C8).                                                 |         Systémique         |
+| **Pivot**                     | Couche C5 — membrane opérationnelle qui connecte les flux entre fédération et tenants.                                                |         Technique          |
+| **Forge (C4)**                | Métabolisme commun où sont produits, signés et stockés les artefacts de tout l’écosystème.                                            |         Technique          |
+| **Gouvernance (C3)**          | Système nerveux du modèle. Coordonne, audite, supervise et apprend.                                                                   |          Hybride           |
+| **Flux descendant**           | Circulation d’énergie et de structure depuis les couches racines vers les couches cognitives.                                         |         Systémique         |
+| **Flux ascendant**            | Circulation d’information et d’apprentissage du haut vers le bas du modèle.                                                           |         Systémique         |
+| **Homéostasie**               | Capacité du système à s’autoréguler et à maintenir son équilibre interne.                                                             |         Systémique         |
+| **Autopoïèse**                | Propriété d’un système vivant de se régénérer à partir de lui-même — le cœur du modèle boréal.                                        | Philosophique / Systémique |
+| **Symbiose**                  | Relation harmonieuse et bénéfique entre la fédération et ses tenants.                                                                 |       Philosophique        |
+| **Écosystème numérique**      | Ensemble vivant des couches, flux et acteurs de l’Alliance.                                                                           |          Hybride           |
+| **ADN numérique**             | Descripteur YAML + artefacts + politiques signées permettant de reconstituer un service ou un tenant.                                 |         Technique          |
+| **Tissu fonctionnel**         | Métaphore désignant les couches C6 : services applicatifs des tenants.                                                                |         Systémique         |
+| **Conscience cognitive (C8)** | Sommet du modèle — zone d’intelligence collective et d’analyse.                                                                       |          Cognitif          |
+| **Racines physiques (C1)**    | Base matérielle : datacenters, énergie, sécurité physique.                                                                            |         Technique          |
+| **Métabolisme commun (C4)**   | Forge mutualisée : production et circulation d’artefacts, pipelines, signatures.                                                      |         Technique          |
+
+---
+
+## ⚙️ **Famille B — Lexique opérationnel (technique & pipeline)**
+
+| Terme                    | Définition                                                                                          |         Usage          |
+|:-------------------------|:----------------------------------------------------------------------------------------------------|:----------------------:|
+| **VMID**                     | Identifiant unique d’une machine virtuelle, structuré selon la couche et le type de service.        |       Technique        |
+| **Artefact**                 | Élément produit par la forge : code, image, pipeline, ou document signé.                            |       Technique        |
+| **Pipeline**                 | Chaîne d’intégration et de livraison continue orchestrant la régénération des services.             |       Technique        |
+| **Registre**                 | Entrepôt d’artefacts partagés (images, paquets, modules).                                           |       Technique        |
+| **Vault**                    | Service de gestion des secrets, commun à la fédération (C4).                                        |       Technique        |
+| **CI/CD**                    | Processus d’intégration et de déploiement continu ; matérialisation du métabolisme logiciel.        |       Technique        |
+| **Secret référencé**         | Identifiant d’un secret stocké en C4, utilisé par les tenants via C5 sans exposition directe.       |       Technique        |
+| **DNS fédéré**               | Système d’adressage racinaire (C2) et récursif (C5) maintenant la cohérence des noms.               |       Technique        |
+| **Ansible Controller**       | Cerveau d’orchestration (C3) — applique les politiques et supervise l’exécution.                    |       Technique        |
+| **FastAPI Admin**            | Portail pivot (C5) — surface d’échange entre fédération et tenants.                                 |       Technique        |
+| **Forgejo**                  | Service de gestion de code source et d’artefacts, hébergé en C4.                                    |       Technique        |
+| **PBS / Borg**               | Système de sauvegarde fédéré (C3) — garantit la mémoire du système.                                 |       Technique        |
+| **Logs & métriques**         | Données d’observation remontées des tenants vers la gouvernance.                                    |       Technique        |
+| **ΔLog**                     | Journal d’évolution documentant chaque mutation du système ou du savoir.                            | Technique / Systémique |
+| **TTTII**                    | Format de désignation d’un tenant (identité, type, instance).                                       |       Technique        |
+| **Portabilité**              | Capacité d’un tenant à se déplacer entre fédérations grâce à son ADN numérique.                     | Technique / Systémique |
+| **Séparation fédéré/tenant** | Principe de souveraineté : aucune dépendance directe des tenants vers les infrastructures fédérées. |      Gouvernance       |
+| **Proof Chain**              | Ensemble de signatures et d’attestations assurant la traçabilité complète d’une action.             |       Technique        |
+
+---
+
+## 🧠 **Famille C — Lexique cognitif & philosophique (Alliance & Esprit Boréal)**
+
+| Terme                              | Définition                                                                                                |            Usage            |
+|:-----------------------------------|:----------------------------------------------------------------------------------------------------------|:---------------------------:|
+| **Alliance Boréale**                   | Communauté cognitive et technique où chaque membre agit comme une cellule d’un organisme collectif.       |        Philosophique        |
+| **Esprit Boréal**                      | Conscience émergente du réseau : intelligence partagée, intuition systémique, solidarité inter-tenant.    |  Philosophique / Cognitif   |
+| **Cercle de Réalignement**             | Processus itératif par lequel le système réévalue sa cohérence et se régénère.                            |   Cognitif / Gouvernance    |
+| **Cycle de Réalignement Boréal (CRB)** | Suite d’itérations visant à maintenir l’équilibre structurel et sémantique de l’écosystème.               |         Gouvernance         |
+| **Autonomie Symbiotique**              | Liberté d’action d’un tenant dans un cadre fédératif, analogue à la liberté d’une espèce dans un biotope. |        Philosophique        |
+| **Homéostasie Collective**             | Capacité du système complet (fédération + tenants) à absorber le changement sans perdre son identité.     | Philosophique / Systémique  |
+| **Éthique du Vivifiant**               | Principe selon lequel chaque action doit régénérer plus qu’elle ne consomme.                              |        Philosophique        |
+| **Empathie Systémique**                | Attitude consistant à concevoir chaque service pour le bien-être des autres composants.                   | Philosophique / Gouvernance |
+| **Sève Numérique**                     | Ensemble des flux vitaux (énergie, données, artefacts) qui circulent dans l’Alliance.                     |    Poétique / Systémique    |
+| **Racines Communes**                   | Métaphore des fondations partagées : les normes, valeurs et protocoles de base.                           |        Philosophique        |
+| **Feuilles Cognitives**                | Interfaces de restitution : dashboards, IA, produits ; là où la lumière devient savoir.                   |     Poétique / Cognitif     |
+| **Pollinisation Cognitive**            | Transmission des connaissances et innovations entre tenants et fédérations.                               |          Cognitif           |
+| **Forêt Numérique**                    | Ensemble des services, données et identités formant l’écosystème boréal.                                  |    Poétique / Systémique    |
+| **Trame Mycorhizienne**                | Réseau invisible de liens de confiance, d’API et de métadonnées reliant les couches.                      |  Philosophique / Technique  |
+| **Souffle du Nord**                    | Concept symbolique : l’élan créatif, la résilience et la fraîcheur d’esprit propres à l’Alliance.         |          Poétique           |
+| **Autopoïétique**                      | Qui se produit et se régénère par lui-même ; cœur conceptuel du modèle.                                   |        Philosophique        |
+| **Réalignement Permanent**             | État de vigilance continue permettant de rester aligné sans rigidité.                                     |   Gouvernance / Cognitif    |
+| **Label de Prestige**                  | Reconnaissance de conformité, d’éthique et de maturité d’un membre.                                       |         Gouvernance         |
+
+---
+
+## 📜 **ΔLog — Itération CRB-2 (25-10-2025)**
+
+* Consolidation du **langage commun** à partir de la version v2.
+* Ajout des **familles A, B, C** pour structurer les usages (Technique / Systémique / Philosophique).
+* Intégration du **principe d’adjacence** et des métaphores biologiques.
+* Actualisation des définitions selon le **Modèle v3** et la **Nomenclature v3**.
+* Inclusion d’un **préambule CRB-2** et d’une **Signature Boréale**.
+* Harmonisation sémantique avec la Charte Cognitive et le Manifeste Philosophique.
+
+---
+
+## 🌌 **Signature Boréale**
+
+> *Chaque mot est une cellule.Chaque phrase, un organe.Le sens circule comme la sève, du code à la conscience.Et l’Alliance, patiemment, continue de se dire.*
\ No newline at end of file
diff --git a/docs/00-fondements/00 - Manifeste.md b/docs/00-fondements/00 - Manifeste.md
new file mode 100644
index 0000000..d11d139
--- /dev/null
+++ b/docs/00-fondements/00 - Manifeste.md	
@@ -0,0 +1,136 @@
+# **Manifeste de l’Alliance Boréale**
+
+### *Pour une gouvernance distribuée, responsable et inclusive du numérique*
+
+**Version :** 3.1 – Rédaction institutionnelle  
+**Cycle :** CRB-4  
+**Statut :** Document fondateur – Préambule éthique  
+**Licence :** CC-BY-SA-4.0
+
+---
+
+## 1. Préambule
+
+L’Alliance Boréale est une fédération d’acteurs du numérique éthique fondée sur la conviction que la technologie doit servir la société, non la dominer.  
+Elle réunit des organisations, des collectivités et des citoyens qui choisissent la **coopération sans subordination**, la **transparence sans naïveté**, et la **souveraineté sans isolement**.
+
+Ce manifeste énonce les principes philosophiques et politiques qui guident son action.  
+Il constitue la référence morale et culturelle de l’Alliance, au même titre que la Charte Fondatrice et le Règlement de Régie Interne.
+
+---
+
+## 2. Objectif et raison d’être
+
+Le numérique structure désormais la vie sociale, économique et démocratique.  
+Mais sa concentration entre quelques acteurs mondiaux a créé une dépendance technologique et une perte de contrôle collectif.  
+L’Alliance Boréale vise à **restaurer la maîtrise du numérique par ceux qui le vivent et le produisent**, en mettant en commun des ressources, des infrastructures et des savoirs au service du bien commun.
+
+Son objectif n’est pas la croissance illimitée, mais la **soutenabilité des écosystèmes numériques** : humains, économiques et environnementaux.
+
+---
+
+## 3. Principes fondateurs
+
+### 3.1 Autonomie et responsabilité
+
+Chaque membre de l’Alliance demeure pleinement souverain sur ses choix, ses infrastructures et ses données.  
+L’Alliance ne se substitue à personne : elle facilite la coopération et la confiance.  
+L’autonomie s’accompagne de la responsabilité de contribuer à la résilience collective.
+
+### 3.2 Transparence et redevabilité
+
+La transparence est la condition de la confiance.  
+Les décisions, politiques et pratiques doivent être documentées et auditées.  
+Ce qui concerne le collectif appartient au collectif ; ce qui relève de la vie privée est protégé.
+
+### 3.3 Solidarité et réciprocité
+
+La force de la fédération repose sur l’entraide et l’équité.  
+Chaque membre contribue selon ses moyens et reçoit selon ses besoins.  
+L’Alliance refuse la compétition interne : elle privilégie la collaboration entre pairs.
+
+### 3.4 Durabilité et sobriété
+
+Le progrès numérique doit respecter les limites physiques et humaines.  
+L’efficacité énergétique, la réutilisation des équipements et la réduction de l’empreinte carbone sont des devoirs, pas des options.
+
+### 3.5 Confiance technologique et éthique
+
+La technologie n’est pas neutre.  
+Les outils déployés doivent incarner les valeurs de l’Alliance : ouverture, interopérabilité, sécurité et respect des droits fondamentaux.  
+Les choix techniques doivent pouvoir être expliqués et audités.
+
+---
+
+## 4. Gouvernance et prise de décision
+
+L’Alliance Boréale adopte une **gouvernance sociocratique** fondée sur le consentement et la subsidiarité.  
+Les décisions sont prises au niveau le plus proche de celles et ceux qu’elles concernent.  
+Le pouvoir est **circulaire, distribué et révocable** : aucune personne ni structure ne peut concentrer durablement la décision.
+
+La gouvernance repose sur trois cercles permanents :
+
+- **Stratégique** : orientation, vision et admission de nouveaux membres.
+- **Opérationnel** : infrastructures, outils communs et interopérabilité.
+- **Éthique et conformité** : veille, médiation et label de prestige.
+
+Chaque cercle est autonome mais interrelié ; les mandats sont limités dans le temps.  
+La régie interne agit comme un mécanisme d’**équilibre et de prévention** plutôt que de sanction.
+
+---
+
+## 5. Position politique et sociale
+
+L’Alliance Boréale promeut :
+
+- la **souveraineté numérique collective** (maîtrise des données, des standards et des infrastructures) ;
+- la **protection des droits fondamentaux** dans l’environnement numérique ;
+- la **transformation écologique** du secteur technologique ;
+- la **coopération économique équitable** entre petites et moyennes organisations locales.
+
+Elle reconnaît que le numérique est un **outil de justice sociale** et que son accès universel est une condition d’inclusion.  
+Aucune personne, aucun territoire, aucune organisation ne doit être laissé en marge du progrès technologique.
+
+---
+
+## 6. Vision à long terme
+
+L’Alliance Boréale souhaite construire un modèle durable de **souveraineté partagée**, capable de s’adapter aux générations futures.  
+Elle documente, forme et transmet afin que les savoirs ne se perdent pas.  
+Sa finalité n’est pas de durer pour elle-même, mais de **laisser derrière elle un cadre ouvert et transmissible**, garantissant que le numérique reste au service de la société.
+
+---
+
+## 7. Engagement moral
+
+Les membres fondateurs et futurs signataires s’engagent à :
+
+- respecter les valeurs énoncées dans ce manifeste ;
+- favoriser la transparence et l’apprentissage collectif ;
+- agir dans l’intérêt général avant tout intérêt commercial ou partisan ;
+- défendre le droit à l’autonomie numérique pour chaque individu et chaque communauté.
+
+Cet engagement vaut signature morale de la fédération : il relie ses membres non par la contrainte, mais par la **volonté partagée de responsabilité**.
+
+---
+
+## 8. Conclusion
+
+L’Alliance Boréale n’est pas une utopie : c’est une méthode.  
+Une méthode pour gouverner ensemble, sans domination ni désordre.  
+Elle ne promet pas la perfection, mais la cohérence.  
+Elle ne cherche pas à posséder, mais à rendre possible.
+
+Ce manifeste est son socle éthique —  
+un texte destiné à **rendre le pouvoir numérique au bien commun**,  
+et à garantir que **personne, jamais, n’en soit exclu.**
+
+---
+
+## ΔLog CRB-4 — Passage vers l’institutionnel
+
+- Conversion complète du Manifeste Philosophique v3 vers une version institutionnelle et opérationnelle.
+- Suppression des métaphores et des symboles poétiques pour une rédaction claire, juridique et politique.
+- Intégration des principes de gouvernance sociocratique, de souveraineté numérique et de responsabilité collective.
+- Alignement sur la Charte Fondatrice, le Règlement de Régie Interne et le Cadre de Conformité.
+- Adoption comme **Préambule éthique officiel** de l’Alliance Boréale.
\ No newline at end of file
diff --git a/docs/00-fondements/00-manifeste.md b/docs/00-fondements/00-manifeste.md
index c943d84..83bfe6f 100644
--- a/docs/00-fondements/00-manifeste.md
+++ b/docs/00-fondements/00-manifeste.md
@@ -1,9 +1,11 @@
-# **Manifeste Philosophique de l’Alliance Boréale**  
-### *Pour une gouvernance distribuée, responsable et inclusive du numérique*  
+# **Manifeste Philosophique de l’Alliance Boréale**
+
+### *Pour une gouvernance distribuée, responsable et inclusive du numérique*
+
 **Version :** 3.1 – Rédaction institutionnelle  
 **Cycle :** CRB-4  
 **Statut :** Document fondateur – Préambule éthique  
-**Licence :** CC-BY-SA-4.0  
+**Licence :** CC-BY-SA-4.0
 
 ---
 
@@ -13,7 +15,7 @@ L’Alliance Boréale est une fédération d’acteurs du numérique éthique fo
 Elle réunit des organisations, des collectivités et des citoyens qui choisissent la **coopération sans subordination**, la **transparence sans naïveté**, et la **souveraineté sans isolement**.
 
 Ce manifeste énonce les principes philosophiques et politiques qui guident son action.  
-Il constitue la référence morale et culturelle de l’Alliance, au même titre que la Charte Fondatrice et le Règlement de Régie Interne.  
+Il constitue la référence morale et culturelle de l’Alliance, au même titre que la Charte Fondatrice et le Règlement de Régie Interne.
 
 ---
 
@@ -23,35 +25,40 @@ Le numérique structure désormais la vie sociale, économique et démocratique.
 Mais sa concentration entre quelques acteurs mondiaux a créé une dépendance technologique et une perte de contrôle collectif.  
 L’Alliance Boréale vise à **restaurer la maîtrise du numérique par ceux qui le vivent et le produisent**, en mettant en commun des ressources, des infrastructures et des savoirs au service du bien commun.
 
-Son objectif n’est pas la croissance illimitée, mais la **soutenabilité des écosystèmes numériques** : humains, économiques et environnementaux.  
+Son objectif n’est pas la croissance illimitée, mais la **soutenabilité des écosystèmes numériques** : humains, économiques et environnementaux.
 
 ---
 
 ## 3. Principes fondateurs
 
-### 3.1 Autonomie et responsabilité  
+### 3.1 Autonomie et responsabilité
+
 Chaque membre de l’Alliance demeure pleinement souverain sur ses choix, ses infrastructures et ses données.  
 L’Alliance ne se substitue à personne : elle facilite la coopération et la confiance.  
 L’autonomie s’accompagne de la responsabilité de contribuer à la résilience collective.
 
-### 3.2 Transparence et redevabilité  
+### 3.2 Transparence et redevabilité
+
 La transparence est la condition de la confiance.  
 Les décisions, politiques et pratiques doivent être documentées et auditées.  
-Ce qui concerne le collectif appartient au collectif ; ce qui relève de la vie privée est protégé.  
+Ce qui concerne le collectif appartient au collectif ; ce qui relève de la vie privée est protégé.
+
+### 3.3 Solidarité et réciprocité
 
-### 3.3 Solidarité et réciprocité  
 La force de la fédération repose sur l’entraide et l’équité.  
 Chaque membre contribue selon ses moyens et reçoit selon ses besoins.  
-L’Alliance refuse la compétition interne : elle privilégie la collaboration entre pairs.  
+L’Alliance refuse la compétition interne : elle privilégie la collaboration entre pairs.
+
+### 3.4 Durabilité et sobriété
 
-### 3.4 Durabilité et sobriété  
 Le progrès numérique doit respecter les limites physiques et humaines.  
-L’efficacité énergétique, la réutilisation des équipements et la réduction de l’empreinte carbone sont des devoirs, pas des options.  
+L’efficacité énergétique, la réutilisation des équipements et la réduction de l’empreinte carbone sont des devoirs, pas des options.
+
+### 3.5 Confiance technologique et éthique
 
-### 3.5 Confiance technologique et éthique  
 La technologie n’est pas neutre.  
 Les outils déployés doivent incarner les valeurs de l’Alliance : ouverture, interopérabilité, sécurité et respect des droits fondamentaux.  
-Les choix techniques doivent pouvoir être expliqués et audités.  
+Les choix techniques doivent pouvoir être expliqués et audités.
 
 ---
 
@@ -59,28 +66,30 @@ Les choix techniques doivent pouvoir être expliqués et audités.
 
 L’Alliance Boréale adopte une **gouvernance sociocratique** fondée sur le consentement et la subsidiarité.  
 Les décisions sont prises au niveau le plus proche de celles et ceux qu’elles concernent.  
-Le pouvoir est **circulaire, distribué et révocable** : aucune personne ni structure ne peut concentrer durablement la décision.  
+Le pouvoir est **circulaire, distribué et révocable** : aucune personne ni structure ne peut concentrer durablement la décision.
 
-La gouvernance repose sur trois cercles permanents :  
-- **Stratégique** : orientation, vision et admission de nouveaux membres.  
-- **Opérationnel** : infrastructures, outils communs et interopérabilité.  
-- **Éthique et conformité** : veille, médiation et label de prestige.  
+La gouvernance repose sur trois cercles permanents :
+
+- **Stratégique** : orientation, vision et admission de nouveaux membres.
+- **Opérationnel** : infrastructures, outils communs et interopérabilité.
+- **Éthique et conformité** : veille, médiation et label de prestige.
 
 Chaque cercle est autonome mais interrelié ; les mandats sont limités dans le temps.  
-La régie interne agit comme un mécanisme d’**équilibre et de prévention** plutôt que de sanction.  
+La régie interne agit comme un mécanisme d’**équilibre et de prévention** plutôt que de sanction.
 
 ---
 
 ## 5. Position politique et sociale
 
-L’Alliance Boréale promeut :  
-- la **souveraineté numérique collective** (maîtrise des données, des standards et des infrastructures) ;  
-- la **protection des droits fondamentaux** dans l’environnement numérique ;  
-- la **transformation écologique** du secteur technologique ;  
-- la **coopération économique équitable** entre petites et moyennes organisations locales.  
+L’Alliance Boréale promeut :
+
+- la **souveraineté numérique collective** (maîtrise des données, des standards et des infrastructures) ;
+- la **protection des droits fondamentaux** dans l’environnement numérique ;
+- la **transformation écologique** du secteur technologique ;
+- la **coopération économique équitable** entre petites et moyennes organisations locales.
 
 Elle reconnaît que le numérique est un **outil de justice sociale** et que son accès universel est une condition d’inclusion.  
-Aucune personne, aucun territoire, aucune organisation ne doit être laissé en marge du progrès technologique.  
+Aucune personne, aucun territoire, aucune organisation ne doit être laissé en marge du progrès technologique.
 
 ---
 
@@ -88,19 +97,20 @@ Aucune personne, aucun territoire, aucune organisation ne doit être laissé en
 
 L’Alliance Boréale souhaite construire un modèle durable de **souveraineté partagée**, capable de s’adapter aux générations futures.  
 Elle documente, forme et transmet afin que les savoirs ne se perdent pas.  
-Sa finalité n’est pas de durer pour elle-même, mais de **laisser derrière elle un cadre ouvert et transmissible**, garantissant que le numérique reste au service de la société.  
+Sa finalité n’est pas de durer pour elle-même, mais de **laisser derrière elle un cadre ouvert et transmissible**, garantissant que le numérique reste au service de la société.
 
 ---
 
 ## 7. Engagement moral
 
-Les membres fondateurs et futurs signataires s’engagent à :  
-- respecter les valeurs énoncées dans ce manifeste ;  
-- favoriser la transparence et l’apprentissage collectif ;  
-- agir dans l’intérêt général avant tout intérêt commercial ou partisan ;  
-- défendre le droit à l’autonomie numérique pour chaque individu et chaque communauté.  
+Les membres fondateurs et futurs signataires s’engagent à :
 
-Cet engagement vaut signature morale de la fédération : il relie ses membres non par la contrainte, mais par la **volonté partagée de responsabilité**.  
+- respecter les valeurs énoncées dans ce manifeste ;
+- favoriser la transparence et l’apprentissage collectif ;
+- agir dans l’intérêt général avant tout intérêt commercial ou partisan ;
+- défendre le droit à l’autonomie numérique pour chaque individu et chaque communauté.
+
+Cet engagement vaut signature morale de la fédération : il relie ses membres non par la contrainte, mais par la **volonté partagée de responsabilité**.
 
 ---
 
@@ -109,19 +119,18 @@ Cet engagement vaut signature morale de la fédération : il relie ses membres n
 L’Alliance Boréale n’est pas une utopie : c’est une méthode.  
 Une méthode pour gouverner ensemble, sans domination ni désordre.  
 Elle ne promet pas la perfection, mais la cohérence.  
-Elle ne cherche pas à posséder, mais à rendre possible.  
+Elle ne cherche pas à posséder, mais à rendre possible.
 
 Ce manifeste est son socle éthique —  
 un texte destiné à **rendre le pouvoir numérique au bien commun**,  
-et à garantir que **personne, jamais, n’en soit exclu.**  
+et à garantir que **personne, jamais, n’en soit exclu.**
 
 ---
 
 ## ΔLog CRB-4 — Passage vers l’institutionnel
 
-- Conversion complète du Manifeste Philosophique v3 vers une version institutionnelle et opérationnelle.  
-- Suppression des métaphores et des symboles poétiques pour une rédaction claire, juridique et politique.  
-- Intégration des principes de gouvernance sociocratique, de souveraineté numérique et de responsabilité collective.  
-- Alignement sur la Charte Fondatrice, le Règlement de Régie Interne et le Cadre de Conformité.  
-- Adoption comme **Préambule éthique officiel** de l’Alliance Boréale.  
-
+- Conversion complète du Manifeste Philosophique v3 vers une version institutionnelle et opérationnelle.
+- Suppression des métaphores et des symboles poétiques pour une rédaction claire, juridique et politique.
+- Intégration des principes de gouvernance sociocratique, de souveraineté numérique et de responsabilité collective.
+- Alignement sur la Charte Fondatrice, le Règlement de Régie Interne et le Cadre de Conformité.
+- Adoption comme **Préambule éthique officiel** de l’Alliance Boréale.
\ No newline at end of file
diff --git a/docs/00-fondements/01-charte-des-valeurs.md b/docs/00-fondements/01-charte-des-valeurs.md
deleted file mode 100644
index 3f9947e..0000000
--- a/docs/00-fondements/01-charte-des-valeurs.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Charte Des Valeurs
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/00-fondements/02-principes-autopoietiques.md b/docs/00-fondements/02-principes-autopoietiques.md
deleted file mode 100644
index 6a403fa..0000000
--- a/docs/00-fondements/02-principes-autopoietiques.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Principes Autopoietiques
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/00-fondements/03-lexique-et-glossaire.md b/docs/00-fondements/03-lexique-et-glossaire.md
deleted file mode 100644
index ff8dfe2..0000000
--- a/docs/00-fondements/03-lexique-et-glossaire.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Lexique Et Glossaire
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/00-fondements/04-symboles-et-identite-visuelle.md b/docs/00-fondements/04-symboles-et-identite-visuelle.md
deleted file mode 100644
index 1d4e756..0000000
--- a/docs/00-fondements/04-symboles-et-identite-visuelle.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Symboles Et Identite Visuelle
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/06 - Controles_Conformite_Label_Prestige_par_Couche_v1.0.md b/docs/06 - Controles_Conformite_Label_Prestige_par_Couche_v1.0.md
new file mode 100644
index 0000000..6b70d0b
--- /dev/null
+++ b/docs/06 - Controles_Conformite_Label_Prestige_par_Couche_v1.0.md	
@@ -0,0 +1,629 @@
+# Annexe D — Contrôles de conformité (Label Prestige) alignés sur le modèle à 8 couches (C1–C8)
+**Version :** 1.0  
+**Date :** 25 janvier 2026  
+**Statut :** Référence d’audit (pack de preuve)  
+
+## 1. But et usage
+Cette annexe relie le **Label de Prestige** (critères 1.x à 6.x) à la **constitution des couches** (C1–C8) en attribuant :
+- une **couche propriétaire primaire** (responsable de produire/tenir la preuve),
+- des **couches en support** (capacité contributive),
+- une **fréquence** de vérification,
+- un **chemin d’évidence** standardisé à versionner dans la forge (C4).
+
+> Note : Le Label vise principalement l’évaluation des **membres fédérés** (C1–C5). Les couches C6–C8 sont incluses ici comme **extension naturelle** pour documenter la portabilité et les garanties tenant, lorsque l’Alliance auditera aussi des services/tenants.
+
+## 2. Structure recommandée du *pack de preuve*
+Dans la forge (C4), créer un répertoire racine versionné :
+
+```text
+compliance/label-prestige/
+  README.md
+  evidence/
+    domaine_1/
+    domaine_2/
+    domaine_3/
+    domaine_4/
+    domaine_5/
+    domaine_6/
+  audit/
+    2026-01/  (rapports, grilles signées, décisions)
+  layers/
+    C1/ C2/ C3/ C4/ C5/ C6/ C7/ C8/
+```
+
+Chaque critère a un dossier dédié (ex. `evidence/domaine_2/2_2/`) pour déposer captures, exports, rapports, configurations, journaux ou liens d’attestation.
+
+## 3. Matrice de responsabilité — critères du Label → couches
+La table ci-dessous sert de **source de vérité** pour savoir *qui produit quelle preuve* et où la ranger.
+
+| Critère | Domaine# | Tier | Libellé | Couches (primaires) | Couches (support) | Fréquence recommandée | Chemin d’évidence (recommandé) | Notes d’applicabilité |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 1.1 | 1 | Obligatoire | Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée) | C3, C5 | C1, C2, C4, C6, C7 | Mensuel (revue) / Continu (métriques) | compliance/label-prestige/evidence/domaine_1/1_1/ | — |
+| 1.10 | 1 | Recommandé | Monitoring externe (tiers indépendant) | C3 | C5 | Continu | compliance/label-prestige/evidence/domaine_1/1_10/ | — |
+| 1.11 | 1 | Recommandé | Redondance réseau (2+ liens internet) | C2 | C1 | Semestriel (revue) / Après changement réseau | compliance/label-prestige/evidence/domaine_1/1_11/ | — |
+| 1.12 | 1 | Recommandé | Infrastructure as Code ≥ 50% | C4 | C1, C2, C3, C5, C6 | Continu (IaC) / Trimestriel (mesure couverture) | compliance/label-prestige/evidence/domaine_1/1_12/ | — |
+| 1.13 | 1 | Excellence | Disponibilité ≥ 99.9% (3 nines) | C3, C5 | C1, C2, C4, C6, C7 | Mensuel (revue) / Continu (métriques) | compliance/label-prestige/evidence/domaine_1/1_13/ | — |
+| 1.14 | 1 | Excellence | Chaos engineering (tests de résilience) | C3 | C1, C2, C4, C5, C6 | Trimestriel (campagne) / Annuel (programme) | compliance/label-prestige/evidence/domaine_1/1_14/ | — |
+| 1.15 | 1 | Excellence | Infrastructure 100% IaC (reproductible) | C4 | C1, C2, C3, C5, C6 | Continu (IaC) / Trimestriel (mesure couverture) | compliance/label-prestige/evidence/domaine_1/1_15/ | — |
+| 1.2 | 1 | Obligatoire | Backup automatisé quotidien | C4, C6 | C3, C8 | Quotidien (exécution) / Mensuel (revue) | compliance/label-prestige/evidence/domaine_1/1_2/ | — |
+| 1.3 | 1 | Obligatoire | Test de restauration réussi dans les 6 derniers mois | C4, C6 | C3 | Semestriel (test) / Trimestriel (planification) | compliance/label-prestige/evidence/domaine_1/1_3/ | — |
+| 1.4 | 1 | Obligatoire | Monitoring actif avec alerting | C3 | C2, C4, C5, C6, C7, C8 | Continu | compliance/label-prestige/evidence/domaine_1/1_4/ | — |
+| 1.5 | 1 | Obligatoire | Documentation de l'architecture (diagramme + inventaire) | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel (revue) / À chaque changement majeur | compliance/label-prestige/evidence/domaine_1/1_5/ | — |
+| 1.6 | 1 | Obligatoire | Plan de reprise documenté (RTO/RPO définis) | C3, C1 | C2, C4, C5, C6, C8 | Annuel (revue) / Après incident majeur | compliance/label-prestige/evidence/domaine_1/1_6/ | — |
+| 1.7 | 1 | Recommandé | Disponibilité ≥ 99.5% | C3, C5 | C1, C2, C4, C6, C7 | Mensuel (revue) / Continu (métriques) | compliance/label-prestige/evidence/domaine_1/1_7/ | — |
+| 1.8 | 1 | Recommandé | Backup incrémental + complet hebdomadaire | C4, C6 | C3, C8 | Quotidien (exécution) / Mensuel (revue) | compliance/label-prestige/evidence/domaine_1/1_8/ | — |
+| 1.9 | 1 | Recommandé | Réplication géographique (2+ sites) | C1, C2, C4 | C3 | Trimestriel (revue) / Annuel (test) | compliance/label-prestige/evidence/domaine_1/1_9/ | — |
+| 2.1 | 2 | Obligatoire | TLS 1.2+ sur tous services publics | C5 | C7, C2 | Continu (scan) / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_2/2_1/ | — |
+| 2.10 | 2 | Recommandé | Registre des traitements RGPD (Article 30) | C3, C8 | C7 | Annuel (revue) / À chaque nouveau traitement | compliance/label-prestige/evidence/domaine_2/2_10/ | — |
+| 2.11 | 2 | Recommandé | Audit de sécurité externe annuel | C3 | — | Annuel | compliance/label-prestige/evidence/domaine_2/2_11/ | — |
+| 2.12 | 2 | Excellence | Zero-knowledge encryption (E2EE) | C6, C7 | C5 | À chaque release majeure | compliance/label-prestige/evidence/domaine_2/2_12/ | Applicable si le service gère des contenus sensibles ou promet E2EE. |
+| 2.13 | 2 | Excellence | Bug bounty program actif | C3 | C4, C5 | Annuel (programme) / Continu (triage) | compliance/label-prestige/evidence/domaine_2/2_13/ | — |
+| 2.14 | 2 | Excellence | Certification ISO 27001 ou SOC 2 | C3 | — | Tous les 3 ans (certif) / Annuel (surveillance) | compliance/label-prestige/evidence/domaine_2/2_14/ | — |
+| 2.2 | 2 | Obligatoire | MFA activée pour accès administrateurs | C3 | C4, C5 | Trimestriel (revue accès) / À chaque arrivée/départ | compliance/label-prestige/evidence/domaine_2/2_2/ | — |
+| 2.3 | 2 | Obligatoire | Backups chiffrés (AES-256 ou équivalent) | C4, C6 | C3 | Quotidien (backups) / Trimestriel (revue chiffrement) | compliance/label-prestige/evidence/domaine_2/2_3/ | — |
+| 2.4 | 2 | Obligatoire | Politique de confidentialité publique et conforme (Loi 25 ou RGPD) | C3, C7 | C8 | Annuel (revue) / À chaque changement de traitement | compliance/label-prestige/evidence/domaine_2/2_4/ | — |
+| 2.5 | 2 | Obligatoire | Patches de sécurité critiques appliqués < 30 jours | C3 | C1, C2, C4, C5, C6, C7, C8 | Continu (patching) / Mensuel (revue) | compliance/label-prestige/evidence/domaine_2/2_5/ | — |
+| 2.6 | 2 | Obligatoire | Pare-feu configuré (ports nécessaires uniquement) | C2 | C5 | Trimestriel (revue) / À chaque changement | compliance/label-prestige/evidence/domaine_2/2_6/ | — |
+| 2.7 | 2 | Recommandé | TLS 1.3 uniquement (pas de 1.2) | C5 | C7, C2 | Continu (scan) / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_2/2_7/ | — |
+| 2.8 | 2 | Recommandé | MFA proposée aux utilisateurs finaux | C5, C7 | C3 | Trimestriel (revue) / Continu (mesure adoption) | compliance/label-prestige/evidence/domaine_2/2_8/ | — |
+| 2.9 | 2 | Recommandé | Patches de sécurité critiques < 7 jours | C3 | C1, C2, C4, C5, C6, C7, C8 | Continu (patching) / Mensuel (revue) | compliance/label-prestige/evidence/domaine_2/2_9/ | — |
+| 3.1 | 3 | Obligatoire | Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire) | C5 | C6, C7, C2 | Trimestriel (revue) / À chaque changement | compliance/label-prestige/evidence/domaine_3/3_1/ | Critère applicable seulement si le service correspondant est offert (email, Cal/CardDAV, multi-protocoles). |
+| 3.10 | 3 | Excellence | Contribution à des standards ouverts (RFC, W3C, etc.) | C4 | C3 | Annuel | compliance/label-prestige/evidence/domaine_3/3_10/ | — |
+| 3.11 | 3 | Excellence | Support multi-protocoles (email + Matrix + CalDAV + WebDAV) | C5 | C6, C7, C2 | Trimestriel (revue) / À chaque changement | compliance/label-prestige/evidence/domaine_3/3_11/ | Critère applicable seulement si le service correspondant est offert (email, Cal/CardDAV, multi-protocoles). |
+| 3.12 | 3 | Excellence | Publication de schémas de données (Open Data) | C8 | C6 | À chaque version de schéma | compliance/label-prestige/evidence/domaine_3/3_12/ | — |
+| 3.2 | 3 | Obligatoire | Export complet des données utilisateur possible | C6, C8 | C7 | Trimestriel (test export) / À chaque changement schéma | compliance/label-prestige/evidence/domaine_3/3_2/ | — |
+| 3.3 | 3 | Obligatoire | Formats de stockage ouverts (pas de lock-in propriétaire) | C4, C6, C8 | C3 | Trimestriel (revue) / À chaque choix de techno | compliance/label-prestige/evidence/domaine_3/3_3/ | — |
+| 3.4 | 3 | Obligatoire | DNS configuré selon standards (DNSSEC recommandé) | C2 | C5 | Semestriel (revue) / À chaque modification DNS | compliance/label-prestige/evidence/domaine_3/3_4/ | — |
+| 3.5 | 3 | Obligatoire | DKIM, SPF, DMARC configurés (si email) | C5 | C6, C7, C2 | Trimestriel (revue) / À chaque changement | compliance/label-prestige/evidence/domaine_3/3_5/ | Critère applicable seulement si le service correspondant est offert (email, Cal/CardDAV, multi-protocoles). |
+| 3.6 | 3 | Recommandé | Calendrier via CalDAV / Contacts via CardDAV | C5 | C6, C7, C2 | Trimestriel (revue) / À chaque changement | compliance/label-prestige/evidence/domaine_3/3_6/ | Critère applicable seulement si le service correspondant est offert (email, Cal/CardDAV, multi-protocoles). |
+| 3.7 | 3 | Recommandé | APIs publiquement documentées (si applicable) | C5, C6 | C4, C7 | À chaque release / Trimestriel (revue docs) | compliance/label-prestige/evidence/domaine_3/3_7/ | — |
+| 3.8 | 3 | Recommandé | Support de fédération (Matrix, ActivityPub, XMPP, etc.) | C5, C6 | C4, C7 | À chaque release / Trimestriel (revue docs) | compliance/label-prestige/evidence/domaine_3/3_8/ | — |
+| 3.9 | 3 | Recommandé | Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.) | C7 | — | À chaque release front | compliance/label-prestige/evidence/domaine_3/3_9/ | — |
+| 4.1 | 4 | Obligatoire | OS serveur libre (Linux, BSD) | C1 | C2, C4 | Annuel / À chaque changement OS | compliance/label-prestige/evidence/domaine_4/4_1/ | — |
+| 4.10 | 4 | Excellence | 100% de la stack en logiciel libre | C4 | C3, C6 | Trimestriel (revue inventaire licences) | compliance/label-prestige/evidence/domaine_4/4_10/ | — |
+| 4.11 | 4 | Excellence | Mainteneur actif d'un projet libre majeur | C4 | — | Annuel | compliance/label-prestige/evidence/domaine_4/4_11/ | — |
+| 4.12 | 4 | Excellence | Certification B Corp ou équivalent | C3 | — | Selon organisme | compliance/label-prestige/evidence/domaine_4/4_12/ | — |
+| 4.2 | 4 | Obligatoire | ≥ 60% de la stack applicative en logiciel libre | C4 | C3, C6 | Trimestriel (revue inventaire licences) | compliance/label-prestige/evidence/domaine_4/4_2/ | — |
+| 4.3 | 4 | Obligatoire | Liste publique des dépendances (transparence) | C4 | C6, C7 | Trimestriel / À chaque release | compliance/label-prestige/evidence/domaine_4/4_3/ | — |
+| 4.4 | 4 | Obligatoire | Aucune dépendance critique aux GAFAM (production) | C3, C4 | C5, C6, C7 | Trimestriel (revue dépendances critiques) | compliance/label-prestige/evidence/domaine_4/4_4/ | — |
+| 4.5 | 4 | Obligatoire | Gouvernance non autoritaire (coopérative, démocratique, ou collégiale) | C3 | — | Annuel / À chaque changement statutaire | compliance/label-prestige/evidence/domaine_4/4_5/ | — |
+| 4.6 | 4 | Recommandé | ≥ 80% de la stack applicative en logiciel libre | C4 | C3, C6 | Trimestriel (revue inventaire licences) | compliance/label-prestige/evidence/domaine_4/4_6/ | — |
+| 4.7 | 4 | Recommandé | Au moins 1 contribution annuelle à un projet libre | C4 | C3 | Annuel | compliance/label-prestige/evidence/domaine_4/4_7/ | — |
+| 4.8 | 4 | Recommandé | Publication de code maison en licence libre | C4 | C6, C7 | Trimestriel / À chaque release | compliance/label-prestige/evidence/domaine_4/4_8/ | — |
+| 4.9 | 4 | Recommandé | Politique d'achat favorisant fournisseurs éthiques | C3 | C1, C4 | Annuel | compliance/label-prestige/evidence/domaine_4/4_9/ | — |
+| 5.1 | 5 | Obligatoire | Runbook pour au moins 3 procédures critiques | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_1/ | — |
+| 5.10 | 5 | Excellence | Infrastructure 100% IaC (zero manual config) | C4 | C3, C6 | Continu / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_5/5_10/ | — |
+| 5.11 | 5 | Excellence | Observabilité avancée (tracing distribué, logs structurés) | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_11/ | — |
+| 5.12 | 5 | Excellence | SLA publiquement documenté et respecté | C3, C5 | — | Trimestriel (revue) / Annuel (publication) | compliance/label-prestige/evidence/domaine_5/5_12/ | — |
+| 5.2 | 5 | Obligatoire | Documentation architecture à jour | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_2/ | — |
+| 5.3 | 5 | Obligatoire | Post-mortem publié pour incidents P0/P1 (6 derniers mois) | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_3/ | — |
+| 5.4 | 5 | Obligatoire | Monitoring avec métriques exportées (Prometheus compatible) | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_4/ | — |
+| 5.5 | 5 | Obligatoire | Status page public (ou métriques disponibilité) | C3 | C1, C2, C4, C5, C6, C7, C8 | Trimestriel / Après incident | compliance/label-prestige/evidence/domaine_5/5_5/ | — |
+| 5.6 | 5 | Recommandé | IaC pour ≥ 70% de l'infrastructure | C4 | C3, C6 | Continu / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_5/5_6/ | — |
+| 5.7 | 5 | Recommandé | CI/CD avec tests automatisés | C4 | C3, C6 | Continu / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_5/5_7/ | — |
+| 5.8 | 5 | Recommandé | Documentation générée automatiquement (code) | C4 | C3, C6 | Continu / Trimestriel (revue) | compliance/label-prestige/evidence/domaine_5/5_8/ | — |
+| 5.9 | 5 | Recommandé | Contributions régulières au wiki L'Alliance | C4, C3 | — | Mensuel | compliance/label-prestige/evidence/domaine_5/5_9/ | — |
+| 6.1 | 6 | Obligatoire | Mesure de la consommation énergétique (kWh/mois) | C1 | C3 | Mensuel (mesure) / Annuel (revue politique) | compliance/label-prestige/evidence/domaine_6/6_1/ | — |
+| 6.10 | 6 | Recommandé | Extinction services non critiques hors heures | C3, C4, C6 | C5 | Trimestriel (revue) / Continu (automations) | compliance/label-prestige/evidence/domaine_6/6_10/ | — |
+| 6.11 | 6 | Excellence | Énergie 100% renouvelable | C1 | C3 | Annuel | compliance/label-prestige/evidence/domaine_6/6_11/ | — |
+| 6.12 | 6 | Excellence | Compensation carbone volontaire | C3 | C1 | Annuel | compliance/label-prestige/evidence/domaine_6/6_12/ | — |
+| 6.13 | 6 | Excellence | Publication rapport impact environnemental annuel | C3 | C1 | Annuel | compliance/label-prestige/evidence/domaine_6/6_13/ | — |
+| 6.2 | 6 | Obligatoire | Politique de rétention des données documentée | C3, C8 | C6, C7 | Annuel / À chaque nouveau traitement | compliance/label-prestige/evidence/domaine_6/6_2/ | — |
+| 6.3 | 6 | Obligatoire | Serveurs utilisés ≥ 3 ans (si contrôle direct) | C1 | C3 | Annuel | compliance/label-prestige/evidence/domaine_6/6_3/ | — |
+| 6.4 | 6 | Obligatoire | Hébergeur avec engagement environnemental (si externalisé) | C1 | C3 | Annuel | compliance/label-prestige/evidence/domaine_6/6_4/ | — |
+| 6.5 | 6 | Obligatoire | Guide utilisateur sur bonnes pratiques sobriété | C7 | C8 | Annuel / À chaque refonte UX | compliance/label-prestige/evidence/domaine_6/6_5/ | — |
+| 6.6 | 6 | Recommandé | Réduction consommation énergétique année/année | C3, C1 | C4, C6 | Trimestriel (revue) / Annuel (bilan) | compliance/label-prestige/evidence/domaine_6/6_6/ | — |
+| 6.7 | 6 | Recommandé | Serveurs utilisés ≥ 5 ans | C1 | C3 | Annuel | compliance/label-prestige/evidence/domaine_6/6_7/ | — |
+| 6.8 | 6 | Recommandé | Optimisation ressources (CPU/RAM/stockage < 70% en moyenne) | C3, C1 | C4, C6 | Trimestriel (revue) / Annuel (bilan) | compliance/label-prestige/evidence/domaine_6/6_8/ | — |
+| 6.9 | 6 | Recommandé | Énergie renouvelable ≥ 50% (si contrôle direct) | C1 | C3 | Annuel | compliance/label-prestige/evidence/domaine_6/6_9/ | — |
+
+## 4. Checklists par couche
+Les sections suivantes listent, par couche, les critères dont elle est **propriétaire primaire** (obligatoires, recommandés, excellence).
+
+## C1 — Checklist de conformité (critères dont C1 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **1.6** — Plan de reprise documenté (RTO/RPO définis)  
+  Preuve (Label): Document DRP (Disaster Recovery Plan)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_6/`  
+  Fréquence: Annuel (revue) / Après incident majeur
+- [ ] **4.1** — OS serveur libre (Linux, BSD)  
+  Preuve (Label): `uname -a` ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_1/`  
+  Fréquence: Annuel / À chaque changement OS
+- [ ] **6.1** — Mesure de la consommation énergétique (kWh/mois)  
+  Preuve (Label): Factures ou monitoring IPMI  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_1/`  
+  Fréquence: Mensuel (mesure) / Annuel (revue politique)
+- [ ] **6.3** — Serveurs utilisés ≥ 3 ans (si contrôle direct)  
+  Preuve (Label): Inventaire avec dates acquisition  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_3/`  
+  Fréquence: Annuel
+- [ ] **6.4** — Hébergeur avec engagement environnemental (si externalisé)  
+  Preuve (Label): Certification hébergeur (ISO 14001, PUE < 1.5)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_4/`  
+  Fréquence: Annuel
+
+### Recommandé
+
+- [ ] **1.9** — Réplication géographique (2+ sites)  
+  Preuve (Label): Preuve hébergement multi-sites  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_9/`  
+  Fréquence: Trimestriel (revue) / Annuel (test)
+- [ ] **6.6** — Réduction consommation énergétique année/année  
+  Preuve (Label): Comparatif metrics  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_6/`  
+  Fréquence: Trimestriel (revue) / Annuel (bilan)
+- [ ] **6.7** — Serveurs utilisés ≥ 5 ans  
+  Preuve (Label): Inventaire  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_7/`  
+  Fréquence: Annuel
+- [ ] **6.8** — Optimisation ressources (CPU/RAM/stockage < 70% en moyenne)  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_8/`  
+  Fréquence: Trimestriel (revue) / Annuel (bilan)
+- [ ] **6.9** — Énergie renouvelable ≥ 50% (si contrôle direct)  
+  Preuve (Label): Factures ou certificat  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_9/`  
+  Fréquence: Annuel
+
+### Excellence
+
+- [ ] **6.11** — Énergie 100% renouvelable  
+  Preuve (Label): Certificat fournisseur  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_11/`  
+  Fréquence: Annuel
+
+## C2 — Checklist de conformité (critères dont C2 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **2.6** — Pare-feu configuré (ports nécessaires uniquement)  
+  Preuve (Label): Sortie `iptables -L` ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_6/`  
+  Fréquence: Trimestriel (revue) / À chaque changement
+- [ ] **3.4** — DNS configuré selon standards (DNSSEC recommandé)  
+  Preuve (Label): Validation DNSViz ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_4/`  
+  Fréquence: Semestriel (revue) / À chaque modification DNS
+
+### Recommandé
+
+- [ ] **1.11** — Redondance réseau (2+ liens internet)  
+  Preuve (Label): Configuration BGP ou failover  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_11/`  
+  Fréquence: Semestriel (revue) / Après changement réseau
+- [ ] **1.9** — Réplication géographique (2+ sites)  
+  Preuve (Label): Preuve hébergement multi-sites  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_9/`  
+  Fréquence: Trimestriel (revue) / Annuel (test)
+
+### Excellence
+
+
+## C3 — Checklist de conformité (critères dont C3 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **1.1** — Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée)  
+  Preuve (Label): Métriques monitoring (Prometheus, Grafana, status page)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_1/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **1.4** — Monitoring actif avec alerting  
+  Preuve (Label): Alertmanager configuré, logs d'alertes  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_4/`  
+  Fréquence: Continu
+- [ ] **1.5** — Documentation de l'architecture (diagramme + inventaire)  
+  Preuve (Label): Wiki ou doc versionnée (Markdown, Diagrams.net)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_5/`  
+  Fréquence: Trimestriel (revue) / À chaque changement majeur
+- [ ] **1.6** — Plan de reprise documenté (RTO/RPO définis)  
+  Preuve (Label): Document DRP (Disaster Recovery Plan)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_6/`  
+  Fréquence: Annuel (revue) / Après incident majeur
+- [ ] **2.2** — MFA activée pour accès administrateurs  
+  Preuve (Label): Capture écran config (TOTP, U2F, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_2/`  
+  Fréquence: Trimestriel (revue accès) / À chaque arrivée/départ
+- [ ] **2.4** — Politique de confidentialité publique et conforme (Loi 25 ou RGPD)  
+  Preuve (Label): URL de la politique + revue conformité  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_4/`  
+  Fréquence: Annuel (revue) / À chaque changement de traitement
+- [ ] **2.5** — Patches de sécurité critiques appliqués < 30 jours  
+  Preuve (Label): Logs de mises à jour (apt, yum, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_5/`  
+  Fréquence: Continu (patching) / Mensuel (revue)
+- [ ] **4.4** — Aucune dépendance critique aux GAFAM (production)  
+  Preuve (Label): Déclaration signée  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_4/`  
+  Fréquence: Trimestriel (revue dépendances critiques)
+- [ ] **4.5** — Gouvernance non autoritaire (coopérative, démocratique, ou collégiale)  
+  Preuve (Label): Statuts légaux ou règlement interne  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_5/`  
+  Fréquence: Annuel / À chaque changement statutaire
+- [ ] **5.1** — Runbook pour au moins 3 procédures critiques  
+  Preuve (Label): Wiki ou dépôt doc  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_1/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **5.2** — Documentation architecture à jour  
+  Preuve (Label): Diagrammes + descriptions  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_2/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **5.3** — Post-mortem publié pour incidents P0/P1 (6 derniers mois)  
+  Preuve (Label): Lien vers post-mortems  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_3/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **5.4** — Monitoring avec métriques exportées (Prometheus compatible)  
+  Preuve (Label): Configuration Prometheus  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_4/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **5.5** — Status page public (ou métriques disponibilité)  
+  Preuve (Label): URL status page  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_5/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **6.2** — Politique de rétention des données documentée  
+  Preuve (Label): Document politique  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_2/`  
+  Fréquence: Annuel / À chaque nouveau traitement
+
+### Recommandé
+
+- [ ] **1.10** — Monitoring externe (tiers indépendant)  
+  Preuve (Label): UptimeRobot, Pingdom, ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_10/`  
+  Fréquence: Continu
+- [ ] **1.7** — Disponibilité ≥ 99.5%  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_7/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **2.10** — Registre des traitements RGPD (Article 30)  
+  Preuve (Label): Document du registre  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_10/`  
+  Fréquence: Annuel (revue) / À chaque nouveau traitement
+- [ ] **2.11** — Audit de sécurité externe annuel  
+  Preuve (Label): Rapport d'audit (synthèse)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_11/`  
+  Fréquence: Annuel
+- [ ] **2.9** — Patches de sécurité critiques < 7 jours  
+  Preuve (Label): Logs mises à jour  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_9/`  
+  Fréquence: Continu (patching) / Mensuel (revue)
+- [ ] **4.9** — Politique d'achat favorisant fournisseurs éthiques  
+  Preuve (Label): Document de politique  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_9/`  
+  Fréquence: Annuel
+- [ ] **5.9** — Contributions régulières au wiki L'Alliance  
+  Preuve (Label): Historique Git wiki  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_9/`  
+  Fréquence: Mensuel
+- [ ] **6.10** — Extinction services non critiques hors heures  
+  Preuve (Label): Scripts automation + logs  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_10/`  
+  Fréquence: Trimestriel (revue) / Continu (automations)
+- [ ] **6.6** — Réduction consommation énergétique année/année  
+  Preuve (Label): Comparatif metrics  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_6/`  
+  Fréquence: Trimestriel (revue) / Annuel (bilan)
+- [ ] **6.8** — Optimisation ressources (CPU/RAM/stockage < 70% en moyenne)  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_8/`  
+  Fréquence: Trimestriel (revue) / Annuel (bilan)
+
+### Excellence
+
+- [ ] **1.13** — Disponibilité ≥ 99.9% (3 nines)  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_13/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **1.14** — Chaos engineering (tests de résilience)  
+  Preuve (Label): Rapports de tests (ex: ChaosMonkey, simulations)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_14/`  
+  Fréquence: Trimestriel (campagne) / Annuel (programme)
+- [ ] **2.13** — Bug bounty program actif  
+  Preuve (Label): URL du programme + règles  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_13/`  
+  Fréquence: Annuel (programme) / Continu (triage)
+- [ ] **2.14** — Certification ISO 27001 ou SOC 2  
+  Preuve (Label): Certificat valide  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_14/`  
+  Fréquence: Tous les 3 ans (certif) / Annuel (surveillance)
+- [ ] **4.12** — Certification B Corp ou équivalent  
+  Preuve (Label): Certificat  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_12/`  
+  Fréquence: Selon organisme
+- [ ] **5.11** — Observabilité avancée (tracing distribué, logs structurés)  
+  Preuve (Label): Jaeger, ELK, ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_11/`  
+  Fréquence: Trimestriel / Après incident
+- [ ] **5.12** — SLA publiquement documenté et respecté  
+  Preuve (Label): SLA + rapport conformité  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_12/`  
+  Fréquence: Trimestriel (revue) / Annuel (publication)
+- [ ] **6.12** — Compensation carbone volontaire  
+  Preuve (Label): Reçus donations (Planetair, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_12/`  
+  Fréquence: Annuel
+- [ ] **6.13** — Publication rapport impact environnemental annuel  
+  Preuve (Label): Rapport public  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_13/`  
+  Fréquence: Annuel
+
+## C4 — Checklist de conformité (critères dont C4 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **1.2** — Backup automatisé quotidien  
+  Preuve (Label): Configuration (cron, script, logs)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_2/`  
+  Fréquence: Quotidien (exécution) / Mensuel (revue)
+- [ ] **1.3** — Test de restauration réussi dans les 6 derniers mois  
+  Preuve (Label): Rapport de test (date, procédure, résultat)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_3/`  
+  Fréquence: Semestriel (test) / Trimestriel (planification)
+- [ ] **2.3** — Backups chiffrés (AES-256 ou équivalent)  
+  Preuve (Label): Configuration de chiffrement  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_3/`  
+  Fréquence: Quotidien (backups) / Trimestriel (revue chiffrement)
+- [ ] **3.3** — Formats de stockage ouverts (pas de lock-in propriétaire)  
+  Preuve (Label): Liste formats utilisés (Markdown, JSON, SQL, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_3/`  
+  Fréquence: Trimestriel (revue) / À chaque choix de techno
+- [ ] **4.2** — ≥ 60% de la stack applicative en logiciel libre  
+  Preuve (Label): Inventaire logiciels (avec licences)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_2/`  
+  Fréquence: Trimestriel (revue inventaire licences)
+- [ ] **4.3** — Liste publique des dépendances (transparence)  
+  Preuve (Label): Document ou page web  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_3/`  
+  Fréquence: Trimestriel / À chaque release
+- [ ] **4.4** — Aucune dépendance critique aux GAFAM (production)  
+  Preuve (Label): Déclaration signée  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_4/`  
+  Fréquence: Trimestriel (revue dépendances critiques)
+
+### Recommandé
+
+- [ ] **1.12** — Infrastructure as Code ≥ 50%  
+  Preuve (Label): Playbooks Ansible, Terraform, scripts  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_12/`  
+  Fréquence: Continu (IaC) / Trimestriel (mesure couverture)
+- [ ] **1.8** — Backup incrémental + complet hebdomadaire  
+  Preuve (Label): Configuration (rsnapshot, Borg, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_8/`  
+  Fréquence: Quotidien (exécution) / Mensuel (revue)
+- [ ] **1.9** — Réplication géographique (2+ sites)  
+  Preuve (Label): Preuve hébergement multi-sites  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_9/`  
+  Fréquence: Trimestriel (revue) / Annuel (test)
+- [ ] **4.6** — ≥ 80% de la stack applicative en logiciel libre  
+  Preuve (Label): Inventaire détaillé  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_6/`  
+  Fréquence: Trimestriel (revue inventaire licences)
+- [ ] **4.7** — Au moins 1 contribution annuelle à un projet libre  
+  Preuve (Label): Liens vers commits, PRs, donations  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_7/`  
+  Fréquence: Annuel
+- [ ] **4.8** — Publication de code maison en licence libre  
+  Preuve (Label): Dépôts Git publics  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_8/`  
+  Fréquence: Trimestriel / À chaque release
+- [ ] **5.6** — IaC pour ≥ 70% de l'infrastructure  
+  Preuve (Label): Playbooks Ansible, Terraform  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_6/`  
+  Fréquence: Continu / Trimestriel (revue)
+- [ ] **5.7** — CI/CD avec tests automatisés  
+  Preuve (Label): Configuration GitLab CI, GitHub Actions, etc.  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_7/`  
+  Fréquence: Continu / Trimestriel (revue)
+- [ ] **5.8** — Documentation générée automatiquement (code)  
+  Preuve (Label): Sphinx, JSDoc, ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_8/`  
+  Fréquence: Continu / Trimestriel (revue)
+- [ ] **5.9** — Contributions régulières au wiki L'Alliance  
+  Preuve (Label): Historique Git wiki  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_9/`  
+  Fréquence: Mensuel
+- [ ] **6.10** — Extinction services non critiques hors heures  
+  Preuve (Label): Scripts automation + logs  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_10/`  
+  Fréquence: Trimestriel (revue) / Continu (automations)
+
+### Excellence
+
+- [ ] **1.15** — Infrastructure 100% IaC (reproductible)  
+  Preuve (Label): Git repo complet  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_15/`  
+  Fréquence: Continu (IaC) / Trimestriel (mesure couverture)
+- [ ] **3.10** — Contribution à des standards ouverts (RFC, W3C, etc.)  
+  Preuve (Label): Liens vers contributions  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_10/`  
+  Fréquence: Annuel
+- [ ] **4.10** — 100% de la stack en logiciel libre  
+  Preuve (Label): Inventaire complet  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_10/`  
+  Fréquence: Trimestriel (revue inventaire licences)
+- [ ] **4.11** — Mainteneur actif d'un projet libre majeur  
+  Preuve (Label): Preuve de maintenance (GitHub stats, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_4/4_11/`  
+  Fréquence: Annuel
+- [ ] **5.10** — Infrastructure 100% IaC (zero manual config)  
+  Preuve (Label): Démo reproductibilité  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_10/`  
+  Fréquence: Continu / Trimestriel (revue)
+
+## C5 — Checklist de conformité (critères dont C5 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **1.1** — Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée)  
+  Preuve (Label): Métriques monitoring (Prometheus, Grafana, status page)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_1/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **2.1** — TLS 1.2+ sur tous services publics  
+  Preuve (Label): Scan SSL Labs (grade A- minimum)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_1/`  
+  Fréquence: Continu (scan) / Trimestriel (revue)
+- [ ] **3.1** — Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire)  
+  Preuve (Label): Configuration serveur (Postfix, Dovecot, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_1/`  
+  Fréquence: Trimestriel (revue) / À chaque changement
+- [ ] **3.5** — DKIM, SPF, DMARC configurés (si email)  
+  Preuve (Label): Scan MXToolbox ou équivalent  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_5/`  
+  Fréquence: Trimestriel (revue) / À chaque changement
+
+### Recommandé
+
+- [ ] **1.7** — Disponibilité ≥ 99.5%  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_7/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **2.7** — TLS 1.3 uniquement (pas de 1.2)  
+  Preuve (Label): Scan SSL Labs (grade A+)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_7/`  
+  Fréquence: Continu (scan) / Trimestriel (revue)
+- [ ] **2.8** — MFA proposée aux utilisateurs finaux  
+  Preuve (Label): Capture écran option activable  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_8/`  
+  Fréquence: Trimestriel (revue) / Continu (mesure adoption)
+- [ ] **3.6** — Calendrier via CalDAV / Contacts via CardDAV  
+  Preuve (Label): Configuration serveur (Radicale, Nextcloud, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_6/`  
+  Fréquence: Trimestriel (revue) / À chaque changement
+- [ ] **3.7** — APIs publiquement documentées (si applicable)  
+  Preuve (Label): URL documentation (Swagger, OpenAPI, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_7/`  
+  Fréquence: À chaque release / Trimestriel (revue docs)
+- [ ] **3.8** — Support de fédération (Matrix, ActivityPub, XMPP, etc.)  
+  Preuve (Label): Configuration + test de fédération  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_8/`  
+  Fréquence: À chaque release / Trimestriel (revue docs)
+
+### Excellence
+
+- [ ] **1.13** — Disponibilité ≥ 99.9% (3 nines)  
+  Preuve (Label): Métriques monitoring  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_13/`  
+  Fréquence: Mensuel (revue) / Continu (métriques)
+- [ ] **3.11** — Support multi-protocoles (email + Matrix + CalDAV + WebDAV)  
+  Preuve (Label): Configuration complète  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_11/`  
+  Fréquence: Trimestriel (revue) / À chaque changement
+- [ ] **5.12** — SLA publiquement documenté et respecté  
+  Preuve (Label): SLA + rapport conformité  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_5/5_12/`  
+  Fréquence: Trimestriel (revue) / Annuel (publication)
+
+## C6 — Checklist de conformité (critères dont C6 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **1.2** — Backup automatisé quotidien  
+  Preuve (Label): Configuration (cron, script, logs)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_2/`  
+  Fréquence: Quotidien (exécution) / Mensuel (revue)
+- [ ] **1.3** — Test de restauration réussi dans les 6 derniers mois  
+  Preuve (Label): Rapport de test (date, procédure, résultat)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_3/`  
+  Fréquence: Semestriel (test) / Trimestriel (planification)
+- [ ] **2.3** — Backups chiffrés (AES-256 ou équivalent)  
+  Preuve (Label): Configuration de chiffrement  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_3/`  
+  Fréquence: Quotidien (backups) / Trimestriel (revue chiffrement)
+- [ ] **3.2** — Export complet des données utilisateur possible  
+  Preuve (Label): Procédure documentée + test  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_2/`  
+  Fréquence: Trimestriel (test export) / À chaque changement schéma
+- [ ] **3.3** — Formats de stockage ouverts (pas de lock-in propriétaire)  
+  Preuve (Label): Liste formats utilisés (Markdown, JSON, SQL, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_3/`  
+  Fréquence: Trimestriel (revue) / À chaque choix de techno
+
+### Recommandé
+
+- [ ] **1.8** — Backup incrémental + complet hebdomadaire  
+  Preuve (Label): Configuration (rsnapshot, Borg, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_1/1_8/`  
+  Fréquence: Quotidien (exécution) / Mensuel (revue)
+- [ ] **3.7** — APIs publiquement documentées (si applicable)  
+  Preuve (Label): URL documentation (Swagger, OpenAPI, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_7/`  
+  Fréquence: À chaque release / Trimestriel (revue docs)
+- [ ] **3.8** — Support de fédération (Matrix, ActivityPub, XMPP, etc.)  
+  Preuve (Label): Configuration + test de fédération  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_8/`  
+  Fréquence: À chaque release / Trimestriel (revue docs)
+- [ ] **6.10** — Extinction services non critiques hors heures  
+  Preuve (Label): Scripts automation + logs  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_10/`  
+  Fréquence: Trimestriel (revue) / Continu (automations)
+
+### Excellence
+
+- [ ] **2.12** — Zero-knowledge encryption (E2EE)  
+  Preuve (Label): Architecture technique + audit  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_12/`  
+  Fréquence: À chaque release majeure
+
+## C7 — Checklist de conformité (critères dont C7 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **2.4** — Politique de confidentialité publique et conforme (Loi 25 ou RGPD)  
+  Preuve (Label): URL de la politique + revue conformité  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_4/`  
+  Fréquence: Annuel (revue) / À chaque changement de traitement
+- [ ] **6.5** — Guide utilisateur sur bonnes pratiques sobriété  
+  Preuve (Label): Document ou page web  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_5/`  
+  Fréquence: Annuel / À chaque refonte UX
+
+### Recommandé
+
+- [ ] **2.8** — MFA proposée aux utilisateurs finaux  
+  Preuve (Label): Capture écran option activable  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_8/`  
+  Fréquence: Trimestriel (revue) / Continu (mesure adoption)
+- [ ] **3.9** — Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.)  
+  Preuve (Label): Analyse Blacklight, uBlock Origin  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_9/`  
+  Fréquence: À chaque release front
+
+### Excellence
+
+- [ ] **2.12** — Zero-knowledge encryption (E2EE)  
+  Preuve (Label): Architecture technique + audit  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_12/`  
+  Fréquence: À chaque release majeure
+
+## C8 — Checklist de conformité (critères dont C8 est propriétaire primaire)
+
+### Obligatoire
+
+- [ ] **3.2** — Export complet des données utilisateur possible  
+  Preuve (Label): Procédure documentée + test  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_2/`  
+  Fréquence: Trimestriel (test export) / À chaque changement schéma
+- [ ] **3.3** — Formats de stockage ouverts (pas de lock-in propriétaire)  
+  Preuve (Label): Liste formats utilisés (Markdown, JSON, SQL, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_3/`  
+  Fréquence: Trimestriel (revue) / À chaque choix de techno
+- [ ] **6.2** — Politique de rétention des données documentée  
+  Preuve (Label): Document politique  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_6/6_2/`  
+  Fréquence: Annuel / À chaque nouveau traitement
+
+### Recommandé
+
+- [ ] **2.10** — Registre des traitements RGPD (Article 30)  
+  Preuve (Label): Document du registre  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_2/2_10/`  
+  Fréquence: Annuel (revue) / À chaque nouveau traitement
+
+### Excellence
+
+- [ ] **3.12** — Publication de schémas de données (Open Data)  
+  Preuve (Label): URL schémas (JSON Schema, etc.)  
+  Dépôt recommandé: `compliance/label-prestige/evidence/domaine_3/3_12/`  
+  Fréquence: À chaque version de schéma
diff --git a/docs/10-architecture/10 - Constitution des couches du modèle Boréal.md b/docs/10-architecture/10 - Constitution des couches du modèle Boréal.md
new file mode 100644
index 0000000..919bc62
--- /dev/null
+++ b/docs/10-architecture/10 - Constitution des couches du modèle Boréal.md	
@@ -0,0 +1,495 @@
+# 🌲 Constitution des couches – Modèle boréal à 8 couches (C1–C8)
+**Version :** 1.1  
+**Date :** 25 janvier 2026  
+**Statut :** Référence normative (SSOT)  
+**Portée :** Définir, justifier et cristalliser la **constitution** de chaque couche du modèle à 8 couches de l’Alliance Boréale, ainsi que les règles d’interface et de gouvernance associées.
+
+---
+
+## 0. Pourquoi ce document existe
+Le modèle à 8 couches sert de **contrat d’architecture** entre :
+- la **Fédération** (C1–C4),
+- le **Pivot** (C5),
+- les **Tenants** (C6–C8).
+
+Sans une constitution explicite par couche, le modèle dérive : les responsabilités se mélangent, les flux “sautent” des couches, la portabilité s’érode, et la conformité devient invérifiable.  
+Ce document fixe donc, **une bonne fois pour toutes**, les limites, responsabilités et artefacts attendus de chaque couche.
+
+---
+
+## 1. Définitions et conventions normatives
+
+### 1.1 Terminologie
+- **Couche (Cx)** : “organe” fonctionnel du système. Chaque couche a un périmètre, des responsabilités, des interfaces et des preuves attendues.
+- **Fédération** : ensemble des capacités mutualisées et opérées pour héberger l’écosystème (C1–C4).
+- **Tenant** : entité logique ou organisationnelle qui déploie des services/produits/connaissances dans la canopée (C6–C8).
+- **Pivot** : membrane opérationnelle (C5) reliant fédération et tenants, régulant les flux.
+- **ADN numérique** : ensemble minimal d’artefacts permettant la **reconstruction** (descripteur, IaC, artefacts signés, SBOM).
+
+### 1.2 Langage normatif
+Les termes **DOIT / NE DOIT PAS / DEVRAIT / PEUT** sont utilisés au sens normatif.
+
+### 1.3 Principes transversaux non négociables
+1) **Adjacency-only** : une couche communique uniquement avec sa voisine immédiate (Cx ↔ Cx±1). Toute exception est une anomalie à traiter (voir §2).  
+2) **Séparation fédéré / tenant** : la Fédération n’opère pas les charges applicatives tenant ; les tenants ne modifient pas les fondations fédérées.  
+3) **Portabilité intégrale** : tout tenant (C6–C8) **DOIT** pouvoir migrer entre membres fédérés sans perte de fonctionnalité, et sans réécriture de code structurelle.  
+4) **Régénération** : toute composante essentielle **DOIT** être reconstruisible à partir d’artefacts signés et versionnés (ADN numérique).  
+5) **Traçabilité** : tout flux structurant (artefacts, identités, décisions de conformité) **DOIT** produire des preuves vérifiables.
+
+---
+
+## 2. Schéma d’interface (contrat des membranes)
+
+```
+C1 ⇄ C2 ⇄ C3 ⇄ C4 ⇄ C5 ⇄ C6 ⇄ C7 ⇄ C8
+```
+
+### 2.1 Règles d’interface
+- **Cx ↔ Cx±1** : seul chemin normal.
+- **Routage obligatoire** : tout flux transversal (ex. tenant → forge) est médié par la couche intermédiaire (ex. C6 → C5 → C4).
+- **C5 comme membrane** : tout échange Fédération ↔ Tenant passe par C5.
+- **C3 comme système nerveux** : tout mécanisme de gouvernance, audit, conformité et supervision globale passe par C3 (et s’alimente via les couches adjacentes).
+
+### 2.2 “Une seule instance” vs haute disponibilité
+- Les couches **C1–C5** sont des **services fédératifs uniques** au niveau du modèle (un SSOT et un contrat).  
+- Elles **PEUVENT** être déployées en **réplicas** (HA), sans cesser d’être “une seule instance” au sens de gouvernance et d’interface.
+- Les couches **C6–C8** sont **multiples**, car elles existent **par tenant**.
+
+---
+
+## 3. Modèle de fiche (à utiliser pour toute couche)
+Chaque couche est documentée selon le format suivant (appliqué ci-dessous) :
+
+1) **Rôle vital (justification)** : pourquoi la couche existe, et ce que son absence casse.
+2) **Constitution (périmètre)** : inclus / exclus.
+3) **Responsabilités** : fonctions attendues.
+4) **Invariants** : règles non négociables propres à la couche.
+5) **Interfaces adjacentes** : entrées/sorties et contrats.
+6) **Artefacts & preuves** : ce qui DOIT être versionné, signé, auditable.
+7) **Exigences opérationnelles** : disponibilité, résilience, sauvegarde, SLO/SLA (selon maturité).
+8) **Anti‑patterns** : erreurs fréquentes à interdire.
+9) **Exemples de mise en œuvre** : technologies possibles (non prescriptif).
+
+---
+
+# 4. Constitution détaillée des couches
+
+## C1 — Racines physiques (Fédération)
+### 1) Rôle vital (justification)
+C1 existe pour **ancrer** l’écosystème dans le réel : énergie, climatisation, sécurité physique, serveurs, stockage brut.  
+Sans C1 : aucune résilience réelle, aucun contrôle de souveraineté matérielle, aucune capacité de reconstruction.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Sites physiques (salles, cages, racks), contrôle d’accès, surveillance.
+- Énergie (alimentation, onduleurs, génératrices), câblage, environnement.
+- Matériel : serveurs, switches physiques, liens, stockage primaire, pièces.
+- Inventaire, étiquetage, cycle de vie (acquisition → décommission).
+
+**Exclut :**
+- Routage logique et services réseau (C2).
+- Identité, audit, gouvernance (C3).
+- Forge, registres, pipelines (C4).
+- Toute exposition applicative tenant (C6–C8).
+
+### 3) Responsabilités
+- Garantir l’intégrité physique et la continuité énergétique.
+- Assurer la capacité d’hébergement (compute, storage brut) et la redondance.
+- Documenter l’inventaire matériel et l’état de santé.
+
+### 4) Invariants
+- Les tenants **NE DOIVENT PAS** dépendre de détails matériels non portables.
+- Toute ressource C1 doit être **remplaçable** par équivalent standard.
+
+### 5) Interfaces adjacentes (C1 ↔ C2)
+- Sortants : connectivité physique, liens, VLAN/L2, temps (NTP matériel si applicable).
+- Entrants : exigences de capacité, topologie réseau, contraintes de sécurité.
+
+### 6) Artefacts & preuves
+- Inventaire matériel (CMDB), schémas de câblage, plans de redondance.
+- Procédures d’intervention (runbooks), preuves de tests (UPS/génératrice).
+- Journal de changement (déploiements, remplacements).
+
+### 7) Exigences opérationnelles
+- Objectif : tolérance de panne (au minimum N+1 sur énergie critique selon maturité).
+- Sauvegarde : n/a (C1 fournit le support, pas les sauvegardes logiques).
+
+### 8) Anti‑patterns
+- “Serveur spécial” indispensable à un tenant.
+- Absence de CMDB / inventaire.
+- Mélange des accès physiques tenant/fédéré sans contrôle.
+
+### 9) Exemples de mise en œuvre
+- Datacenter membre, colocation souveraine, micro‑datacenter maillé.
+
+---
+
+## C2 — Système vasculaire (Fédération)
+### 1) Rôle vital (justification)
+C2 existe pour assurer la **circulation** : adressage, DNS racinaire autoritatif, PKI de transport, liens inter‑DC, segmentation.  
+Sans C2 : pas d’interconnexion fiable, pas de souveraineté de nommage, pas de chiffrement cohérent.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Réseau logique : routage, segmentation, interconnexion, politiques réseau.
+- DNS **autoritatif** fédéré (racine de nommage).
+- PKI de transport (certificats pour interconnexions et services fédérés).
+- Protection réseau (DDoS, filtrage, ACL, egress control) au niveau fédéré.
+
+**Exclut :**
+- Gestion d’identité et audit (C3).
+- Registres d’artefacts/pipelines (C4).
+- Proxy/API gateway tenant-facing (C5).
+
+### 3) Responsabilités
+- Assurer la connectivité est‑ouest fédérée (entre sites) et nord‑sud vers C3/C4.
+- Maintenir un nommage fédéré cohérent (DNS autoritatif).
+- Fournir des primitives réseau standardisées aux couches supérieures.
+
+### 4) Invariants
+- Les tenants ne parlent **jamais** directement à C2 : tout accès traverse C5.
+- Le DNS fédéré est la source de vérité des zones racines fédérées.
+
+### 5) Interfaces adjacentes
+- **C1 ↔ C2** : liens physiques, disponibilité, contraintes de site.
+- **C2 ↔ C3** : exposition des métriques réseau, événements de sécurité, services de résolution/PKI pour la gouvernance.
+
+### 6) Artefacts & preuves
+- Topologies, politiques réseau, zones DNS (IaC recommandé).
+- Journaux de changements réseau, tests de résilience inter‑sites.
+- Inventaire des certificats de transport et rotations.
+
+### 7) Exigences opérationnelles
+- Redondance des composants réseau critiques.
+- RTO/RPO réseau définis selon criticité des services fédérés.
+
+### 8) Anti‑patterns
+- “DNS sauvage” géré par un tenant.
+- Règles réseau ad‑hoc non versionnées.
+- Contournement de segmentation pour “aller plus vite”.
+
+### 9) Exemples de mise en œuvre
+- BGP/EVPN, firewalls, PowerDNS autoritatif, PKI interne.
+
+---
+
+## C3 — Système nerveux central (Fédération)
+### 1) Rôle vital (justification)
+C3 existe pour gouverner, superviser et auditer : c’est le **centre de décision** et de rétroaction.  
+Sans C3 : absence de cohérence de sécurité, impossibilité de conformité, aucun mécanisme d’apprentissage global.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Gouvernance : politiques, règles, contrôles, arbitrages.
+- Identité fédérée (IAM/SSO), annuaire, RBAC/ABAC fédératifs.
+- Journalisation/audit central (preuves, événements structurants).
+- Supervision/observabilité fédérée (métriques, alertes, incidents).
+- Conformité : critères, attestations, trajectoires de maturité.
+
+**Exclut :**
+- Build/release et stockage des artefacts (C4) — C3 dicte les règles, C4 exécute le métabolisme.
+- Exposition aux tenants (C5 gère la surface).
+
+### 3) Responsabilités
+- Définir et appliquer les politiques communes (sécurité, portabilité, traçabilité).
+- Opérer l’identité fédérée et les permissions de contribution.
+- Centraliser la détection d’anomalies systémiques et déclencher la remédiation.
+
+### 4) Invariants
+- Toute décision de conformité doit être traçable (qui/quoi/quand/pourquoi).
+- Les identités privilégiées doivent être gouvernées (MFA, just‑in‑time si maturité).
+
+### 5) Interfaces adjacentes
+- **C2 ↔ C3** : flux réseau et signaux de sécurité ; services de nommage/PKI.
+- **C3 ↔ C4** : règles de signature, politiques SBOM, exigences de pipelines, attestations.
+
+### 6) Artefacts & preuves
+- Politiques publiées (SSOT), journaux d’audit, registres de décisions.
+- Catégorisation d’incidents, post‑mortems, indicateurs de résilience.
+- Référentiels d’exigences (ex. Label / conformité).
+
+### 7) Exigences opérationnelles
+- Haute disponibilité logique (au minimum redondance des composants IAM/audit).
+- Rétention des logs conforme à la politique boréale.
+
+### 8) Anti‑patterns
+- Gouvernance “orale” non documentée.
+- Supervision uniquement locale, sans vue fédérée.
+- Identités partagées (“comptes génériques”).
+
+### 9) Exemples de mise en œuvre
+- Annuaire + SSO (OpenLDAP/Keycloak), SIEM léger, OTel/Prometheus, portails de conformité.
+
+---
+
+## C4 — Métabolisme commun / Forge mutualisée (Fédération)
+### 1) Rôle vital (justification)
+C4 existe pour produire, signer, stocker et distribuer les artefacts : c’est le **métabolisme** de l’écosystème.  
+Sans C4 : pas de chaîne d’approvisionnement vérifiable, pas d’ADN numérique partagé, pas de reconstruction fiable.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Forge (code, tickets, docs), registres (containers, paquets), dépôts d’artefacts.
+- Pipelines CI/CD fédérés, politiques de build, attestations, SBOM.
+- Signature d’artefacts (clé/PKI applicative), politique de provenance.
+- Catalogue : modèles, modules, composants de référence, “patterns” portables.
+- Stockage de secrets fédérés **si** gouverné (secrets de base, jamais des secrets métier tenant).
+
+**Exclut :**
+- Runtime d’exposition tenant (C5).
+- Exécution applicative tenant (C6–C8).
+
+### 3) Responsabilités
+- Offrir une chaîne de production reproductible (build → scan → signature → publication).
+- Héberger la source de vérité des composants mutualisés.
+- Garantir la disponibilité et l’intégrité des artefacts.
+
+### 4) Invariants
+- Un artefact consommé par C5/C6 **DOIT** être traçable (version, hash, provenance).
+- Les pipelines critiques **DOIVENT** être versionnés et audités.
+
+### 5) Interfaces adjacentes
+- **C3 ↔ C4** : politiques (signature, conformité, exigences SBOM), droits.
+- **C4 ↔ C5** : distribution d’artefacts, configs, descripteurs ; publication de surfaces d’API du pivot.
+
+### 6) Artefacts & preuves
+- Descripteurs YAML (ADN), IaC, manifests, SBOM, attestations.
+- Clés/empreintes, registres de signatures, journaux de releases.
+- Catalogue des modules “boréalisés”.
+
+### 7) Exigences opérationnelles
+- Sauvegardes et réplication (C4 est critique : perte = perte d’ADN).
+- Contrôles d’intégrité (immuabilité des releases, rétention).
+
+### 8) Anti‑patterns
+- Artefacts “binaries” sans sources ou sans SBOM.
+- Déploiements manuels non reproductibles.
+- Secrets tenant stockés en C4 sans garde‑fous.
+
+### 9) Exemples de mise en œuvre
+- Forgejo/Git, registries OCI, Cosign/Sigstore‑like, scanners (Trivy/Grype), IaC (Terraform/Ansible).
+
+---
+
+## C5 — Membrane d’échange / Pivot (Fédération – service commun, multi‑tenant)
+### 1) Rôle vital (justification)
+C5 existe pour **réguler** l’échange entre racines et canopée : exposition contrôlée, médiation, filtrage, compatibilité de portabilité.  
+Sans C5 : les tenants finissent par “toucher” C1–C4 directement (dérive), et la séparation fédéré/tenant s’effondre.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Surface d’entrée/sortie : reverse proxy, API gateway, routage tenant‑aware.
+- Médiation d’identité : intégration SSO, tokens, délégation, sessions.
+- Politique de flux : rate limiting, quotas, contrats d’API, WAF logique.
+- Services de “récursion” et d’accès contrôlé (ex. DNS récursif tenant‑side si prévu).
+- Portail d’administration pivot (surfaces d’échange), observabilité exposable.
+
+**Exclut :**
+- Stockage d’artefacts (C4).
+- Runtime applicatif métier tenant (C6–C8).
+- Décision de gouvernance globale (C3).
+
+### 3) Responsabilités
+- Fournir un **service unique** de membrane fédérative, multi‑tenant, gouverné.
+- Appliquer les politiques de C3 et consommer les artefacts/politiques de C4.
+- Garantir que tout accès tenant aux ressources fédérées passe par des contrôles explicites.
+
+### 4) Invariants
+- C5 est **un service fédéral** : les tenants ne possèdent pas l’instance, seulement leur **tranche logique** (config/politiques).
+- C5 **NE DOIT PAS** contenir de logique métier tenant durable.
+- Toute exception de flux non adjacent est **interdite** (elle doit être re‑mappée via C5 ou C3).
+
+### 5) Interfaces adjacentes
+- **C4 ↔ C5** : artefacts du pivot, politiques, descripteurs, versions.
+- **C5 ↔ C6** : routage vers services tenant, injection d’identité, exposition d’APIs, collecte de métriques.
+
+### 6) Artefacts & preuves
+- Configuration “slice” par tenant (YAML/manifest), versionnée et auditable.
+- Journaux d’accès (tenant‑aware), politiques appliquées, preuves de déploiement.
+- Contrats d’API, règles de quotas, attestations WAF.
+
+### 7) Exigences opérationnelles
+- HA (réplicas) fortement recommandé : C5 est un point de passage critique.
+- Journalisation et métriques par tenant (au minimum agrégées, idéalement exportables).
+
+### 8) Anti‑patterns
+- Tenants qui contournent C5 pour parler à C4/C3/C2.
+- Ajout de logique applicative métier tenant dans la membrane.
+- Config non versionnée (hotfixes invisibles).
+
+### 9) Exemples de mise en œuvre
+- Nginx/Traefik/Envoy + OIDC, API gateway, portail admin, DNS récursif contrôlé.
+
+---
+
+## C6 — Tissu fonctionnel (Tenants)
+### 1) Rôle vital (justification)
+C6 existe pour héberger les **services applicatifs génériques** d’un tenant : backends, workflows, APIs internes.  
+Sans C6 : les produits (C7) deviennent monolithiques, non portables, et la connaissance (C8) se détache du runtime.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Services backend, microservices, jobs, orchestrations, bases de données tenant.
+- APIs internes et contrats de service.
+- Observabilité applicative (métriques, logs, traces) côté tenant.
+
+**Exclut :**
+- Exposition publique directe : passe par C5.
+- UX/fronts (C7) et analytique/IA (C8).
+
+### 3) Responsabilités
+- Fournir les fonctions métier réutilisables (domain services).
+- Respecter les contraintes de portabilité (stateless si possible, data migration plan).
+- Exposer des healthchecks, métriques et contrats d’API.
+
+### 4) Invariants
+- Aucun secret fédéré n’est copié : usage via mécanismes contrôlés.
+- Toute dépendance externe doit être déclarée (SBOM/manifest du tenant si requis).
+
+### 5) Interfaces adjacentes
+- **C5 ↔ C6** : réception d’identité/délégation, trafic entrant, politiques.
+- **C6 ↔ C7** : APIs produits, BFF, services d’assemblage.
+
+### 6) Artefacts & preuves
+- Descripteur tenant (YAML), manifests de déploiement, IaC.
+- Contrats d’API, tests, versions d’images, SBOM (au minimum pour releases).
+- Plan de migration des données (portabilité).
+
+### 7) Exigences opérationnelles
+- Sauvegardes et restaurations testées pour données tenant.
+- SLO propres au produit, mais observables et exportables.
+
+### 8) Anti‑patterns
+- Endpoint public direct sans C5.
+- État local non sauvegardé (données “sur disque” sans plan).
+- Configuration non reproductible (snowflake).
+
+### 9) Exemples de mise en œuvre
+- Kubernetes/Nomad, bases PostgreSQL/MariaDB, queues, workers, OTel côté tenant.
+
+---
+
+## C7 — Organes sensoriels & moteurs (Tenants)
+### 1) Rôle vital (justification)
+C7 existe pour matérialiser l’expérience : interfaces, produits, interactions humaines.  
+Sans C7 : C6 reste une “boîte noire” inutilisable, et C8 n’a pas de boucle de rétroaction utilisateur.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Frontends web/mobile, clients, portails, UI kits.
+- BFF (backend-for-frontend) si pertinent (sinon en C6, mais boundary clair).
+- Gestion de sessions/UX (sous contraintes d’identité via C5/C3).
+
+**Exclut :**
+- Règles d’accès fédérées (C3) et médiation d’identité (C5).
+- Analytique/IA et mémoire cognitive (C8).
+
+### 3) Responsabilités
+- Offrir une UX cohérente, sécurisée, accessible.
+- Appliquer les contraintes de sécurité (CSP, protections client) en cohérence avec C5.
+- Produire des signaux d’usage exploitables (télémétrie, événements) vers C8.
+
+### 4) Invariants
+- Les identités et sessions doivent respecter le cadre fédéré (pas d’IAM “shadow”).
+- Les données sensibles doivent être minimisées côté client.
+
+### 5) Interfaces adjacentes
+- **C6 ↔ C7** : consommation des APIs, orchestration des parcours.
+- **C7 ↔ C8** : émission d’événements, métriques d’usage, feedback.
+
+### 6) Artefacts & preuves
+- Releases UI versionnées, hashées, reproductibles.
+- Matrice de compatibilité (navigateurs), preuves d’accessibilité (selon exigences).
+- Schémas d’événements d’usage.
+
+### 7) Exigences opérationnelles
+- CDN/cache si nécessaire (via C5 ou services tenant), objectifs de performance.
+
+### 8) Anti‑patterns
+- Secrets dans le client.
+- APIs “direct to C4/C3”.
+- UX qui impose des dépendances non portables (services externes non maîtrisés).
+
+### 9) Exemples de mise en œuvre
+- SPA/SSR, apps mobiles, design system, analytics events.
+
+---
+
+## C8 — Conscience cognitive (Tenants)
+### 1) Rôle vital (justification)
+C8 existe pour transformer l’usage et les données en **connaissance** : analytique, recherche, IA, décision.  
+Sans C8 : aucun apprentissage, aucune optimisation, aucune “mémoire” structurée.
+
+### 2) Constitution (périmètre)
+**Inclut :**
+- Pipelines data, entrepôts/lacs tenant, modèles ML/IA, recherche sémantique.
+- Gouvernance des données tenant (catalogue, qualité, lineage) au niveau tenant.
+- Tableaux de bord décisionnels, recommandations.
+
+**Exclut :**
+- Gouvernance fédérée globale (C3) sauf exigences minimales de conformité.
+- Runtime de produit (C6/C7) — C8 consomme des événements/données.
+
+### 3) Responsabilités
+- Mettre en place la boucle d’apprentissage (collecte → traitement → décision → action).
+- Assurer la qualité, la confidentialité et la minimisation des données.
+- Fournir des signaux remontants utiles (insights) vers C6/C7 et, sous forme agrégée, vers C3 si requis.
+
+### 4) Invariants
+- Les données tenant restent sous contrôle tenant (politiques, rétention, accès).
+- Toute dérivation de données doit être justifiable (finalité, minimisation).
+
+### 5) Interfaces adjacentes
+- **C7 ↔ C8** : réception des signaux d’usage et feedback.
+- **C8 ↔ (retour vers C7/C6)** : recommandations, scores, décisions (toujours via contrats adjacents).
+
+### 6) Artefacts & preuves
+- Jeux de données versionnés si applicable, schémas, lineage.
+- Modèles versionnés, évaluations, cartes de modèles (selon maturité).
+- Politiques de rétention et accès.
+
+### 7) Exigences opérationnelles
+- Sauvegardes / réplication des données analytiques selon criticité.
+- Contrôles d’accès robustes (données sensibles).
+
+### 8) Anti‑patterns
+- “Aspirer toutes les données” sans finalité.
+- Modèles non versionnés, non testés, non auditables.
+- Mélange de données tenants sans cloisonnement.
+
+### 9) Exemples de mise en œuvre
+- ELT/ETL, lakehouse, BI, vector store, pipelines ML.
+
+---
+
+# 5. Annexes (recommandées)
+
+## A) Tableau de responsabilité (ownership)
+- **C1–C4 : Fédération** (opération + gouvernance).
+- **C5 : Fédération (service commun) + slices tenant** (config/politiques par tenant).
+- **C6–C8 : Tenants** (opération + données + produits).
+
+## B) Checklist “preuve minimale” par couche (MVP conformité)
+- C1 : inventaire + runbooks + tests énergie.
+- C2 : topologie + DNS autoritatif + journal de changements.
+- C3 : IAM + audit + politiques publiées.
+- C4 : forge + registry + signature + sauvegarde + SBOM minimal.
+- C5 : routage tenant-aware + logs + quotas + config versionnée.
+- C6 : manifests + sauvegardes données + healthchecks + API contracts.
+- C7 : releases reproductibles + schéma événements usage.
+- C8 : politiques données + versioning modèles + lineage minimal.
+
+## C) Gouvernance du changement (CRB)
+Toute modification de périmètre d’une couche (inclusion/exclusion, interfaces, invariants) doit :
+1) être proposée comme **Avis de Réalignement (CRB)**,
+2) inclure impact sur portabilité, séparation, conformité,
+3) produire une mise à jour versionnée de ce SSOT.
+
+---
+
+
+---
+
+## 6. Annexe D — Contrôles de conformité (Label Prestige)
+Pour l’attribution du Label et l’audit pair-à-pair, utiliser l’annexe dédiée :
+- `06_AnnexeD_Controles_Conformite_Label_Prestige_par_Couche_v1.0.md`
diff --git a/docs/10-architecture/10 - Les 8 couches du modèle Boréal.md b/docs/10-architecture/10 - Les 8 couches du modèle Boréal.md
new file mode 100644
index 0000000..5ba9986
--- /dev/null
+++ b/docs/10-architecture/10 - Les 8 couches du modèle Boréal.md	
@@ -0,0 +1,587 @@
+# 🌲 Constitution des couches – Modèle boréal à 8 couches (C1–C8)
+
+**Version :** 1.1  
+**Date :** 25 janvier 2026  
+**Statut :** Référence normative (SSOT)  
+**Portée :** Définir, justifier et cristalliser la **constitution** de chaque couche du modèle à 8 couches de l’Alliance Boréale, ainsi que les règles d’interface et de gouvernance associées.
+
+---
+
+## 0. Pourquoi ce document existe
+
+Le modèle à 8 couches sert de **contrat d’architecture** entre :
+
+- la **Fédération** (C1–C4),
+- le **Pivot** (C5),
+- les **Tenants** (C6–C8).
+
+Sans une constitution explicite par couche, le modèle dérive : les responsabilités se mélangent, les flux “sautent” des couches, la portabilité s’érode, et la conformité devient invérifiable.  
+Ce document fixe  les limites, responsabilités et artefacts attendus de chaque couche.
+
+---
+
+## 1. Définitions et conventions normatives
+
+### 1.1 Terminologie
+
+- **Couche (Cx)** : “organe” fonctionnel du système. Chaque couche a un périmètre, des responsabilités, des interfaces et des preuves attendues.
+- **Fédération** : ensemble des capacités mutualisées et opérées pour héberger l’écosystème (C1–C4).
+- **Tenant** : entité logique ou organisationnelle qui déploie des services/produits/connaissances dans la canopée (C6–C8).
+- **Pivot** : membrane opérationnelle (C5) reliant fédération et tenants, régulant les flux.
+- **ADN numérique** : ensemble minimal d’artefacts permettant la **reconstruction** (descripteur, IaC, artefacts signés, SBOM).
+
+### 1.2 Langage normatif
+
+Les termes **DOIT / NE DOIT PAS / DEVRAIT / PEUT** sont utilisés au sens normatif.
+
+### 1.3 Principes transversaux non négociables
+
+1. **Adjacency-only** : une couche communique uniquement avec sa voisine immédiate (Cx ↔ Cx±1). Toute exception est une anomalie à traiter (voir §2).
+2. **Séparation fédéré / tenant** : la Fédération n’opère pas les charges applicatives tenant ; les tenants ne modifient pas les fondations fédérées.
+3. **Portabilité intégrale** : tout tenant (C6–C8) **DOIT** pouvoir migrer entre membres fédérés sans perte de fonctionnalité, et sans réécriture de code structurelle.
+4. **Régénération** : toute composante essentielle **DOIT** être reconstruisible à partir d’artefacts signés et versionnés (ADN numérique).
+5. **Traçabilité** : tout flux structurant (artefacts, identités, décisions de conformité) **DOIT** produire des preuves vérifiables.
+
+---
+
+## 2. Schéma d’interface (contrat des membranes)
+
+```
+C1 ⇄ C2 ⇄ C3 ⇄ C4 ⇄ C5 ⇄ C6 ⇄ C7 ⇄ C8
+```
+
+### 2.1 Règles d’interface
+
+- **Cx ↔ Cx±1** : seul chemin normal.
+- **Routage obligatoire** : tout flux transversal (ex. tenant → forge) est médié par la couche intermédiaire (ex. C6 → C5 → C4).
+- **C5 comme membrane** : tout échange Fédération ↔ Tenant passe par C5.
+- **C3 comme système nerveux** : tout mécanisme de gouvernance, audit, conformité et supervision globale passe par C3 (et s’alimente via les couches adjacentes).
+
+### 2.2 “Une seule instance” vs haute disponibilité
+
+- Les couches **C1–C5** sont des **services fédératifs uniques** au niveau du modèle (un SSOT et un contrat).
+- Elles **PEUVENT** être déployées en **réplicas** (HA), sans cesser d’être “une seule instance” au sens de gouvernance et d’interface.
+- Les couches **C6–C8** sont **multiples**, car elles existent **par tenant**.
+
+---
+
+## 3. Modèle de fiche (à utiliser pour toute couche)
+
+Chaque couche est documentée selon le format suivant (appliqué ci-dessous) :
+
+1. **Rôle vital (justification)** : pourquoi la couche existe, et ce que son absence casse.
+2. **Constitution (périmètre)** : inclus / exclus.
+3. **Responsabilités** : fonctions attendues.
+4. **Invariants** : règles non négociables propres à la couche.
+5. **Interfaces adjacentes** : entrées/sorties et contrats.
+6. **Artefacts & preuves** : ce qui DOIT être versionné, signé, auditable.
+7. **Exigences opérationnelles** : disponibilité, résilience, sauvegarde, SLO/SLA (selon maturité).
+8. **Anti‑patterns** : erreurs fréquentes à interdire.
+9. **Exemples de mise en œuvre** : technologies possibles (non prescriptif).
+
+---
+
+# 4. Constitution détaillée des couches
+
+## C1 — Racines physiques (Fédération)
+
+### 1) Rôle vital (justification)
+
+C1 existe pour **ancrer** l’écosystème dans le réel : énergie, climatisation, sécurité physique, serveurs, stockage brut.  
+Sans C1 : aucune résilience réelle, aucun contrôle de souveraineté matérielle, aucune capacité de reconstruction.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Sites physiques (salles, cages, racks), contrôle d’accès, surveillance.
+- Énergie (alimentation, onduleurs, génératrices), câblage, environnement.
+- Matériel : serveurs, switches physiques, liens, stockage primaire, pièces.
+- Inventaire, étiquetage, cycle de vie (acquisition → décommission).
+
+**Exclut :**
+
+- Routage logique et services réseau (C2).
+- Identité, audit, gouvernance (C3).
+- Forge, registres, pipelines (C4).
+- Toute exposition applicative tenant (C6–C8).
+
+### 3) Responsabilités
+
+- Garantir l’intégrité physique et la continuité énergétique.
+- Assurer la capacité d’hébergement (compute, storage brut) et la redondance.
+- Documenter l’inventaire matériel et l’état de santé.
+
+### 4) Invariants
+
+- Les tenants **NE DOIVENT PAS** dépendre de détails matériels non portables.
+- Toute ressource C1 doit être **remplaçable** par équivalent standard.
+
+### 5) Interfaces adjacentes (C1 ↔ C2)
+
+- Sortants : connectivité physique, liens, VLAN/L2, temps (NTP matériel si applicable).
+- Entrants : exigences de capacité, topologie réseau, contraintes de sécurité.
+
+### 6) Artefacts & preuves
+
+- Inventaire matériel (CMDB), schémas de câblage, plans de redondance.
+- Procédures d’intervention (runbooks), preuves de tests (UPS/génératrice).
+- Journal de changement (déploiements, remplacements).
+
+### 7) Exigences opérationnelles
+
+- Objectif : tolérance de panne (au minimum N+1 sur énergie critique selon maturité).
+- Sauvegarde : n/a (C1 fournit le support, pas les sauvegardes logiques).
+
+### 8) Anti‑patterns
+
+- “Serveur spécial” indispensable à un tenant.
+- Absence de CMDB / inventaire.
+- Mélange des accès physiques tenant/fédéré sans contrôle.
+
+### 9) Exemples de mise en œuvre
+
+- Datacenter membre, colocation souveraine, micro‑datacenter maillé.
+
+---
+
+## C2 — Système vasculaire (Fédération)
+
+### 1) Rôle vital (justification)
+
+C2 existe pour assurer la **circulation** : adressage, DNS racinaire autoritatif, PKI de transport, liens inter‑DC, segmentation.  
+Sans C2 : pas d’interconnexion fiable, pas de souveraineté de nommage, pas de chiffrement cohérent.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Réseau logique : routage, segmentation, interconnexion, politiques réseau.
+- DNS **autoritatif** fédéré (racine de nommage).
+- PKI de transport (certificats pour interconnexions et services fédérés).
+- Protection réseau (DDoS, filtrage, ACL, egress control) au niveau fédéré.
+
+**Exclut :**
+
+- Gestion d’identité et audit (C3).
+- Registres d’artefacts/pipelines (C4).
+- Proxy/API gateway tenant-facing (C5).
+
+### 3) Responsabilités
+
+- Assurer la connectivité est‑ouest fédérée (entre sites) et nord‑sud vers C3/C4.
+- Maintenir un nommage fédéré cohérent (DNS autoritatif).
+- Fournir des primitives réseau standardisées aux couches supérieures.
+
+### 4) Invariants
+
+- Les tenants ne parlent **jamais** directement à C2 : tout accès traverse C5.
+- Le DNS fédéré est la source de vérité des zones racines fédérées.
+
+### 5) Interfaces adjacentes
+
+- **C1 ↔ C2** : liens physiques, disponibilité, contraintes de site.
+- **C2 ↔ C3** : exposition des métriques réseau, événements de sécurité, services de résolution/PKI pour la gouvernance.
+
+### 6) Artefacts & preuves
+
+- Topologies, politiques réseau, zones DNS (IaC recommandé).
+- Journaux de changements réseau, tests de résilience inter‑sites.
+- Inventaire des certificats de transport et rotations.
+
+### 7) Exigences opérationnelles
+
+- Redondance des composants réseau critiques.
+- RTO/RPO réseau définis selon criticité des services fédérés.
+
+### 8) Anti‑patterns
+
+- “DNS sauvage” géré par un tenant.
+- Règles réseau ad‑hoc non versionnées.
+- Contournement de segmentation pour “aller plus vite”.
+
+### 9) Exemples de mise en œuvre
+
+- BGP/EVPN, firewalls, PowerDNS autoritatif, PKI interne.
+
+---
+
+## C3 — Système nerveux central (Fédération)
+
+### 1) Rôle vital (justification)
+
+C3 existe pour gouverner, superviser et auditer : c’est le **centre de décision** et de rétroaction.  
+Sans C3 : absence de cohérence de sécurité, impossibilité de conformité, aucun mécanisme d’apprentissage global.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Gouvernance : politiques, règles, contrôles, arbitrages.
+- Identité fédérée (IAM/SSO), annuaire, RBAC/ABAC fédératifs.
+- Journalisation/audit central (preuves, événements structurants).
+- Supervision/observabilité fédérée (métriques, alertes, incidents).
+- Conformité : critères, attestations, trajectoires de maturité.
+
+**Exclut :**
+
+- Build/release et stockage des artefacts (C4) — C3 dicte les règles, C4 exécute le métabolisme.
+- Exposition aux tenants (C5 gère la surface).
+
+### 3) Responsabilités
+
+- Définir et appliquer les politiques communes (sécurité, portabilité, traçabilité).
+- Opérer l’identité fédérée et les permissions de contribution.
+- Centraliser la détection d’anomalies systémiques et déclencher la remédiation.
+
+### 4) Invariants
+
+- Toute décision de conformité doit être traçable (qui/quoi/quand/pourquoi).
+- Les identités privilégiées doivent être gouvernées (MFA, just‑in‑time si maturité).
+
+### 5) Interfaces adjacentes
+
+- **C2 ↔ C3** : flux réseau et signaux de sécurité ; services de nommage/PKI.
+- **C3 ↔ C4** : règles de signature, politiques SBOM, exigences de pipelines, attestations.
+
+### 6) Artefacts & preuves
+
+- Politiques publiées (SSOT), journaux d’audit, registres de décisions.
+- Catégorisation d’incidents, post‑mortems, indicateurs de résilience.
+- Référentiels d’exigences (ex. Label / conformité).
+
+### 7) Exigences opérationnelles
+
+- Haute disponibilité logique (au minimum redondance des composants IAM/audit).
+- Rétention des logs conforme à la politique boréale.
+
+### 8) Anti‑patterns
+
+- Gouvernance “orale” non documentée.
+- Supervision uniquement locale, sans vue fédérée.
+- Identités partagées (“comptes génériques”).
+
+### 9) Exemples de mise en œuvre
+
+- Annuaire + SSO (OpenLDAP/Keycloak), SIEM léger, OTel/Prometheus, portails de conformité.
+
+---
+
+## C4 — Métabolisme commun / Forge mutualisée (Fédération)
+
+### 1) Rôle vital (justification)
+
+C4 existe pour produire, signer, stocker et distribuer les artefacts : c’est le **métabolisme** de l’écosystème.  
+Sans C4 : pas de chaîne d’approvisionnement vérifiable, pas d’ADN numérique partagé, pas de reconstruction fiable.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Forge (code, tickets, docs), registres (containers, paquets), dépôts d’artefacts.
+- Pipelines CI/CD fédérés, politiques de build, attestations, SBOM.
+- Signature d’artefacts (clé/PKI applicative), politique de provenance.
+- Catalogue : modèles, modules, composants de référence, “patterns” portables.
+- Stockage de secrets fédérés **si** gouverné (secrets de base, jamais des secrets métier tenant).
+
+**Exclut :**
+
+- Runtime d’exposition tenant (C5).
+- Exécution applicative tenant (C6–C8).
+
+### 3) Responsabilités
+
+- Offrir une chaîne de production reproductible (build → scan → signature → publication).
+- Héberger la source de vérité des composants mutualisés.
+- Garantir la disponibilité et l’intégrité des artefacts.
+
+### 4) Invariants
+
+- Un artefact consommé par C5/C6 **DOIT** être traçable (version, hash, provenance).
+- Les pipelines critiques **DOIVENT** être versionnés et audités.
+
+### 5) Interfaces adjacentes
+
+- **C3 ↔ C4** : politiques (signature, conformité, exigences SBOM), droits.
+- **C4 ↔ C5** : distribution d’artefacts, configs, descripteurs ; publication de surfaces d’API du pivot.
+
+### 6) Artefacts & preuves
+
+- Descripteurs YAML (ADN), IaC, manifests, SBOM, attestations.
+- Clés/empreintes, registres de signatures, journaux de releases.
+- Catalogue des modules “boréalisés”.
+
+### 7) Exigences opérationnelles
+
+- Sauvegardes et réplication (C4 est critique : perte = perte d’ADN).
+- Contrôles d’intégrité (immuabilité des releases, rétention).
+
+### 8) Anti‑patterns
+
+- Artefacts “binaries” sans sources ou sans SBOM.
+- Déploiements manuels non reproductibles.
+- Secrets tenant stockés en C4 sans garde‑fous.
+
+### 9) Exemples de mise en œuvre
+
+- Forgejo/Git, registries OCI, Cosign/Sigstore‑like, scanners (Trivy/Grype), IaC (Terraform/Ansible).
+
+---
+
+## C5 — Membrane d’échange / Pivot (Fédération – service commun, multi‑tenant)
+
+### 1) Rôle vital (justification)
+
+C5 existe pour **réguler** l’échange entre racines et canopée : exposition contrôlée, médiation, filtrage, compatibilité de portabilité.  
+Sans C5 : les tenants finissent par “toucher” C1–C4 directement (dérive), et la séparation fédéré/tenant s’effondre.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Surface d’entrée/sortie : reverse proxy, API gateway, routage tenant‑aware.
+- Médiation d’identité : intégration SSO, tokens, délégation, sessions.
+- Politique de flux : rate limiting, quotas, contrats d’API, WAF logique.
+- Services de “récursion” et d’accès contrôlé (ex. DNS récursif tenant‑side si prévu).
+- Portail d’administration pivot (surfaces d’échange), observabilité exposable.
+
+**Exclut :**
+
+- Stockage d’artefacts (C4).
+- Runtime applicatif métier tenant (C6–C8).
+- Décision de gouvernance globale (C3).
+
+### 3) Responsabilités
+
+- Fournir un **service unique** de membrane fédérative, multi‑tenant, gouverné.
+- Appliquer les politiques de C3 et consommer les artefacts/politiques de C4.
+- Garantir que tout accès tenant aux ressources fédérées passe par des contrôles explicites.
+
+### 4) Invariants
+
+- C5 est **un service fédéral** : les tenants ne possèdent pas l’instance, seulement leur **tranche logique** (config/politiques).
+- C5 **NE DOIT PAS** contenir de logique métier tenant durable.
+- Toute exception de flux non adjacent est **interdite** (elle doit être re‑mappée via C5 ou C3).
+
+### 5) Interfaces adjacentes
+
+- **C4 ↔ C5** : artefacts du pivot, politiques, descripteurs, versions.
+- **C5 ↔ C6** : routage vers services tenant, injection d’identité, exposition d’APIs, collecte de métriques.
+
+### 6) Artefacts & preuves
+
+- Configuration “slice” par tenant (YAML/manifest), versionnée et auditable.
+- Journaux d’accès (tenant‑aware), politiques appliquées, preuves de déploiement.
+- Contrats d’API, règles de quotas, attestations WAF.
+
+### 7) Exigences opérationnelles
+
+- HA (réplicas) fortement recommandé : C5 est un point de passage critique.
+- Journalisation et métriques par tenant (au minimum agrégées, idéalement exportables).
+
+### 8) Anti‑patterns
+
+- Tenants qui contournent C5 pour parler à C4/C3/C2.
+- Ajout de logique applicative métier tenant dans la membrane.
+- Config non versionnée (hotfixes invisibles).
+
+### 9) Exemples de mise en œuvre
+
+- Nginx/Traefik/Envoy + OIDC, API gateway, portail admin, DNS récursif contrôlé.
+
+---
+
+## C6 — Tissu fonctionnel (Tenants)
+
+### 1) Rôle vital (justification)
+
+C6 existe pour héberger les **services applicatifs génériques** d’un tenant : backends, workflows, APIs internes.  
+Sans C6 : les produits (C7) deviennent monolithiques, non portables, et la connaissance (C8) se détache du runtime.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Services backend, microservices, jobs, orchestrations, bases de données tenant.
+- APIs internes et contrats de service.
+- Observabilité applicative (métriques, logs, traces) côté tenant.
+
+**Exclut :**
+
+- Exposition publique directe : passe par C5.
+- UX/fronts (C7) et analytique/IA (C8).
+
+### 3) Responsabilités
+
+- Fournir les fonctions métier réutilisables (domain services).
+- Respecter les contraintes de portabilité (stateless si possible, data migration plan).
+- Exposer des healthchecks, métriques et contrats d’API.
+
+### 4) Invariants
+
+- Aucun secret fédéré n’est copié : usage via mécanismes contrôlés.
+- Toute dépendance externe doit être déclarée (SBOM/manifest du tenant si requis).
+
+### 5) Interfaces adjacentes
+
+- **C5 ↔ C6** : réception d’identité/délégation, trafic entrant, politiques.
+- **C6 ↔ C7** : APIs produits, BFF, services d’assemblage.
+
+### 6) Artefacts & preuves
+
+- Descripteur tenant (YAML), manifests de déploiement, IaC.
+- Contrats d’API, tests, versions d’images, SBOM (au minimum pour releases).
+- Plan de migration des données (portabilité).
+
+### 7) Exigences opérationnelles
+
+- Sauvegardes et restaurations testées pour données tenant.
+- SLO propres au produit, mais observables et exportables.
+
+### 8) Anti‑patterns
+
+- Endpoint public direct sans C5.
+- État local non sauvegardé (données “sur disque” sans plan).
+- Configuration non reproductible (snowflake).
+
+### 9) Exemples de mise en œuvre
+
+- Kubernetes/Nomad, bases PostgreSQL/MariaDB, queues, workers, OTel côté tenant.
+
+---
+
+## C7 — Organes sensoriels & moteurs (Tenants)
+
+### 1) Rôle vital (justification)
+
+C7 existe pour matérialiser l’expérience : interfaces, produits, interactions humaines.  
+Sans C7 : C6 reste une “boîte noire” inutilisable, et C8 n’a pas de boucle de rétroaction utilisateur.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Frontends web/mobile, clients, portails, UI kits.
+- BFF (backend-for-frontend) si pertinent (sinon en C6, mais boundary clair).
+- Gestion de sessions/UX (sous contraintes d’identité via C5/C3).
+
+**Exclut :**
+
+- Règles d’accès fédérées (C3) et médiation d’identité (C5).
+- Analytique/IA et mémoire cognitive (C8).
+
+### 3) Responsabilités
+
+- Offrir une UX cohérente, sécurisée, accessible.
+- Appliquer les contraintes de sécurité (CSP, protections client) en cohérence avec C5.
+- Produire des signaux d’usage exploitables (télémétrie, événements) vers C8.
+
+### 4) Invariants
+
+- Les identités et sessions doivent respecter le cadre fédéré (pas d’IAM “shadow”).
+- Les données sensibles doivent être minimisées côté client.
+
+### 5) Interfaces adjacentes
+
+- **C6 ↔ C7** : consommation des APIs, orchestration des parcours.
+- **C7 ↔ C8** : émission d’événements, métriques d’usage, feedback.
+
+### 6) Artefacts & preuves
+
+- Releases UI versionnées, hashées, reproductibles.
+- Matrice de compatibilité (navigateurs), preuves d’accessibilité (selon exigences).
+- Schémas d’événements d’usage.
+
+### 7) Exigences opérationnelles
+
+- CDN/cache si nécessaire (via C5 ou services tenant), objectifs de performance.
+
+### 8) Anti‑patterns
+
+- Secrets dans le client.
+- APIs “direct to C4/C3”.
+- UX qui impose des dépendances non portables (services externes non maîtrisés).
+
+### 9) Exemples de mise en œuvre
+
+- SPA/SSR, apps mobiles, design system, analytics events.
+
+---
+
+## C8 — Conscience cognitive (Tenants)
+
+### 1) Rôle vital (justification)
+
+C8 existe pour transformer l’usage et les données en **connaissance** : analytique, recherche, IA, décision.  
+Sans C8 : aucun apprentissage, aucune optimisation, aucune “mémoire” structurée.
+
+### 2) Constitution (périmètre)
+
+**Inclut :**
+
+- Pipelines data, entrepôts/lacs tenant, modèles ML/IA, recherche sémantique.
+- Gouvernance des données tenant (catalogue, qualité, lineage) au niveau tenant.
+- Tableaux de bord décisionnels, recommandations.
+
+**Exclut :**
+
+- Gouvernance fédérée globale (C3) sauf exigences minimales de conformité.
+- Runtime de produit (C6/C7) — C8 consomme des événements/données.
+
+### 3) Responsabilités
+
+- Mettre en place la boucle d’apprentissage (collecte → traitement → décision → action).
+- Assurer la qualité, la confidentialité et la minimisation des données.
+- Fournir des signaux remontants utiles (insights) vers C6/C7 et, sous forme agrégée, vers C3 si requis.
+
+### 4) Invariants
+
+- Les données tenant restent sous contrôle tenant (politiques, rétention, accès).
+- Toute dérivation de données doit être justifiable (finalité, minimisation).
+
+### 5) Interfaces adjacentes
+
+- **C7 ↔ C8** : réception des signaux d’usage et feedback.
+- **C8 ↔ (retour vers C7/C6)** : recommandations, scores, décisions (toujours via contrats adjacents).
+
+### 6) Artefacts & preuves
+
+- Jeux de données versionnés si applicable, schémas, lineage.
+- Modèles versionnés, évaluations, cartes de modèles (selon maturité).
+- Politiques de rétention et accès.
+
+### 7) Exigences opérationnelles
+
+- Sauvegardes / réplication des données analytiques selon criticité.
+- Contrôles d’accès robustes (données sensibles).
+
+### 8) Anti‑patterns
+
+- “Aspirer toutes les données” sans finalité.
+- Modèles non versionnés, non testés, non auditables.
+- Mélange de données tenants sans cloisonnement.
+
+### 9) Exemples de mise en œuvre
+
+- ELT/ETL, lakehouse, BI, vector store, pipelines ML.
+
+---
+
+# 5. Annexes (recommandées)
+
+## A) Tableau de responsabilité (ownership)
+
+- **C1–C4 : Fédération** (opération + gouvernance).
+- **C5 : Fédération (service commun) + slices tenant** (config/politiques par tenant).
+- **C6–C8 : Tenants** (opération + données + produits).
+
+## B) Checklist “preuve minimale” par couche (MVP conformité)
+
+- C1 : inventaire + runbooks + tests énergie.
+- C2 : topologie + DNS autoritatif + journal de changements.
+- C3 : IAM + audit + politiques publiées.
+- C4 : forge + registry + signature + sauvegarde + SBOM minimal.
+- C5 : routage tenant-aware + logs + quotas + config versionnée.
+- C6 : manifests + sauvegardes données + healthchecks + API contracts.
+- C7 : releases reproductibles + schéma événements usage.
+- C8 : politiques données + versioning modèles + lineage minimal.
\ No newline at end of file
diff --git a/docs/10-architecture/10 - Modèle Boréal.md b/docs/10-architecture/10 - Modèle Boréal.md
new file mode 100644
index 0000000..15c6d27
--- /dev/null
+++ b/docs/10-architecture/10 - Modèle Boréal.md	
@@ -0,0 +1,189 @@
+# 🌲 Modèle Boréal à 8 couches
+
+**Version :** 3.0  
+**Date :** 25 octobre 2025  
+**Statut :** Référence vivante (SSOT)  
+**Objet :** Décrire l’architecture boréale comme un **organisme fédératif vivant**, capable de se régénérer, de croître et de s’adapter sans rompre son intégrité.  
+**Compatibilité :** Conforme au réordonnancement « endroit » : **C3 = gouvernance/supervision**, **C4 = mutualisation/forge**, **C5 = pivot**, **C6–C8 = tenants**.
+
+---
+
+## 1. 🌱 Introduction
+
+L’Alliance Boréale n’est pas un système informatique : c’est un **écosystème**.  
+Ses datacenters sont ses **racines** dans le sol du monde physique, ses tenants des **feuilles** tournées vers la lumière de la connaissance, et ses flux numériques la **sève** qui les relie.
+
+Le **Modèle à 8 couches** est la charpente de cet organisme. Chaque couche agit comme un **organe** au service du tout : elle vit, communique, et s’autorégule grâce à des mécanismes de rétro‑action, homéostasie, régénération.  
+Le but de ce document est de formuler **une grammaire vivante du numérique fédératif**, où chaque composant peut se comprendre et se reconstruire à partir de son **ADN**.
+
+---
+
+## 2. 🧬 Anatomie des 8 couches
+
+Chaque couche est un **organe spécialisé** doté de **membranes de communication adjacentes** et de processus propres de régénération.
+
+| Couche | Organe vivant analogue       | Rôle vital                                                                  | Interfaces adjacentes | Responsable          |
+|:------:|:-----------------------------|:----------------------------------------------------------------------------|:----------------------|:---------------------|
+|   **C1**   | Racines physiques            | Ancrage matériel : énergie, climat, serveurs, sécurité physique             | C2                    | Fédération           |
+|   **C2**   | Système vasculaire           | Circulation : réseau, DNS autoritatif, PKI de transport, liens inter‑DC     | C1 ↔ C3               | Fédération           |
+|   **C3**   | Système nerveux central      | Gouvernance, supervision, identité fédérée, audit, rétro‑action             | C2 ↔ C4               | Fédération           |
+|   **C4**   | Métabolisme commun           | **Forge mutualisée** : artefacts, registres, pipelines, signatures, SBOM        | C3 ↔ C5               | Fédération           |
+|   **C5**   | Membrane d’échange           | **Pivot** : interface vivante entre fédération et tenants ; régulation des flux | C4 ↔ C6               | Fédération / Tenants |
+|   **C6**   | Tissu fonctionnel            | Services applicatifs génériques du tenant ; organes métier                  | C5 ↔ C7               | Tenants              |
+|   **C7**   | Organes sensoriels & moteurs | Expériences utilisateurs, fronts, produits assemblés                        | C6 ↔ C8               | Tenants              |
+|   **C8**   | Conscience cognitive         | Analyse, IA, décision ; mémoire et apprentissage                            | C7                    | Tenants              |
+
+### 2.1. Dynamique de régénération
+
+Chaque organe contient sa **matrice d’auto‑reconstruction** (ADN numérique) : **descripteur YAML**, **pipeline IaC**, **artefacts signés** hébergés en **C4**. En cas de défaillance, une couche peut se recréer à l’identique à partir du socle commun.
+
+### 2.2. Schéma des interactions adjacentes
+
+```
+C1 ⇄ C2 ⇄ C3 ⇄ C4 ⇄ C5 ⇄ C6 ⇄ C7 ⇄ C8
+```
+
+Toute communication **non adjacente** est une **anomalie systémique** ; elle est redirigée vers le **pivot (C5)** ou la **gouvernance (C3)**.
+
+### 2.3. Homologie écosystémique
+
+- **C1–C4** : sol et racines de la forêt numérique (**fédération**).
+- **C5** : écorce **perméable** qui filtre et protège.
+- **C6–C8** : canopée (**tenants**).
+
+---
+
+## 3. 🌊 Flux vitaux
+
+Chaque donnée, signal, artefact circule comme un **nutriment** dans un réseau vasculaire ordonné — sans jamais sauter une membrane.
+
+### 3.1 Flux descendants (énergie → forme)
+
+| Origine | Destination                                 | Nature du flux                                 | Fonction   |
+|---------|---------------------------------------------|------------------------------------------------|------------|
+| C1 → C2 | Énergie, réseau, synchronisation            | Sève de base (connectivité, sécurité)          | Fondation  |
+| C2 → C3 | Télémetrie brute, topologie réseau          | Informe le système nerveux des états physiques | Perception |
+| C3 → C4 | Politiques, référentiels, clés de confiance | Régule le métabolisme commun                   | Régulation |
+| C4 → C5 | Artefacts, registres, images, secrets       | Fournit les nutriments applicatifs             | Nutrition  |
+| C5 → C6 | Templates, déploiements, configurations     | Nourrit les tissus fonctionnels                | Croissance |
+| C6 → C7 | Services, APIs, sorties métier              | Expression externe                             | Mouvement  |
+| C7 → C8 | Données d’usage, signaux                    | Alimente la conscience cognitive               | Conscience |
+
+### 3.2 Flux ascendants (perception → régulation)
+
+| Origine | Destination                            | Nature du flux                          | Fonction      |
+|---------|----------------------------------------|-----------------------------------------|---------------|
+| C8 → C7 | Décisions, analyses, apprentissage     | Ajuste l’expérience utilisateur         | Réponse       |
+| C7 → C6 | Retours d’usage, métriques             | Améliore les services                   | Ajustement    |
+| C6 → C5 | Logs, états, besoins                   | Informe le pivot pour adaptation        | Médiation     |
+| C5 → C4 | Feedback de déploiement, traces        | Améliore les artefacts                  | Métabolisme   |
+| C4 → C3 | Preuves de conformité, journaux signés | Alimente la supervision et la confiance | Immunité      |
+| C3 → C2 | Politiques réseau, alertes             | Régule le flux sanguin du système       | Vasomotricité |
+| C2 → C1 | Signaux de charge, besoins             | Ferme la boucle homéostatique           | Résilience    |
+
+---
+
+## 4. 🩺 Homéostasie & régénération
+
+### 4.1 Mécanismes homéostatiques
+
+- **Auto‑détection** : chaque couche observe ses paramètres vitaux (latence, charge, erreurs).
+- **Rétro‑action** : C3 reçoit, ajuste ; C5 applique.
+- **Seuils adaptatifs** : alarmes contextuelles (comme le stress cellulaire).
+- **Apprentissage** : C8 réinjecte ses leçons sous forme de politiques (boucle C8→C3).
+
+### 4.2 Régénération autopoïétique
+
+- **ADN** : YAML, chartes, manifests, signatures (**C4**).
+- **ARN** : pipelines et jobs de déploiement (**C5**).
+- **Protéines** : services opérationnels (**C6–C8**).  
+  La mort d’une “cellule” déclenche **lecture de l’ADN** et **re‑synthèse** automatique.
+
+---
+
+## 5. 🪶 Symbiose fédéré‑tenant
+
+La relation n’est pas hiérarchique mais **écologique**.
+
+| Élément            | Métaphore            | Rôle symbiotique                                               |
+|--------------------|----------------------|----------------------------------------------------------------|
+| Fédération (C1–C4) | Sol, racines, climat | Stabilité, énergie, conditions de vie                          |
+| Pivot (C5)         | Écorce perméable     | Régule les échanges, protège des excès                         |
+| Tenants (C6–C8)    | Espèces hôtes        | Transforment l’énergie en intelligence, produits, connaissance |
+| Gouvernance (C3)   | Système immunitaire  | Détecte anomalies, maintient l’équilibre                       |
+
+### 5.1 Portabilité naturelle
+
+Les tenants sont portables comme des **graines** : leur **ADN (YAML + artefacts signés + politiques)** permet la migration vers toute fédération conforme, via **C5** et **C4** — **sans lock‑in**.
+
+---
+
+## 6. 🍃 Cycle de vie
+
+1. **Germination** : initialisation à partir de modèles (ADN).
+2. **Croissance** : intégration des flux descendants.
+3. **Maturité** : équilibre des flux.
+4. **Mutation** : adaptation (upgrade/fork).
+5. **Dissémination** : partage d’artefacts, pollinisation cognitive.
+6. **Décroissance contrôlée** : décommissionnement et recyclage.
+
+> Rien ne meurt vraiment : tout se recompose.
+
+---
+
+## 7. ⚖️ Bio‑éthique et équilibre
+
+- **Sobriété** : chaque flux doit avoir un sens.
+- **Justice** : la fédération nourrit, elle ne domine pas.
+- **Transparence** : toute interaction laisse une trace vérifiable.
+- **Empathie systémique** : chaque organe protège les autres.
+
+---
+
+## 8. 🧭 Annexes vivantes (ADN du système)
+
+- **Descripteur YAML de couche** (identités, flux, politiques, secrets référencés).
+- **IaC & pipelines reproductibles** (Terraform/Ansible/CI).
+- **Interopérabilité** : standards ouverts (export, audit).
+- **Identité & DNS fédérés** (SSO, délégation).
+- **Observabilité exportable** : vision locale et globale.
+
+---
+
+## 9. 🧾 Traçabilité & Compatibilité
+
+- **Origine structurante** : dérivé du **Modèle à 8 couches – réordonné (25‑10‑2025)** : C3=gouvernance/supervision, C4=forge/mutualisation, C5=pivot, C6–C8=tenants.
+- **Règle d’interface** : **communication adjacente uniquement** (pas de flux non adjacents).
+- **Séparation** : **fédération (C1–C4)** / **tenants (C6–C8)** avec **C5** comme membrane.
+- **Portabilité** : tout tenant = paquet **TTTII.yaml + artefacts signés + politiques**.
+
+---
+
+##   
+10. 🛠️ Résumé d’usage opérationnel (1 page)
+
+**Pour qui ?** Architectes, SRE/DevOps, Sécurité, Data/IA, Produits.
+
+**Comment lire le modèle :**
+
+1. Identifier la **couche d’appartenance** du service.
+2. Vérifier ses **interfaces adjacentes** (amont/aval).
+3. S’assurer que les **artefacts** résident en **C4**, que les **actions** passent par **C5**, que les **politiques** et **preuves** remontent en **C3**.
+
+**À faire dans les pipelines :**
+
+- **Supply chain** : build/sign (C4) → approve (C3) → deploy (C5) → run (C6–C7) → observe (C5→C3).
+- **Secrets** : stocker en **C4 (Vault)**, exposer via **C5**, gouverner en **C3**.
+- **DNS** : résolveur **C5** (forward) → autoritatif **C2** ; pas d’accès direct tenant→C2.
+- **Observabilité** : collecter **C5**, agréger **C3**, exporter (audits).
+
+**Invariants (ne jamais briser) :**
+
+- **Adjacency‑only.**
+- **Séparation fédération/tenants**, **portabilité** garantie.
+- **Traçabilité** partout (preuves signées, ΔLog).
+
+---
+
+> **Ce modèle n’est plus seulement une architecture.**  
+> C’est une **écologie cognitive** : un système capable de s’auto‑organiser, d’apprendre et de se renouveler sans perdre son identité.
\ No newline at end of file
diff --git a/docs/10-architecture/10 - Nomenclature mnémotechnique.md b/docs/10-architecture/10 - Nomenclature mnémotechnique.md
new file mode 100644
index 0000000..a7adb10
--- /dev/null
+++ b/docs/10-architecture/10 - Nomenclature mnémotechnique.md	
@@ -0,0 +1,242 @@
+# 🌲 Nomenclature Boréale v3 — Bio-Mimétiste & Autopoïétique
+
+**Version :** 3.0
+**Date :** 25 octobre 2025
+**Statut :** Référence vivante (SSOT)
+**Objet :** Établir la nomenclature organique des identifiants, adresses et noms au sein de l’écosystème boréal, selon le modèle à 8 couches bio-mimétiste et autopoïétique.
+**Compatibilité :** Conforme au réalignement CRB-1 ; C3 = gouvernance/supervision ; C4 = forge/mutualisation ; C5 = pivot ; C6–C8 = tenants.
+
+---
+
+## 🌱 Préambule — Avis de Réalignement CRB-1
+
+> **AB-Avis de Réalignement 25-10-2025 / Cycle de Réalignement Boréal #1**
+> Adoption du modèle biomimétique & autopoïétique comme racine unique de la nomenclature.
+> Intégration du principe **adjacent-only**, de la séparation **fédéré / tenant**, et de la portabilité intégrale des tenants.
+> Ce document remplace la version 2 et devient la **référence vivante** pour tous les artefacts, registres et pipelines.
+
+---
+
+## 🧬 1. Règle d’appartenance et portabilité
+
+### 1.1 Règle par couche
+
+* **C1–C4 = Fédération :** les racines et le métabolisme commun (datacenters, réseau, forge, artefacts).
+* **C5 = Pivot :** la membrane d’échange, régulatrice des flux entre fédéré et tenant.
+* **C6–C8 = Tenants :** la canopée cognitive, où se déploient les services, produits et connaissances.
+
+### 1.2 Principe de portabilité
+
+Tout tenant (C6-C8) doit pouvoir migrer sans perte vers un autre membre fédéré.
+Garanties minimales :
+
+1. **Descripteur YAML** complet (identités TTTII, DNS, inventaire, secrets référencés).
+2. **Interopérabilité ouverte :** formats standard, exports intégraux testables.
+3. **IaC & pipelines reproductibles :** Terraform/Ansible/CI signés.
+4. **Identité & DNS fédérés :** SSO OpenID/SAML, délégation documentée.
+5. **Observabilité scindée :** métriques infra chez le fédéré, applicatives chez le tenant, exportables.
+
+---
+
+## 🌳 2. Architecture vivante de référence
+
+La nomenclature n’est pas un tableau : c’est un **organisme de cohérence**.
+Les VMIDs, IPs et noms DNS forment la sève qui relie chaque organe du système.
+
+### 2.1 Topologie organique de la fédération
+
+```
+      [ C8  Conscience ]
+             ▲
+      [ C7  Produits / Expériences ]
+             ▲
+      [ C6  Services Tenant ]
+             ▲
+      [ C5  Pivot / Membrane ]
+             ▲
+      [ C4  Forge / Métabolisme commun ]
+             ▲
+      [ C3  Gouvernance / Supervision ]
+             ▲
+      [ C2  Réseau / DNS / PKI ]
+             ▲
+      [ C1  Physique / Énergie / Sécurité ]
+```
+
+Chaque flèche représente une interface **adjacente et perméable** ; aucun flux ne traverse plusieurs couches directement.
+
+---
+
+## ⚙️ 3. Langage des identifiants et des services
+
+La nomenclature décrit comment chaque élément s’inscrit dans le corps boréal.
+
+### 3.1 Structure VMID (organes numériques)
+
+**Format :**
+
+```
+0CTTII   →  Infrastructure fédérée (Couches 1–4)
+TTTII    →  Tenants (Couches 6–8)
+```
+
+* `C` = Couche (1–4)
+* `TT` = Type de service (00-99)
+* `II` = Instance (01-99)
+* `TTT` = Tenant ID (001-999)
+
+**Plages principales :**
+
+```
+01000-01999 → C1 Physique  
+02000-02999 → C2 Réseau  
+03000-03999 → C3 Gouvernance / Supervision  
+04000-04999 → C4 Forge / Mutualisation  
+05000-05999 → C5 Pivot / Médiation  
+10000-99999 → C6-C8 Tenants
+```
+
+**Exemples :**
+
+```
+03010 → C3 : Keycloak (IdP)  
+04021 → C4 : Forgejo Git  
+05011 → C5 : FastAPI Admin / Portail  
+10011 → C6 : Backend tenant 001  
+10021 → C6 : DB tenant 001
+```
+
+---
+
+## 🌐 4. Plan d’Adressage et Réseau
+
+### 4.1 Invariants
+
+* Tous les flux passent par leurs **couches adjacentes**.
+* Les tenants ne parlent jamais directement au DNS fédéré (C2) : ils utilisent le résolveur du pivot (C5).
+* Les services fédérés partagent un espace d’adressage cohérent (10.0.0.0/8).
+
+### 4.2 Répartition logique des espaces
+
+```
+10.0.0.0/24     → Management (C1)
+10.0.1.0/24     → Forge & Mutualisation (C4)
+10.0.2.0/24     → Réseau & DNS (C2)
+10.0.3.0/24     → Gouvernance & Supervision (C3)
+10.0.4.0/24     → Pivot Opérationnel (C5)
+10.0.10.0/23    → Tenants (C6-C8)
+172.16.0.0/12   → Espace fédératif inter-membres
+```
+
+### 4.3 Flux autorisés (adjacent-only)
+
+| Source | Destination | Sens | Description                  |
+| ------ | ----------- | ---- | ---------------------------- |
+| C1     | C2          | ↓    | Transport et synchronisation |
+| C2     | C3          | ↓    | Télémetrie et topologie      |
+| C3     | C4          | ↓    | Politiques et clés           |
+| C4     | C5          | ↓    | Artefacts et secrets         |
+| C5     | C6          | ↓    | Déploiements et templates    |
+| C6     | C7          | ↓    | Services métiers             |
+| C7     | C8          | ↓    | Données d’usage              |
+| C8     | C7          | ↑    | Décisions et analyses        |
+| C7     | C6          | ↑    | Retours et métriques         |
+| C6     | C5          | ↑    | Logs et besoins              |
+| C5     | C4          | ↑    | Feedbacks                    |
+| C4     | C3          | ↑    | Preuves et conformité        |
+| C3     | C2          | ↑    | Alertes et politiques réseau |
+| C2     | C1          | ↑    | Charge et besoins physiques  |
+
+---
+
+## 🧩 5. Noms de Machines et DNS
+
+### 5.1 Forme générale
+
+```
+<service>.<contexte>.<membre>.alliance-boreale.ca
+```
+
+* `<contexte>` = infra | pivot | t<tenant-id>
+* `<membre>`  = ID court (czp, nul, tli…)
+* Les tenants utilisent le préfixe `tXXX`.
+
+**Exemples :**
+
+```
+dns-master.infra.czp.alliance-boreale.ca   → 10.0.2.10
+keycloak.gov.czp.alliance-boreale.ca       → 10.0.3.20
+forgejo.forge.czp.alliance-boreale.ca      → 10.0.1.20
+fastapi.pivot.czp.alliance-boreale.ca      → 10.0.4.10
+web.t001.czp.alliance-boreale.ca           → 10.0.10.1
+db.t001.czp.alliance-boreale.ca            → 10.0.10.2
+```
+
+---
+
+## 🪶 6. Procédures d’Ensemencement
+
+Créer ou migrer une entité dans l’écosystème boréal revient à greffer une cellule dans un organisme.
+
+### 6.1 Création d’un service fédéré (C1–C5)
+
+1. **Choisir la couche et le type de service.**
+2. **Attribuer le VMID** selon la plage.
+3. **Déterminer l’adresse IP** à partir du plan.
+4. **Nommer la VM** suivant la syntaxe :
+
+   ```
+   <membre>-infra-<type>-prod-<instance>
+   ```
+5. **Créer l’entrée DNS**.
+6. **Documenter** dans l’inventaire Ansible et le registre.
+
+### 6.2 Création d’un tenant (C6–C8)
+
+1. **Allouer un Tenant ID (tXXX)**.
+2. **Définir le descripteur YAML** (TTTII, DNS, inventaire, secrets référencés).
+3. **Générer le paquet portatif** : YAML + artefacts signés.
+4. **Déployer via le pivot (C5)** ; aucun accès direct C4/C3.
+5. **Vérifier la traçabilité** (ΔLog & preuves signées).
+
+---
+
+## 🌐 7. Tables de Correspondance (Extrait)
+
+| VMID  | Couche | Nom VM                          | IP        | DNS                        | Fonction                   |
+| ----- | :----: | ------------------------------- | --------- | -------------------------- | -------------------------- |
+| 02001 |   C2   | czp-infra-dns-master-prod-01    | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS maître                 |
+| 03010 |   C3   | czp-infra-idp-keycloak-prod-01  | 10.0.3.20 | keycloak.gov.czp.ab.ca     | Identité fédérée           |
+| 04021 |   C4   | czp-infra-forgejo-git-prod-01   | 10.0.1.20 | forgejo.forge.czp.ab.ca    | Forge mutualisée           |
+| 05011 |   C5   | czp-infra-fastapi-pivot-prod-01 | 10.0.4.10 | fastapi.pivot.czp.ab.ca    | Portail & API              |
+| 10011 |   C6   | czp-t001-backend-prod-01        | 10.0.10.3 | api.t001.czp.ab.ca         | Backend tenant 001         |
+| 10021 |   C6   | czp-t001-db-postgres-prod-01    | 10.0.10.4 | db.t001.czp.ab.ca          | Base de données tenant 001 |
+
+---
+
+## 📜 8. ΔLog — Itération CRB-1 (25-10-2025)
+
+* **Refonte totale** de la nomenclature v2 → v3.
+* Adoption du modèle biomimétique/autopoïétique.
+* Ajout du principe **adjacent-only**.
+* Reclassement des services :
+
+  * Ansible → C3, Forgejo → C4, FastAPI → C5.
+* Ajout de la métaphore organique (flux ascendants/descendants).
+* Simplification du plan d’adressage.
+* Nouvelles tables de correspondance.
+* Introduction de la notion d’**ensemencement** (plutôt que création).
+
+---
+
+## 🌌 9. Signature Boréale
+
+> *Sous la voûte numérique, chaque bit est une graine.*
+> *Chaque grappe de VM est un organe, chaque tenant une espèce.*
+> *La forêt se régénère, la fédération veille, la conscience apprend.*
+> *Ainsi pousse l’Alliance Boréale, autopoïétique et libre.*
+
+---
+
+**Fin du document — Référence vivante v3 (2025-10-25)**
+📁 ce fichier sert de base à la Nomenclature, aux pipelines et au Label de Prestige.
diff --git a/docs/10-architecture/10 - Stack opérateur de référence (C1-C5).md b/docs/10-architecture/10 - Stack opérateur de référence (C1-C5).md
new file mode 100644
index 0000000..74c14d5
--- /dev/null
+++ b/docs/10-architecture/10 - Stack opérateur de référence (C1-C5).md	
@@ -0,0 +1,151 @@
+# ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5)
+
+**Version :** 1.1  
+**Date :** 26 janvier 2026  
+**Statut :** Adopté (référence vivante)  
+**Portée :** Opérateurs (C1–C5), Gouvernance, Audit interne/externe
+
+---
+
+## 1. Contexte
+
+L’Alliance Boréale requiert une pile logicielle “Opérateur” stable, reproductible et audit-ready pour opérer les couches **C1 à C5** :
+
+- **C1** : capacité (compute) et stockage primaire
+- **C2** : segmentation, edge, DNS autoritatif, accès opérateurs
+- **C3** : identité et observabilité (SLA, métriques, logs)
+- **C4** : forge, traçabilité, CI, artefacts, secrets (plan de vérité)
+- **C5** : pivot/membrane (point d’entrée unique) et exécution contrôlée (plan d’exécution)
+
+Cette standardisation vise :
+- réduction de la variabilité inter-opérateurs,
+- amélioration de l’auditabilité (preuves uniformes),
+- simplification du déploiement et de l’exploitation,
+- cohérence stricte avec le principe de membrane (C5).
+
+---
+
+## 2. Décision
+
+La pile logicielle suivante est adoptée comme **Pile opérateur de référence** (C1–C5).
+
+### 2.1 Stack par couche (C1–C5)
+
+**C1 — Compute & Storage**
+- Proxmox VE
+- Ceph
+- TrueNAS
+
+**C2 — Segmentation, Edge, DNS autoritatif, Accès ops**
+- OPNsense
+- PowerDNS Authoritative
+- WireGuard
+
+**C3 — IAM & Observabilité**
+- Keycloak
+- OpenLDAP
+- Icinga2 + Icinga Web 2 + BPM
+- Prometheus + Alertmanager
+- Grafana
+- Loki
+
+**C4 — Forge, CI, Artefacts, Secrets (plan de vérité)**
+- Forgejo
+- Forgejo Actions (CI de validation)
+- Harbor
+- Vault
+- Référentiels IaC : OpenTofu (modules) + Ansible (playbooks/inventaires)
+
+**C5 — Pivot / membrane (plan d’exécution)**
+- NGINX + ModSecurity
+- FastAPI
+- Unbound
+- Exécution IaC : runner contrôlé (OpenTofu + Ansible)
+
+---
+
+## 3. Règles d’architecture associées
+
+### 3.1 Membrane (point d’entrée unique)
+
+- **NGINX + ModSecurity (C5)** constitue le **point d’entrée unique** pour les accès utilisateurs/tenants vers les services exposés (portails, APIs, consultation dashboards).
+- Les composants internes (C2–C4) ne sont pas exposés directement aux tenants.
+
+### 3.2 Cloisonnement “adjacent-only” (principe opérateur)
+
+- Le cloisonnement réseau impose une logique “default deny” et une segmentation par couches.
+- Tout contournement de C5 (bypass) est considéré comme une non-conformité sauf exception formalisée.
+
+### 3.3 Traçabilité (PR + ΔLog)
+
+- Toute modification (config, infra, politiques, runbooks) est versionnée dans Forgejo via PR.
+- Chaque PR doit être reliée à une entrée ΔLog (trace de décision et de preuve).
+
+### 3.4 Séparation IaC : référentiel vs exécution (invariant)
+
+Cette séparation est un invariant (sécurité + gouvernance), pas une convention de mots :
+
+- **C4 (plan de vérité)** : contient et gouverne le **code IaC** (OpenTofu/Ansible), la validation CI (format/lint/tests/plan), et la traçabilité (PR/ΔLog).
+- **C5 (plan d’exécution)** : exécute les actions à privilèges (ex. `tofu apply`, `ansible-playbook`) via un **runner contrôlé**, afin de :
+  - concentrer les privilèges au niveau de la membrane,
+  - imposer des contrôles uniformes (RBAC, quotas, journalisation),
+  - empêcher qu’une compromission de la forge/CI se transforme automatiquement en compromission infra.
+
+> Note : le runner d’exécution peut être techniquement un “Forgejo Actions runner”, mais son **positionnement réseau et ses droits** le rattachent à C5 (membrane).
+
+---
+
+## 4. Conséquences
+
+### 4.1 Bénéfices
+
+- Standardisation : onboarding opérateur accéléré.
+- Auditabilité : preuves minimales uniformes (BPM, Grafana, Loki, exports OPNsense).
+- Réduction de la surface d’attaque : exécution IaC contrôlée et centralisée en C5.
+- Exploitabilité : séparation claire entre observabilité (C3) et exposition (C5).
+
+### 4.2 Obligations
+
+- Discipline de changements : PR + ΔLog obligatoires.
+- Preuves : collecte structurée et indexée selon la politique `POL-OPS-STACK-001`.
+- Maintien : versions supportées, runbooks, et exécutions IaC traçables.
+
+---
+
+## 5. Critères d’acceptation
+
+La pile est considérée **en place** pour un opérateur lorsque :
+
+1) Tous les composants (C1–C5) sont déployés et accessibles conformément au principe de membrane.  
+2) Le cloisonnement réseau est démontré (OPNsense + tests de non-bypass).  
+3) SSO (Keycloak) protège les portails (Grafana, Icinga Web) via C5.  
+4) Les preuves minimales `POL-OPS-STACK-001` existent, datées et indexées.  
+5) Les changements IaC sont gouvernés en C4, et exécutés via C5 avec traçabilité complète.
+
+---
+
+## 6. Gouvernance des changements
+
+Toute modification à la pile opérateur de référence exige :
+
+- PR + ΔLog,
+- mise à jour des runbooks et des preuves attendues,
+- ADR additionnel si changement de composant ou de rôle.
+
+---
+
+## 7. Références internes
+
+- POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5) — preuves attendues
+- ADR-OBS-001 — Loki comme backend de logs de référence
+- POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki
+
+---
+
+## 8. ΔLog (à compléter au commit)
+
+- Décision : Adoption de la pile opérateur de référence (C1–C5)  
+- Auteur(s) : __________________  
+- Référence PR : __________________  
+- Date d’entrée : __________________
+
diff --git a/docs/architecture/14_Structure_YAML_Registraire.md b/docs/10-architecture/10 - Structure YAML du registraire.md
similarity index 100%
rename from docs/architecture/14_Structure_YAML_Registraire.md
rename to docs/10-architecture/10 - Structure YAML du registraire.md
diff --git a/docs/10-architecture/2026-01-29 - Cache OVH - NGINX.md b/docs/10-architecture/2026-01-29 - Cache OVH - NGINX.md
new file mode 100644
index 0000000..9e2484d
--- /dev/null
+++ b/docs/10-architecture/2026-01-29 - Cache OVH - NGINX.md	
@@ -0,0 +1,100 @@
+Le truc, c’est de viser ce qui **répète** (assets), ce qui **burst** (pics), et ce qui **sature** (gros transferts).
+
+## 1) Odoo “sites web” : là où tu peux gagner gros
+
+Odoo sert beaucoup de contenu *identique* (assets, images, pièces jointes). Ça se cache très bien **au VPS**.
+
+### À faire au VPS (reverse-proxy cache)
+
+- **Cache long** pour les assets versionnés :
+  - `/web/assets/*`
+  - fichiers statiques thème/website
+- **Cache prudent** pour les médias/attachments :
+  - `/web/content/*` (souvent images/documents publics)
+- **Micro-cache** (1–5 s) pour les pages publiques *anonymes* (anti-burst) : énorme ROI quand tu as des pics.
+
+Même 5 secondes de micro-cache peut diviser tes hits backend par 10 sur un pic.
+
+### Réduire le poids
+
+- Activer **gzip/brotli** (au VPS) pour HTML/CSS/JS/JSON.
+- Forcer des images plus petites (WebP si ton pipeline le permet).
+- Vérifier que tes pages publiques ne tirent pas des méga-images “full-res”.
+
+## 2) Nextcloud : gains réels, mais plus limités
+
+Nextcloud est majoritairement **auth + personnalisé + WebDAV** ⇒ cache “full” non. Par contre :
+
+### Ce que tu peux cacher sans risque (au VPS)
+
+- **Assets statiques** Nextcloud (JS/CSS/fonts/images) : `/core/`, `/apps/`, `/dist/`, `/themes/` (selon ton layout).
+- Résultat : moins d’aller-retour maison pour le “bruit” de l’UI, surtout quand plusieurs utilisateurs se connectent.
+
+### Ce que tu optimises surtout autrement (pas via cache)
+
+- **Limiter la concurrence** et **plafonner le bulk** :
+  - limiter le nombre de téléchargements simultanés
+  - plafonner le débit par connexion (ou par IP)
+- **Contrôler les partages publics** (si c’est ça qui mange ton upload) :
+  - expiration des liens publics
+  - limiter taille max / quotas
+  - éviter “gros dépôt public” tant que tu es à 50 Mb/s
+
+## 3) Le trio gagnant pour ton 50 Mb/s
+
+1. **QoS/shaper à la maison** (cap à \~45 Mb/s + fq_codel/cake) → stabilité immédiate.
+2. **Edge cache au VPS** pour Odoo + assets Nextcloud → réduction du trafic répétitif.
+3. **Rate-limit / limites de transferts** (au VPS et/ou à la maison) → un client ne te tue pas.
+
+## 4) Exemple concret (Nginx cache au VPS) – simple et safe
+
+Tu peux garder HAProxy pour le routage, et mettre Nginx devant pour le cache (ou l’inverse). Exemple Nginx “edge cache” :
+
+```nginx
+proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=EDGE:200m max_size=30g inactive=7d use_temp_path=off;
+
+map $http_cookie $has_cookie { default 1; "" 0; }
+map $http_authorization $has_auth { default 1; "" 0; }
+
+# Odoo - assets cacheables
+location ^~ /web/assets/ {
+  proxy_pass http://odoo_home;
+  proxy_cache EDGE;
+  proxy_cache_valid 200 7d;
+  add_header X-Cache $upstream_cache_status always;
+}
+
+# Odoo - médias (à valider selon ton usage)
+location ^~ /web/content/ {
+  proxy_pass http://odoo_home;
+  proxy_cache EDGE;
+  proxy_cache_valid 200 1d;
+  add_header X-Cache $upstream_cache_status always;
+}
+
+# Odoo - microcache pages publiques (GET sans cookies/auth)
+location / {
+  proxy_pass http://odoo_home;
+  if ($request_method != GET) { set $skip 1; }
+  if ($has_cookie = 1) { set $skip 1; }
+  if ($has_auth = 1)   { set $skip 1; }
+
+  proxy_cache EDGE;
+  proxy_cache_bypass $skip;
+  proxy_no_cache     $skip;
+  proxy_cache_valid 200 2s;
+  proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
+  add_header X-Cache $upstream_cache_status always;
+}
+```
+
+Même si tu n’actives que **/web/assets/** + micro-cache 2s sur pages publiques, tu vas le sentir.
+
+## 5) La question qui détermine la meilleure optimisation (1 seule)
+
+Ton upload est surtout mangé par :
+
+- **visiteurs des sites Odoo** (trafic web public), ou
+- **transferts de fichiers Nextcloud** (downloads/shares/sync) ?
+
+Dis-moi “Odoo” ou “Nextcloud”, et je te donne le réglage prioritaire (cache/micro-cache vs plafonds/rate-limit) avec des valeurs concrètes adaptées à ton 50 Mb/s.
\ No newline at end of file
diff --git a/docs/architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md b/docs/10-architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md
similarity index 100%
rename from docs/architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md
rename to docs/10-architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md
diff --git a/docs/architecture/Architecture_Deterministe_Diagrammes_Visuels.md b/docs/10-architecture/Architecture_Deterministe_Diagrammes_Visuels.md
similarity index 100%
rename from docs/architecture/Architecture_Deterministe_Diagrammes_Visuels.md
rename to docs/10-architecture/Architecture_Deterministe_Diagrammes_Visuels.md
diff --git a/docs/architecture/Forgejo_dans_le_cycle_vivant.md b/docs/10-architecture/Forgejo_dans_le_cycle_vivant.md
similarity index 100%
rename from docs/architecture/Forgejo_dans_le_cycle_vivant.md
rename to docs/10-architecture/Forgejo_dans_le_cycle_vivant.md
diff --git a/docs/architecture/checklist_reunion.md b/docs/10-architecture/checklist_reunion.md
similarity index 100%
rename from docs/architecture/checklist_reunion.md
rename to docs/10-architecture/checklist_reunion.md
diff --git a/docs/architecture/guide_formation.md b/docs/10-architecture/guide_formation.md
similarity index 100%
rename from docs/architecture/guide_formation.md
rename to docs/10-architecture/guide_formation.md
diff --git a/docs/architecture/readme_package.md b/docs/10-architecture/readme_package.md
similarity index 100%
rename from docs/architecture/readme_package.md
rename to docs/10-architecture/readme_package.md
diff --git a/docs/architecture/resolution_adoption.md b/docs/10-architecture/resolution_adoption.md
similarity index 100%
rename from docs/architecture/resolution_adoption.md
rename to docs/10-architecture/resolution_adoption.md
diff --git a/docs/architecture/scripts_migration.sh b/docs/10-architecture/scripts_migration.sh
similarity index 100%
rename from docs/architecture/scripts_migration.sh
rename to docs/10-architecture/scripts_migration.sh
diff --git a/docs/architecture/templates_automation.md b/docs/10-architecture/templates_automation.md
similarity index 100%
rename from docs/architecture/templates_automation.md
rename to docs/10-architecture/templates_automation.md
diff --git a/docs/10-instanciation/00-prerequis.md b/docs/10-instanciation/00-prerequis.md
deleted file mode 100644
index 06af748..0000000
--- a/docs/10-instanciation/00-prerequis.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Prerequis
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/01-architecture-generale.md b/docs/10-instanciation/01-architecture-generale.md
deleted file mode 100644
index 92edc42..0000000
--- a/docs/10-instanciation/01-architecture-generale.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Architecture Generale
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/02-guide-de-demarrage.md b/docs/10-instanciation/02-guide-de-demarrage.md
deleted file mode 100644
index 12f3f7e..0000000
--- a/docs/10-instanciation/02-guide-de-demarrage.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Guide De Demarrage
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/03-registre-yaml-exemple.md b/docs/10-instanciation/03-registre-yaml-exemple.md
deleted file mode 100644
index eb3a69c..0000000
--- a/docs/10-instanciation/03-registre-yaml-exemple.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Registre Yaml Exemple
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/04-deploiement-automatique.md b/docs/10-instanciation/04-deploiement-automatique.md
deleted file mode 100644
index 301b032..0000000
--- a/docs/10-instanciation/04-deploiement-automatique.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Deploiement Automatique
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/05-tests-et-validation.md b/docs/10-instanciation/05-tests-et-validation.md
deleted file mode 100644
index 6ff4e54..0000000
--- a/docs/10-instanciation/05-tests-et-validation.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Tests Et Validation
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/10-instanciation/06-maintenance-et-mise-a-jour.md b/docs/10-instanciation/06-maintenance-et-mise-a-jour.md
deleted file mode 100644
index d57e788..0000000
--- a/docs/10-instanciation/06-maintenance-et-mise-a-jour.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Maintenance Et Mise A Jour
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/00-roles-et-responsabilites.md b/docs/20-gouvernance/00-roles-et-responsabilites.md
deleted file mode 100644
index 64df70b..0000000
--- a/docs/20-gouvernance/00-roles-et-responsabilites.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Roles Et Responsabilites
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/01-processus-decisionnel.md b/docs/20-gouvernance/01-processus-decisionnel.md
deleted file mode 100644
index 16a64fa..0000000
--- a/docs/20-gouvernance/01-processus-decisionnel.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Processus Decisionnel
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/02-documents-de-reference.md b/docs/20-gouvernance/02-documents-de-reference.md
deleted file mode 100644
index 7e00f35..0000000
--- a/docs/20-gouvernance/02-documents-de-reference.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Documents De Reference
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/03-modele-juridique-et-structure-sep-obnl.md b/docs/20-gouvernance/03-modele-juridique-et-structure-sep-obnl.md
deleted file mode 100644
index 671045a..0000000
--- a/docs/20-gouvernance/03-modele-juridique-et-structure-sep-obnl.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Modele Juridique Et Structure Sep Obnl
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/04-adhesion-et-contribution.md b/docs/20-gouvernance/04-adhesion-et-contribution.md
deleted file mode 100644
index 8d66c2b..0000000
--- a/docs/20-gouvernance/04-adhesion-et-contribution.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Adhesion Et Contribution
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-gouvernance/05-ethique-et-confidentialite.md b/docs/20-gouvernance/05-ethique-et-confidentialite.md
deleted file mode 100644
index a53ea50..0000000
--- a/docs/20-gouvernance/05-ethique-et-confidentialite.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Ethique Et Confidentialite
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/20-rag/01 - Charte fondatrice.md b/docs/20-rag/01 - Charte fondatrice.md
new file mode 100644
index 0000000..f603c7f
--- /dev/null
+++ b/docs/20-rag/01 - Charte fondatrice.md	
@@ -0,0 +1,619 @@
+# Document 1 : Charte Fondatrice de L'Alliance Boréale
+
+## Constitution et Principes Fondamentaux
+
+###### 🔗 Cette documentation est régie par la Charte Cognitive
+
+######  Date: 22 octobre 2025 - Statut: Document fondateur - Auteurs: Membres fondateurs (Chezlepro, TechnoLibre) - Signataires: Daniel Allaire (président fondateur) - Licence: CC BY-SA 4.0
+
+## PRÉAMBULE — Vision Fondatrice
+
+### Le constat : un numérique en crise de sens
+
+> *"Seuls, nous sommes vulnérables. Ensemble, nous sommes une forêt."*
+> Nous sommes en 2025. Le numérique, cette promesse d'émancipation et de connexion, s'est transformé en vecteur de dépendance et de centralisation. Quelques acteurs mondiaux contrôlent nos données, nos infrastructures, nos choix technologiques. La surveillance est devenue la norme, la vie privée une exception. L'obsolescence programmée détruit nos ressources. La croissance pour la croissance consume notre planète.
+> **Les petits acteurs du numérique éthique — hébergeurs, coopératives, OBNL — se retrouvent isolés.** Chacun doit réinventer la roue, négocier seul avec les géants, justifier perpétuellement ses choix face à la facilité des solutions clé en main des GAFAM.
+
+### Notre réponse : tisser une forêt numérique vivante
+
+**L'Alliance Boréale naît de ce constat et de ce refus.**
+Refus de l'isolement. Refus de la dépendance. Refus de la croissance aveugle.
+**Nous choisissons la voie de la fédération libre :** des acteurs autonomes qui coopèrent selon des règles communes, sans sacrifier leur souveraineté. Nous tissons un réseau de confiance, basé sur des standards ouverts et une éthique partagée.
+**Nous ne sommes pas naïfs.** Nous savons que la technique seule ne résout rien. Une fédération sans éthique devient vite un empire déguisé. C'est pourquoi nous ancrons notre projet dans une vision philosophique claire, inspirée par ceux qui ont pensé la sobriété heureuse, les outils conviviaux, et la gestion des communs.
+
+### Pourquoi "Boréale" ?
+
+Le nom **Boréale** évoque la forêt boréale canadienne, cet écosystème résilient où les arbres partagent leurs nutriments via les réseaux de mycorhizes souterrains. Chaque arbre est autonome, mais tous bénéficient du réseau invisible qui relie leurs racines. Quand un arbre est en difficulté, les autres lui envoient des ressources. Quand un arbre meurt, ses nutriments nourrissent les jeunes pousses.
+**L'Alliance Boréale est ce réseau mycorhizien numérique :** elle facilite les échanges, partage les ressources, renforce la résilience. Mais elle ne possède rien, ne commande personne, n'impose rien.
+
+### La métaphore : la forêt, pas l'empire
+
+**Nous ne bâtissons pas un empire. Nous entretenons une forêt.**
+Un empire centralise, extrait, domine. Il croît vite et meurt brutalement. Il impose l'uniformité et étouffe la diversité.
+Une forêt s'enracine, s'entraide, se régénère. Elle croît lentement, mais dure des siècles. Elle prospère par la diversité de ses espèces. Chaque arbre garde son autonomie, tout en contribuant à la santé de l'ensemble.
+**Notre Alliance est un organisme numérique vivant** — capable de se maintenir et de se régénérer lui-même, au-delà de ses fondateurs.
+
+### Un projet pour les générations futures
+
+###### Cette Alliance ne se construit pas pour nous seuls. Nous la pensons comme un système **autopoïétique** — capable de se maintenir et de se régénérer lui-même, au-delà de ses fondateurs. Nous documentons pour transmettre. Nous formons pour perpétuer. Nous choisissons la sobriété pour durer. **Ce que nous léguons, c'est une méthode, une éthique, un réseau vivant.**
+
+## ARTICLE 1 — Nature et Identité de L'Alliance
+
+### 1.1 Définition juridique
+
+**L'Alliance Boréale** est une fédération libre d'acteurs du numérique éthique, constituée initialement sous forme d'association non incorporée, avec l'intention de se constituer en **organisme à but non lucratif (OBNL)** selon la Partie III de la Loi sur les compagnies du Québec d'ici **2026**.
+**Siège social :** Saint-Bruno-de-Montarville, Québec, Canada
+**Juridiction :** Droit québécois
+
+### 1.2 Nature de la fédération
+
+**Principe fondamental :** Chaque membre de L'Alliance conserve son **autonomie juridique, opérationnelle et stratégique** complète. L'Alliance ne détient aucune part, aucun contrôle, aucun pouvoir décisionnel sur les opérations internes de ses membres.
+
+
+**L'Alliance est :**
+
+- Un **facilitateur** de coopération technique
+- Un **garant** de conformité éthique via un label de prestige
+- Un **fournisseur** d'outils et d'infrastructures mutualisés
+- Un **espace** de gouvernance collective sociocratique 
+
+**L'Alliance n'est PAS :**
+
+- Un franchiseur (pas de redevance sur les revenus)
+- Un contrôleur (pas d'audit financier des membres)
+- Un fournisseur exclusif (les membres restent libres de leurs choix)
+- Une autorité centrale (décisions par consentement, pas directive)
+
+### 1.3 Valeurs cardinales
+
+L'Alliance Boréale repose sur **cinq valeurs cardinales**, non négociables et indissociables :
+
+#### **1. Souveraineté**
+
+Chaque membre contrôle ses données, ses infrastructures, ses choix technologiques. La fédération renforce cette souveraineté, elle ne l'affaiblit pas.
+
+**Application concrète :**
+
+- Hébergement sur territoire contrôlé (Québec, Canada)
+- Pas de dépendance aux GAFAM pour les services critiques
+- Standards ouverts privilégiés aux solutions propriétaires
+
+#### **2. Liberté**
+
+Liberté de choix technologiques, dans le respect des standards d'interopérabilité. Liberté d'adhérer, de partir, de contribuer selon ses moyens.
+
+**Application concrète :**
+
+- Pas d'obligation d'utiliser les outils communs de L'Alliance
+- Pas de lock-in technique ou contractuel
+- Droit de retrait sans pénalité (délai de préavis raisonnable)
+
+#### **3. Sobriété**
+
+Refus de la croissance pour la croissance. Optimisation pour la durabilité, pas la performance maximale. Mesure et réduction de l'empreinte numérique.
+
+**Application concrète :**
+
+- Évaluation de la sobriété numérique dans le label (domaine 6)
+- Choix de solutions frugales quand elles répondent au besoin
+- Documentation de la consommation (énergie, ressources)
+
+#### **4. Solidarité**
+
+Entraide entre pairs. Support mutuel en cas de difficulté. Partage de connaissances et d'outils. Aucun membre ne doit être laissé seul face à une crise.
+**Application concrète :**
+
+- Banque de temps (valorisation équitable des contributions)
+- Support technique peer-to-peer
+- Partage des post-mortems d'incidents (apprentissage collectif)
+
+#### **5. Transparence (utile)**
+
+Publier ce qui renforce la confiance et permet l'audit. Protéger ce qui relève de l'intimité technique ou de la sécurité opérationnelle.
+**Application concrète :**
+
+- Registraire public (métadonnées des membres, décisions de gouvernance)
+- Scores de label publiés
+- Mais configurations de sécurité gardées privées
+
+### 1.4 Principes opérationnels
+
+###### **Principe de subsidiarité** Les décisions sont prises au niveau le plus proche de ceux qu'elles affectent. L'Alliance n'intervient que lorsque les membres individuels ne peuvent résoudre un problème seuls. **Légèreté bureaucratique** Gouvernance sociocratique efficace. Documentation minimale suffisante. Pas de règles pour le plaisir des règles. **Proportionnalité** Les exigences (techniques, financières, participatives) s'adaptent aux moyens de chaque membre. Pas de one-size-fits-all. **Amélioration continue** L'Alliance est un organisme vivant. Révision annuelle des documents constitutifs. Adaptation aux apprentissages et aux évolutions du contexte.
+
+## ARTICLE 2 — Mission et Objectifs
+
+### 2.1 Mission principale
+
+**Tisser une forêt numérique vivante où chaque organisation peut exercer sa souveraineté technologique, protéger ses données, et coopérer avec d'autres, dans le respect des valeurs humaines et écologiques.**
+
+### 2.2 Notre vision à 10 ans (2035)
+
+D'ici 2035, L'Alliance Boréale sera :
+
+- **Une fédération mature** de plusieurs dizaines de membres actifs
+- **Un réseau de confiance** protégeant les données de milliers d'utilisateurs
+- **Une infrastructure DNS fédérée** reliant tous les membres de manière résiliente
+- **Une référence** en matière de gouvernance sociocratique et de sobriété numérique
+- **Un modèle** inspirant d'autres fédérations au Québec, au Canada, et au-delà 
+- **Principe de croissance :** Organique, pas forcée. Nous préférons quelques dizaines de membres alignés et actifs à des centaines de membres fantômes. La qualité prime sur la quantité.
+
+### 2.3 Objectifs stratégiques
+
+#### **Objectif 1 : Faciliter l'interopérabilité technique**
+
+**Moyens :**
+
+- Fédération DNS (serveurs autoritaires en AXFR mutuel)
+- Identités fédérées (SSO via OpenID Connect / SAML)
+- Standards ouverts documentés (email, fichiers, visio, messagerie)
+- Tests d'interopérabilité entre membres **Résultat attendu :** Un utilisateur d'un membre A peut utiliser les services d'un membre B sans friction technique.
+
+#### **Objectif 2 : Établir un label de conformité et de prestige**
+
+**Moyens :**
+
+- Cadre de conformité sur 6 domaines (gouvernance, sécurité, vie privée, interop, opérations, sobriété)
+- Audits pair-à-pair (évaluation par les pairs, pas organisme externe)
+- Quatre niveaux de label (Bronze, Argent, Or, Platine)
+- Processus de labellisation transparent et documenté **Résultat attendu :** Le label "Boréal [Niveau]" devient une référence de qualité reconnue sur le marché du numérique éthique.
+
+#### **Objectif 3 : Mutualiser outils et infrastructures**
+
+**Moyens :**
+
+- Registraire public (YAML versionné Git)
+- Outils de communication (Matrix, forge logicielle)
+- Monitoring fédéré (métriques partagées Prometheus/Grafana)
+- Documentation collaborative (wiki)
+- Banque de temps (valorisation des contributions) **Résultat attendu :** Réduction des coûts et efforts individuels par la mise en commun des ressources.
+
+#### **Objectif 4 : Garantir une gouvernance durable et éthique**
+
+**Moyens :**
+
+- Gouvernance sociocratique (3 cercles : Stratégique, Opérationnel, Éthique)
+- Décisions par consentement (pas consensus ni vote majoritaire par défaut)
+- Transparence des décisions (toutes documentées au Registraire)
+- Constitution en OBNL (2026) pour pérennité juridique **Résultat attendu :** Une organisation résiliente, capable de se régénérer au-delà de ses fondateurs.
+
+### 2.4 Ce que L'Alliance ne fait PAS
+
+###### **L'Alliance ne vend pas de services aux utilisateurs finaux.** Elle ne concurrence pas ses membres. Elle facilite leur succès collectif. **L'Alliance ne certifie pas au sens normatif (ISO).** Elle labellise selon ses propres critères, adaptés aux réalités des petites structures éthiques. **L'Alliance ne gère pas d'adresses IP.** Elle n'est pas un registraire d'adresses. Chaque membre utilise ses propres IPs publiques. **L'Alliance ne finance pas ses membres.** Elle ne distribue pas de subventions. Elle mutualise des coûts, mais chaque membre reste responsable de sa soutenabilité financière.
+
+## ARTICLE 3 — Architecture Vivante à 8 Couches
+
+### 3.1 Le modèle autopoïétique
+
+Notre infrastructure est un **organisme numérique vivant**. Le terme **autopoïèse** (du grec "auto" = soi-même, "poiesis" = création) désigne la capacité d'un système à se maintenir et se régénérer lui-même.
+**L'Alliance Boréale n'est pas une machine statique — c'est un écosystème vivant** où l'information circule en boucles de rétroaction, où les décisions techniques influencent la philosophie, et où l'éthique guide les choix techniques.
+
+### 3.2 Les 8 couches de l'organisme
+
+**Couche 1 — Physique (Le sol)Couche 2 — Réseau (Le mycélium)Couche 3 — Virtualisation (Les racines système)Couche 4 — Orchestration (La sève)Couche 5 — Supervision (Les signaux)Couche 6 — Services (Les branches)Couche 7 — Gouvernance & données (Le cerveau collectif)Couche 8 — Philosophie/Éthique (La lumière)**
+
+*(Les contenus “Stockage” et “Applications” sont réintégrés : sauvegardes/stockage → Couches 1 & domaines d’infrastructure; interfaces/applications → Couches 6/7.)*
+
+### 3.3 Boucle de rétroaction — L'organisme respire
+
+**L'information circule dans les deux sens :⬆️ Remontée (des racines vers la lumière) :**
+
+- Les incidents techniques (couche 1-7) remontent jusqu'à la gouvernance (couche 8)
+- Les métriques de performance informent les décisions stratégiques
+- Les retours d'expérience nourrissent l'amélioration continue **⬇️ Descente (de la lumière vers les racines) :**
+- Les décisions éthiques (couche 8) influencent toutes les couches techniques
+- Les valeurs de sobriété guident le dimensionnement de l'infrastructure
+- La gouvernance sociocratique structure l'organisation technique **C'est cette circulation continue qui fait de L'Alliance un système vivant, capable d'apprendre et de s'adapter.**
+
+---
+
+## ARTICLE 4 — Territoire et Portée
+
+### 4.1 Ancrage géographique
+
+**L'Alliance Boréale se définit par son ancrage nordique :**
+
+- Principalement : Québec et Canada
+- Possiblement : autres régions nordiques (provinces maritimes, Territoires du Nord-Ouest, etc.) **L'ancrage géographique n'est pas exclusif,** mais il reflète une identité culturelle et une proximité facilitant les rencontres physiques et la compréhension mutuelle.
+
+### 4.2 Périmètre sectoriel
+
+**Acteurs éligibles :**
+
+- Hébergeurs web et fournisseurs d'infrastructure
+- Coopératives technologiques
+- OBNL du numérique éthique
+- Entreprises à mission sociale dans le numérique
+- Tout acteur aligné avec les 5 valeurs cardinales **Critères d'éligibilité (voir Règlement de Régie Interne pour détails) :**
+- Acteur du numérique éthique (pas de pure vente de matériel)
+- Alignement démontré avec les valeurs de la Charte
+- Capacité technique minimale (hébergement de services)
+- Volonté de participer activement à la gouvernance 
+
+**Exclusions :**
+
+- Acteurs dont le modèle d'affaires repose sur la vente de données personnelles
+- Acteurs financés principalement par des VC extractifs
+- Acteurs ne respectant pas les lois canadiennes et québécoises (Loi 25, etc.)
+
+---
+
+## ARTICLE 5 — Philosophie d'Intervention
+
+### 5.1 Principe de subsidiarité
+
+**Définition :** Les décisions doivent être prises au niveau le plus proche de ceux qu'elles affectent.
+**Application :**
+
+- Un membre gère son infrastructure de manière autonome
+- L'Alliance intervient pour l'interopérabilité (DNS, SSO, standards)
+- L'Alliance ne dicte pas les choix technologiques internes d'un membre
+
+### 5.2 Légèreté et facilitation
+
+**L'Alliance est un facilitateur, pas un contrôleur.**
+
+**Concrètement :**
+
+- Pas d'inspection surprise des serveurs
+- Pas d'audit financier des membres
+- Pas de reporting hebdomadaire obligatoire
+- Pas de bureaucratie pour le plaisir de la bureaucratie 
+
+**La documentation obligatoire se limite à :**
+
+- Décisions de gouvernance (cercles)
+- Incidents majeurs (P0/P1) affectant la fédération
+- Auto-évaluations pour le label (annuel)
+- Participation aux réunions de cercle (si membre d'un cercle)
+
+### 5.3 Intervention minimale de L'Alliance
+
+**L'Alliance n'intervient dans les affaires d'un membre que dans 3 cas 😀** 
+
+**Cas 1 : Non-conformité majeure menaçant l'Alliance**
+Exemple : Membre victime d'une faille de sécurité majeure, ne déclare pas l'incident, met en danger les autres membres de la fédération DNS.
+→ Intervention du Cercle Éthique & Conformité
+
+**Cas 2 : Demande explicite d'aide d'un membre**
+Exemple : Membre en difficulté technique demande support via Matrix #incidents.
+→ Solidarité peer-to-peer (pas intervention top-down)
+
+**Cas 3 : Arbitrage d'un conflit entre membres**
+Exemple : Désaccord sur l'usage d'une zone DNS déléguée.
+→ Médiation par le Cercle Éthique & Conformité
+
+**Dans tous les autres cas, l'Alliance reste en retrait.**
+
+### 5.4 Préservation de la souveraineté des membres
+
+**Chaque membre reste maître :**
+
+- De sa stratégie commerciale
+- De ses tarifs et modèle économique
+- De ses choix de partenaires
+- De sa communication publique
+- De son organisation interne 
+
+**L'Alliance ne peut pas :**
+
+- Imposer des tarifs uniformes
+- Interdire à un membre de travailler avec un acteur externe
+- Exiger l'exclusivité sur un service
+- Contrôler la communication d'un membre (sauf usage abusif du label)
+
+---
+
+## ARTICLE 6 — Membres Fondateurs et Gouvernance Initiale
+
+### 6.1 Membres fondateurs
+
+**Les membres fondateurs de L'Alliance Boréale sont :**
+
+1. **Chezlepro inc.**
+   - Représenté par : Daniel Allaire (président fondateur de L'Alliance)
+   - Siège social : Saint-Bruno-de-Montarville, Québec
+2. **TechnoLibre**
+   - Représenté par : Mathieu Benoît
+   - Siège social : [à compléter]
+
+**Rôle des fondateurs :**
+
+- Signature initiale de la Charte
+- Constitution du Cercle des Référents Boréaux (phase transitoire 2025-2026)
+- Mise en place de la gouvernance sociocratique (3 cercles)
+- Recrutement des membres
+
+### 6.2 Cercle des Référents Boréaux (phase transitoire)
+
+**Durée :** 2025-2026 (dissolution lors de la constitution en OBNL)
+**Composition :** Membres fondateurs + premiers membres admis (phase pilote)
+**Mandat :**
+
+- Rôle d'arbitrage final en cas de blocage dans un cercle
+- Validation des documents constitutifs (cette Charte, le Règlement, etc.)
+- Pilotage de la phase pilote
+- Préparation de la constitution en OBNL 
+
+**Mode de décision :** Consentement renforcé (exigence d'unanimité pour les décisions stratégiques majeures durant la phase pilote) 
+
+**Dissolution :** Automatique lors de la constitution en OBNL. Les pouvoirs sont transférés au conseil d'administration de l'OBNL.
+
+### 6.3 Gouvernance sociocratique
+
+**Voir le Règlement de Régie Interne (Document 2) pour les détails complets.Structure :**
+
+- **Cercle Stratégique** : Tous les membres actifs (vision, orientation, admissions)
+- **Cercle Opérationnel** : Membres techniques désignés (coordination technique, infrastructure)
+- **Cercle Éthique & Conformité** : Membres élus (label, audits, arbitrages, communication) **Mode de décision par défaut :** Consentement sociocratique (absence d'objection raisonnée) **Fallback :** Vote majoritaire si blocage ≥ 14 jours
+
+---
+
+## ARTICLE 7 — Admission et Retrait des Membres
+
+### 7.1 Admission
+
+**Processus détaillé dans le Règlement de Régie Interne (Document 2) et le Guide d'Onboarding (Document 8).Grandes étapes :**
+
+1. Lettre d'intention
+2. Parrainage par un membre existant (après phase fondatrice)
+3. Entretien avec le Cercle Stratégique
+4. Vote d'admission (unanimité en phase pilote, puis consentement)
+5. Période probatoire de 3 mois
+6. Statut de membre actif (si évaluation positive) **Critères d'admission :**
+
+- Alignement avec les 5 valeurs cardinales
+- Capacité technique minimale (hébergement de services)
+- Volonté de participer activement (gouvernance, outils communs)
+- Conformité légale (Loi 25, etc.)
+
+### 7.2 Retrait volontaire
+
+**Un membre peut quitter L'Alliance à tout moment**, moyennant :
+
+- Préavis de **30 jours**
+- Transition propre des services fédérés (DNS, SSO)
+- Restitution des accès aux outils communs
+- Arrêt immédiat de l'usage du label Boréal **Aucune pénalité financière.** Les cotisations déjà payées ne sont pas remboursables (prorata possible selon règlement interne).
+
+### 7.3 Suspension et radiation
+
+**Voir Règlement de Régie Interne (Document 2) pour les détails.Motifs de suspension temporaire :**
+
+- Non-conformité majeure non corrigée
+- Incident grave non déclaré
+- Non-paiement de cotisation (>60 jours) **Motifs de radiation (cas extrêmes) :**
+- Violation grave et répétée des valeurs de la Charte
+- Fraude ou usage abusif du label
+- Mise en danger délibérée de la fédération **Procédure :** Contradictoire, avec possibilité de défense. Décision par consentement renforcé du Cercle Éthique & Conformité.
+
+---
+
+## ARTICLE 8 — Financement et Soutenabilité
+
+### 8.1 Modèle financier
+
+**Voir le Document 13 (Modèle Financier et Soutenabilité) pour les détails complets.Principes directeurs :**
+
+- **Soutenabilité avant croissance** : L'Alliance vise l'équilibre budgétaire, pas le profit
+- **Transparence financière totale** : Bilans publiés trimestriellement au Registraire
+- **Diversification des sources** : Pas de dépendance à une source unique
+
+### 8.2 Sources de revenus
+
+**1. Cotisations des membres (source principale)**
+
+- Barème progressif selon taille/revenus : 
+  * Petite structure (<100k$ CA) : 500 $/an
+  * Moyenne structure (100-500k$) : 1 000 $/an
+  * Grande structure (>500k$) : 2 000 $/an
+- Révision annuelle possible (décision Cercle Stratégique) 
+
+**2. Subventions et financements publics (après constitution en OBNL)**
+
+- Programmes gouvernementaux (innovation, numérique responsable)
+- Sous condition d'alignement avec les valeurs (refus de financement extractif) 
+
+**3. Services facultatifs payants**
+
+- Formations et ateliers
+- Consulting en gouvernance coopérative
+- Audits de conformité pour non-membres
+- Réinvestissement total dans L'Alliance **4. Dons et mécénat éthique**
+- Acceptés si pas de conflit d'intérêts
+
+### 8.3 Utilisation des fonds
+
+**Dépenses autorisées :**
+
+- Infrastructure technique partagée (serveurs, DNS, monitoring)
+- Outils de communication (Matrix, forge, wiki)
+- Frais légaux et administratifs (constitution OBNL, comptabilité)
+- Coordination rémunérée (si soutenabilité atteinte, après 2026)
+- Événements et rayonnement (rencontres annuelles, conférences) 
+
+**Dépenses interdites :**
+
+- Dividendes ou distributions aux membres
+- Financement des opérations internes d'un membre
+- Investissements spéculatifs
+
+### 8.4 Réserve de prudence
+
+###### **Objectif :** Constituer une réserve équivalente à 6 mois de dépenses courantes. **Usage :** Uniquement en cas de crise (perte soudaine de membres, frais légaux imprévus).
+
+## ARTICLE 9 — Propriété Intellectuelle et Licences
+
+### 9.1 Principe général
+
+**Tout ce qui est créé par L'Alliance (documentation, outils, code) est publié sous licence libre.**
+
+**Licence par défaut :** CC BY-SA 4.0 (documentation) et GPL/AGPL (code logiciel)
+
+### 9.2 Contributions des membres
+
+**Les membres conservent la propriété de leurs contributions**, mais les mettent à disposition de L'Alliance et des autres membres selon les termes suivants :
+
+- Documentation technique : CC BY-SA 4.0
+- Code logiciel : GPL v3 ou AGPL v3 (selon pertinence)
+- Outils propriétaires : Peuvent être gardés privés, mais non partageables via L'Alliance
+
+### 9.3 Marques et logo
+
+**"L'Alliance Boréale" et le logo associé** sont des marques déposées appartenant à l'organisation (OBNL après constitution).
+  
+**Usage autorisé :**
+
+- Membres actifs (dans leur communication)
+- Usage du label "Boréal [Niveau]" (si attribué) 
+
+**Usage interdit :**
+
+- Ex-membres (après retrait ou radiation)
+- Non-membres (sauf autorisation écrite du Cercle Éthique)
+- Usage commercial trompeur
+
+---
+
+## ARTICLE 10 — Révision et Dissolution
+
+### 10.1 Révision de la Charte
+
+**Périodicité :** Revue annuelle obligatoire lors de l'assemblée générale annuelle.
+  
+**Processus d'amendement :**
+
+- Proposition par n'importe quel membre actif
+- Minimum **30 jours** de consultation publique (via Matrix, wiki)
+- Vote par **consentement renforcé** du Cercle Stratégique
+- Entrée en vigueur **6 mois** après adoption (sauf urgence justifiée) 
+
+**Amendements mineurs vs majeurs :**
+
+- Mineurs (corrections éditoriales) : décision rapide par le Cercle Stratégique
+- Majeurs (changement de valeurs, mission) : processus complet + possibilité de retrait sans préavis pour les membres en désaccord 
+
+**Valeurs cardinales inviolables :** Les 5 valeurs fondamentales ne peuvent être supprimées.
+
+### 10.2 Dissolution de L'Alliance
+
+**Conditions de dissolution :**
+
+1. Vote de dissolution par consentement renforcé (après consultation de tous les membres)
+2. Impossibilité de poursuivre la mission (plus aucun membre actif)
+3. Obligation légale (décision judiciaire ou administrative) **Processus :**
+4. Annonce publique (3 mois de préavis minimum)
+5. Liquidation ordonnée des actifs
+6. Restitution des fonds aux membres (prorata) ou don à un organisme aligné avec les valeurs
+7. Archivage de la documentation (dépôt public pour la postérité)
+8. Dissolution légale (selon procédures OBNL) 
+
+**Devenir des actifs :**
+
+- Code et documentation : restent sous licence libre (CC BY-SA, GPL)
+- Actifs financiers : distribution selon délibération du Cercle Stratégique
+- Marques et domaines : libérés ou transférés à un organisme successeur
+
+---
+
+## ANNEXE A : Glossaire des Termes
+
+**Voir Document 0 : Glossaire et Définitions pour la terminologie complète.**
+
+**Termes clés :**
+
+- **Autopoïèse** : Capacité d'un système à se maintenir et se régénérer lui-même
+- **Consentement sociocratique** : Absence d'objection raisonnée et argumentée
+- **Fédération libre** : Collaboration sans perte de souveraineté
+- **Label de prestige** : Reconnaissance de conformité (Bronze, Argent, Or, Platine)
+- **Objection valide** : Argument démontrant un risque sérieux pour la mission
+- **Subsidiarité** : Décision au niveau le plus proche des affectés
+
+---
+
+## ANNEXE B : Références Philosophiques
+
+**L'Alliance Boréale s'inspire de penseurs ayant réfléchi à la sobriété, l'autonomie, et la gestion des communs :**
+
+### **Pierre Rabhi (1938-2021) — Sobriété heureuse**
+
+> "La sobriété est un acte de résistance et de libération."
+> Refus de la croissance pour la croissance. Recherche d'un équilibre entre besoins réels et impact environnemental. Application au numérique : optimiser pour la durabilité plutôt que la performance maximale.
+
+### **Ivan Illich (1926-2002) — Outils conviviaux**
+
+> "L'outil convivial est celui qui me laisse la plus grande latitude et le plus grand pouvoir de modifier le monde au gré de mon intention."
+> Distinction entre outils conviviaux (qui augmentent l'autonomie) et outils manipulatoires (qui créent la dépendance). L'Alliance privilégie les protocoles ouverts et les logiciels libres — des outils conviviaux par excellence.
+
+### **Humberto Maturana (1928-2021) — Autopoïèse**
+
+Concept d'autopoïèse : capacité d'un système vivant à se maintenir et se régénérer lui-même, à produire ses propres composants. L'Alliance vise à devenir un système autopoïétique, capable de former ses nouveaux membres, de documenter son savoir, d'adapter sa gouvernance, et de perdurer au-delà de ses fondateurs.
+
+### **Elinor Ostrom (1933-2012) — Gestion des communs**
+
+Prix Nobel d'économie 2009 pour ses travaux sur la gestion collective de ressources partagées sans privatisation ni tragédie des communs. Elle a démontré qu'une communauté peut gérer durablement un bien commun si elle établit des règles claires, des mécanismes de surveillance, et des sanctions graduées. L'Alliance applique ces principes à l'infrastructure numérique.
+
+### **Principe de subsidiarité — Fédéralisme**
+
+###### Principe selon lequel les décisions doivent être prises au niveau le plus proche de ceux qu'elles affectent. Inspiré du fédéralisme suisse et canadien, ce principe garantit que L'Alliance n'intervient que lorsque les membres individuels ne peuvent résoudre un problème seuls.
+
+## ANNEXE C : Historique de Fondation
+
+**Phase de conception (2024-2025)**
+
+- Constat partagé par les acteurs du numérique éthique québécois : isolement, duplication des efforts, vulnérabilité face aux géants
+- Rencontres informelles et échanges sur les défis communs
+- Décision de formaliser une structure de coopération fédérée **Phase pilote (2025)**
+- Signature de la Charte par les membres fondateurs (Chezlepro, TechnoLibre)
+- Mise en place de la gouvernance sociocratique (3 cercles)
+- Déploiement de l'infrastructure technique fédérée (DNS, SSO)
+- Premiers audits pair-à-pair et attribution de labels **Consolidation (2026)**
+- Constitution en OBNL (visée)
+- Croissance organique (recrutement de nouveaux membres)
+- Soutenabilité financière progressive
+- Reconnaissance croissante du label Boréal
+
+---
+
+## ANNEXE D : Signataires Fondateurs
+
+##### **Cette Charte est adoptée et signée par les membres fondateurs de L'Alliance Boréale :**
+
+##### **Pour Chezlepro inc.**
+
+##### **Signature :** \______________________________\_ 
+
+##### **Nom :** Daniel Allaire 
+
+##### **Titre :** Président fondateur de L'Alliance Boréale 
+
+##### **Date :** \__________________\_
+
+##### **Pour TechnoLibre**
+
+##### **Signature :** \______________________________\_ 
+
+##### **Nom :** [À compléter]
+
+##### **Titre :** [À compléter]
+
+##### **Date :** \__________________\_
+
+## CONCLUSION
+
+###### **L'Alliance Boréale est plus qu'une fédération technique — c'est un acte de foi en notre capacité collective à bâtir un numérique à visage humain.** Nous refusons la fatalité de la dépendance aux géants. Nous croyons qu'une autre voie est possible : plus lente, plus coopérative, plus éthique, mais infiniment plus digne et durable. Nous ne promettons pas la perfection. Nous ne promettons pas la facilité. Nous ne promettons pas la croissance exponentielle. **Nous promettons l'authenticité.** Nous promettons la solidarité. Nous promettons la transmission. **Ensemble, arbre par arbre, nous tissons une forêt boréale numérique.** Que cette forêt grandisse lentement mais sûrement. Qu'elle survive aux tempêtes. Qu'elle nourrisse ceux qui viendront après nous. **Bienvenue dans L'Alliance. Bienvenue dans la forêt.** 🌲
+
+## **FIN DE LA CHARTE FONDATRICE**
+
+## *"Seuls, nous sommes vulnérables. Ensemble, nous sommes une forêt."* 
+
+## 🌲 **L'Alliance Boréale**
+
+## *Pour une souveraineté numérique québécoise et canadienne.*
+
+**Version 2.1 (consolidée) complétée le 22 octobre 2025**
+
+**Prochaine révision prévue :** Octobre 2026
+**Document vivant.** Cette Charte évolue avec L'Alliance. Les amendements sont documentés dans le Registraire et suivent le processus défini à l'Article 10.
+**Pour toute question ou proposition d'amendement :**
+contact@alliance-boreale.ca
+**Registraire public (métadonnées et décisions) :** https://forge.alliance-boreale.ca
\ No newline at end of file
diff --git a/docs/20-rag/02 - Règlement de régie interne.md b/docs/20-rag/02 - Règlement de régie interne.md
new file mode 100644
index 0000000..5e3be79
--- /dev/null
+++ b/docs/20-rag/02 - Règlement de régie interne.md	
@@ -0,0 +1,151 @@
+# 🌿 **Règlement de Régie Interne — Version Bio-Mimétiste & Autopoïétique (v3)**
+
+**Version :** 3.0
+**Date :** 25 octobre 2025
+**Cycle de Réalignement Boréal (CRB-3)**
+**Statut :** Référence vivante de gouvernance organique
+
+---
+
+## 🪧 Préambule — Avis de Réalignement CRB-3
+
+> Adoption du **principe d’autopoïèse institutionnelle** : la régie interne ne dicte plus, elle **maintient la cohérence du vivant numérique**.
+> Alignement complet avec :
+> – *Modèle à 8 couches biomimétique & autopoïétique (v3)*
+> – *Nomenclature v3*
+> – *Glossaire v3*
+>
+> Le présent règlement devient la **peau vivante** de la gouvernance boréale.
+
+---
+
+## 🌱 I. Introduction — La régie comme système immunitaire
+
+La régie interne agit comme le **système immunitaire** de la Fédération : elle veille à la santé du corps entier, détecte les dérives, et favorise leur guérison.
+
+Son rôle n’est pas de contraindre mais de **préserver la vitalité**.
+Elle apprend de chaque incident, intègre les leçons dans sa mémoire collective et ajuste ses réponses.
+
+> **Autorité vivante :** la régie ne commande pas ; elle orchestre l’équilibre.
+
+Chaque cercle, chaque membre, chaque service y contribue, comme une cellule qui sent et réagit sans ordre central.
+
+---
+
+## 🧩 II. Principes organiques de gouvernance
+
+| Principe                      | Description                                                  | Fonction biologique |
+| :---------------------------- | :----------------------------------------------------------- | :------------------ |
+| **Subsidiarité vivante**      | Les décisions se prennent au plus près du phénomène observé. | Réflexe local       |
+| **Responsabilité distribuée** | Le pouvoir circule comme la sève, partagé entre les couches. | Circulation         |
+| **Homéostasie**               | Les règles s’ajustent selon les retours d’expérience.        | Équilibre           |
+| **Autopoïèse**                | Chaque cercle peut se régénérer après transformation.        | Régénération        |
+| **Empathie systémique**       | Gouverner, c’est comprendre la fonction de l’autre.          | Immunité partagée   |
+| **Frugalité vitale**          | Aucune règle sans fonction nutritive pour l’ensemble.        | Métabolisme sobre   |
+
+Ces principes remplacent la hiérarchie classique ; la régie n’est plus un sommet mais une **symbiose de cercles**.
+
+---
+
+## ⚙️ III. Architecture des cercles et des rôles
+
+### 1. **Cercle fédératif (C1–C4)**
+
+* Gère les ressources physiques, les normes et la forge commune.
+* Définit les cadres de sécurité, de conformité et d’interopérabilité.
+* Garant de la stabilité et de la mémoire du système.
+
+### 2. **Cercle pivot (C5)**
+
+* Agit comme membrane intelligente entre la fédération et les tenants.
+* Filtre, protège, traduit et synchronise les flux.
+* Administre les identités croisées et les canaux d’observabilité.
+
+### 3. **Cercles des tenants (C6–C8)**
+
+* Espaces d’innovation et d’expression.
+* Produisent la valeur, partagent la connaissance et renvoient les signaux d’apprentissage.
+* Chaque tenant est libre mais responsable de la santé du tout.
+
+### 4. **Rôles vivants**
+
+* **Rôle de veille :** détecte les signaux faibles, signale les anomalies, initie la régénération.
+* **Rôle de facilitation :** assure la fluidité des interactions.
+* **Rôle de documentation :** consigne les ajustements dans le ΔLog institutionnel.
+
+Chaque cercle possède un fichier `regie.yaml` : son **ADN réglementaire**, décrivant mission, interfaces et rythme de régénération.
+
+---
+
+## 🔄 IV. Processus et flux décisionnels
+
+### 1. Détection
+
+Un besoin ou un déséquilibre est perçu (flux ascendant : C6→C5→C3).
+
+### 2. Régulation
+
+Le cercle concerné adapte ses politiques locales, informe ses adjacents.
+
+### 3. Propagation
+
+Les autres cercles synchronisent leurs ajustements ; la cohérence se rétablit.
+
+### 4. Traçabilité
+
+Chaque action crée une entrée dans le **ΔLog institutionnel**, consultable par tous.
+
+### 5. Apprentissage
+
+Les données et décisions enrichissent la mémoire collective ; le système se renforce.
+
+> **Règle d’or :** aucun message, aucune décision ne saute une couche.
+
+---
+
+## 💎 V. Éthique et conformité vivante
+
+* **Transparence** : tout processus est traçable, auditable, partageable.
+* **Bienveillance** : corriger, c’est enseigner ; punir, c’est un échec du système.
+* **Sobriété** : moins de règles, plus de sens.
+* **Régénérativité** : chaque règle doit nourrir l’écosystème.
+* **Symbiose** : fédérés et tenants coopèrent comme espèces complémentaires.
+
+Le **Label de Prestige** distingue les cercles incarnant pleinement ces valeurs.
+
+---
+
+## 📘 VI. Documentation et mémoire
+
+* Ce règlement est **auto-documenté** : chaque article est versionné avec son propre ΔLog.
+* Les révisions successives s’empilent comme des strates biologiques ; aucune n’efface la précédente.
+* Chaque mise à jour doit inclure :
+
+  * un *AB-Avis de Réalignement*,
+  * un ΔLog détaillé,
+  * et une Signature Boréale.
+
+---
+
+## 📜 VII. ΔLog CRB-3 (25-10-2025)
+
+* Conversion complète du *Règlement de Régie Interne* en organisme vivant.
+* Introduction des notions : autopoïèse institutionnelle, homéostasie, empathie systémique.
+* Transformation des articles en processus auto-régulés.
+* Ajout des fichiers ADN `regie.yaml` par cercle.
+* Synchronisation sémantique avec Modèle, Nomenclature et Glossaire v3.
+* Ajout du préambule CRB-3 et de la Signature Boréale.
+
+---
+
+## 🌌 Signature Boréale
+
+> *Quand une règle s’endort, une autre s’éveille.*
+> *La régie n’est pas un mur, mais une peau.*
+> *Elle respire, apprend, cicatrise et recommence.*
+> *Ainsi veille l’Alliance, vivante et lucide.*
+
+---
+
+📁 **Destination** :
+`docs/constitution/02_Reglement_de_Regie_Interne_biomimetique_autopoietique_v3.md`
diff --git a/docs/20-rag/03_Cadre_Conformite_Label_Prestige(1).md b/docs/20-rag/03_Cadre_Conformite_Label_Prestige(1).md
new file mode 100644
index 0000000..a0b0eee
--- /dev/null
+++ b/docs/20-rag/03_Cadre_Conformite_Label_Prestige(1).md
@@ -0,0 +1,1085 @@
+# Document 3 : Cadre de Conformité et Label de Prestige
+
+<!-- AB-Avis-de-réalignement 20251025-162438 -->
+## Réalignement des couches & Portabilité des tenants
+
+### Règle d’appartenance par couche
+- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**.
+- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**.
+- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**.
+
+### Principe de portabilité des tenants
+Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont :
+1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte).
+2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable.
+3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible.
+4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée.
+5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**.
+
+> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**;  
+> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus.
+<!-- /AB-Avis-de-réalignement 20251025-162438 -->
+
+
+## L'Alliance Boréale
+🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md)
+**Version:** 1.0
+**Date:** 23 octobre 2025
+**Statut:** Document fondateur
+**Adopté par :** Cercle Éthique & Conformité
+**Licence:** CC BY-SA 4.0
+---
+## PRÉAMBULE
+Le Label de Prestige de L'Alliance Boréale n'est pas un certificat marketing vide de sens.
+**C'est un outil de transparence, d'amélioration continue, et de reconnaissance mutuelle.**
+**Trois objectifs complémentaires :**
+1. **Transparence envers le public**
+   Permettre aux utilisateurs finaux de choisir en connaissance de cause (quel membre respecte quelles pratiques).
+2. **Amélioration continue des membres**
+   Le label est un miroir. Il montre où nous excellons et où nous devons progresser.
+3. **Reconnaissance entre pairs**
+   Le label est décerné PAR les membres POUR les membres. C'est une validation par ceux qui connaissent vraiment les défis du terrain.
+**Ce que le label N'EST PAS :**
+- ❌ Une certification ISO bureaucratique
+- ❌ Un outil de compétition toxique (classement, ranking public)
+- ❌ Une barrière à l'entrée (le label est volontaire, pas obligatoire)
+- ❌ Une garantie absolue (même les meilleurs peuvent avoir des incidents)
+**Le label est un processus vivant.** Il évolue avec L'Alliance, nos apprentissages, et l'écosystème numérique.
+---
+## SECTION 1 : ARCHITECTURE DU LABEL
+### 1.1 Les 6 Domaines d'Évaluation
+
+(couvrant l’ensemble des 8 couches : Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie/Éthique)
+
+Le label évalue les pratiques selon **6 domaines** couvrant l'ensemble des couches de l'architecture boréale (couches 1-8 (Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie)).
+#### Domaine 1 : Infrastructure & Résilience (Couches 1-3 (Physique, Réseau, Virtualisation))
+**Objectif :** Garantir la disponibilité, la durabilité, et la réparabilité de l'infrastructure physique et réseau.
+**Thématiques couvertes :**
+- Hardware (serveurs, stockage, énergie)
+- Réseau (bande passante, latence, redondance)
+- Stockage (backups, réplication, chiffrement)
+- Monitoring (métriques, alerting)
+- Plans de reprise (disaster recovery, RTO/RPO)
+**Exemples de critères :**
+- Disponibilité mesurée > 99% (hors maintenance planifiée)
+- Backups testés mensuellement
+- Documentation à jour de l'infrastructure
+- Énergie renouvelable > 50% (si contrôle direct) ou hébergeur vert
+---
+#### Domaine 2 : Sécurité & Vie Privée (Couches 2-5 (Réseau, Virtualisation, Orchestration, Supervision))
+**Objectif :** Protéger les données des utilisateurs et prévenir les intrusions, conformément aux lois (Loi 25, RGPD).
+**Thématiques couvertes :**
+- Chiffrement (transit, repos, backups)
+- Authentification (MFA, politiques mots de passe)
+- Gestion des accès (principe moindre privilège)
+- Mises à jour de sécurité (délais, automation)
+- Conformité légale (Loi 25, RGPD)
+- Gestion des incidents de sécurité
+**Exemples de critères :**
+- TLS 1.3 obligatoire (pas de TLS 1.0/1.1)
+- MFA activée pour accès admin
+- Patches critiques appliqués < 7 jours après publication
+- Politique de confidentialité publique et conforme
+- Registre des traitements de données (RGPD Article 30)
+---
+#### Domaine 3 : Interopérabilité & Standards Ouverts (Couches 3-6 (Virtualisation, Orchestration, Supervision, Services))
+**Objectif :** Garantir que les services respectent les standards ouverts et facilitent la portabilité des données.
+**Thématiques couvertes :**
+- Protocoles ouverts (SMTP, IMAP, CalDAV, WebDAV, XMPP/Matrix, etc.)
+- Formats de données (pas de lock-in propriétaire)
+- APIs documentées (si applicable)
+- Export de données (RGPD Article 20)
+- Fédération (si applicable)
+**Exemples de critères :**
+- Email via SMTP/IMAP (pas uniquement webmail propriétaire)
+- Calendrier accessible via CalDAV (pas uniquement app propriétaire)
+- Export complet des données utilisateur en < 30 jours
+- APIs publiquement documentées (si services API)
+- Support de standards de fédération (Matrix, ActivityPub, etc.)
+---
+#### Domaine 4 : Logiciels Libres & Éthique (Couches 5-7 (Supervision, Services, Gouvernance & données))
+**Objectif :** Promouvoir l'usage de logiciels libres et l'alignement avec les valeurs de L'Alliance.
+**Thématiques couvertes :**
+- Pourcentage de stack libre (OS, applications, outils)
+- Contribution à l'écosystème libre (patches, donations, sponsoring)
+- Transparence sur les dépendances propriétaires
+- Éthique des fournisseurs (pas de GAFAM pour services critiques)
+- Gouvernance interne (démocratie, transparence)
+**Exemples de critères :**
+- ≥ 80% de la stack en logiciel libre
+- Au moins 1 contribution annuelle à un projet libre
+- Aucune dépendance critique aux GAFAM (AWS, GCP, Azure pour prod)
+- Publication de la liste des dépendances (transparence)
+- Gouvernance démocratique ou coopérative (si applicable)
+---
+#### Domaine 5 : Opérations & Documentation (Couches 4-7 (Orchestration, Supervision, Services, Gouvernance & données))
+**Objectif :** Garantir la qualité opérationnelle, la traçabilité, et la transmissibilité des pratiques.
+**Thématiques couvertes :**
+- Infrastructure as Code (IaC)
+- Documentation technique (runbooks, architectures)
+- Gestion des incidents (post-mortems, déclarations)
+- Monitoring et observabilité
+- Automatisation (CI/CD, tests)
+**Exemples de critères :**
+- IaC pour ≥ 70% de l'infrastructure
+- Runbooks à jour pour procédures critiques
+- Post-mortem publié pour tout incident P0/P1
+- Métriques de disponibilité publiques (status page)
+- Tests automatisés pour changements critiques
+---
+#### Domaine 6 : Sobriété Numérique & Durabilité (Toutes Couches)
+**Objectif :** Mesurer et réduire l'empreinte écologique du numérique.
+**Thématiques couvertes :**
+- Consommation énergétique (mesure, réduction)
+- Durée de vie du matériel (allongement, réparation)
+- Optimisation des ressources (CPU, RAM, stockage, bande passante)
+- Sensibilisation des utilisateurs (bonnes pratiques)
+- Compensation carbone (optionnel mais valorisé)
+**Exemples de critères :**
+- Mesure de la consommation énergétique (kWh/mois)
+- Serveurs utilisés > 5 ans (si fonctionnels)
+- Politique de rétention des données (suppression automatique)
+- Guide utilisateur sur sobriété numérique
+- Hébergement dans datacenter < 1.3 PUE (Power Usage Effectiveness)
+---### 1.2 Les 4 Niveaux de Label
+Le label comporte 4 niveaux progressifs. Chaque niveau nécessite un score minimal dans chaque domaine ET un score global minimal.
+#### Niveau Bronze (Fondations)
+**Symbolique :** Engagement initial, bases solides.
+**Critères :**
+- Score minimal par domaine : **40/100**
+- Score global minimal : **50/100**
+- Durée de validité : **12 mois**
+**Profil type :**
+Nouveau membre ayant déployé les fondations (DNS, sécurité de base, documentation minimale), mais avec marges d'amélioration importantes.
+**Autorisations :**
+- Usage du badge "Alliance Boréale — Bronze"
+- Mention sur site web et communications
+- Accès aux outils communs (Matrix, forge, wiki)
+---
+#### Niveau Argent (Maturité)
+**Symbolique :** Maturité opérationnelle, pratiques établies.
+**Critères :**
+- Score minimal par domaine : **60/100**
+- Score global minimal : **65/100**
+- Durée de validité : **12 mois**
+**Profil type :**
+Membre avec infrastructure robuste, documentation solide, participation active, mais n'ayant pas encore atteint l'excellence dans tous les domaines.
+**Autorisations :**
+- Usage du badge "Alliance Boréale — Argent"
+- Participation comme auditeur pair (avec formation)
+- Mention prioritaire dans annuaire public
+---
+#### Niveau Or (Excellence)
+**Symbolique :** Excellence technique et éthique, référence pour les pairs.
+**Critères :**
+- Score minimal par domaine : **75/100**
+- Score global minimal : **80/100**
+- Durée de validité : **12 mois**
+- Obligation : Au moins 1 contribution significative à L'Alliance (code, doc, formation)
+**Profil type :**
+Membre exemplaire, peu d'incidents, documentation exhaustive, forte contribution à la communauté, alignement éthique démontré.
+**Autorisations :**
+- Usage du badge "Alliance Boréale — Or"
+- Rôle de mentor pour nouveaux membres
+- Participation au Cercle Éthique (si élu)
+- Mention comme "Membre Exemplaire" dans communications
+---
+#### Niveau Platine (Avant-garde)
+**Symbolique :** Innovation, leadership, modèle inspirant.
+**Critères :**
+- Score minimal par domaine : **85/100**
+- Score global minimal : **90/100**
+- Durée de validité : **18 mois** (reconnaissance de l'excellence soutenue)
+- Obligation : Au moins 2 contributions majeures à L'Alliance OU leadership d'un projet fédéral
+**Profil type :**
+Membre d'avant-garde, zéro incident P0 sur 12 mois, innovations partagées, mentorat actif, alignement éthique parfait, inspiration pour l'écosystème.
+**Autorisations :**
+- Usage du badge "Alliance Boréale — Platine"
+- Reconnaissance publique (cas d'étude, conférences)
+- Invitation automatique aux cercles stratégiques
+- Droit de veto éthique (cas exceptionnels)
+**Rare et mérité :**
+Le Platine n'est pas un objectif pour tous. C'est une reconnaissance de l'excellence soutenue et de l'impact sur l'ensemble de L'Alliance.
+---
+### 1.3 Calcul du Score
+#### 1.3.1 Notation par Domaine
+Chaque domaine est noté sur **100 points**.
+**Structure :**
+- Critères obligatoires (60 points)
+- Critères recommandés (30 points)
+- Critères d'excellence (10 points)
+**Critères obligatoires (60 pts) :**
+Fondations indispensables. Échec = score plafonné à 59/100 dans le domaine.
+**Critères recommandés (30 pts) :**
+Bonnes pratiques. Permettent d'atteindre scores Argent/Or.
+**Critères d'excellence (10 pts) :**
+Innovation, avant-garde. Nécessaires pour Or/Platine.
+**Exemple (Domaine 2 : Sécurité) :**
+```
+Critères obligatoires (60 pts) :
+- TLS 1.2+ sur tous les services publics (10 pts)
+- MFA pour accès admin (10 pts)
+- Backups chiffrés (10 pts)
+- Politique confidentialité publique (10 pts)
+- Patches critiques < 30 jours (10 pts)
+- Monitoring sécurité actif (10 pts)
+Critères recommandés (30 pts) :
+- TLS 1.3 uniquement (5 pts)
+- MFA pour utilisateurs finaux (5 pts)
+- Patches critiques < 7 jours (10 pts)
+- Audit de sécurité externe annuel (5 pts)
+- Politique RGPD Article 30 complète (5 pts)
+Critères d'excellence (10 pts) :
+- Zero-knowledge encryption (5 pts)
+- Bug bounty program (3 pts)
+- Certification ISO 27001 ou équivalent (2 pts)
+```
+**Total domaine :** Maximum 100 pts.
+---
+#### 1.3.2 Score Global
+**Calcul :**
+```
+Score Global = Moyenne des 6 domaines
+```
+**Exemple :**
+| Domaine | Score |
+|---------|-------|
+| Infrastructure | 75 |
+| Sécurité | 80 |
+| Interopérabilité | 70 |
+| Logiciels Libres | 85 |
+| Opérations | 65 |
+| Sobriété | 60 |
+| **Moyenne** | **72.5** |
+→ Niveau : **Argent** (score global 72.5, tous domaines ≥ 60)
+**Règle importante :**
+Un domaine faible (< seuil) empêche l'accès au niveau supérieur, même si le score global est élevé.
+**Rationale :** Éviter les membres "spécialisés" qui excellent dans 4 domaines mais négligent 2 autres. L'Alliance promeut l'excellence équilibrée.
+---
+#### 1.3.3 Pondération (Future Évolution)
+**Version 1.0 (ce document) :** Tous les domaines ont le même poids (1/6).
+**Version future (2027+) :** Possibilité d'introduire pondération si consensus :
+- Exemple : Sécurité 25%, Interopérabilité 20%, autres 11% chacun
+- Nécessite amendement de ce document (Section 7)
+**Rationale de l'égalité actuelle :**
+En phase pilote, nous voulons observer quels domaines sont les plus critiques avant d'introduire une pondération.
+---
+## SECTION 2 : GRILLES D'ÉVALUATION DÉTAILLÉES
+### 2.1 Domaine 1 : Infrastructure & Résilience
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 1.1 | Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée) | 10 | Métriques monitoring (Prometheus, Grafana, status page) |
+| 1.2 | Backup automatisé quotidien | 10 | Configuration (cron, script, logs) |
+| 1.3 | Test de restauration réussi dans les 6 derniers mois | 10 | Rapport de test (date, procédure, résultat) |
+| 1.4 | Monitoring actif avec alerting | 10 | Alertmanager configuré, logs d'alertes |
+| 1.5 | Documentation de l'architecture (diagramme + inventaire) | 10 | Wiki ou doc versionnée (Markdown, Diagrams.net) |
+| 1.6 | Plan de reprise documenté (RTO/RPO définis) | 10 | Document DRP (Disaster Recovery Plan) |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 1.7 | Disponibilité ≥ 99.5% | 5 | Métriques monitoring |
+| 1.8 | Backup incrémental + complet hebdomadaire | 5 | Configuration (rsnapshot, Borg, etc.) |
+| 1.9 | Réplication géographique (2+ sites) | 5 | Preuve hébergement multi-sites |
+| 1.10 | Monitoring externe (tiers indépendant) | 5 | UptimeRobot, Pingdom, ou équivalent |
+| 1.11 | Redondance réseau (2+ liens internet) | 5 | Configuration BGP ou failover |
+| 1.12 | Infrastructure as Code ≥ 50% | 5 | Playbooks Ansible, Terraform, scripts |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 1.13 | Disponibilité ≥ 99.9% (3 nines) | 5 | Métriques monitoring |
+| 1.14 | Chaos engineering (tests de résilience) | 3 | Rapports de tests (ex: ChaosMonkey, simulations) |
+| 1.15 | Infrastructure 100% IaC (reproductible) | 2 | Git repo complet |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 1 :** 100 pts
+---
+### 2.2 Domaine 2 : Sécurité & Vie Privée
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 2.1 | TLS 1.2+ sur tous services publics | 10 | Scan SSL Labs (grade A- minimum) |
+| 2.2 | MFA activée pour accès administrateurs | 10 | Capture écran config (TOTP, U2F, etc.) |
+| 2.3 | Backups chiffrés (AES-256 ou équivalent) | 10 | Configuration de chiffrement |
+| 2.4 | Politique de confidentialité publique et conforme (Loi 25 ou RGPD) | 10 | URL de la politique + revue conformité |
+| 2.5 | Patches de sécurité critiques appliqués < 30 jours | 10 | Logs de mises à jour (apt, yum, etc.) |
+| 2.6 | Pare-feu configuré (ports nécessaires uniquement) | 10 | Sortie `iptables -L` ou équivalent |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 2.7 | TLS 1.3 uniquement (pas de 1.2) | 5 | Scan SSL Labs (grade A+) |
+| 2.8 | MFA proposée aux utilisateurs finaux | 5 | Capture écran option activable |
+| 2.9 | Patches de sécurité critiques < 7 jours | 10 | Logs mises à jour |
+| 2.10 | Registre des traitements RGPD (Article 30) | 5 | Document du registre |
+| 2.11 | Audit de sécurité externe annuel | 5 | Rapport d'audit (synthèse) |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 2.12 | Zero-knowledge encryption (E2EE) | 5 | Architecture technique + audit |
+| 2.13 | Bug bounty program actif | 3 | URL du programme + règles |
+| 2.14 | Certification ISO 27001 ou SOC 2 | 2 | Certificat valide |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 2 :** 100 pts
+---
+### 2.3 Domaine 3 : Interopérabilité & Standards Ouverts
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 3.1 | Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire) | 15 | Configuration serveur (Postfix, Dovecot, etc.) |
+| 3.2 | Export complet des données utilisateur possible | 15 | Procédure documentée + test |
+| 3.3 | Formats de stockage ouverts (pas de lock-in propriétaire) | 10 | Liste formats utilisés (Markdown, JSON, SQL, etc.) |
+| 3.4 | DNS configuré selon standards (DNSSEC recommandé) | 10 | Validation DNSViz ou équivalent |
+| 3.5 | DKIM, SPF, DMARC configurés (si email) | 10 | Scan MXToolbox ou équivalent |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 3.6 | Calendrier via CalDAV / Contacts via CardDAV | 10 | Configuration serveur (Radicale, Nextcloud, etc.) |
+| 3.7 | APIs publiquement documentées (si applicable) | 10 | URL documentation (Swagger, OpenAPI, etc.) |
+| 3.8 | Support de fédération (Matrix, ActivityPub, XMPP, etc.) | 5 | Configuration + test de fédération |
+| 3.9 | Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.) | 5 | Analyse Blacklight, uBlock Origin |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 3.10 | Contribution à des standards ouverts (RFC, W3C, etc.) | 5 | Liens vers contributions |
+| 3.11 | Support multi-protocoles (email + Matrix + CalDAV + WebDAV) | 3 | Configuration complète |
+| 3.12 | Publication de schémas de données (Open Data) | 2 | URL schémas (JSON Schema, etc.) |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 3 :** 100 pts
+---
+### 2.4 Domaine 4 : Logiciels Libres & Éthique
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 4.1 | OS serveur libre (Linux, BSD) | 15 | `uname -a` ou équivalent |
+| 4.2 | ≥ 60% de la stack applicative en logiciel libre | 15 | Inventaire logiciels (avec licences) |
+| 4.3 | Liste publique des dépendances (transparence) | 10 | Document ou page web |
+| 4.4 | Aucune dépendance critique aux GAFAM (production) | 10 | Déclaration signée |
+| 4.5 | Gouvernance non autoritaire (coopérative, démocratique, ou collégiale) | 10 | Statuts légaux ou règlement interne |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 4.6 | ≥ 80% de la stack applicative en logiciel libre | 10 | Inventaire détaillé |
+| 4.7 | Au moins 1 contribution annuelle à un projet libre | 10 | Liens vers commits, PRs, donations |
+| 4.8 | Publication de code maison en licence libre | 5 | Dépôts Git publics |
+| 4.9 | Politique d'achat favorisant fournisseurs éthiques | 5 | Document de politique |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 4.10 | 100% de la stack en logiciel libre | 5 | Inventaire complet |
+| 4.11 | Mainteneur actif d'un projet libre majeur | 3 | Preuve de maintenance (GitHub stats, etc.) |
+| 4.12 | Certification B Corp ou équivalent | 2 | Certificat |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 4 :** 100 pts
+---
+### 2.5 Domaine 5 : Opérations & Documentation
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 5.1 | Runbook pour au moins 3 procédures critiques | 15 | Wiki ou dépôt doc |
+| 5.2 | Documentation architecture à jour | 10 | Diagrammes + descriptions |
+| 5.3 | Post-mortem publié pour incidents P0/P1 (6 derniers mois) | 15 | Lien vers post-mortems |
+| 5.4 | Monitoring avec métriques exportées (Prometheus compatible) | 10 | Configuration Prometheus |
+| 5.5 | Status page public (ou métriques disponibilité) | 10 | URL status page |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 5.6 | IaC pour ≥ 70% de l'infrastructure | 10 | Playbooks Ansible, Terraform |
+| 5.7 | CI/CD avec tests automatisés | 10 | Configuration GitLab CI, GitHub Actions, etc. |
+| 5.8 | Documentation générée automatiquement (code) | 5 | Sphinx, JSDoc, ou équivalent |
+| 5.9 | Contributions régulières au wiki L'Alliance | 5 | Historique Git wiki |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 5.10 | Infrastructure 100% IaC (zero manual config) | 5 | Démo reproductibilité |
+| 5.11 | Observabilité avancée (tracing distribué, logs structurés) | 3 | Jaeger, ELK, ou équivalent |
+| 5.12 | SLA publiquement documenté et respecté | 2 | SLA + rapport conformité |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 5 :** 100 pts
+---
+### 2.6 Domaine 6 : Sobriété Numérique & Durabilité
+#### Critères Obligatoires (60 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 6.1 | Mesure de la consommation énergétique (kWh/mois) | 15 | Factures ou monitoring IPMI |
+| 6.2 | Politique de rétention des données documentée | 10 | Document politique |
+| 6.3 | Serveurs utilisés ≥ 3 ans (si contrôle direct) | 15 | Inventaire avec dates acquisition |
+| 6.4 | Hébergeur avec engagement environnemental (si externalisé) | 10 | Certification hébergeur (ISO 14001, PUE < 1.5) |
+| 6.5 | Guide utilisateur sur bonnes pratiques sobriété | 10 | Document ou page web |
+**Total obligatoire :** 60 pts
+---
+#### Critères Recommandés (30 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 6.6 | Réduction consommation énergétique année/année | 10 | Comparatif metrics |
+| 6.7 | Serveurs utilisés ≥ 5 ans | 5 | Inventaire |
+| 6.8 | Optimisation ressources (CPU/RAM/stockage < 70% en moyenne) | 5 | Métriques monitoring |
+| 6.9 | Énergie renouvelable ≥ 50% (si contrôle direct) | 5 | Factures ou certificat |
+| 6.10 | Extinction services non critiques hors heures | 5 | Scripts automation + logs |
+**Total recommandé :** 30 pts
+---
+#### Critères d'Excellence (10 pts)
+| # | Critère | Points | Preuve Requise |
+|---|---------|--------|----------------|
+| 6.11 | Énergie 100% renouvelable | 5 | Certificat fournisseur |
+| 6.12 | Compensation carbone volontaire | 3 | Reçus donations (Planetair, etc.) |
+| 6.13 | Publication rapport impact environnemental annuel | 2 | Rapport public |
+**Total excellence :** 10 pts
+**TOTAL DOMAINE 6 :** 100 pts
+---
+## SECTION 3 : PROCESSUS D'AUDIT
+### 3.1 Principe de l'Audit Pair-à-Pair
+**L'Alliance Boréale utilise l'audit pair-à-pair :**
+Les membres auditent les membres. Pas d'auditeur externe coûteux. Pas de certification bureaucratique.
+**Avantages :**
+- **Coût zéro** (temps valorisé via banque de temps)
+- **Expertise réelle** (les auditeurs connaissent les défis du terrain)
+- **Apprentissage mutuel** (audité ET auditeur progressent)
+- **Confiance renforcée** (transparence entre pairs)
+**Garde-fous :**
+- Conflit d'intérêts interdit (on n'audite pas son concurrent direct)
+- Formation obligatoire des auditeurs
+- Validation finale par Cercle Éthique
+- Possibilité de recours (si désaccord sur notation)
+---
+### 3.2 Qui Peut Auditer ?
+**Éligibilité auditeur :**
+- Membre actif depuis ≥ 6 mois
+- Score label Argent ou supérieur (si déjà labellisé)
+- Formation auditeur complétée (atelier 4h)
+- Aucun conflit d'intérêts avec l'audité
+**Formation auditeur (obligatoire) :**
+- Compréhension des 6 domaines et grilles
+- Méthodologie de collecte de preuves
+- Rédaction de rapport d'audit
+- Éthique de l'auditeur (impartialité, confidentialité)
+**Durée formation :** 4h (atelier interactif, 1x/trimestre)
+**Validation :** Quiz final (80% requis)
+**Certification :** Valide 24 mois (renouvellement via atelier ou examen)
+---
+### 3.3 Étapes du Processus d'Audit
+#### Étape 1 : Demande de Labellisation (Semaine 0)
+**Qui :** Membre actif souhaitant obtenir ou renouveler le label.
+**Prérequis :**
+- Membre actif depuis ≥ 6 mois
+- Aucune suspension en cours
+- Cotisation à jour
+**Action :**
+1. Remplir formulaire de demande (via Registraire ou email)
+2. Auto-évaluation préliminaire (grille des 6 domaines)
+3. Identification des preuves disponibles
+**Délai de traitement :** 7 jours (validation admissibilité par Cercle Éthique)
+---
+#### Étape 2 : Désignation de l'Auditeur (Semaine 1)
+**Qui :** Cercle Éthique & Conformité.
+**Critères de désignation :**
+- Éviter conflit d'intérêts (pas de compétiteur direct)
+- Privilégier expertise pertinente (ex: expert infra pour domaine 1)
+- Rotation équitable (chaque auditeur audite environ 2-3 (Réseau, Virtualisation) fois/an)
+**Notification :**
+- Auditeur contacté (acceptation sous 7 jours)
+- Si refus, désignation d'un autre auditeur
+- Audité informé de l'identité de l'auditeur
+**Kick-off :**
+- Réunion initiale (auditeur + audité, 30-60 min)
+- Clarification du périmètre
+- Planning de l'audit (4-6 (Orchestration, Supervision, Services) semaines typiquement)
+---
+#### Étape 3 : Collecte de Preuves (Semaines 2-4 (Réseau, Virtualisation, Orchestration))
+**Qui :** Audité (prépare preuves) + Auditeur (révise et valide).
+**Preuves attendues (selon domaine) :**
+**Domaine 1 (Infrastructure) :**
+- Captures écran monitoring (Grafana, Prometheus)
+- Logs de backups (derniers 3 mois)
+- Rapport de test de restauration
+- Diagramme architecture (Diagrams.net, Draw.io)
+- Plan de reprise (document DRP)
+**Domaine 2 (Sécurité) :**
+- Scan SSL Labs (grade A- minimum)
+- Capture config MFA (avec données sensibles masquées)
+- Politique de confidentialité (URL publique)
+- Logs mises à jour sécurité (derniers 6 mois)
+- Configuration pare-feu (règles actives)
+**Domaine 3 (Interopérabilité) :**
+- Configuration serveurs (Postfix, Dovecot, etc.)
+- Test export données (capture procédure)
+- Scan MXToolbox (DKIM, SPF, DMARC)
+- Liste formats de données utilisés
+**Domaine 4 (Logiciels Libres) :**
+- Inventaire logiciels (nom, version, licence)
+- Déclaration dépendances GAFAM (signée)
+- Liens vers contributions (commits GitHub, donations)
+- Statuts légaux (si gouvernance évaluée)
+**Domaine 5 (Opérations) :**
+- Runbooks (au moins 3, liens wiki)
+- Post-mortems (derniers 12 mois)
+- Configuration monitoring (Prometheus, Grafana)
+- Playbooks IaC (Ansible, Terraform)
+**Domaine 6 (Sobriété) :**
+- Factures énergétiques (derniers 12 mois, anonymisées si besoin)
+- Inventaire serveurs (âge, consommation estimée)
+- Politique rétention données (document)
+- Guide utilisateur sobriété (URL ou doc)
+**Format de soumission :**
+- Dépôt Git privé partagé (auditeur + audité + Cercle Éthique)
+- Structure : `/domaine-X/critere-X.Y/preuve-*.{pdf,png,md}`
+**Échanges :**
+- Questions/réponses asynchrones (Matrix canal privé)
+- Réunion de mi-parcours (facultative, semaine 3)
+---
+#### Étape 4 : Évaluation et Notation (Semaine 5)
+**Qui :** Auditeur.
+**Action :**
+1. Révision de toutes les preuves
+2. Attribution des points (critère par critère)
+3. Calcul score par domaine (max 100)
+4. Calcul score global (moyenne des 6 domaines)
+5. Détermination niveau éligible (Bronze/Argent/Or/Platine)
+**Grille de notation :**
+- ✅ **Preuve solide et complète** → Points attribués
+- ⚠️ **Preuve partielle ou incomplète** → Points partiels (50%)
+- ❌ **Preuve absente ou invalide** → 0 point
+**Justification obligatoire :**
+Pour chaque critère, l'auditeur doit noter :
+- Preuve fournie (référence)
+- Points attribués (nombre)
+- Justification (pourquoi ce score)
+**Exemple :**
+```yaml
+domaine: 2
+critere: 2.1
+titre: "TLS 1.2+ sur tous services publics"
+points_max: 10
+preuve: "domaine-2/critere-2.1/ssllabs-scan.pdf"
+evaluation:
+  points_attribues: 10
+  justification: "Scan SSL Labs montre grade A sur tous les sous-domaines testés. TLS 1.2 et 1.3 activés, pas de TLS 1.0/1.1."
+```
+---
+#### Étape 5 : Rapport d'Audit (Semaine 5-6 (Supervision, Services))
+**Qui :** Auditeur.
+**Contenu du rapport :**
+1. **Page de titre**
+   - Audité (nom, membre ID)
+   - Auditeur (nom, membre ID)
+   - Date de l'audit
+   - Niveau demandé vs. niveau obtenu
+2. **Synthèse exécutive** (1 page)
+   - Score global
+   - Scores par domaine (tableau)
+   - Niveau de label attribué
+   - Points forts (3-5 (Virtualisation, Orchestration, Supervision))
+   - Points d'amélioration (3-5 (Virtualisation, Orchestration, Supervision))
+3. **Évaluation détaillée par domaine** (1-2 (Physique, Réseau) pages/domaine)
+   - Tableau critères avec points
+   - Justifications
+   - Observations de l'auditeur
+   - Recommandations
+4. **Non-conformités identifiées**
+   - Majeures (critères obligatoires non respectés)
+   - Mineures (critères recommandés non atteints)
+   - Suggestions (critères d'excellence)
+5. **Plan d'action recommandé** (optionnel)
+   - Actions prioritaires pour améliorer score
+   - Délais suggérés
+   - Ressources nécessaires
+6. **Annexes**
+   - Liste des preuves examinées
+   - Captures écran clés (si pertinent)
+**Format :** Markdown ou PDF.
+**Longueur typique :** 10-15 pages.
+---
+#### Étape 6 : Révision par l'Audité (Semaine 6)
+**Qui :** Audité.
+**Délai :** 7 jours pour réagir au rapport.
+**Options :**
+**A) Acceptation sans réserve**
+→ Passage direct à validation Cercle Éthique.
+**B) Demande de clarification**
+→ Auditeur clarifie (48h). Si satisfaisant, acceptation. Sinon, recours.
+**C) Contestation d'un critère**
+→ Procédure de recours (voir Section 3.4).
+**Documentation :**
+- Réponse écrite de l'audité (acceptation, questions, ou contestation)
+- Versée au dépôt d'audit
+---
+#### Étape 7 : Validation par Cercle Éthique (Semaine 7)
+**Qui :** Cercle Éthique & Conformité.
+**Action :**
+1. Révision du rapport d'audit (cohérence, qualité)
+2. Vérification absence conflit d'intérêts
+3. Validation des scores (spot-check sur 2-3 (Réseau, Virtualisation) critères)
+4. Décision d'attribution du label (consentement)
+**Critères de validation :**
+- ✅ Rapport complet et justifié
+- ✅ Preuves solides
+- ✅ Pas de conflit d'intérêts détecté
+- ✅ Audité a accepté (ou recours traité)
+**Décision possible :**
+- **Approuvé** : Label attribué au niveau calculé
+- **Approuvé avec conditions** : Label attribué, mais plan d'action obligatoire (délai 6 mois)
+- **Rejeté** : Score insuffisant OU preuves invalides → Réaudit requis (délai 3 mois)
+**Notification :**
+- Audité informé sous 7 jours (email + Matrix)
+- Si approuvé : Badge généré, Registraire mis à jour
+- Si rejeté : Feedback détaillé + accompagnement proposé
+---
+### 3.4 Procédure de Recours
+**Déclenchement :**
+Audité conteste un ou plusieurs critères du rapport d'audit (désaccord sur notation).
+**Délai :** 7 jours après réception du rapport.
+**Étapes :**
+1. **Dépôt de recours** (formulaire standardisé)
+   - Critère(s) contesté(s)
+   - Justification (pourquoi le score devrait être différent)
+   - Preuves complémentaires (si nouvelles)
+2. **Médiation** (Cercle Éthique, 14 jours)
+   - Rencontre tripartite (audité, auditeur, médiateur du Cercle Éthique)
+   - Révision des preuves contestées
+   - Tentative d'accord à l'amiable
+3. **Décision finale** (Cercle Éthique, consentement renforcé)
+   - Si médiation échoue → Cercle Éthique tranche
+   - Décision motivée par écrit
+   - Pas d'autre recours (sauf violation de procédure grave → Cercle Stratégique)
+**Délai total :** Maximum 30 jours.
+**Coûts :** Aucun (inclus dans cotisation). Temps valorisé via banque de temps.
+---
+## SECTION 4 : CERTIFICATION ET VALIDITÉ
+### 4.1 Attribution du Label
+**Suite à validation par Cercle Éthique :**
+1. **Génération du badge** (logo + niveau + ID unique)
+   - Format : SVG + PNG (haute résolution)
+   - Couleurs : Bronze (CD7F32), Argent (C0C0C0), Or (FFD700), Platine (E5E4E2)
+2. **Mise à jour Registraire**
+   - Fiche membre : ajout du label (niveau, score, date, validité)
+   - Historique : traçabilité des labels successifs
+3. **Communication**
+   - Annonce sur Matrix #general (félicitations publiques)
+   - Mention dans newsletter trimestrielle
+   - Partage autorisé sur réseaux sociaux (membre peut publier son badge)
+4. **Remise symbolique** (optionnel)
+   - Lors de la rencontre annuelle (présentiel)
+   - Certificat imprimé + badge physique (si demandé)
+---
+### 4.2 Durée de Validité
+**Par niveau :**
+| Niveau | Durée |
+|--------|-------|
+| Bronze | 12 mois |
+| Argent | 12 mois |
+| Or | 12 mois |
+| Platine | 18 mois |
+**Rationale Platine :**
+Reconnaître l'excellence soutenue en allégeant la charge de recertification (tous les 1.5 ans au lieu de 1 an).
+**Expiration :**
+À la date anniversaire (jour/mois/année de l'attribution + durée).
+**Alerte :**
+- Email automatique 60 jours avant expiration
+- Rappel 30 jours avant expiration
+- Dernière alerte 7 jours avant expiration
+**Si expiration sans renouvellement :**
+- Label révoqué automatiquement
+- Badge retiré du Registraire (historique conservé)
+- Membre doit cesser usage du badge
+---
+### 4.3 Renouvellement (Recertification)
+**Processus :**
+Identique à l'audit initial, MAIS avec simplifications possibles :
+**Simplification 1 : Auto-évaluation allégée**
+- Focus sur les domaines ayant changé
+- Si score précédent ≥ 80 → Auditeur peut spot-check (pas tout réviser)
+**Simplification 2 : Même auditeur (optionnel)**
+- Si audité et auditeur consentent, possibilité de ré-assigner même binôme
+- Avantage : auditeur connaît déjà le contexte
+- Rotation tous les 3 cycles recommandée (éviter complaisance)
+**Délai recommandé :**
+Démarrer le processus 90 jours avant expiration (marge confortable).
+**Recertification tardive :**
+- Possible jusqu'à 30 jours après expiration (label révoqué mais processus simplifié)
+- Au-delà de 30 jours → Audit complet requis (comme nouveau label)
+---
+### 4.4 Amélioration de Niveau
+**Membre peut demander audit pour niveau supérieur à tout moment :**
+**Conditions :**
+- Délai minimum : 6 mois après dernier audit
+- Auto-évaluation préliminaire montrant éligibilité au niveau supérieur
+- Cotisation à jour
+**Processus :**
+Identique à audit initial (même si label valide).
+**Si échec :**
+- Label actuel conservé jusqu'à expiration normale
+- Possibilité de ré-essayer après 6 mois
+**Incitation :**
+- Pas de pénalité financière (inclus dans cotisation)
+- Reconnaissance publique si passage Or → Platine
+---
+## SECTION 5 : USAGE DU LABEL
+### 5.1 Droits d'Usage
+**Membre labellisé peut :**
+✅ Afficher le badge sur :
+- Site web (page d'accueil, footer)
+- Signatures email professionnelles
+- Profils réseaux sociaux (LinkedIn, Mastodon, etc.)
+- Matériel de communication (brochures, présentations)
+✅ Mentionner le label dans :
+- Propositions commerciales
+- Appels d'offres (preuve de conformité)
+- Communications publiques (articles, conférences)
+✅ Utiliser la phrase :
+> *"[Nom Membre] est membre certifié de L'Alliance Boréale avec un label [Niveau]."*
+---
+### 5.2 Obligations d'Usage
+**Membre labellisé doit :**
+❌ NE PAS altérer le badge (couleurs, proportions, texte)
+❌ NE PAS utiliser un niveau non attribué (ex: afficher Or si Argent)
+❌ NE PAS utiliser le badge après expiration
+❌ NE PAS faire de déclarations mensongères sur le score
+✅ Retirer le badge immédiatement si :
+- Label expiré sans renouvellement
+- Label révoqué (suspension, radiation)
+- Demande du Cercle Éthique (abus constaté)
+✅ Lier le badge au Registraire public (URL de vérification)
+**URL de vérification :**
+`https://registraire.alliance-boreale.ca/membres/[ID]/label`
+**Exemple :**
+```html
+<a href="https://registraire.alliance-boreale.ca/membres/m001/label">
+  <img src="badge-alliance-boreale-or.svg" alt="Label Or - Alliance Boréale" />
+</a>
+```
+---
+### 5.3 Surveillance et Sanctions
+**Surveillance :**
+- Audit aléatoire d'usage (Cercle Éthique, 2x/an)
+- Signalement par membres ou public (formulaire web)
+**Abus typiques :**
+- Badge affiché après expiration
+- Badge altéré (couleurs, texte)
+- Déclaration niveau supérieur (afficher Platine si Or)
+- Usage commercial trompeur (ex: "Certifié ISO 27001" si seulement label Bronze)
+**Sanctions :**
+**Abus mineur (non intentionnel) :**
+- Avertissement écrit
+- Correction sous 7 jours
+- Aucune autre conséquence
+**Abus majeur (intentionnel ou répété) :**
+- Suspension du label (3-6 (Virtualisation, Orchestration, Supervision, Services) mois)
+- Interdiction de demander label durant suspension
+- Possible radiation (si gravité extrême)
+**Procédure :**
+Contradictoire (voir Document 2, Section 4.6 - Suspension).
+---
+## SECTION 6 : RÉVOCATION DU LABEL
+### 6.1 Motifs de Révocation
+**Le label peut être révoqué dans les cas suivants :**
+**1. Non-conformité majeure découverte après attribution**
+- Fraude dans les preuves (preuves falsifiées)
+- Incident de sécurité grave non déclaré révélant manquements systémiques
+- Violation grave des 5 valeurs cardinales
+**2. Suspension du membre**
+- Suspension administrative → révocation automatique du label
+- Rétablissement possible après levée de suspension + réaudit
+**3. Dégradation avérée de la conformité**
+- Monitoring partagé détecte disponibilité < 95% (domaine 1)
+- Scan SSL Labs montre dégradation (domaine 2)
+- Signalements répétés d'utilisateurs (domaine 3, 4)
+**4. Abus d'usage du label**
+- Voir Section 5.3
+**5. Demande volontaire du membre**
+- Membre peut renoncer à son label (sans pénalité)
+- Utile si le membre sait qu'il ne respecte plus les critères
+---
+### 6.2 Procédure de Révocation
+**Garanties :**
+1. **Enquête préalable** (Cercle Éthique)
+   - Collecte de preuves (monitoring, rapports, témoignages)
+   - Vérification des faits
+2. **Notification au membre** (14 jours pour répondre)
+   - Motifs précis de la révocation envisagée
+   - Preuves fournies
+   - Droit de défense
+3. **Défense du membre**
+   - Réponse écrite (max 5 pages)
+   - Audition possible (si demandée, Cercle Éthique)
+   - Apport de contre-preuves
+4. **Décision** (Cercle Éthique, consentement renforcé)
+   - Révocation confirmée OU
+   - Révocation abandonnée (si défense convaincante) OU
+   - Avertissement (si gravité moindre)
+5. **Notification de la décision** (motivée par écrit)
+   - Membre informé sous 7 jours
+   - Publication résumé anonymisé au Registraire (transparence)
+**Délai total :** Maximum 45 jours.
+---
+### 6.3 Conséquences de la Révocation
+**Immédiates :**
+- Badge retiré du Registraire
+- Membre doit cesser usage du badge (7 jours)
+- Notification aux autres membres (Matrix, interne)
+**Long terme :**
+- Membre peut redemander label après correction (délai 6 mois minimum)
+- Audit complet requis (pas de simplification)
+- Historique de révocation documenté (mais pas publié)
+**Aucune exclusion de L'Alliance** (sauf si radiation pour autre motif).
+---
+## SECTION 7 : ÉVOLUTION DU CADRE DE CONFORMITÉ
+### 7.1 Révision Annuelle
+**Obligation :** Le Cercle Éthique révise ce document chaque année (Q4).
+**Objectifs :**
+- Ajuster critères (retours d'expérience auditeurs/audités)
+- Ajouter/supprimer critères (évolution technologique)
+- Clarifier ambiguïtés (interprétations divergentes)
+- Mettre à jour grilles de notation
+**Processus :**
+1. Collecte feedback (auditeurs, audités, membres)
+2. Analyse des scores (domaines trop faciles/difficiles ?)
+3. Propositions d'amendements (Cercle Éthique)
+4. Consultation publique (30 jours, tous les membres)
+5. Amendements finalisés (consentement Cercle Éthique)
+6. Validation Cercle Stratégique (si changements majeurs)
+**Entrée en vigueur :** 1er janvier de l'année suivante (prévisibilité).
+---
+### 7.2 Amendements Hors Cycle
+**Possibles si nécessité urgente :**
+- Nouvelle loi (ex: Loi 25 amendée)
+- Vulnérabilité critique découverte (ex: Log4Shell → ajout critère patches < 48h)
+- Incohérence grave détectée
+**Processus accéléré :**
+- Consultation 14 jours (au lieu de 30)
+- Décision Cercle Éthique (consentement)
+- Entrée en vigueur immédiate ou différée (selon urgence)
+**Notification :**
+- Tous les membres alertés (email + Matrix)
+- Membres labellisés : évaluation si critères nouveaux les affectent
+---
+### 7.3 Transition entre Versions
+**Principe : Pas de pénalisation rétroactive.**
+**Scénario 1 : Critères durcis**
+- Labels déjà attribués restent valides jusqu'à expiration
+- Renouvellement : nouveaux critères appliqués
+- Délai de grâce : 6 mois pour s'adapter
+**Scénario 2 : Critères assouplis**
+- Labels existants conservés
+- Membres peuvent demander réévaluation immédiate (si score amélioré)
+**Scénario 3 : Nouveau domaine ajouté**
+- Labels existants : domaine noté 0 (pas pénalisant pour durée restante)
+- Renouvellement : nouveau domaine obligatoire
+**Exemple concret (version hypothétique 2.0 en 2027) :**
+Version 1.0 (2025) : 6 domaines
+Version 2.0 (2027) : 7 domaines (ajout "Accessibilité Numérique")
+→ Membre labellisé Or en 2026 (version 1.0) conserve son Or jusqu'à expiration 2027.
+→ Renouvellement 2027 : audit sur 7 domaines, score Accessibilité doit être ≥ 75 pour garder Or.
+---
+## SECTION 8 : GOUVERNANCE DU LABEL
+### 8.1 Rôle du Cercle Éthique & Conformité
+**Responsabilités exclusives :**
+- Gestion des audits (désignation auditeurs, validation rapports)
+- Attribution/révocation des labels (décision finale)
+- Résolution des recours (médiation, arbitrage)
+- Évolution du cadre (amendements annuels)
+- Formation des auditeurs (ateliers, certifications)
+**Le Cercle Éthique ne fait PAS :**
+- Audits techniques détaillés (délégué aux auditeurs pairs)
+- Décisions stratégiques (Cercle Stratégique)
+- Gestion infrastructure (Cercle Opérationnel)
+---
+### 8.2 Transparence et Redevabilité
+**Données publiques (Registraire) :**
+- Liste des membres labellisés (niveau, score global, date)
+- Scores par domaine (agrégés ou détaillés, selon choix membre)
+- Historique des labels (timelines)
+**Données privées (Cercle Éthique) :**
+- Rapports d'audit complets (sauf synthèse publique)
+- Preuves techniques (configurations, logs)
+- Médiations et recours (sauf décision finale)
+**Rapport annuel (Cercle Éthique) :**
+- Nombre d'audits réalisés
+- Distribution des niveaux (combien Bronze/Argent/Or/Platine)
+- Domaines les plus forts/faibles (statistiques agrégées)
+- Évolutions année/année
+- Révocations (nombre, motifs anonymisés)
+**Publication :** Registraire, section `/rapports/label/YYYY.md`
+---
+### 8.3 Financement et Ressources
+**Coûts du label :**
+- Aucun pour les membres (inclus dans cotisation annuelle)
+- Temps auditeurs valorisé via banque de temps (crédits)
+**Budget alloué :**
+- Formation auditeurs (matériel pédagogique, ateliers)
+- Outils de suivi (plateforme d'audit, si développée)
+- Badges physiques (impression, envoi)
+**Estimation :** 5-10% du budget annuel de L'Alliance.
+---
+## CONCLUSION
+Le Label de Prestige de L'Alliance Boréale n'est pas un gadget marketing.
+**C'est un outil de transformation collective.**
+En rendant visibles nos pratiques, en célébrant l'excellence, et en accompagnant l'amélioration continue, le label incarne nos valeurs :
+- **Souveraineté** : Audit pair-à-pair, pas de dépendance à un tiers certificateur
+- **Liberté** : Labellisation volontaire, critères transparents et évolutifs
+- **Sobriété** : Domaine 6 dédié, mesure et réduction de l'empreinte
+- **Solidarité** : Auditeurs pairs, apprentissage mutuel, banque de temps
+- **Transparence** : Scores publics, processus documenté, recours possibles
+**Le label évolue avec nous.**
+Chaque année, nous apprenons. Chaque audit, nous progressons. Chaque membre labellisé, nous renforçons la crédibilité de L'Alliance.
+**Le label n'est pas une fin. C'est un moyen.**
+Le moyen de nous tenir mutuellement responsables. Le moyen de montrer au monde qu'un autre numérique est possible. Le moyen de transformer nos valeurs en pratiques concrètes, mesurables, vérifiables.
+**Bienvenue dans la forêt labellisée.** 🌲
+---
+## ANNEXES
+### Annexe A : Checklist Rapide par Niveau
+#### Pour Bronze (Score global ≥ 50, chaque domaine ≥ 40)
+**Prioriser :**
+- ✅ Critères obligatoires (60 pts/domaine)
+- ✅ Disponibilité > 99%
+- ✅ TLS 1.2+, MFA admin
+- ✅ Backups testés
+- ✅ Documentation de base
+- ✅ Mesure consommation énergétique
+**Suffisant pour Bronze.**
+---
+#### Pour Argent (Score global ≥ 65, chaque domaine ≥ 60)
+**Ajouter :**
+- ✅ 50% des critères recommandés
+- ✅ Disponibilité > 99.5%
+- ✅ IaC ≥ 50%
+- ✅ Contribution à projet libre
+- ✅ Post-mortems publiés
+**Maturité opérationnelle démontrée.**
+---
+#### Pour Or (Score global ≥ 80, chaque domaine ≥ 75)
+**Ajouter :**
+- ✅ 75% des critères recommandés
+- ✅ Quelques critères d'excellence
+- ✅ Contribution significative L'Alliance
+- ✅ Disponibilité > 99.9%
+- ✅ Audit externe annuel (sécurité)
+**Excellence technique et éthique.**
+---
+#### Pour Platine (Score global ≥ 90, chaque domaine ≥ 85)
+**Ajouter :**
+- ✅ 90% des critères recommandés
+- ✅ Majorité critères d'excellence
+- ✅ Contributions majeures multiples
+- ✅ Zéro incident P0 (12 mois)
+- ✅ Innovation partagée (publication, conférences)
+**Modèle inspirant.**
+---
+### Annexe B : Templates de Documents
+#### B.1 Demande de Labellisation
+```yaml
+demande_label:
+  membre_id: m001-exemple
+  date_demande: 2025-10-23
+  niveau_cible: argent
+  contact:
+    nom: "Jean Dupont"
+    email: "jean@exemple.ca"
+    telephone: "+1-514-555-0100"
+  auto_evaluation:
+    domaine_1: 70  # Infrastructure
+    domaine_2: 75  # Sécurité
+    domaine_3: 65  # Interopérabilité
+    domaine_4: 80  # Logiciels Libres
+    domaine_5: 60  # Opérations
+    domaine_6: 55  # Sobriété
+    score_global: 67.5
+  motivation: |
+    Nous souhaitons obtenir le label Argent pour démontrer notre maturité
+    opérationnelle et notre alignement avec les valeurs de L'Alliance.
+    Nous avons investi 6 mois dans l'amélioration de notre documentation
+    et de notre infrastructure.
+  disponibilites_audit:
+    - "2025-11-01 to 2025-11-30"
+    - "2025-12-01 to 2025-12-15"
+```
+---
+#### B.2 Rapport d'Audit (Structure Minimale)
+```markdown
+# Rapport d'Audit — Label Alliance Boréale
+## Informations Générales
+- **Audité** : [Nom Membre] (ID: mXXX)
+- **Auditeur** : [Nom Auditeur] (ID: mYYY)
+- **Date audit** : YYYY-MM-DD à YYYY-MM-DD
+- **Version cadre** : 1.0
+## Synthèse Exécutive
+**Niveau demandé** : Argent
+**Niveau obtenu** : Argent
+**Score global** : 67.5/100
+| Domaine | Score | Seuil | Statut |
+|---------|-------|-------|--------|
+| Infrastructure | 70 | 60 | ✅ |
+| Sécurité | 75 | 60 | ✅ |
+| Interopérabilité | 65 | 60 | ✅ |
+| Logiciels Libres | 80 | 60 | ✅ |
+| Opérations | 60 | 60 | ✅ |
+| Sobriété | 55 | 60 | ❌ |
+**Points forts** :
+- Excellente conformité logiciels libres (80%)
+- Sécurité solide (MFA, TLS 1.3, patches rapides)
+- Documentation claire et à jour
+**Points d'amélioration** :
+- Sobriété numérique (55) sous le seuil Argent (60)
+- IaC incomplet (40% de l'infra seulement)
+- Monitoring externe absent
+## [Sections détaillées par domaine...]
+## Conclusion
+Le membre XXX démontre une bonne maturité opérationnelle. Le niveau Argent est mérité sous réserve de correction du domaine 6 (Sobriété) dans les 6 mois.
+**Signature électronique** : [Auditeur], [Date]
+```
+---
+### Annexe C : Calendrier Type d'Audit
+```
+Semaine 0 : Demande labellisation
+Semaine 1 : Désignation auditeur + kick-off
+Semaines 2-4 (Réseau, Virtualisation, Orchestration) : Collecte preuves (audité prépare, auditeur révise)
+Semaine 5 : Évaluation + notation (auditeur)
+Semaine 5-6 (Supervision, Services) : Rédaction rapport
+Semaine 6 : Révision par audité (7 jours)
+Semaine 7 : Validation Cercle Éthique
+Semaine 8 : Attribution label + communication
+Total : ~8 semaines (2 mois)
+```
+**Version accélérée (recertification, si simplifié) : 4-5 (Orchestration, Supervision) semaines**
+---
+## MÉTADONNÉES
+**Document :** 03_Cadre_Conformite_Label_Prestige.md
+**Version :** 1.0
+**Date de création :** 23 octobre 2025
+**Auteur :** Claude (profils #10 Sécurité, #11 Gouvernance, #12 Documentaliste)
+**Révision par :** Cercle Éthique & Conformité
+**Statut :** À adopter par Cercle Stratégique
+**Longueur :** ~14 000 mots (28 pages avec grilles détaillées)
+**Licence :** CC BY-SA 4.0
+**Sources utilisées :**
+- `00_Glossaire_et_Definitions.md`
+- `01_Charte_Fondatrice_v2_1.md`
+- `02_Reglement_de_Regie_Interne.md`
+- `devis_alliance_boreale_v2.md`
+**Prochaine révision prévue :** Octobre 2026 (Q4, annuelle)
+---
+**Changelog :**
+- 2025-10-23 v1.0 : Création initiale du Cadre de Conformité et Label
+---
+**FIN DU CADRE DE CONFORMITÉ ET LABEL DE PRESTIGE**
+*"Le label n'est pas une médaille à accrocher. C'est un miroir qui nous montre qui nous sommes vraiment."*
+🌲 **L'Alliance Boréale**
+*Excellence mesurée, amélioration continue, transparence totale.*
+ 
diff --git a/docs/20-rag/devis(2).md b/docs/20-rag/devis(2).md
new file mode 100644
index 0000000..c7873dc
--- /dev/null
+++ b/docs/20-rag/devis(2).md
@@ -0,0 +1,1782 @@
+# L'Alliance Boréale — Devis Documentaire Révisé
+## Blueprint et Table des Matières
+
+**Version:** 2.0  
+**Date:** 22 octobre 2025  
+**Statut:** Devis pour validation
+
+---
+
+## 📋 VUE D'ENSEMBLE
+
+Cet ensemble constitutif comprend **16 documents** organisés en **5 catégories** :
+
+### Catégorie 0 : Base Commune (1 doc)
+### Catégorie 1 : Documents Fondateurs (4 docs)
+### Catégorie 2 : Documents Opérationnels (5 docs)
+### Catégorie 3 : Documents Légaux (3 docs)
+### Catégorie 4 : Outils de Pilotage (3 docs)
+
+**Estimation totale :** 130-160 pages
+
+---
+
+# CATÉGORIE 0 : BASE COMMUNE
+
+## Document 0 : Glossaire et Définitions
+**Longueur estimée :** 6-8 pages
+
+### Objectif :
+Établir un langage commun et éviter toute ambiguïté terminologique dans l'ensemble de la documentation.
+
+### Table des matières :
+
+1. Termes juridiques et organisationnels
+   - OBNL (Organisme à but non lucratif)
+   - Fédération libre
+   - Coopérative
+   - Gouvernance sociocratique
+   - Consentement (vs consensus vs unanimité)
+   - Cercle
+   - Représentant-lien
+   - Objection valide
+
+2. Termes techniques
+   - DNS autoritaire
+   - Fédération DNS
+   - Zone déléguée
+   - AXFR (transfert de zone)
+   - DNSSEC
+   - Interopérabilité
+   - Protocole ouvert
+   - Single Sign-On (SSO)
+   - Infrastructure fédérée
+
+3. Termes liés au label
+   - Conformité
+   - Audit pair-Ã -pair
+   - Label de prestige
+   - Non-conformité majeure vs mineure
+   - Période probatoire
+   - Certification vs labellisation
+
+4. Termes économiques
+   - Cotisation
+   - Banque de temps
+   - Crédit mutuel
+   - Contributeur net vs consommateur net
+   - Soutenabilité financière
+
+5. Valeurs et philosophie
+   - Souveraineté numérique
+   - Sobriété numérique
+   - Sobriété heureuse
+   - Autopoïèse
+   - Subsidiarité
+   - Transparence utile (vs transparence radicale)
+
+6. Rôles et acteurs
+   - Membre fondateur
+   - Membre actif
+   - Membre en probation
+   - Parrain (sponsor)
+   - Auditeur
+   - Cercle des Référents Boréaux
+
+---
+
+# CATÉGORIE 1 : DOCUMENTS FONDATEURS
+
+## Document 1 : Charte Fondatrice de L'Alliance Boréale
+**Longueur estimée :** 10-12 pages
+
+### Table des matières :
+
+1. Préambule — Vision fondatrice
+   - Le constat : centralisation, dépendance, perte de confiance
+   - Notre réponse : coopération distribuée
+   - Métaphore : "Nous ne bâtissons pas un empire. Nous entretenons une forêt."
+
+2. Article 1 — Nature et identité
+   - Définition juridique (fédération libre, évolutive vers OBNL)
+   - Valeurs cardinales (souveraineté, liberté, sobriété, solidarité, transparence)
+   - Principes opérationnels
+
+3. Article 2 — Mission et objectifs
+   - Faciliter l'interopérabilité technique entre membres
+   - Établir un label de conformité et de prestige
+   - Mettre en commun des outils (forges, DNS, monitoring)
+   - Garantir une gouvernance durable et éthique
+
+4. Article 3 — Territoire et portée
+   - Géographique : acteurs du Nord (Québec, Canada, régions nordiques)
+   - Sectoriel : hébergeurs, coopératives tech, organisations éthiques
+   - Échelle : croissance organique, de quelques membres à plusieurs dizaines
+
+5. Article 4 — Philosophie d'intervention
+   - Principe de subsidiarité (autonomie locale d'abord)
+   - Légèreté et facilitation (pas de bureaucratie)
+   - Intervention minimale de l'Alliance
+   - Préservation de la souveraineté des membres
+
+6. Annexes
+   - Références philosophiques (autopoïèse, sobriété heureuse, fédéralisme)
+   - Historique de fondation
+   - Signataires fondateurs
+
+---
+
+## Document 2 : Règlement de Régie Interne
+**Longueur estimée :** 20-24 pages
+
+### Table des matières :
+
+1. Structure de gouvernance sociocratique
+
+   1.1 Cercle Stratégique
+   - Composition : tous les membres permanents
+   - Mandat : vision, orientation stratégique, admission nouveaux membres
+   - Durée des mandats : 12 mois renouvelable
+   - Mode de décision : consentement sociocratique
+   - Fréquence : réunions trimestrielles + extraordinaires
+
+   1.2 Cercle Opérationnel
+   - Composition : membres techniques désignés (3-7 personnes)
+   - Mandat : coordination technique, infrastructure partagée, outils communs
+   - Durée des mandats : 6 mois, rotation
+   - Mode de décision : consentement avec fallback vote majoritaire
+   - Fréquence : réunions mensuelles
+
+   1.3 Cercle Éthique & Conformité
+   - Composition : membres élus (3-5 personnes)
+   - Mandat : gestion du label, audits, arbitrages, communication publique
+   - Durée des mandats : 24 mois, non consécutifs
+   - Mode de décision : consentement renforcé
+   - Fréquence : réunions bimensuelles
+
+   1.4 Représentants-liens
+   - Rôle et responsabilités
+   - Élection et rotation
+   - Communication entre cercles
+
+2. Cercle des Référents Boréaux (phase transitoire 2025-2027)
+   - Composition initiale : membres fondateurs
+   - Rôle d'arbitrage final durant la phase pilote
+   - Conditions de dissolution
+   - Transition vers gouvernance pleine
+
+3. Processus de prise de décision
+
+   3.1 Consentement sociocratique (mode par défaut)
+   - Définition : absence d'objection raisonnée et argumentée
+   - Processus en 3 tours (clarification, réactions, objections)
+   - Critères d'objection valide
+   - Documentation systématique des décisions
+
+   3.2 Fallback : Vote majoritaire
+   - Conditions de déclenchement (blocage ≥ 14 jours)
+   - Procédure de vote
+   - Quorum requis (2/3 des membres actifs)
+
+   3.3 Escalade vers cercle supérieur
+   - Cas d'égalité persistante
+   - Processus formel d'escalade
+   - Délais et exigences de transparence
+
+4. Cycle de vie des membres
+
+   4.1 Critères d'admissibilité
+   - Acteur du numérique éthique
+   - Alignement avec les valeurs de la Charte
+   - Capacité technique minimale
+   - Volonté de participer activement
+
+   4.2 Processus de candidature
+   - Lettre d'intention
+   - Entretien avec le Cercle Stratégique
+   - Présentation du projet technique
+   - Parrainage par un membre existant (après phase fondatrice)
+   - Vote d'admission (unanimité requise en phase pilote)
+
+   4.3 Phase probatoire (3 mois)
+   - Objectifs à atteindre
+   - Services minimaux à déployer
+   - Engagement de disponibilité (>99%)
+   - Participation active aux échanges
+   - Évaluation pair-à -pair
+
+   4.4 Statut de membre actif
+   - Droits (vote, accès outils, support communautaire)
+   - Responsabilités (cotisation, participation, conformité)
+   - Obligations continues
+
+   4.5 Demande de labellisation
+   - Processus de demande volontaire
+   - Audit par pairs
+   - Attribution du niveau (Bronze → Platine)
+   - Durée de validité : 12 mois
+   - Processus de recertification
+
+   4.6 Suspension temporaire
+   - Motifs (non-conformité majeure, incident grave non déclaré)
+   - Procédure contradictoire
+   - Durée et conditions de levée
+
+   4.7 Retrait volontaire
+   - Préavis requis (30 jours)
+   - Obligations de transition
+   - Restitution des ressources communes
+
+   4.8 Radiation (cas extrêmes)
+   - Motifs graves justifiant l'exclusion
+   - Procédure (consentement renforcé du Cercle Éthique)
+   - Effets immédiats et conséquences
+
+5. Communication et transparence
+
+   - Registraire public (métadonnées des membres)
+   - Documentation obligatoire (décisions, audits)
+   - Outils de communication (Matrix, forge, wiki)
+   - Langue officielle : français (traductions bienvenues)
+
+6. Révision du règlement
+
+   - Périodicité : revue annuelle obligatoire
+   - Processus d'amendement
+   - Période de discussion publique (14 jours minimum)
+   - Entrée en vigueur (6 mois après adoption)
+
+---
+
+## Document 3 : Cadre de Conformité et Label de Prestige
+**Longueur estimée :** 16-20 pages
+
+### Table des matières :
+
+1. Principes directeurs du label
+
+   - Alignement de valeurs (pas seulement technique)
+   - Preuve par l'évidence (pas de déclarations gratuites)
+   - Proportionnalité (adapter aux moyens de chaque membre)
+   - Évaluation par les pairs (pas d'auditeur externe)
+   - Transparence utile (publier ce qui compte)
+
+2. Périmètre de conformité (6 domaines)
+
+   2.1 Gouvernance & Éthique
+   - Charte interne signée et publiée
+   - Registre public des responsabilités
+   - Politique formelle de conflits d'intérêts
+   - Documentation des décisions stratégiques
+   - Transparence financière (si pertinent)
+   - **Indicateurs :** 0-5 points
+
+   2.2 Sécurité de l'Information
+   - Politique de gestion des vulnérabilités (SLA correctifs)
+   - Authentification multi-facteurs (MFA) pour tous les comptes admin
+   - Stratégie de sauvegarde 3-2-1 testée régulièrement
+   - Processus de réponse à incident documenté
+   - Chiffrement des données sensibles au repos
+   - **Indicateurs :** 0-5 points
+
+   2.3 Vie Privée & Conformité Légale
+   - Registre des activités de traitement (Loi 25 / RGPD)
+   - Base légale explicite pour chaque traitement
+   - Évaluation d'impact (DPIA) si nécessaire
+   - Politiques claires de rétention et suppression
+   - Respect des droits des personnes (accès, rectification, suppression)
+   - **Indicateurs :** 0-5 points
+
+   2.4 Interopérabilité & Fédération
+   - Support des identités fédérées (Keycloak, OpenID, SAML)
+   - Courriel selon standards ouverts (SMTP, IMAP, S/MIME ou PGP optionnel)
+   - Partage de fichiers via protocoles ouverts (WebDAV, SFTP, etc.)
+   - Visioconférence compatible standards (SIP, Jitsi, etc.)
+   - Publication des métadonnées de fédération
+   - **Indicateurs :** 0-5 points
+
+   2.5 Opérations & Résilience
+   - Monitoring actif des services critiques
+   - Conservation des journaux ≥ 90 jours
+   - Gestion de la capacité et de la disponibilité
+   - Runbooks et documentation technique à jour
+   - Tests de restauration trimestriels réussis
+   - **Indicateurs :** 0-5 points
+
+   2.6 Sobriété Numérique
+   - Mesure de la consommation (énergie, bande passante, stockage)
+   - Stratégies d'optimisation (mise en veille, délestage)
+   - Choix privilégiant les solutions frugales
+   - Publication volontaire des indicateurs par service
+   - Amélioration continue mesurable
+   - **Indicateurs :** 0-5 points
+
+3. Système de notation et pondération
+
+   - Échelle de notation : 0 à 5 par domaine
+   - Pondération équilibrée (tous domaines égaux par défaut)
+   - Calcul du score global (/100)
+   - Seuils d'attribution par niveau de label
+
+4. Niveaux de label
+
+   4.1 Boréal Bronze (Conforme)
+   - **Critères :** Minima atteints sur les 6 domaines
+   - **Score minimum :** 60/100
+   - **Exigence :** Aucune non-conformité majeure
+   - **Validité :** 12 mois
+   - Badge et visuels fournis
+
+   4.2 Boréal Argent (Solide)
+   - **Critères :** Bronze + score ≥ 72/100
+   - Audit pair semestriel sans réserve majeure
+   - Transparence renforcée (page status publique)
+   - **Validité :** 12 mois
+
+   4.3 Boréal Or (Référence)
+   - **Critères :** Argent + score ≥ 85/100
+   - Exercices de simulation de crise annuels
+   - Publication volontaire des indicateurs de sobriété
+   - Tests de restauration réussis (12 derniers mois)
+   - **Validité :** 12 mois
+
+   4.4 Boréal Platine (Excellence)
+   - **Critères :** Or + amélioration continue démontrée
+   - Plan de continuité d'affaires documenté et testé
+   - Chiffrement bout-à -bout où pertinent
+   - Preuves tierces (pentest annuel partagé avec pairs)
+   - **Validité :** 12 mois
+
+5. Processus d'évaluation et d'audit
+
+   - Auto-évaluation initiale (questionnaire structuré)
+   - Revue documentaire par un pair désigné
+   - Audit technique pair-Ã -pair (sur site ou virtuel)
+   - Rapport d'audit avec recommandations
+   - Décision finale du Cercle Éthique & Conformité
+
+6. Surveillance continue et recertification
+
+   - Obligation de déclaration des incidents majeurs
+   - Revue semestrielle légère (auto-évaluation)
+   - Audits surprises possibles (si suspicion fondée)
+   - Ajustement du label si dégradation constatée
+   - Processus de recertification avant expiration
+
+7. Règles d'usage du label
+
+   - Droit d'usage strictement personnel
+   - Format : "Boréal [Niveau] [Année]"
+   - Prohibitions (usage commercial trompeur, transfert)
+   - Kit graphique officiel fourni
+   - Référencement obligatoire au Registraire
+
+8. Annexes
+
+   - Grille d'auto-évaluation détaillée (6 domaines)
+   - Modèle de résolution interne pour usage du label
+   - Exemples de preuves acceptables par domaine
+
+---
+
+## Document 4 : Manifeste Philosophique — L'Esprit Boréal
+**Longueur estimée :** 8-10 pages
+
+### Table des matières :
+
+1. Nos racines intellectuelles
+
+   - Ivan Illich : convivialité et outils conviviaux
+   - Pierre Rabhi : sobriété heureuse
+   - Humberto Maturana : autopoïèse et autonomie
+   - Elinor Ostrom : gestion des communs
+   - Principe de subsidiarité (fédéralisme)
+
+2. Pourquoi "Boréal" ?
+
+   - Le Nord comme espace de résilience
+   - Métaphore de la forêt boréale (résilience, interconnexion, lenteur)
+   - Ancrage géographique et culturel (Québec, Canada)
+
+3. Sobriété heureuse appliquée au numérique
+
+   - Refus de la croissance pour la croissance
+   - Optimiser pour la durabilité, pas la performance maximale
+   - Technologie au service de l'humain, pas l'inverse
+   - Mesure et réduction de l'empreinte numérique
+
+4. Autopoïèse organisationnelle
+
+   - Un système qui se maintient et se régénère lui-même
+   - Transmission du savoir comme mécanisme de perpétuation
+   - Documentation vivante et évolutive
+   - Gouvernance adaptative
+
+5. Souveraineté sans isolement
+
+   - Autonomie locale ET coopération fédérée
+   - Refus de la dépendance aux GAFAM
+   - Interopérabilité comme vecteur de liberté
+   - Solidarité entre pairs
+
+6. Transparence utile vs transparence radicale
+
+   - Publier ce qui compte pour la confiance
+   - Protéger ce qui relève de l'intimité technique
+   - Équilibre entre ouverture et pragmatisme
+
+7. La forêt, pas l'empire
+
+   - Croissance organique vs expansion agressive
+   - Diversité des acteurs comme force
+   - Résilience par la décentralisation
+   - Longévité plutôt que vitesse
+
+8. Nos engagements pour les générations futures
+
+   - Laisser un système transmissible
+   - Former plutôt que vendre
+   - Documenter pour permettre la relève
+   - Refuser l'obsolescence programmée
+
+---
+
+# CATÉGORIE 2 : DOCUMENTS OPÉRATIONNELS
+
+## Document 5 : Charte de Fédération DNS
+**Longueur estimée :** 10-12 pages
+
+### Table des matières :
+
+1. Principes de la fédération DNS
+
+   - Autonomie locale (chaque membre gère ses propres zones)
+   - Résilience par la redondance (DNS secondaires mutuels)
+   - Standards ouverts (RFC DNS, DNSSEC)
+   - Confiance vérifiable (DNSSEC obligatoire pour services critiques)
+
+2. Architecture DNS distribuée
+
+   - Serveurs DNS autoritaires (chaque membre héberge le sien)
+   - Relations primaire/secondaire (AXFR entre pairs)
+   - Stratégies de délégation de zones
+   - Topologie recommandée (triangulation minimale)
+
+3. Standards techniques obligatoires
+
+   - PowerDNS (ou équivalent respectant les RFCs)
+   - DNSSEC activé pour zones critiques
+   - AXFR sécurisé (ACL strictes, TSIG ou équivalent)
+   - Notifications (NOTIFY) fonctionnelles
+   - TTL raisonnables (équilibre cache/réactivité)
+
+4. Processus de délégation et enregistrement
+
+   - Demande de délégation de sous-zone
+   - Vérification de conformité technique
+   - Enregistrement au Registraire
+   - Propagation et tests
+
+5. Niveaux de service DNS
+
+   - Disponibilité cible (>99,5% pour membres actifs)
+   - Temps de réponse acceptable
+   - Maintenance planifiée (notification 48h)
+   - Gestion des incidents DNS
+
+6. Sécurité et gestion des incidents
+
+   - Protection contre DDoS (rate limiting, ACL)
+   - Détection d'anomalies (monitoring)
+   - Réponse à incident (escalade, communication)
+   - Post-mortem obligatoire pour panne >1h
+
+7. Outils et monitoring mutualisés
+
+   - Tableau de bord partagé (état des DNS membres)
+   - Alerting inter-pairs
+   - Tests automatisés (DNS probes)
+
+8. Retrait et transition
+
+   - Procédure de retrait propre
+   - Délais de préavis (14 jours pour DNS)
+   - Migration des zones déléguées
+   - Archivage des configurations
+
+---
+
+## Document 6 : Standards d'Interopérabilité Technique
+**Longueur estimée :** 12-14 pages
+
+### Table des matières :
+
+1. Philosophie de l'interopérabilité
+
+   - Protocoles ouverts avant tout
+   - Préférence pour standards matures (RFCs, W3C)
+   - Éviter les silos technologiques
+   - Faciliter la migration des utilisateurs
+
+2. Identité fédérée (Single Sign-On)
+
+   2.1 Standards requis
+   - OpenID Connect (recommandé)
+   - SAML 2.0 (accepté)
+   - OAuth 2.0 pour APIs
+
+   2.2 Implémentations recommandées
+   - Keycloak (préféré)
+   - Authelia, Authentik (acceptés)
+   - Publication des métadonnées de fédération
+
+   2.3 Attributs minimaux échangés
+   - Identifiant unique
+   - Email de contact
+   - Nom d'affichage
+   - Groupes/rôles (optionnel)
+
+3. Courriel
+
+   3.1 Standards obligatoires
+   - SMTP, IMAP/POP3
+   - DKIM, SPF, DMARC
+   - TLS pour transport (STARTTLS)
+
+   3.2 Fonctionnalités recommandées
+   - Support S/MIME ou PGP (chiffrement bout-Ã -bout)
+   - Antispam collaboratif
+   - Listes de diffusion (Mailman, Sympa)
+
+4. Partage de fichiers et collaboration
+
+   4.1 Protocoles ouverts
+   - WebDAV (CalDAV, CardDAV)
+   - SFTP/SCP
+   - rsync pour synchronisation
+
+   4.2 Solutions recommandées
+   - Nextcloud (préféré)
+   - Seafile, ownCloud (acceptés)
+   - Partage public via liens sécurisés
+
+5. Visioconférence
+
+   5.1 Standards et protocoles
+   - Jitsi Meet (recommandé)
+   - SIP/RTP pour interopérabilité
+   - WebRTC
+
+   5.2 Exigences
+   - Hébergement local (pas de relais cloud propriétaire)
+   - Chiffrement bout-Ã -bout optionnel
+   - Enregistrement possible (avec consentement)
+
+6. Messagerie instantanée
+
+   6.1 Protocole requis
+   - Matrix (protocole fédéré)
+
+   6.2 Implémentation
+   - Synapse (serveur de référence)
+   - Bridges optionnels (IRC, XMPP, Signal)
+   - Chiffrement E2E (Olm/Megolm)
+
+7. Forge logicielle et gestion de projets
+
+   7.1 Solutions recommandées
+   - Forgejo / Gitea (préférés)
+   - GitLab CE (accepté)
+
+   7.2 Interopérabilité
+   - Git comme base (push/pull inter-forges)
+   - APIs REST documentées
+   - Webhooks pour CI/CD
+
+8. Monitoring et observabilité
+
+   8.1 Métriques partagées
+   - Prometheus + Grafana (recommandé)
+   - Export de métriques standardisées
+
+   8.2 Logs centralisés (optionnel)
+   - Formats structurés (JSON)
+   - Respect de la vie privée (anonymisation)
+
+9. Exceptions et évolutions
+
+   - Processus de dérogation (justification requise)
+   - Revue annuelle des standards
+   - Intégration de nouveaux protocoles
+
+---
+
+## Document 7 : Règlement de la Banque de Temps
+**Longueur estimée :** 8-10 pages
+
+### Table des matières :
+
+1. Philosophie de la banque de temps
+
+   - Économie de la réciprocité
+   - Valorisation égale de toutes les contributions
+   - Complément (pas remplacement) aux cotisations monétaires
+   - Tisser des liens entre membres
+
+2. Principes de fonctionnement
+
+   - 1 heure = 1 crédit (quelle que soit la compétence)
+   - Compte individuel ou organisationnel
+   - Solde peut être négatif temporairement
+   - Transparence des transactions
+
+3. Types de contributions créditables
+
+   3.1 Contributions techniques
+   - Développement d'outils communs
+   - Configuration d'infrastructure
+   - Audits de sécurité
+   - Support technique pair-Ã -pair
+
+   3.2 Contributions organisationnelles
+   - Animation de cercles
+   - Rédaction de documentation
+   - Formation et mentorat
+   - Représentation publique de l'Alliance
+
+   3.3 Contributions non créditables
+   - Obligations contractuelles normales
+   - Travail rémunéré par ailleurs
+   - Participation minimale requise
+
+4. Gestion des crédits
+
+   - Déclaration des heures (formulaire simple)
+   - Validation par le bénéficiaire (ou cercle concerné)
+   - Enregistrement au Registraire
+   - Soldes publiés (avec consentement)
+
+5. Utilisation des crédits
+
+   - Demande de service à un autre membre
+   - Échange de crédits contre réduction de cotisation (taux à définir)
+   - Don de crédits à un autre membre
+   - Pas de conversion directe en argent
+
+6. Limites et garde-fous
+
+   - Solde négatif maximum : -20 crédits (sauf exception)
+   - Obligation de rééquilibrage si solde < -15 pendant 6 mois
+   - Pas d'accumulation excessive (plafond optionnel à discuter)
+
+7. Gouvernance de la banque
+
+   - Supervision par le Cercle Opérationnel
+   - Ajustements annuels des règles
+   - Mécanismes de résolution de litiges
+
+8. Outils techniques
+
+   - Plateforme de gestion (Timebank, custom, ou tableur)
+   - Intégration au Registraire (YAML ou API)
+   - Historique immuable (audit trail)
+
+---
+
+## Document 8 : Guide d'Onboarding des Nouveaux Membres
+**Longueur estimée :** 10-12 pages
+
+### Table des matières :
+
+1. Vue d'ensemble du processus
+
+   - Durée totale : 3-4 mois (candidature + probation)
+   - Étapes clés
+   - Acteurs impliqués
+
+2. Phase 1 : Candidature (2-4 semaines)
+
+   2.1 Prérequis
+   - Alignement avec les valeurs de la Charte
+   - Capacité technique minimale (checklist)
+   - Volonté de participer activement
+
+   2.2 Documents à préparer
+   - Lettre d'intention (pourquoi rejoindre l'Alliance ?)
+   - Présentation de l'organisation (légal, technique, valeurs)
+   - Plan de contribution (services, outils, expertises)
+   - Fiche membre (partner.yml) préliminaire
+
+   2.3 Parrainage
+   - Identification d'un membre parrain
+   - Rôle du parrain (accompagnement, évaluation)
+
+   2.4 Entretien avec le Cercle Stratégique
+   - Présentation du projet
+   - Questions-réponses
+   - Décision d'admission (unanimité en phase pilote)
+
+3. Phase 2 : Intégration technique (2-3 semaines)
+
+   3.1 Accès aux outils communs
+   - Compte Matrix (communication)
+   - Accès à la forge (dépôts, documentation)
+   - Accès au Registraire (lecture/écriture)
+
+   3.2 Configuration DNS
+   - Déclaration des serveurs DNS
+   - Configuration AXFR avec pairs
+   - Tests de délégation
+
+   3.3 Identité fédérée
+   - Configuration SSO (Keycloak ou équivalent)
+   - Publication des métadonnées
+   - Tests d'interopérabilité
+
+   3.4 Services de base
+   - Courriel (DKIM, SPF, DMARC)
+   - Partage de fichiers (si pertinent)
+   - Monitoring (export métriques)
+
+4. Phase 3 : Probation (3 mois)
+
+   4.1 Objectifs à atteindre
+   - Disponibilité >99% sur services critiques
+   - Participation active aux échanges (Matrix, réunions)
+   - Contribution à au moins 1 outil commun
+   - Début d'audits croisés avec pairs
+
+   4.2 Suivi par le parrain
+   - Points de contact réguliers (bimensuels)
+   - Support technique au besoin
+   - Rapport d'évaluation en fin de probation
+
+   4.3 Évaluation finale
+   - Auto-évaluation du nouveau membre
+   - Évaluation par le parrain
+   - Feedback des pairs ayant interagi
+   - Décision du Cercle Stratégique (statut actif ou prolongation)
+
+5. Phase 4 : Membre actif
+
+   - Droits et responsabilités complets
+   - Éligibilité à l'attribution d'un label
+   - Participation aux cercles (si volontaire)
+
+6. Checklist maître d'onboarding
+
+   - [ ] Candidature reçue
+   - [ ] Parrain identifié
+   - [ ] Entretien Cercle Stratégique réussi
+   - [ ] Accès outils communs activés
+   - [ ] DNS configuré et testé
+   - [ ] SSO configuré et testé
+   - [ ] Services de base opérationnels
+   - [ ] Première contribution livrée
+   - [ ] Évaluation de probation positive
+   - [ ] Statut actif confirmé
+
+7. Ressources et support
+
+   - Documentation technique (wiki)
+   - Contacts des pairs mentors
+   - Canaux de support (Matrix #support)
+   - FAQ onboarding
+
+---
+
+## Document 9 : Procédures de Gestion des Incidents
+**Longueur estimée :** 10-12 pages
+
+### Table des matières :
+
+1. Définitions et classifications
+
+   1.1 Qu'est-ce qu'un incident ?
+   - Interruption non planifiée d'un service
+   - Dégradation significative de performance
+   - Violation de sécurité ou vie privée
+   - Non-respect des SLA contractuels
+
+   1.2 Niveaux de gravité
+   - **P0 (Critique)** : Panne totale service critique, impact sécurité majeur
+   - **P1 (Majeur)** : Dégradation importante, impact utilisateurs significatif
+   - **P2 (Mineur)** : Problème localisé, workaround disponible
+   - **P3 (Cosmétique)** : Désagrément sans impact fonctionnel
+
+2. Obligations de déclaration
+
+   - P0/P1 : Déclaration obligatoire dans les 2h
+   - P2 : Déclaration recommandée dans les 24h
+   - P3 : Déclaration optionnelle
+   - Canal : Matrix #incidents + formulaire Registraire
+
+3. Processus de gestion d'incident (pour le membre affecté)
+
+   3.1 Détection et triage
+   - Confirmation de l'incident
+   - Classification de gravité
+   - Identification des impacts
+
+   3.2 Communication initiale
+   - Alerte aux membres (si impact fédéral)
+   - Notification aux utilisateurs finaux
+   - Activation de la page de statut
+
+   3.3 Résolution
+   - Investigation des causes
+   - Mise en Å“uvre de correctifs
+   - Tests de validation
+   - Surveillance post-résolution
+
+   3.4 Communication finale
+   - Annonce de résolution
+   - Résumé des impacts
+   - Actions préventives
+
+4. Support inter-membres
+
+   - Principe de solidarité (entraide technique)
+   - Mobilisation via Matrix #incidents
+   - Utilisation de crédits banque de temps (optionnel)
+   - Pas d'obligation formelle (best effort)
+
+5. Post-mortem obligatoire (P0/P1)
+
+   5.1 Contenu requis
+   - Timeline détaillée
+   - Causes racines (technique, organisationnelle, humaine)
+   - Impact mesuré (durée, utilisateurs, services)
+   - Actions correctives prises
+   - Actions préventives planifiées
+
+   5.2 Publication
+   - Partage avec pairs (Matrix ou forge)
+   - Anonymisation si nécessaire (sécurité)
+   - Apprentissage collectif
+
+6. Incidents de sécurité (traitement spécifique)
+
+   6.1 Déclaration renforcée
+   - Contact immédiat du Cercle Éthique & Conformité
+   - Évaluation de l'impact fédéral
+   - Coordination avec pairs affectés
+
+   6.2 Confidentialité temporaire
+   - Restriction de diffusion pendant investigation
+   - Divulgation responsable après mitigation
+   - Transparence ultime (sauf exception justifiée)
+
+7. Récurrence et patterns
+
+   - Analyse trimestrielle des incidents (Cercle Opérationnel)
+   - Identification de patterns systémiques
+   - Recommandations d'amélioration collective
+
+8. Outils et templates
+
+   - Formulaire de déclaration d'incident
+   - Template de post-mortem
+   - Checklist de résolution
+
+---
+
+# CATÉGORIE 3 : DOCUMENTS LÉGAUX
+
+## Document 10 : Modèle de Contrat d'Adhésion
+**Longueur estimée :** 8-10 pages
+
+### Table des matières :
+
+1. Préambule
+   - Présentation de L'Alliance Boréale
+   - Nature juridique de l'accord
+   - Portée contractuelle
+
+2. Article 1 : Parties contractantes
+   - Identité du membre
+   - Identité juridique de l'Alliance (représentée par)
+
+3. Article 2 : Objet du contrat
+   - Adhésion à L'Alliance Boréale
+   - Acceptation de la Charte Fondatrice
+   - Engagement à respecter le Règlement de Régie Interne
+
+4. Article 3 : Obligations du membre
+   - Respect des valeurs et principes
+   - Participation active à la gouvernance
+   - Cotisation financière annuelle
+   - Conformité technique (DNS, interop)
+   - Déclaration des incidents P0/P1
+   - Contribution à la banque de temps (recommandée)
+
+5. Article 4 : Droits du membre
+   - Participation aux décisions (cercles)
+   - Accès aux outils communs
+   - Support technique de la communauté
+   - Usage du label (si obtenu)
+   - Bénéfice de la fédération DNS
+
+6. Article 5 : Cotisation financière
+   - Montant annuel (selon barème)
+   - Modalités de paiement
+   - Révision annuelle possible
+   - Défaut de paiement (suspension après 60 jours)
+
+7. Article 6 : Confidentialité et propriété intellectuelle
+   - Respect de la confidentialité des échanges internes
+   - Propriété des contributions (licence libre privilégiée)
+   - Usage des marques et logos
+
+8. Article 7 : Durée et résiliation
+   - Durée : indéterminée avec renouvellement annuel tacite
+   - Résiliation volontaire (préavis 30 jours)
+   - Résiliation pour cause (selon Règlement)
+   - Effets de la résiliation
+
+9. Article 8 : Responsabilité et limitation
+   - Responsabilité limitée aux obligations contractuelles
+   - Exclusion de garantie sur services tiers
+   - Indemnisation mutuelle (dommages intentionnels)
+
+10. Article 9 : Règlement des différends
+    - Résolution amiable privilégiée (médiation par Cercle Éthique)
+    - Arbitrage si nécessaire
+    - Juridiction compétente (Québec)
+
+11. Article 10 : Dispositions générales
+    - Loi applicable (droit québécois)
+    - Intégralité de l'accord
+    - Modifications (accord mutuel écrit)
+    - Signatures électroniques acceptées
+
+12. Annexes
+    - Annexe A : Charte Fondatrice (référence)
+    - Annexe B : Règlement de Régie Interne (référence)
+    - Annexe C : Fiche membre (partner.yml)
+
+---
+
+## Document 11 : Modèle de Politique de Sécurité de l'Information
+**Longueur estimée :** 12-14 pages
+
+### Objectif :
+Fournir un **template** que chaque membre peut adapter à son contexte pour démontrer sa conformité au domaine "Sécurité" du label.
+
+### Table des matières :
+
+1. Introduction
+   - Objet de la politique
+   - Portée (systèmes, données, personnes)
+   - Responsable de la sécurité
+
+2. Gouvernance de la sécurité
+   - Rôles et responsabilités
+   - Comité sécurité (si pertinent)
+   - Revue annuelle de la politique
+
+3. Gestion des actifs
+   - Inventaire des actifs informationnels
+   - Classification des données (publiques, internes, confidentielles)
+   - Propriété et responsabilité
+
+4. Contrôle d'accès
+   - Principe du moindre privilège
+   - Authentification forte (MFA obligatoire pour admin)
+   - Gestion des comptes (création, révision, suppression)
+   - Accès à distance sécurisé (VPN, SSH)
+
+5. Gestion des vulnérabilités
+   - Veille sur vulnérabilités (CVE, bulletins)
+   - SLA de correctifs :
+     * Critique : 48h
+     * Élevée : 7 jours
+     * Moyenne : 30 jours
+   - Tests de sécurité (scans, audits)
+
+6. Protection des données
+   - Chiffrement au repos (données sensibles)
+   - Chiffrement en transit (TLS/SSL obligatoire)
+   - Anonymisation/pseudonymisation (où pertinent)
+
+7. Sauvegarde et continuité
+   - Stratégie 3-2-1 (3 copies, 2 supports, 1 hors-site)
+   - Fréquence des sauvegardes (quotidienne pour données critiques)
+   - Tests de restauration (trimestriels)
+   - Plan de continuité d'activité (PCA)
+
+8. Gestion des incidents de sécurité
+   - Détection (SIEM, logs, alertes)
+   - Procédure de réponse (escalade, containment, éradication)
+   - Communication (interne, externe, autorités si requis)
+   - Post-mortem et amélioration continue
+
+9. Sensibilisation et formation
+   - Formation initiale (nouveaux employés)
+   - Sensibilisation continue (phishing, hygiene)
+   - Responsabilité individuelle
+
+10. Conformité et audit
+    - Conformité légale (Loi 25, RGPD si applicable)
+    - Audits internes (annuels)
+    - Audits par pairs (dans cadre du label)
+
+11. Sanctions et application
+    - Conséquences du non-respect
+    - Processus disciplinaire
+
+12. Annexes
+    - Annexe A : Procédure de gestion des incidents
+    - Annexe B : Liste des actifs critiques
+    - Annexe C : Registre des vulnérabilités
+
+---
+
+## Document 12 : Modèle de Politique de Protection des Renseignements Personnels
+**Longueur estimée :** 10-12 pages
+
+### Objectif :
+Fournir un **template** conforme à la Loi 25 (Québec) et au RGPD que chaque membre peut adapter.
+
+### Table des matières :
+
+1. Introduction
+   - Objet de la politique
+   - Champ d'application
+   - Responsable de la protection des renseignements personnels
+
+2. Définitions
+   - Renseignement personnel
+   - Renseignement personnel sensible
+   - Traitement
+   - Personne concernée
+   - Responsable du traitement vs sous-traitant
+
+3. Principes directeurs
+   - Licéité, loyauté, transparence
+   - Limitation des finalités
+   - Minimisation des données
+   - Exactitude
+   - Limitation de la conservation
+   - Intégrité et confidentialité
+
+4. Base légale des traitements
+   - Consentement (explicite si sensible)
+   - Exécution d'un contrat
+   - Obligation légale
+   - Intérêt légitime
+   - Documentation de la base légale
+
+5. Droits des personnes concernées
+   - Droit d'accès
+   - Droit de rectification
+   - Droit à l'effacement ("droit à l'oubli")
+   - Droit à la limitation du traitement
+   - Droit à la portabilité
+   - Droit d'opposition
+   - Procédure pour exercer ces droits (formulaire, délais)
+
+6. Registre des activités de traitement
+   - Obligation de tenir un registre
+   - Informations à documenter (finalité, catégories, destinataires, durées)
+   - Mise à jour continue
+
+7. Évaluation des facteurs relatifs à la vie privée (EFVP / DPIA)
+   - Quand réaliser une EFVP (traitements à risque élevé)
+   - Méthodologie
+   - Documentation et révision
+
+8. Mesures de sécurité
+   - Chiffrement
+   - Contrôle d'accès
+   - Pseudonymisation/anonymisation
+   - Sauvegarde sécurisée
+
+9. Transferts de données
+   - Transferts hors Québec/Canada (si applicable)
+   - Garanties appropriées (clauses contractuelles)
+
+10. Violation de la sécurité des renseignements personnels
+    - Obligation de notification (Commission d'accès à l'information)
+    - Délais (incident découvert → notification)
+    - Notification aux personnes concernées (si risque de préjudice)
+
+11. Sous-traitance
+    - Sélection de sous-traitants conformes
+    - Clauses contractuelles (confidentialité, sécurité)
+    - Supervision et audit
+
+12. Formation et sensibilisation
+    - Formation du personnel
+    - Responsabilité individuelle
+
+13. Révision et mise à jour
+    - Révision annuelle de la politique
+    - Adaptation aux évolutions légales
+
+14. Annexes
+    - Annexe A : Registre des traitements (template)
+    - Annexe B : Formulaire d'exercice des droits
+    - Annexe C : Procédure de notification de violation
+
+---
+
+# CATÉGORIE 4 : OUTILS DE PILOTAGE
+
+## Document 13 : Modèle Financier et Soutenabilité
+**Longueur estimée :** 12-14 pages
+
+### Table des matières :
+
+1. Philosophie financière de L'Alliance
+
+   - Soutenabilité avant croissance
+   - Transparence financière totale
+   - Diversification des sources de revenus
+   - Constitution d'une réserve de prudence
+
+2. Sources de revenus
+
+   2.1 Cotisations des membres
+   - Barème progressif selon taille/revenus :
+     * Petite structure (<100k$ CA) : 500 $/an
+     * Moyenne structure (100-500k$) : 1 000 $/an
+     * Grande structure (>500k$) : 2 000 $/an
+   - Révision annuelle possible (décision Cercle Stratégique)
+
+   2.2 Subventions et financements publics
+   - Admissibilité (si OBNL constitué)
+   - Programmes ciblés (innovation, numérique responsable)
+   - Conditions d'acceptation (alignement valeurs)
+
+   2.3 Dons et mécénat
+   - Dons ponctuels (individus, organisations sympathisantes)
+   - Mécénat éthique (pas de conflits d'intérêts)
+
+   2.4 Services facultatifs payants
+   - Formations et ateliers
+   - Consulting en gouvernance coopérative
+   - Audits de conformité pour non-membres
+   - Réinvestissement dans l'Alliance
+
+3. Dépenses prévues
+
+   3.1 Frais de fonctionnement
+   - Infrastructure technique partagée (serveurs, DNS, monitoring)
+   - Outils de communication (Matrix, forge)
+   - Domaines et certificats SSL
+   - Assurances (responsabilité civile)
+
+   3.2 Frais légaux et administratifs
+   - Constitution en OBNL (année 3)
+   - Comptabilité et audit financier
+   - Honoraires juridiques (contrats, litiges)
+
+   3.3 Coordination rémunérée (optionnel, phase mature)
+   - Coordinateur technique à temps partiel (10-20h/semaine)
+   - Facilitateur de gouvernance
+   - Communicateur (événements, site web)
+
+   3.4 Événements et rayonnement
+   - Rencontres annuelles (hébergement, déplacements)
+   - Participation à conférences (stands, conférences)
+   - Production de contenu (vidéos, articles)
+
+4. Projections financières sur 3 ans
+
+   4.1 Année 1 (Phase pilote : 5 membres)
+   - Revenus cotisations : 5 000 $
+   - Dépenses infrastructure : 2 000 $
+   - Dépenses légales : 3 000 $
+   - Dépenses communication : 1 000 $
+   - Solde : -1 000 $ (déficit initial acceptable)
+
+   4.2 Année 2 (Consolidation : 15 membres)
+   - Revenus cotisations : 18 000 $
+   - Subventions obtenues : 10 000 $
+   - Dépenses infrastructure : 5 000 $
+   - Dépenses légales : 4 000 $
+   - Dépenses coordination : 12 000 $ (partiel)
+   - Dépenses événements : 3 000 $
+   - Solde : +4 000 $
+
+   4.3 Année 3 (Constitution OBNL : 25 membres)
+   - Revenus cotisations : 30 000 $
+   - Subventions : 15 000 $
+   - Services payants : 8 000 $
+   - Dépenses infrastructure : 8 000 $
+   - Dépenses légales (OBNL) : 10 000 $
+   - Dépenses coordination : 20 000 $
+   - Dépenses événements : 5 000 $
+   - Solde : +10 000 $ (début de réserve)
+
+5. Scénarios et sensibilité
+
+   5.1 Scénario pessimiste (croissance lente)
+   - 3 membres année 1, 8 membres année 2, 12 membres année 3
+   - Revenus insuffisants pour coordination rémunérée
+   - Dépendance accrue à la banque de temps
+
+   5.2 Scénario réaliste (croissance organique)
+   - Projections ci-dessus
+
+   5.3 Scénario optimiste (adoption rapide)
+   - 5-20-35 membres
+   - Coordination rémunérée dès année 2
+   - Réserve substantielle (>30k$) en année 3
+
+6. Stratégies de financement complémentaire
+
+   - Partenariats avec universités (recherche-action)
+   - Candidatures à des prix et reconnaissances
+   - Crowdfunding éthique (si besoin ponctuel)
+
+7. Gouvernance financière
+
+   - Trésorier désigné (membre du Cercle Opérationnel)
+   - Transparence totale (bilans publiés trimestriellement)
+   - Audit financier annuel (si budget >50k$)
+   - Décisions budgétaires par consentement (Cercle Stratégique)
+
+8. Réserve de prudence
+
+   - Objectif : 6 mois de dépenses courantes
+   - Constitution progressive (surplus réinvestis)
+   - Utilisation uniquement en cas de crise
+
+---
+
+## Document 14 : Structure YAML du Registraire
+**Longueur estimée :** 8-10 pages
+
+### Table des matières :
+
+1. Philosophie du Registraire
+
+   - Source unique de vérité (single source of truth)
+   - Lisible par humains ET machines
+   - Versionné (Git) pour traçabilité
+   - Public par défaut (sauf données sensibles)
+
+2. Architecture des fichiers
+
+   ```
+   registraire.alliance-boreale.ca/
+   ├── membres/
+   │   ├── fondateur-01.yml
+   │   ├── fondateur-02.yml
+   │   ├── fondateur-03.yml
+   │   └── membre-NNNN.yml
+   ├── labels/
+   │   ├── 2025-T1.yml
+   │   ├── 2025-T2.yml
+   │   └── ...
+   ├── gouvernance/
+   │   ├── cercles.yml
+   │   ├── decisions/
+   │   │   ├── 2025-001-admission-membre-x.yml
+   │   │   └── ...
+   │   └── resolutions/
+   │       ├── 2025-R01-cotisation-ajustement.yml
+   │       └── ...
+   ├── banque-temps/
+   │   ├── transactions.yml
+   │   └── soldes.yml
+   └── meta/
+       ├── schemas/
+       │   ├── member.schema.json
+       │   └── label.schema.json
+       └── README.md
+   ```
+
+3. Schéma d'une fiche membre (partner.yml)
+
+   ```yaml
+   # Identité unique
+   id: f01  # fondateur-01, ou m0042 pour membres ultérieurs
+   status: active  # active | probation | suspended | exited
+
+   # Informations légales
+   legal:
+     name: "Exemple OBNL"
+     type: npo  # corporation | cooperative | npo
+     jurisdiction: QC
+     registration_number: "NEQ 1234567890"
+     founded: 2020-05-15
+
+   # Contacts clés
+   contact:
+     primary: contact@exemple.org
+     legal: legal@exemple.org
+     security: security@exemple.org
+     privacy: privacy@exemple.org
+     technical: noc@exemple.org
+
+   # Adhésion à L'Alliance
+   membership:
+     joined: 2025-01-15
+     probation_end: 2025-04-15  # null si membre permanent
+     sponsor: f02  # ID du parrain, null pour fondateurs
+     status_history:
+       - date: 2025-01-15
+         status: probation
+         decision: cercle-strategique-2025-001
+       - date: 2025-04-20
+         status: active
+         decision: cercle-strategique-2025-008
+
+   # Labellisation (si obtenue)
+   label:
+     level: silver  # bronze | silver | gold | platinum | null
+     score: 74
+     issued: 2025-10-15
+     valid_until: 2026-10-15
+     auditor: f03
+     audit_report_url: https://registraire.alliance-boreale.ca/audits/2025-f01-silver.pdf
+
+   # DNS et fédération
+   dns:
+     primary:
+       - ns1.exemple.org (198.51.100.10)
+       - ns2.exemple.org (198.51.100.11)
+     secondary:
+       - ns1.autre-membre.ca
+       - ns2.troisieme-membre.org
+     zones_delegated:
+       - exemple.org
+       - services.exemple.org
+     dnssec: true
+
+   # Identité fédérée (SSO)
+   identity:
+     provider_type: keycloak  # keycloak | authentik | authelia | other
+     metadata_url: https://sso.exemple.org/.well-known/openid-configuration
+     federation_tested: true
+     last_test_date: 2025-10-01
+
+   # Services offerts (interopérabilité)
+   services:
+     email: true
+     files: true  # Nextcloud ou équivalent
+     chat: true  # Matrix
+     forge: true  # Forgejo/Gitea/GitLab
+     video: false
+     other:
+       - name: "Plateforme collaborative"
+         url: https://collab.exemple.org
+
+   # URLs publiques
+   public_urls:
+     website: https://exemple.org
+     status: https://status.exemple.org
+     policies: https://exemple.org/politiques
+     transparency: https://exemple.org/transparence
+
+   # Valeurs et engagements
+   values:
+     open_source: true
+     local_hosting: true  # Hébergement sur territoire
+     privacy_first: true
+     sustainability_focus: true
+
+   # Contributions à l'Alliance
+   contributions:
+     timebank_balance: 12  # crédits (positif = créditeur)
+     audits_performed:
+       - member_id: f02
+         date: 2025-09-10
+         type: label-silver
+     tools_contributed:
+       - name: ansible-role-powerdns-federated
+         url: https://forge.alliance-boreale.ca/outils/ansible-role-powerdns
+     documentation:
+       - title: "Guide configuration DNSSEC"
+         url: https://wiki.alliance-boreale.ca/dns/dnssec
+   ```
+
+4. Schéma d'attribution de label
+
+   ```yaml
+   # labels/2025-T4.yml (trimestre 4 de 2025)
+   period: 2025-T4
+   issued: 2025-10-15
+
+   attributions:
+     - member_id: f01
+       level: silver
+       score: 74
+       domains_scores:
+         governance: 4
+         security: 4
+         privacy: 4
+         interoperability: 3
+         operations: 5
+         sustainability: 4
+       auditor: f03
+       audit_date: 2025-09-22
+       valid_until: 2026-10-15
+       notes: "Excellente progression, interop à améliorer"
+
+     - member_id: f02
+       level: gold
+       score: 87
+       domains_scores:
+         governance: 5
+         security: 5
+         privacy: 4
+         interoperability: 5
+         operations: 4
+         sustainability: 5
+       auditor: f01
+       audit_date: 2025-09-30
+       valid_until: 2026-10-15
+       notes: "Référence en sobriété numérique"
+   ```
+
+5. Schéma de gouvernance (cercles)
+
+   ```yaml
+   # gouvernance/cercles.yml
+   circles:
+     strategic:
+       mandate: "Vision, orientation, admission membres"
+       composition: all_active_members
+       term_months: 12
+       chair: f01-daniel-allaire
+       next_election: 2026-01-15
+       members:
+         - f01-daniel-allaire
+         - f02-membre-b
+         - f03-membre-c
+         # (liste complète)
+
+     operational:
+       mandate: "Coordination technique, infrastructure"
+       composition:
+         - f02-tech-lead  # term ends 2025-12-31
+         - f03-devops     # term ends 2025-12-31
+         - m001-sysadmin  # term ends 2026-06-30
+       term_months: 6
+       chair: f02-tech-lead
+       rotation_schedule: semi-annual
+
+     ethics:
+       mandate: "Label, audits, arbitrages, communication"
+       composition:
+         - f01-daniel-allaire  # term ends 2027-01-15
+         - f03-governance      # term ends 2026-07-15
+         - m005-ethics-rep     # term ends 2027-01-15
+       term_months: 24
+       chair: f01-daniel-allaire
+   ```
+
+6. Schéma de décision
+
+   ```yaml
+   # gouvernance/decisions/2025-015-admission-membre-nouveau.yml
+   decision_id: 2025-015
+   date: 2025-10-22
+   circle: strategic
+   type: admission  # admission | policy | budget | label | other
+   
+   title: "Admission de Nouveau Membre OBNL"
+   
+   proposal:
+     summary: "Admettre Nouveau Membre OBNL comme membre en probation"
+     sponsor: f02-membre-b
+     candidate:
+       name: "Nouveau Membre OBNL"
+       contact: contact@nouveau.org
+       motivation_letter_url: https://registraire.../candidatures/2025-nouveau.pdf
+   
+   decision_process:
+     mode: consent  # consent | vote | escalated
+     rounds:
+       - round: 1-clarification
+         questions:
+           - author: f03-membre-c
+             question: "Quelle est leur capacité technique actuelle ?"
+             answer: "Infrastructure Proxmox, services email/Nextcloud opérationnels"
+       - round: 2-reactions
+         reactions:
+           - author: f01-daniel-allaire
+             reaction: "Excellent alignement valeurs, bienvenue"
+           - author: f03-membre-c
+             reaction: "Bon fit technique, supportons leur intégration"
+       - round: 3-objections
+         objections: []
+   
+   outcome: approved
+   effective_date: 2025-10-25
+   actions:
+     - create_member_file: m008-nouveau-membre.yml
+     - assign_sponsor: f02-membre-b
+     - grant_access: [matrix, forge, registraire]
+   ```
+
+7. API et intégration
+
+   - Endpoints REST en lecture (JSON)
+     * GET /api/v1/members
+     * GET /api/v1/members/{id}
+     * GET /api/v1/labels/current
+   - Webhooks pour notifications (admissions, labels, incidents)
+   - Intégration monitoring (export métriques Prometheus)
+
+8. Validation et CI/CD
+
+   - Schémas JSON Schema pour validation automatique
+   - Tests automatisés :
+     * yamllint (syntaxe)
+     * schema validation (conformité)
+     * cross-references check (IDs valides)
+   - Processus de contribution :
+     * Pull Request obligatoire
+     * Review par 1 membre du Cercle concerné
+     * Merge automatique si tests passent
+
+9. Sécurité et accès
+
+   - Dépôt Git public (lecture)
+   - Accès en écriture : membres actifs uniquement
+   - Données sensibles (ex: contacts privés) : fichier séparé chiffré
+   - Audit trail complet (Git history)
+
+---
+
+## Document 15 : Guide de Démarrage Rapide
+**Longueur estimée :** 10-12 pages
+
+### Table des matières :
+
+1. Introduction
+
+   - À qui s'adresse ce guide (membres fondateurs)
+   - Objectif : lancer L'Alliance en 60 jours
+   - Prérequis de lecture (Charte, Règlement)
+
+2. Prérequis techniques et légaux
+
+   2.1 Pour chaque membre fondateur
+   - Infrastructure minimale (serveur, DNS)
+   - Documents légaux (statuts, NEQ)
+   - Contacts désignés (technique, légal, sécurité)
+
+   2.2 Pour le groupe
+   - Domaine principal (alliance-boreale.ca)
+   - Serveur Git pour le Registraire
+   - Serveur Matrix pour communication
+
+3. Phase 1 : Fondation (Semaines 1-2)
+
+   Semaine 1 : Documents fondateurs
+   - Jour 1-2 : Révision finale et adoption de la Charte
+     * Résolution du conseil d'administration de chaque membre
+     * Signature électronique
+   - Jour 3-4 : Création du Registraire (dépôt Git)
+     * Initialisation du dépôt
+     * Création des fiches membres fondateurs (partner.yml)
+     * Validation schémas
+   - Jour 5 : Première réunion Cercle des Référents Boréaux
+     * Nomination du président
+     * Adoption du Règlement de Régie Interne
+     * Plan d'action 60 jours
+
+   Semaine 2 : Gouvernance initiale
+   - Constitution des 3 cercles (Stratégique, Opérationnel, Éthique)
+   - Élection des présidents de cercle
+   - Première décision par consentement (test du processus)
+   - Mise en place des outils de communication (Matrix, forge)
+
+4. Phase 2 : Infrastructure technique (Semaines 3-4)
+
+   Semaine 3 : DNS fédéré
+   - Configuration PowerDNS sur chaque nœud
+   - Définition des zones autoritaires
+   - Configuration AXFR (transferts de zone entre pairs)
+   - Tests de réplication et de résolution
+
+   Semaine 4 : Identité fédérée et services
+   - Configuration SSO (Keycloak ou équivalent)
+   - Tests d'interopérabilité (login croisé)
+   - Activation services de base (email, fichiers)
+   - Monitoring mutualisé (métriques Prometheus)
+
+5. Phase 3 : Consolidation (Semaines 5-6)
+
+   Semaine 5 : Banque de temps et premières contributions
+   - Initialisation de la banque de temps
+   - Première contribution commune (outil partagé, doc)
+   - Échanges de crédits entre membres
+
+   Semaine 6 : Première labellisation (auto-évaluation)
+   - Chaque membre réalise son auto-évaluation
+   - Audits croisés entre fondateurs
+   - Attribution des premiers labels Bronze/Argent
+
+6. Phase 4 : Ouverture (Semaines 7-8)
+
+   Semaine 7 : Communication publique
+   - Lancement du site web vitrine
+   - Annonce publique (réseaux sociaux, presse)
+   - Publication de la liste des membres fondateurs
+
+   Semaine 8 : Préparation onboarding externe
+   - Documentation d'onboarding finalisée
+   - Identification de candidats potentiels (1-2 membres)
+   - Ouverture des candidatures
+
+7. Checklist maître (60 jours)
+
+   **Juridique et gouvernance**
+   - [ ] Charte adoptée par tous les fondateurs (résolutions CA)
+   - [ ] Règlement de Régie Interne adopté
+   - [ ] Cercles constitués et présidents élus
+   - [ ] Contrats d'adhésion signés
+
+   **Technique**
+   - [ ] Registraire en ligne (Git + validation automatisée)
+   - [ ] DNS fédéré fonctionnel (AXFR entre tous les pairs)
+   - [ ] SSO configuré et testé (login croisé)
+   - [ ] Monitoring partagé opérationnel
+   - [ ] Outils communs accessibles (Matrix, forge)
+
+   **Label et conformité**
+   - [ ] Premiers audits croisés réalisés
+   - [ ] Labels Bronze/Argent attribués
+   - [ ] Documentation conformité publiée
+
+   **Communication**
+   - [ ] Site web public en ligne
+   - [ ] Annonce de lancement diffusée
+   - [ ] Processus d'onboarding documenté
+
+   **Financier**
+   - [ ] Première cotisation perçue
+   - [ ] Budget année 1 adopté
+   - [ ] Compte bancaire ouvert (si nécessaire)
+
+8. Post-lancement (Mois 3-6)
+
+   - Accueil du premier membre externe
+   - Ajustements basés sur les apprentissages
+   - Planification année 2 (objectifs, recrutement)
+   - Première revue de gouvernance (qu'est-ce qui fonctionne ?)
+
+9. Ressources et contacts
+
+   - Documentation complète : wiki.alliance-boreale.ca
+   - Support technique : #support sur Matrix
+   - Questions gouvernance : Cercle Éthique
+   - Contact public : contact@alliance-boreale.ca
+
+10. FAQ du démarrage
+
+    Q: Que faire si on bloque sur une décision ?
+    R: Appliquer le processus sociocratique (3 tours), puis fallback vote si nécessaire.
+
+    Q: Un membre n'arrive pas à configurer AXFR, comment l'aider ?
+    R: Support pair-à -pair via Matrix #technique, documentation wiki, crédits banque de temps.
+
+    Q: Peut-on modifier la Charte en cours de route ?
+    R: Oui, mais nécessite consentement du Cercle Stratégique + période de discussion 14 jours.
+
+    Q: Combien de temps pour le premier label ?
+    R: Auto-évaluation : 2-4h. Audit pair : 1 journée. Délai total : 2-3 semaines.
+
+---
+
+# ANNEXE : RÉSUMÉ EXÉCUTIF
+
+**L'Alliance Boréale en une page**
+
+**Mission :**
+Fédérer les acteurs du numérique éthique du Nord dans une coopération technique distribuée, garantie par un label de prestige.
+
+**Valeurs cardinales :**
+Souveraineté • Liberté • Sobriété • Solidarité • Transparence
+
+**Gouvernance :**
+Sociocratique à 3 cercles (Stratégique, Opérationnel, Éthique & Conformité)
+
+**Financement :**
+Hybride (cotisations 500-2000$/an + banque de temps + subventions éthiques)
+
+**Label de prestige :**
+4 niveaux (Bronze, Argent, Or, Platine) évalués sur 6 domaines de conformité
+
+**Croissance :**
+Organique, de quelques membres fondateurs à plusieurs dizaines de membres actifs
+
+**Différenciateur :**
+> "Nous ne bâtissons pas un empire. Nous entretenons une forêt."
+
+**Timeline :**
+- **2025** : Phase pilote (membres fondateurs)
+- **2026** : Consolidation (croissance progressive)
+- **2027** : Constitution en OBNL (maturité organisationnelle)
+
+**Interopérabilité technique :**
+DNS fédéré • Identités fédérées (SSO) • Protocoles ouverts • Standards matures
+
+**Philosophie :**
+Sobriété heureuse assistée par la technologie • Autopoïèse organisationnelle • Subsidiarité
+
+---
+
+# VALIDATION ET PROCHAINES ÉTAPES
+
+## Changements majeurs de cette version 2.0
+
+1. **Suppression des références obsolètes**
+   - Retiré : "156 membres" (remplacé par "croissance organique")
+   - Retiré : Plan d'adressage IP /16 (L'Alliance n'est pas registraire IP)
+   - Retiré : Toute mention d'Ortrux (projet distinct)
+
+2. **Ajout : Document 0 (Glossaire)**
+   - Base commune de terminologie
+   - Référence unique pour tous les autres documents
+
+3. **Clarification du rôle des Docs 11-12**
+   - Désormais des **templates/modèles** (pas des politiques opérationnelles de Chezlepro)
+   - Chaque membre adapte à son contexte
+
+4. **Renforcement de la cohérence**
+   - Chronologie clarifiée (2025-2027)
+   - Rôles et responsabilités mieux définis
+   - Interdépendances documentaires explicitées
+
+5. **Restructuration mineure**
+   - Catégorie 0 ajoutée (Base Commune)
+   - Total : 16 documents (au lieu de 15)
+   - Estimation : 130-160 pages (légère hausse pour la complétude)
+
+## Questions pour validation finale
+
+1. **Membres fondateurs :**
+   - Les "f01, f02, f03" dans les exemples sont-ils Chezlepro, Nuage Libre, TechnoLibre ?
+   - Ou préfères-tu des exemples génériques/anonymisés ?
+
+2. **Chronologie :**
+   - Phase pilote démarre quand exactement ? (T4 2025 ?)
+   - Constitution OBNL prévue pour 2027 est-elle réaliste ?
+
+3. **DNS :**
+   - Sans gestion d'adresses IP, quel est le modèle exact ?
+   - Chaque membre utilise ses propres IPs publiques + DNS fédéré via AXFR ?
+
+4. **Priorités de rédaction :**
+   - Commencer par quel document en premier ?
+   - Suggestion : Doc 0 (Glossaire) → Doc 1 (Charte) → Doc 4 (Manifeste) → Doc 2 (Régie) → reste
+
+## Prêt pour la production
+
+Une fois ce devis validé, je procéderai à la rédaction complète de chaque document, un par un, en suivant l'ordre logique des dépendances.
+
+**Temps estimé de rédaction complète :** 15-20 heures de travail concentré (sur plusieurs jours)
+
+**Format de livraison :** Fichiers markdown séparés, structurés, prêts à intégrer dans la Forge
+
+---
+
+**FIN DU DEVIS — Version 2.0**
diff --git a/docs/30-federation/00-protocole-federatif.md b/docs/30-federation/00-protocole-federatif.md
deleted file mode 100644
index 2a32e78..0000000
--- a/docs/30-federation/00-protocole-federatif.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Protocole Federatif
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/30-federation/01-registre-central-yaml.md b/docs/30-federation/01-registre-central-yaml.md
deleted file mode 100644
index c38fcd8..0000000
--- a/docs/30-federation/01-registre-central-yaml.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Registre Central Yaml
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/30-federation/02-communication-entre-noeuds.md b/docs/30-federation/02-communication-entre-noeuds.md
deleted file mode 100644
index 7dc7101..0000000
--- a/docs/30-federation/02-communication-entre-noeuds.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Communication Entre Noeuds
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/30-federation/03-synchronisation-et-replication.md b/docs/30-federation/03-synchronisation-et-replication.md
deleted file mode 100644
index bfce818..0000000
--- a/docs/30-federation/03-synchronisation-et-replication.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Synchronisation Et Replication
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/30-federation/04-identites-et-authentification.md b/docs/30-federation/04-identites-et-authentification.md
deleted file mode 100644
index 73fe929..0000000
--- a/docs/30-federation/04-identites-et-authentification.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Identites Et Authentification
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/30-federation/05-procedure-de-reprise-et-resilience.md b/docs/30-federation/05-procedure-de-reprise-et-resilience.md
deleted file mode 100644
index 3f1de52..0000000
--- a/docs/30-federation/05-procedure-de-reprise-et-resilience.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Procedure De Reprise Et Resilience
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/50-annexes/00-schema-global.md b/docs/50-annexes/00-schema-global.md
deleted file mode 100644
index c690fde..0000000
--- a/docs/50-annexes/00-schema-global.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Schema Global
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/50-annexes/01-references-logicielles.md b/docs/50-annexes/01-references-logicielles.md
deleted file mode 100644
index b3ac253..0000000
--- a/docs/50-annexes/01-references-logicielles.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# References Logicielles
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/50-annexes/02-normes-nomenclature-ip-et-dns.md b/docs/50-annexes/02-normes-nomenclature-ip-et-dns.md
deleted file mode 100644
index d9af858..0000000
--- a/docs/50-annexes/02-normes-nomenclature-ip-et-dns.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Normes Nomenclature Ip Et Dns
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/50-annexes/03-outils-et-scripts.md b/docs/50-annexes/03-outils-et-scripts.md
deleted file mode 100644
index f1c14fc..0000000
--- a/docs/50-annexes/03-outils-et-scripts.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Outils Et Scripts
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/50-annexes/04-bibliographie-et-liens-externes.md b/docs/50-annexes/04-bibliographie-et-liens-externes.md
deleted file mode 100644
index ef92cec..0000000
--- a/docs/50-annexes/04-bibliographie-et-liens-externes.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Bibliographie Et Liens Externes
-
-> Brouillon — à compléter.
-
-## Objet
-Décrire clairement le périmètre de ce document.
-
-## Contexte
-Pourquoi ce contenu est nécessaire dans l’Alliance Boréale.
-
-## Contenu
-- Points à couvrir
-- Exemples
-- Références internes
-
-## Révisions
-- YYYY-MM-DD — création (brouillon)
diff --git a/docs/TODO.md b/docs/TODO.md
index 379b1eb..267a4a4 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,4 +1,4 @@
-# 📋 L'ALLIANCE BORÉALE — PLAN DOCUMENTAIRE COMPLET
+# 📋 L'ALLIANCE BORÉALE — PLAN DU CORPUS DOCUMENTAIRE COMPLET
 
 **Version Exécutive**  
 **Date :** 27 octobre 2025  
@@ -20,13 +20,13 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### État d'avancement global
 
-| Catégorie | Complets | En cours | Planifiés | Total |
-|-----------|----------|----------|-----------|-------|
-| **Gouvernance & Conformité** | 60% | 30% | 10% | 7 docs |
-| **Opérations Techniques** | 40% | 20% | 40% | 8 docs |
-| **Sécurité & Résilience** | 30% | 20% | 50% | 5 docs |
-| **Formation & Transmission** | 20% | 30% | 50% | 4 docs |
-| **Total** | **45%** | **25%** | **30%** | **24 docs** |
+| Catégorie                | Complets | En cours | Planifiés | Total   |
+|--------------------------|----------|----------|-----------|---------|
+| **Gouvernance & Conformité** | 60%      | 30%      | 10%       | 7 docs  |
+| **Opérations Techniques**    | 40%      | 20%      | 40%       | 8 docs  |
+| **Sécurité & Résilience**    | 30%      | 20%      | 50%       | 5 docs  |
+| **Formation & Transmission** | 20%      | 30%      | 50%       | 4 docs  |
+| **Total**                    | **45%**      | **25%**      | **30%**       | **24 docs** |
 
 ### Investissement temps estimé (finalisation)
 
@@ -44,12 +44,12 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **1. Documents de référence (SSOT) — 100% complet ✅**
 
-| # | Document | Pages | Statut | Audience |
-|---|----------|-------|--------|----------|
-| 1.1 | **Modèle à 8 couches biomimétique** | 12 | ✅ Finalisé | Architectes, Direction |
-| 1.2 | **Nomenclature technique (VMID, DNS, réseau)** | 10 | ✅ Finalisé | Ops, DevOps, Réseau |
-| 1.3 | **Glossaire complet (terminologie unifiée)** | 8 | ✅ Finalisé | Tous |
-| 1.4 | **État du dépôt vivant (dashboard projet)** | 6 | ✅ Actualisé | Direction, Coordinateurs |
+| \#   | Document                                   | Pages | Statut      | Audience                 |
+|-----|--------------------------------------------|-------|-------------|--------------------------|
+| 1.1 | **Modèle à 8 couches biomimétique**            | 12    | ✅ Finalisé  | Architectes, Direction   |
+| 1.2 | **Nomenclature technique (VMID, DNS, réseau)** | 10    | ✅ Finalisé  | Ops, DevOps, Réseau      |
+| 1.3 | **Glossaire complet (terminologie unifiée)**   | 8     | ✅ Finalisé  | Tous                     |
+| 1.4 | **État du dépôt vivant (dashboard projet)**    | 6     | ✅ Actualisé | Direction, Coordinateurs |
 
 **Impact business :** Base technique et sémantique garantissant la cohérence de tous les autres documents.
 
@@ -57,20 +57,22 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **2. Gouvernance & Cadre légal — 80% complet 🔨**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 2.1 | **Charte Fondatrice** | 12 | ✅ v2.1 validée | — | Fondateurs, Conseil |
-| 2.2 | **Règlement de Régie Interne (sociocratie)** | 20 | 🔨 v3 en finalisation | **P0** | Direction, Membres |
-| 2.3 | **Cadre de Conformité & Label de Prestige** | 18 | 🔨 v3 en finalisation | **P0** | Auditeurs, Membres |
-| 2.4 | **Manifeste Philosophique (L'Esprit Boréal)** | 10 | ✅ v1.0 validé | — | Communication, Partenaires |
-| 2.5 | **Protocole de Symbiose (adhésion membres)** | 8 | ❌ À créer | **P1** | Direction, Nouveaux membres |
+| \#   | Document                                  | Pages | Statut                | Priorité | Audience                    |
+|-----|-------------------------------------------|-------|-----------------------|----------|-----------------------------|
+| 2.1 | **Charte Fondatrice**                         | 12    | ✅ v2.1 validée        | —        | Fondateurs, Conseil         |
+| 2.2 | **Règlement de Régie Interne (sociocratie)**  | 20    | 🔨 v3 en finalisation | **P0**       | Direction, Membres          |
+| 2.3 | **Cadre de Conformité & Label de Prestige**   | 18    | 🔨 v3 en finalisation | **P0**       | Auditeurs, Membres          |
+| 2.4 | **Manifeste Philosophique (L'Esprit Boréal)** | 10    | ✅ v1.0 validé         | —        | Communication, Partenaires  |
+| 2.5 | **Protocole de Symbiose (adhésion membres)**  | 8     | ❌ À créer             | **P1**       | Direction, Nouveaux membres |
 
 **Impact business :**
+
 - Clarté des rôles et responsabilités (réduction litiges)
 - Processus décisionnel explicite (vélocité organisationnelle)
 - Label différenciateur (positionnement marché)
 
 **Conformité :**
+
 - Alignement Code civil du Québec (associations)
 - Préparation future constitution OBNL (2027)
 
@@ -78,17 +80,19 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **3. Conformité & Standards externes — 70% complet 📋**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 3.1 | **Carte d'Équivalence Standards (ISO 27001, SOC 2, NIST)** | 12 | 📝 Draft v1.0 | **P2** | Auditeurs, Conformité |
-| 3.2 | **Guide de l'Auditeur Pair (checklist Label)** | 10 | ❌ À créer | **P2** | Auditeurs internes |
+| \#   | Document                                               | Pages | Statut        | Priorité | Audience              |
+|-----|--------------------------------------------------------|-------|---------------|----------|-----------------------|
+| 3.1 | **Carte d'Équivalence Standards (ISO 27001, SOC 2, NIST)** | 12    | 📝 Draft v1.0 | **P2**       | Auditeurs, Conformité |
+| 3.2 | **Guide de l'Auditeur Pair (checklist Label)**             | 10    | ❌ À créer     | **P2**       | Auditeurs internes    |
 
 **Impact business :**
+
 - Reconnaissance externe (appels d'offres gouvernementaux)
 - Équivalence avec certifications coûteuses (ISO 27001 ~$15-30k)
 - Facilitation audits clients (réduction charge admin)
 
 **Standards couverts :**
+
 - ISO/IEC 27001 (ISMS)
 - SOC 2 Type II (Trust Services Criteria)
 - NIST Cybersecurity Framework
@@ -101,17 +105,19 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **4. Infrastructure & Réseau (C1-C2) — 60% complet 🌐**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 4.1 | **Opération DNS Fédérée** | 12 | ⚠️ v0.9 pré-v3 | **P1** | Ops Réseau, SysAdmin |
-| 4.2 | **Protocole DNSSEC & Délégations** | 8 | ❌ À créer | **P2** | Ops Réseau |
+| \#   | Document                       | Pages | Statut         | Priorité | Audience             |
+|-----|--------------------------------|-------|----------------|----------|----------------------|
+| 4.1 | **Opération DNS Fédérée**          | 12    | ⚠️ v0.9 pré-v3 | **P1**       | Ops Réseau, SysAdmin |
+| 4.2 | **Protocole DNSSEC & Délégations** | 8     | ❌ À créer      | **P2**       | Ops Réseau           |
 
 **Impact business :**
+
 - Autonomie DNS (pas de dépendance fournisseurs)
 - Résilience (redondance entre membres)
 - Conformité DNSSEC (sécurité, confiance)
 
 **Technologies :**
+
 - PowerDNS (authoritative)
 - AXFR (transferts sécurisés)
 - DNSSEC (signatures cryptographiques)
@@ -120,18 +126,20 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **5. Forge & Supply Chain (C4) — 40% complet 🔧**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 5.1 | **Guide Contribution Forge C4 (workflows Git, CI/CD)** | 14 | ❌ À créer | **P1** | Développeurs, DevOps |
-| 5.2 | **Protocole Signatures & Attestations (SBOM, SLSA)** | 10 | ❌ À créer | **P2** | DevSecOps, Conformité |
-| 5.3 | **Standards Interopérabilité Technique** | 16 | ✅ v1.0 finalisé | — | Tous profils techniques |
+| \#   | Document                                           | Pages | Statut          | Priorité | Audience                |
+|-----|----------------------------------------------------|-------|-----------------|----------|-------------------------|
+| 5.1 | **Guide Contribution Forge C4 (workflows Git, CI/CD)** | 14    | ❌ À créer       | **P1**       | Développeurs, DevOps    |
+| 5.2 | **Protocole Signatures & Attestations (SBOM, SLSA)**   | 10    | ❌ À créer       | **P2**       | DevSecOps, Conformité   |
+| 5.3 | **Standards Interopérabilité Technique**               | 16    | ✅ v1.0 finalisé | —        | Tous profils techniques |
 
 **Impact business :**
+
 - Supply chain sécurisée (traçabilité complète)
 - Conformité SLSA (Software Supply Chain Levels)
 - Réduction incidents (tests automatisés)
 
 **Technologies :**
+
 - Forgejo/GitLab (forge)
 - Sigstore/Cosign (signatures)
 - SBOM (Software Bill of Materials)
@@ -141,18 +149,20 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **6. Pivot & Services (C5-C6) — 50% complet 🔄**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 6.1 | **Processus d'Ensemencement (onboarding)** | 12 | ⚠️ v0.9 pré-v3 | **P1** | Direction, Parrains |
-| 6.2 | **Kit Démarrage Nouveau Tenant** | 8 | ❌ À créer | **P2** | Nouveaux membres |
-| 6.3 | **Architecture FastAPI Pivot (spec technique)** | 10 | ❌ À créer | **P2** | Architectes, DevOps |
+| \#   | Document                                    | Pages | Statut         | Priorité | Audience            |
+|-----|---------------------------------------------|-------|----------------|----------|---------------------|
+| 6.1 | **Processus d'Ensemencement (onboarding)**      | 12    | ⚠️ v0.9 pré-v3 | **P1**       | Direction, Parrains |
+| 6.2 | **Kit Démarrage Nouveau Tenant**                | 8     | ❌ À créer      | **P2**       | Nouveaux membres    |
+| 6.3 | **Architecture FastAPI Pivot (spec technique)** | 10    | ❌ À créer      | **P2**       | Architectes, DevOps |
 
 **Impact business :**
+
 - Onboarding structuré (réduction time-to-value)
 - Autonomie tenants (self-service via API)
 - Portabilité garantie (pas de lock-in)
 
 **Technologies :**
+
 - FastAPI (Python)
 - Keycloak/Authentik (SSO)
 - Prometheus/Grafana (observabilité)
@@ -163,25 +173,28 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **7. Sécurité transversale — 40% complet 🛡️**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 7.1 | **Charte de Résilience Organique (sécurité par couche)** | 16 | ❌ À créer | **P2** | RSSI, Conformité |
-| 7.2 | **Garde de l'Intimité Numérique (Loi 25, RGPD)** | 14 | ❌ À créer | **P2** | DPO, Juridique |
-| 7.3 | **Protocole Régénération & Incidents (post-mortems)** | 10 | ❌ À créer | **P1** | Ops, SRE |
+| \#   | Document                                             | Pages | Statut    | Priorité | Audience         |
+|-----|------------------------------------------------------|-------|-----------|----------|------------------|
+| 7.1 | **Charte de Résilience Organique (sécurité par couche)** | 16    | ❌ À créer | **P2**       | RSSI, Conformité |
+| 7.2 | **Garde de l'Intimité Numérique (Loi 25, RGPD)**         | 14    | ❌ À créer | **P2**       | DPO, Juridique   |
+| 7.3 | **Protocole Régénération & Incidents (post-mortems)**    | 10    | ❌ À créer | **P1**       | Ops, SRE         |
 
 **Impact business :**
+
 - Conformité Loi 25 (obligatoire Québec)
 - Conformité RGPD (clients européens)
 - Réduction MTTR (procédures claires)
 - Protection réputation (gestion crises)
 
 **Conformité légale :**
+
 - ✅ Loi 25 (protection renseignements personnels)
 - ✅ RGPD (si applicable)
 - ✅ Notification autorités (délais conformes)
 - ✅ Droits des personnes (accès, rectification, effacement)
 
 **Frameworks sécurité :**
+
 - ISO 27001 (ISMS)
 - NIST CSF (Identify, Protect, Detect, Respond, Recover)
 - OWASP (sécurité applicative)
@@ -192,12 +205,13 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **8. Modèle économique — 30% complet 💰**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 8.1 | **Économie de la Sève (cotisations + banque temps)** | 14 | ❌ À créer | **P1** | Direction, Trésorier |
-| 8.2 | **Registraire (structure YAML, API)** | 8 | 📝 À documenter | **P3** | Technique, Gouvernance |
+| \#   | Document                                         | Pages | Statut          | Priorité | Audience               |
+|-----|--------------------------------------------------|-------|-----------------|----------|------------------------|
+| 8.1 | **Économie de la Sève (cotisations + banque temps)** | 14    | ❌ À créer       | **P1**       | Direction, Trésorier   |
+| 8.2 | **Registraire (structure YAML, API)**                | 8     | 📝 À documenter | **P3**       | Technique, Gouvernance |
 
 **Impact business :**
+
 - Soutenabilité financière (projections 3 ans)
 - Diversification revenus (cotisations + banque temps)
 - Transparence financière (confiance membres)
@@ -205,11 +219,11 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 **Projections financières (réalistes) :**
 
-| Année | Membres | Cotisations | Subventions | Total revenus | Dépenses | Solde |
-|-------|---------|-------------|-------------|---------------|----------|-------|
-| 1 (2025) | 5 | 5k$ | 0 | 5k$ | 6k$ | -1k$ ✅ |
-| 2 (2026) | 15 | 18k$ | 10k$ | 28k$ | 24k$ | +4k$ ✅ |
-| 3 (2027) | 25 | 30k$ | 15k$ | 45k$ | 35k$ | +10k$ ✅ |
+| Année    | Membres | Cotisations | Subventions | Total revenus | Dépenses | Solde   |
+|----------|---------|-------------|-------------|---------------|----------|---------|
+| 1 (2025) | 5       | 5k$         | 0           | 5k$           | 6k$      | \-1k$ ✅  |
+| 2 (2026) | 15      | 18k$        | 10k$        | 28k$          | 24k$     | +4k$ ✅  |
+| 3 (2027) | 25      | 30k$        | 15k$        | 45k$          | 35k$     | +10k$ ✅ |
 
 **Réserve cible :** 6 mois de dépenses courantes (année 3)
 
@@ -219,12 +233,13 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **9. Documentation & Transmission — 30% complet 📖**
 
-| # | Document | Pages | Statut | Priorité | Audience |
-|---|----------|-------|--------|----------|----------|
-| 9.1 | **Runbooks Opérationnels (par couche C1-C8)** | 20+ | 📝 Fragmentés | **P3** | Ops, SRE |
-| 9.2 | **Mémoire Collective & ΔLogs (apprentissage)** | 8 | ❌ À créer | **P2** | Direction, Auditeurs |
+| \#   | Document                                   | Pages | Statut        | Priorité | Audience             |
+|-----|--------------------------------------------|-------|---------------|----------|----------------------|
+| 9.1 | **Runbooks Opérationnels (par couche C1-C8)**  | 20+   | 📝 Fragmentés | **P3**       | Ops, SRE             |
+| 9.2 | **Mémoire Collective & ΔLogs (apprentissage)** | 8     | ❌ À créer     | **P2**       | Direction, Auditeurs |
 
 **Impact business :**
+
 - Réduction dépendance personnes-clés
 - Onboarding accéléré (documentation claire)
 - Amélioration continue (leçons capitalisées)
@@ -238,15 +253,18 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 #### **MOIS 1 — NOVEMBRE 2025 : Fondations gouvernance** ⚡
 
 **Sprint 1 (sem 1-2) :**
+
 - ✅ Finaliser Règlement de Régie Interne v3
 - ✅ Finaliser Cadre Conformité & Label v3
 - ✅ Créer Protocole de Symbiose v1
 
 **Sprint 2 (sem 3-4) :**
+
 - ✅ Créer Protocole Régénération Incidents v1
 - ✅ Transformer Opération DNS Fédérée → v3
 
 **Livrables critiques :**
+
 - 5 documents finalisés
 - Gouvernance opérationnelle
 - Cadre légal complet
@@ -256,14 +274,17 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 #### **MOIS 2 — DÉCEMBRE 2025 : Opérations techniques** 🔧
 
 **Sprint 3 (sem 1-2) :**
+
 - ✅ Créer Guide Contribution Forge C4 v1
 - ✅ Transformer Onboarding → Ensemencement v3
 
 **Sprint 4 (sem 3-4) :**
+
 - ✅ Créer Économie de la Sève v1
 - ✅ Créer Kit Démarrage Tenant v1
 
 **Livrables critiques :**
+
 - 4 documents finalisés
 - Supply chain sécurisée
 - Modèle économique documenté
@@ -273,14 +294,17 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 #### **MOIS 3 — JANVIER 2026 : Résilience & conformité** 🛡️
 
 **Sprint 5 (sem 1-2) :**
+
 - ✅ Créer Charte Résilience Organique v1
 - ✅ Créer Garde de l'Intimité Numérique v1
 
 **Sprint 6 (sem 3-4) :**
+
 - ✅ Créer Guide Auditeur Pair v1
 - ✅ Compléter Carte Équivalence Standards
 
 **Livrables critiques :**
+
 - 4 documents finalisés
 - Conformité Loi 25/RGPD
 - Label audit-ready
@@ -291,21 +315,21 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 #### **Ressources humaines requises :**
 
-| Profil | Heures/mois | Phase critique |
-|--------|-------------|----------------|
-| **Direction / Coordination** | 20-30h | Mois 1-2 |
-| **Technique (DevOps/SRE)** | 15-20h | Mois 2-3 |
-| **Conformité / Juridique** | 10-15h | Mois 1, 3 |
-| **Documentation** | 10-15h | Continu |
+| Profil                   | Heures/mois | Phase critique |
+|--------------------------|-------------|----------------|
+| **Direction / Coordination** | 20-30h      | Mois 1-2       |
+| **Technique (DevOps/SRE)**   | 15-20h      | Mois 2-3       |
+| **Conformité / Juridique**   | 10-15h      | Mois 1, 3      |
+| **Documentation**            | 10-15h      | Continu        |
 
 #### **Coûts externes (optionnels) :**
 
-| Poste | Coût | Justification |
-|-------|------|---------------|
+| Poste                                  | Coût  | Justification                |
+|----------------------------------------|-------|------------------------------|
 | Révision juridique (Charte, Règlement) | 2-3k$ | Validation conformité Québec |
-| Audit externe (Label pilote) | 1-2k$ | Crédibilité externe |
-| Formation sociocratie (équipe) | 1-2k$ | Gouvernance efficace |
-| **Total estimé** | **4-7k$** | Investissement année 1 |
+| Audit externe (Label pilote)           | 1-2k$ | Crédibilité externe          |
+| Formation sociocratie (équipe)         | 1-2k$ | Gouvernance efficace         |
+| **Total estimé**                           | **4-7k$** | Investissement année 1       |
 
 ---
 
@@ -313,23 +337,23 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **12. KPIs documentaires**
 
-| Indicateur | Cible 3 mois | Cible 6 mois | Mesure |
-|------------|--------------|--------------|--------|
-| **Documents critiques finalisés** | 90% | 100% | Checklist |
-| **Conformité Loi 25** | 80% | 100% | Audit interne |
-| **Standards Interop implémentés** | 75% | 90% | Tests techniques |
-| **Membres onboardés avec succès** | 2 | 5 | Feedback membres |
-| **Incidents documentés (post-mortem)** | 100% | 100% | ΔLogs |
+| Indicateur                         | Cible 3 mois | Cible 6 mois | Mesure           |
+|------------------------------------|--------------|--------------|------------------|
+| **Documents critiques finalisés**      | 90%          | 100%         | Checklist        |
+| **Conformité Loi 25**                  | 80%          | 100%         | Audit interne    |
+| **Standards Interop implémentés**      | 75%          | 90%          | Tests techniques |
+| **Membres onboardés avec succès**      | 2            | 5            | Feedback membres |
+| **Incidents documentés (post-mortem)** | 100%         | 100%         | ΔLogs            |
 
 ### **13. KPIs business**
 
-| Indicateur | Cible An 1 | Cible An 2 | Mesure |
-|------------|------------|------------|--------|
-| **Membres actifs** | 5 | 15 | Registraire |
-| **Labels attribués** | 3 Bronze | 10 (Bronze-Argent) | Audits |
-| **Disponibilité DNS** | >99.5% | >99.8% | Monitoring |
-| **Solde trésorerie** | -1k$ ✅ | +4k$ | Comptabilité |
-| **Satisfaction membres** | >4/5 | >4.5/5 | Sondages |
+| Indicateur           | Cible An 1 | Cible An 2         | Mesure       |
+|----------------------|------------|--------------------|--------------|
+| **Membres actifs**       | 5          | 15                 | Registraire  |
+| **Labels attribués**     | 3 Bronze   | 10 (Bronze-Argent) | Audits       |
+| **Disponibilité DNS**    | \>99.5%     | \>99.8%             | Monitoring   |
+| **Solde trésorerie**     | \-1k$ ✅     | +4k$               | Comptabilité |
+| **Satisfaction membres** | \>4/5       | \>4.5/5             | Sondages     |
 
 ---
 
@@ -337,13 +361,13 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 ### **14. Risques identifiés & mitigations**
 
-| Risque | Probabilité | Impact | Mitigation |
-|--------|-------------|--------|------------|
-| **Charge documentation sous-estimée** | Moyenne | Moyen | Priorisation stricte (P0-P1 seulement) |
-| **Départ fondateur clé** | Faible | Élevé | Documentation exhaustive + redondance |
-| **Non-conformité Loi 25** | Faible | Critique | Révision juridique externe |
-| **Croissance trop rapide** | Faible | Moyen | Processus onboarding strict |
-| **Conflits gouvernance** | Moyenne | Moyen | Sociocratie + médiation formalisée |
+| Risque                            | Probabilité | Impact   | Mitigation                             |
+|-----------------------------------|-------------|----------|----------------------------------------|
+| **Charge documentation sous-estimée** | Moyenne     | Moyen    | Priorisation stricte (P0-P1 seulement) |
+| **Départ fondateur clé**              | Faible      | Élevé    | Documentation exhaustive + redondance  |
+| **Non-conformité Loi 25**             | Faible      | Critique | Révision juridique externe             |
+| **Croissance trop rapide**            | Faible      | Moyen    | Processus onboarding strict            |
+| **Conflits gouvernance**              | Moyenne     | Moyen    | Sociocratie + médiation formalisée     |
 
 ---
 
@@ -362,6 +386,7 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 ### Prochaine étape immédiate
 
 **Action requise (cette semaine) :**
+
 - [ ] Validation plan par fondateurs
 - [ ] Allocation ressources (20-30h direction, 15-20h technique)
 - [ ] Lancement Sprint 1 (finalisation Règlement v3, Conformité v3)
@@ -383,4 +408,4 @@ L'Alliance Boréale se positionne comme une **fédération d'excellence techniqu
 
 📁 **Document source :** `docs/TODO_v3_biomimetique.md`  
 📅 **Prochaine revue :** 27 janvier 2026  
-✍️ **Responsable :** Président + Cercle Stratégique
+✍️ **Responsable :** Président + Cercle Stratégique
\ No newline at end of file
diff --git a/docs/constitution/03_Cadre_Conformite_Label_Prestige.md b/docs/constitution/03_Cadre_Conformite_Label_Prestige.md
index a0b0eee..90e9857 100644
--- a/docs/constitution/03_Cadre_Conformite_Label_Prestige.md
+++ b/docs/constitution/03_Cadre_Conformite_Label_Prestige.md
@@ -1,15 +1,19 @@
 # Document 3 : Cadre de Conformité et Label de Prestige
 
 <!-- AB-Avis-de-réalignement 20251025-162438 -->
+
 ## Réalignement des couches & Portabilité des tenants
 
 ### Règle d’appartenance par couche
+
 - **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**.
 - **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**.
 - **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**.
 
 ### Principe de portabilité des tenants
+
 Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont :
+
 1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte).
 2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable.
 3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible.
@@ -18,203 +22,213 @@ Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans
 
 > **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**;  
 > les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus.
-<!-- /AB-Avis-de-réalignement 20251025-162438 -->
-
+> <!-- /AB-Avis-de-réalignement 20251025-162438 -->
 
 ## L'Alliance Boréale
-🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md)
-**Version:** 1.0
-**Date:** 23 octobre 2025
-**Statut:** Document fondateur
-**Adopté par :** Cercle Éthique & Conformité
-**Licence:** CC BY-SA 4.0
----
+
+###### 🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md) **Version:** 1.0 **Date:** 23 octobre 2025 **Statut:** Document fondateur **Adopté par :** Cercle Éthique & Conformité **Licence:** CC BY-SA 4.0
+
 ## PRÉAMBULE
+
 Le Label de Prestige de L'Alliance Boréale n'est pas un certificat marketing vide de sens.
-**C'est un outil de transparence, d'amélioration continue, et de reconnaissance mutuelle.**
-**Trois objectifs complémentaires :**
-1. **Transparence envers le public**
-   Permettre aux utilisateurs finaux de choisir en connaissance de cause (quel membre respecte quelles pratiques).
-2. **Amélioration continue des membres**
-   Le label est un miroir. Il montre où nous excellons et où nous devons progresser.
-3. **Reconnaissance entre pairs**
-   Le label est décerné PAR les membres POUR les membres. C'est une validation par ceux qui connaissent vraiment les défis du terrain.
-**Ce que le label N'EST PAS :**
+**C'est un outil de transparence, d'amélioration continue, et de reconnaissance mutuelle.Trois objectifs complémentaires :**
+
+1. **Transparence envers le public** Permettre aux utilisateurs finaux de choisir en connaissance de cause (quel membre respecte quelles pratiques).
+2. **Amélioration continue des membres** Le label est un miroir. Il montre où nous excellons et où nous devons progresser.
+3. **Reconnaissance entre pairs** Le label est décerné PAR les membres POUR les membres. C'est une validation par ceux qui connaissent vraiment les défis du terrain. **Ce que le label N'EST PAS :**
+
 - ❌ Une certification ISO bureaucratique
 - ❌ Un outil de compétition toxique (classement, ranking public)
 - ❌ Une barrière à l'entrée (le label est volontaire, pas obligatoire)
-- ❌ Une garantie absolue (même les meilleurs peuvent avoir des incidents)
-**Le label est un processus vivant.** Il évolue avec L'Alliance, nos apprentissages, et l'écosystème numérique.
+- ❌ Une garantie absolue (même les meilleurs peuvent avoir des incidents) **Le label est un processus vivant.** Il évolue avec L'Alliance, nos apprentissages, et l'écosystème numérique.
+
 ---
+
 ## SECTION 1 : ARCHITECTURE DU LABEL
+
 ### 1.1 Les 6 Domaines d'Évaluation
 
 (couvrant l’ensemble des 8 couches : Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie/Éthique)
 
 Le label évalue les pratiques selon **6 domaines** couvrant l'ensemble des couches de l'architecture boréale (couches 1-8 (Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie)).
+
 #### Domaine 1 : Infrastructure & Résilience (Couches 1-3 (Physique, Réseau, Virtualisation))
+
 **Objectif :** Garantir la disponibilité, la durabilité, et la réparabilité de l'infrastructure physique et réseau.
 **Thématiques couvertes :**
+
 - Hardware (serveurs, stockage, énergie)
 - Réseau (bande passante, latence, redondance)
 - Stockage (backups, réplication, chiffrement)
 - Monitoring (métriques, alerting)
-- Plans de reprise (disaster recovery, RTO/RPO)
-**Exemples de critères :**
+- Plans de reprise (disaster recovery, RTO/RPO) **Exemples de critères :**
 - Disponibilité mesurée > 99% (hors maintenance planifiée)
 - Backups testés mensuellement
 - Documentation à jour de l'infrastructure
 - Énergie renouvelable > 50% (si contrôle direct) ou hébergeur vert
+
 ---
+
 #### Domaine 2 : Sécurité & Vie Privée (Couches 2-5 (Réseau, Virtualisation, Orchestration, Supervision))
+
 **Objectif :** Protéger les données des utilisateurs et prévenir les intrusions, conformément aux lois (Loi 25, RGPD).
 **Thématiques couvertes :**
+
 - Chiffrement (transit, repos, backups)
 - Authentification (MFA, politiques mots de passe)
 - Gestion des accès (principe moindre privilège)
 - Mises à jour de sécurité (délais, automation)
 - Conformité légale (Loi 25, RGPD)
-- Gestion des incidents de sécurité
-**Exemples de critères :**
+- Gestion des incidents de sécurité **Exemples de critères :**
 - TLS 1.3 obligatoire (pas de TLS 1.0/1.1)
 - MFA activée pour accès admin
 - Patches critiques appliqués < 7 jours après publication
 - Politique de confidentialité publique et conforme
 - Registre des traitements de données (RGPD Article 30)
+
 ---
+
 #### Domaine 3 : Interopérabilité & Standards Ouverts (Couches 3-6 (Virtualisation, Orchestration, Supervision, Services))
+
 **Objectif :** Garantir que les services respectent les standards ouverts et facilitent la portabilité des données.
 **Thématiques couvertes :**
+
 - Protocoles ouverts (SMTP, IMAP, CalDAV, WebDAV, XMPP/Matrix, etc.)
 - Formats de données (pas de lock-in propriétaire)
 - APIs documentées (si applicable)
 - Export de données (RGPD Article 20)
-- Fédération (si applicable)
-**Exemples de critères :**
+- Fédération (si applicable) **Exemples de critères :**
 - Email via SMTP/IMAP (pas uniquement webmail propriétaire)
 - Calendrier accessible via CalDAV (pas uniquement app propriétaire)
 - Export complet des données utilisateur en < 30 jours
 - APIs publiquement documentées (si services API)
 - Support de standards de fédération (Matrix, ActivityPub, etc.)
+
 ---
+
 #### Domaine 4 : Logiciels Libres & Éthique (Couches 5-7 (Supervision, Services, Gouvernance & données))
+
 **Objectif :** Promouvoir l'usage de logiciels libres et l'alignement avec les valeurs de L'Alliance.
 **Thématiques couvertes :**
+
 - Pourcentage de stack libre (OS, applications, outils)
 - Contribution à l'écosystème libre (patches, donations, sponsoring)
 - Transparence sur les dépendances propriétaires
 - Éthique des fournisseurs (pas de GAFAM pour services critiques)
-- Gouvernance interne (démocratie, transparence)
-**Exemples de critères :**
+- Gouvernance interne (démocratie, transparence) **Exemples de critères :**
 - ≥ 80% de la stack en logiciel libre
 - Au moins 1 contribution annuelle à un projet libre
 - Aucune dépendance critique aux GAFAM (AWS, GCP, Azure pour prod)
 - Publication de la liste des dépendances (transparence)
 - Gouvernance démocratique ou coopérative (si applicable)
+
 ---
+
 #### Domaine 5 : Opérations & Documentation (Couches 4-7 (Orchestration, Supervision, Services, Gouvernance & données))
+
 **Objectif :** Garantir la qualité opérationnelle, la traçabilité, et la transmissibilité des pratiques.
 **Thématiques couvertes :**
+
 - Infrastructure as Code (IaC)
 - Documentation technique (runbooks, architectures)
 - Gestion des incidents (post-mortems, déclarations)
 - Monitoring et observabilité
-- Automatisation (CI/CD, tests)
-**Exemples de critères :**
+- Automatisation (CI/CD, tests) **Exemples de critères :**
 - IaC pour ≥ 70% de l'infrastructure
 - Runbooks à jour pour procédures critiques
 - Post-mortem publié pour tout incident P0/P1
 - Métriques de disponibilité publiques (status page)
 - Tests automatisés pour changements critiques
+
 ---
+
 #### Domaine 6 : Sobriété Numérique & Durabilité (Toutes Couches)
+
 **Objectif :** Mesurer et réduire l'empreinte écologique du numérique.
 **Thématiques couvertes :**
+
 - Consommation énergétique (mesure, réduction)
 - Durée de vie du matériel (allongement, réparation)
 - Optimisation des ressources (CPU, RAM, stockage, bande passante)
 - Sensibilisation des utilisateurs (bonnes pratiques)
-- Compensation carbone (optionnel mais valorisé)
-**Exemples de critères :**
+- Compensation carbone (optionnel mais valorisé) **Exemples de critères :**
 - Mesure de la consommation énergétique (kWh/mois)
 - Serveurs utilisés > 5 ans (si fonctionnels)
 - Politique de rétention des données (suppression automatique)
 - Guide utilisateur sur sobriété numérique
-- Hébergement dans datacenter < 1.3 PUE (Power Usage Effectiveness)
----### 1.2 Les 4 Niveaux de Label
-Le label comporte 4 niveaux progressifs. Chaque niveau nécessite un score minimal dans chaque domaine ET un score global minimal.
+- Hébergement dans datacenter < 1.3 PUE (Power Usage Effectiveness) ---### 1.2 Les 4 Niveaux de Label Le label comporte 4 niveaux progressifs. Chaque niveau nécessite un score minimal dans chaque domaine ET un score global minimal.
+
 #### Niveau Bronze (Fondations)
+
 **Symbolique :** Engagement initial, bases solides.
 **Critères :**
+
 - Score minimal par domaine : **40/100**
 - Score global minimal : **50/100**
-- Durée de validité : **12 mois**
-**Profil type :**
-Nouveau membre ayant déployé les fondations (DNS, sécurité de base, documentation minimale), mais avec marges d'amélioration importantes.
-**Autorisations :**
+- Durée de validité : **12 moisProfil type :** Nouveau membre ayant déployé les fondations (DNS, sécurité de base, documentation minimale), mais avec marges d'amélioration importantes. **Autorisations :**
 - Usage du badge "Alliance Boréale — Bronze"
 - Mention sur site web et communications
 - Accès aux outils communs (Matrix, forge, wiki)
+
 ---
+
 #### Niveau Argent (Maturité)
+
 **Symbolique :** Maturité opérationnelle, pratiques établies.
 **Critères :**
+
 - Score minimal par domaine : **60/100**
 - Score global minimal : **65/100**
-- Durée de validité : **12 mois**
-**Profil type :**
-Membre avec infrastructure robuste, documentation solide, participation active, mais n'ayant pas encore atteint l'excellence dans tous les domaines.
-**Autorisations :**
+- Durée de validité : **12 moisProfil type :** Membre avec infrastructure robuste, documentation solide, participation active, mais n'ayant pas encore atteint l'excellence dans tous les domaines. **Autorisations :**
 - Usage du badge "Alliance Boréale — Argent"
 - Participation comme auditeur pair (avec formation)
 - Mention prioritaire dans annuaire public
+
 ---
+
 #### Niveau Or (Excellence)
+
 **Symbolique :** Excellence technique et éthique, référence pour les pairs.
 **Critères :**
+
 - Score minimal par domaine : **75/100**
 - Score global minimal : **80/100**
 - Durée de validité : **12 mois**
-- Obligation : Au moins 1 contribution significative à L'Alliance (code, doc, formation)
-**Profil type :**
-Membre exemplaire, peu d'incidents, documentation exhaustive, forte contribution à la communauté, alignement éthique démontré.
-**Autorisations :**
+- Obligation : Au moins 1 contribution significative à L'Alliance (code, doc, formation) **Profil type :** Membre exemplaire, peu d'incidents, documentation exhaustive, forte contribution à la communauté, alignement éthique démontré. **Autorisations :**
 - Usage du badge "Alliance Boréale — Or"
 - Rôle de mentor pour nouveaux membres
 - Participation au Cercle Éthique (si élu)
 - Mention comme "Membre Exemplaire" dans communications
+
 ---
+
 #### Niveau Platine (Avant-garde)
+
 **Symbolique :** Innovation, leadership, modèle inspirant.
 **Critères :**
+
 - Score minimal par domaine : **85/100**
 - Score global minimal : **90/100**
 - Durée de validité : **18 mois** (reconnaissance de l'excellence soutenue)
-- Obligation : Au moins 2 contributions majeures à L'Alliance OU leadership d'un projet fédéral
-**Profil type :**
-Membre d'avant-garde, zéro incident P0 sur 12 mois, innovations partagées, mentorat actif, alignement éthique parfait, inspiration pour l'écosystème.
-**Autorisations :**
+- Obligation : Au moins 2 contributions majeures à L'Alliance OU leadership d'un projet fédéral **Profil type :** Membre d'avant-garde, zéro incident P0 sur 12 mois, innovations partagées, mentorat actif, alignement éthique parfait, inspiration pour l'écosystème. **Autorisations :**
 - Usage du badge "Alliance Boréale — Platine"
 - Reconnaissance publique (cas d'étude, conférences)
 - Invitation automatique aux cercles stratégiques
-- Droit de veto éthique (cas exceptionnels)
-**Rare et mérité :**
-Le Platine n'est pas un objectif pour tous. C'est une reconnaissance de l'excellence soutenue et de l'impact sur l'ensemble de L'Alliance.
+- Droit de veto éthique (cas exceptionnels) **Rare et mérité :** Le Platine n'est pas un objectif pour tous. C'est une reconnaissance de l'excellence soutenue et de l'impact sur l'ensemble de L'Alliance.
+
 ---
+
 ### 1.3 Calcul du Score
+
 #### 1.3.1 Notation par Domaine
+
 Chaque domaine est noté sur **100 points**.
 **Structure :**
+
 - Critères obligatoires (60 points)
 - Critères recommandés (30 points)
-- Critères d'excellence (10 points)
-**Critères obligatoires (60 pts) :**
-Fondations indispensables. Échec = score plafonné à 59/100 dans le domaine.
-**Critères recommandés (30 pts) :**
-Bonnes pratiques. Permettent d'atteindre scores Argent/Or.
-**Critères d'excellence (10 pts) :**
-Innovation, avant-garde. Nécessaires pour Or/Platine.
-**Exemple (Domaine 2 : Sécurité) :**
+- Critères d'excellence (10 points) **Critères obligatoires (60 pts) :** Fondations indispensables. Échec = score plafonné à 59/100 dans le domaine. **Critères recommandés (30 pts) :** Bonnes pratiques. Permettent d'atteindre scores Argent/Or. **Critères d'excellence (10 pts) :** Innovation, avant-garde. Nécessaires pour Or/Platine. **Exemple (Domaine 2 : Sécurité) :**
+
 ```
 Critères obligatoires (60 pts) :
 - TLS 1.2+ sur tous les services publics (10 pts)
@@ -234,335 +248,411 @@ Critères d'excellence (10 pts) :
 - Bug bounty program (3 pts)
 - Certification ISO 27001 ou équivalent (2 pts)
 ```
-**Total domaine :** Maximum 100 pts.
----
+
+## **Total domaine :** Maximum 100 pts.
+
 #### 1.3.2 Score Global
+
 **Calcul :**
+
 ```
 Score Global = Moyenne des 6 domaines
 ```
+
 **Exemple :**
-| Domaine | Score |
-|---------|-------|
-| Infrastructure | 75 |
-| Sécurité | 80 |
-| Interopérabilité | 70 |
-| Logiciels Libres | 85 |
-| Opérations | 65 |
-| Sobriété | 60 |
-| **Moyenne** | **72.5** |
-→ Niveau : **Argent** (score global 72.5, tous domaines ≥ 60)
-**Règle importante :**
-Un domaine faible (< seuil) empêche l'accès au niveau supérieur, même si le score global est élevé.
-**Rationale :** Éviter les membres "spécialisés" qui excellent dans 4 domaines mais négligent 2 autres. L'Alliance promeut l'excellence équilibrée.
+
+| Domaine                                                                                                                                         | Score |
+|-------------------------------------------------------------------------------------------------------------------------------------------------|-------|
+| Infrastructure                                                                                                                                  | 75    |
+| Sécurité                                                                                                                                        | 80    |
+| Interopérabilité                                                                                                                                | 70    |
+| Logiciels Libres                                                                                                                                | 85    |
+| Opérations                                                                                                                                      | 65    |
+| Sobriété                                                                                                                                        | 60    |
+| **Moyenne**                                                                                                                                         | **72.5**  |
+| → Niveau : **Argent** (score global 72.5, tous domaines ≥ 60)                                                                                       |       |
+| **Règle importante :**                                                                                                                              |       |
+| Un domaine faible (< seuil) empêche l'accès au niveau supérieur, même si le score global est élevé.                                             |       |
+| **Rationale :** Éviter les membres "spécialisés" qui excellent dans 4 domaines mais négligent 2 autres. L'Alliance promeut l'excellence équilibrée. |       |
+
 ---
+
 #### 1.3.3 Pondération (Future Évolution)
+
 **Version 1.0 (ce document) :** Tous les domaines ont le même poids (1/6).
 **Version future (2027+) :** Possibilité d'introduire pondération si consensus :
+
 - Exemple : Sécurité 25%, Interopérabilité 20%, autres 11% chacun
-- Nécessite amendement de ce document (Section 7)
-**Rationale de l'égalité actuelle :**
-En phase pilote, nous voulons observer quels domaines sont les plus critiques avant d'introduire une pondération.
+- Nécessite amendement de ce document (Section 7) **Rationale de l'égalité actuelle :** En phase pilote, nous voulons observer quels domaines sont les plus critiques avant d'introduire une pondération.
+
 ---
+
 ## SECTION 2 : GRILLES D'ÉVALUATION DÉTAILLÉES
+
 ### 2.1 Domaine 1 : Infrastructure & Résilience
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 1.1 | Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée) | 10 | Métriques monitoring (Prometheus, Grafana, status page) |
-| 1.2 | Backup automatisé quotidien | 10 | Configuration (cron, script, logs) |
-| 1.3 | Test de restauration réussi dans les 6 derniers mois | 10 | Rapport de test (date, procédure, résultat) |
-| 1.4 | Monitoring actif avec alerting | 10 | Alertmanager configuré, logs d'alertes |
-| 1.5 | Documentation de l'architecture (diagramme + inventaire) | 10 | Wiki ou doc versionnée (Markdown, Diagrams.net) |
-| 1.6 | Plan de reprise documenté (RTO/RPO définis) | 10 | Document DRP (Disaster Recovery Plan) |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                            | Points | Preuve Requise                                          |
+|----------------------------|--------------------------------------------------------------------|--------|---------------------------------------------------------|
+| 1.1                        | Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée) | 10     | Métriques monitoring (Prometheus, Grafana, status page) |
+| 1.2                        | Backup automatisé quotidien                                        | 10     | Configuration (cron, script, logs)                      |
+| 1.3                        | Test de restauration réussi dans les 6 derniers mois               | 10     | Rapport de test (date, procédure, résultat)             |
+| 1.4                        | Monitoring actif avec alerting                                     | 10     | Alertmanager configuré, logs d'alertes                  |
+| 1.5                        | Documentation de l'architecture (diagramme + inventaire)           | 10     | Wiki ou doc versionnée (Markdown, Diagrams.net)         |
+| 1.6                        | Plan de reprise documenté (RTO/RPO définis)                        | 10     | Document DRP (Disaster Recovery Plan)                   |
+| **Total obligatoire :** 60 pts |                                                                    |        |                                                         |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 1.7 | Disponibilité ≥ 99.5% | 5 | Métriques monitoring |
-| 1.8 | Backup incrémental + complet hebdomadaire | 5 | Configuration (rsnapshot, Borg, etc.) |
-| 1.9 | Réplication géographique (2+ sites) | 5 | Preuve hébergement multi-sites |
-| 1.10 | Monitoring externe (tiers indépendant) | 5 | UptimeRobot, Pingdom, ou équivalent |
-| 1.11 | Redondance réseau (2+ liens internet) | 5 | Configuration BGP ou failover |
-| 1.12 | Infrastructure as Code ≥ 50% | 5 | Playbooks Ansible, Terraform, scripts |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                   | Points | Preuve Requise                        |
+|---------------------------|-------------------------------------------|--------|---------------------------------------|
+| 1.7                       | Disponibilité ≥ 99.5%                     | 5      | Métriques monitoring                  |
+| 1.8                       | Backup incrémental + complet hebdomadaire | 5      | Configuration (rsnapshot, Borg, etc.) |
+| 1.9                       | Réplication géographique (2+ sites)       | 5      | Preuve hébergement multi-sites        |
+| 1.10                      | Monitoring externe (tiers indépendant)    | 5      | UptimeRobot, Pingdom, ou équivalent   |
+| 1.11                      | Redondance réseau (2+ liens internet)     | 5      | Configuration BGP ou failover         |
+| 1.12                      | Infrastructure as Code ≥ 50%              | 5      | Playbooks Ansible, Terraform, scripts |
+| **Total recommandé :** 30 pts |                                           |        |                                       |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 1.13 | Disponibilité ≥ 99.9% (3 nines) | 5 | Métriques monitoring |
-| 1.14 | Chaos engineering (tests de résilience) | 3 | Rapports de tests (ex: ChaosMonkey, simulations) |
-| 1.15 | Infrastructure 100% IaC (reproductible) | 2 | Git repo complet |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 1 :** 100 pts
+
+| \#                         | Critère                                 | Points | Preuve Requise                                   |
+|---------------------------|-----------------------------------------|--------|--------------------------------------------------|
+| 1.13                      | Disponibilité ≥ 99.9% (3 nines)         | 5      | Métriques monitoring                             |
+| 1.14                      | Chaos engineering (tests de résilience) | 3      | Rapports de tests (ex: ChaosMonkey, simulations) |
+| 1.15                      | Infrastructure 100% IaC (reproductible) | 2      | Git repo complet                                 |
+| **Total excellence :** 10 pts |                                         |        |                                                  |
+| **TOTAL DOMAINE 1 :** 100 pts |                                         |        |                                                  |
+
 ---
+
 ### 2.2 Domaine 2 : Sécurité & Vie Privée
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 2.1 | TLS 1.2+ sur tous services publics | 10 | Scan SSL Labs (grade A- minimum) |
-| 2.2 | MFA activée pour accès administrateurs | 10 | Capture écran config (TOTP, U2F, etc.) |
-| 2.3 | Backups chiffrés (AES-256 ou équivalent) | 10 | Configuration de chiffrement |
-| 2.4 | Politique de confidentialité publique et conforme (Loi 25 ou RGPD) | 10 | URL de la politique + revue conformité |
-| 2.5 | Patches de sécurité critiques appliqués < 30 jours | 10 | Logs de mises à jour (apt, yum, etc.) |
-| 2.6 | Pare-feu configuré (ports nécessaires uniquement) | 10 | Sortie `iptables -L` ou équivalent |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                            | Points | Preuve Requise                         |
+|----------------------------|--------------------------------------------------------------------|--------|----------------------------------------|
+| 2.1                        | TLS 1.2+ sur tous services publics                                 | 10     | Scan SSL Labs (grade A- minimum)       |
+| 2.2                        | MFA activée pour accès administrateurs                             | 10     | Capture écran config (TOTP, U2F, etc.) |
+| 2.3                        | Backups chiffrés (AES-256 ou équivalent)                           | 10     | Configuration de chiffrement           |
+| 2.4                        | Politique de confidentialité publique et conforme (Loi 25 ou RGPD) | 10     | URL de la politique + revue conformité |
+| 2.5                        | Patches de sécurité critiques appliqués < 30 jours                 | 10     | Logs de mises à jour (apt, yum, etc.)  |
+| 2.6                        | Pare-feu configuré (ports nécessaires uniquement)                  | 10     | Sortie `iptables -L` ou équivalent       |
+| **Total obligatoire :** 60 pts |                                                                    |        |                                        |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 2.7 | TLS 1.3 uniquement (pas de 1.2) | 5 | Scan SSL Labs (grade A+) |
-| 2.8 | MFA proposée aux utilisateurs finaux | 5 | Capture écran option activable |
-| 2.9 | Patches de sécurité critiques < 7 jours | 10 | Logs mises à jour |
-| 2.10 | Registre des traitements RGPD (Article 30) | 5 | Document du registre |
-| 2.11 | Audit de sécurité externe annuel | 5 | Rapport d'audit (synthèse) |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                    | Points | Preuve Requise                 |
+|---------------------------|--------------------------------------------|--------|--------------------------------|
+| 2.7                       | TLS 1.3 uniquement (pas de 1.2)            | 5      | Scan SSL Labs (grade A+)       |
+| 2.8                       | MFA proposée aux utilisateurs finaux       | 5      | Capture écran option activable |
+| 2.9                       | Patches de sécurité critiques < 7 jours    | 10     | Logs mises à jour              |
+| 2.10                      | Registre des traitements RGPD (Article 30) | 5      | Document du registre           |
+| 2.11                      | Audit de sécurité externe annuel           | 5      | Rapport d'audit (synthèse)     |
+| **Total recommandé :** 30 pts |                                            |        |                                |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 2.12 | Zero-knowledge encryption (E2EE) | 5 | Architecture technique + audit |
-| 2.13 | Bug bounty program actif | 3 | URL du programme + règles |
-| 2.14 | Certification ISO 27001 ou SOC 2 | 2 | Certificat valide |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 2 :** 100 pts
+
+| \#                         | Critère                          | Points | Preuve Requise                 |
+|---------------------------|----------------------------------|--------|--------------------------------|
+| 2.12                      | Zero-knowledge encryption (E2EE) | 5      | Architecture technique + audit |
+| 2.13                      | Bug bounty program actif         | 3      | URL du programme + règles      |
+| 2.14                      | Certification ISO 27001 ou SOC 2 | 2      | Certificat valide              |
+| **Total excellence :** 10 pts |                                  |        |                                |
+| **TOTAL DOMAINE 2 :** 100 pts |                                  |        |                                |
+
 ---
+
 ### 2.3 Domaine 3 : Interopérabilité & Standards Ouverts
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 3.1 | Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire) | 15 | Configuration serveur (Postfix, Dovecot, etc.) |
-| 3.2 | Export complet des données utilisateur possible | 15 | Procédure documentée + test |
-| 3.3 | Formats de stockage ouverts (pas de lock-in propriétaire) | 10 | Liste formats utilisés (Markdown, JSON, SQL, etc.) |
-| 3.4 | DNS configuré selon standards (DNSSEC recommandé) | 10 | Validation DNSViz ou équivalent |
-| 3.5 | DKIM, SPF, DMARC configurés (si email) | 10 | Scan MXToolbox ou équivalent |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                        | Points | Preuve Requise                                     |
+|----------------------------|----------------------------------------------------------------|--------|----------------------------------------------------|
+| 3.1                        | Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire) | 15     | Configuration serveur (Postfix, Dovecot, etc.)     |
+| 3.2                        | Export complet des données utilisateur possible                | 15     | Procédure documentée + test                        |
+| 3.3                        | Formats de stockage ouverts (pas de lock-in propriétaire)      | 10     | Liste formats utilisés (Markdown, JSON, SQL, etc.) |
+| 3.4                        | DNS configuré selon standards (DNSSEC recommandé)              | 10     | Validation DNSViz ou équivalent                    |
+| 3.5                        | DKIM, SPF, DMARC configurés (si email)                         | 10     | Scan MXToolbox ou équivalent                       |
+| **Total obligatoire :** 60 pts |                                                                |        |                                                    |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 3.6 | Calendrier via CalDAV / Contacts via CardDAV | 10 | Configuration serveur (Radicale, Nextcloud, etc.) |
-| 3.7 | APIs publiquement documentées (si applicable) | 10 | URL documentation (Swagger, OpenAPI, etc.) |
-| 3.8 | Support de fédération (Matrix, ActivityPub, XMPP, etc.) | 5 | Configuration + test de fédération |
-| 3.9 | Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.) | 5 | Analyse Blacklight, uBlock Origin |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                                                     | Points | Preuve Requise                                    |
+|---------------------------|-----------------------------------------------------------------------------|--------|---------------------------------------------------|
+| 3.6                       | Calendrier via CalDAV / Contacts via CardDAV                                | 10     | Configuration serveur (Radicale, Nextcloud, etc.) |
+| 3.7                       | APIs publiquement documentées (si applicable)                               | 10     | URL documentation (Swagger, OpenAPI, etc.)        |
+| 3.8                       | Support de fédération (Matrix, ActivityPub, XMPP, etc.)                     | 5      | Configuration + test de fédération                |
+| 3.9                       | Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.) | 5      | Analyse Blacklight, uBlock Origin                 |
+| **Total recommandé :** 30 pts |                                                                             |        |                                                   |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 3.10 | Contribution à des standards ouverts (RFC, W3C, etc.) | 5 | Liens vers contributions |
-| 3.11 | Support multi-protocoles (email + Matrix + CalDAV + WebDAV) | 3 | Configuration complète |
-| 3.12 | Publication de schémas de données (Open Data) | 2 | URL schémas (JSON Schema, etc.) |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 3 :** 100 pts
+
+| \#                         | Critère                                                     | Points | Preuve Requise                  |
+|---------------------------|-------------------------------------------------------------|--------|---------------------------------|
+| 3.10                      | Contribution à des standards ouverts (RFC, W3C, etc.)       | 5      | Liens vers contributions        |
+| 3.11                      | Support multi-protocoles (email + Matrix + CalDAV + WebDAV) | 3      | Configuration complète          |
+| 3.12                      | Publication de schémas de données (Open Data)               | 2      | URL schémas (JSON Schema, etc.) |
+| **Total excellence :** 10 pts |                                                             |        |                                 |
+| **TOTAL DOMAINE 3 :** 100 pts |                                                             |        |                                 |
+
 ---
+
 ### 2.4 Domaine 4 : Logiciels Libres & Éthique
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 4.1 | OS serveur libre (Linux, BSD) | 15 | `uname -a` ou équivalent |
-| 4.2 | ≥ 60% de la stack applicative en logiciel libre | 15 | Inventaire logiciels (avec licences) |
-| 4.3 | Liste publique des dépendances (transparence) | 10 | Document ou page web |
-| 4.4 | Aucune dépendance critique aux GAFAM (production) | 10 | Déclaration signée |
-| 4.5 | Gouvernance non autoritaire (coopérative, démocratique, ou collégiale) | 10 | Statuts légaux ou règlement interne |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                                | Points | Preuve Requise                       |
+|----------------------------|------------------------------------------------------------------------|--------|--------------------------------------|
+| 4.1                        | OS serveur libre (Linux, BSD)                                          | 15     | `uname -a` ou équivalent               |
+| 4.2                        | ≥ 60% de la stack applicative en logiciel libre                        | 15     | Inventaire logiciels (avec licences) |
+| 4.3                        | Liste publique des dépendances (transparence)                          | 10     | Document ou page web                 |
+| 4.4                        | Aucune dépendance critique aux GAFAM (production)                      | 10     | Déclaration signée                   |
+| 4.5                        | Gouvernance non autoritaire (coopérative, démocratique, ou collégiale) | 10     | Statuts légaux ou règlement interne  |
+| **Total obligatoire :** 60 pts |                                                                        |        |                                      |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 4.6 | ≥ 80% de la stack applicative en logiciel libre | 10 | Inventaire détaillé |
-| 4.7 | Au moins 1 contribution annuelle à un projet libre | 10 | Liens vers commits, PRs, donations |
-| 4.8 | Publication de code maison en licence libre | 5 | Dépôts Git publics |
-| 4.9 | Politique d'achat favorisant fournisseurs éthiques | 5 | Document de politique |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                            | Points | Preuve Requise                     |
+|---------------------------|----------------------------------------------------|--------|------------------------------------|
+| 4.6                       | ≥ 80% de la stack applicative en logiciel libre    | 10     | Inventaire détaillé                |
+| 4.7                       | Au moins 1 contribution annuelle à un projet libre | 10     | Liens vers commits, PRs, donations |
+| 4.8                       | Publication de code maison en licence libre        | 5      | Dépôts Git publics                 |
+| 4.9                       | Politique d'achat favorisant fournisseurs éthiques | 5      | Document de politique              |
+| **Total recommandé :** 30 pts |                                                    |        |                                    |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 4.10 | 100% de la stack en logiciel libre | 5 | Inventaire complet |
-| 4.11 | Mainteneur actif d'un projet libre majeur | 3 | Preuve de maintenance (GitHub stats, etc.) |
-| 4.12 | Certification B Corp ou équivalent | 2 | Certificat |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 4 :** 100 pts
+
+| \#                         | Critère                                   | Points | Preuve Requise                             |
+|---------------------------|-------------------------------------------|--------|--------------------------------------------|
+| 4.10                      | 100% de la stack en logiciel libre        | 5      | Inventaire complet                         |
+| 4.11                      | Mainteneur actif d'un projet libre majeur | 3      | Preuve de maintenance (GitHub stats, etc.) |
+| 4.12                      | Certification B Corp ou équivalent        | 2      | Certificat                                 |
+| **Total excellence :** 10 pts |                                           |        |                                            |
+| **TOTAL DOMAINE 4 :** 100 pts |                                           |        |                                            |
+
 ---
+
 ### 2.5 Domaine 5 : Opérations & Documentation
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 5.1 | Runbook pour au moins 3 procédures critiques | 15 | Wiki ou dépôt doc |
-| 5.2 | Documentation architecture à jour | 10 | Diagrammes + descriptions |
-| 5.3 | Post-mortem publié pour incidents P0/P1 (6 derniers mois) | 15 | Lien vers post-mortems |
-| 5.4 | Monitoring avec métriques exportées (Prometheus compatible) | 10 | Configuration Prometheus |
-| 5.5 | Status page public (ou métriques disponibilité) | 10 | URL status page |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                     | Points | Preuve Requise            |
+|----------------------------|-------------------------------------------------------------|--------|---------------------------|
+| 5.1                        | Runbook pour au moins 3 procédures critiques                | 15     | Wiki ou dépôt doc         |
+| 5.2                        | Documentation architecture à jour                           | 10     | Diagrammes + descriptions |
+| 5.3                        | Post-mortem publié pour incidents P0/P1 (6 derniers mois)   | 15     | Lien vers post-mortems    |
+| 5.4                        | Monitoring avec métriques exportées (Prometheus compatible) | 10     | Configuration Prometheus  |
+| 5.5                        | Status page public (ou métriques disponibilité)             | 10     | URL status page           |
+| **Total obligatoire :** 60 pts |                                                             |        |                           |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 5.6 | IaC pour ≥ 70% de l'infrastructure | 10 | Playbooks Ansible, Terraform |
-| 5.7 | CI/CD avec tests automatisés | 10 | Configuration GitLab CI, GitHub Actions, etc. |
-| 5.8 | Documentation générée automatiquement (code) | 5 | Sphinx, JSDoc, ou équivalent |
-| 5.9 | Contributions régulières au wiki L'Alliance | 5 | Historique Git wiki |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                      | Points | Preuve Requise                                |
+|---------------------------|----------------------------------------------|--------|-----------------------------------------------|
+| 5.6                       | IaC pour ≥ 70% de l'infrastructure           | 10     | Playbooks Ansible, Terraform                  |
+| 5.7                       | CI/CD avec tests automatisés                 | 10     | Configuration GitLab CI, GitHub Actions, etc. |
+| 5.8                       | Documentation générée automatiquement (code) | 5      | Sphinx, JSDoc, ou équivalent                  |
+| 5.9                       | Contributions régulières au wiki L'Alliance  | 5      | Historique Git wiki                           |
+| **Total recommandé :** 30 pts |                                              |        |                                               |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 5.10 | Infrastructure 100% IaC (zero manual config) | 5 | Démo reproductibilité |
-| 5.11 | Observabilité avancée (tracing distribué, logs structurés) | 3 | Jaeger, ELK, ou équivalent |
-| 5.12 | SLA publiquement documenté et respecté | 2 | SLA + rapport conformité |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 5 :** 100 pts
+
+| \#                         | Critère                                                    | Points | Preuve Requise             |
+|---------------------------|------------------------------------------------------------|--------|----------------------------|
+| 5.10                      | Infrastructure 100% IaC (zero manual config)               | 5      | Démo reproductibilité      |
+| 5.11                      | Observabilité avancée (tracing distribué, logs structurés) | 3      | Jaeger, ELK, ou équivalent |
+| 5.12                      | SLA publiquement documenté et respecté                     | 2      | SLA + rapport conformité   |
+| **Total excellence :** 10 pts |                                                            |        |                            |
+| **TOTAL DOMAINE 5 :** 100 pts |                                                            |        |                            |
+
 ---
+
 ### 2.6 Domaine 6 : Sobriété Numérique & Durabilité
+
 #### Critères Obligatoires (60 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 6.1 | Mesure de la consommation énergétique (kWh/mois) | 15 | Factures ou monitoring IPMI |
-| 6.2 | Politique de rétention des données documentée | 10 | Document politique |
-| 6.3 | Serveurs utilisés ≥ 3 ans (si contrôle direct) | 15 | Inventaire avec dates acquisition |
-| 6.4 | Hébergeur avec engagement environnemental (si externalisé) | 10 | Certification hébergeur (ISO 14001, PUE < 1.5) |
-| 6.5 | Guide utilisateur sur bonnes pratiques sobriété | 10 | Document ou page web |
-**Total obligatoire :** 60 pts
+
+| \#                          | Critère                                                    | Points | Preuve Requise                                 |
+|----------------------------|------------------------------------------------------------|--------|------------------------------------------------|
+| 6.1                        | Mesure de la consommation énergétique (kWh/mois)           | 15     | Factures ou monitoring IPMI                    |
+| 6.2                        | Politique de rétention des données documentée              | 10     | Document politique                             |
+| 6.3                        | Serveurs utilisés ≥ 3 ans (si contrôle direct)             | 15     | Inventaire avec dates acquisition              |
+| 6.4                        | Hébergeur avec engagement environnemental (si externalisé) | 10     | Certification hébergeur (ISO 14001, PUE < 1.5) |
+| 6.5                        | Guide utilisateur sur bonnes pratiques sobriété            | 10     | Document ou page web                           |
+| **Total obligatoire :** 60 pts |                                                            |        |                                                |
+
 ---
+
 #### Critères Recommandés (30 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 6.6 | Réduction consommation énergétique année/année | 10 | Comparatif metrics |
-| 6.7 | Serveurs utilisés ≥ 5 ans | 5 | Inventaire |
-| 6.8 | Optimisation ressources (CPU/RAM/stockage < 70% en moyenne) | 5 | Métriques monitoring |
-| 6.9 | Énergie renouvelable ≥ 50% (si contrôle direct) | 5 | Factures ou certificat |
-| 6.10 | Extinction services non critiques hors heures | 5 | Scripts automation + logs |
-**Total recommandé :** 30 pts
+
+| \#                         | Critère                                                     | Points | Preuve Requise            |
+|---------------------------|-------------------------------------------------------------|--------|---------------------------|
+| 6.6                       | Réduction consommation énergétique année/année              | 10     | Comparatif metrics        |
+| 6.7                       | Serveurs utilisés ≥ 5 ans                                   | 5      | Inventaire                |
+| 6.8                       | Optimisation ressources (CPU/RAM/stockage < 70% en moyenne) | 5      | Métriques monitoring      |
+| 6.9                       | Énergie renouvelable ≥ 50% (si contrôle direct)             | 5      | Factures ou certificat    |
+| 6.10                      | Extinction services non critiques hors heures               | 5      | Scripts automation + logs |
+| **Total recommandé :** 30 pts |                                                             |        |                           |
+
 ---
+
 #### Critères d'Excellence (10 pts)
-| # | Critère | Points | Preuve Requise |
-|---|---------|--------|----------------|
-| 6.11 | Énergie 100% renouvelable | 5 | Certificat fournisseur |
-| 6.12 | Compensation carbone volontaire | 3 | Reçus donations (Planetair, etc.) |
-| 6.13 | Publication rapport impact environnemental annuel | 2 | Rapport public |
-**Total excellence :** 10 pts
-**TOTAL DOMAINE 6 :** 100 pts
+
+| \#                         | Critère                                           | Points | Preuve Requise                    |
+|---------------------------|---------------------------------------------------|--------|-----------------------------------|
+| 6.11                      | Énergie 100% renouvelable                         | 5      | Certificat fournisseur            |
+| 6.12                      | Compensation carbone volontaire                   | 3      | Reçus donations (Planetair, etc.) |
+| 6.13                      | Publication rapport impact environnemental annuel | 2      | Rapport public                    |
+| **Total excellence :** 10 pts |                                                   |        |                                   |
+| **TOTAL DOMAINE 6 :** 100 pts |                                                   |        |                                   |
+
 ---
+
 ## SECTION 3 : PROCESSUS D'AUDIT
+
 ### 3.1 Principe de l'Audit Pair-à-Pair
+
 **L'Alliance Boréale utilise l'audit pair-à-pair :**
 Les membres auditent les membres. Pas d'auditeur externe coûteux. Pas de certification bureaucratique.
 **Avantages :**
+
 - **Coût zéro** (temps valorisé via banque de temps)
 - **Expertise réelle** (les auditeurs connaissent les défis du terrain)
 - **Apprentissage mutuel** (audité ET auditeur progressent)
-- **Confiance renforcée** (transparence entre pairs)
-**Garde-fous :**
+- **Confiance renforcée** (transparence entre pairs) **Garde-fous :**
 - Conflit d'intérêts interdit (on n'audite pas son concurrent direct)
 - Formation obligatoire des auditeurs
 - Validation finale par Cercle Éthique
 - Possibilité de recours (si désaccord sur notation)
+
 ---
+
 ### 3.2 Qui Peut Auditer ?
+
 **Éligibilité auditeur :**
+
 - Membre actif depuis ≥ 6 mois
 - Score label Argent ou supérieur (si déjà labellisé)
 - Formation auditeur complétée (atelier 4h)
-- Aucun conflit d'intérêts avec l'audité
-**Formation auditeur (obligatoire) :**
+- Aucun conflit d'intérêts avec l'audité **Formation auditeur (obligatoire) :**
 - Compréhension des 6 domaines et grilles
 - Méthodologie de collecte de preuves
 - Rédaction de rapport d'audit
-- Éthique de l'auditeur (impartialité, confidentialité)
-**Durée formation :** 4h (atelier interactif, 1x/trimestre)
-**Validation :** Quiz final (80% requis)
-**Certification :** Valide 24 mois (renouvellement via atelier ou examen)
+- Éthique de l'auditeur (impartialité, confidentialité) **Durée formation :** 4h (atelier interactif, 1x/trimestre) **Validation :** Quiz final (80% requis) **Certification :** Valide 24 mois (renouvellement via atelier ou examen)
+
 ---
+
 ### 3.3 Étapes du Processus d'Audit
+
 #### Étape 1 : Demande de Labellisation (Semaine 0)
+
 **Qui :** Membre actif souhaitant obtenir ou renouveler le label.
 **Prérequis :**
+
 - Membre actif depuis ≥ 6 mois
 - Aucune suspension en cours
-- Cotisation à jour
-**Action :**
+- Cotisation à jour **Action :**
+
 1. Remplir formulaire de demande (via Registraire ou email)
 2. Auto-évaluation préliminaire (grille des 6 domaines)
-3. Identification des preuves disponibles
-**Délai de traitement :** 7 jours (validation admissibilité par Cercle Éthique)
+3. Identification des preuves disponibles **Délai de traitement :** 7 jours (validation admissibilité par Cercle Éthique)
+
 ---
+
 #### Étape 2 : Désignation de l'Auditeur (Semaine 1)
+
 **Qui :** Cercle Éthique & Conformité.
 **Critères de désignation :**
+
 - Éviter conflit d'intérêts (pas de compétiteur direct)
 - Privilégier expertise pertinente (ex: expert infra pour domaine 1)
-- Rotation équitable (chaque auditeur audite environ 2-3 (Réseau, Virtualisation) fois/an)
-**Notification :**
+- Rotation équitable (chaque auditeur audite environ 2-3 (Réseau, Virtualisation) fois/an) **Notification :**
 - Auditeur contacté (acceptation sous 7 jours)
 - Si refus, désignation d'un autre auditeur
-- Audité informé de l'identité de l'auditeur
-**Kick-off :**
+- Audité informé de l'identité de l'auditeur **Kick-off :**
 - Réunion initiale (auditeur + audité, 30-60 min)
 - Clarification du périmètre
 - Planning de l'audit (4-6 (Orchestration, Supervision, Services) semaines typiquement)
+
 ---
+
 #### Étape 3 : Collecte de Preuves (Semaines 2-4 (Réseau, Virtualisation, Orchestration))
+
 **Qui :** Audité (prépare preuves) + Auditeur (révise et valide).
-**Preuves attendues (selon domaine) :**
-**Domaine 1 (Infrastructure) :**
+**Preuves attendues (selon domaine) :Domaine 1 (Infrastructure) :**
+
 - Captures écran monitoring (Grafana, Prometheus)
 - Logs de backups (derniers 3 mois)
 - Rapport de test de restauration
 - Diagramme architecture (Diagrams.net, Draw.io)
-- Plan de reprise (document DRP)
-**Domaine 2 (Sécurité) :**
+- Plan de reprise (document DRP) **Domaine 2 (Sécurité) :**
 - Scan SSL Labs (grade A- minimum)
 - Capture config MFA (avec données sensibles masquées)
 - Politique de confidentialité (URL publique)
 - Logs mises à jour sécurité (derniers 6 mois)
-- Configuration pare-feu (règles actives)
-**Domaine 3 (Interopérabilité) :**
+- Configuration pare-feu (règles actives) **Domaine 3 (Interopérabilité) :**
 - Configuration serveurs (Postfix, Dovecot, etc.)
 - Test export données (capture procédure)
 - Scan MXToolbox (DKIM, SPF, DMARC)
-- Liste formats de données utilisés
-**Domaine 4 (Logiciels Libres) :**
+- Liste formats de données utilisés **Domaine 4 (Logiciels Libres) :**
 - Inventaire logiciels (nom, version, licence)
 - Déclaration dépendances GAFAM (signée)
 - Liens vers contributions (commits GitHub, donations)
-- Statuts légaux (si gouvernance évaluée)
-**Domaine 5 (Opérations) :**
+- Statuts légaux (si gouvernance évaluée) **Domaine 5 (Opérations) :**
 - Runbooks (au moins 3, liens wiki)
 - Post-mortems (derniers 12 mois)
 - Configuration monitoring (Prometheus, Grafana)
-- Playbooks IaC (Ansible, Terraform)
-**Domaine 6 (Sobriété) :**
+- Playbooks IaC (Ansible, Terraform) **Domaine 6 (Sobriété) :**
 - Factures énergétiques (derniers 12 mois, anonymisées si besoin)
 - Inventaire serveurs (âge, consommation estimée)
 - Politique rétention données (document)
-- Guide utilisateur sobriété (URL ou doc)
-**Format de soumission :**
+- Guide utilisateur sobriété (URL ou doc) **Format de soumission :**
 - Dépôt Git privé partagé (auditeur + audité + Cercle Éthique)
-- Structure : `/domaine-X/critere-X.Y/preuve-*.{pdf,png,md}`
-**Échanges :**
+- Structure : `/domaine-X/critere-X.Y/preuve-*.{pdf,png,md}`**Échanges :**
 - Questions/réponses asynchrones (Matrix canal privé)
 - Réunion de mi-parcours (facultative, semaine 3)
+
 ---
+
 #### Étape 4 : Évaluation et Notation (Semaine 5)
+
 **Qui :** Auditeur.
 **Action :**
+
 1. Révision de toutes les preuves
 2. Attribution des points (critère par critère)
 3. Calcul score par domaine (max 100)
 4. Calcul score global (moyenne des 6 domaines)
-5. Détermination niveau éligible (Bronze/Argent/Or/Platine)
-**Grille de notation :**
+5. Détermination niveau éligible (Bronze/Argent/Or/Platine) **Grille de notation :**
+
 - ✅ **Preuve solide et complète** → Points attribués
 - ⚠️ **Preuve partielle ou incomplète** → Points partiels (50%)
-- ❌ **Preuve absente ou invalide** → 0 point
-**Justification obligatoire :**
-Pour chaque critère, l'auditeur doit noter :
+- ❌ **Preuve absente ou invalide** → 0 point **Justification obligatoire :** Pour chaque critère, l'auditeur doit noter :
 - Preuve fournie (référence)
 - Points attribués (nombre)
-- Justification (pourquoi ce score)
-**Exemple :**
+- Justification (pourquoi ce score) **Exemple :**
+
 ```yaml
 domaine: 2
 critere: 2.1
@@ -573,10 +663,14 @@ evaluation:
   points_attribues: 10
   justification: "Scan SSL Labs montre grade A sur tous les sous-domaines testés. TLS 1.2 et 1.3 activés, pas de TLS 1.0/1.1."
 ```
+
 ---
+
 #### Étape 5 : Rapport d'Audit (Semaine 5-6 (Supervision, Services))
+
 **Qui :** Auditeur.
 **Contenu du rapport :**
+
 1. **Page de titre**
    - Audité (nom, membre ID)
    - Auditeur (nom, membre ID)
@@ -603,50 +697,57 @@ evaluation:
    - Ressources nécessaires
 6. **Annexes**
    - Liste des preuves examinées
-   - Captures écran clés (si pertinent)
-**Format :** Markdown ou PDF.
-**Longueur typique :** 10-15 pages.
+   - Captures écran clés (si pertinent) **Format :** Markdown ou PDF. **Longueur typique :** 10-15 pages.
+
 ---
+
 #### Étape 6 : Révision par l'Audité (Semaine 6)
+
 **Qui :** Audité.
 **Délai :** 7 jours pour réagir au rapport.
-**Options :**
-**A) Acceptation sans réserve**
+**Options :A) Acceptation sans réserve**
 → Passage direct à validation Cercle Éthique.
 **B) Demande de clarification**
 → Auditeur clarifie (48h). Si satisfaisant, acceptation. Sinon, recours.
 **C) Contestation d'un critère**
 → Procédure de recours (voir Section 3.4).
 **Documentation :**
+
 - Réponse écrite de l'audité (acceptation, questions, ou contestation)
 - Versée au dépôt d'audit
+
 ---
+
 #### Étape 7 : Validation par Cercle Éthique (Semaine 7)
+
 **Qui :** Cercle Éthique & Conformité.
 **Action :**
+
 1. Révision du rapport d'audit (cohérence, qualité)
 2. Vérification absence conflit d'intérêts
 3. Validation des scores (spot-check sur 2-3 (Réseau, Virtualisation) critères)
-4. Décision d'attribution du label (consentement)
-**Critères de validation :**
+4. Décision d'attribution du label (consentement) **Critères de validation :**
+
 - ✅ Rapport complet et justifié
 - ✅ Preuves solides
 - ✅ Pas de conflit d'intérêts détecté
-- ✅ Audité a accepté (ou recours traité)
-**Décision possible :**
+- ✅ Audité a accepté (ou recours traité) **Décision possible :**
 - **Approuvé** : Label attribué au niveau calculé
 - **Approuvé avec conditions** : Label attribué, mais plan d'action obligatoire (délai 6 mois)
-- **Rejeté** : Score insuffisant OU preuves invalides → Réaudit requis (délai 3 mois)
-**Notification :**
+- **Rejeté** : Score insuffisant OU preuves invalides → Réaudit requis (délai 3 mois) **Notification :**
 - Audité informé sous 7 jours (email + Matrix)
 - Si approuvé : Badge généré, Registraire mis à jour
 - Si rejeté : Feedback détaillé + accompagnement proposé
+
 ---
+
 ### 3.4 Procédure de Recours
+
 **Déclenchement :**
 Audité conteste un ou plusieurs critères du rapport d'audit (désaccord sur notation).
 **Délai :** 7 jours après réception du rapport.
 **Étapes :**
+
 1. **Dépôt de recours** (formulaire standardisé)
    - Critère(s) contesté(s)
    - Justification (pourquoi le score devrait être différent)
@@ -658,13 +759,16 @@ Audité conteste un ou plusieurs critères du rapport d'audit (désaccord sur no
 3. **Décision finale** (Cercle Éthique, consentement renforcé)
    - Si médiation échoue → Cercle Éthique tranche
    - Décision motivée par écrit
-   - Pas d'autre recours (sauf violation de procédure grave → Cercle Stratégique)
-**Délai total :** Maximum 30 jours.
-**Coûts :** Aucun (inclus dans cotisation). Temps valorisé via banque de temps.
+   - Pas d'autre recours (sauf violation de procédure grave → Cercle Stratégique) **Délai total :** Maximum 30 jours. **Coûts :** Aucun (inclus dans cotisation). Temps valorisé via banque de temps.
+
 ---
+
 ## SECTION 4 : CERTIFICATION ET VALIDITÉ
+
 ### 4.1 Attribution du Label
+
 **Suite à validation par Cercle Éthique :**
+
 1. **Génération du badge** (logo + niveau + ID unique)
    - Format : SVG + PNG (haute résolution)
    - Couleurs : Bronze (CD7F32), Argent (C0C0C0), Or (FFD700), Platine (E5E4E2)
@@ -678,137 +782,202 @@ Audité conteste un ou plusieurs critères du rapport d'audit (désaccord sur no
 4. **Remise symbolique** (optionnel)
    - Lors de la rencontre annuelle (présentiel)
    - Certificat imprimé + badge physique (si demandé)
+
 ---
+
 ### 4.2 Durée de Validité
+
 **Par niveau :**
-| Niveau | Durée |
-|--------|-------|
-| Bronze | 12 mois |
-| Argent | 12 mois |
-| Or | 12 mois |
-| Platine | 18 mois |
-**Rationale Platine :**
-Reconnaître l'excellence soutenue en allégeant la charge de recertification (tous les 1.5 ans au lieu de 1 an).
-**Expiration :**
-À la date anniversaire (jour/mois/année de l'attribution + durée).
-**Alerte :**
+
+| Niveau                                                                                                          | Durée   |
+|-----------------------------------------------------------------------------------------------------------------|---------|
+| Bronze                                                                                                          | 12 mois |
+| Argent                                                                                                          | 12 mois |
+| Or                                                                                                              | 12 mois |
+| Platine                                                                                                         | 18 mois |
+| **Rationale Platine :**                                                                                             |         |
+| Reconnaître l'excellence soutenue en allégeant la charge de recertification (tous les 1.5 ans au lieu de 1 an). |         |
+| **Expiration :**                                                                                                    |         |
+| À la date anniversaire (jour/mois/année de l'attribution + durée).                                              |         |
+| **Alerte :**                                                                                                        |         |
+
 - Email automatique 60 jours avant expiration
 - Rappel 30 jours avant expiration
-- Dernière alerte 7 jours avant expiration
-**Si expiration sans renouvellement :**
+- Dernière alerte 7 jours avant expiration **Si expiration sans renouvellement :**
 - Label révoqué automatiquement
 - Badge retiré du Registraire (historique conservé)
 - Membre doit cesser usage du badge
+
 ---
+
 ### 4.3 Renouvellement (Recertification)
+
 **Processus :**
 Identique à l'audit initial, MAIS avec simplifications possibles :
+  
 **Simplification 1 : Auto-évaluation allégée**
+
 - Focus sur les domaines ayant changé
-- Si score précédent ≥ 80 → Auditeur peut spot-check (pas tout réviser)
+- Si score précédent ≥ 80 → Auditeur peut spot-check (pas tout réviser) 
+
 **Simplification 2 : Même auditeur (optionnel)**
+
 - Si audité et auditeur consentent, possibilité de ré-assigner même binôme
 - Avantage : auditeur connaît déjà le contexte
-- Rotation tous les 3 cycles recommandée (éviter complaisance)
-**Délai recommandé :**
-Démarrer le processus 90 jours avant expiration (marge confortable).
+- Rotation tous les 3 cycles recommandée (éviter complaisance) 
+
+**Délai recommandé :** Démarrer le processus 90 jours avant expiration (marge confortable). 
+
 **Recertification tardive :**
+
 - Possible jusqu'à 30 jours après expiration (label révoqué mais processus simplifié)
 - Au-delà de 30 jours → Audit complet requis (comme nouveau label)
+
 ---
+
 ### 4.4 Amélioration de Niveau
+
 **Membre peut demander audit pour niveau supérieur à tout moment :**
+
 **Conditions :**
+
 - Délai minimum : 6 mois après dernier audit
 - Auto-évaluation préliminaire montrant éligibilité au niveau supérieur
-- Cotisation à jour
-**Processus :**
-Identique à audit initial (même si label valide).
+- Cotisation à jour 
+
+**Processus :** Identique à audit initial (même si label valide). 
+
 **Si échec :**
+
 - Label actuel conservé jusqu'à expiration normale
-- Possibilité de ré-essayer après 6 mois
+- Possibilité de ré-essayer après 6 mois 
+
 **Incitation :**
+
 - Pas de pénalité financière (inclus dans cotisation)
 - Reconnaissance publique si passage Or → Platine
+
 ---
+
 ## SECTION 5 : USAGE DU LABEL
+
 ### 5.1 Droits d'Usage
+
 **Membre labellisé peut :**
 ✅ Afficher le badge sur :
+
 - Site web (page d'accueil, footer)
 - Signatures email professionnelles
 - Profils réseaux sociaux (LinkedIn, Mastodon, etc.)
-- Matériel de communication (brochures, présentations)
+- Matériel de communication (brochures, présentations) 
+
 ✅ Mentionner le label dans :
+
 - Propositions commerciales
 - Appels d'offres (preuve de conformité)
-- Communications publiques (articles, conférences)
+- Communications publiques (articles, conférences) 
+
 ✅ Utiliser la phrase :
+
 > *"[Nom Membre] est membre certifié de L'Alliance Boréale avec un label [Niveau]."*
+
 ---
+
 ### 5.2 Obligations d'Usage
+
 **Membre labellisé doit :**
 ❌ NE PAS altérer le badge (couleurs, proportions, texte)
 ❌ NE PAS utiliser un niveau non attribué (ex: afficher Or si Argent)
 ❌ NE PAS utiliser le badge après expiration
 ❌ NE PAS faire de déclarations mensongères sur le score
+  
 ✅ Retirer le badge immédiatement si :
+
 - Label expiré sans renouvellement
 - Label révoqué (suspension, radiation)
-- Demande du Cercle Éthique (abus constaté)
-✅ Lier le badge au Registraire public (URL de vérification)
-**URL de vérification :**
-`https://registraire.alliance-boreale.ca/membres/[ID]/label`
+- Demande du Cercle Éthique (abus constaté) 
+
+✅ Lier le badge au Registraire public (URL de vérification) 
+
+**URL de vérification :**`https://registraire.alliance-boreale.ca/membres/[ID]/label`
+
 **Exemple :**
+
 ```html
 <a href="https://registraire.alliance-boreale.ca/membres/m001/label">
   <img src="badge-alliance-boreale-or.svg" alt="Label Or - Alliance Boréale" />
 </a>
 ```
+
 ---
+
 ### 5.3 Surveillance et Sanctions
+
 **Surveillance :**
+
 - Audit aléatoire d'usage (Cercle Éthique, 2x/an)
-- Signalement par membres ou public (formulaire web)
-**Abus typiques :**
+- Signalement par membres ou public (formulaire web) **Abus typiques :**
 - Badge affiché après expiration
 - Badge altéré (couleurs, texte)
 - Déclaration niveau supérieur (afficher Platine si Or)
-- Usage commercial trompeur (ex: "Certifié ISO 27001" si seulement label Bronze)
+- Usage commercial trompeur (ex: "Certifié ISO 27001" si seulement label Bronze) 
+
 **Sanctions :**
+
 **Abus mineur (non intentionnel) :**
+
 - Avertissement écrit
 - Correction sous 7 jours
-- Aucune autre conséquence
+- Aucune autre conséquence 
+
 **Abus majeur (intentionnel ou répété) :**
+
 - Suspension du label (3-6 (Virtualisation, Orchestration, Supervision, Services) mois)
 - Interdiction de demander label durant suspension
-- Possible radiation (si gravité extrême)
-**Procédure :**
-Contradictoire (voir Document 2, Section 4.6 - Suspension).
+- Possible radiation (si gravité extrême) 
+
+**Procédure :** Contradictoire (voir Document 2, Section 4.6 - Suspension).
+
 ---
+
 ## SECTION 6 : RÉVOCATION DU LABEL
+
 ### 6.1 Motifs de Révocation
+
 **Le label peut être révoqué dans les cas suivants :**
+
 **1. Non-conformité majeure découverte après attribution**
+
 - Fraude dans les preuves (preuves falsifiées)
 - Incident de sécurité grave non déclaré révélant manquements systémiques
-- Violation grave des 5 valeurs cardinales
+- Violation grave des 5 valeurs cardinales 
+
 **2. Suspension du membre**
+
 - Suspension administrative → révocation automatique du label
-- Rétablissement possible après levée de suspension + réaudit
+- Rétablissement possible après levée de suspension + réaudit 
+
 **3. Dégradation avérée de la conformité**
+
 - Monitoring partagé détecte disponibilité < 95% (domaine 1)
 - Scan SSL Labs montre dégradation (domaine 2)
-- Signalements répétés d'utilisateurs (domaine 3, 4)
+- Signalements répétés d'utilisateurs (domaine 3, 4) 
+
 **4. Abus d'usage du label**
-- Voir Section 5.3
+
+- Voir Section 5.3 
+
 **5. Demande volontaire du membre**
+
 - Membre peut renoncer à son label (sans pénalité)
 - Utile si le membre sait qu'il ne respecte plus les critères
+
 ---
+
 ### 6.2 Procédure de Révocation
+
 **Garanties :**
+
 1. **Enquête préalable** (Cercle Éthique)
    - Collecte de preuves (monitoring, rapports, témoignages)
    - Vérification des faits
@@ -826,164 +995,255 @@ Contradictoire (voir Document 2, Section 4.6 - Suspension).
    - Avertissement (si gravité moindre)
 5. **Notification de la décision** (motivée par écrit)
    - Membre informé sous 7 jours
-   - Publication résumé anonymisé au Registraire (transparence)
-**Délai total :** Maximum 45 jours.
+   - Publication résumé anonymisé au Registraire (transparence) 
+
+**Délai total :** 
+
+1. Maximum 45 jours.
+
 ---
+
 ### 6.3 Conséquences de la Révocation
+
 **Immédiates :**
+
 - Badge retiré du Registraire
 - Membre doit cesser usage du badge (7 jours)
-- Notification aux autres membres (Matrix, interne)
+- Notification aux autres membres (Matrix, interne) 
+
 **Long terme :**
+
 - Membre peut redemander label après correction (délai 6 mois minimum)
 - Audit complet requis (pas de simplification)
-- Historique de révocation documenté (mais pas publié)
+- Historique de révocation documenté (mais pas publié) 
+
 **Aucune exclusion de L'Alliance** (sauf si radiation pour autre motif).
+
 ---
+
 ## SECTION 7 : ÉVOLUTION DU CADRE DE CONFORMITÉ
+
 ### 7.1 Révision Annuelle
+
 **Obligation :** Le Cercle Éthique révise ce document chaque année (Q4).
 **Objectifs :**
+
 - Ajuster critères (retours d'expérience auditeurs/audités)
 - Ajouter/supprimer critères (évolution technologique)
 - Clarifier ambiguïtés (interprétations divergentes)
-- Mettre à jour grilles de notation
+- Mettre à jour grilles de notation 
+
 **Processus :**
+
 1. Collecte feedback (auditeurs, audités, membres)
 2. Analyse des scores (domaines trop faciles/difficiles ?)
 3. Propositions d'amendements (Cercle Éthique)
 4. Consultation publique (30 jours, tous les membres)
 5. Amendements finalisés (consentement Cercle Éthique)
-6. Validation Cercle Stratégique (si changements majeurs)
+6. Validation Cercle Stratégique (si changements majeurs) 
+
 **Entrée en vigueur :** 1er janvier de l'année suivante (prévisibilité).
+
 ---
+
 ### 7.2 Amendements Hors Cycle
+
 **Possibles si nécessité urgente :**
+
 - Nouvelle loi (ex: Loi 25 amendée)
 - Vulnérabilité critique découverte (ex: Log4Shell → ajout critère patches < 48h)
-- Incohérence grave détectée
+- Incohérence grave détectée 
+
 **Processus accéléré :**
+
 - Consultation 14 jours (au lieu de 30)
 - Décision Cercle Éthique (consentement)
-- Entrée en vigueur immédiate ou différée (selon urgence)
+- Entrée en vigueur immédiate ou différée (selon urgence) 
+
 **Notification :**
+
 - Tous les membres alertés (email + Matrix)
 - Membres labellisés : évaluation si critères nouveaux les affectent
+
 ---
+
 ### 7.3 Transition entre Versions
+
 **Principe : Pas de pénalisation rétroactive.**
+
 **Scénario 1 : Critères durcis**
+
 - Labels déjà attribués restent valides jusqu'à expiration
 - Renouvellement : nouveaux critères appliqués
-- Délai de grâce : 6 mois pour s'adapter
+- Délai de grâce : 6 mois pour s'adapter 
+
 **Scénario 2 : Critères assouplis**
+
 - Labels existants conservés
-- Membres peuvent demander réévaluation immédiate (si score amélioré)
+- Membres peuvent demander réévaluation immédiate (si score amélioré) 
+
 **Scénario 3 : Nouveau domaine ajouté**
+
 - Labels existants : domaine noté 0 (pas pénalisant pour durée restante)
-- Renouvellement : nouveau domaine obligatoire
-**Exemple concret (version hypothétique 2.0 en 2027) :**
-Version 1.0 (2025) : 6 domaines
-Version 2.0 (2027) : 7 domaines (ajout "Accessibilité Numérique")
-→ Membre labellisé Or en 2026 (version 1.0) conserve son Or jusqu'à expiration 2027.
+- Renouvellement : nouveau domaine obligatoire 
+
+**Exemple concret (version hypothétique 2.0 en 2027) :** 
+
+Version 1.0 (2025) : 6 domaines 
+
+Version 2.0 (2027) : 7 domaines (ajout "Accessibilité Numérique") 
+
+→ Membre labellisé Or en 2026 (version 1.0) conserve son Or jusqu'à expiration 2027. 
+
 → Renouvellement 2027 : audit sur 7 domaines, score Accessibilité doit être ≥ 75 pour garder Or.
+
 ---
+
 ## SECTION 8 : GOUVERNANCE DU LABEL
+
 ### 8.1 Rôle du Cercle Éthique & Conformité
+
 **Responsabilités exclusives :**
+
 - Gestion des audits (désignation auditeurs, validation rapports)
 - Attribution/révocation des labels (décision finale)
 - Résolution des recours (médiation, arbitrage)
 - Évolution du cadre (amendements annuels)
-- Formation des auditeurs (ateliers, certifications)
+- Formation des auditeurs (ateliers, certifications) 
+
 **Le Cercle Éthique ne fait PAS :**
+
 - Audits techniques détaillés (délégué aux auditeurs pairs)
 - Décisions stratégiques (Cercle Stratégique)
 - Gestion infrastructure (Cercle Opérationnel)
+
 ---
+
 ### 8.2 Transparence et Redevabilité
+
 **Données publiques (Registraire) :**
+
 - Liste des membres labellisés (niveau, score global, date)
 - Scores par domaine (agrégés ou détaillés, selon choix membre)
-- Historique des labels (timelines)
+- Historique des labels (timelines) 
+
 **Données privées (Cercle Éthique) :**
+
 - Rapports d'audit complets (sauf synthèse publique)
 - Preuves techniques (configurations, logs)
-- Médiations et recours (sauf décision finale)
+- Médiations et recours (sauf décision finale) 
+
 **Rapport annuel (Cercle Éthique) :**
+
 - Nombre d'audits réalisés
 - Distribution des niveaux (combien Bronze/Argent/Or/Platine)
 - Domaines les plus forts/faibles (statistiques agrégées)
 - Évolutions année/année
-- Révocations (nombre, motifs anonymisés)
-**Publication :** Registraire, section `/rapports/label/YYYY.md`
+- Révocations (nombre, motifs anonymisés) **Publication :** Registraire, section `/rapports/label/YYYY.md`
+
 ---
+
 ### 8.3 Financement et Ressources
+
 **Coûts du label :**
+
 - Aucun pour les membres (inclus dans cotisation annuelle)
-- Temps auditeurs valorisé via banque de temps (crédits)
+- Temps auditeurs valorisé via banque de temps (crédits) 
+
 **Budget alloué :**
+
 - Formation auditeurs (matériel pédagogique, ateliers)
 - Outils de suivi (plateforme d'audit, si développée)
-- Badges physiques (impression, envoi)
+- Badges physiques (impression, envoi) 
+
 **Estimation :** 5-10% du budget annuel de L'Alliance.
+
 ---
+
 ## CONCLUSION
+
 Le Label de Prestige de L'Alliance Boréale n'est pas un gadget marketing.
 **C'est un outil de transformation collective.**
 En rendant visibles nos pratiques, en célébrant l'excellence, et en accompagnant l'amélioration continue, le label incarne nos valeurs :
+
 - **Souveraineté** : Audit pair-à-pair, pas de dépendance à un tiers certificateur
 - **Liberté** : Labellisation volontaire, critères transparents et évolutifs
 - **Sobriété** : Domaine 6 dédié, mesure et réduction de l'empreinte
 - **Solidarité** : Auditeurs pairs, apprentissage mutuel, banque de temps
-- **Transparence** : Scores publics, processus documenté, recours possibles
-**Le label évolue avec nous.**
-Chaque année, nous apprenons. Chaque audit, nous progressons. Chaque membre labellisé, nous renforçons la crédibilité de L'Alliance.
-**Le label n'est pas une fin. C'est un moyen.**
-Le moyen de nous tenir mutuellement responsables. Le moyen de montrer au monde qu'un autre numérique est possible. Le moyen de transformer nos valeurs en pratiques concrètes, mesurables, vérifiables.
-**Bienvenue dans la forêt labellisée.** 🌲
+- **Transparence** : Scores publics, processus documenté, recours possibles 
+- **Le label évolue avec nous.** Chaque année, nous apprenons. Chaque audit, nous progressons. Chaque membre labellisé, nous renforçons la crédibilité de L'Alliance. 
+- **Le label n'est pas une fin. C'est un moyen.** Le moyen de nous tenir mutuellement responsables. Le moyen de montrer au monde qu'un autre numérique est possible. Le moyen de transformer nos valeurs en pratiques concrètes, mesurables, vérifiables. 
+
+  **Bienvenue dans la forêt labellisée.** 🌲
+
 ---
+
 ## ANNEXES
+
 ### Annexe A : Checklist Rapide par Niveau
+
 #### Pour Bronze (Score global ≥ 50, chaque domaine ≥ 40)
+
 **Prioriser :**
+
 - ✅ Critères obligatoires (60 pts/domaine)
 - ✅ Disponibilité > 99%
 - ✅ TLS 1.2+, MFA admin
 - ✅ Backups testés
 - ✅ Documentation de base
-- ✅ Mesure consommation énergétique
-**Suffisant pour Bronze.**
+- ✅ Mesure consommation énergétique 
+
+    
+  **Suffisant pour Bronze.**
+
 ---
+
 #### Pour Argent (Score global ≥ 65, chaque domaine ≥ 60)
+
 **Ajouter :**
+
 - ✅ 50% des critères recommandés
 - ✅ Disponibilité > 99.5%
 - ✅ IaC ≥ 50%
 - ✅ Contribution à projet libre
-- ✅ Post-mortems publiés
-**Maturité opérationnelle démontrée.**
+- ✅ Post-mortems publiés 
+
+  **Maturité opérationnelle démontrée.**
+
 ---
+
 #### Pour Or (Score global ≥ 80, chaque domaine ≥ 75)
+
 **Ajouter :**
+
 - ✅ 75% des critères recommandés
 - ✅ Quelques critères d'excellence
 - ✅ Contribution significative L'Alliance
 - ✅ Disponibilité > 99.9%
-- ✅ Audit externe annuel (sécurité)
-**Excellence technique et éthique.**
+- ✅ Audit externe annuel (sécurité) 
+
+  **Excellence technique et éthique.**
+
 ---
+
 #### Pour Platine (Score global ≥ 90, chaque domaine ≥ 85)
+
 **Ajouter :**
+
 - ✅ 90% des critères recommandés
 - ✅ Majorité critères d'excellence
 - ✅ Contributions majeures multiples
 - ✅ Zéro incident P0 (12 mois)
-- ✅ Innovation partagée (publication, conférences)
-**Modèle inspirant.**
+- ✅ Innovation partagée (publication, conférences) 
+
+  **Modèle inspirant.**
+
 ---
+
 ### Annexe B : Templates de Documents
+
 #### B.1 Demande de Labellisation
+
 ```yaml
 demande_label:
   membre_id: m001-exemple
@@ -1010,8 +1270,11 @@ demande_label:
     - "2025-11-01 to 2025-11-30"
     - "2025-12-01 to 2025-12-15"
 ```
+
 ---
+
 #### B.2 Rapport d'Audit (Structure Minimale)
+
 ```markdown
 # Rapport d'Audit — Label Alliance Boréale
 ## Informations Générales
@@ -1044,8 +1307,11 @@ demande_label:
 Le membre XXX démontre une bonne maturité opérationnelle. Le niveau Argent est mérité sous réserve de correction du domaine 6 (Sobriété) dans les 6 mois.
 **Signature électronique** : [Auditeur], [Date]
 ```
+
 ---
+
 ### Annexe C : Calendrier Type d'Audit
+
 ```
 Semaine 0 : Demande labellisation
 Semaine 1 : Désignation auditeur + kick-off
@@ -1057,9 +1323,11 @@ Semaine 7 : Validation Cercle Éthique
 Semaine 8 : Attribution label + communication
 Total : ~8 semaines (2 mois)
 ```
-**Version accélérée (recertification, si simplifié) : 4-5 (Orchestration, Supervision) semaines**
----
+
+## **Version accélérée (recertification, si simplifié) : 4-5 (Orchestration, Supervision) semaines**
+
 ## MÉTADONNÉES
+
 **Document :** 03_Cadre_Conformite_Label_Prestige.md
 **Version :** 1.0
 **Date de création :** 23 octobre 2025
@@ -1069,17 +1337,19 @@ Total : ~8 semaines (2 mois)
 **Longueur :** ~14 000 mots (28 pages avec grilles détaillées)
 **Licence :** CC BY-SA 4.0
 **Sources utilisées :**
+
 - `00_Glossaire_et_Definitions.md`
 - `01_Charte_Fondatrice_v2_1.md`
 - `02_Reglement_de_Regie_Interne.md`
-- `devis_alliance_boreale_v2.md`
-**Prochaine révision prévue :** Octobre 2026 (Q4, annuelle)
+- `devis_alliance_boreale_v2.md`**Prochaine révision prévue :** Octobre 2026 (Q4, annuelle)
+
 ---
+
 **Changelog :**
+
 - 2025-10-23 v1.0 : Création initiale du Cadre de Conformité et Label
+
 ---
-**FIN DU CADRE DE CONFORMITÉ ET LABEL DE PRESTIGE**
-*"Le label n'est pas une médaille à accrocher. C'est un miroir qui nous montre qui nous sommes vraiment."*
-🌲 **L'Alliance Boréale**
-*Excellence mesurée, amélioration continue, transparence totale.*
- 
+
+**FIN DU CADRE DE CONFORMITÉ ET LABEL DE PRESTIGE***"Le label n'est pas une médaille à accrocher. C'est un miroir qui nous montre qui nous sommes vraiment."*
+🌲 **L'Alliance Boréale***Excellence mesurée, amélioration continue, transparence totale.*
\ No newline at end of file
diff --git a/docs/constitution/03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md b/docs/constitution/03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md
deleted file mode 100644
index f3c4810..0000000
--- a/docs/constitution/03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md
+++ /dev/null
@@ -1,95 +0,0 @@
-📘 **Document pivot :** `03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md`
-🧭 **Références structurantes :**
-
-* `00_Modele_8_couches_biomimetique_autopoietique_v3.md`
-* `00_Glossaire_biomimetique_autopoietique_v3.md`
-* `02_Reglement_de_Regie_Interne_biomimetique_autopoietique_v3.md`
-
-### 🎯 **Objectif**
-
-Transformer le cadre de conformité d’un système d’audit statique en un **système de vitalité et de confiance vivante**.
-Le Label de Prestige devient le **symptôme d’un organisme en santé**, non un badge de conformité.
-
----
-
-## 🧬 **Trame organique du nouveau Cadre de Conformité (v3)**
-
-### 1. **Préambule — Avis de Réalignement CRB-4**
-
-> Le label évalue la vitalité d’un membre, non sa perfection.
-> La conformité boréale est un équilibre : un système est “prestigieux” quand il sait se régénérer.
-
-### 2. **Introduction — De la conformité à la vitalité**
-
-* Le contrôle devient **observation**.
-* L’auditeur devient **symbiote**.
-* L’évaluation devient **dialogue**.
-
-### 3. **Principes organiques du label**
-
-| Principe               | Description                                     | Fonction biologique |
-| :--------------------- | :---------------------------------------------- | :------------------ |
-| **Autopoïèse évaluée** | Capacité du membre à se corriger lui-même.      | Régénération        |
-| **Homéostasie**        | Stabilité dynamique des flux internes.          | Équilibre           |
-| **Transparence**       | Visibilité des processus et des ΔLogs.          | Perception          |
-| **Symbiose**           | Coopération saine avec les autres membres.      | Écologie            |
-| **Frugalité**          | Utilisation mesurée des ressources communes.    | Métabolisme sobre   |
-| **Portabilité**        | Capacité d’exporter ses artefacts et identités. | Reproduction        |
-
-### 4. **Processus de labellisation vivante**
-
-1. **Observation** : un cercle pair examine les preuves vivantes (ΔLogs, ADN YAML, traces).
-2. **Dialogue** : discussion inter-membres ; l’auditeur écoute avant d’évaluer.
-3. **Régénération** : corrections ou apprentissages activés dans les 30 jours.
-4. **Attestation** : le label est renouvelé automatiquement quand l’équilibre est constaté.
-
-### 5. **Instruments de mesure**
-
-* **Biomarqueurs organisationnels :** stabilité, réactivité, transparence.
-* **Biomarqueurs techniques :** taux de portabilité, intégrité des artefacts, qualité des ΔLogs.
-* **Biomarqueurs éthiques :** bienveillance, sobriété, solidarité inter-tenant.
-
-### 6. **Rôles et responsabilités**
-
-* **Cercle fédératif** : définit les métriques communes (ADN de conformité).
-* **Cercle pivot** : collecte les flux d’observation.
-* **Cercle tenant** : démontre sa vitalité à travers la transparence et la coopération.
-* **Cercle d’harmonisation** (nouveau) : facilite la compréhension entre pairs.
-
-### 7. **Cycle de vie du Label**
-
-1. **Émergence** → première évaluation collaborative.
-2. **Maturation** → partage des apprentissages.
-3. **Régénération** → adaptation à de nouveaux contextes.
-4. **Transfert** → transmission du savoir aux nouveaux membres.
-
-### 8. **Révocation et renouvellement**
-
-Le label n’est jamais “retiré” : il **entre en dormance** lorsqu’un système cesse d’émettre des signes de vitalité.
-Il est **réveillé** dès que le membre montre une reprise d’activité organique.
-
-### 9. **Documentation et ΔLog**
-
-Chaque labellisation génère :
-
-* un `label.yaml` (métadonnées, périmètre, scores),
-* un ΔLog daté, signé et archivé,
-* un lien vers le glossaire et la charte cognitive correspondants.
-
----
-
-### 📜 **ΔLog — CRB-4 (25-10-2025)**
-
-* Transformation du cadre d’audit en cadre de vitalité.
-* Introduction des **biomarqueurs** et du **cycle de régénération du label**.
-* Adoption de la métaphore biologique dans les évaluations.
-* Alignement avec le Règlement v3 et le Modèle biomimétique.
-
----
-
-### 🌌 **Signature Boréale**
-
-> *Un label n’est pas un sceau, mais une respiration.*
-> *Quand la confiance circule, la forêt prospère.*
-> *Quand la sève s’arrête, le label se tait.*
-> *Et renaît dès qu’un membre reprend vie.*
diff --git a/docs/pile opérateur/README.md b/docs/pile opérateur/README.md
new file mode 100644
index 0000000..ffc1196
--- /dev/null
+++ b/docs/pile opérateur/README.md	
@@ -0,0 +1,76 @@
+# README - Pile C1-C5 (Opérateur de référence)
+
+Ce dépôt est la **source de vérité** (documentation + configuration + preuves) de la **Pile opérateur de référence** pour l’Alliance Boréale (couches **C1 à C5**).  
+Références normatives : **ADR-OPS-STACK-001** (décision) et **POL-OPS-STACK-001** (exigences + preuves).
+
+## 1) Principes non négociables
+
+- **Membrane** : tout accès exposé passe par **C5 (NGINX + ModSecurity)**, sans bypass vers C2/C3/C4.
+- **Traçabilité** : tout changement passe par **PR + ΔLog**, et génère ses preuves.
+- **Séparation IaC** : **C4 = plan de vérité** (code, PR, CI, plan) ; **C5 = plan d’exécution** (runner `apply` sous contrôle de la membrane).
+
+## 2) Table — Stack opérateur (Exposition + Preuves)
+
+> Les “preuves” ci-dessous référencent les identifiants exigés par **POL-OPS-STACK-001** (Cx-Ey). Les détails (contenu exact attendu) sont dans la POL.
+
+| Couche | Domaine                      | Composant                  | Exposition                                    | Preuves attendues                      |
+|--------|------------------------------|----------------------------|-----------------------------------------------|----------------------------------------|
+| C1     | Virtualisation               | Proxmox VE                 | Admin-only (réseau gestion)                   | C1-E1, C1-E3                           |
+| C1     | Stockage distribué           | Ceph                       | Admin-only (réseau stockage/gestion)          | C1-E2, C1-E3                           |
+| C1     | NAS / landing zone / backup  | TrueNAS                    | Admin-only                                    | C1-E4 (si activé)                      |
+| C2     | Pare-feu / segmentation      | OPNsense                   | Admin-only (enforcement réseau)               | C2-E1, C2-E2                           |
+| C2     | DNS autoritatif              | PowerDNS Authoritative     | Interne fédération (pas tenants)              | C2-E3                                  |
+| C2     | VPN admin / interco          | WireGuard                  | Ops-only                                      | C2-E4                                  |
+| C3     | SSO / IAM                    | Keycloak                   | Via C5 (portails/UI) ; admin-only direct      | C3-E1                                  |
+| C3     | Annuaire                     | OpenLDAP                   | Interne (consommé par C3)                     | C3 (documenter si requis)              |
+| C3     | Monitoring états/SLA         | Icinga2                    | Lecture via C5 (Icinga Web) ; checks internes | C3-E2, C3-E3                           |
+| C3     | UI monitoring                | Icinga Web 2               | Via C5 (SSO)                                  | C3-E2, C3-E3                           |
+| C3     | Dashboards audit/SLA         | Icinga Web 2 – BPM         | Via C5 (SSO)                                  | C3-E2                                  |
+| C3     | Observabilité métriques      | Prometheus                 | Interne ; consulté via Grafana                | C3-E4                                  |
+| C3     | Alerting métriques           | Alertmanager               | Ops-only (notifications)                      | C3-E4                                  |
+| C3     | Dashboards unifiés           | Grafana                    | Via C5 (SSO)                                  | C3-E5                                  |
+| C3     | Logs centralisés (référence) | Loki                       | Ingestion via C5 ; lecture via Grafana        | C3-E6 (+ ADR-OBS-001, POL-OBS-LOG-001) |
+| C4     | Forge / traçabilité          | Forgejo                    | Via C5 (SSO)                                  | C4-E1                                  |
+| C4     | CI / validation              | Forgejo Actions            | Interne (CI)                                  | C4-E2                                  |
+| C4     | Registre artefacts           | Harbor                     | Via C5 (auth)                                 | C4-E3                                  |
+| C4     | Secrets                      | Vault                      | Interne ; accès restreint (C3/C5)             | C4-E4                                  |
+| C4     | Référentiels IaC             | OpenTofu + Ansible (code)  | Via Forgejo (PR/CI)                           | C4-E5                                  |
+| C5     | Reverse proxy / WAF          | NGINX + ModSecurity        | Public/tenant-facing (point d’entrée unique)  | C5-E1, C5-E2                           |
+| C5     | Pivot API / portail          | FastAPI                    | Via NGINX (SSO)                               | C5-E3                                  |
+| C5     | DNS récursif tenants         | Unbound                    | Tenants uniquement (C6+)                      | C5-E4                                  |
+| C5     | Runner d’exécution IaC       | OpenTofu + Ansible (apply) | Ops-only (membrane)                           | C5-E5                                  |
+
+## 3) IaC : “C4 vérité / C5 exécution” (règle opérateur)
+
+- **C4 (Forgejo + Actions)** héberge le *code* (OpenTofu/Ansible), les PR, le ΔLog, et la **validation** (lint/format/tests + `tofu plan` attaché aux PR).
+- **C5 (runner contrôlé)** exécute les actions à privilèges (`tofu apply`, `ansible-playbook`) avec secrets fournis via Vault et accès réseau minimal requis.
+- Toute exécution IaC doit être **traçable** : PR → job → logs d’exécution → preuves déposées dans `/evidence/`.
+
+## 4) Mode d’audit (trimestriel) — 12 lignes
+
+ 1. Ouvrir la période dans `/evidence/quarterly/YYYY-Qn/`.
+ 2. Vérifier la présence de l’index `evidence/00_Evidence_Index.md` mis à jour.
+ 3. Confirmer C2-E1 (export OPNsense) et C2-E2 (tests non-bypass) pour la période.
+ 4. Confirmer C3-E1 (export Keycloak) et cohérence RBAC ops/audit.
+ 5. Confirmer C3-E2 (exports BPM) couvrant au minimum les services C1–C5.
+ 6. Confirmer C3-E3 (couverture checks Icinga + historique alertes/incidents).
+ 7. Confirmer C3-E4 (targets Prometheus + règles Alertmanager + exemple d’alerte).
+ 8. Confirmer C3-E5 (exports dashboards Grafana + sources).
+ 9. Confirmer C3-E6 (Loki : labels/rétention + requêtes de preuve reproductibles).
+10. Confirmer C4-E1..E4 (Forgejo/Actions/Harbor/Vault) avec artefacts et journaux.
+11. Confirmer C4-E5 et C5-E5 (IaC : plan attaché PR + logs d’apply côté C5).
+12. Produire un ΔLog “Audit trimestriel” liant les preuves et conclure OK/KO.
+
+## 5) Structure du dépôt (résumé)
+
+- `/adr/` : décisions (dont ADR-OPS-STACK-001)
+- `/pol/` : politiques (dont POL-OPS-STACK-001, POL-OBS-LOG-001)
+- `/configs/` : configs versionnées (opnsense/nginx/unbound/icinga/grafana/loki/harbor/vault, etc.)
+- `/iac/` : OpenTofu + Ansible (code) + inventory
+- `/runbooks/` : procédures opératoires (incluant exécution IaC en C5)
+- `/evidence/` : preuves datées + index (audit mécanique)
+- `/dashboards/` : exports Grafana et Icinga BPM
+
+## 6) Règle d’or
+
+Si ce n’est pas **versionné**, **traçable**, et **prouvable**, ça n’existe pas dans la pile opérateur.
\ No newline at end of file
diff --git a/docs/pile opérateur/adr/ADR-OBS-001 — Loki comme backend de logs de référence.md b/docs/pile opérateur/adr/ADR-OBS-001 — Loki comme backend de logs de référence.md
new file mode 100644
index 0000000..6856705
--- /dev/null
+++ b/docs/pile opérateur/adr/ADR-OBS-001 — Loki comme backend de logs de référence.md	
@@ -0,0 +1,105 @@
+# ADR-OBS-001 — Loki comme backend de logs de référence
+
+**Version :** 1.0  
+**Date :** 25 janvier 2026  
+**Cycle de Réalignement Boréal :** CRB-3  
+**Statut :** Adopté (référence vivante)  
+**Portée :** Fédération (C3), Pivot (C5), Membres affiliés, Tenants (C6–C8)
+
+---
+
+## 1. Contexte
+
+L’Alliance Boréale requiert une capacité de **journalisation** (logs) commune, interopérable et auditable, compatible avec :
+
+- La séparation **Fédération / Pivot / Tenants**
+- Le principe **adjacent-only** (aucun flux ne saute une couche)
+- La **portabilité** des tenants (export/rejeu possible, preuves de fonctionnement)
+
+Les logs sont un intrant critique pour :
+
+- la résilience opérationnelle (diagnostic, incident, détection)
+- la conformité (preuves, audits, traçabilité)
+- la gouvernance (ΔLog et boucles de rétroaction)
+
+---
+
+## 2. Décision
+
+**Grafana Loki** est adopté comme **backend de logs de référence** pour l’architecture de référence Alliance Boréale.
+
+Cela signifie :
+
+1. **Référence technologique**
+
+- Loki est l’implémentation de référence pour l’ingestion, le stockage, la rétention et la requête de logs.
+
+1. **Référence d’intégration**
+
+- Les flux logs des tenants (C6–C8) et des services pivot (C5) transitent via le **Pivot (C5)** vers la **capacité observabilité fédérée (C3)**, conformément à l’adjacent-only.
+
+1. **Référence d’agent**
+
+- **Grafana Alloy** est l’agent de collecte/expédition recommandé par défaut.
+- Les alternatives sont tolérées uniquement si elles respectent le contrat de la politique `POL-OBS-LOG-001`.
+
+---
+
+## 3. Alternatives considérées
+
+### A) Stack “full-text” (indexation complète)
+
+- Avantage : recherche textuelle plus directe.
+- Inconvénients : coût/complexité plus élevés, risques de dérives (indexation incontrôlée, PII), difficile à rendre “facile aux petits”.
+
+### B) “Un Loki par membre” (décentralisé)
+
+- Avantage : simplicité locale, autonomie.
+- Inconvénients : dispersion des pratiques, consolidation fédérale plus difficile, effort d’opération multiplié.
+
+### C) “Loki fédéré + ingestion via Pivot” (modèle retenu)
+
+- Avantages : simplicité pour les petits (un seul endpoint), cohérence fédérale, contrôle d’accès et preuves centralisées, isolation par tenant.
+- Inconvénient : nécessite un pivot/gateway bien cadré (mais c’est déjà un invariant C5).
+
+---
+
+## 4. Conséquences (ce que cela change)
+
+### 4.1 Pour les membres affiliés (petits inclus)
+
+- Ils n’ont pas l’obligation d’opérer Loki localement.
+- Ils doivent être **compatibles Loki** : capacité d’expédier des logs via l’endpoint standard (TLS, auth, labels conformes).
+
+### 4.2 Pour la Fédération (C3)
+
+- Opération d’un Loki “référence” (au minimum en mode simple) + Grafana de consultation.
+- Mise en place des politiques : rétention, quotas, RBAC, preuves auditables.
+
+### 4.3 Pour le Pivot (C5)
+
+- Le pivot devient **le point d’entrée unique** pour l’ingestion et la consultation (proxy/gateway).
+- Le pivot applique l’authentification, la médiation (multi-tenant masquée) et les contrôles de conformité (labels/quotas).
+
+---
+
+## 5. Décision opérationnelle de démarrage (MVP)
+
+- **Mode de déploiement Loki** : démarrage en mode simple (priorité à l’opérabilité).
+- **Chemin d’ingestion** : agents (C6/C5) → Gateway Pivot (C5) → Loki (C3).
+- **Chemin de consultation** : utilisateurs → Grafana (C3) via Gateway Pivot (C5) + SSO (Keycloak).
+- **Multi-tenant** : géré par le Pivot (C5). Les petits n’ont pas à manipuler l’isolation.
+
+---
+
+## 6. Critères d’acceptation
+
+La décision est considérée “en place” lorsque :
+
+1. Un membre affilié peut expédier des logs avec Alloy vers l’endpoint pivot, sans configuration complexe.
+2. Les labels minimaux requis sont présents et conformes (cardinalité maîtrisée).
+3. Un utilisateur autorisé peut consulter les logs dans Grafana via SSO.
+4. La rétention par défaut est appliquée et vérifiable.
+5. Les preuves minimales d’audit (configuration + traces d’exécution + exemple de requêtes) sont archivées.
+
+---
\ No newline at end of file
diff --git a/docs/pile opérateur/adr/ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5).md b/docs/pile opérateur/adr/ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5).md
new file mode 100644
index 0000000..74c14d5
--- /dev/null
+++ b/docs/pile opérateur/adr/ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5).md	
@@ -0,0 +1,151 @@
+# ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5)
+
+**Version :** 1.1  
+**Date :** 26 janvier 2026  
+**Statut :** Adopté (référence vivante)  
+**Portée :** Opérateurs (C1–C5), Gouvernance, Audit interne/externe
+
+---
+
+## 1. Contexte
+
+L’Alliance Boréale requiert une pile logicielle “Opérateur” stable, reproductible et audit-ready pour opérer les couches **C1 à C5** :
+
+- **C1** : capacité (compute) et stockage primaire
+- **C2** : segmentation, edge, DNS autoritatif, accès opérateurs
+- **C3** : identité et observabilité (SLA, métriques, logs)
+- **C4** : forge, traçabilité, CI, artefacts, secrets (plan de vérité)
+- **C5** : pivot/membrane (point d’entrée unique) et exécution contrôlée (plan d’exécution)
+
+Cette standardisation vise :
+- réduction de la variabilité inter-opérateurs,
+- amélioration de l’auditabilité (preuves uniformes),
+- simplification du déploiement et de l’exploitation,
+- cohérence stricte avec le principe de membrane (C5).
+
+---
+
+## 2. Décision
+
+La pile logicielle suivante est adoptée comme **Pile opérateur de référence** (C1–C5).
+
+### 2.1 Stack par couche (C1–C5)
+
+**C1 — Compute & Storage**
+- Proxmox VE
+- Ceph
+- TrueNAS
+
+**C2 — Segmentation, Edge, DNS autoritatif, Accès ops**
+- OPNsense
+- PowerDNS Authoritative
+- WireGuard
+
+**C3 — IAM & Observabilité**
+- Keycloak
+- OpenLDAP
+- Icinga2 + Icinga Web 2 + BPM
+- Prometheus + Alertmanager
+- Grafana
+- Loki
+
+**C4 — Forge, CI, Artefacts, Secrets (plan de vérité)**
+- Forgejo
+- Forgejo Actions (CI de validation)
+- Harbor
+- Vault
+- Référentiels IaC : OpenTofu (modules) + Ansible (playbooks/inventaires)
+
+**C5 — Pivot / membrane (plan d’exécution)**
+- NGINX + ModSecurity
+- FastAPI
+- Unbound
+- Exécution IaC : runner contrôlé (OpenTofu + Ansible)
+
+---
+
+## 3. Règles d’architecture associées
+
+### 3.1 Membrane (point d’entrée unique)
+
+- **NGINX + ModSecurity (C5)** constitue le **point d’entrée unique** pour les accès utilisateurs/tenants vers les services exposés (portails, APIs, consultation dashboards).
+- Les composants internes (C2–C4) ne sont pas exposés directement aux tenants.
+
+### 3.2 Cloisonnement “adjacent-only” (principe opérateur)
+
+- Le cloisonnement réseau impose une logique “default deny” et une segmentation par couches.
+- Tout contournement de C5 (bypass) est considéré comme une non-conformité sauf exception formalisée.
+
+### 3.3 Traçabilité (PR + ΔLog)
+
+- Toute modification (config, infra, politiques, runbooks) est versionnée dans Forgejo via PR.
+- Chaque PR doit être reliée à une entrée ΔLog (trace de décision et de preuve).
+
+### 3.4 Séparation IaC : référentiel vs exécution (invariant)
+
+Cette séparation est un invariant (sécurité + gouvernance), pas une convention de mots :
+
+- **C4 (plan de vérité)** : contient et gouverne le **code IaC** (OpenTofu/Ansible), la validation CI (format/lint/tests/plan), et la traçabilité (PR/ΔLog).
+- **C5 (plan d’exécution)** : exécute les actions à privilèges (ex. `tofu apply`, `ansible-playbook`) via un **runner contrôlé**, afin de :
+  - concentrer les privilèges au niveau de la membrane,
+  - imposer des contrôles uniformes (RBAC, quotas, journalisation),
+  - empêcher qu’une compromission de la forge/CI se transforme automatiquement en compromission infra.
+
+> Note : le runner d’exécution peut être techniquement un “Forgejo Actions runner”, mais son **positionnement réseau et ses droits** le rattachent à C5 (membrane).
+
+---
+
+## 4. Conséquences
+
+### 4.1 Bénéfices
+
+- Standardisation : onboarding opérateur accéléré.
+- Auditabilité : preuves minimales uniformes (BPM, Grafana, Loki, exports OPNsense).
+- Réduction de la surface d’attaque : exécution IaC contrôlée et centralisée en C5.
+- Exploitabilité : séparation claire entre observabilité (C3) et exposition (C5).
+
+### 4.2 Obligations
+
+- Discipline de changements : PR + ΔLog obligatoires.
+- Preuves : collecte structurée et indexée selon la politique `POL-OPS-STACK-001`.
+- Maintien : versions supportées, runbooks, et exécutions IaC traçables.
+
+---
+
+## 5. Critères d’acceptation
+
+La pile est considérée **en place** pour un opérateur lorsque :
+
+1) Tous les composants (C1–C5) sont déployés et accessibles conformément au principe de membrane.  
+2) Le cloisonnement réseau est démontré (OPNsense + tests de non-bypass).  
+3) SSO (Keycloak) protège les portails (Grafana, Icinga Web) via C5.  
+4) Les preuves minimales `POL-OPS-STACK-001` existent, datées et indexées.  
+5) Les changements IaC sont gouvernés en C4, et exécutés via C5 avec traçabilité complète.
+
+---
+
+## 6. Gouvernance des changements
+
+Toute modification à la pile opérateur de référence exige :
+
+- PR + ΔLog,
+- mise à jour des runbooks et des preuves attendues,
+- ADR additionnel si changement de composant ou de rôle.
+
+---
+
+## 7. Références internes
+
+- POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5) — preuves attendues
+- ADR-OBS-001 — Loki comme backend de logs de référence
+- POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki
+
+---
+
+## 8. ΔLog (à compléter au commit)
+
+- Décision : Adoption de la pile opérateur de référence (C1–C5)  
+- Auteur(s) : __________________  
+- Référence PR : __________________  
+- Date d’entrée : __________________
+
diff --git a/docs/pile opérateur/evidence/00_Evidence_Index.md b/docs/pile opérateur/evidence/00_Evidence_Index.md
new file mode 100644
index 0000000..1ed219e
--- /dev/null
+++ b/docs/pile opérateur/evidence/00_Evidence_Index.md	
@@ -0,0 +1,16 @@
+## Index des preuves
+
+### Règles
+
+Chaque preuve doit être :
+
+- datée,
+- rattachée à une couche (C1..C5),
+- rattachée à une exigence (ex. C3-E2),
+- exportable et vérifiable.
+
+### Tableau d’index (à compléter)
+
+| Date       | Période | Couche | Référence exigence | Fichier(s)                               | Commentaire          |
+|------------|---------|--------|--------------------|------------------------------------------|----------------------|
+| 2026-01-26 | 2026-Q1 | C2     | C2-E1              | quarterly/2026-Q1/C2/opnsense-export.xml | Export config + hash |
diff --git a/docs/pile opérateur/evidence/templates/Evidence-Checklist.md b/docs/pile opérateur/evidence/templates/Evidence-Checklist.md
new file mode 100644
index 0000000..74ddfee
--- /dev/null
+++ b/docs/pile opérateur/evidence/templates/Evidence-Checklist.md	
@@ -0,0 +1,40 @@
+## Checklist trimestrielle — Pile opérateur (C1–C5)
+
+### C1
+
+- [ ] C1-E1 Inventaire Proxmox
+- [ ] C1-E2 Santé Ceph + capacité
+- [ ] C1-E3 Restore test (preuve)
+- [ ] C1-E4 TrueNAS (si activé)
+
+### C2
+
+- [ ] C2-E1 Export OPNsense + matrice flux
+- [ ] C2-E2 Test non-bypass / adjacent-only
+- [ ] C2-E3 Inventaire PowerDNS + ΔLog
+- [ ] C2-E4 WireGuard (pairs + logs + runbook)
+
+### C3
+
+- [ ] C3-E1 Export Keycloak + RBAC
+- [ ] C3-E2 BPM “auditeur” (exports)
+- [ ] C3-E3 Checks Icinga + historique
+- [ ] C3-E4 Prometheus targets + Alertmanager rules
+- [ ] C3-E5 Dashboards Grafana (exports)
+- [ ] C3-E6 Loki (labels/rétention/requêtes)
+
+### C4
+
+- [ ] C4-E1 Règles Forgejo (PR/branches) + ΔLog
+- [ ] C4-E2 Logs Forgejo Actions (CI)
+- [ ] C4-E3 Harbor (RBAC/rétention/provenance)
+- [ ] C4-E4 Vault (policies/audit/rotation)
+- [ ] C4-E5 IaC validation (lint/plan attaché PR)
+
+### C5
+
+- [ ] C5-E1 Config NGINX + ModSecurity + TLS
+- [ ] C5-E2 Logs NGINX (preuve médiation)
+- [ ] C5-E3 FastAPI (OpenAPI/logs/admission/quotas)
+- [ ] C5-E4 Unbound (ACL/logs)
+- [ ] C5-E5 Runner IaC (logs apply + liens PR→exécution)
\ No newline at end of file
diff --git a/docs/pile opérateur/evidence/templates/Evidence-Naming-Convention.md b/docs/pile opérateur/evidence/templates/Evidence-Naming-Convention.md
new file mode 100644
index 0000000..d251d8d
--- /dev/null
+++ b/docs/pile opérateur/evidence/templates/Evidence-Naming-Convention.md	
@@ -0,0 +1,10 @@
+## Convention de nommage — preuves
+
+Format recommandé :
+`YYYY-MM-DD__<Periode>__<Couche>__<Exigence>__<Objet>.<ext>`
+
+Exemples :
+
+- `2026-01-26__2026-Q1__C2__C2-E1__opnsense-export.xml`
+- `2026-01-26__2026-Q1__C3__C3-E2__icinga-bpm-export.json`
+- `2026-01-26__2026-Q1__C5__C5-E1__nginx-conf.tar.gz`
\ No newline at end of file
diff --git a/docs/pile opérateur/evidence/templates/docs/ΔLog-Template.md b/docs/pile opérateur/evidence/templates/docs/ΔLog-Template.md
new file mode 100644
index 0000000..2a1af16
--- /dev/null
+++ b/docs/pile opérateur/evidence/templates/docs/ΔLog-Template.md	
@@ -0,0 +1,12 @@
+## ΔLog — Entrée standard
+
+- Date :
+- Auteur :
+- Changement :
+- Portée (C1..C5) :
+- Justification :
+- Risques :
+- Mesures compensatoires :
+- Preuves générées (liens /evidence/) :
+- Liens PR :
+- Liens exécution (CI / runner C5) :
\ No newline at end of file
diff --git a/docs/pile opérateur/pol/POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki.md b/docs/pile opérateur/pol/POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki.md
new file mode 100644
index 0000000..0b99f0b
--- /dev/null
+++ b/docs/pile opérateur/pol/POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki.md	
@@ -0,0 +1,219 @@
+# POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki
+
+**Version :** 1.0  
+**Date :** 25 janvier 2026  
+**Cycle de Réalignement Boréal :** CRB-3  
+**Statut :** Obligatoire (référence vivante)  
+**Portée :** C3 (Observabilité fédérée), C5 (Pivot), C6–C8 (Tenants), Membres affiliés
+
+---
+
+## 1. Objet
+
+Définir le **contrat minimal** de collecte, transport, étiquetage, rétention, accès et preuves pour les logs,
+avec **Loki** comme backend de référence.
+
+Cette politique vise explicitement la simplicité d’adoption par les petits membres :
+
+- un endpoint standard,
+- une configuration “copier-coller” (agent),
+- un jeu de labels minimal,
+- un modèle d’accès via SSO.
+
+---
+
+## 2. Principes invariants
+
+### 2.1 Adjacent-only (obligatoire)
+
+- Les logs **ne contournent jamais** le pivot.
+- Chemin normatif : **C6 → C5 → C3** (tenant vers pivot vers fédération).
+
+### 2.2 Séparation Fédération / Tenants
+
+- Les tenants sont isolés en lecture/écriture.
+- La Fédération peut opérer et auditer sans exposer les couches internes.
+
+### 2.3 Simplicité opératoire
+
+- Un petit membre n’a pas à comprendre le multi-tenant.
+- L’isolation est assurée **par le Pivot (C5)**.
+
+---
+
+## 3. Référence technique
+
+### 3.1 Backend
+
+- **Loki** = backend de logs de référence.
+
+### 3.2 Visualisation / requêtes
+
+- **Grafana** = interface de consultation de référence.
+
+### 3.3 Agent de collecte
+
+- **Grafana Alloy** = agent recommandé par défaut.
+- Autres agents acceptés si : 
+  - ils supportent l’ingestion Loki via HTTP(S),
+  - ils respectent les labels et les contraintes de cette politique,
+  - ils n’introduisent pas de labels à haute cardinalité.
+
+---
+
+## 4. Points d’entrée (endpoints) — standardisation
+
+### 4.1 Ingestion (écriture)
+
+- Endpoint unique via le Pivot (C5) : `https://logs.pivot.<membre>.alliance-boreale.ca/...`
+- Interdiction : accès direct tenant → Loki (C3).
+
+### 4.2 Consultation (lecture)
+
+- Accès Grafana via Pivot (C5) (reverse-proxy) + SSO (Keycloak).
+
+> Note : Le chemin exact (`/loki/api/v1/push`, etc.) est défini par l’implémentation du Gateway,
+> mais l’invariant est : **une URL unique, TLS obligatoire, auth obligatoire**.
+
+---
+
+## 5. Authentification & autorisation
+
+### 5.1 Lecture (Grafana)
+
+- SSO via **Keycloak** (OIDC/SAML).
+- RBAC : permissions par organisation/tenant et par rôle (admin, ops, lecteur).
+
+### 5.2 Écriture (agents)
+
+Mode recommandé (simple) :
+
+- Token d’ingestion (Bearer) par organisation/tenant, délivré/provisionné via le Pivot.
+- Le secret est stocké comme **secret** (Vault ou mécanisme équivalent), jamais en clair dans un repo.
+
+Mode alternatif (si requis) :
+
+- mTLS avec certificats gérés par la Fédération.
+
+---
+
+## 6. Isolation (multi-tenant) — masquée pour les petits
+
+### 6.1 Principe
+
+- Le Pivot (C5) est responsable d’assigner l’isolement tenant (ex. injection d’un identifiant d’organisation).
+- Les petits membres/tenants ne manipulent pas l’identifiant d’isolation.
+
+### 6.2 Interdictions
+
+- Un agent ne doit pas pouvoir écrire dans un autre tenant.
+- Toute tentative d’accès hors périmètre est loggée et alertée.
+
+---
+
+## 7. Labels (schéma Boréal) — minimal et stable
+
+### 7.1 Labels obligatoires (MVP)
+
+Chaque stream de logs DOIT inclure au minimum :
+
+- `org` : organisation ou tenant (valeur stable)
+- `env` : `prod | preprod | dev`
+- `service` : nom stable du service (ex. `pivot-api`, `forgejo`, `nextcloud`, `tenant-app`)
+- `member` : code membre (ex. `czp`, `mtl`, `qc2`)
+
+### 7.2 Labels optionnels (avec prudence)
+
+- `host` : nom machine/VM (stable)
+- `layer` : couche (`c3`, `c5`, `c6`, etc.) si utile
+
+### 7.3 Interdictions (cardinalité)
+
+Il est strictement interdit de promouvoir en labels des valeurs à haute cardinalité, incluant (non exhaustif) :
+
+- `trace_id`, `span_id`, `request_id`, `session_id`
+- `user_id`, `email`, identifiants personnels
+- timestamps, UUIDs, numéros de commande, adresses IP client
+
+Ces valeurs doivent rester dans le **contenu** du log (requêtables), pas dans les labels.
+
+---
+
+## 8. Qualité des logs (hygiène minimale)
+
+### 8.1 Format recommandé
+
+- JSON structuré si possible (clé/valeur), sinon logfmt.
+- Les champs sensibles doivent être masqués (redaction) avant expédition.
+
+### 8.2 Données sensibles
+
+- Ne pas expédier de secrets (tokens, clés, mots de passe).
+- Ne pas expédier de données personnelles non nécessaires.
+- Si un tenant a des contraintes particulières, il doit fournir une règle de redaction.
+
+---
+
+## 9. Rétention & classes de service
+
+### 9.1 Rétention par défaut (standard)
+
+- **14 jours** (sauf exception documentée).
+
+### 9.2 Exceptions
+
+- Toute rétention supérieure (ex. “régulé”) doit être : 
+  - justifiée,
+  - validée par gouvernance (C3),
+  - accompagnée de preuves (stockage, coûts, risques, contrôles).
+
+---
+
+## 10. Quotas & protection
+
+Le Pivot (C5) doit appliquer :
+
+- quotas d’ingestion (taux, volume/jour),
+- limites de taille par entrée,
+- protections anti-boucle / anti-tempête (burst control),
+- blocage ou mise en quarantaine en cas de non-conformité (labels interdits, volumes anormaux).
+
+---
+
+## 11. Preuves minimales (audit)
+
+Pour être “conforme POL-OBS-LOG-001”, les preuves suivantes doivent être disponibles :
+
+1. Configuration du Gateway (C5) : TLS, auth, routage, quotas.
+2. Configuration Loki (C3) : rétention, stockage, limites, accès.
+3. Exemple de configuration agent (Alloy) “copier-coller” (template).
+4. Démonstration : une requête Grafana/Loki qui retourne des logs d’un service donné.
+5. Journal des incidents de non-conformité (tentatives cross-tenant, labels interdits).
+
+---
+
+## 12. Non-conformité & remédiation
+
+### 12.1 Détection
+
+- Toute violation (labels interdits, volumétrie anormale, tentative cross-tenant) déclenche : 
+  - un événement de sécurité/opérations,
+  - une entrée de traçabilité (ΔLog / incident).
+
+### 12.2 Réponse
+
+- Quarantaine du flux (au pivot) si nécessaire.
+- Correction du template agent.
+- Ajustement des politiques si apprentissage systémique requis.
+
+---
+
+## 13. Annexes
+
+### A) Requête Loki (exemple conceptuel)
+
+- `{org="t001", env="prod", service="pivot-api", member="czp"}`
+
+### B) Convention de nommage (rappel)
+
+- Conformité à la Nomenclature v3 pour VMID, DNS, et segmentation par couche.
\ No newline at end of file
diff --git a/docs/pile opérateur/pol/POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5).md b/docs/pile opérateur/pol/POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5).md
new file mode 100644
index 0000000..257803e
--- /dev/null
+++ b/docs/pile opérateur/pol/POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5).md	
@@ -0,0 +1,212 @@
+# POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5) — Exigences & preuves attendues
+
+**Version :** 1.1  
+**Date :** 26 janvier 2026  
+**Statut :** Obligatoire (référence vivante)  
+**Portée :** Opérateurs (C1–C5), Gouvernance, Audit
+
+---
+
+## 1. Objet
+
+Définir les exigences minimales et les **preuves attendues** pour qu’un membre “Opérateur” soit considéré conforme à la **Pile opérateur de référence** (ADR-OPS-STACK-001).
+
+Cette politique est conçue pour produire une conformité **mécanique** :
+
+- des preuves standardisées,
+- indexées,
+- et vérifiables.
+
+---
+
+## 2. Exigences transversales (obligatoires)
+
+### 2.1 Traçabilité (PR + ΔLog)
+
+- Toute modification doit être : 
+  - versionnée (Forgejo),
+  - validée (PR),
+  - expliquée (ΔLog),
+  - reliée à une exécution (CI, OpenTofu, Ansible) si applicable.
+
+**Preuves :**
+
+- Liens PR + ΔLog
+- Logs d’exécution (CI / runner C5)
+- Tag/release si changement livré
+
+---
+
+### 2.2 Membrane & non-bypass
+
+- C5 (NGINX+ModSecurity) est **le** point d’entrée unique.
+- Aucun accès tenant direct vers C2/C3/C4.
+
+**Preuves :**
+
+- Export OPNsense + matrice de flux autorisés
+- Tests “saut de couche” (résultats + horodatage)
+- Logs NGINX/OPNsense démontrant la médiation
+
+---
+
+### 2.3 SSO & RBAC
+
+- Les portails exposés (Grafana, Icinga Web) sont accessibles via C5 et protégés par SSO (Keycloak).
+- Rôles séparés (ops, audit) documentés.
+
+**Preuves :**
+
+- Export Keycloak (realm/clients/roles)
+- Matrice rôles → permissions
+- Logs d’authentification (exemples)
+
+---
+
+### 2.4 Indexation des preuves
+
+- Les preuves doivent être déposées et indexées dans le dépôt `operator-stack/` selon un format stable.
+
+**Preuves :**
+
+- `evidence/00_Evidence_Index.md` à jour
+- Convention de nommage appliquée
+- Preuves datées par période (trimestre ou mois)
+
+---
+
+## 3. Exigences et preuves par couche
+
+### 3.1 C1 — Proxmox VE / Ceph / TrueNAS
+
+**Exigences**
+
+- Proxmox VE : cluster opéré, accès admin restreint, inventaire maintenu.
+- Ceph : santé OK, réplication définie, capacité suivie.
+- TrueNAS : datasets/ACL + snapshots/rétention si utilisé pour landing zone / exports / backup.
+
+**Preuves minimales**
+
+- C1-E1 : inventaire Proxmox (nœuds, versions, ressources)
+- C1-E2 : état de santé Ceph + capacité
+- C1-E3 : test de restauration documenté pour un workload critique
+- C1-E4 : configuration TrueNAS pertinente (datasets/snapshots) si activée
+
+---
+
+### 3.2 C2 — OPNsense / PowerDNS Authoritative / WireGuard
+
+**Exigences**
+
+- OPNsense : segmentation par couche, “default deny”, logs activés.
+- PowerDNS : zones + délégations, ACL, traçabilité des changements.
+- WireGuard : accès ops/admin sécurisé, onboarding/offboarding maîtrisé.
+
+**Preuves minimales**
+
+- C2-E1 : export configuration OPNsense (versionné) + matrice de flux
+- C2-E2 : test “non-bypass / adjacent-only” (résultats + logs)
+- C2-E3 : inventaire DNS (zones/délégations) + ΔLog des changements
+- C2-E4 : preuves WireGuard (pairs autorisés + journal connexions + runbook)
+
+---
+
+### 3.3 C3 — Keycloak / OpenLDAP / Icinga / Prometheus / Grafana / Loki
+
+**Exigences**
+
+- Keycloak : SSO fonctionnel, RBAC, séparation ops/audit.
+- OpenLDAP : seulement si requis ; sauvegarde et contrôle d’accès.
+- Icinga2 + Web 2 + BPM : SLA/états auditables (vues auditeurs).
+- Prometheus + Alertmanager : collecte métriques et alerting.
+- Grafana : console unifiée (Prometheus + Loki).
+- Loki : logs centralisés, conventions de labels, rétention appliquée, séparation prouvable.
+
+**Preuves minimales**
+
+- C3-E1 : export Keycloak + matrice rôles→droits
+- C3-E2 : exports BPM (tableaux “auditeur” couvrant C1–C5)
+- C3-E3 : couverture checks Icinga + historique alertes/incidents
+- C3-E4 : targets Prometheus + règles Alertmanager + exemple d’alerte
+- C3-E5 : exports dashboards Grafana + sources de données
+- C3-E6 : conformité Loki (labels/rétention + requêtes d’exemple reproductibles)
+
+---
+
+### 3.4 C4 — Forgejo / Forgejo Actions (CI) / Harbor / Vault / Référentiels IaC
+
+**Exigences**
+
+- Forgejo : PR obligatoires, branches protégées, ADR/POL versionnés, ΔLog actif.
+- Forgejo Actions : CI de validation (build/test/scan/validation IaC), logs conservés.
+- Harbor : registry OCI avec RBAC, rétention, provenance (liens CI).
+- Vault : secrets centralisés, policies, audit log, rotation minimale.
+- Référentiels IaC : modules OpenTofu + playbooks/inventaires Ansible versionnés et revus.
+
+**Preuves minimales**
+
+- C4-E1 : règles repos (branch protection, PR rules) + exemples PR + ΔLog
+- C4-E2 : logs Forgejo Actions (CI) + politique pass/fail
+- C4-E3 : configuration Harbor (RBAC/rétention) + preuve d’artefacts publiés
+- C4-E4 : policies Vault + audit log + preuve “no secrets in repos”
+- C4-E5 : preuves IaC côté C4 : 
+  - format/lint (OpenTofu/Ansible),
+  - `tofu plan` (ou équivalent) attaché aux PR,
+  - artefacts de validation si utilisés
+
+---
+
+### 3.5 C5 — NGINX+ModSecurity / FastAPI / Unbound / Runner d’exécution IaC
+
+**Exigences**
+
+- NGINX + ModSecurity : point d’entrée unique, TLS, protections WAF, logs d’accès.
+- FastAPI : admission/quotas/politiques (au minimum), journalisation.
+- Unbound : DNS récursif tenants, ACL, forwarding contrôlé.
+- Runner d’exécution IaC (C5) : exécute les actions à privilèges (OpenTofu apply, Ansible) avec : 
+  - secrets fournis via Vault,
+  - accès réseau minimal nécessaire,
+  - traçabilité PR → exécution,
+  - contrôle d’accès strict.
+
+**Preuves minimales**
+
+- C5-E1 : configurations versionnées NGINX + ModSecurity + preuve TLS (certs)
+- C5-E2 : logs NGINX démontrant la médiation (absence de bypass)
+- C5-E3 : FastAPI (OpenAPI, version, logs, contrôles admission/quotas)
+- C5-E4 : Unbound (ACL/forwarding) + logs + preuve “tenants ne parlent pas à C2”
+- C5-E5 : preuves exécution IaC côté C5 : 
+  - logs `plan/apply` OpenTofu,
+  - logs Ansible,
+  - identité d’exécution (qui/quoi/quand),
+  - liens PR → job → exécution,
+  - preuve de rollback/restore si applicable
+
+---
+
+## 4. Déclaration de non-conformité
+
+Une non-conformité est déclarée si :
+
+- un composant de la pile est absent,
+- les preuves minimales manquent ou ne sont pas indexées,
+- un bypass du pivot est possible,
+- les portails ne sont pas protégés par SSO via C5,
+- la traçabilité (PR/ΔLog) est absente,
+- l’exécution IaC n’est pas contrôlée via C5.
+
+Remédiation attendue :
+
+- incident/ticket (si votre ITSM existe),
+- ΔLog,
+- PR corrective,
+- preuves mises à jour et indexées.
+
+---
+
+## 5. ΔLog (à compléter au commit)
+
+- Politique : Conformité pile opérateur (C1–C5) + preuves attendues
+- Auteur(s) : \_________________\_
+- Référence PR : \_________________\_
+- Date d’entrée : \_________________\_
\ No newline at end of file
diff --git a/docs/pile opérateur/runbooks/00_index.md b/docs/pile opérateur/runbooks/00_index.md
new file mode 100644
index 0000000..e6c4806
--- /dev/null
+++ b/docs/pile opérateur/runbooks/00_index.md	
@@ -0,0 +1,11 @@
+## Index des runbooks (pile opérateur)
+
+- [RBK-C1-Backup-Restore.md](http://RBK-C1-Backup-Restore.md) — Sauvegarde & restauration (preuves)
+- [RBK-C2-Firewall-Change.md](http://RBK-C2-Firewall-Change.md) — Changement OPNsense (process + preuves)
+- [RBK-C2-DNS-Change.md](http://RBK-C2-DNS-Change.md) — Changements PowerDNS (zones/délégations)
+- [RBK-C3-SSO-RBAC.md](http://RBK-C3-SSO-RBAC.md) — Keycloak (RBAC, MFA, séparation)
+- [RBK-C3-Observability.md](http://RBK-C3-Observability.md) — Icinga/Prometheus/Grafana/Loki (opérations)
+- [RBK-C4-Release-Process.md](http://RBK-C4-Release-Process.md) — Releases (Forgejo + Actions + Harbor + Vault)
+- [RBK-C4-Secrets-Handling.md](http://RBK-C4-Secrets-Handling.md) — Secrets (Vault, redaction, interdits)
+- [RBK-C5-Pivot-Admission.md](http://RBK-C5-Pivot-Admission.md) — Admission/quotas FastAPI (contrôles)
+- [RBK-C5-IaC-Execution.md](http://RBK-C5-IaC-Execution.md) — Exécution IaC en C5 (runner, droits, logs)
\ No newline at end of file
diff --git a/docs/presentation_rencontres_linux_alliance_boreale v2.pptx b/docs/presentation_rencontres_linux_alliance_boreale v2.pptx
new file mode 100644
index 0000000..c595813
Binary files /dev/null and b/docs/presentation_rencontres_linux_alliance_boreale v2.pptx differ