mini-refonte

2026-01-29 09:46:17 -05:00 · 2026-01-29 09:46:17 -05:00 · 22e5954295
commit 22e5954295
parent 7e1288e942
67 changed files with 8096 additions and 1056 deletions
--- a/docs/00-fondements/00
+++ b/docs/00-fondements/00
@ -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.
--- a/docs/00-fondements/00
+++ b/docs/00-fondements/00
@ -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.*
--- a/docs/00-fondements/00
+++ b/docs/00-fondements/00
@ -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.
--- 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.
--- a/docs/00-fondements/01-charte-des-valeurs.md
+++ b/docs/00-fondements/01-charte-des-valeurs.md
@ -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)
--- a/docs/00-fondements/02-principes-autopoietiques.md
+++ b/docs/00-fondements/02-principes-autopoietiques.md
@ -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)
--- a/docs/00-fondements/03-lexique-et-glossaire.md
+++ b/docs/00-fondements/03-lexique-et-glossaire.md
@ -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)
--- a/docs/00-fondements/04-symboles-et-identite-visuelle.md
+++ b/docs/00-fondements/04-symboles-et-identite-visuelle.md
@ -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)
--- a/Controles_Conformite_Label_Prestige_par_Couche_v1.0.md
+++ b/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
--- a/docs/10-architecture/10
+++ b/docs/10-architecture/10
@ -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`
--- a/docs/10-architecture/10
+++ b/docs/10-architecture/10
@ -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.
--- a/docs/10-architecture/10
+++ b/docs/10-architecture/10
@ -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é.
--- a/docs/10-architecture/10
+++ b/docs/10-architecture/10
@ -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.
--- a/docs/10-architecture/10
+++ b/docs/10-architecture/10
@ -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 : __________________
+
--- a/docs/architecture/14_Structure_YAML_Registraire.md
+++ b/docs/architecture/14_Structure_YAML_Registraire.md
--- a/docs/10-architecture/2026-01-29
+++ b/docs/10-architecture/2026-01-29
@ -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.
--- a/docs/10-architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md
+++ b/docs/10-architecture/Architecture_Deterministe_Alliance_Boreale_Whitepaper.md
--- a/docs/10-architecture/Architecture_Deterministe_Diagrammes_Visuels.md
+++ b/docs/10-architecture/Architecture_Deterministe_Diagrammes_Visuels.md
--- a/docs/10-architecture/Forgejo_dans_le_cycle_vivant.md
+++ b/docs/10-architecture/Forgejo_dans_le_cycle_vivant.md
--- a/docs/10-architecture/checklist_reunion.md
+++ b/docs/10-architecture/checklist_reunion.md
--- a/docs/10-architecture/guide_formation.md
+++ b/docs/10-architecture/guide_formation.md
--- a/docs/10-architecture/readme_package.md
+++ b/docs/10-architecture/readme_package.md
--- a/docs/10-architecture/resolution_adoption.md
+++ b/docs/10-architecture/resolution_adoption.md
--- a/docs/10-architecture/scripts_migration.sh
+++ b/docs/10-architecture/scripts_migration.sh
--- a/docs/10-architecture/templates_automation.md
+++ b/docs/10-architecture/templates_automation.md
--- a/docs/10-instanciation/00-prerequis.md
+++ b/docs/10-instanciation/00-prerequis.md
@ -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)
--- a/docs/10-instanciation/01-architecture-generale.md
+++ b/docs/10-instanciation/01-architecture-generale.md
@ -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)
--- a/docs/10-instanciation/02-guide-de-demarrage.md
+++ b/docs/10-instanciation/02-guide-de-demarrage.md
@ -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)
--- a/docs/10-instanciation/03-registre-yaml-exemple.md
+++ b/docs/10-instanciation/03-registre-yaml-exemple.md
@ -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)
--- a/docs/10-instanciation/04-deploiement-automatique.md
+++ b/docs/10-instanciation/04-deploiement-automatique.md
@ -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)
--- a/docs/10-instanciation/05-tests-et-validation.md
+++ b/docs/10-instanciation/05-tests-et-validation.md
@ -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)
--- a/docs/10-instanciation/06-maintenance-et-mise-a-jour.md
+++ b/docs/10-instanciation/06-maintenance-et-mise-a-jour.md
@ -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)
--- a/docs/20-gouvernance/00-roles-et-responsabilites.md
+++ b/docs/20-gouvernance/00-roles-et-responsabilites.md
@ -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)
--- a/docs/20-gouvernance/01-processus-decisionnel.md
+++ b/docs/20-gouvernance/01-processus-decisionnel.md
@ -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)
--- a/docs/20-gouvernance/02-documents-de-reference.md
+++ b/docs/20-gouvernance/02-documents-de-reference.md
@ -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)
--- a/docs/20-gouvernance/03-modele-juridique-et-structure-sep-obnl.md
+++ b/docs/20-gouvernance/03-modele-juridique-et-structure-sep-obnl.md
@ -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)
--- a/docs/20-gouvernance/04-adhesion-et-contribution.md
+++ b/docs/20-gouvernance/04-adhesion-et-contribution.md
@ -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)
--- a/docs/20-gouvernance/05-ethique-et-confidentialite.md
+++ b/docs/20-gouvernance/05-ethique-et-confidentialite.md
@ -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)
--- a/docs/20-rag/01
+++ b/docs/20-rag/01
@ -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
--- a/docs/20-rag/02
+++ b/docs/20-rag/02
@ -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`
--- a/docs/20-rag/03_Cadre_Conformite_Label_Prestige(1).md
+++ b/docs/20-rag/03_Cadre_Conformite_Label_Prestige(1).md
--- a/docs/20-rag/devis(2).md
+++ b/docs/20-rag/devis(2).md
--- a/docs/30-federation/00-protocole-federatif.md
+++ b/docs/30-federation/00-protocole-federatif.md
@ -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)
--- a/docs/30-federation/01-registre-central-yaml.md
+++ b/docs/30-federation/01-registre-central-yaml.md
@ -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)
--- a/docs/30-federation/02-communication-entre-noeuds.md
+++ b/docs/30-federation/02-communication-entre-noeuds.md
@ -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)
--- a/docs/30-federation/03-synchronisation-et-replication.md
+++ b/docs/30-federation/03-synchronisation-et-replication.md
@ -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)
--- a/docs/30-federation/04-identites-et-authentification.md
+++ b/docs/30-federation/04-identites-et-authentification.md
@ -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)
--- a/docs/30-federation/05-procedure-de-reprise-et-resilience.md
+++ b/docs/30-federation/05-procedure-de-reprise-et-resilience.md
@ -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)
--- a/docs/50-annexes/00-schema-global.md
+++ b/docs/50-annexes/00-schema-global.md
@ -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)
--- a/docs/50-annexes/01-references-logicielles.md
+++ b/docs/50-annexes/01-references-logicielles.md
@ -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)
--- a/docs/50-annexes/02-normes-nomenclature-ip-et-dns.md
+++ b/docs/50-annexes/02-normes-nomenclature-ip-et-dns.md
@ -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)
--- a/docs/50-annexes/03-outils-et-scripts.md
+++ b/docs/50-annexes/03-outils-et-scripts.md
@ -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)
--- a/docs/50-annexes/04-bibliographie-et-liens-externes.md
+++ b/docs/50-annexes/04-bibliographie-et-liens-externes.md
@ -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)
--- 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
--- a/docs/constitution/03_Cadre_Conformite_Label_Prestige.md
+++ b/docs/constitution/03_Cadre_Conformite_Label_Prestige.md
--- a/docs/constitution/03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md
+++ b/docs/constitution/03_Cadre_Conformite_Label_Prestige_biomimetique_autopoietique_v3.md
@ -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.*
--- a/opérateur/README.md
+++ b/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.
--- a/opérateur/adr/ADR-OBS-001
+++ b/opérateur/adr/ADR-OBS-001
@ -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.
+
+---
--- a/opérateur/adr/ADR-OPS-STACK-001
+++ b/opérateur/adr/ADR-OPS-STACK-001
@ -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 : __________________
+
--- a/opérateur/evidence/00_Evidence_Index.md
+++ b/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 |
--- a/opérateur/evidence/templates/Evidence-Checklist.md
+++ b/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)
--- a/opérateur/evidence/templates/Evidence-Naming-Convention.md
+++ b/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`
--- a/opérateur/evidence/templates/docs/ΔLog-Template.md
+++ b/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) :
--- a/opérateur/pol/POL-OBS-LOG-001
+++ b/opérateur/pol/POL-OBS-LOG-001
@ -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.
--- a/opérateur/pol/POL-OPS-STACK-001
+++ b/opérateur/pol/POL-OPS-STACK-001
@ -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 : \_________________\_
--- a/opérateur/runbooks/00_index.md
+++ b/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)
--- a/docs/presentation_rencontres_linux_alliance_boreale
+++ b/docs/presentation_rencontres_linux_alliance_boreale