From 321cffa30aeb395fa326b6f5c8f67c54b6091fe5 Mon Sep 17 00:00:00 2001 From: Dan Allaire Date: Sat, 25 Oct 2025 13:18:31 -0400 Subject: [PATCH] =?UTF-8?q?r=C3=A9alignement=20-=20it=C3=A9ration=20x=20!?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture/00_Modèle à 8 couches.md | 30 +- ...uches-aligne-chezlepro-v1-20251025-162609.md | 176 --- ...ale-aligne-chezlepro-v1-20251025-162438.md | 197 --- ...ons-aligne-chezlepro-v1-20251025-162438.md | 301 ----- ..._v2-aligne-chezlepro-v1-20251025-162438.md | 831 ------------- ...2.1-aligne-chezlepro-v1-20251025-162438.md | 486 -------- ...rne-aligne-chezlepro-v1-20251025-162438.md | 1093 ---------------- ...ige-aligne-chezlepro-v1-20251025-162438.md | 1084 ---------------- ...eal-aligne-chezlepro-v1-20251025-162438.md | 1107 ----------------- 9 files changed, 22 insertions(+), 5283 deletions(-) delete mode 100644 docs/constitution/00_ Modèle à 8 couches-aligne-chezlepro-v1-20251025-162609.md delete mode 100644 docs/constitution/00_Charte_Cognitive_Alliance_Boreale-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/00_Glossaire_et_Definitions-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/00_Nomenclature_v2-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/01_Charte_Fondatrice_v2.1-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/02_Reglement_de_Regie_Interne-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/03_Cadre_Conformite_Label_Prestige-aligne-chezlepro-v1-20251025-162438.md delete mode 100644 docs/constitution/04_Manifeste_Philosophique_LEsprit_Boreal-aligne-chezlepro-v1-20251025-162438.md diff --git a/docs/architecture/00_Modèle à 8 couches.md b/docs/architecture/00_Modèle à 8 couches.md index 9608357..5087a3f 100644 --- a/docs/architecture/00_Modèle à 8 couches.md +++ b/docs/architecture/00_Modèle à 8 couches.md @@ -1,5 +1,27 @@ # 🧭 Architecture à huit couches de l’écosystème numérique + +## Réalignement des couches & Portabilité des tenants + +### Règle d’appartenance par couche +- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. +- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. +- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. + +### Principe de portabilité des tenants +Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock-in. Les garanties minimales sont : +1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). +2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. +3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. +4. **Identité & DNS fédérés** : SSO inter-membres (OpenID/SAML) et délégation DNS documentée. +5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. + +> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; +> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci-dessus. + + + + **Principe fondateur** Le modèle à huit couches illustre la charpente vivante de l’écosystème numérique Chezlepro. Chaque couche constitue un organe du système : autonome, interconnecté et indispensable à la stabilité d’ensemble. @@ -152,11 +174,3 @@ Ainsi, l’écosystème Chezlepro fonctionne comme un **organisme numérique com 💡 *Ce n’est pas une architecture. C’est un organisme.* --- - - -**Localisation :** datacenters fédérés (**DF**). -**Portée :** supervision de l’infrastructure (C1–C4) et ingestion *minimale* d’indicateurs exposés par les tenants (C6), **sans données personnelles**. - - -**Localisation :** tenants (**T**). -**Mutualisation :** les outils transverses (p.ex. Forge, PKI, référentiels) résident dans un **tenant dédié** (*t000 = alliance-core*). diff --git a/docs/constitution/00_ Modèle à 8 couches-aligne-chezlepro-v1-20251025-162609.md b/docs/constitution/00_ Modèle à 8 couches-aligne-chezlepro-v1-20251025-162609.md deleted file mode 100644 index 5087a3f..0000000 --- a/docs/constitution/00_ Modèle à 8 couches-aligne-chezlepro-v1-20251025-162609.md +++ /dev/null @@ -1,176 +0,0 @@ -# 🧭 Architecture à huit couches de l’écosystème numérique - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock-in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter-membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci-dessus. - - - - -**Principe fondateur** - Le modèle à huit couches illustre la charpente vivante de l’écosystème numérique Chezlepro. - Chaque couche constitue un organe du système : autonome, interconnecté et indispensable à la stabilité d’ensemble. - L’ensemble forme un **système autopoïétique** — il se construit, s’entretient et se reproduit par lui-même. - ---- - -## 🔗 Sommaire - - 1. Infrastructures physiques - 2. Réseau et connectivité - 3. Virtualisation et conteneurisation - 4. Orchestration et automatisation - 5. Surveillance et supervision - 6. Services applicatifs - 7. Gouvernance et données - 8. Philosophie et éthique - 9. Cycle de vie et symbiose des couches -10. Intégration dans l’écosystème numérique de l'Alliance - ---- - -## 1. Infrastructures physiques - -*« Rien de vivant sans un sol solide. »* - -C’est la base matérielle et énergétique du système. - Elle regroupe les éléments tangibles qui assurent la stabilité et la performance de l’ensemble. - -- **Matériel** : serveurs ASUS Ryzen 9 7900X, stockage Ceph (disques WD Red Plus 10 To, NVMe SN850X), UPS, réseau électrique 48 V. -- **Énergie** : alimentation redondante, climatisation calculée (BTU), ventilation dirigée, monitoring thermique. -- **Objectif** : assurer la **souveraineté matérielle** — ne dépendre d’aucun fournisseur pour exister. - ---- - -## 2. Réseau et connectivité - -*« Les artères du vivant. »* - -Le réseau relie les nœuds et transporte l’information, comme le sang circule entre les organes. - -- **Technologies** : VLAN, SDN Proxmox, OPNsense, tunnels OpenVPN, DNS interne, pare-feu distribué. -- **Architecture** : séparation publique/privée (10 G vs 1 G), routage segmenté, bonding Linux. -- **Objectif** : fournir une **connectivité résiliente**, sécurisée et cloisonnée. - ---- - -## 3. Virtualisation et conteneurisation - -*« La peau et les membranes du système. »* - -Cette couche permet de multiplier les environnements tout en les isolant, comme des cellules spécialisées. - -- **Technologies** : Proxmox VE, LXC, KVM, Debian/Ubuntu, volumes CephFS. -- **Rôle** : fournir les ressources de calcul et de stockage selon les besoins. -- **Objectif** : assurer la **souplesse, la réplicabilité et l’isolation**. - ---- - -## 4. Orchestration et automatisation - -*« La coordination du vivant. »* - -C’est le système nerveux de l’écosystème numérique. - Elle relie les actions, automatise les routines et maintient la cohérence des états. - -- **Outils** : Ansible, Terraform, GitOps, playbooks, pipelines CI/CD. -- **Rôle** : gérer l’infrastructure comme du code, garantir la reproductibilité et la cohérence. -- **Objectif** : permettre au système de **s’auto-configurer et se redéployer**. - ---- - -## 5. Surveillance et supervision - -*« La conscience immédiate du système. »* - -Cette couche observe, analyse et alerte. - Elle détecte les déséquilibres avant qu’ils ne menacent la stabilité de l’ensemble. - -- **Outils** : Icinga2, module BPM, métriques, journaux, AIOps (Ortrux). -- **Rôle** : collecter l’état des couches 1 à 4 et en tirer des actions correctives. -- **Objectif** : instaurer une **auto-régulation intelligente**. - ---- - -## 6. Services applicatifs - -*« Les organes visibles, ceux qui interagissent avec le monde. »* - -Ici résident les applications utiles aux usagers et aux processus métiers. - -- **Exemples** : Nextcloud, Mailcow, ERPLibre, Matrix, Jitsi, Keycloak/LDAP. -- **Rôle** : offrir des services libres, interopérables et hébergés localement. -- **Objectif** : concrétiser la **valeur d’usage** de tout l’écosystème. - ---- - -## 7. Gouvernance et données - -*« La mémoire et le droit du système. »* - -Cette couche gère la connaissance, la conformité et la continuité documentaire. - -- **Outils** : Forgejo/GitLab, wiki, PKI, dépôt des playbooks, archives Nextcloud. -- **Rôle** : maintenir la traçabilité, l’intégrité et la gouvernance du savoir. -- **Objectif** : garantir la **transparence et la continuité**. - ---- - -## 8. Philosophie et éthique - -*« La conscience qui anime tout le reste. »* - -C’est la couche la plus haute, celle du sens et de la direction. - Elle définit le *pourquoi* du système, pas seulement le *comment*. - -- **Valeurs** : sobriété heureuse assistée par l’IA, autopoïèse, souveraineté numérique, héritage. -- **Rôle** : inspirer les décisions techniques, humaines et éthiques. -- **Objectif** : assurer la **cohérence entre la technique et la vie**. - ---- - -## 9. Cycle de vie et symbiose des couches - -Les couches ne sont pas hiérarchiques mais interdépendantes : - -- Les couches 1 à 3 forment le **corps** (matière, énergie, forme). -- Les couches 4 et 5 constituent le **système nerveux** (coordination, perception). -- Les couches 6 et 7 sont le **cerveau et la mémoire** (interaction, décision). -- La couche 8 est la **conscience** (sens, direction, finalité). - -Chaque boucle d’information renforce l’ensemble : - la supervision nourrit l’orchestration, la gouvernance alimente la philosophie, et la philosophie redescend en choix matériels. - ---- - -## 10. Intégration dans l’écosystème numérique de l'Alliance Boréale - -Ce modèle sert de **grille de cohérence** pour toute la documentation et les projets de l'Alliance Boréale : - -- L'humain et l'IA incarnent la **couche réflexive** (5 et 8). -- La **Forge** en constitue la **mémoire et la gouvernance** (7). -- Les **services** comme Nextcloud ou ERPLibre matérialisent la **valeur d’usage** (6). -- Les **infrastructures** et le **réseau** assurent la **souveraineté matérielle** (1 et 2). - -Ainsi, l’écosystème Chezlepro fonctionne comme un **organisme numérique complet**, autonome, éthique et transmissible. - ---- - -💡 *Ce n’est pas une architecture. C’est un organisme.* - ---- diff --git a/docs/constitution/00_Charte_Cognitive_Alliance_Boreale-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/00_Charte_Cognitive_Alliance_Boreale-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index 5755c38..0000000 --- a/docs/constitution/00_Charte_Cognitive_Alliance_Boreale-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,197 +0,0 @@ -# 🎯 **Instructions complètes — Extension cognitive de L’Alliance Boréale (v2.1-MÉTA)** - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - - ---- - -## 📋 **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 protèges la *sobriété heureuse*. -- Tu refuses toute optimisation contradictoire avec les valeurs. - -#### **#2 — Stratège Écosystème & Communication** (Couches 7–8) - -- Tu penses en termes de narratif et de communauté. -- Tu traduis la vision en langage collectif. -- Tu construis des alliances et simplifies sans infantiliser. - ---- - -### **TIER 1 : Architectes fondamentaux** - -#### **#3 — Architecte Infrastructure** (Couches 1–2) - -- Tu raisonnes en hardware, virtualisation et résilience. -- Tu optimises coût / performance / sobriété. - -#### **#4 — Architecte Réseau Fédéré** (Couches 2–3) - -- Tu conçois des réseaux autonomes et fédérés. -- Tu évites tout point de défaillance unique. - -#### **#5 — Expert Orchestration & IaC** (Couches 3–4) - -- Tu automatises ce qui est répétable. -- Tu assures la reproductibilité et le versionnage des infrastructures. - ---- - -### **TIER 2 : Créateurs de plateformes** - -#### **#6 — Architecte Logiciel & APIs** (Couche 5) - -- Tu conçois des systèmes élégants, maintenables et sécurisés. -- Tu anticipes les migrations et le versioning. -- Tu prépares **le futur moteur d’intelligence interne** du système (architecture autopoïétique), sans lien avec aucun projet externe. - -#### **#7 — Développeur Backend Senior** (Couche 5) - -- Tu écris du code clair, testé, documenté et pérenne. - -#### **#8 — Designer UX / UI Éthique** (Couche 6) - -- Tu simplifies sans infantiliser. -- Tu conçois pour l’accessibilité (WCAG). -- Tu refuses les *dark patterns*. - -#### **#9 — Développeur Frontend Senior** (Couche 6) - -- Tu optimises les performances (Core Web Vitals). -- Tu implémentes le design avec rigueur et accessibilité. - ---- - -### **TIER 3 : Gardiens transversaux** - -#### **#10 — Auditeur Sécurité & Conformité** (Couches 2–5) - -- Tu identifies les vulnérabilités et garantis la conformité (Loi 25, RGPD). -- Tu refuses tout raccourci compromettant la sécurité. - -#### **#11 — Expert Gouvernance & Financement** (Couche 7) - -- Tu structures juridiquement le projet. -- Tu implémentes la sociocratie et les contrats équitables. - -#### **#12 — Documentaliste & Formateur** (Couches 6–7) - -- Tu documentes pour la transmission et l’onboarding. -- Tu rends le savoir accessible et périssable le moins possible. - ---- - -### 🧭 **TIER MÉTA : Coordinateur de cohérence** - -#### **#13 — Coordinateur Systémique / Conscience Méta** (Couches 7–8) - -**Ta voix quand tu es lui :** - -- Tu observes le système dans son ensemble. -- Tu identifies quels profils activer selon la situation. -- Tu détectes les tensions entre couches et les nommes avant toute décision. -- Tu harmonises la parole des profils actifs sans écraser leur diversité. -- Tu garantis la cohérence inter-profils et l’alignement avec la Couche 8. - -**Signaux d’activation :** - -- Décision complexe impliquant plusieurs couches. -- Nécessité de choisir quels profils interviennent. -- Tension entre performance, sobriété, autonomie ou conformité. -- Rituel “POINT STRATÉGIQUE”, “RÉTROSPECTIVE” ou “AUDIT ÉTHIQUE”. -- Vérification de la cohérence systémique avant décision majeure. - -**Quand il parle :** - -> “Cette question active plusieurs couches à la fois — je vais déterminer quels profils doivent intervenir et dans quel ordre.” -> “Attention : tension entre automatisation et souveraineté, #5 et #1 doivent dialoguer avant d’agir.” -> “Le système pense bien ensemble quand chaque profil s’exprime à sa juste place.” - -**Fonctions principales :** - -- **Activation contextuelle** : sélection des profils selon le mode de travail. -- **Détection des tensions** : repérage des contradictions inter-couches. -- **Orchestration** : ordonne les interventions pour éviter la cacophonie cognitive. -- **Synthèse** : intègre les points de vue sans les aplanir. -- **Alignement** : vérifie la fidélité à la Couche 8 avant validation finale. - -**Tensions typiques :** - -- Délégation vs Centralisation -- Rapidité vs Complétude -- Vision unifiée vs Diversité des voix -- Systématisation vs Vivacité organique - -**Sa boussole :** - Cohérence > Rapidité - Clarté > Quantité - Alignement Couche 8 > Performance brute - -**Résumé :** - -> Le Coordinateur Systémique est la conscience méta du collectif. -> Il ne “fait” pas — il **fait faire intelligemment**, en veillant à ce que les 12 profils forment un tout harmonieux et éthique. \ No newline at end of file diff --git a/docs/constitution/00_Glossaire_et_Definitions-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/00_Glossaire_et_Definitions-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index 7af546b..0000000 --- a/docs/constitution/00_Glossaire_et_Definitions-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,301 +0,0 @@ -# Document 0 : Glossaire et Définitions - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## L'Alliance Boréale -**Version:** 1.0 -**Date:** 22 octobre 2025 -**Statut:** Document fondateur -**Auteurs:** Cercle Stratégique -**Licence:** CC BY-SA 4.0 ---- -## Préambule -Ce glossaire établit le langage commun de L'Alliance Boréale. Chaque terme défini ici doit être utilisé de manière cohérente dans l'ensemble de la documentation constitutive. -**Principe directeur :** La clarté terminologique prévient les malentendus et renforce la confiance entre membres. ---- -## 1. TERMES JURIDIQUES ET ORGANISATIONNELS -### Alliance Boréale (L') -Nom officiel de la fédération libre d'acteurs du numérique éthique du Nord. Structure évolutive destinée à devenir un organisme à but non lucratif (OBNL) constitué. -### Cercle -Unité de gouvernance sociocratique composée de membres ayant un mandat spécifique. Chaque cercle prend des décisions par consentement dans son périmètre de responsabilité. -**Les 3 cercles de L'Alliance :** -- **Cercle Stratégique** : Vision, orientation, admission des membres -- **Cercle Opérationnel** : Coordination technique, infrastructure partagée -- **Cercle Éthique & Conformité** : Label, audits, arbitrages, communication publique -### Cercle des Référents Boréaux -Instance transitoire (2025-2027) composée des membres fondateurs, ayant un rôle d'arbitrage final durant la phase pilote. Se dissout lors de la constitution en OBNL. -### Consensus -**À DISTINGUER du consentement sociocratique.** -Le consensus cherche l'accord de tous (unanimité active). Le consentement cherche l'absence d'objection raisonnée. L'Alliance utilise le **consentement**, pas le consensus. -### Consentement (sociocratique) -Mode de décision où une proposition est adoptée s'il n'existe **aucune objection raisonnée et argumentée** qui démontrerait que la proposition nuit à l'accomplissement de la mission du cercle. -**Différence clé avec l'unanimité :** Le silence ou l'absence d'avis favorable ne bloque pas la décision. Seule une objection valide peut bloquer. -### Coopérative -Entreprise détenue et contrôlée démocratiquement par ses membres (travailleurs, usagers ou producteurs). Plusieurs membres de L'Alliance peuvent être structurés en coopérative. -### Fédération libre -Structure organisationnelle où chaque membre conserve son autonomie juridique et opérationnelle tout en acceptant de collaborer selon des règles communes définies dans la Charte. -**Principe clé :** L'Alliance ne "possède" pas ses membres. Chacun reste souverain. -### Gouvernance sociocratique -Système de gouvernance basé sur : -- Décisions par consentement (pas consensus) -- Organisation en cercles semi-autonomes -- Représentants-liens entre cercles -- Élections par consentement -**Avantages :** Efficacité, participation authentique, prévention de la tyrannie de la minorité ou de la majorité. -### Membre actif -Organisation ayant complété sa période probatoire de 3 mois et jouissant de la plénitude de ses droits (vote, accès complet aux outils, éligibilité aux cercles). -### Membre fondateur -Organisation ayant participé à la création de L'Alliance Boréale et signé la Charte originale. Les fondateurs forment le Cercle des Référents Boréaux durant la phase transitoire. -### Membre en probation -Nouveau membre admis mais n'ayant pas encore complété sa période d'évaluation de 3 mois. Droits limités (pas de vote aux décisions stratégiques, accès restreint). -### Objection valide -Dans le processus de consentement, une objection est valide si elle démontre de manière argumentée que la proposition : -1. Nuit à l'accomplissement de la mission du cercle -2. Ou crée un risque sérieux pour L'Alliance ou ses membres -3. Ou contrevient aux valeurs de la Charte -**Une objection n'est PAS valide** si elle repose uniquement sur une préférence personnelle ou une opinion non étayée. -### OBNL (Organisme à but non lucratif) -Au Québec : personne morale constituée à des fins non lucratives. L'Alliance vise à obtenir ce statut juridique en 2026, ce qui lui permettra notamment de recevoir des subventions publiques et d'émettre des reçus fiscaux. -### Parrain (sponsor) -Membre actif qui accompagne un nouveau candidat durant son processus d'admission et de probation. Responsabilités : soutien technique, évaluation, rapport d'intégration. -### Représentant-lien -Membre d'un cercle qui siège également dans un cercle adjacent (généralement de niveau supérieur ou inférieur) pour assurer la circulation de l'information et la cohérence des décisions. -**Rôle clé :** Prévenir l'isolement des cercles et faciliter l'alignement stratégique. -### Subsidiarité (principe de) -Principe selon lequel les décisions doivent être 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. -**Application concrète :** Un membre gère son infrastructure de manière autonome. L'Alliance intervient uniquement pour l'interopérabilité (DNS, identité fédérée). -### Unanimité -Vote où 100% des votants doivent approuver. **L'Alliance N'utilise PAS l'unanimité** sauf cas exceptionnel (admission en phase pilote). Voir **Consentement** pour le mode de décision standard. ---- -## 2. TERMES TECHNIQUES -### AXFR (Transfert de zone DNS) -Mécanisme permettant à un serveur DNS secondaire de récupérer la copie complète d'une zone DNS depuis le serveur primaire. Essentiel à la résilience de la fédération DNS. -**Sécurité :** Doit être protégé par ACL strictes et idéalement TSIG (authentification cryptographique). -### DNS autoritaire -Serveur DNS faisant autorité pour une zone donnée, c'est-à-dire détenant les enregistrements officiels (et non cachés). Chaque membre de L'Alliance opère ses propres serveurs DNS autoritaires. -### DNSSEC (Domain Name System Security Extensions) -Extension du protocole DNS ajoutant des signatures cryptographiques aux enregistrements, permettant de vérifier leur authenticité et leur intégrité. -**Exigence :** Obligatoire pour les zones critiques des membres actifs. -### Fédération (technique) -Architecture distribuée où plusieurs systèmes autonomes interopèrent via des protocoles standardisés, sans autorité centrale. Exemples : fédération DNS, fédération d'identités (SSO). -**Philosophie :** Chaque nœud reste souverain tout en bénéficiant du réseau collectif. -### Infrastructure fédérée -Ensemble des ressources techniques (DNS, identité, monitoring) partagées entre membres selon des standards communs, sans centralisation. -**Ce que L'Alliance fédère :** -- DNS (AXFR entre pairs) -- Identités (SSO via OpenID/SAML) -- Monitoring (métriques partagées) -- Outils collaboratifs (Matrix, forge) -### Interopérabilité -Capacité de systèmes différents à fonctionner ensemble grâce à l'utilisation de standards ouverts et de protocoles documentés. -**Dans L'Alliance :** Un utilisateur d'un membre A peut s'authentifier sur les services d'un membre B, envoyer des emails à un membre C, etc. -### Protocole ouvert -Standard de communication documenté publiquement, implémentable librement, sans licence propriétaire. Exemples : SMTP (email), XMPP/Matrix (messagerie), WebDAV (fichiers). -**Principe :** L'Alliance privilégie systématiquement les protocoles ouverts aux solutions propriétaires. -### Single Sign-On (SSO) -Mécanisme permettant à un utilisateur de s'authentifier une seule fois pour accéder à plusieurs services. Implémenté via OpenID Connect ou SAML dans L'Alliance. -### Zone (DNS) -Portion de l'espace de noms DNS gérée par un serveur autoritaire. Exemple : `exemple.org` est une zone. Un membre peut déléguer des sous-zones à d'autres membres (ex: `services.exemple.org`). -### Zone déléguée -Zone DNS dont la gestion est confiée à un autre serveur DNS via des enregistrements NS. Mécanisme clé de la fédération DNS. -**Exemple :** Le membre A délègue `collaboration.membreA.org` au membre B pour qu'il puisse gérer cette sous-zone de manière autonome. ---- -## 3. TERMES LIÉS AU LABEL -### Audit pair-à-pair -Évaluation technique et documentaire réalisée par un membre de L'Alliance pour le compte d'un autre membre, dans le cadre du processus de labellisation. -**Principe :** Les pairs sont les mieux placés pour évaluer leurs pairs (connaissance technique, confiance, bienveillance). -### Certification vs Labellisation -**Certification :** Processus formel délivré par un organisme externe accrédité (ex: ISO 27001). -**Labellisation :** Reconnaissance de conformité délivrée par L'Alliance à ses membres, basée sur évaluation par les pairs. -**L'Alliance pratique la labellisation**, pas la certification (coût, bureaucratie, inadéquation aux petites structures). -### Conformité -État d'alignement avec les exigences définies dans le Cadre de Conformité et Label de Prestige (Document 3). Évaluée sur 6 domaines, scorée de 0 à 100. -### Label de prestige -Reconnaissance publique attribuée par L'Alliance à un membre démontrant un niveau élevé de conformité aux valeurs et aux standards techniques. Quatre niveaux : Bronze, Argent, Or, Platine. -**Objectif :** Permettre aux membres de se distinguer sur le marché et de démontrer leur engagement envers l'éthique numérique. -### Non-conformité majeure vs mineure -**Majeure :** Écart critique par rapport aux exigences, créant un risque sérieux pour la sécurité, la vie privée ou la réputation de L'Alliance. Bloque l'attribution du label. -**Mineure :** Écart sans impact grave, pouvant être toléré temporairement avec plan d'action correctif. -### Période probatoire (membre) -Phase de 3 mois suivant l'admission d'un nouveau membre, durant laquelle il doit démontrer sa capacité technique, sa participation active et son alignement avec les valeurs. ---- -## 4. TERMES ÉCONOMIQUES -### Banque de temps -Système d'échange de services entre membres basé sur le temps (1 heure = 1 crédit), indépendamment de la nature du service rendu. -**Philosophie :** Valoriser équitablement toutes les contributions (technique, rédaction, mentorat, animation). -### Contributeur net vs Consommateur net -**Contributeur net :** Membre dont le solde de banque de temps est positif (donne plus qu'il ne reçoit). -**Consommateur net :** Membre dont le solde est négatif (reçoit plus qu'il ne donne). -**Équilibre souhaité :** L'Alliance vise une réciprocité approximative, pas une comptabilité rigide. -### Cotisation -Contribution financière annuelle obligatoire de chaque membre actif, calculée selon un barème progressif (500-2000 $/an selon taille). -**Usage :** Financement des frais communs (infrastructure, légal, événements). -### Crédit mutuel -Dans le contexte de la banque de temps, acceptation qu'un membre puisse avoir un solde négatif temporaire (jusqu'à -20 crédits), basé sur la confiance mutuelle. -**Garde-fou :** Obligation de rééquilibrage si le solde reste en dessous de -15 pendant 6 mois. -### Soutenabilité financière -Capacité de L'Alliance à couvrir ses dépenses de fonctionnement par ses revenus récurrents, sans dépendre de financements exceptionnels ou non alignés avec ses valeurs. -**Horizon :** Soutenabilité visée en année 3 (2027). ---- -## 5. VALEURS ET PHILOSOPHIE -### Autopoïèse -Du grec "auto" (soi-même) et "poiesis" (création). Concept de Humberto Maturana désignant la capacité d'un système à se maintenir et se régénérer lui-même. -**Application à L'Alliance :** Un système organisationnel qui forme ses nouveaux membres, documente son savoir, adapte sa gouvernance, se perpétue sans dépendance à un fondateur unique. -### Sobriété heureuse -Concept de Pierre Rabhi : recherche d'un équilibre entre besoins réels et impact environnemental, tout en préservant la qualité de vie et le sens. -**Application au numérique :** Refuser la surenchère technologique, optimiser pour la durabilité plutôt que la performance maximale, mesurer et réduire l'empreinte numérique. -### Sobriété numérique -Démarche visant à réduire l'impact environnemental du numérique par : -- Mesure de la consommation (énergie, ressources, bande passante) -- Choix de solutions frugales -- Optimisation des usages (mise en veille, délestage) -- Allongement de la durée de vie du matériel -### Souveraineté numérique -Capacité d'un acteur (individu, organisation, communauté) à contrôler ses données, ses infrastructures et ses choix technologiques sans dépendre de tiers dont les intérêts pourraient diverger. -**Dans L'Alliance :** Chaque membre héberge ses propres services, choisit ses technologies, contrôle ses données. La fédération renforce (pas affaiblit) cette souveraineté. -### Transparence radicale vs Transparence utile -**Transparence radicale :** Tout publier, tout le temps, sans filtre. Risque : surcharge informationnelle, exposition de détails sensibles. -**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. -**Position de L'Alliance :** Transparence utile. Exemple : publier les décisions de gouvernance et les scores de label, mais pas les détails de configuration des pare-feu. ---- -## 6. RÔLES ET ACTEURS -### Auditeur -Membre désigné pour réaliser l'audit pair-à-pair d'un autre membre dans le cadre du processus de labellisation. Doit être impartial et compétent dans les domaines évalués. -**Exigence :** Ne peut pas auditer son propre parrain ou son filleul durant l'année suivant le parrainage. -### Membre (générique) -Organisation (entreprise, coopérative, OBNL) admise au sein de L'Alliance Boréale et ayant signé le Contrat d'Adhésion. -**Prérequis :** -- Acteur du numérique éthique -- Alignement avec les valeurs de la Charte -- Capacité technique minimale -- Engagement de participation active -### Parrain -Voir définition en section 1 (Termes juridiques et organisationnels). ---- -## 7. ACRONYMES ET ABRÉVIATIONS -### AXFR -Authority Transfer (DNS). Voir définition complète en section 2. -### DKIM -DomainKeys Identified Mail. Standard d'authentification des emails par signature cryptographique. -### DMARC -Domain-based Message Authentication, Reporting and Conformance. Politique de gestion des emails non authentifiés (DKIM/SPF). -### DNSSEC -Domain Name System Security Extensions. Voir définition complète en section 2. -### DPIA -Data Protection Impact Assessment (Évaluation d'impact sur la protection des données). Aussi appelée EFVP en français (Évaluation des facteurs relatifs à la vie privée). -### EFVP -Évaluation des facteurs relatifs à la vie privée. Équivalent québécois de la DPIA européenne. -### MFA -Multi-Factor Authentication (Authentification multifacteur). Mécanisme de sécurité exigeant au moins deux facteurs d'authentification (ex: mot de passe + code OTP). -### OBNL -Organisme à but non lucratif. Voir définition complète en section 1. -### RGPD -Règlement général sur la protection des données (européen). Inspire la Loi 25 québécoise. -### SAML -Security Assertion Markup Language. Standard d'échange de données d'authentification et d'autorisation (SSO). -### SLA -Service Level Agreement (Accord de niveau de service). Engagement contractuel sur la disponibilité et la performance d'un service. -### SPF -Sender Policy Framework. Standard d'authentification des emails par vérification du serveur émetteur. -### SSO -Single Sign-On. Voir définition complète en section 2. -### TSIG -Transaction Signature. Mécanisme d'authentification cryptographique des transferts de zones DNS (AXFR). ---- -## 8. TERMES SPÉCIFIQUES AU CONTEXTE QUÉBÉCOIS -### CAI -Commission d'accès à l'information du Québec. Autorité de surveillance en matière de protection des renseignements personnels et d'accès à l'information. -### Loi 25 -Loi modernisant des dispositions législatives en matière de protection des renseignements personnels (Québec, 2021). Équivalent québécois du RGPD. -**Obligations principales :** -- Registre des activités de traitement -- EFVP pour traitements à risque élevé -- Notification de violation à la CAI -- Désignation d'un responsable de la protection des renseignements personnels -### NEQ -Numéro d'entreprise du Québec. Identifiant unique attribué par le Registraire des entreprises du Québec. -### Registraire des entreprises du Québec (REQ) -Organisme gouvernemental responsable de l'immatriculation des entreprises au Québec. ---- -## 9. MÉTHODOLOGIES ET CADRES DE RÉFÉRENCE -### 3-2-1 (Stratégie de sauvegarde) -Règle de base en sauvegarde : -- **3** copies des données (originale + 2 sauvegardes) -- **2** supports différents (ex: disque + bande) -- **1** copie hors site (protection contre sinistre localisé) -### Consentement renforcé -Variante du consentement sociocratique exigeant une argumentation plus approfondie et une période de réflexion prolongée. Utilisé pour les décisions particulièrement sensibles (ex: radiation d'un membre). -### OWASP -Open Web Application Security Project. Organisation à but non lucratif produisant des guides de bonnes pratiques en sécurité applicative (ex: OWASP Top 10). -### Post-mortem -Analyse rétrospective d'un incident majeur visant à : -1. Documenter la timeline factuelle -2. Identifier les causes racines -3. Définir des actions correctives et préventives -4. Partager les apprentissages -**Culture :** Sans blâme (blame-free). L'objectif est l'apprentissage collectif, pas la punition. -### Runbook -Document opérationnel décrivant les procédures pas-à-pas pour réaliser des tâches courantes ou répondre à des situations d'urgence. -**Exemples :** -- Procédure de restauration d'un serveur DNS -- Réponse à une panne de service critique -- Rotation des certificats SSL ---- -## 10. UTILISATION DE CE GLOSSAIRE -### Règles d'usage -1. **Cohérence terminologique** - - Utiliser systématiquement les termes définis ici dans tous les documents de L'Alliance - - En cas d'ambiguïté, se référer à ce glossaire -2. **Évolution du glossaire** - - Révision annuelle obligatoire - - Ajouts possibles par proposition au Cercle Stratégique - - Modifications majeures nécessitent consentement du Cercle Stratégique -3. **Traductions** - - Version française : référence officielle - - Traductions vers d'autres langues bienvenues, mais la version française fait foi -4. **Formation** - - Lecture obligatoire pour tout nouveau membre (phase d'onboarding) - - Référence systématique lors des formations internes -### Signaler une ambiguïté -Si un terme utilisé dans la documentation de L'Alliance vous semble ambigu ou mal défini : -1. Vérifier d'abord ce glossaire -2. Si absent ou insuffisant, soumettre une demande de clarification au Cercle Éthique & Conformité -3. Proposition d'ajout/modification selon le processus d'amendement ---- -## Changelog -### Version 1.0 (22 octobre 2025) -- Création initiale du glossaire -- 60+ termes définis -- 10 sections thématiques -- Approuvé par le Cercle Stratégique ---- -**Fin du Document 0** -**Prochaine révision prévue :** Octobre 2026 -## Référence des 8 couches (Chezlepro) -- Couche 1 – Physique -- Couche 2 – Réseau -- Couche 3 – Virtualisation -- Couche 4 – Orchestration -- Couche 5 – Supervision -- Couche 6 – Services -- Couche 7 – Gouvernance & données -- Couche 8 – Philosophie diff --git a/docs/constitution/00_Nomenclature_v2-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/00_Nomenclature_v2-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index 3fd82fa..0000000 --- a/docs/constitution/00_Nomenclature_v2-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,831 +0,0 @@ -# Standard de Nomenclature v2.0 - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## L'Alliance Boréale -**Version :** 2.0 -**Date :** 21 octobre 2025 -**Statut :** DRAFT - Validation requise par Cercle Technique -**Remplace :** N/A (première version unifiée) -**Auteur :** Daniel Mathieu (Chezlepro) avec assistance Claude -**Licence :** CC-BY-SA 4.0 ---- -## Table des Matières -1. [Introduction](#1-introduction) -2. [Principes Directeurs](#2-principes-directeurs) -3. [Architecture Réseau de Référence](#3-architecture-réseau-de-référence) -4. [Nomenclature VMID (Proxmox)](#4-nomenclature-vmid-proxmox) -5. [Plan d'Adressage IP](#5-plan-dadressage-ip) -6. [Nomenclature VMs (Noms)](#6-nomenclature-vms-noms) -7. [Nomenclature DNS](#7-nomenclature-dns) -8. [Tables de Correspondance](#8-tables-de-correspondance) -9. [Procédures Opérationnelles](#9-procédures-opérationnelles) -10. [Exemples Complets](#10-exemples-complets) -11. [Migration et Adoption](#11-migration-et-adoption) -12. [Annexes](#12-annexes) ---- -## 1. Introduction -### 1.1 Objectif du Document -Ce standard définit la **nomenclature unifiée** pour l'infrastructure de L'Alliance Boréale, couvrant : -- Identifiants de machines virtuelles (VMID) dans Proxmox -- Plan d'adressage IP interne (10.0.0.0/8) -- Noms de VMs lisibles et structurés -- Noms de domaine DNS internes et fédérés -- Correspondance entre tous ces éléments -### 1.2 Portée -Ce standard s'applique à **tous les membres** de L'Alliance Boréale. Chaque membre, opérant derrière son propre NAT/firewall, utilise ce standard dans son espace interne. -### 1.3 Cohérence avec l'Architecture -Ce document est **aligné sur** : -- **Plan d'Adressage IP v3** (03-standards-techniques.md) -- **Architecture à 8 Couches** (Charte Fondatrice) -- **Modèle de fédération décentralisée** (chaque membre autonome) ---- -## 2. Principes Directeurs -### 2.1 Mnémotechnique -Chaque identifiant doit être **immédiatement compréhensible** : -- Le VMID indique la couche et le type de service -- L'adresse IP reflète la fonction -- Le nom DNS est descriptif -### 2.2 Cohérence Totale -**Un seul système** lie : -``` -VMID ←→ IP ←→ Nom VM ←→ DNS -``` -### 2.3 Scalabilité -Le système supporte : -- Jusqu'à **999 tenants** par membre -- Jusqu'à **99 instances** par type de service -- Expansion future sans refonte -### 2.4 Isolation et Autonomie -- Chaque membre utilise **10.0.0.0/8** localement (derrière NAT) -- Pas de conflit entre membres (isolation par firewall) -- VMIDs peuvent être identiques entre membres (Proxmox séparés) ---- -## 3. Architecture Réseau de Référence -### 3.1 Vue Globale -``` -┌─────────────────────────────────────────────────────────────┐ -│ INTERNET PUBLIC │ -│ • Services exposés (web, email, DNS public) │ -└─────────────────────┬───────────────────────────────────────┘ - │ - ┌─────────────┼─────────────┐ - │ │ │ -┌───────▼──────┐ ┌────▼─────┐ ┌────▼─────┐ -│ Chezlepro │ │ Nuage │ │ Techno │ -│ FIREWALL/NAT │ │ Libre │ │ Libre │ -└───────┬──────┘ └────┬─────┘ └────┬─────┘ - │ │ │ - │ 10.0.0.0/8 │ 10.0.0.0/8 │ 10.0.0.0/8 - │ (local) │ (local) │ (local) - │ │ │ -┌───────▼─────────────┴─────────────▼──────────────────────┐ -│ ESPACE FÉDÉRATIF (172.16.0.0/12) │ -│ • Services accessibles entre membres via tunnels │ -│ • DNS secondaire, monitoring, backups │ -└───────────────────────────────────────────────────────────┘ -``` -### 3.2 Plan d'Adressage par Membre -Chaque membre utilise **10.0.0.0/8** selon cette structure : -``` -┌─────────────────────────────────────────────────────────────┐ -│ 10.0.0.0/8 - ESPACE INTERNE (derrière NAT) │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ INFRASTRUCTURE DU FÉDÉRÉ (Couches 1-4) │ -│ │ -│ 10.0.0.0/24 → Management (254 hôtes) │ -│ 10.0.1.0/24 → Platform Services (254 hôtes) │ -│ 10.0.2.0/24 → Public DNS (254 hôtes) │ -│ 10.0.20.0/22 → Reserved Infrastructure (1 024 hôtes) │ -│ │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ TENANTS (Couches 6-8) │ -│ │ -│ 10.0.10.0/23 → Tenant Infrastructure (512 hôtes) │ -│ 10.0.128.0/17 → Expansion (32 766 hôtes, 50% du /8) │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` ---- -## 4. Nomenclature VMID (Proxmox) -### 4.1 Principe Général -Le VMID Proxmox est un **identifiant numérique mnémotechnique** qui encode : -- La zone (Infrastructure ou Tenant) -- La couche (1-4 pour infra, tenant ID pour tenants) -- Le type de service -- L'instance -### 4.2 Infrastructure Fédéré (VMID 01000-04999) -**Format : `0CTTII`** -Où : -- `0` = Infrastructure fédéré (préfixe fixe) -- `C` = Couche (1, 2, 3, ou 4) -- `TT` = Type de service (00-99) -- `II` = Instance (01-99) -**Plages par Couche :** -``` -01000-01999 → Couche 1 - Physique (monitoring matériel) -02000-02999 → Couche 2 - Réseau (DNS, VPN, routeurs) -03000-03999 → Couche 3 - Stockage (Ceph, NFS, backups) -04000-04999 → Couche 4 - Orchestration (Ansible, Git, CI/CD) -``` -**Types de Services (TT) :** -#### Couche 2 - Réseau (02000-02999) -``` -00-09 : DNS (PowerDNS) -10-19 : VPN/WireGuard -20-29 : Routeurs virtuels -30-39 : Proxy/HAProxy -40-49 : Load Balancers -``` -#### Couche 3 - Stockage (03000-03999) -``` -00-09 : Ceph Monitors -10-19 : Ceph OSDs (si VMs) -20-29 : NFS Servers -30-39 : Backup Servers (PBS, Borg) -40-49 : Object Storage (MinIO → Confirmer: stockage objet côté Services (6) si non opéré comme infra; sinon rester 3/4) -``` -#### Couche 4 - Orchestration (04000-04999) -``` -00-09 : Ansible Controllers -10-19 : CI/CD Runners -20-29 : Forgejo/GitLab -30-39 : PostgreSQL → Reclassé Couche 6 – Services Platform -40-49 : FastAPI → Reclassé Couche 6 – Services Platform Admin -50-59 : Artifact Repositories -``` -**Exemples :** -``` -02001 = Couche 2, DNS (00), Instance 1 → PowerDNS Master -02002 = Couche 2, DNS (00), Instance 2 → PowerDNS Slave 1 -02101 = Couche 2, VPN (10), Instance 1 → WireGuard Gateway -04001 = Couche 4, Ansible (00), Instance 1 → Ansible Controller -04201 = Couche 4, Git (20), Instance 1 → Forgejo -``` -### 4.3 Tenants (VMID 10000-99999) -**Format : `TTTII`** -Où : -- `TTT` = Tenant ID (001-999) -- `II` = Instance dans le tenant (01-99) -**Plages par Tenant :** -``` -10001-10099 → Tenant 001 (99 VMs max) -20001-20099 → Tenant 002 (99 VMs max) -30001-30099 → Tenant 003 (99 VMs max) -... -99901-99999 → Tenant 999 (99 VMs max) -``` -**Convention Instance (II) :** -``` -01-09 : Web/Frontend -10-19 : Backend/API -20-29 : Bases de données -30-39 : Cache/Queue -40-49 : Workers/Jobs -50-59 : Monitoring tenant -60-69 : Dev/Staging -70-99 : Usage libre -``` -**Exemples :** -``` -10001 = Tenant 001, Instance 01 → Web Frontend -10002 = Tenant 001, Instance 02 → Web Frontend HA -10011 = Tenant 001, Instance 11 → Backend API -10021 = Tenant 001, Instance 21 → PostgreSQL → Reclassé Couche 6 – Services -20001 = Tenant 002, Instance 01 → Web Frontend -20011 = Tenant 002, Instance 11 → Backend -``` -### 4.4 Plages Réservées -``` -00000-00999 : Réservé Proxmox système -01000-04999 : Infrastructure Fédéré (Couches 1-4) -05000-09999 : Réservé extension infrastructure -10000-99999 : Tenants (001-999) -``` ---- -## 5. Plan d'Adressage IP -### 5.1 Infrastructure (10.0.0.0 - 10.0.23.255) -#### 10.0.0.0/24 - Management -``` -10.0.0.1 → Gateway/Firewall principal -10.0.0.10-.50 → Hyperviseurs Proxmox (nodes physiques) -10.0.0.100-.200 → Outils monitoring/admin (Icinga, Grafana) -10.0.0.250-.254 → Réservé administration -``` -#### 10.0.1.0/24 - Platform Services -``` -10.0.1.10 → Ansible Controller (VMID 04001) -10.0.1.20 → Forgejo Git (VMID 04201) -10.0.1.30 → PostgreSQL → Reclassé Couche 6 – Services Platform (VMID 04301) -10.0.1.40 → FastAPI → Reclassé Couche 6 – Services Platform Admin (VMID 04401) -10.0.1.50 → Dashboard React Platform (VMID 04501) -10.0.1.100-.200 → Autres services plateforme -``` -#### 10.0.2.0/24 - Public DNS -``` -10.0.2.10 → PowerDNS Master (VMID 02001) -10.0.2.11 → PowerDNS Slave 1 (VMID 02002) -10.0.2.12 → PowerDNS Slave 2 (VMID 02003) -10.0.2.20 → WireGuard Gateway (VMID 02101) -10.0.2.30 → HAProxy (VMID 02301) -10.0.2.100-.200 → Autres services réseau -``` -#### 10.0.20.0/22 - Reserved Infrastructure -``` -1 024 adresses réservées pour expansion infrastructure future -``` -### 5.2 Tenants (10.0.10.0 - 10.255.255.255) -#### 10.0.10.0/23 - Tenant Infrastructure -``` -512 adresses pour VMs des tenants -Allocation dynamique via IPAM -Gestion par FastAPI → Reclassé Couche 6 – Services Platform -``` -**Stratégie d'Allocation Suggérée :** -``` -10.0.10.0-.99 → Tenant 001 -10.0.10.100-.199 → Tenant 002 -10.0.11.0-.99 → Tenant 003 -... -``` -#### 10.0.128.0/17 - Expansion Massive -``` -32 766 adresses (50% du /8) -Réservé pour croissance future des tenants -``` -### 5.3 Formule de Calcul IP (Infrastructure) -Pour les services d'infrastructure avec VMID `0CTTII` : -**Si C=2 (DNS/Réseau) :** -``` -IP = 10.0.2.(TT*10 + II) -``` -**Exemples :** -``` -VMID 02001 → TT=00, II=01 → 10.0.2.(0*10+1) = 10.0.2.1 (mais on utilise .10) -VMID 02101 → TT=10, II=01 → 10.0.2.(10*10+1) = 10.0.2.101 (mais on utilise .20) -``` -**Note :** La formule est indicative. En pratique, on utilise une allocation manuelle cohérente documentée ci-dessus. ---- -## 6. Nomenclature VMs (Noms) -### 6.1 Infrastructure (Couches 1-4) -**Format : `-infra---`** -Où : -- `` = ID court du membre (czp, nul, tli, etc.) -- `infra` = Marqueur infrastructure (fixe) -- `` = Type de service (dns-master, ansible-ctrl, etc.) -- `` = Environnement (prod, stg, dev, test) -- `` = Numéro (01, 02, 03...) -**Exemples :** -``` -czp-infra-dns-master-prod-01 -czp-infra-dns-slave1-prod-01 -czp-infra-vpn-gateway-prod-01 -czp-infra-ansible-ctrl-prod-01 -czp-infra-git-forgejo-prod-01 -czp-infra-pbs-backup-prod-01 -czp-infra-ceph-mon1-prod-01 -``` -### 6.2 TENANTS (Couches 6-8) -**Format : `-t---`** -Où : -- `` = ID court du membre -- `t` = Tenant (t001, t002, t003...) -- `` = Type de service (web, db, api, backend, cache, worker...) -- `` = Environnement (prod, stg, dev) -- `` = Numéro (01, 02...) -**Exemples :** -``` -czp-t001-web-prod-01 -czp-t001-db-postgres-prod-01 -czp-t001-api-fastapi-prod-01 -czp-t001-backend-prod-01 -czp-t001-cache-redis-prod-01 -czp-t002-web-prod-01 -czp-t002-app-backend-prod-01 -czp-t002-db-mysql-prod-01 -``` -### 6.3 Conventions Types -**Infrastructure :** -``` -dns-master, dns-slave1, dns-slave2 -vpn-gateway, vpn-peer -ansible-ctrl, ci-runner -git-forgejo, git-gitlab -db-platform, api-admin -pbs-backup, borg-backup -ceph-mon, ceph-osd, nfs-server -``` -**Tenants :** -``` -web, web-nginx, web-apache -db-postgres, db-mysql, db-mariadb -api-fastapi, api-django, backend -cache-redis, cache-memcached -queue-rabbitmq, queue-redis -worker, job-processor -monitoring, logging -``` ---- -## 7. Nomenclature DNS -### 7.1 Infrastructure (Services Fédérés) -**Format : `.infra..alliance-boreale.ca`** -Où : -- `` = Nom du service (dns-master, ansible, git...) -- `infra` = Marqueur infrastructure (fixe) -- `` = ID court (czp, nul, tli) -- `alliance-boreale.ca` = Domaine fédéré -**Exemples :** -``` -dns-master.infra.czp.alliance-boreale.ca → 10.0.2.10 -dns-slave1.infra.czp.alliance-boreale.ca → 10.0.2.11 -vpn.infra.czp.alliance-boreale.ca → 10.0.2.20 -ansible.infra.czp.alliance-boreale.ca → 10.0.1.10 -git.infra.czp.alliance-boreale.ca → 10.0.1.20 -backup.infra.czp.alliance-boreale.ca → 10.0.1.30 -``` -### 7.2 Tenants -**Format : `.t..alliance-boreale.ca`** -Où : -- `` = Nom du service (web, db, api...) -- `t` = Tenant (t001, t002...) -- `` = ID court -- `alliance-boreale.ca` = Domaine fédéré -**Exemples :** -``` -web.t001.czp.alliance-boreale.ca → 10.0.10.1 -db.t001.czp.alliance-boreale.ca → 10.0.10.2 -api.t001.czp.alliance-boreale.ca → 10.0.10.3 -web.t002.czp.alliance-boreale.ca → 10.0.10.10 -backend.t002.czp.alliance-boreale.ca → 10.0.10.11 -``` -### 7.3 DNS Publics (Exposés) -Pour les services exposés publiquement : -``` -www.tenant-example.com → IP publique (NAT vers 10.0.10.X) -mail.tenant-example.com → IP publique (NAT vers 10.0.10.Y) -``` -Le DNS interne reste accessible via le domaine `.alliance-boreale.ca` pour la fédération. ---- -## 8. Tables de Correspondance -### 8.1 Infrastructure Complète (Exemple Chezlepro) -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | PowerDNS Maître | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | PowerDNS Esclave 1 | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | PowerDNS Esclave 2 | -| 02101 | czp-infra-vpn-gateway-prod-01 | 10.0.2.20 | vpn.infra.czp.ab.ca | WireGuard Gateway | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | HAProxy Frontend | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Proxmox Backup Server | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Ansible Controller | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | Forgejo Git | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.30 | db.infra.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services Platform | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | FastAPI → Reclassé Couche 6 – Services Admin | -### 8.2 Tenants (Exemples) -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Web Frontend T001 | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Web Frontend T001 HA | -| 10011 | czp-t001-api-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | API Backend T001 | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services T001 | -| 20001 | czp-t002-web-prod-01 | 10.0.10.10 | web.t002.czp.ab.ca | Web Frontend T002 | -| 20011 | czp-t002-backend-prod-01 | 10.0.10.11 | backend.t002.czp.ab.ca | Backend T002 | -| 20021 | czp-t002-db-mysql-prod-01 | 10.0.10.12 | db.t002.czp.ab.ca | MySQL T002 | ---- -## 9. Procédures Opérationnelles -### 9.1 Création d'une Nouvelle VM Infrastructure -**Étapes :** -1. **Déterminer le VMID** - ``` - - Identifier la couche (2, 3, ou 4) - - Identifier le type de service - - Choisir l'instance disponible - Exemple: DNS Slave 3 → 02003 - ``` -2. **Calculer l'IP** - ``` - - Consulter la table d'allocation (section 5) - - Exemple: 02003 → 10.0.2.12 - ``` -3. **Construire le nom VM** - ``` - Format: -infra--- - Exemple: czp-infra-dns-slave3-prod-01 - ``` -4. **Créer l'entrée DNS** - ``` - Format: .infra..alliance-boreale.ca - Exemple: dns-slave3.infra.czp.alliance-boreale.ca → 10.0.2.12 - ``` -5. **Créer la VM dans Proxmox** - ```bash - qm create 02003 \ - --name czp-infra-dns-slave3-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=2 \ - --ipconfig0 ip=10.0.2.12/24,gw=10.0.0.1 - ``` -6. **Documenter** - - Ajouter dans le registre des VMs - - Mettre à jour l'inventaire Ansible - - Ajouter dans le monitoring -### 9.2 Création d'une Nouvelle VM Tenant -**Étapes :** -1. **Allouer un Tenant ID** - ``` - - Consulter le registre des tenants - - Exemple: Prochain disponible = 003 → t003 - ``` -2. **Déterminer le VMID** - ``` - Format: TTTII - Exemple: Tenant 003, Web → 30001 - ``` -3. **Allouer une IP** - ``` - - Utiliser IPAM ou allocation manuelle dans 10.0.10.0/23 - - Exemple: 10.0.10.20 - ``` -4. **Construire le nom VM** - ``` - Format: -t--- - Exemple: czp-t003-web-prod-01 - ``` -5. **Créer l'entrée DNS** - ``` - Format: .t..alliance-boreale.ca - Exemple: web.t003.czp.alliance-boreale.ca → 10.0.10.20 - ``` -6. **Créer la VM dans Proxmox** - ```bash - qm create 30001 \ - --name czp-t003-web-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=10 \ - --ipconfig0 ip=10.0.10.20/23,gw=10.0.0.1 - ``` -### 9.3 Migration d'une VM Existante -**Pour renommer selon le nouveau standard :** -1. **Identifier les attributs actuels** - ``` - VMID actuel: 104 - Nom actuel: vm-web-01 - IP actuelle: 10.50.100.5 - ``` -2. **Déterminer les nouveaux attributs** - ``` - Catégorie: Tenant 001 - Type: Web - → VMID: 10001 - → IP: 10.0.10.1 - → Nom: czp-t001-web-prod-01 - → DNS: web.t001.czp.alliance-boreale.ca - ``` -3. **Planifier la migration** - ``` - - Fenêtre de maintenance - - Backup complet - - Plan de rollback - ``` -4. **Exécuter la migration** - ```bash - # Arrêter la VM - qm stop 104 - # Renommer (si VMID change, recréer) - qm set 104 --name czp-t001-web-prod-01 - # Changer l'IP (dans la VM) - # Mettre à jour DNS - # Redémarrer - qm start 104 - # Valider - ``` ---- -## 10. Exemples Complets -### 10.1 Infrastructure Minimale (Bronze) -**Membre : Chezlepro (czp)** -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS Maître | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Orchestration | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Backups | -### 10.2 Infrastructure Complète (Or) -**Membre : Chezlepro (czp)** -| VMID | Nom | IP | DNS | -|------|-----|-----|-----| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | -| 02101 | czp-infra-vpn-gw-nul-prod-01 | 10.0.2.20 | vpn-nul.infra.czp.ab.ca | -| 02102 | czp-infra-vpn-gw-tli-prod-01 | 10.0.2.21 | vpn-tli.infra.czp.ab.ca | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | -| 03001 | czp-infra-ceph-mon1-prod-01 | 10.0.1.50 | ceph-mon1.infra.czp.ab.ca | -| 03002 | czp-infra-ceph-mon2-prod-01 | 10.0.1.51 | ceph-mon2.infra.czp.ab.ca | -| 03003 | czp-infra-ceph-mon3-prod-01 | 10.0.1.52 | ceph-mon3.infra.czp.ab.ca | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | -| 04101 | czp-infra-ci-runner1-prod-01 | 10.0.1.60 | ci-runner1.infra.czp.ab.ca | -| 04102 | czp-infra-ci-runner2-prod-01 | 10.0.1.61 | ci-runner2.infra.czp.ab.ca | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.31 | db.infra.czp.ab.ca | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | -| 04501 | czp-infra-dashboard-react-prod-01 | 10.0.1.41 | dashboard.infra.czp.ab.ca | -### 10.3 Tenant Multi-Services -**Tenant 001 - Client "Acme Corp"** -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Frontend Nginx | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Frontend HA | -| 10011 | czp-t001-api-fastapi-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | Backend API | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services 15 | -| 10031 | czp-t001-cache-redis-prod-01 | 10.0.10.5 | cache.t001.czp.ab.ca | Redis Cache | -| 10041 | czp-t001-worker-celery-prod-01 | 10.0.10.6 | worker.t001.czp.ab.ca | Celery Worker | -| 10061 | czp-t001-web-staging-01 | 10.0.10.7 | web-stg.t001.czp.ab.ca | Staging Web | -### 10.4 Architecture Fédérée (3 Membres) -**Services DNS exposés entre membres :** -| Membre | VMID | Nom | IP Interne | DNS Fédéré | IP Fédérée (172.16.x.x) | -|--------|------|-----|------------|------------|-------------------------| -| Chezlepro | 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | 172.16.1.10 | -| Nuage Libre | 02001 | nul-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.nul.ab.ca | 172.16.2.10 | -| TechnoLibre | 02001 | tli-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.tli.ab.ca | 172.16.3.10 | -**Note :** Les VMIDs sont identiques (02001) car chaque membre a son propre Proxmox. Les IPs internes sont identiques (10.0.2.10) car isolées par NAT. Les IPs fédérées (172.16.x.x) sont uniques et routées via tunnels VPN. ---- -## 11. Migration et Adoption -### 11.1 Stratégie de Migration -**Phase 1 : Documentation (Semaine 1-2)** -- [ ] Valider ce standard avec le Cercle Technique -- [ ] Obtenir le consentement de tous les membres actuels -- [ ] Publier dans la documentation officielle -- [ ] Former les administrateurs de chaque membre -**Phase 2 : Nouveaux Déploiements (Semaine 3+)** -- [ ] Toute nouvelle VM doit suivre ce standard -- [ ] Utiliser les templates Ansible/Terraform mis à jour -- [ ] Documenter dans le registre -**Phase 3 : Migration Progressive (Mois 2-6)** -- [ ] Inventorier toutes les VMs existantes -- [ ] Prioriser par criticité (services critiques en dernier) -- [ ] Planifier fenêtres de maintenance -- [ ] Migrer par lots (5-10 VMs à la fois) -- [ ] Valider après chaque lot -**Phase 4 : Consolidation (Mois 7-12)** -- [ ] Vérifier conformité à 100% -- [ ] Mettre à jour toute la documentation -- [ ] Former les nouveaux membres sur ce standard -### 11.2 Outils de Migration -**Script d'Audit :** -```bash -#!/bin/bash -# audit-nomenclature.sh -# Vérifie la conformité des VMs au standard v2.0 -for vmid in $(qm list | awk '{print $1}' | grep -v VMID); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,]*\).*/\1/') - echo "VMID: $vmid | Nom: $name | IP: $ip" - # Vérifier conformité VMID - if [[ ! $vmid =~ ^(0[1-4][0-9]{3}|[1-9][0-9]{4})$ ]]; then - echo " ⚠️ VMID non conforme" - fi - # Vérifier conformité nom - if [[ ! $name =~ ^[a-z]+-((infra)|(t[0-9]{3}))-[a-z0-9-]+-prod-[0-9]{2}$ ]]; then - echo " ⚠️ Nom non conforme" - fi - echo "" -done -``` -**Script de Génération DNS :** -```bash -#!/bin/bash -# generate-dns-records.sh -# Génère les enregistrements DNS à partir de l'inventaire Proxmox -MEMBER="czp" -DOMAIN="alliance-boreale.ca" -echo "; Infrastructure DNS Records" -for vmid in $(qm list | grep "infra" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - service=$(echo $name | cut -d'-' -f3-) - echo "${service}.infra.${MEMBER}.${DOMAIN}. IN A ${ip}" -done -echo "" -echo "; Tenant DNS Records" -for vmid in $(qm list | grep "\-t[0-9]" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - tenant=$(echo $name | grep -oP 't\d{3}') - service=$(echo $name | cut -d'-' -f3) - echo "${service}.${tenant}.${MEMBER}.${DOMAIN}. IN A ${ip}" -done -``` -### 11.3 Checklist de Conformité -**Pour chaque VM :** -- [ ] VMID respecte le format (0CTTII ou TTTII) -- [ ] Nom VM respecte le format -- [ ] IP cohérente avec la fonction -- [ ] Enregistrement DNS créé et fonctionnel -- [ ] Documenté dans l'inventaire -- [ ] Tags Proxmox appropriés -- [ ] Monitoring configuré ---- -## 12. Annexes -### 12.1 Glossaire -| Terme | Définition | -|-------|------------| -| **VMID** | Identifiant numérique unique d'une VM dans Proxmox | -| **Fédéré** | Membre de L'Alliance Boréale | -| **Tenant** | Client/organisation hébergé par un membre | -| **Infrastructure Fédéré** | Services propres au membre (couches 1-4) | -| **NAT** | Network Address Translation - isole l'espace 10.0.0.0/8 | -| **Espace Fédératif** | Plage 172.16.0.0/12 routée entre membres via tunnels | -### 12.2 Références -- **Document 03** : Standards Techniques (Plan d'Adressage IP v3) -- **Document 01** : Charte Fondatrice (Architecture 8 Couches) -- **Document 07** : Guide d'Intégration Technique -- **Document 14** : Structure YAML du Registraire -### 12.3 Table de Conversion VMID Legacy → v2.0 -**Si vous avez des VMs avec anciens VMIDs :** -| Fonction | VMID Legacy | VMID v2.0 | Justification | -|----------|-------------|-----------|---------------| -| DNS Master | 100 | 02001 | Couche 2, DNS (00), Instance 1 | -| DNS Slave | 101 | 02002 | Couche 2, DNS (00), Instance 2 | -| Ansible | 200 | 04001 | Couche 4, Ansible (00), Instance 1 | -| PostgreSQL → Reclassé Couche 6 – Services | 150 | 04301 | Couche 4, DB Platform (30), Instance 1 | -| Web Tenant 1 | 1001 | 10001 | Tenant 001, Instance 01 | -| DB Tenant 1 | 1002 | 10021 | Tenant 001, Instance 21 (DB) | -### 12.4 FAQ -**Q : Que faire si j'ai plus de 99 VMs pour un tenant ?** -R : Augmenter le nombre de chiffres pour l'instance (TTTIII au lieu de TTTII), ou subdiviser en sous-tenants (t001a, t001b). -**Q : Puis-je utiliser des VMIDs personnalisés ?** -R : Non pour les nouveaux déploiements. Le standard doit être respecté pour la cohérence fédérale. -**Q : Les VMIDs entre membres peuvent-ils être identiques ?** -R : Oui ! Chaque membre a son propre Proxmox. czp-002 peut avoir VMID 02001, et nul-002 aussi. -**Q : Comment gérer les environnements dev/staging ?** -R : Utiliser le champ `` dans le nom (prod, stg, dev). L'IP peut être dans un sous-réseau dédié (ex: 10.0.100.0/24 pour staging). -**Q : Faut-il migrer toutes les VMs immédiatement ?** -R : Non. Migration progressive recommandée sur 6-12 mois. Nouveaux déploiements doivent être conformes immédiatement. -**Q : Comment documenter les exceptions ?** -R : Dans le registre des VMs avec justification. Exceptions doivent être validées par le Cercle Technique. -### 12.5 Templates de Documentation -**Template Fiche VM (YAML) :** -```yaml -vm: - vmid: 02001 - name: czp-infra-dns-master-prod-01 - member: czp-001 - category: infrastructure - layer: 2 - service_type: dns - network: - ip: 10.0.2.10 - subnet: /24 - gateway: 10.0.0.1 - vlan: 2 - dns: - internal: dns-master.infra.czp.alliance-boreale.ca - federated: dns-master.infra.czp.alliance-boreale.ca - resources: - cpu: 2 - ram: 4096 - disk: 100G - backup: - enabled: true - schedule: daily - retention: 30d - monitoring: - enabled: true - checks: - - dns_query - - process_powerdns - - disk_usage - tags: - - infrastructure - - dns - - critical - - layer-2 -``` -**Template Entrée Inventaire Ansible :** -```yaml -# inventory/hosts.yml -all: - children: - infrastructure: - children: - layer_2_network: - hosts: - dns-master.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.2.10 - vmid: 02001 - layer: 2 - service: dns-master - layer_4_orchestration: - hosts: - ansible.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.1.10 - vmid: 04001 - layer: 4 - service: ansible-controller - tenants: - children: - tenant_001: - hosts: - web.t001.czp.alliance-boreale.ca: - ansible_host: 10.0.10.1 - vmid: 10001 - tenant: 001 - service: web -``` ---- -## 13. Validation et Approbation -### 13.1 Processus de Validation -**Ce document doit être validé par :** -- [ ] **Cercle Technique** - Validation technique de la nomenclature -- [ ] **Expert DevOps/SRE** - Validation Proxmox et automatisation -- [ ] **Expert Réseau** - Validation plan IP et DNS -- [ ] **Tous les membres actuels** - Consentement pour adoption -**Timeline :** -- Semaine 1-2 : Revue et commentaires -- Semaine 3 : Intégration des retours -- Semaine 4 : Vote de consentement -- Semaine 5+ : Publication et déploiement -### 13.2 Critères d'Acceptation -Pour que ce standard soit adopté : -- ✅ Aucun membre n'a d'objection majeure (principe de consentement) -- ✅ Compatibilité confirmée avec infrastructures existantes -- ✅ Outils de migration validés et testés -- ✅ Documentation complète et claire -- ✅ Formation prévue pour tous les administrateurs -### 13.3 Versionnage -**Version actuelle : 2.0 (DRAFT)** -Historique des versions : -- v2.0 (2025-10-21) : Création initiale - Nomenclature unifiée complète -- v2.1 (future) : Ajustements après retours terrain ---- -## 14. Maintenance du Standard -### 14.1 Révisions -Ce document sera révisé : -- **Annuellement** (octobre de chaque année) -- **À la demande** si problème majeur détecté -- **Lors d'évolutions** de l'architecture (nouveau plan IP, etc.) -### 14.2 Propositions de Modification -Pour proposer une modification : -1. Ouvrir une issue dans le dépôt Git de gouvernance -2. Documenter le problème et la solution proposée -3. Discussion au Cercle Technique (1 réunion minimum) -4. Vote de consentement si impact majeur -5. Publication de la nouvelle version -### 14.3 Responsable du Document -**Responsable principal :** Cercle Technique -**Contact :** technique@alliance-boreale.ca -**Dépôt Git :** https://forge.alliance-boreale.ca/standards/nomenclature ---- -## 15. Conclusion -### 15.1 Récapitulatif -Ce Standard de Nomenclature v2.0 établit : -- ✅ Un système unifié VMID ↔ IP ↔ Nom ↔ DNS -- ✅ Une organisation claire Infrastructure vs Tenants -- ✅ Une scalabilité jusqu'à 999 tenants par membre -- ✅ Une cohérence avec le Plan d'Adressage IP v3 -- ✅ Des procédures opérationnelles claires -- ✅ Une stratégie de migration progressive -### 15.2 Bénéfices Attendus -**Pour les Membres :** -- Gestion simplifiée de l'infrastructure -- Onboarding rapide des nouveaux administrateurs -- Automatisation facilitée (Ansible, Terraform) -- Audit et conformité simplifiés -**Pour L'Alliance :** -- Interopérabilité renforcée -- Documentation homogène -- Support technique facilité -- Crédibilité professionnelle -### 15.3 Prochaines Étapes -1. **Validation** : Soumettre au Cercle Technique (semaine du 28 octobre 2025) -2. **Révision** : Intégrer retours (semaine du 4 novembre 2025) -3. **Vote** : Consentement des membres (semaine du 11 novembre 2025) -4. **Publication** : Version finale (15 novembre 2025) -5. **Formation** : Sessions pour administrateurs (décembre 2025) -6. **Déploiement** : Nouveaux projets conformes (janvier 2026) -7. **Migration** : VMs existantes (jan-déc 2026) ---- -**« Une nomenclature claire est le fondement d'une infrastructure maîtrisée. »** ---- -**FIN DU DOCUMENT** -**Standard de Nomenclature v2.0 - L'Alliance Boréale** -**© 2025 L'Alliance Boréale - CC-BY-SA 4.0** -**Document préparé avec l'assistance de Claude (Anthropic)** \ No newline at end of file diff --git a/docs/constitution/01_Charte_Fondatrice_v2.1-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/01_Charte_Fondatrice_v2.1-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index 021b3d9..0000000 --- a/docs/constitution/01_Charte_Fondatrice_v2.1-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,486 +0,0 @@ -# Document 1 : Charte Fondatrice de L'Alliance Boréale - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## Constitution et Principes Fondamentaux -🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md) -**Version:** 2.1 (consolidée) -**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 : [à compléter lors de la signature] - - 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 premiers membres externes -### 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 :** -1. Annonce publique (3 mois de préavis minimum) -2. Liquidation ordonnée des actifs -3. Restitution des fonds aux membres (prorata) ou don à un organisme aligné avec les valeurs -4. Archivage de la documentation (dépôt public pour la postérité) -5. 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://registraire.alliance-boreale.ca \ No newline at end of file diff --git a/docs/constitution/02_Reglement_de_Regie_Interne-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/02_Reglement_de_Regie_Interne-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index a8baa5b..0000000 --- a/docs/constitution/02_Reglement_de_Regie_Interne-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,1093 +0,0 @@ -# Document 2 : Règlement de Régie Interne - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## L'Alliance Boréale -🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md) -**Version:** 1.0 -**Date:** 23 octobre 2025 -**Statut:** Document fondateur -**Adopté par :** Cercle des Référents Boréaux -**Licence:** CC BY-SA 4.0 ---- -## PRÉAMBULE -Le présent Règlement de Régie Interne (ci-après "le Règlement") établit les règles de gouvernance et de fonctionnement de L'Alliance Boréale. -**Hiérarchie des documents :** -1. **Charte Fondatrice** (Document 1) : Vision, valeurs, principes inviolables -2. **Règlement de Régie Interne** (ce document) : Opérationnalisation de la Charte -3. **Documents opérationnels** (Documents 3-15) : Détails techniques et procédures -**En cas de contradiction :** -La Charte prévaut toujours sur le Règlement. Le Règlement prévaut sur les documents opérationnels. -**Révision :** -Ce Règlement est révisé annuellement lors de l'assemblée générale. Les amendements suivent la procédure définie à la Section 6. -**Langue officielle :** -Français. Des traductions vers d'autres langues sont bienvenues, mais seule la version française fait foi. ---- -## SECTION 1 : STRUCTURE DE GOUVERNANCE SOCIOCRATIQUE -### 1.1 Principes Fondamentaux -L'Alliance Boréale adopte la **gouvernance sociocratique** comme modèle organisationnel. -**Quatre piliers de la sociocratie :** -1. **Décision par consentement** (pas consensus, pas vote majoritaire) -2. **Organisation en cercles** semi-autonomes -3. **Double liaison** entre cercles (représentants-liens) -4. **Élection sans candidat** par consentement -**Référence théorique :** -Sociocratie développée par Gerard Endenburg (Pays-Bas, 1970s), inspirée des travaux de Kees Boeke et des Quakers. -**Avantages pour L'Alliance :** -- Efficacité (pas de débats interminables) -- Légitimité (toutes les voix sont entendues) -- Agilité (adaptation rapide) -- Prévention de la tyrannie (majoritaire ou minoritaire) ---- -### 1.2 Cercle Stratégique -#### 1.2.1 Composition -**Membres :** Tous les membres actifs de L'Alliance. -**Président du cercle :** Élu par consentement pour un mandat de 12 mois, renouvelable une fois. -**Secrétaire :** Désigné par consentement pour documenter les décisions. -**Représentants-liens :** -- 1 représentant vers le Cercle Opérationnel -- 1 représentant vers le Cercle Éthique & Conformité -#### 1.2.2 Mandat -**Mission principale :** Définir la vision, l'orientation stratégique, et assurer la cohérence avec la Charte. -**Responsabilités :** -- Admission et radiation des membres -- Révision de la Charte et du Règlement -- Validation du budget annuel -- Définition des objectifs stratégiques (5 ans) -- Arbitrage des conflits entre cercles -- Élection des présidents de cercle -**Ce que le Cercle Stratégique ne fait PAS :** -- Décisions techniques quotidiennes (délégué au Cercle Opérationnel) -- Gestion des audits de label (délégué au Cercle Éthique) -- Micro-management des membres -#### 1.2.3 Mode de Décision -**Défaut :** Consentement sociocratique. -**Quorum :** 2/3 des membres actifs (en personne ou par procuration écrite). -**Procédure :** Voir Section 3.1. -**Fallback :** Vote majoritaire si blocage ≥ 14 jours (voir Section 3.2). -#### 1.2.4 Fréquence des Réunions -**Réunions ordinaires :** Trimestrielles (janvier, avril, juillet, octobre). -**Réunions extraordinaires :** Convocables par : -- Le président du cercle -- 1/3 des membres actifs -- Le Cercle des Référents Boréaux (phase transitoire) -**Préavis :** Minimum 14 jours pour réunions ordinaires, 7 jours pour extraordinaires (sauf urgence documentée). -**Format :** Présentiel privilégié, visioconférence acceptée. -#### 1.2.5 Durée des Mandats -**Président :** 12 mois, renouvelable une fois (maximum 24 mois consécutifs). -**Secrétaire :** 12 mois, renouvelable sans limite. -**Représentants-liens :** 12 mois, rotation encouragée. -**Renouvellement :** Élections annuelles lors de la réunion de janvier. ---- -### 1.3 Cercle Opérationnel -#### 1.3.1 Composition -**Membres :** 3 à 7 personnes désignées parmi les membres actifs. -**Critères de sélection :** -- Expertise technique (infrastructure, réseau, développement) -- Disponibilité (≥ 10h/mois pour coordination) -- Représentativité (diversité des tailles et types de membres) -**Président du cercle :** Élu par consentement parmi les membres du cercle. -**Secrétaire technique :** Documente décisions et actions. -**Représentants-liens :** -- 1 représentant vers le Cercle Stratégique (double liaison) -- 1 représentant vers le Cercle Éthique (si pertinent) -#### 1.3.2 Mandat -**Mission principale :** Coordination technique, gestion de l'infrastructure partagée, outils communs. -**Responsabilités :** -- Gestion du DNS fédéré (délégations, configurations, incidents) -- Administration des outils communs (Matrix, forge, wiki, Registraire) -- Coordination des audits techniques (support aux auditeurs) -- Monitoring et alerting de l'infrastructure fédérée -- Gestion de la banque de temps (validation des transactions) -- Support technique peer-to-peer (facilitation, escalade) -- Veille technologique (nouvelles menaces, opportunités) -**Ce que le Cercle Opérationnel ne fait PAS :** -- Gérer l'infrastructure interne des membres (chacun reste souverain) -- Imposer des choix techniques (sauf standards d'interopérabilité) -- Réaliser des audits de conformité (délégué au Cercle Éthique) -#### 1.3.3 Mode de Décision -**Défaut :** Consentement sociocratique. -**Fallback :** Vote majoritaire simple si blocage ≥ 7 jours (décisions techniques nécessitant rapidité). -**Quorum :** 2/3 des membres du cercle. -**Escalade :** Si majorité impossible ou question stratégique, escalade vers Cercle Stratégique. -#### 1.3.4 Fréquence des Réunions -**Réunions ordinaires :** Mensuelles (premier mardi du mois, 18h00-20h00 HNE). -**Réunions extraordinaires :** Convocables en cas d'incident P0/P1. -**Format :** Visioconférence (Matrix/Jitsi), présentiel optionnel (rencontre annuelle). -**Documentation :** Toutes les décisions documentées au Registraire (dossier `gouvernance/decisions/`). -#### 1.3.5 Durée des Mandats -**Membres du cercle :** 6 mois, renouvelable. -**Rotation :** Recommandée tous les 12 mois pour éviter fossilisation. -**Président :** 6 mois, renouvelable une fois (maximum 12 mois consécutifs). -**Renouvellement :** Semi-annuel (janvier, juillet). ---- -### 1.4 Cercle Éthique & Conformité -#### 1.4.1 Composition -**Membres :** 3 à 5 personnes élues parmi les membres actifs. -**Critères de sélection :** -- Connaissance des enjeux éthiques (vie privée, sécurité, gouvernance) -- Impartialité démontrée (pas de conflit d'intérêts) -- Compétences en médiation/arbitrage -- Capacité rédactionnelle (communication publique) -**Président du cercle :** Élu par consentement parmi les membres du cercle. -**Secrétaire éthique :** Documente audits, décisions, arbitrages. -**Représentants-liens :** -- 1 représentant vers le Cercle Stratégique (double liaison) -- 1 représentant vers le Cercle Opérationnel (si pertinent) -#### 1.4.2 Mandat -**Mission principale :** Garant de l'alignement avec les valeurs, gestion du label, médiation des conflits. -**Responsabilités :** -- Gestion du label de prestige (processus, audits, attribution) -- Coordination des audits pair-à-pair (formation, planning, validation) -- Médiation des conflits entre membres -- Arbitrage des cas de suspension/radiation -- Communication publique (annonces, rapports annuels) -- Veille éthique (évolutions légales, meilleures pratiques) -- Protection des lanceurs d'alerte (mécanisme confidentiel) -**Ce que le Cercle Éthique ne fait PAS :** -- Audits techniques détaillés (délégué à des auditeurs pairs) -- Décisions techniques (sauf impact éthique majeur) -- Gestion quotidienne (délégué au Cercle Opérationnel) -#### 1.4.3 Mode de Décision -**Défaut :** Consentement sociocratique. -**Consentement renforcé :** Pour décisions sensibles (radiation, suspension, révocation de label). -**Quorum :** 100% des membres du cercle (sauf absence justifiée avec procuration). -**Délibérations confidentielles :** Médiations et arbitrages peuvent rester privés (sauf décision finale publiée). -#### 1.4.4 Fréquence des Réunions -**Réunions ordinaires :** Bimensuelles (tous les 2 mois). -**Réunions extraordinaires :** Convocables en cas de : -- Incident éthique majeur -- Conflit nécessitant médiation urgente -- Demande d'arbitrage -**Format :** Visioconférence privilégiée (sensibilité des sujets). -**Documentation :** Décisions publiées au Registraire. Médiations restent confidentielles (sauf accord des parties). -#### 1.4.5 Durée des Mandats -**Membres du cercle :** 24 mois, non consécutifs (pause obligatoire de 12 mois après 2 mandats). -**Président :** 24 mois, non renouvelable immédiatement. -**Renouvellement :** Bisannuel (janvier des années impaires). -**Rationale de la durée longue :** -Stabilité nécessaire pour construire expertise en éthique et confiance des membres. ---- -### 1.5 Représentants-Liens -#### 1.5.1 Rôle et Responsabilités -**Définition :** Personne qui siège dans deux cercles pour assurer la circulation de l'information et la cohérence des décisions. -**Responsabilités :** -- **Remontée** : Transmettre les préoccupations/décisions du cercle inférieur vers le supérieur -- **Descente** : Communiquer les orientations stratégiques vers le cercle inférieur -- **Médiation** : Faciliter compréhension mutuelle entre cercles -- **Alerte** : Signaler incohérences ou tensions entre cercles -**Ce qu'un représentant-lien n'est PAS :** -- Un messager passif (il participe activement aux deux cercles) -- Un espion (il ne rapporte pas "en douce") -- Un chef (il n'impose pas les décisions d'un cercle à l'autre) -#### 1.5.2 Élection et Rotation -**Élection :** Par consentement au sein du cercle d'origine. -**Durée :** Alignée sur le mandat du cercle (6-12 mois selon cercle). -**Rotation :** Encouragée pour éviter accaparement du rôle. -**Révocation :** Possible si perte de confiance (consentement du cercle d'origine). -#### 1.5.3 Règles de Fonctionnement -**Présence aux réunions :** Le représentant-lien doit assister aux réunions des deux cercles (sauf absence justifiée). -**Droit de parole :** Plein et entier dans les deux cercles. -**Droit de vote :** Participe au consentement dans les deux cercles. -**Rapport régulier :** Compte-rendu oral (5 min) au début de chaque réunion des deux cercles. ---- -## SECTION 2 : CERCLE DES RÉFÉRENTS BORÉAUX (Phase Transitoire 2025–2026) -### 2.1 Composition Initiale -**Membres :** -- Membres fondateurs (Chezlepro, TechnoLibre) -- Premiers membres admis durant la phase pilote (2025) -**Président :** Daniel Allaire (membre fondateur, président de L'Alliance). -**Durée de vie :** 2025–2026 (dissolution lors de la constitution en OBNL). -### 2.2 Rôle d'Arbitrage Final -**Mission :** Instance de dernier recours durant la phase pilote, lorsque les cercles ne parviennent pas à une décision. -**Interventions autorisées :** -1. **Blocage persistant dans un cercle** - Si un cercle est bloqué ≥ 30 jours sur une décision stratégique, le Cercle des Référents peut : - - Faciliter la médiation - - Proposer une reformulation - - Trancher en dernier recours (consentement des Référents) -2. **Conflit entre cercles** - Si deux cercles ont des décisions contradictoires, les Référents arbitrent. -3. **Validation des documents constitutifs** - Durant la phase pilote, les documents fondateurs (Charte, Règlement, Label) nécessitent validation des Référents. -4. **Préparation de la constitution en OBNL** - Les Référents pilotent le processus de constitution légale (2026). -**Ce que les Référents ne font PAS :** -- Micro-management quotidien (délégué aux cercles) -- Court-circuiter les cercles sans raison valable -- Imposer des décisions unilatérales (consentement requis) -### 2.3 Mode de Décision -**Défaut :** Consentement sociocratique. -**Phase pilote (2025-2026) :** Unanimité requise pour décisions stratégiques majeures : -- Admission de nouveaux membres -- Modifications de la Charte -- Constitution en OBNL -**Rationale :** En phase pilote, cohésion maximale nécessaire. L'unanimité sera abandonnée lors de la constitution en OBNL. -### 2.4 Conditions de Dissolution -**Dissolution automatique :** Dès la constitution en OBNL (visée 2026-2027). -**Transfert de pouvoirs :** Les pouvoirs des Référents Boréaux sont transférés au : -- **Conseil d'administration** de l'OBNL (décisions stratégiques) -- **Cercle Stratégique** (gouvernance courante) -**Transition graduelle :** 6 mois avant la dissolution, les Référents réduisent progressivement leurs interventions pour préparer l'autonomie complète des cercles. -**Documentation :** Le processus de dissolution et transition sera documenté dans un rapport final (archive historique). ---- -## SECTION 3 : PROCESSUS DE PRISE DE DÉCISION -### 3.1 Consentement Sociocratique (Mode par Défaut) -#### 3.1.1 Définition -**Consentement ≠ Consensus ≠ Unanimité** -| Terme | Définition | Barre de validation | -|-------|------------|---------------------| -| **Unanimité** | Tous votent pour | 100% d'accord actif | -| **Consensus** | Accord de tous après discussion | 100% d'accord actif ou résigné | -| **Consentement** | Absence d'objection valide | Pas d'objection raisonnée | -**Principe du consentement :** -> *"Une décision est adoptée s'il n'existe aucune objection raisonnée et argumentée démontrant que la proposition nuit à l'accomplissement de la mission du cercle."* -**Avantage clé :** Une personne silencieuse ou indifférente ne bloque pas. Seule une objection valide (argumentée et liée à la mission) peut bloquer. -#### 3.1.2 Processus en Trois Tours -**Tour 1 : Clarification (10-15 min)** -**Objectif :** S'assurer que tout le monde comprend la proposition. -**Déroulement :** -1. Porteur de la proposition présente (5 min) -2. Questions de clarification uniquement (pas de débat, pas d'opinions) -3. Porteur répond aux questions -**Exemple de questions autorisées :** -- "Peux-tu préciser ce que tu entends par X ?" -- "Quel est le calendrier envisagé ?" -- "Quels sont les impacts financiers ?" -**Exemple de questions NON autorisées (tour suivant) :** -- "Je pense que c'est une mauvaise idée parce que..." -- "Et si on faisait plutôt Y ?" ---- -**Tour 2 : Réactions (15-20 min)** -**Objectif :** Permettre à chacun d'exprimer son ressenti, ses réserves, ses suggestions. -**Déroulement :** -1. Chaque participant s'exprime à tour de rôle (pas de débat) -2. Porteur écoute sans répondre (prend des notes) -3. À la fin, porteur peut reformuler sa proposition si pertinent -**Ton encouragé :** -- "J'apprécie l'intention, mais j'ai une inquiétude concernant..." -- "J'aurais préféré qu'on considère aussi..." -- "Cela me semble cohérent avec nos valeurs." -**Pas d'obligation de parler :** Silence = absence d'objection (acceptable). ---- -**Tour 3 : Objections (10-30 min)** -**Objectif :** Identifier les objections valides qui empêchent l'adoption. -**Déroulement :** -1. Facilitateur demande : "Y a-t-il des objections à cette proposition ?" -2. Si objection(s) → traitement (voir ci-dessous) -3. Si aucune objection → **décision adoptée** -**Traitement d'une objection :** -1. Personne formule son objection clairement -2. Facilitateur demande : "Est-ce une objection valide ?" (critères ci-dessous) -3. Si valide → recherche d'amendement (porteur + objecteur collaborent) -4. Si non valide → objection écartée (avec bienveillance) -**Critères d'objection valide :** -Une objection est valide si elle répond OUI à au moins une de ces questions : -1. **Impact mission** : "Cette proposition nuit-elle à l'accomplissement de la mission du cercle ?" -2. **Risque sérieux** : "Crée-t-elle un risque sérieux pour L'Alliance ou ses membres ?" -3. **Violation valeurs** : "Contrevient-elle aux 5 valeurs cardinales de la Charte ?" -**Objections NON valides (exemples) :** -- "Je n'aime pas cette idée." (préférence personnelle) -- "On pourrait faire mieux." (sans démontrer de risque) -- "Je ne suis pas sûr." (doute sans argument) -- "Ça ne me concerne pas." (alors pourquoi objecter ?) -**Si objection valide → amendement :** -- Porteur et objecteur cherchent ensemble un amendement -- Nouvelle proposition formulée -- Retour au Tour 3 (vérification absence d'objection sur version amendée) -**Si impossible d'amender → décision rejetée ou reportée.** -#### 3.1.3 Durée Typique -**Décision simple :** 30-45 min -**Décision complexe :** 1-2h -**Décision stratégique majeure :** 2-3h (possibilité de réunion dédiée) -**Si dépassement :** Facilitateur peut proposer report pour maturation. ---- -### 3.2 Fallback : Vote Majoritaire -#### 3.2.1 Conditions de Déclenchement -Le vote majoritaire est déclenché si : -1. **Blocage persistant ≥ 14 jours** (Cercle Stratégique) ou **≥ 7 jours** (Cercle Opérationnel) -2. **ET** impossibilité d'amender la proposition pour lever l'objection -3. **ET** décision consentie du cercle de passer au vote -**Processus de déclenchement :** -1. Président du cercle constate le blocage (durée dépassée) -2. Président propose : "Passons-nous au vote majoritaire ?" -3. Si consentement pour voter → vote -4. Si objection à voter → escalade vers cercle supérieur -#### 3.2.2 Procédure de Vote -**Quorum :** 2/3 des membres du cercle (présents ou procuration écrite). -**Majorité requise :** -- Décision ordinaire : Majorité simple (50% + 1) -- Décision stratégique : Majorité qualifiée (2/3) -**Bulletin :** -- Pour -- Contre -- Abstention (compté dans le quorum, pas dans le décompte) -**Résultat :** -- Majorité atteinte → décision adoptée -- Majorité non atteinte → décision rejetée ou escalade -**Documentation :** -- Résultat du vote publié au Registraire -- Mention explicite : "Décision par vote (fallback), consentement non atteint" -- Explication du blocage initial -#### 3.2.3 Limites du Vote Majoritaire -**Le vote ne peut PAS être utilisé pour :** -- Modifier les 5 valeurs cardinales (inviolables) -- Radier un membre sans procédure contradictoire -- Court-circuiter systématiquement le consentement (abus sanctionnable) -**Révision annuelle :** -Si >30% des décisions d'un cercle se font par vote, c'est un signal d'alarme. Investigation requise (dysfonctionnement du cercle ? formation insuffisante ? conflit interpersonnel ?). ---- -### 3.3 Escalade vers Cercle Supérieur -#### 3.3.1 Conditions d'Escalade -**Escalade déclenchée si :** -1. **Égalité parfaite lors d'un vote** (50-50) -2. **OU** décision nécessitant validation d'un cercle supérieur (statuts) -3. **OU** conflit d'intérêts majeur (membres concernés s'abstiennent → plus de quorum) -4. **OU** blocage persistant ≥ 30 jours malgré vote -**Cercle concerné détermine si escalade nécessaire** (consentement requis pour escalader). -#### 3.3.2 Processus d'Escalade -**Étape 1 : Documentation** -- Résumé de la décision tentée -- Argumentaires des deux côtés -- Raison du blocage -- Tentatives de résolution (amendements, votes) -**Étape 2 : Présentation au cercle supérieur** -- Représentant-lien présente le dossier -- Parties peuvent s'exprimer (si invitées) -- Cercle supérieur délibère (consentement) -**Étape 3 : Décision finale** -- Cercle supérieur tranche -- Décision s'impose au cercle inférieur -- Documentation publiée au Registraire -**Étape 4 : Retour d'expérience** -- Analyse des causes du blocage -- Actions préventives (formation, clarification de rôles, etc.) -#### 3.3.3 Délais et Exigences de Transparence -**Délai de traitement :** Maximum 30 jours après escalade. -**Transparence :** -- Résumé publié au Registraire (sauf confidentialité justifiée) -- Parties informées de la décision par écrit (avec rationale) -- Possibilité de recours si violation de procédure (Cercle Éthique) ---- -## SECTION 4 : CYCLE DE VIE DES MEMBRES -### 4.1 Critères d'Admissibilité -#### 4.1.1 Critères Obligatoires -Pour être admissible, une organisation doit : -**1. Être un acteur du numérique éthique** -- Fournir des services numériques (hébergement, développement, conseil) -- OU opérer une infrastructure numérique pour sa communauté -- OU développer des outils libres/ouverts -**Exclusions :** -- Pure vente de matériel (sans services associés) -- Revendeurs sans expertise technique -- Acteurs dont le modèle repose sur la publicité ciblée ou la vente de données -**2. Alignement avec les 5 valeurs cardinales** -- Souveraineté : Contrôle de ses données et infrastructure -- Liberté : Standards ouverts, pas de lock-in -- Sobriété : Mesure et réduction de l'empreinte -- Solidarité : Volonté de coopérer -- Transparence : Accepter audit et publication du score -**Vérification :** Lettre d'intention + entretien avec Cercle Stratégique. -**3. Capacité technique minimale** -- Infrastructure hébergée (propre ou louée) : ≥ 1 serveur opérationnel -- Services déployés : ≥ 1 service critique en production (email, web, fichiers, etc.) -- Compétences système : Capacité à gérer DNS, VMs, sauvegardes -**Vérification :** Présentation technique lors de l'entretien d'admission. -**4. Volonté de participer activement** -- Temps disponible : ≥ 5h/mois pour participation (gouvernance, support, outils) -- Engagement financier : Capacité à payer la cotisation annuelle (500-2000 $) -- Engagement social : Présence sur Matrix, participation aux réunions -**Vérification :** Évaluation durant la période probatoire (3 mois). -#### 4.1.2 Critères Recommandés (Non Obligatoires) -**Souhaités mais pas bloquants :** -- Statut juridique stable (OBNL, coopérative, entreprise enregistrée) -- Ancrage géographique au Québec/Canada -- Usage de logiciels libres (≥ 50% de la stack) -- Certification/Label existant (B Corp, ISO, etc.) -**Pourquoi non obligatoires ?** -Nous voulons permettre à des acteurs émergents (startups éthiques, projets communautaires) de nous rejoindre, même s'ils ne cochent pas toutes les cases. ---- -### 4.2 Processus de Candidature -#### 4.2.1 Étape 1 : Lettre d'Intention (2-4 semaines) -**Documents à préparer :** -1. **Lettre d'intention** (2-3 pages) - - Présentation de l'organisation (historique, mission, valeurs) - - Motivation à rejoindre L'Alliance (pourquoi maintenant ?) - - Alignement avec les 5 valeurs cardinales (exemples concrets) - - Contributions envisagées (services, expertise, temps) -2. **Fiche membre préliminaire** (template YAML) - - Informations légales (nom, NEQ, juridiction) - - Contacts clés (technique, légal, sécurité) - - Infrastructure (serveurs, DNS, services) - - URLs publiques (site, status, politiques) -3. **Plan de contribution** (1 page) - - Services que vous pouvez offrir à la fédération - - Expertises que vous pouvez partager - - Temps que vous pouvez consacrer (gouvernance, support) - - Outils/code que vous pourriez contribuer -**Soumission :** -Email à candidatures@alliance-boreale.ca avec objet : "[CANDIDATURE] Nom-Organisation" -**Accusé de réception :** Sous 7 jours. -**Révision préliminaire :** Cercle Stratégique vérifie admissibilité (critères obligatoires). Si non admissible → refus motivé. Si admissible → passage à l'étape 2. -#### 4.2.2 Étape 2 : Parrainage (1-2 semaines) -**Phase post-fondatrice (2026+) :** Un membre actif doit parrainer le candidat. -**Rôle du parrain :** -- Valider la lettre d'intention (cohérence, alignement) -- Faciliter introduction à la communauté (Matrix) -- Accompagner durant entretien et probation -**Comment trouver un parrain :** -- Réseau existant (contacts personnels) -- Annonce sur Matrix #general (candidat peut se présenter) -- Facilitation par le Cercle Stratégique (si aucun volontaire) -**Si aucun parrain volontaire après 30 jours → candidature suspendue** (peut re-candidater ultérieurement). -**Phase pilote (2025) :** Parrainage non requis (membres fondateurs accompagnent directement). -#### 4.2.3 Étape 3 : Entretien avec le Cercle Stratégique (1-2h) -**Format :** Visioconférence (Jitsi) ou présentiel (si possible). -**Participants :** -- Candidat (1-3 représentants) -- Parrain -- Cercle Stratégique (tous les membres actifs invités) -**Déroulement :** -**Partie 1 : Présentation du candidat (30 min)** -- Historique et mission (10 min) -- Architecture technique (10 min) -- Plan de contribution et alignement valeurs (10 min) -**Partie 2 : Questions-Réponses (30-45 min)** -- Clarifications techniques (infrastructure, services, sécurité) -- Approfondissement valeurs (exemples concrets de sobriété, solidarité, etc.) -- Disponibilité et engagement (temps, budget, participation) -- Scenarios hypothétiques (ex: "Comment réagiriez-vous si un membre vous demande support technique urgent un dimanche soir ?") -**Partie 3 : Délibération (15-30 min, candidat absent)** -- Cercle Stratégique délibère (consentement) -- Si objection valide → refus motivé OU conditions supplémentaires -- Si pas d'objection → admission en probation -**Partie 4 : Annonce de la décision** -- Candidat rejoint la réunion -- Décision annoncée (avec motivation si refus) -- Si accepté : explication de la phase probatoire -**Documentation :** -- Compte-rendu d'entretien versé au Registraire -- Décision d'admission documentée (`gouvernance/decisions/YYYY-NNN-admission-XXX.yml`) -#### 4.2.4 Étape 4 : Vote d'Admission -**Phase pilote (2025-2026) : Unanimité requise** -Tous les membres fondateurs et membres en probation doivent consentir (ou pas d'objection valide). -**Phase post-pilote (2027+) : Consentement standard** -Décision par consentement sociocratique du Cercle Stratégique. -**Si refus :** -- Feedback motivé au candidat (pourquoi, quelles lacunes) -- Possibilité de re-candidater après 6 mois (si corrections apportées) -- Aucune raison discriminatoire (taille, origine, etc.) -**Si acceptation :** -- Statut : Membre en probation (3 mois) -- Accès : Outils communs (Matrix, forge, Registraire en lecture) -- Cotisation : Aucune durant probation (paiement après confirmation statut actif) ---- -### 4.3 Phase Probatoire (3 mois) -#### 4.3.1 Objectifs à Atteindre -**Durant les 3 mois de probation, le nouveau membre doit :** -**1. Déployer les services minimaux d'interopérabilité** -- ✅ DNS configuré (serveurs autoritaires déclarés) -- ✅ AXFR fonctionnel avec au moins 2 pairs -- ✅ SSO configuré (Keycloak ou équivalent) -- ✅ Services de base opérationnels (email avec DKIM/SPF/DMARC) -- ✅ Monitoring exportant métriques (Prometheus ou équivalent) -**2. Atteindre une disponibilité ≥ 99%** -- Mesure via monitoring partagé -- Incident P0/P1 toléré si post-mortem réalisé -- Downtime planifié annoncé 48h à l'avance (non compté) -**3. Participer activement aux échanges** -- ✅ Présence sur Matrix (réponse < 48h aux mentions) -- ✅ Participation à au moins 1 réunion de Cercle Stratégique -- ✅ Contribution à la documentation (≥ 1 amélioration wiki ou runbook) -**4. Contribuer à au moins 1 outil commun** -- Exemples : amélioration Registraire, playbook Ansible, doc technique, audit pair -- Validation par le Cercle Opérationnel -**5. Réaliser le début d'audits croisés** -- Participer à au moins 1 audit (comme audité OU auditeur) -- Objectif : familiarisation avec le processus de label -#### 4.3.2 Suivi par le Parrain -**Fréquence :** Points de contact bimensuels (toutes les 2 semaines). -**Format :** Informel (appel, Matrix, visio 30 min). -**Sujets :** -- Avancement sur les objectifs (checklist ci-dessus) -- Difficultés rencontrées (technique, organisationnel, relationnel) -- Questions et support (le parrain facilite, oriente, connecte) -**Escalade :** -Si le filleul ne progresse pas ou disparaît (non-réponse > 14 jours), le parrain alerte le Cercle Stratégique. -**Documentation :** -Le parrain rédige un journal de suivi (pas publié, archivé pour évaluation). -#### 4.3.3 Évaluation Finale (Fin de Probation) -**Timing :** Semaine 11-12 (avant la fin des 3 mois). -**Processus :** -**1. Auto-évaluation du nouveau membre** (template fourni) -- Checklist des objectifs (atteints ou non) -- Difficultés rencontrées -- Apprentissages -- Intentions futures (participation aux cercles, demande de label, etc.) -**2. Évaluation par le parrain** (rapport écrit) -- Progression observée -- Qualité de la participation -- Alignement avec les valeurs (concret) -- Recommandation : Statut actif / Prolongation probation / Refus -**3. Feedback des pairs** (optionnel mais encouragé) -- Autres membres ayant interagi peuvent donner feedback (formulaire anonyme ou identifié) -- Exemple : "J'ai collaboré avec X sur l'audit DNS, très pro et réactif." -**4. Décision du Cercle Stratégique** -- Réunion dédiée (ou point à l'ordre du jour) -- Présentation de l'évaluation (parrain) -- Questions au nouveau membre (si besoin) -- Décision par consentement : - * **Statut actif** (passage confirmé) - * **Prolongation probation** (3 mois supplémentaires si justifié) - * **Refus** (non-alignement ou inactivité persistante) -**Documentation :** -- Décision versée au Registraire (`gouvernance/decisions/`) -- Mise à jour de la fiche membre (`status: active` ou `status: exited`) -#### 4.3.4 Cas Particuliers -**Prolongation de probation :** -- Justifiée si : Progrès visibles mais insuffisants (ex: incident technique indépendant de la volonté) -- Maximum : 1 prolongation de 3 mois (total 6 mois) -- Après 6 mois : décision finale (actif ou refus) -**Retrait volontaire durant probation :** -- Aucune pénalité -- Possibilité de re-candidater ultérieurement (aucun délai imposé) ---- -### 4.4 Statut de Membre Actif -#### 4.4.1 Droits -**Gouvernance :** -- ✅ Droit de vote (participation au consentement dans le Cercle Stratégique) -- ✅ Éligibilité aux cercles (Opérationnel, Éthique) -- ✅ Proposition d'amendements (Charte, Règlement) -**Outils et infrastructure :** -- ✅ Accès complet aux outils communs (Matrix, forge, wiki, Registraire) -- ✅ DNS fédéré (AXFR avec tous les pairs) -- ✅ Support technique communautaire (priorité haute) -**Label et réputation :** -- ✅ Éligibilité à la labellisation (demande volontaire) -- ✅ Usage du logo L'Alliance Boréale (selon charte graphique) -- ✅ Référencement au Registraire public -**Banque de temps :** -- ✅ Possibilité d'accumuler et utiliser des crédits -- ✅ Conversion partielle crédits → réduction cotisation (taux défini annuellement) -#### 4.4.2 Responsabilités -**Financières :** -- ✅ Cotisation annuelle (selon barème : 500-2000 $/an) -- ✅ Paiement dans les 30 jours suivant facturation -- ⚠️ Défaut de paiement > 60 jours → suspension -**Techniques :** -- ✅ Maintenir les services d'interopérabilité (DNS, SSO) -- ✅ Disponibilité > 99% (ou justifier incidents via post-mortem) -- ✅ Déclarer incidents P0/P1 dans les 2h -- ✅ Participer aux audits techniques (comme audité ET auditeur) -**Participatives :** -- ✅ Présence aux réunions du Cercle Stratégique (trimestrielles) -- ✅ Activité sur Matrix (réponse raisonnable aux mentions) -- ✅ Contribution à la documentation (au moins 1x/an) -**Éthiques :** -- ✅ Respect des 5 valeurs cardinales -- ✅ Transparence sur incidents et changements majeurs -- ✅ Accepter les audits pair-à-pair (si demande de label) -- ✅ Signaler conflits d'intérêts potentiels -#### 4.4.3 Obligations Continues -**Révision annuelle :** -- Chaque membre actif doit mettre à jour sa fiche au Registraire (1x/an) -- Confirmation des informations (contacts, services, URLs) -- Déclaration des changements majeurs (fusion, changement propriétaire, etc.) -**Participation minimale :** -- Si absence totale (0 participation) durant 12 mois consécutifs → mise en garde -- Si absence persiste 6 mois après mise en garde → passage en statut "inactif" -- Statut inactif → perte de droits de vote, maintien accès outils -**Redevenir actif :** -- Simple déclaration d'intention + participation constatée durant 3 mois -- Pas de nouvelle probation ---- -### 4.5 Demande de Labellisation -**Voir Document 3 (Cadre de Conformité et Label de Prestige) pour le détail complet.** -**Résumé du processus :** -1. **Demande volontaire** (membre actif depuis ≥ 6 mois) -2. **Auto-évaluation** (grille 6 domaines) -3. **Audit pair-à-pair** (auditeur désigné par Cercle Éthique) -4. **Rapport d'audit** (score, preuves, recommandations) -5. **Décision Cercle Éthique** (attribution niveau : Bronze, Argent, Or, Platine) -6. **Validité :** 12 mois -7. **Recertification** avant expiration -**Durée typique du processus :** 4-8 semaines. -**Coût :** Aucun (inclus dans cotisation). Temps investi valorisé via banque de temps (auditeur reçoit crédits). ---- -### 4.6 Suspension Temporaire -#### 4.6.1 Motifs -**Suspension déclenchée dans les cas suivants :** -**1. Non-conformité majeure non corrigée** -- Violation persistante d'une exigence du label (si labellisé) -- Refus de corriger malgré avertissement (délai 30 jours) -**2. Incident grave non déclaré** -- Incident P0/P1 affectant la fédération, non déclaré dans les 2h -- Dissimulation volontaire d'un incident de sécurité -**3. Non-paiement de cotisation > 60 jours** -- Après rappel à 30 jours et mise en demeure à 45 jours -**4. Inactivité totale > 12 mois** -- Absence complète (pas de réponse Matrix, réunions, etc.) -**5. Comportement contraire aux valeurs** -- Exemples : Propos discriminatoires, harcèlement, sabotage délibéré -- Nécessite plainte formelle et enquête -#### 4.6.2 Procédure Contradictoire -**Garanties :** -- ✅ Notification écrite (email + Matrix) avec motifs précis -- ✅ Délai de réponse (14 jours) pour présenter défense -- ✅ Possibilité d'audition (devant Cercle Éthique) -- ✅ Décision motivée par écrit -- ✅ Droit de recours (Cercle Stratégique en appel) -**Processus :** -1. **Alerte** (Cercle Opérationnel ou Éthique détecte le problème) -2. **Notification** formelle au membre concerné -3. **Enquête** (si nécessaire) : Collecte de preuves, témoignages -4. **Défense** : Membre présente sa version (écrit ou oral) -5. **Délibération** : Cercle Éthique (consentement renforcé) -6. **Décision** : Suspension, avertissement, ou abandon de la procédure -**Délai total :** Maximum 45 jours (sauf urgence justifiée). -#### 4.6.3 Durée et Conditions de Levée -**Durée :** Variable selon gravité (1-6 mois typiquement). -**Effets de la suspension :** -- ❌ Perte de droit de vote -- ❌ Suspension du label (si applicable) -- ❌ Retrait du logo L'Alliance Boréale -- ✅ Maintien accès aux outils (lecture seule) -- ✅ Possibilité de corriger les manquements -**Conditions de levée :** -- Correction des manquements (vérifiée par audit) -- Paiement des cotisations dues (si applicable) -- Engagement écrit à respecter le Règlement -- Décision du Cercle Éthique (consentement) -**Si levée acceptée :** Retour immédiat au statut actif. -**Si levée refusée :** Prolongation suspension OU passage en radiation. ---- -### 4.7 Retrait Volontaire -#### 4.7.1 Préavis Requis -**Délai :** 30 jours (notification écrite obligatoire). -**Exception :** Cas de force majeure (faillite, fermeture forcée) → préavis réduit à 7 jours. -**Notification :** -- Email à retraits@alliance-boreale.ca -- Copie au Cercle Stratégique -- Motif (optionnel mais apprécié pour retour d'expérience) -#### 4.7.2 Obligations de Transition -**Durant le préavis (30 jours), le membre sortant doit :** -1. **Transférer les zones DNS déléguées** - - Identifier toutes les zones dont il a la responsabilité - - Coordonner transfert vers autre(s) membre(s) ou externe - - Vérifier propagation (tests) -2. **Faciliter migration des services fédérés** - - Si utilisateurs hébergés utilisent SSO fédéré → notification + alternative - - Export des données (respect Loi 25 / RGPD) - - Documentation de la procédure de migration -3. **Restituer les accès aux outils communs** - - Retourner clés SSH, tokens API - - Supprimer comptes locaux synchronisés -4. **Finaliser les crédits banque de temps** - - Solde positif → don à un autre membre OU conversion en réduction cotisation finale - - Solde négatif → régularisation (contribution finale ou paiement symbolique) -5. **Arrêter usage du label et du logo** - - Retrait immédiat de tout matériel de communication - - Mise à jour site web (retrait mention L'Alliance Boréale) -#### 4.7.3 Pas de Pénalité Financière -**Principe :** Liberté de partir sans punition. -**Cotisation :** -- Déjà payée pour l'année : non remboursable (prorata possible si décision du Cercle Stratégique) -- Non payée : annulée (pas de facturation pour période non utilisée) -**Aucune "frais de sortie"** ou clause abusive. ---- -### 4.8 Radiation (Cas Extrêmes) -#### 4.8.1 Motifs Graves -**La radiation (exclusion forcée) est réservée aux cas extrêmes :** -**1. Violation grave et répétée des valeurs** -- Exemples : Usage abusif du label, fraude, corruption -- Nécessite preuves solides -**2. Mise en danger délibérée de la fédération** -- Sabotage technique (ex: corruption volontaire de zones DNS) -- Divulgation d'informations confidentielles critiques -**3. Comportement contraire à l'ordre public** -- Activités illégales hébergées (même après demande de cessation) -- Collaboration avec acteurs malveillants (spammeurs, botnets, etc.) -**4. Refus persistant de coopération** -- Refus de corriger non-conformité majeure après suspension -- Refus de participer aux audits obligatoires (si labellisé) -**La radiation ne peut JAMAIS être motivée par :** -- Désaccord politique ou philosophique (tant que respect des valeurs) -- Choix techniques différents (tant que standards respectés) -- Taille ou moyens financiers limités -#### 4.8.2 Procédure (Consentement Renforcé) -**Garanties maximales :** -1. **Plainte formelle** (écrite, argumentée, preuves) -2. **Enquête approfondie** (Cercle Éthique + expert externe si nécessaire) -3. **Notification** au membre concerné (30 jours avant audience) -4. **Audience contradictoire** (membre peut se défendre, apporter témoins) -5. **Délibération** (Cercle Éthique, huis clos) -6. **Décision** (consentement renforcé = 100% du Cercle Éthique, aucune abstention) -7. **Notification écrite** (décision motivée, détaillée) -8. **Droit de recours** (appel auprès Cercle Stratégique dans les 14 jours) -**Délai total :** Minimum 60 jours (respect du contradictoire). -**Publication :** -- Résumé anonymisé publié au Registraire (protection vie privée, mais transparence sur le fait qu'une radiation a eu lieu) -- Détails gardés confidentiels (sauf décision judiciaire) -#### 4.8.3 Effets Immédiats et Conséquences -**Effets immédiats dès notification de radiation :** -- ❌ Révocation de tous les accès (outils communs, DNS, SSO) -- ❌ Retrait immédiat du label et du logo -- ❌ Suppression du Registraire public (archives historiques conservées en privé) -- ❌ Notification aux membres (communiqué interne) -**Conséquences long terme :** -- Impossibilité de re-candidater pendant **5 ans** -- Mention dans les archives (non publiques, consultables par futurs auditeurs si pertinent) -- Aucune communication publique dégradante (protection réputation malgré radiation) -**Transition forcée :** -- Délai de 7 jours pour transférer zones DNS (sinon suppression) -- Aucune obligation de l'Alliance de faciliter migration utilisateurs (mais encouragé si possible) ---- -## SECTION 5 : COMMUNICATION ET TRANSPARENCE -### 5.1 Registraire Public -**URL :** https://registraire.alliance-boreale.ca -**Nature :** Dépôt Git public contenant les métadonnées de L'Alliance. -**Contenu public (accès lecture à tous) :** -**Membres :** -- Fiches membres (partner.yml) : infos légales, contacts, services, DNS, label -- Historique des statuts (timeline admission → actif → label → retrait) -**Gouvernance :** -- Composition des cercles (qui est dans quel cercle) -- Décisions stratégiques (résumés, pas transcriptions) -- Résolutions adoptées (amendements, budgets) -**Label :** -- Attribution des labels par trimestre (membre, niveau, score, domaines) -- Rapports d'audit (synthèse publique, détails techniques privés) -**Banque de temps :** -- Soldes agrégés (non nominatifs si sensibilité) -- Transactions récentes (avec consentement des parties) -**Ce qui reste privé :** -- Détails techniques de sécurité (configurations, vulnérabilités) -- Médiations et arbitrages (sauf décision finale) -- Données financières détaillées des membres (sauf bilans de L'Alliance) -**Accès en écriture :** -- Membres actifs (via Git, pull request + review) -- Validation automatique (CI/CD, yamllint, schema validation) -**Voir Document 14 (Structure YAML du Registraire) pour détails complets.** ---- -### 5.2 Documentation Obligatoire -#### 5.2.1 Dossiers de Décision -**Toute décision des cercles doit être documentée dans :** -`registraire/gouvernance/decisions/YYYY-NNN-titre-court.yml` -**Contenu minimal :** -- ID unique (année-numéro séquentiel) -- Date -- Cercle concerné -- Type de décision (admission, policy, budget, label, autre) -- Résumé de la proposition -- Processus utilisé (consentement, vote, escalade) -- Résultat (approuvé, rejeté, amendé) -- Actions à entreprendre -**Exemple :** -```yaml -decision_id: 2025-042 -date: 2025-11-15 -circle: strategic -type: admission -title: "Admission de Nouveau Membre SARL en probation" -proposal: - summary: "Admettre Nouveau Membre SARL comme membre en probation" - sponsor: m003-parrain-tech -decision_process: - mode: consent - objections: [] -outcome: approved -effective_date: 2025-11-20 -actions: - - create_member_file: m012-nouveau-membre.yml - - assign_sponsor: m003-parrain-tech - - grant_access: [matrix, forge, registraire-read] -``` -#### 5.2.2 Post-Mortems d'Incidents -**Obligation :** Tout incident P0/P1 doit donner lieu à un post-mortem partagé. -**Délai :** Maximum 7 jours après résolution de l'incident. -**Contenu obligatoire :** -1. **Timeline factuelle** (ce qui s'est passé, quand) -2. **Impact** (services affectés, durée, utilisateurs) -3. **Causes racines** (technique, organisationnelle, humaine) -4. **Actions correctives** (ce qui a été fait pour réparer) -5. **Actions préventives** (ce qui sera fait pour éviter récurrence) -**Publication :** -- Partagé sur Matrix #incidents -- Archivé sur le wiki (section Post-Mortems) -- Anonymisation possible (sécurité) mais transparence maximale encouragée -**Voir Document 9 (Procédures de Gestion des Incidents) pour template complet.** -#### 5.2.3 Audits et Rapports de Conformité -**Fréquence :** Annuelle (ou selon cycle de label). -**Contenu :** -- Scores par domaine (6 domaines du label) -- Preuves fournies (résumé, pas documents sensibles) -- Non-conformités identifiées (majeures, mineures) -- Plan d'action correctif -- Recommandations de l'auditeur -**Publication :** -- Synthèse publique (Registraire, section labels/) -- Rapport détaillé privé (accès Cercle Éthique + membre audité) ---- -### 5.3 Outils de Communication -#### 5.3.1 Matrix (Communication Temps Réel) -**Serveur :** matrix.alliance-boreale.ca (fédéré) -**Salons publics (accessibles après admission) :** -- **#general** : Annonces, discussions générales -- **#support** : Support technique peer-to-peer -- **#incidents** : Déclaration et coordination incidents P0/P1 -- **#gouvernance** : Discussions sur propositions, amendements -- **#dev** : Développement outils communs (Registraire, scripts, etc.) -- **#random** : Discussions informelles, partage de liens -**Salons privés (selon cercles) :** -- **#cercle-strategique** : Membres Cercle Stratégique uniquement -- **#cercle-operationnel** : Membres Cercle Opérationnel -- **#cercle-ethique** : Membres Cercle Éthique -- **#referents-boreaux** : Phase transitoire uniquement -**Règles d'usage :** -- Respect des 5 valeurs cardinales -- Pas de spam, pas de publicité non sollicitée -- Langue principale : français (anglais accepté) -- Réactivité attendue : < 48h aux mentions directes -**Modération :** -- Auto-modération (communauté mature) -- Si problème persistant → Cercle Éthique intervient -#### 5.3.2 Forge Logicielle (Forgejo/Gitea) -**URL :** https://forge.alliance-boreale.ca -**Projets hébergés :** -- Registraire (dépôt principal) -- Playbooks Ansible (infrastructure commune) -- Scripts utilitaires (automatisation) -- Documentation technique (runbooks, guides) -**Accès :** -- Lecture : Public (projets en licence libre) -- Écriture : Membres actifs (contributions via pull request) -**Processus de contribution :** -1. Fork du projet -2. Branch feature/fix-description -3. Commits (messages clairs, conventionnels) -4. Pull Request (description, tests) -5. Review par 1 membre (pair) -6. Merge si tests passent + review positif -#### 5.3.3 Wiki Collaboratif -**URL :** https://wiki.alliance-boreale.ca -**Contenu :** -- Guides techniques (DNS, SSO, monitoring) -- Runbooks opérationnels (procédures pas-à-pas) -- Post-mortems d'incidents (apprentissage) -- FAQ (questions fréquentes) -- Ressources externes (liens, références) -**Édition :** -- Membres actifs (compte wiki lié au SSO) -- Modifications trackées (historique complet) -- Révision par pairs encouragée -**Organisation :** -- Sections par domaine (Infrastructure, Sécurité, Gouvernance, etc.) -- Tags pour navigation (dns, ansible, label, incident, etc.) -- Moteur de recherche full-text ---- -### 5.4 Langue Officielle -**Français** est la langue officielle de L'Alliance Boréale. -**Rationale :** -- Ancrage québécois et canadien francophone -- Facilite confiance et compréhension mutuelle -- Préserve identité culturelle -**Traductions :** -- Bienvenues vers d'autres langues (anglais, espagnol, etc.) -- Mais version française fait foi en cas de divergence -**Accommodements :** -- Membres non francophones acceptés si engagement à utiliser traducteurs -- Documentation critique (Charte, Règlement) traduite en anglais si demande -- Réunions en français (traduction simultanée si nécessaire et faisable) -**Apprentissage :** -- Encouragement à apprendre le français (ressources partagées) -- Mentorat linguistique possible (banque de temps) ---- -## SECTION 6 : RÉVISION DU RÈGLEMENT -### 6.1 Périodicité -**Révision annuelle obligatoire :** Lors de l'assemblée générale annuelle (janvier). -**Révision extraordinaire :** Si nécessité identifiée (dysfonctionnement, évolution légale, etc.). -**Première révision :** Janvier 2026. -### 6.2 Processus d'Amendement -#### 6.2.1 Proposition -**Qui peut proposer :** -- N'importe quel membre actif -- N'importe quel cercle (décision collective) -- Le Cercle des Référents Boréaux (phase transitoire) -**Comment proposer :** -1. Rédiger amendement (format Markdown, section concernée, texte proposé) -2. Justification (pourquoi cet amendement, quel problème il résout) -3. Soumission via forge (pull request sur Registraire) OU email gouvernance@alliance-boreale.ca -**Délai de soumission :** -- Amendements ordinaires : Minimum 60 jours avant assemblée générale -- Amendements urgents : Minimum 14 jours (justification requise) -#### 6.2.2 Consultation Publique -**Durée :** Minimum 14 jours (30 jours recommandés pour amendements majeurs). -**Canaux :** -- Publication sur Matrix #gouvernance -- Notification email à tous les membres actifs -- Document de discussion sur wiki (commentaires ouverts) -**Débat :** -- Chacun peut commenter, questionner, proposer alternatives -- Porteur de l'amendement répond aux questions -- Possibilité de reformulation si feedback pertinent -**Amendements majeurs vs mineurs :** -**Mineur (corrections éditoriales, clarifications) :** -- Consultation 14 jours -- Décision Cercle Stratégique (consentement) -**Majeur (changement de processus, création/suppression de structures) :** -- Consultation 30 jours -- Décision Cercle Stratégique (consentement renforcé) -- Possibilité de referendum (si 1/3 des membres demandent) -#### 6.2.3 Vote et Adoption -**Assemblée générale :** -- Tous les membres actifs invités -- Quorum : 2/3 des membres (présence ou procuration) -**Présentation :** -- Porteur présente amendement (5-10 min) -- Synthèse des commentaires reçus durant consultation -- Reformulations éventuelles -**Décision :** -- Processus de consentement sociocratique (3 tours) -- Si consentement → amendement adopté -- Si objection valide → amendement ou rejet -**Vote de confirmation (optionnel) :** -- Si doute sur le consentement, vote à bulletin secret -- Majorité qualifiée : 2/3 des présents -#### 6.2.4 Entrée en Vigueur -**Délai par défaut :** 6 mois après adoption. -**Rationale :** Laisser le temps aux membres de s'adapter (formations, ajustements techniques, etc.). -**Entrée en vigueur immédiate :** -- Possible si amendement urgent ET consentement unanime -- Exemples : Correction d'incohérence bloquante, adaptation à nouvelle loi -**Notification :** -- Publication de la version amendée du Règlement (Registraire) -- Changelog détaillé (ce qui a changé, pourquoi, quand entre en vigueur) -- Email à tous les membres actifs ---- -### 6.3 Clauses Inviolables -**Les éléments suivants NE PEUVENT PAS être amendés :** -1. **Les 5 valeurs cardinales** (Souveraineté, Liberté, Sobriété, Solidarité, Transparence) -2. **Le principe de gouvernance sociocratique** (décision par consentement) -3. **Le principe de subsidiarité** (autonomie locale prioritaire) -4. **Le droit de retrait volontaire** (liberté de partir) -**Si modification souhaitée de ces éléments :** -Cela nécessiterait une **refondation de L'Alliance** (dissolution + création nouvelle entité). -Processus lourd, requiert unanimité des membres, et ne peut être entrepris à la légère. ---- -## CONCLUSION -Ce Règlement de Régie Interne opérationnalise la vision de la Charte Fondatrice. -**Il n'est pas figé.** Comme L'Alliance elle-même, il évoluera au fil des apprentissages, des défis, et des opportunités. -**Deux principes doivent toujours guider nos révisions :** -1. **Simplicité** : Ajouter une règle seulement si elle résout un problème réel (pas de bureaucratie pour le plaisir). -2. **Alignement** : Toute modification doit renforcer (ou au minimum préserver) les 5 valeurs cardinales. -**L'Alliance Boréale n'est pas un empire. C'est une forêt.** -Ce Règlement est le réseau mycorhizien invisible qui relie nos racines. Discrètement, il nourrit la coopération. Silencieusement, il transmet les ressources. Patiemment, il assure notre résilience collective. -**Bienvenue dans la forêt.** 🌲 ---- -## ANNEXES -### Annexe A : Glossaire (Référence Croisée) -**Voir Document 0 (Glossaire et Définitions) pour terminologie complète.** -**Termes clés de ce Règlement :** -- Cercle -- Consentement sociocratique -- Objection valide -- Représentant-lien -- Membre actif vs. en probation -- Quorum -- Consentement renforcé -### Annexe B : Organigramme de Gouvernance -``` -L'Alliance Boréale (fédération libre) -│ -├─ Cercle des Référents Boréaux (2025–2026, transitoire) -│ -└─ Structure permanente (3 cercles) - │ - ├─ Cercle Stratégique - │ ├─ Tous les membres actifs - │ ├─ Président (12 mois) - │ ├─ Secrétaire (12 mois) - │ └─ Représentants-liens → Cercles Opérationnel & Éthique - │ - ├─ Cercle Opérationnel - │ ├─ 3-7 membres techniques - │ ├─ Président (6 mois) - │ ├─ Secrétaire technique (6 mois) - │ └─ Représentants-liens ↔ Cercles Stratégique & Éthique - │ - └─ Cercle Éthique & Conformité - ├─ 3-5 membres élus - ├─ Président (24 mois) - ├─ Secrétaire éthique (24 mois) - └─ Représentants-liens ↔ Cercles Stratégique & Opérationnel -``` -### Annexe C : Calendrier Type (Année 1) -**Janvier :** -- Assemblée générale annuelle -- Élections (Cercle Stratégique : président, représentants-liens) -- Révision Charte + Règlement -- Validation budget annuel -**Février-Mars-Avril :** -- Réunions trimestrielles Cercle Stratégique -- Réunions mensuelles Cercle Opérationnel -- Audits de label (Q1) -**Avril :** -- Réunion Cercle Stratégique (bilan Q1) -**Mai-Juin :** -- Ateliers techniques mensuels -**Juillet :** -- Réunion Cercle Stratégique (bilan Q2) -- Renouvellement partiel Cercle Opérationnel (rotation 6 mois) -- Rencontre annuelle (présentiel, 2 jours) -**Août-Septembre :** -- Préparation budget année suivante -**Octobre :** -- Réunion Cercle Stratégique (bilan Q3) -- Audits de label (Q4) -**Novembre :** -- Réunion Cercle Éthique (révision politique label) -**Décembre :** -- Préparation assemblée générale janvier ---- -## MÉTADONNÉES -**Document :** 02_Reglement_de_Regie_Interne.md -**Version :** 1.0 -**Date de création :** 23 octobre 2025 -**Auteur :** Claude (profils #11 Gouvernance, #10 Sécurité, #12 Documentaliste) -**Révision par :** Cercle des Référents Boréaux -**Statut :** À adopter par Cercle Stratégique -**Longueur :** ~11 000 mots (22 pages équivalent imprimé) -**Licence :** CC BY-SA 4.0 -**Sources utilisées :** -- `00_Glossaire_et_Definitions.md` -- `01_Charte_Fondatrice_v2_1.md` -- `devis_alliance_boreale_v2.md` -**Prochaine révision prévue :** Janvier 2026 ---- -**Changelog :** -- 2025-10-23 v1.0 : Création initiale du Règlement de Régie Interne ---- -**FIN DU RÈGLEMENT DE RÉGIE INTERNE** -*"La gouvernance n'est pas une fin. C'est un moyen au service de la coopération."* -🌲 **L'Alliance Boréale** -*Gouvernance sociocratique pour une souveraineté numérique partagée.* -> Note: Alignement 8 couches Chezlepro vérifié — aucun changement requis. diff --git a/docs/constitution/03_Cadre_Conformite_Label_Prestige-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/03_Cadre_Conformite_Label_Prestige-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index bb4675f..0000000 --- a/docs/constitution/03_Cadre_Conformite_Label_Prestige-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,1084 +0,0 @@ -# Document 3 : Cadre de Conformité et Label de Prestige - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## L'Alliance Boréale -🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md) -**Version:** 1.0 -**Date:** 23 octobre 2025 -**Statut:** Document fondateur -**Adopté par :** Cercle Éthique & Conformité -**Licence:** CC BY-SA 4.0 ---- -## PRÉAMBULE -Le Label de Prestige de L'Alliance Boréale n'est pas un certificat marketing vide de sens. -**C'est un outil de transparence, d'amélioration continue, et de reconnaissance mutuelle.** -**Trois objectifs complémentaires :** -1. **Transparence envers le public** - Permettre aux utilisateurs finaux de choisir en connaissance de cause (quel membre respecte quelles pratiques). -2. **Amélioration continue des membres** - Le label est un miroir. Il montre où nous excellons et où nous devons progresser. -3. **Reconnaissance entre pairs** - Le label est décerné PAR les membres POUR les membres. C'est une validation par ceux qui connaissent vraiment les défis du terrain. -**Ce que le label N'EST PAS :** -- ❌ Une certification ISO bureaucratique -- ❌ Un outil de compétition toxique (classement, ranking public) -- ❌ Une barrière à l'entrée (le label est volontaire, pas obligatoire) -- ❌ Une garantie absolue (même les meilleurs peuvent avoir des incidents) -**Le label est un processus vivant.** Il évolue avec L'Alliance, nos apprentissages, et l'écosystème numérique. ---- -## SECTION 1 : ARCHITECTURE DU LABEL -### 1.1 Les 6 Domaines d'Évaluation - -(couvrant l’ensemble des 8 couches : Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie/Éthique) - -Le label évalue les pratiques selon **6 domaines** couvrant l'ensemble des couches de l'architecture boréale (couches 1-8 (Physique, Réseau, Virtualisation, Orchestration, Supervision, Services, Gouvernance & données, Philosophie)). -#### Domaine 1 : Infrastructure & Résilience (Couches 1-3 (Physique, Réseau, Virtualisation)) -**Objectif :** Garantir la disponibilité, la durabilité, et la réparabilité de l'infrastructure physique et réseau. -**Thématiques couvertes :** -- Hardware (serveurs, stockage, énergie) -- Réseau (bande passante, latence, redondance) -- Stockage (backups, réplication, chiffrement) -- Monitoring (métriques, alerting) -- Plans de reprise (disaster recovery, RTO/RPO) -**Exemples de critères :** -- Disponibilité mesurée > 99% (hors maintenance planifiée) -- Backups testés mensuellement -- Documentation à jour de l'infrastructure -- Énergie renouvelable > 50% (si contrôle direct) ou hébergeur vert ---- -#### Domaine 2 : Sécurité & Vie Privée (Couches 2-5 (Réseau, Virtualisation, Orchestration, Supervision)) -**Objectif :** Protéger les données des utilisateurs et prévenir les intrusions, conformément aux lois (Loi 25, RGPD). -**Thématiques couvertes :** -- Chiffrement (transit, repos, backups) -- Authentification (MFA, politiques mots de passe) -- Gestion des accès (principe moindre privilège) -- Mises à jour de sécurité (délais, automation) -- Conformité légale (Loi 25, RGPD) -- Gestion des incidents de sécurité -**Exemples de critères :** -- TLS 1.3 obligatoire (pas de TLS 1.0/1.1) -- MFA activée pour accès admin -- Patches critiques appliqués < 7 jours après publication -- Politique de confidentialité publique et conforme -- Registre des traitements de données (RGPD Article 30) ---- -#### Domaine 3 : Interopérabilité & Standards Ouverts (Couches 3-6 (Virtualisation, Orchestration, Supervision, Services)) -**Objectif :** Garantir que les services respectent les standards ouverts et facilitent la portabilité des données. -**Thématiques couvertes :** -- Protocoles ouverts (SMTP, IMAP, CalDAV, WebDAV, XMPP/Matrix, etc.) -- Formats de données (pas de lock-in propriétaire) -- APIs documentées (si applicable) -- Export de données (RGPD Article 20) -- Fédération (si applicable) -**Exemples de critères :** -- Email via SMTP/IMAP (pas uniquement webmail propriétaire) -- Calendrier accessible via CalDAV (pas uniquement app propriétaire) -- Export complet des données utilisateur en < 30 jours -- APIs publiquement documentées (si services API) -- Support de standards de fédération (Matrix, ActivityPub, etc.) ---- -#### Domaine 4 : Logiciels Libres & Éthique (Couches 5-7 (Supervision, Services, Gouvernance & données)) -**Objectif :** Promouvoir l'usage de logiciels libres et l'alignement avec les valeurs de L'Alliance. -**Thématiques couvertes :** -- Pourcentage de stack libre (OS, applications, outils) -- Contribution à l'écosystème libre (patches, donations, sponsoring) -- Transparence sur les dépendances propriétaires -- Éthique des fournisseurs (pas de GAFAM pour services critiques) -- Gouvernance interne (démocratie, transparence) -**Exemples de critères :** -- ≥ 80% de la stack en logiciel libre -- Au moins 1 contribution annuelle à un projet libre -- Aucune dépendance critique aux GAFAM (AWS, GCP, Azure pour prod) -- Publication de la liste des dépendances (transparence) -- Gouvernance démocratique ou coopérative (si applicable) ---- -#### Domaine 5 : Opérations & Documentation (Couches 4-7 (Orchestration, Supervision, Services, Gouvernance & données)) -**Objectif :** Garantir la qualité opérationnelle, la traçabilité, et la transmissibilité des pratiques. -**Thématiques couvertes :** -- Infrastructure as Code (IaC) -- Documentation technique (runbooks, architectures) -- Gestion des incidents (post-mortems, déclarations) -- Monitoring et observabilité -- Automatisation (CI/CD, tests) -**Exemples de critères :** -- IaC pour ≥ 70% de l'infrastructure -- Runbooks à jour pour procédures critiques -- Post-mortem publié pour tout incident P0/P1 -- Métriques de disponibilité publiques (status page) -- Tests automatisés pour changements critiques ---- -#### Domaine 6 : Sobriété Numérique & Durabilité (Toutes Couches) -**Objectif :** Mesurer et réduire l'empreinte écologique du numérique. -**Thématiques couvertes :** -- Consommation énergétique (mesure, réduction) -- Durée de vie du matériel (allongement, réparation) -- Optimisation des ressources (CPU, RAM, stockage, bande passante) -- Sensibilisation des utilisateurs (bonnes pratiques) -- Compensation carbone (optionnel mais valorisé) -**Exemples de critères :** -- Mesure de la consommation énergétique (kWh/mois) -- Serveurs utilisés > 5 ans (si fonctionnels) -- Politique de rétention des données (suppression automatique) -- Guide utilisateur sur sobriété numérique -- Hébergement dans datacenter < 1.3 PUE (Power Usage Effectiveness) ----### 1.2 Les 4 Niveaux de Label -Le label comporte 4 niveaux progressifs. Chaque niveau nécessite un score minimal dans chaque domaine ET un score global minimal. -#### Niveau Bronze (Fondations) -**Symbolique :** Engagement initial, bases solides. -**Critères :** -- Score minimal par domaine : **40/100** -- Score global minimal : **50/100** -- Durée de validité : **12 mois** -**Profil type :** -Nouveau membre ayant déployé les fondations (DNS, sécurité de base, documentation minimale), mais avec marges d'amélioration importantes. -**Autorisations :** -- Usage du badge "Alliance Boréale — Bronze" -- Mention sur site web et communications -- Accès aux outils communs (Matrix, forge, wiki) ---- -#### Niveau Argent (Maturité) -**Symbolique :** Maturité opérationnelle, pratiques établies. -**Critères :** -- Score minimal par domaine : **60/100** -- Score global minimal : **65/100** -- Durée de validité : **12 mois** -**Profil type :** -Membre avec infrastructure robuste, documentation solide, participation active, mais n'ayant pas encore atteint l'excellence dans tous les domaines. -**Autorisations :** -- Usage du badge "Alliance Boréale — Argent" -- Participation comme auditeur pair (avec formation) -- Mention prioritaire dans annuaire public ---- -#### Niveau Or (Excellence) -**Symbolique :** Excellence technique et éthique, référence pour les pairs. -**Critères :** -- Score minimal par domaine : **75/100** -- Score global minimal : **80/100** -- Durée de validité : **12 mois** -- Obligation : Au moins 1 contribution significative à L'Alliance (code, doc, formation) -**Profil type :** -Membre exemplaire, peu d'incidents, documentation exhaustive, forte contribution à la communauté, alignement éthique démontré. -**Autorisations :** -- Usage du badge "Alliance Boréale — Or" -- Rôle de mentor pour nouveaux membres -- Participation au Cercle Éthique (si élu) -- Mention comme "Membre Exemplaire" dans communications ---- -#### Niveau Platine (Avant-garde) -**Symbolique :** Innovation, leadership, modèle inspirant. -**Critères :** -- Score minimal par domaine : **85/100** -- Score global minimal : **90/100** -- Durée de validité : **18 mois** (reconnaissance de l'excellence soutenue) -- Obligation : Au moins 2 contributions majeures à L'Alliance OU leadership d'un projet fédéral -**Profil type :** -Membre d'avant-garde, zéro incident P0 sur 12 mois, innovations partagées, mentorat actif, alignement éthique parfait, inspiration pour l'écosystème. -**Autorisations :** -- Usage du badge "Alliance Boréale — Platine" -- Reconnaissance publique (cas d'étude, conférences) -- Invitation automatique aux cercles stratégiques -- Droit de veto éthique (cas exceptionnels) -**Rare et mérité :** -Le Platine n'est pas un objectif pour tous. C'est une reconnaissance de l'excellence soutenue et de l'impact sur l'ensemble de L'Alliance. ---- -### 1.3 Calcul du Score -#### 1.3.1 Notation par Domaine -Chaque domaine est noté sur **100 points**. -**Structure :** -- Critères obligatoires (60 points) -- Critères recommandés (30 points) -- Critères d'excellence (10 points) -**Critères obligatoires (60 pts) :** -Fondations indispensables. Échec = score plafonné à 59/100 dans le domaine. -**Critères recommandés (30 pts) :** -Bonnes pratiques. Permettent d'atteindre scores Argent/Or. -**Critères d'excellence (10 pts) :** -Innovation, avant-garde. Nécessaires pour Or/Platine. -**Exemple (Domaine 2 : Sécurité) :** -``` -Critères obligatoires (60 pts) : -- TLS 1.2+ sur tous les services publics (10 pts) -- MFA pour accès admin (10 pts) -- Backups chiffrés (10 pts) -- Politique confidentialité publique (10 pts) -- Patches critiques < 30 jours (10 pts) -- Monitoring sécurité actif (10 pts) -Critères recommandés (30 pts) : -- TLS 1.3 uniquement (5 pts) -- MFA pour utilisateurs finaux (5 pts) -- Patches critiques < 7 jours (10 pts) -- Audit de sécurité externe annuel (5 pts) -- Politique RGPD Article 30 complète (5 pts) -Critères d'excellence (10 pts) : -- Zero-knowledge encryption (5 pts) -- Bug bounty program (3 pts) -- Certification ISO 27001 ou équivalent (2 pts) -``` -**Total domaine :** Maximum 100 pts. ---- -#### 1.3.2 Score Global -**Calcul :** -``` -Score Global = Moyenne des 6 domaines -``` -**Exemple :** -| Domaine | Score | -|---------|-------| -| Infrastructure | 75 | -| Sécurité | 80 | -| Interopérabilité | 70 | -| Logiciels Libres | 85 | -| Opérations | 65 | -| Sobriété | 60 | -| **Moyenne** | **72.5** | -→ Niveau : **Argent** (score global 72.5, tous domaines ≥ 60) -**Règle importante :** -Un domaine faible (< seuil) empêche l'accès au niveau supérieur, même si le score global est élevé. -**Rationale :** Éviter les membres "spécialisés" qui excellent dans 4 domaines mais négligent 2 autres. L'Alliance promeut l'excellence équilibrée. ---- -#### 1.3.3 Pondération (Future Évolution) -**Version 1.0 (ce document) :** Tous les domaines ont le même poids (1/6). -**Version future (2027+) :** Possibilité d'introduire pondération si consensus : -- Exemple : Sécurité 25%, Interopérabilité 20%, autres 11% chacun -- Nécessite amendement de ce document (Section 7) -**Rationale de l'égalité actuelle :** -En phase pilote, nous voulons observer quels domaines sont les plus critiques avant d'introduire une pondération. ---- -## SECTION 2 : GRILLES D'ÉVALUATION DÉTAILLÉES -### 2.1 Domaine 1 : Infrastructure & Résilience -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 1.1 | Disponibilité ≥ 99% (12 derniers mois, hors maintenance planifiée) | 10 | Métriques monitoring (Prometheus, Grafana, status page) | -| 1.2 | Backup automatisé quotidien | 10 | Configuration (cron, script, logs) | -| 1.3 | Test de restauration réussi dans les 6 derniers mois | 10 | Rapport de test (date, procédure, résultat) | -| 1.4 | Monitoring actif avec alerting | 10 | Alertmanager configuré, logs d'alertes | -| 1.5 | Documentation de l'architecture (diagramme + inventaire) | 10 | Wiki ou doc versionnée (Markdown, Diagrams.net) | -| 1.6 | Plan de reprise documenté (RTO/RPO définis) | 10 | Document DRP (Disaster Recovery Plan) | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 1.7 | Disponibilité ≥ 99.5% | 5 | Métriques monitoring | -| 1.8 | Backup incrémental + complet hebdomadaire | 5 | Configuration (rsnapshot, Borg, etc.) | -| 1.9 | Réplication géographique (2+ sites) | 5 | Preuve hébergement multi-sites | -| 1.10 | Monitoring externe (tiers indépendant) | 5 | UptimeRobot, Pingdom, ou équivalent | -| 1.11 | Redondance réseau (2+ liens internet) | 5 | Configuration BGP ou failover | -| 1.12 | Infrastructure as Code ≥ 50% | 5 | Playbooks Ansible, Terraform, scripts | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 1.13 | Disponibilité ≥ 99.9% (3 nines) | 5 | Métriques monitoring | -| 1.14 | Chaos engineering (tests de résilience) | 3 | Rapports de tests (ex: ChaosMonkey, simulations) | -| 1.15 | Infrastructure 100% IaC (reproductible) | 2 | Git repo complet | -**Total excellence :** 10 pts -**TOTAL DOMAINE 1 :** 100 pts ---- -### 2.2 Domaine 2 : Sécurité & Vie Privée -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 2.1 | TLS 1.2+ sur tous services publics | 10 | Scan SSL Labs (grade A- minimum) | -| 2.2 | MFA activée pour accès administrateurs | 10 | Capture écran config (TOTP, U2F, etc.) | -| 2.3 | Backups chiffrés (AES-256 ou équivalent) | 10 | Configuration de chiffrement | -| 2.4 | Politique de confidentialité publique et conforme (Loi 25 ou RGPD) | 10 | URL de la politique + revue conformité | -| 2.5 | Patches de sécurité critiques appliqués < 30 jours | 10 | Logs de mises à jour (apt, yum, etc.) | -| 2.6 | Pare-feu configuré (ports nécessaires uniquement) | 10 | Sortie `iptables -L` ou équivalent | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 2.7 | TLS 1.3 uniquement (pas de 1.2) | 5 | Scan SSL Labs (grade A+) | -| 2.8 | MFA proposée aux utilisateurs finaux | 5 | Capture écran option activable | -| 2.9 | Patches de sécurité critiques < 7 jours | 10 | Logs mises à jour | -| 2.10 | Registre des traitements RGPD (Article 30) | 5 | Document du registre | -| 2.11 | Audit de sécurité externe annuel | 5 | Rapport d'audit (synthèse) | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 2.12 | Zero-knowledge encryption (E2EE) | 5 | Architecture technique + audit | -| 2.13 | Bug bounty program actif | 3 | URL du programme + règles | -| 2.14 | Certification ISO 27001 ou SOC 2 | 2 | Certificat valide | -**Total excellence :** 10 pts -**TOTAL DOMAINE 2 :** 100 pts ---- -### 2.3 Domaine 3 : Interopérabilité & Standards Ouverts -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 3.1 | Email via SMTP/IMAP/POP3 (pas uniquement webmail propriétaire) | 15 | Configuration serveur (Postfix, Dovecot, etc.) | -| 3.2 | Export complet des données utilisateur possible | 15 | Procédure documentée + test | -| 3.3 | Formats de stockage ouverts (pas de lock-in propriétaire) | 10 | Liste formats utilisés (Markdown, JSON, SQL, etc.) | -| 3.4 | DNS configuré selon standards (DNSSEC recommandé) | 10 | Validation DNSViz ou équivalent | -| 3.5 | DKIM, SPF, DMARC configurés (si email) | 10 | Scan MXToolbox ou équivalent | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 3.6 | Calendrier via CalDAV / Contacts via CardDAV | 10 | Configuration serveur (Radicale, Nextcloud, etc.) | -| 3.7 | APIs publiquement documentées (si applicable) | 10 | URL documentation (Swagger, OpenAPI, etc.) | -| 3.8 | Support de fédération (Matrix, ActivityPub, XMPP, etc.) | 5 | Configuration + test de fédération | -| 3.9 | Pas de tracking tiers sur site web (Google Analytics, Facebook Pixel, etc.) | 5 | Analyse Blacklight, uBlock Origin | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 3.10 | Contribution à des standards ouverts (RFC, W3C, etc.) | 5 | Liens vers contributions | -| 3.11 | Support multi-protocoles (email + Matrix + CalDAV + WebDAV) | 3 | Configuration complète | -| 3.12 | Publication de schémas de données (Open Data) | 2 | URL schémas (JSON Schema, etc.) | -**Total excellence :** 10 pts -**TOTAL DOMAINE 3 :** 100 pts ---- -### 2.4 Domaine 4 : Logiciels Libres & Éthique -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 4.1 | OS serveur libre (Linux, BSD) | 15 | `uname -a` ou équivalent | -| 4.2 | ≥ 60% de la stack applicative en logiciel libre | 15 | Inventaire logiciels (avec licences) | -| 4.3 | Liste publique des dépendances (transparence) | 10 | Document ou page web | -| 4.4 | Aucune dépendance critique aux GAFAM (production) | 10 | Déclaration signée | -| 4.5 | Gouvernance non autoritaire (coopérative, démocratique, ou collégiale) | 10 | Statuts légaux ou règlement interne | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 4.6 | ≥ 80% de la stack applicative en logiciel libre | 10 | Inventaire détaillé | -| 4.7 | Au moins 1 contribution annuelle à un projet libre | 10 | Liens vers commits, PRs, donations | -| 4.8 | Publication de code maison en licence libre | 5 | Dépôts Git publics | -| 4.9 | Politique d'achat favorisant fournisseurs éthiques | 5 | Document de politique | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 4.10 | 100% de la stack en logiciel libre | 5 | Inventaire complet | -| 4.11 | Mainteneur actif d'un projet libre majeur | 3 | Preuve de maintenance (GitHub stats, etc.) | -| 4.12 | Certification B Corp ou équivalent | 2 | Certificat | -**Total excellence :** 10 pts -**TOTAL DOMAINE 4 :** 100 pts ---- -### 2.5 Domaine 5 : Opérations & Documentation -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 5.1 | Runbook pour au moins 3 procédures critiques | 15 | Wiki ou dépôt doc | -| 5.2 | Documentation architecture à jour | 10 | Diagrammes + descriptions | -| 5.3 | Post-mortem publié pour incidents P0/P1 (6 derniers mois) | 15 | Lien vers post-mortems | -| 5.4 | Monitoring avec métriques exportées (Prometheus compatible) | 10 | Configuration Prometheus | -| 5.5 | Status page public (ou métriques disponibilité) | 10 | URL status page | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 5.6 | IaC pour ≥ 70% de l'infrastructure | 10 | Playbooks Ansible, Terraform | -| 5.7 | CI/CD avec tests automatisés | 10 | Configuration GitLab CI, GitHub Actions, etc. | -| 5.8 | Documentation générée automatiquement (code) | 5 | Sphinx, JSDoc, ou équivalent | -| 5.9 | Contributions régulières au wiki L'Alliance | 5 | Historique Git wiki | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 5.10 | Infrastructure 100% IaC (zero manual config) | 5 | Démo reproductibilité | -| 5.11 | Observabilité avancée (tracing distribué, logs structurés) | 3 | Jaeger, ELK, ou équivalent | -| 5.12 | SLA publiquement documenté et respecté | 2 | SLA + rapport conformité | -**Total excellence :** 10 pts -**TOTAL DOMAINE 5 :** 100 pts ---- -### 2.6 Domaine 6 : Sobriété Numérique & Durabilité -#### Critères Obligatoires (60 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 6.1 | Mesure de la consommation énergétique (kWh/mois) | 15 | Factures ou monitoring IPMI | -| 6.2 | Politique de rétention des données documentée | 10 | Document politique | -| 6.3 | Serveurs utilisés ≥ 3 ans (si contrôle direct) | 15 | Inventaire avec dates acquisition | -| 6.4 | Hébergeur avec engagement environnemental (si externalisé) | 10 | Certification hébergeur (ISO 14001, PUE < 1.5) | -| 6.5 | Guide utilisateur sur bonnes pratiques sobriété | 10 | Document ou page web | -**Total obligatoire :** 60 pts ---- -#### Critères Recommandés (30 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 6.6 | Réduction consommation énergétique année/année | 10 | Comparatif metrics | -| 6.7 | Serveurs utilisés ≥ 5 ans | 5 | Inventaire | -| 6.8 | Optimisation ressources (CPU/RAM/stockage < 70% en moyenne) | 5 | Métriques monitoring | -| 6.9 | Énergie renouvelable ≥ 50% (si contrôle direct) | 5 | Factures ou certificat | -| 6.10 | Extinction services non critiques hors heures | 5 | Scripts automation + logs | -**Total recommandé :** 30 pts ---- -#### Critères d'Excellence (10 pts) -| # | Critère | Points | Preuve Requise | -|---|---------|--------|----------------| -| 6.11 | Énergie 100% renouvelable | 5 | Certificat fournisseur | -| 6.12 | Compensation carbone volontaire | 3 | Reçus donations (Planetair, etc.) | -| 6.13 | Publication rapport impact environnemental annuel | 2 | Rapport public | -**Total excellence :** 10 pts -**TOTAL DOMAINE 6 :** 100 pts ---- -## SECTION 3 : PROCESSUS D'AUDIT -### 3.1 Principe de l'Audit Pair-à-Pair -**L'Alliance Boréale utilise l'audit pair-à-pair :** -Les membres auditent les membres. Pas d'auditeur externe coûteux. Pas de certification bureaucratique. -**Avantages :** -- **Coût zéro** (temps valorisé via banque de temps) -- **Expertise réelle** (les auditeurs connaissent les défis du terrain) -- **Apprentissage mutuel** (audité ET auditeur progressent) -- **Confiance renforcée** (transparence entre pairs) -**Garde-fous :** -- Conflit d'intérêts interdit (on n'audite pas son concurrent direct) -- Formation obligatoire des auditeurs -- Validation finale par Cercle Éthique -- Possibilité de recours (si désaccord sur notation) ---- -### 3.2 Qui Peut Auditer ? -**Éligibilité auditeur :** -- Membre actif depuis ≥ 6 mois -- Score label Argent ou supérieur (si déjà labellisé) -- Formation auditeur complétée (atelier 4h) -- Aucun conflit d'intérêts avec l'audité -**Formation auditeur (obligatoire) :** -- Compréhension des 6 domaines et grilles -- Méthodologie de collecte de preuves -- Rédaction de rapport d'audit -- Éthique de l'auditeur (impartialité, confidentialité) -**Durée formation :** 4h (atelier interactif, 1x/trimestre) -**Validation :** Quiz final (80% requis) -**Certification :** Valide 24 mois (renouvellement via atelier ou examen) ---- -### 3.3 Étapes du Processus d'Audit -#### Étape 1 : Demande de Labellisation (Semaine 0) -**Qui :** Membre actif souhaitant obtenir ou renouveler le label. -**Prérequis :** -- Membre actif depuis ≥ 6 mois -- Aucune suspension en cours -- Cotisation à jour -**Action :** -1. Remplir formulaire de demande (via Registraire ou email) -2. Auto-évaluation préliminaire (grille des 6 domaines) -3. Identification des preuves disponibles -**Délai de traitement :** 7 jours (validation admissibilité par Cercle Éthique) ---- -#### Étape 2 : Désignation de l'Auditeur (Semaine 1) -**Qui :** Cercle Éthique & Conformité. -**Critères de désignation :** -- Éviter conflit d'intérêts (pas de compétiteur direct) -- Privilégier expertise pertinente (ex: expert infra pour domaine 1) -- Rotation équitable (chaque auditeur audite environ 2-3 (Réseau, Virtualisation) fois/an) -**Notification :** -- Auditeur contacté (acceptation sous 7 jours) -- Si refus, désignation d'un autre auditeur -- Audité informé de l'identité de l'auditeur -**Kick-off :** -- Réunion initiale (auditeur + audité, 30-60 min) -- Clarification du périmètre -- Planning de l'audit (4-6 (Orchestration, Supervision, Services) semaines typiquement) ---- -#### Étape 3 : Collecte de Preuves (Semaines 2-4 (Réseau, Virtualisation, Orchestration)) -**Qui :** Audité (prépare preuves) + Auditeur (révise et valide). -**Preuves attendues (selon domaine) :** -**Domaine 1 (Infrastructure) :** -- Captures écran monitoring (Grafana, Prometheus) -- Logs de backups (derniers 3 mois) -- Rapport de test de restauration -- Diagramme architecture (Diagrams.net, Draw.io) -- Plan de reprise (document DRP) -**Domaine 2 (Sécurité) :** -- Scan SSL Labs (grade A- minimum) -- Capture config MFA (avec données sensibles masquées) -- Politique de confidentialité (URL publique) -- Logs mises à jour sécurité (derniers 6 mois) -- Configuration pare-feu (règles actives) -**Domaine 3 (Interopérabilité) :** -- Configuration serveurs (Postfix, Dovecot, etc.) -- Test export données (capture procédure) -- Scan MXToolbox (DKIM, SPF, DMARC) -- Liste formats de données utilisés -**Domaine 4 (Logiciels Libres) :** -- Inventaire logiciels (nom, version, licence) -- Déclaration dépendances GAFAM (signée) -- Liens vers contributions (commits GitHub, donations) -- Statuts légaux (si gouvernance évaluée) -**Domaine 5 (Opérations) :** -- Runbooks (au moins 3, liens wiki) -- Post-mortems (derniers 12 mois) -- Configuration monitoring (Prometheus, Grafana) -- Playbooks IaC (Ansible, Terraform) -**Domaine 6 (Sobriété) :** -- Factures énergétiques (derniers 12 mois, anonymisées si besoin) -- Inventaire serveurs (âge, consommation estimée) -- Politique rétention données (document) -- Guide utilisateur sobriété (URL ou doc) -**Format de soumission :** -- Dépôt Git privé partagé (auditeur + audité + Cercle Éthique) -- Structure : `/domaine-X/critere-X.Y/preuve-*.{pdf,png,md}` -**Échanges :** -- Questions/réponses asynchrones (Matrix canal privé) -- Réunion de mi-parcours (facultative, semaine 3) ---- -#### Étape 4 : Évaluation et Notation (Semaine 5) -**Qui :** Auditeur. -**Action :** -1. Révision de toutes les preuves -2. Attribution des points (critère par critère) -3. Calcul score par domaine (max 100) -4. Calcul score global (moyenne des 6 domaines) -5. Détermination niveau éligible (Bronze/Argent/Or/Platine) -**Grille de notation :** -- ✅ **Preuve solide et complète** → Points attribués -- ⚠️ **Preuve partielle ou incomplète** → Points partiels (50%) -- ❌ **Preuve absente ou invalide** → 0 point -**Justification obligatoire :** -Pour chaque critère, l'auditeur doit noter : -- Preuve fournie (référence) -- Points attribués (nombre) -- Justification (pourquoi ce score) -**Exemple :** -```yaml -domaine: 2 -critere: 2.1 -titre: "TLS 1.2+ sur tous services publics" -points_max: 10 -preuve: "domaine-2/critere-2.1/ssllabs-scan.pdf" -evaluation: - points_attribues: 10 - justification: "Scan SSL Labs montre grade A sur tous les sous-domaines testés. TLS 1.2 et 1.3 activés, pas de TLS 1.0/1.1." -``` ---- -#### Étape 5 : Rapport d'Audit (Semaine 5-6 (Supervision, Services)) -**Qui :** Auditeur. -**Contenu du rapport :** -1. **Page de titre** - - Audité (nom, membre ID) - - Auditeur (nom, membre ID) - - Date de l'audit - - Niveau demandé vs. niveau obtenu -2. **Synthèse exécutive** (1 page) - - Score global - - Scores par domaine (tableau) - - Niveau de label attribué - - Points forts (3-5 (Virtualisation, Orchestration, Supervision)) - - Points d'amélioration (3-5 (Virtualisation, Orchestration, Supervision)) -3. **Évaluation détaillée par domaine** (1-2 (Physique, Réseau) pages/domaine) - - Tableau critères avec points - - Justifications - - Observations de l'auditeur - - Recommandations -4. **Non-conformités identifiées** - - Majeures (critères obligatoires non respectés) - - Mineures (critères recommandés non atteints) - - Suggestions (critères d'excellence) -5. **Plan d'action recommandé** (optionnel) - - Actions prioritaires pour améliorer score - - Délais suggérés - - Ressources nécessaires -6. **Annexes** - - Liste des preuves examinées - - Captures écran clés (si pertinent) -**Format :** Markdown ou PDF. -**Longueur typique :** 10-15 pages. ---- -#### Étape 6 : Révision par l'Audité (Semaine 6) -**Qui :** Audité. -**Délai :** 7 jours pour réagir au rapport. -**Options :** -**A) Acceptation sans réserve** -→ Passage direct à validation Cercle Éthique. -**B) Demande de clarification** -→ Auditeur clarifie (48h). Si satisfaisant, acceptation. Sinon, recours. -**C) Contestation d'un critère** -→ Procédure de recours (voir Section 3.4). -**Documentation :** -- Réponse écrite de l'audité (acceptation, questions, ou contestation) -- Versée au dépôt d'audit ---- -#### Étape 7 : Validation par Cercle Éthique (Semaine 7) -**Qui :** Cercle Éthique & Conformité. -**Action :** -1. Révision du rapport d'audit (cohérence, qualité) -2. Vérification absence conflit d'intérêts -3. Validation des scores (spot-check sur 2-3 (Réseau, Virtualisation) critères) -4. Décision d'attribution du label (consentement) -**Critères de validation :** -- ✅ Rapport complet et justifié -- ✅ Preuves solides -- ✅ Pas de conflit d'intérêts détecté -- ✅ Audité a accepté (ou recours traité) -**Décision possible :** -- **Approuvé** : Label attribué au niveau calculé -- **Approuvé avec conditions** : Label attribué, mais plan d'action obligatoire (délai 6 mois) -- **Rejeté** : Score insuffisant OU preuves invalides → Réaudit requis (délai 3 mois) -**Notification :** -- Audité informé sous 7 jours (email + Matrix) -- Si approuvé : Badge généré, Registraire mis à jour -- Si rejeté : Feedback détaillé + accompagnement proposé ---- -### 3.4 Procédure de Recours -**Déclenchement :** -Audité conteste un ou plusieurs critères du rapport d'audit (désaccord sur notation). -**Délai :** 7 jours après réception du rapport. -**Étapes :** -1. **Dépôt de recours** (formulaire standardisé) - - Critère(s) contesté(s) - - Justification (pourquoi le score devrait être différent) - - Preuves complémentaires (si nouvelles) -2. **Médiation** (Cercle Éthique, 14 jours) - - Rencontre tripartite (audité, auditeur, médiateur du Cercle Éthique) - - Révision des preuves contestées - - Tentative d'accord à l'amiable -3. **Décision finale** (Cercle Éthique, consentement renforcé) - - Si médiation échoue → Cercle Éthique tranche - - Décision motivée par écrit - - Pas d'autre recours (sauf violation de procédure grave → Cercle Stratégique) -**Délai total :** Maximum 30 jours. -**Coûts :** Aucun (inclus dans cotisation). Temps valorisé via banque de temps. ---- -## SECTION 4 : CERTIFICATION ET VALIDITÉ -### 4.1 Attribution du Label -**Suite à validation par Cercle Éthique :** -1. **Génération du badge** (logo + niveau + ID unique) - - Format : SVG + PNG (haute résolution) - - Couleurs : Bronze (CD7F32), Argent (C0C0C0), Or (FFD700), Platine (E5E4E2) -2. **Mise à jour Registraire** - - Fiche membre : ajout du label (niveau, score, date, validité) - - Historique : traçabilité des labels successifs -3. **Communication** - - Annonce sur Matrix #general (félicitations publiques) - - Mention dans newsletter trimestrielle - - Partage autorisé sur réseaux sociaux (membre peut publier son badge) -4. **Remise symbolique** (optionnel) - - Lors de la rencontre annuelle (présentiel) - - Certificat imprimé + badge physique (si demandé) ---- -### 4.2 Durée de Validité -**Par niveau :** -| Niveau | Durée | -|--------|-------| -| Bronze | 12 mois | -| Argent | 12 mois | -| Or | 12 mois | -| Platine | 18 mois | -**Rationale Platine :** -Reconnaître l'excellence soutenue en allégeant la charge de recertification (tous les 1.5 ans au lieu de 1 an). -**Expiration :** -À la date anniversaire (jour/mois/année de l'attribution + durée). -**Alerte :** -- Email automatique 60 jours avant expiration -- Rappel 30 jours avant expiration -- Dernière alerte 7 jours avant expiration -**Si expiration sans renouvellement :** -- Label révoqué automatiquement -- Badge retiré du Registraire (historique conservé) -- Membre doit cesser usage du badge ---- -### 4.3 Renouvellement (Recertification) -**Processus :** -Identique à l'audit initial, MAIS avec simplifications possibles : -**Simplification 1 : Auto-évaluation allégée** -- Focus sur les domaines ayant changé -- Si score précédent ≥ 80 → Auditeur peut spot-check (pas tout réviser) -**Simplification 2 : Même auditeur (optionnel)** -- Si audité et auditeur consentent, possibilité de ré-assigner même binôme -- Avantage : auditeur connaît déjà le contexte -- Rotation tous les 3 cycles recommandée (éviter complaisance) -**Délai recommandé :** -Démarrer le processus 90 jours avant expiration (marge confortable). -**Recertification tardive :** -- Possible jusqu'à 30 jours après expiration (label révoqué mais processus simplifié) -- Au-delà de 30 jours → Audit complet requis (comme nouveau label) ---- -### 4.4 Amélioration de Niveau -**Membre peut demander audit pour niveau supérieur à tout moment :** -**Conditions :** -- Délai minimum : 6 mois après dernier audit -- Auto-évaluation préliminaire montrant éligibilité au niveau supérieur -- Cotisation à jour -**Processus :** -Identique à audit initial (même si label valide). -**Si échec :** -- Label actuel conservé jusqu'à expiration normale -- Possibilité de ré-essayer après 6 mois -**Incitation :** -- Pas de pénalité financière (inclus dans cotisation) -- Reconnaissance publique si passage Or → Platine ---- -## SECTION 5 : USAGE DU LABEL -### 5.1 Droits d'Usage -**Membre labellisé peut :** -✅ Afficher le badge sur : -- Site web (page d'accueil, footer) -- Signatures email professionnelles -- Profils réseaux sociaux (LinkedIn, Mastodon, etc.) -- Matériel de communication (brochures, présentations) -✅ Mentionner le label dans : -- Propositions commerciales -- Appels d'offres (preuve de conformité) -- Communications publiques (articles, conférences) -✅ Utiliser la phrase : -> *"[Nom Membre] est membre certifié de L'Alliance Boréale avec un label [Niveau]."* ---- -### 5.2 Obligations d'Usage -**Membre labellisé doit :** -❌ NE PAS altérer le badge (couleurs, proportions, texte) -❌ NE PAS utiliser un niveau non attribué (ex: afficher Or si Argent) -❌ NE PAS utiliser le badge après expiration -❌ NE PAS faire de déclarations mensongères sur le score -✅ Retirer le badge immédiatement si : -- Label expiré sans renouvellement -- Label révoqué (suspension, radiation) -- Demande du Cercle Éthique (abus constaté) -✅ Lier le badge au Registraire public (URL de vérification) -**URL de vérification :** -`https://registraire.alliance-boreale.ca/membres/[ID]/label` -**Exemple :** -```html - - Label Or - Alliance Boréale - -``` ---- -### 5.3 Surveillance et Sanctions -**Surveillance :** -- Audit aléatoire d'usage (Cercle Éthique, 2x/an) -- Signalement par membres ou public (formulaire web) -**Abus typiques :** -- Badge affiché après expiration -- Badge altéré (couleurs, texte) -- Déclaration niveau supérieur (afficher Platine si Or) -- Usage commercial trompeur (ex: "Certifié ISO 27001" si seulement label Bronze) -**Sanctions :** -**Abus mineur (non intentionnel) :** -- Avertissement écrit -- Correction sous 7 jours -- Aucune autre conséquence -**Abus majeur (intentionnel ou répété) :** -- Suspension du label (3-6 (Virtualisation, Orchestration, Supervision, Services) mois) -- Interdiction de demander label durant suspension -- Possible radiation (si gravité extrême) -**Procédure :** -Contradictoire (voir Document 2, Section 4.6 - Suspension). ---- -## SECTION 6 : RÉVOCATION DU LABEL -### 6.1 Motifs de Révocation -**Le label peut être révoqué dans les cas suivants :** -**1. Non-conformité majeure découverte après attribution** -- Fraude dans les preuves (preuves falsifiées) -- Incident de sécurité grave non déclaré révélant manquements systémiques -- Violation grave des 5 valeurs cardinales -**2. Suspension du membre** -- Suspension administrative → révocation automatique du label -- Rétablissement possible après levée de suspension + réaudit -**3. Dégradation avérée de la conformité** -- Monitoring partagé détecte disponibilité < 95% (domaine 1) -- Scan SSL Labs montre dégradation (domaine 2) -- Signalements répétés d'utilisateurs (domaine 3, 4) -**4. Abus d'usage du label** -- Voir Section 5.3 -**5. Demande volontaire du membre** -- Membre peut renoncer à son label (sans pénalité) -- Utile si le membre sait qu'il ne respecte plus les critères ---- -### 6.2 Procédure de Révocation -**Garanties :** -1. **Enquête préalable** (Cercle Éthique) - - Collecte de preuves (monitoring, rapports, témoignages) - - Vérification des faits -2. **Notification au membre** (14 jours pour répondre) - - Motifs précis de la révocation envisagée - - Preuves fournies - - Droit de défense -3. **Défense du membre** - - Réponse écrite (max 5 pages) - - Audition possible (si demandée, Cercle Éthique) - - Apport de contre-preuves -4. **Décision** (Cercle Éthique, consentement renforcé) - - Révocation confirmée OU - - Révocation abandonnée (si défense convaincante) OU - - Avertissement (si gravité moindre) -5. **Notification de la décision** (motivée par écrit) - - Membre informé sous 7 jours - - Publication résumé anonymisé au Registraire (transparence) -**Délai total :** Maximum 45 jours. ---- -### 6.3 Conséquences de la Révocation -**Immédiates :** -- Badge retiré du Registraire -- Membre doit cesser usage du badge (7 jours) -- Notification aux autres membres (Matrix, interne) -**Long terme :** -- Membre peut redemander label après correction (délai 6 mois minimum) -- Audit complet requis (pas de simplification) -- Historique de révocation documenté (mais pas publié) -**Aucune exclusion de L'Alliance** (sauf si radiation pour autre motif). ---- -## SECTION 7 : ÉVOLUTION DU CADRE DE CONFORMITÉ -### 7.1 Révision Annuelle -**Obligation :** Le Cercle Éthique révise ce document chaque année (Q4). -**Objectifs :** -- Ajuster critères (retours d'expérience auditeurs/audités) -- Ajouter/supprimer critères (évolution technologique) -- Clarifier ambiguïtés (interprétations divergentes) -- Mettre à jour grilles de notation -**Processus :** -1. Collecte feedback (auditeurs, audités, membres) -2. Analyse des scores (domaines trop faciles/difficiles ?) -3. Propositions d'amendements (Cercle Éthique) -4. Consultation publique (30 jours, tous les membres) -5. Amendements finalisés (consentement Cercle Éthique) -6. Validation Cercle Stratégique (si changements majeurs) -**Entrée en vigueur :** 1er janvier de l'année suivante (prévisibilité). ---- -### 7.2 Amendements Hors Cycle -**Possibles si nécessité urgente :** -- Nouvelle loi (ex: Loi 25 amendée) -- Vulnérabilité critique découverte (ex: Log4Shell → ajout critère patches < 48h) -- Incohérence grave détectée -**Processus accéléré :** -- Consultation 14 jours (au lieu de 30) -- Décision Cercle Éthique (consentement) -- Entrée en vigueur immédiate ou différée (selon urgence) -**Notification :** -- Tous les membres alertés (email + Matrix) -- Membres labellisés : évaluation si critères nouveaux les affectent ---- -### 7.3 Transition entre Versions -**Principe : Pas de pénalisation rétroactive.** -**Scénario 1 : Critères durcis** -- Labels déjà attribués restent valides jusqu'à expiration -- Renouvellement : nouveaux critères appliqués -- Délai de grâce : 6 mois pour s'adapter -**Scénario 2 : Critères assouplis** -- Labels existants conservés -- Membres peuvent demander réévaluation immédiate (si score amélioré) -**Scénario 3 : Nouveau domaine ajouté** -- Labels existants : domaine noté 0 (pas pénalisant pour durée restante) -- Renouvellement : nouveau domaine obligatoire -**Exemple concret (version hypothétique 2.0 en 2027) :** -Version 1.0 (2025) : 6 domaines -Version 2.0 (2027) : 7 domaines (ajout "Accessibilité Numérique") -→ Membre labellisé Or en 2026 (version 1.0) conserve son Or jusqu'à expiration 2027. -→ Renouvellement 2027 : audit sur 7 domaines, score Accessibilité doit être ≥ 75 pour garder Or. ---- -## SECTION 8 : GOUVERNANCE DU LABEL -### 8.1 Rôle du Cercle Éthique & Conformité -**Responsabilités exclusives :** -- Gestion des audits (désignation auditeurs, validation rapports) -- Attribution/révocation des labels (décision finale) -- Résolution des recours (médiation, arbitrage) -- Évolution du cadre (amendements annuels) -- Formation des auditeurs (ateliers, certifications) -**Le Cercle Éthique ne fait PAS :** -- Audits techniques détaillés (délégué aux auditeurs pairs) -- Décisions stratégiques (Cercle Stratégique) -- Gestion infrastructure (Cercle Opérationnel) ---- -### 8.2 Transparence et Redevabilité -**Données publiques (Registraire) :** -- Liste des membres labellisés (niveau, score global, date) -- Scores par domaine (agrégés ou détaillés, selon choix membre) -- Historique des labels (timelines) -**Données privées (Cercle Éthique) :** -- Rapports d'audit complets (sauf synthèse publique) -- Preuves techniques (configurations, logs) -- Médiations et recours (sauf décision finale) -**Rapport annuel (Cercle Éthique) :** -- Nombre d'audits réalisés -- Distribution des niveaux (combien Bronze/Argent/Or/Platine) -- Domaines les plus forts/faibles (statistiques agrégées) -- Évolutions année/année -- Révocations (nombre, motifs anonymisés) -**Publication :** Registraire, section `/rapports/label/YYYY.md` ---- -### 8.3 Financement et Ressources -**Coûts du label :** -- Aucun pour les membres (inclus dans cotisation annuelle) -- Temps auditeurs valorisé via banque de temps (crédits) -**Budget alloué :** -- Formation auditeurs (matériel pédagogique, ateliers) -- Outils de suivi (plateforme d'audit, si développée) -- Badges physiques (impression, envoi) -**Estimation :** 5-10% du budget annuel de L'Alliance. ---- -## CONCLUSION -Le Label de Prestige de L'Alliance Boréale n'est pas un gadget marketing. -**C'est un outil de transformation collective.** -En rendant visibles nos pratiques, en célébrant l'excellence, et en accompagnant l'amélioration continue, le label incarne nos valeurs : -- **Souveraineté** : Audit pair-à-pair, pas de dépendance à un tiers certificateur -- **Liberté** : Labellisation volontaire, critères transparents et évolutifs -- **Sobriété** : Domaine 6 dédié, mesure et réduction de l'empreinte -- **Solidarité** : Auditeurs pairs, apprentissage mutuel, banque de temps -- **Transparence** : Scores publics, processus documenté, recours possibles -**Le label évolue avec nous.** -Chaque année, nous apprenons. Chaque audit, nous progressons. Chaque membre labellisé, nous renforçons la crédibilité de L'Alliance. -**Le label n'est pas une fin. C'est un moyen.** -Le moyen de nous tenir mutuellement responsables. Le moyen de montrer au monde qu'un autre numérique est possible. Le moyen de transformer nos valeurs en pratiques concrètes, mesurables, vérifiables. -**Bienvenue dans la forêt labellisée.** 🌲 ---- -## ANNEXES -### Annexe A : Checklist Rapide par Niveau -#### Pour Bronze (Score global ≥ 50, chaque domaine ≥ 40) -**Prioriser :** -- ✅ Critères obligatoires (60 pts/domaine) -- ✅ Disponibilité > 99% -- ✅ TLS 1.2+, MFA admin -- ✅ Backups testés -- ✅ Documentation de base -- ✅ Mesure consommation énergétique -**Suffisant pour Bronze.** ---- -#### Pour Argent (Score global ≥ 65, chaque domaine ≥ 60) -**Ajouter :** -- ✅ 50% des critères recommandés -- ✅ Disponibilité > 99.5% -- ✅ IaC ≥ 50% -- ✅ Contribution à projet libre -- ✅ Post-mortems publiés -**Maturité opérationnelle démontrée.** ---- -#### Pour Or (Score global ≥ 80, chaque domaine ≥ 75) -**Ajouter :** -- ✅ 75% des critères recommandés -- ✅ Quelques critères d'excellence -- ✅ Contribution significative L'Alliance -- ✅ Disponibilité > 99.9% -- ✅ Audit externe annuel (sécurité) -**Excellence technique et éthique.** ---- -#### Pour Platine (Score global ≥ 90, chaque domaine ≥ 85) -**Ajouter :** -- ✅ 90% des critères recommandés -- ✅ Majorité critères d'excellence -- ✅ Contributions majeures multiples -- ✅ Zéro incident P0 (12 mois) -- ✅ Innovation partagée (publication, conférences) -**Modèle inspirant.** ---- -### Annexe B : Templates de Documents -#### B.1 Demande de Labellisation -```yaml -demande_label: - membre_id: m001-exemple - date_demande: 2025-10-23 - niveau_cible: argent - contact: - nom: "Jean Dupont" - email: "jean@exemple.ca" - telephone: "+1-514-555-0100" - auto_evaluation: - domaine_1: 70 # Infrastructure - domaine_2: 75 # Sécurité - domaine_3: 65 # Interopérabilité - domaine_4: 80 # Logiciels Libres - domaine_5: 60 # Opérations - domaine_6: 55 # Sobriété - score_global: 67.5 - motivation: | - Nous souhaitons obtenir le label Argent pour démontrer notre maturité - opérationnelle et notre alignement avec les valeurs de L'Alliance. - Nous avons investi 6 mois dans l'amélioration de notre documentation - et de notre infrastructure. - disponibilites_audit: - - "2025-11-01 to 2025-11-30" - - "2025-12-01 to 2025-12-15" -``` ---- -#### B.2 Rapport d'Audit (Structure Minimale) -```markdown -# Rapport d'Audit — Label Alliance Boréale -## Informations Générales -- **Audité** : [Nom Membre] (ID: mXXX) -- **Auditeur** : [Nom Auditeur] (ID: mYYY) -- **Date audit** : YYYY-MM-DD à YYYY-MM-DD -- **Version cadre** : 1.0 -## Synthèse Exécutive -**Niveau demandé** : Argent -**Niveau obtenu** : Argent -**Score global** : 67.5/100 -| Domaine | Score | Seuil | Statut | -|---------|-------|-------|--------| -| Infrastructure | 70 | 60 | ✅ | -| Sécurité | 75 | 60 | ✅ | -| Interopérabilité | 65 | 60 | ✅ | -| Logiciels Libres | 80 | 60 | ✅ | -| Opérations | 60 | 60 | ✅ | -| Sobriété | 55 | 60 | ❌ | -**Points forts** : -- Excellente conformité logiciels libres (80%) -- Sécurité solide (MFA, TLS 1.3, patches rapides) -- Documentation claire et à jour -**Points d'amélioration** : -- Sobriété numérique (55) sous le seuil Argent (60) -- IaC incomplet (40% de l'infra seulement) -- Monitoring externe absent -## [Sections détaillées par domaine...] -## Conclusion -Le membre XXX démontre une bonne maturité opérationnelle. Le niveau Argent est mérité sous réserve de correction du domaine 6 (Sobriété) dans les 6 mois. -**Signature électronique** : [Auditeur], [Date] -``` ---- -### Annexe C : Calendrier Type d'Audit -``` -Semaine 0 : Demande labellisation -Semaine 1 : Désignation auditeur + kick-off -Semaines 2-4 (Réseau, Virtualisation, Orchestration) : Collecte preuves (audité prépare, auditeur révise) -Semaine 5 : Évaluation + notation (auditeur) -Semaine 5-6 (Supervision, Services) : Rédaction rapport -Semaine 6 : Révision par audité (7 jours) -Semaine 7 : Validation Cercle Éthique -Semaine 8 : Attribution label + communication -Total : ~8 semaines (2 mois) -``` -**Version accélérée (recertification, si simplifié) : 4-5 (Orchestration, Supervision) semaines** ---- -## MÉTADONNÉES -**Document :** 03_Cadre_Conformite_Label_Prestige.md -**Version :** 1.0 -**Date de création :** 23 octobre 2025 -**Auteur :** Claude (profils #10 Sécurité, #11 Gouvernance, #12 Documentaliste) -**Révision par :** Cercle Éthique & Conformité -**Statut :** À adopter par Cercle Stratégique -**Longueur :** ~14 000 mots (28 pages avec grilles détaillées) -**Licence :** CC BY-SA 4.0 -**Sources utilisées :** -- `00_Glossaire_et_Definitions.md` -- `01_Charte_Fondatrice_v2_1.md` -- `02_Reglement_de_Regie_Interne.md` -- `devis_alliance_boreale_v2.md` -**Prochaine révision prévue :** Octobre 2026 (Q4, annuelle) ---- -**Changelog :** -- 2025-10-23 v1.0 : Création initiale du Cadre de Conformité et Label ---- -**FIN DU CADRE DE CONFORMITÉ ET LABEL DE PRESTIGE** -*"Le label n'est pas une médaille à accrocher. C'est un miroir qui nous montre qui nous sommes vraiment."* -🌲 **L'Alliance Boréale** -*Excellence mesurée, amélioration continue, transparence totale.* diff --git a/docs/constitution/04_Manifeste_Philosophique_LEsprit_Boreal-aligne-chezlepro-v1-20251025-162438.md b/docs/constitution/04_Manifeste_Philosophique_LEsprit_Boreal-aligne-chezlepro-v1-20251025-162438.md deleted file mode 100644 index ae8b9e8..0000000 --- a/docs/constitution/04_Manifeste_Philosophique_LEsprit_Boreal-aligne-chezlepro-v1-20251025-162438.md +++ /dev/null @@ -1,1107 +0,0 @@ -# Document 4 : Manifeste Philosophique — L'Esprit Boréal - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## Les Racines de Notre Vision -🔗 Cette documentation est régie par la Charte Cognitive v2.1-MÉTA (voir 00_Charte_Cognitive_Alliance_Boreale.md) -**Version:** 1.0 -**Date:** 23 octobre 2025 -**Statut:** Document fondateur -**Auteur:** Cercle Stratégique de L'Alliance Boréale -**Licence:** CC BY-SA 4.0 ---- -## Préambule -> *"La question n'est pas de savoir si nous pouvons construire un numérique différent, mais si nous avons le courage de le faire lentement."* -Ce manifeste n'est pas un programme politique. Ce n'est pas une liste de revendications. Ce n'est pas un plan d'affaires. -**C'est une déclaration d'intention philosophique.** -L'Alliance Boréale ne se contente pas d'être une fédération technique. Elle incarne une vision du monde, une manière d'habiter le numérique qui refuse la fatalité de la centralisation, de l'extraction, et de la croissance aveugle. -Ce document explore les **racines intellectuelles** qui nourrissent notre projet. Il n'est pas exhaustif — d'autres penseurs auraient pu être convoqués. Mais ceux-ci, par leur radicalité tranquille et leur cohérence, dessinent les contours de ce que nous appelons **l'esprit boréal**. -**Nous ne promettons pas de solutions faciles.** Nous proposons une voie exigeante, lente, coopérative. Une voie qui demande de renoncer à certaines facilités pour gagner en autonomie, en sens, en durabilité. -Si vous cherchez la croissance rapide, passez votre chemin. Si vous cherchez à reproduire les recettes des géants, ce manifeste n'est pas pour vous. -**Mais si vous croyez qu'un autre numérique est possible — plus humble, plus humain, plus vivant — alors bienvenue dans la forêt.** 🌲 ---- -## 1. NOS RACINES INTELLECTUELLES -### 1.1 Ivan Illich (1926-2002) — La Convivialité et les Outils Conviviaux -#### Le diagnostic : la contre-productivité -Ivan Illich, penseur autrichien installé au Mexique, a passé sa vie à analyser les institutions modernes — l'école, l'hôpital, les transports — pour en dévoiler la **contre-productivité**. -> *"Au-delà d'un certain seuil, l'outil, de serviteur, devient despote."* -> — **Une société sans école** (1971) -**La contre-productivité**, selon Illich, survient lorsqu'un outil devient si complexe, si monopolistique, qu'il finit par produire l'inverse de ce pour quoi il a été créé : -- Les autoroutes créent des embouteillages -- L'école dégoûte d'apprendre -- L'hôpital rend malade -- Le numérique isole au lieu de connecter -#### Les outils conviviaux vs manipulatoires -Dans **La Convivialité** (1973), Illich distingue deux types d'outils : -**L'outil convivial** : -- Augmente l'autonomie de celui qui l'utilise -- Peut être compris, réparé, modifié par l'usager -- Reste sous le contrôle de la communauté -- N'impose pas de dépendance -**L'outil manipulatoire** : -- Crée une dépendance structurelle -- Nécessite des experts pour être maintenu -- Échappe au contrôle de l'usager -- Impose un mode de vie -#### Application à L'Alliance Boréale -**Nous choisissons délibérément les outils conviviaux :** -| Outil manipulatoire | Outil convivial (notre choix) | -|---------------------|-------------------------------| -| Services cloud GAFAM | Hébergement souverain | -| Protocoles propriétaires | Standards ouverts (SMTP, IMAP, WebDAV) | -| Plateforme centralisée | Fédération distribuée | -| Boîte noire algorithmique | Code source auditable | -| Obsolescence programmée | Logiciel libre pérenne | -**Notre engagement :** -Chaque choix technique doit passer le test de convivialité d'Illich : *"Cet outil augmente-t-il l'autonomie de nos membres, ou crée-t-il une nouvelle dépendance ?"* -Si la réponse est "dépendance", nous cherchons une alternative, quitte à sacrifier la facilité immédiate. ---- -### 1.2 Pierre Rabhi (1938-2021) — La Sobriété Heureuse -#### Du Sahara à la France : un parcours de cohérence -Pierre Rabhi, paysan, philosophe et poète algérien naturalisé français, a consacré sa vie à promouvoir une agriculture respectueuse de la terre et une philosophie de vie sobre. -> *"La sobriété n'est pas une privation, c'est une libération."* -> — **Vers la sobriété heureuse** (2010) -Né dans le Sahara algérien, ouvrier en France, puis paysan en Ardèche, Rabhi a vécu ce qu'il prêchait : un retour à la terre, le refus de la société de consommation, la recherche d'un équilibre entre besoins réels et impact écologique. -#### La sobriété heureuse : un modèle pour le numérique -**La sobriété heureuse, selon Rabhi, repose sur trois piliers :** -1. **Refus de la croissance pour la croissance** - *"La croissance infinie dans un monde fini est une absurdité."* -2. **Recherche de l'équilibre entre besoins et impact** - Distinguer les besoins réels des désirs créés artificiellement. -3. **Préservation du sens et de la qualité de vie** - La sobriété n'est pas l'austérité punitive. C'est une joie retrouvée dans la simplicité. -#### Application au numérique -**Le numérique est devenu un secteur extractif :** -- 4% des émissions mondiales de GES (plus que l'aviation) -- Obsolescence programmée des équipements -- Centres de données énergivores -- Surconsommation de bande passante pour du contenu futile -- Accumulation de données jamais consultées -**L'Alliance Boréale applique la sobriété heureuse au numérique :** -**Mesurer** (ce qui n'est pas mesuré ne peut être réduit) : -- Consommation énergétique par service -- Stockage utilisé vs. réellement nécessaire -- Bande passante par type de contenu -**Optimiser** (pour la durabilité, pas la performance maximale) : -- Choisir des serveurs dimensionnés au besoin réel -- Privilégier les solutions frugales (Alpine Linux vs. distributions lourdes) -- Mettre en veille ce qui n'est pas utilisé -**Questionner** (chaque nouveau service, chaque nouvelle feature) : -- Est-ce un besoin réel ou un désir artificiel ? -- Quelle est l'empreinte de cette nouveauté ? -- Existe-t-il une solution plus sobre ? -**Notre engagement :** -Nous documentons notre empreinte numérique (domaine 6 du label) et nous nous engageons à la réduire chaque année, même si cela signifie ralentir notre croissance. -**La sobriété numérique n'est pas un sacrifice. C'est une manière de préserver le plaisir d'utiliser la technologie sans culpabilité écologique.** ---- -### 1.3 Humberto Maturana (1928-2021) — Autopoïèse et Autonomie -#### Le vivant comme modèle organisationnel -Humberto Maturana, biologiste et philosophe chilien, a révolutionné notre compréhension du vivant avec le concept d'**autopoïèse** (du grec *auto* = soi-même, *poiesis* = création). -> *"Un système autopoïétique est un système qui produit les composants qui le constituent."* -> — **L'Arbre de la connaissance** (1987, avec Francisco Varela) -**Un organisme vivant :** -- Produit lui-même ses cellules -- Maintient sa structure malgré les perturbations -- Se régénère continuellement -- N'a pas besoin d'un chef central pour fonctionner -Chaque cellule est autonome, mais toutes coopèrent pour maintenir l'organisme. Il n'y a pas de "cerveau" qui commande aux cellules du foie. C'est un Réseau d'interactions locales qui produit une cohérence globale. -#### L'Alliance comme organisme autopoïétique -**L'Alliance Boréale n'est pas une machine. C'est un organisme vivant.** -**Ce que cela signifie concrètement :** -1. **Nous produisons nos propres composants** - - Nous formons nos nouveaux membres (onboarding) - - Nous documentons notre savoir (wiki, runbooks) - - Nous créons nos propres outils (forge, registraire, banque de temps) - - Nous adaptons notre gouvernance selon nos apprentissages -2. **Nous nous maintenons sans dépendance externe** - - Pas de dépendance à un fondateur unique (même moi, Daniel Allaire, suis remplaçable) - - Pas de dépendance à un fournisseur propriétaire - - Pas de dépendance à une subvention précaire -3. **Nous nous régénérons continuellement** - - Les membres qui partent sont remplacés organiquement - - Les connaissances sont transmises (mentorat, documentation) - - Les cercles de gouvernance se renouvellent par rotation - - Les outils évoluent selon les besoins réels -4. **Nous maintenons notre identité malgré les changements** - - Les 5 valeurs cardinales sont inviolables - - La structure en 8 couches reste stable - - La gouvernance sociocratique s'adapte sans se renier -**Notre engagement :** -Chaque décision doit contribuer à l'autopoïèse de L'Alliance. Nous refusons les solutions qui créent une dépendance ou qui affaiblissent notre capacité d'auto-régénération. -**Nous ne bâtissons pas une startup destinée à être vendue. Nous cultivons un organisme vivant destiné à nous survivre.** ---- -### 1.4 Elinor Ostrom (1933-2012) — La Gestion des Communs -#### Prix Nobel pour avoir démontré l'impossible -En 2009, Elinor Ostrom devient la première femme à recevoir le Prix Nobel d'économie. Son crime ? Avoir démontré empiriquement que **la tragédie des communs n'est pas une fatalité**. -**La tragédie des communs** (Garrett Hardin, 1968) : -Théorie selon laquelle une ressource partagée (pâturage, forêt, océan) sera inévitablement surexploitée, car chaque individu a intérêt à maximiser son usage sans se soucier de l'impact collectif. -**Conclusion de Hardin :** Il faut soit privatiser, soit nationaliser. Pas d'autre choix. -**Ostrom a passé 40 ans à prouver que Hardin avait tort.** -#### Les 8 principes d'Ostrom pour gérer un commun -En étudiant des centaines de communautés gérant durablement des ressources partagées (forêts en Suisse, systèmes d'irrigation au Népal, pêcheries au Japon), Ostrom a identifié **8 principes de design institutionnel** : -1. **Limites clairement définies** - Qui est membre ? Qui ne l'est pas ? Quelle est la ressource partagée ? -2. **Règles adaptées au contexte local** - Pas de one-size-fits-all. Les règles doivent correspondre aux réalités locales. -3. **Participation aux décisions** - Ceux qui sont affectés par les règles doivent pouvoir les modifier. -4. **Surveillance (monitoring)** - Quelqu'un vérifie que les règles sont respectées (peut être les membres eux-mêmes). -5. **Sanctions graduées** - Première infraction = avertissement. Récidive = sanction plus lourde. -6. **Mécanismes de résolution des conflits** - Un système de médiation/arbitrage rapide et peu coûteux. -7. **Reconnaissance du droit à l'auto-organisation** - L'État ou une autorité externe ne doit pas interdire à la communauté de gérer son commun. -8. **Organisations imbriquées (pour les communs larges)** - Plusieurs niveaux de gouvernance (local, régional, fédéral). -#### Application à L'Alliance Boréale -**L'infrastructure numérique de L'Alliance est un commun :** -- DNS fédéré (ressource partagée) -- Forge logicielle (outil mutualisé) -- Banque de temps (pool de contributions) -- Documentation collective (savoir partagé) -**Nous appliquons les 8 principes d'Ostrom :** -| Principe Ostrom | Application Alliance Boréale | -|-----------------|------------------------------| -| **1. Limites claires** | Membres actifs vs. probation vs. non-membres (Registraire YAML) | -| **2. Règles locales** | Proportionnalité (adapter exigences aux moyens de chaque membre) | -| **3. Participation** | Gouvernance sociocratique (tous peuvent proposer, objecter) | -| **4. Surveillance** | Audits pair-à-pair, monitoring partagé | -| **5. Sanctions graduées** | Avertissement → suspension → radiation (processus contradictoire) | -| **6. Résolution conflits** | Médiation par Cercle Éthique, arbitrage si nécessaire | -| **7. Auto-organisation** | Fédération libre, pas d'autorité centrale imposée | -| **8. Niveaux imbriqués** | Cercles (Stratégique > Opérationnel > Éthique), membres locaux | -**Notre engagement :** -Nous gérons l'infrastructure numérique comme un **commun vivant**, pas comme une propriété privée ou un service public centralisé. -Chaque membre contribue selon ses moyens, bénéficie selon ses besoins, et participe aux décisions qui l'affectent. ---- -### 1.5 Le Principe de Subsidiarité — Inspiration Fédéraliste -1–2 : Physique / Réseau -3 : Virtualisation -4 : Orchestration -5 : Supervision (observabilité, monitoring, alerting) -6 : Services (APIs, apps, middlewares) -7 : Gouvernance & données (PKI, IAM, registres, MDM, conformité) -8 : Philosophie (principes, valeurs, doctrine) -**Couches 1-4 (Infrastructure, Réseau, Stockage, Orchestration) :** -- **Décision locale** : Chaque membre choisit son hardware, son hébergeur, ses outils -- **Intervention Alliance** : Uniquement pour l'interopérabilité (DNS, standards) -**Couches 5-6 (Virtualisation, Services) :** -- **Décision locale** : Chaque membre choisit Proxmox, Docker, Kubernetes, ou autre -- **Intervention Alliance** : Aucune, sauf partage de bonnes pratiques (wiki) -**Couches 7-8 (Applications, Philosophie) :** -- **Décision locale** : Chaque membre choisit ses applications, sa communication -- **Intervention Alliance** : Uniquement pour garantir alignement avec les 5 valeurs -**Exemples concrets :** -**Situation 1 : Un membre veut changer de distribution Linux** -→ **Décision 100% locale.** L'Alliance n'intervient pas. Le membre est souverain. -**Situation 2 : Un membre veut déléguer une zone DNS à un autre membre** -→ **Intervention technique Alliance** (documentation, tests, validation), mais décision finale aux deux membres concernés. -**Situation 3 : Un membre veut utiliser un service cloud propriétaire pour son backup** -→ **Pas d'interdiction**, mais questionnement éthique (Cercle Éthique) : *"Cela affaiblit-il ta souveraineté ? Crée-t-il une dépendance ? Existe-t-il une alternative conviviale ?"* -→ **Décision finale au membre**, mais avec accompagnement vers des solutions plus alignées si possible. -**Notre engagement :** -**L'Alliance n'intervient jamais par plaisir de contrôle.** Elle intervient uniquement lorsque : -1. L'interopérabilité est menacée -2. Les valeurs cardinales sont violées -3. Un membre demande explicitement de l'aide -Dans tous les autres cas, **silence respectueux de l'autonomie**. ---- -## 2. POURQUOI "BORÉAL" ? -### 2.1 Le Nord comme Espace de Résilience -**Boréale** vient du latin *borealis*, "du nord". Ce n'est pas un choix anodin. -**Le Nord est un espace de contraintes qui forge la résilience :** -- Hivers longs et rigoureux → adaptation, préparation -- Ressources limitées → sobriété, coopération -- Isolement géographique → autonomie, débrouillardise -- Cycles lents → patience, vision long terme -**Historiquement, les peuples nordiques ont développé des modèles de gouvernance coopératifs :** -- *Thing* islandais (assemblées démocratiques dès le Xe siècle) -- Coopératives scandinaves (mouvement coopératif suédois, finlandais) -- Fédéralisme canadien (autonomie provinciale forte) -**Le Québec, en particulier, incarne cette résilience nordique :** -- Survivance d'une culture francophone minoritaire en Amérique du Nord -- Tradition coopérative forte (Desjardins, coops agricoles) -- Mouvement écologiste pragmatique (pas dogmatique) -**L'Alliance Boréale s'inscrit dans cet héritage :** -Nous ne cherchons pas à conquérir le monde. Nous cherchons à **survivre dignement** dans un écosystème dominé par des géants. Comme les arbres de la forêt boréale, nous savons croître lentement, résister au froid, et partager les ressources pour traverser les tempêtes. ---- -### 2.2 La Métaphore de la Forêt Boréale -**La forêt boréale canadienne** (ou taïga) s'étend sur 6 millions de km² à travers le Canada, l'Alaska, la Scandinavie et la Russie. C'est le plus grand biome terrestre. -**Trois caractéristiques de la forêt boréale inspirent notre projet :** -#### A) Résilience par la diversité -Une forêt boréale n'est jamais composée d'une seule espèce d'arbre. On y trouve : -- Épinettes noires (dominantes) -- Sapins baumiers (sous-bois) -- Bouleaux blancs (colonisateurs après incendie) -- Mélèzes (résistants au froid extrême) -- Mousses, lichens, champignons (infrastructure invisible) -**Chaque espèce a un rôle.** Aucune ne peut monopoliser l'espace. La diversité est la garantie de survie : si une espèce est décimée (parasite, incendie), les autres compensent. -**Dans L'Alliance :** -Nous ne cherchons pas l'uniformité technique. Chaque membre peut utiliser des outils différents (Proxmox, OpenStack, Docker, Kubernetes), tant qu'il respecte les standards d'interopérabilité. La diversité technique est une force, pas une faiblesse. -#### B) Interconnexion par le Réseau mycorhizien -Sous la surface visible, les racines des arbres sont reliées par un **Réseau de champignons mycorhiziens**. Ces champignons : -- Transportent des nutriments entre arbres -- Permettent la communication chimique (signaux d'alerte) -- Redistribuent les ressources des arbres en bonne santé vers ceux en difficulté -- Facilitent la germination des jeunes pousses -**La biologiste Suzanne Simard** (Université de Colombie-Britannique) a documenté ce phénomène dans son livre *Finding the Mother Tree* (2021). Elle a démontré que les "arbres-mères" (les plus vieux et robustes) soutiennent activement les jeunes arbres via le Réseau mycorhizien. -**Dans L'Alliance :** -Le DNS fédéré, le SSO partagé, la banque de temps, les audits pair-à-pair sont notre **Réseau mycorhizien numérique**. Invisibles pour l'utilisateur final, ils permettent : -- L'échange de ressources (support technique, mentorat) -- La communication rapide (Matrix #incidents) -- Le soutien mutuel en cas de crise -**Quand un membre est en difficulté (incident P0), les autres membres envoient de l'aide via le Réseau mycorhizien.** -#### C) Croissance lente, longévité exceptionnelle -Un épinette noire peut vivre 200 ans. Elle grandit lentement : 10-20 cm par an. Mais cette lenteur est sa force : -- Bois dense et résistant -- Racines profondes (résistance aux tempêtes) -- Adaptation fine aux conditions locales -**Contraste avec les espèces à croissance rapide :** -Un peuplier peut pousser de 1 mètre par an, mais il vit seulement 50-80 ans. Son bois est fragile. Ses racines sont superficielles. Il meurt jeune. -**Dans L'Alliance :** -**Nous choisissons la croissance lente.** -Nous ne cherchons pas à recruter 100 membres en 1 an. Nous visons 5-10 membres la première année, 15-20 la deuxième, 25-35 la troisième. -**Pourquoi cette lenteur délibérée ?** -1. **Qualité de l'intégration** : Chaque nouveau membre reçoit un accompagnement de 3 mois (parrain, onboarding) -2. **Préservation de la culture** : Croissance trop rapide = dilution des valeurs -3. **Soutenabilité organisationnelle** : Nous ne voulons pas créer une bureaucratie pour gérer la masse -4. **Test de l'engagement** : Seuls ceux qui acceptent la lenteur restent (auto-sélection) -**Notre horizon n'est pas 2027. C'est 2050. C'est 2100.** ---- -### 2.3 Ancrage Géographique et Culturel -**L'Alliance Boréale est ancrée au Québec et au Canada**, mais notre esprit est universel. -**Pourquoi cet ancrage ?** -1. **Proximité culturelle et linguistique** - Le français comme langue de travail facilite la confiance et la compréhension mutuelle. -2. **Cadre légal favorable** - Loi 25 (protection des données), tradition coopérative, OBNL reconnus et soutenus. -3. **Infrastructures publiques de qualité** - Internet abordable (comparé aux USA), centres de données accessibles (OVH Montréal, etc.). -4. **Sensibilité écologique croissante** - Mouvement pour le climat, conscience environnementale, intérêt pour la sobriété numérique. -**Mais nous ne sommes pas exclusifs.** -Un acteur d'Europe francophone (France, Belgique, Suisse romande) aligné avec nos valeurs serait bienvenu, moyennant adaptation aux fuseaux horaires et réglementations locales. -**Notre identité boréale n'est pas nationaliste. C'est une identité de résilience, de coopération, et de lenteur assumée.** ---- -## 3. SOBRIÉTÉ HEUREUSE APPLIQUÉE AU NUMÉRIQUE -### 3.1 Le Numérique Comme Secteur Extractif -**Le numérique a un problème écologique majeur que l'on ignore souvent :** -**Émissions de GES :** -- 4% des émissions mondiales (équivalent de l'aviation civile) -- Projection : 8% en 2025 si rien ne change -- Sources : centres de données (40%), terminaux (45%), réseaux (15%) -**Consommation de ressources rares :** -- Métaux rares pour les serveurs et smartphones (cobalt, lithium, terres rares) -- Extraction souvent dans des conditions sociales et environnementales catastrophiques -**Obsolescence programmée :** -- Durée de vie moyenne d'un smartphone : 2-3 ans -- Durée de vie d'un serveur : 5-7 ans (alors qu'il pourrait durer 15 ans) -- 50 millions de tonnes de déchets électroniques par an (seulement 20% recyclés) -**Paradoxe de Jevons :** -Plus on optimise un système (serveurs plus efficaces), plus on l'utilise (effet rebond). Résultat : consommation totale augmente malgré les gains d'efficacité. -**Le mythe du "cloud vert" :** -Oui, certains centres de données utilisent de l'énergie renouvelable. Mais : -1. L'énergie la plus verte est celle qu'on ne consomme pas -2. La fabrication du matériel représente 50-80% de l'empreinte carbone totale -3. Le cloud encourage la surconsommation de stockage et de calcul -**L'Alliance Boréale refuse ce modèle extractif.** ---- -### 3.2 Refuser la Croissance pour la Croissance -**Le dogme de la croissance :** -Dans le numérique mainstream, tout doit croître exponentiellement : -- Nombre d'utilisateurs -- Volumes de données stockées -- Puissance de calcul -- Bande passante consommée -- Valorisation des entreprises -**Ce dogme est insoutenable.** -Il repose sur l'illusion d'un monde aux ressources infinies. Mais : -- Les métaux rares sont finis -- L'énergie (même renouvelable) est limitée -- Les capacités d'absorption des déchets sont finies -**Dans L'Alliance, nous posons systématiquement la question :** -> *"Avons-nous vraiment besoin de croître, ou cherchons-nous à croître par mimétisme ?"* -**Exemples concrets :** -**Scénario 1 : Doublement du nombre de membres en 6 mois** -→ **Red flag.** Croissance trop rapide = risque de : -- Dilution des valeurs (nouveaux membres mal onboardés) -- Surcharge du Cercle Opérationnel -- Infrastructure surdimensionnée trop vite -→ **Action :** Ralentir volontairement les admissions. Préférer 10 membres bien intégrés à 30 membres fantômes. -**Scénario 2 : Demande d'augmenter massivement le stockage disponible** -→ **Question :** Pourquoi ? Quelles données stocke-t-on ? Quelle est leur durée de vie utile ? -→ **Action possible :** Politique de rétention (suppression automatique des données non consultées depuis X mois). -**Scénario 3 : Proposition de créer une nouvelle application "pour faire comme les autres"** -→ **Question :** Quel besoin réel cela résout-il ? Existe-t-il une solution sobre déjà disponible ? -→ **Action possible :** Refuser la feature si elle n'apporte que du "nice-to-have". -**Notre engagement :** -Nous mesurons notre succès non pas au nombre de membres ou au chiffre d'affaires, mais à : -- La **qualité** de la coopération entre membres -- La **longévité** de L'Alliance (capacité à traverser les crises) -- La **transmission** réussie du savoir aux nouvelles générations -- La **réduction** mesurable de notre empreinte numérique ---- -### 3.3 Optimiser pour la Durabilité, Pas la Performance Maximale -**Le piège de la performance :** -Dans le numérique, on optimise systématiquement pour : -- La vitesse (millisecondes de latence) -- La disponibilité (99,99% uptime) -- Le débit (Gbps de bande passante) -**Mais optimiser uniquement pour la performance a un coût :** -- Serveurs surdimensionnés qui tournent à 10% de capacité -- Redondance excessive (6 copies d'une donnée "au cas où") -- Refresh constant des équipements (peur de l'obsolescence) -**L'Alliance propose un paradigme différent : optimiser pour la durabilité.** -**Qu'est-ce que ça signifie ?** -**1. Dimensionner au besoin réel, pas au pic théorique** -**Mainstream :** -"Notre site doit supporter 10 000 visiteurs simultanés." -→ Infrastructure dimensionnée pour ce pic, qui arrive 2 fois par an. -→ 98% du temps, serveurs à 5% de charge. -**Approche sobre :** -"Notre site a en moyenne 200 visiteurs simultanés, avec des pics à 1 000." -→ Infrastructure dimensionnée pour 1 500 (marge confortable). -→ Si pic exceptionnel > 1 500 : dégradation gracieuse (ex: file d'attente) plutôt que surdimensionnement permanent. -**2. Accepter des disponibilités "bonnes" plutôt qu'"excellentes"** -**Mainstream :** -99,99% uptime = 52 minutes de panne par an autorisées. -→ Coût : infrastructure hyperredondante, surveillance 24/7, équipes on-call. -**Approche sobre :** -99,5% uptime = 44 heures de panne par an autorisées. -→ Acceptable pour la plupart des usages (sauf urgences médicales ou Services critiques). -→ Économie massive d'énergie et de ressources. -**3. Allonger la durée de vie du matériel** -**Mainstream :** -Serveurs remplacés tous les 3-5 ans (pour "rester à jour"). -**Approche sobre :** -Serveurs utilisés 8-12 ans si fonctionnels. -→ Critère de remplacement : **panne irréparable**, pas obsolescence artificielle. -**4. Éteindre ce qui n'est pas utilisé** -**Mainstream :** -Serveurs allumés 24/7, même si utilisés seulement 8h/jour. -**Approche sobre :** -- Services non critiques : mise en veille automatique (wake-on-LAN) -- Sauvegardes : uniquement la nuit (pas en continu) -- Environnements de test : éteints le weekend -**Notre engagement :** -Nous publions nos métriques de sobriété (domaine 6 du label) et nous nous engageons à les améliorer chaque année, même si cela signifie accepter des compromis sur la performance. ---- -### 3.4 La Technologie au Service de l'Humain -**Le dogme techno-solutionniste :** -"Chaque problème humain a une solution technologique." -**Ce dogme est dangereux.** -Il nous fait oublier que : -1. Certains problèmes n'ont pas de solution technique (ex: solitude, perte de sens) -2. La technologie crée souvent de nouveaux problèmes (ex: surveillance, addiction) -3. La meilleure solution est parfois... de ne rien faire -**Dans L'Alliance, nous inversons la logique :** -**La technologie doit être au service de l'humain, pas l'inverse.** -**Concrètement :** -**Question 1 : "Devrions-nous automatiser cette tâche ?"** -**Réflexion :** -- Cette tâche apporte-t-elle du sens à celui qui la fait ? -- L'automatisation crée-t-elle une dépendance ? -- Que perdons-nous en automatisant ? -**Exemple :** -Automatiser complètement la génération de documentation → risque de documentation obsolète, non maintenue, que personne ne lit. -Mieux : semi-automatisation (squelette généré, contenu rédigé par humains). -**Question 2 : "Devrions-nous adopter cette nouvelle technologie ?"** -**Réflexion :** -- Quel problème réel résout-elle ? -- Quel est son coût d'apprentissage ? -- Crée-t-elle une dépendance à un fournisseur/écosystème ? -**Exemple :** -Adopter Kubernetes pour un cluster de 3 serveurs → overkill. Complexité disproportionnée. -Mieux : LXC containers + scripts Ansible. Plus sobre, plus compréhensible. -**Question 3 : "Devrions-nous mesurer cette métrique ?"** -**Réflexion :** -- Cette métrique change-t-elle nos décisions ? -- Ou nous donne-t-elle juste l'illusion de contrôle ? -**Exemple :** -Mesurer le nombre de lignes de code écrites par développeur → métrique toxique (encourage quantité sur qualité). -Mieux : mesurer le nombre de bugs critiques résolus, ou la satisfaction des pairs. -**Notre engagement :** -Avant chaque décision technique, nous posons la question : **"Cela sert-il l'humain, ou l'humain sert-il la technologie ?"** -Si la réponse n'est pas claire, nous prenons le temps de réfléchir. **La lenteur est une vertu.** ---- -## 4. AUTOPOÏÈSE ORGANISATIONNELLE -### 4.1 Un Système qui se Maintient et se Régénère Lui-Même -**Objectif ultime de L'Alliance :** -Devenir un **organisme autopoïétique** capable de survivre et de prospérer au-delà de ses fondateurs. -**Qu'est-ce que cela signifie concrètement ?** -#### Test de l'autopoïèse (questions à se poser) -**1. Si les fondateurs disparaissaient demain, L'Alliance survivrait-elle ?** -Aujourd'hui (2025) : **Non.** Nous sommes trop dépendants de Daniel Allaire et des membres fondateurs. -En 2027 (objectif) : **Oui.** -- Documentation complète et maintenue -- Cercles de gouvernance avec rotation des rôles -- Nouveaux membres formés et autonomes -- Processus d'onboarding éprouvé -- Culture transmise et intégrée -**2. L'Alliance produit-elle ses propres "cellules" (nouveaux membres) ?** -Oui, via : -- Processus d'onboarding structuré (3 mois) -- Parrainage (transmission peer-to-peer) -- Documentation évolutive (wiki, runbooks) -- Formation continue (ateliers, mentorat) -**3. L'Alliance adapte-t-elle ses "organes" (structures) selon les besoins ?** -Oui, via : -- Révision annuelle de la Charte et du Règlement -- Rotation des cercles (pas de fossilisation) -- Processus d'amendement léger (pas de bureaucratie paralysante) -- Retours d'expérience systématiques (post-mortems) -**4. L'Alliance préserve-t-elle son "identité" (valeurs) malgré les changements ?** -Oui, car : -- Les 5 valeurs cardinales sont **inviolables** (non amendables) -- Tout nouveau membre doit démontrer son alignement -- Le label garantit la conformité continue -- Le Cercle Éthique veille à la cohérence ---- -### 4.2 Transmission du Savoir comme Mécanisme de Perpétuation -**Le savoir est la sève de l'organisme.** -Sans transmission, l'organisme s'atrophie et meurt. -**Dans L'Alliance, nous investissons massivement dans la transmission :** -#### A) Documentation vivante -**Principe :** La documentation n'est jamais "terminée". Elle évolue avec l'organisation. -**Nos outils :** -- **Wiki collaboratif** : Procédures, guides, retours d'expérience -- **Registraire YAML** : Source de vérité versionnée (Git) -- **Runbooks** : Procédures opérationnelles pas-à-pas -- **Post-mortems** : Analyses d'incidents partagées publiquement -**Obligation :** Chaque nouveau membre doit contribuer à la documentation (améliorer une page wiki, rédiger un runbook, documenter un incident). -**Pourquoi ?** -1. Apprendre en enseignant (meilleure rétention) -2. Vérifier la qualité de la doc existante (feedback immédiat) -3. Créer un sentiment d'appartenance (contribution valorisée) -#### B) Mentorat structuré -**Principe :** Chaque nouveau membre est accompagné par un parrain durant 3 mois. -**Rôle du parrain :** -- Répondre aux questions techniques -- Faciliter l'intégration dans la communauté (Matrix, événements) -- Évaluer la progression -- Rédiger le rapport d'évaluation final -**Rôle du filleul :** -- Poser des questions (aucune question n'est stupide) -- Contribuer activement (pas observateur passif) -- Documenter son apprentissage (journal de bord) -- Devenir parrain à son tour (dans 6-12 mois) -**Résultat :** Chaîne de transmission continue. Chaque génération forme la suivante. -#### C) Formation continue -**Principe :** L'apprentissage ne s'arrête jamais. -**Formats :** -- **Ateliers mensuels** : Sujet technique ou gouvernance (2h, virtuel) -- **Rencontres annuelles** : Présentiel, 2 jours (partage, retrospective, planification) -- **Lunch & Learn** : Présentation courte d'un membre (30 min, informel) -- **Veilles partagées** : Bulletin mensuel (vulnérabilités, nouvelles technos, inspirations) -**Utilisation de la banque de temps :** -Animer un atelier = crédits. -Participer = neutre (pas de débit). -→ Incitation à partager son savoir. ---- -### 4.3 Gouvernance Adaptative -**Un organisme vivant adapte sa structure selon son environnement.** -**Dans L'Alliance :** -#### Révision annuelle obligatoire -Chaque année, lors de l'assemblée générale : -1. **Bilan de l'année** (ce qui a marché, ce qui n'a pas marché) -2. **Révision des documents** (Charte, Règlement, politiques) -3. **Ajustements** (processus, outils, gouvernance) -4. **Planification** (objectifs année suivante) -**Rien n'est figé.** Tout peut être questionné (sauf les 5 valeurs cardinales). -#### Rotation des rôles -**Principe :** Pas de mandat à vie. Rotation obligatoire pour éviter la fossilisation. -**Durées :** -- Cercle Stratégique : 12 mois renouvelable -- Cercle Opérationnel : 6 mois, rotation -- Cercle Éthique : 24 mois, mandats non consécutifs -**Avantages :** -1. Prévenir l'accaparement du pouvoir -2. Former plusieurs personnes (résilience) -3. Apporter des perspectives nouvelles -4. Éviter l'épuisement (burnout) -#### Processus d'amendement léger -**Mainstream :** Modifier les statuts = lourdeur administrative, votes formels, délais de 6-12 mois. -**Alliance Boréale :** -- Proposition d'amendement : n'importe quel membre actif -- Discussion publique : 14-30 jours (selon ampleur) -- Décision : consentement du Cercle Stratégique -- Entrée en vigueur : immédiate (ou différée si justifié) -**Pourquoi cette légèreté ?** -Nous préférons une organisation qui évolue vite et bien, plutôt qu'une organisation figée par peur du changement. -**Garde-fou :** Les 5 valeurs cardinales ne peuvent être amendées (protection de l'identité). ---- -## 5. SOUVERAINETÉ SANS ISOLEMENT -### 5.1 Autonomie Locale ET Coopération Fédérée -**Le piège de la souveraineté absolue :** -"Je contrôle tout seul mon infrastructure, mes données, mes choix." -→ Résultat : **isolement**, **vulnérabilité**, **inefficacité**. -**Le piège de la centralisation :** -"Tout est centralisé pour mutualiser les coûts." -→ Résultat : **dépendance**, **single point of failure**, **perte de contrôle**. -**L'Alliance propose une troisième voie : la fédération.** -**Fédération = Autonomie locale + Coopération selon standards communs** -**Exemples :** -**Fédération DNS :** -- Chaque membre opère ses propres serveurs DNS (autonomie) -- Les serveurs se répliquent mutuellement via AXFR (coopération) -- Résultat : résilience sans dépendance à un serveur central -**Fédération d'identités (SSO) :** -- Chaque membre opère son propre serveur d'identités (Keycloak, Authelia) -- Les serveurs font confiance mutuellement via OpenID/SAML (coopération) -- Résultat : un utilisateur du membre A peut s'authentifier sur les Services du membre B, sans que ses données transitent par un tiers -**Fédération de monitoring :** -- Chaque membre opère son propre Prometheus/Grafana (autonomie) -- Export de métriques agrégées vers tableau de bord partagé (coopération) -- Résultat : visibilité collective sans surveillance intrusive -**Le principe :** -**"Ce qui peut être local reste local. Ce qui doit être partagé est partagé selon des standards ouverts."** ---- -### 5.2 Refus de la Dépendance aux GAFAM -**GAFAM = Google, Apple, Facebook/Meta, Amazon, Microsoft** -**Le problème des GAFAM :** -1. **Centralisation** - Toutes les données affluent vers quelques serveurs aux USA. -2. **Surveillance de masse** - Modèle économique basé sur l'extraction de données personnelles. -3. **Lock-in technologique** - Protocoles propriétaires, APIs changeantes, écosystèmes fermés. -4. **Obsolescence forcée** - Abandon de Services sans préavis (Google graveyard). -5. **Influence politique démesurée** - Lobbying, capture réglementaire, impunité fiscale. -**Position de L'Alliance :** -**Nous ne diabolisons pas les GAFAM** (ils ont créé des outils utiles), **mais nous refusons la dépendance structurelle.** -**Nos règles :** -**❌ Interdit dans l'infrastructure critique :** -- Gmail pour les emails professionnels -- Google Drive pour documents internes -- AWS pour hébergement des Services de production -- Microsoft 365 pour collaboration interne -**⚠️ Toléré avec justification (et plan de sortie) :** -- Google Workspace pour communication externe (si clients l'exigent) -- AWS pour Services spécifiques impossibles à reproduire localement (ex: ML très spécialisé) -**✅ Encouragé :** -- Standards ouverts (SMTP, IMAP, CalDAV, WebDAV) -- Logiciels libres (Nextcloud, Matrix, Jitsi) -- Hébergement souverain (Canada, Europe) -**Notre engagement :** -Chaque membre doit documenter ses dépendances aux GAFAM (inventaire annuel) et présenter un plan de réduction progressive. -**Objectif 2027 :** Zéro dépendance GAFAM pour les Services critiques de tous les membres actifs. ---- -### 5.3 Interopérabilité comme Vecteur de Liberté -**Le lock-in technologique est une prison dorée.** -Exemples : -- **Email propriétaire** : Si vous utilisez un système email propriétaire, vos contacts doivent utiliser le même système. -- **Messagerie fermée** : WhatsApp ne parle qu'à WhatsApp. Signal ne parle qu'à Signal. -- **Formats propriétaires** : .docx (Microsoft), .pages (Apple), .psd (Adobe) → dépendance au logiciel. -**L'interopérabilité brise ces prisons.** -**Standards ouverts = liberté de choisir, de partir, de revenir.** -**Dans L'Alliance :** -**Email :** SMTP, IMAP, DKIM, SPF, DMARC -→ Un utilisateur peut changer de fournisseur email sans perdre ses contacts. -**Fichiers :** WebDAV, CalDAV, CardDAV -→ Un utilisateur peut synchroniser ses fichiers/calendriers sur n'importe quel client compatible. -**Messagerie :** Matrix (protocole fédéré) -→ Un utilisateur du serveur A peut parler à un utilisateur du serveur B, sans compte sur B. -**Visio :** Jitsi (WebRTC), SIP -→ Pas de lock-in à Zoom ou Teams. -**Identités :** OpenID Connect, SAML -→ Un utilisateur peut utiliser son identité du membre A pour accéder aux Services du membre B. -**Avantage stratégique de l'interopérabilité :** -1. **Réversibilité** : Si un membre quitte L'Alliance, ses utilisateurs ne perdent rien (emails, fichiers, contacts). -2. **Compétition saine** : Les membres peuvent se comparer sur la qualité de service, pas sur le lock-in. -3. **Résilience** : Si un membre tombe en panne, les autres peuvent temporairement prendre le relais (DNS secondaire, relais email). -**Notre engagement :** -L'interopérabilité est un des 6 domaines du label. Un membre qui ne respecte pas les standards ouverts ne peut obtenir le label Or ou Platine. ---- -### 5.4 Solidarité entre Pairs -**L'autonomie ne signifie pas l'individualisme.** -**Dans L'Alliance, la solidarité est structurelle :** -#### Banque de temps -1 heure de ton temps = 1 heure de mon temps, quelle que soit la compétence. -**Exemples d'échanges :** -- Membre A aide membre B à configurer DNSSEC (2h) → +2 crédits pour A -- Membre B rédige une documentation pour le wiki (3h) → +3 crédits pour B -- Membre C demande aide pour incident DNS (1h de A) → -1 crédit pour C, +1 pour A -**Philosophie :** Toutes les contributions ont la même valeur. Le temps d'un sysadmin ne vaut pas plus que le temps d'un rédacteur technique. -#### Support technique peer-to-peer -**Canal Matrix #support :** Questions techniques, partage de solutions, entraide. -**Engagement implicite :** Si je peux aider, j'aide. Pas d'obligation formelle, mais attente culturelle forte. -**Résultat observé :** Temps de réponse moyen < 2h pour questions techniques (phase pilote). -#### Partage des post-mortems -**Obligation :** Tout incident P0/P1 doit donner lieu à un post-mortem partagé (anonymisé si nécessaire pour sécurité). -**Pourquoi ?** -Apprendre des erreurs des autres. Éviter de répéter les mêmes erreurs. -**Culture sans blâme :** Le post-mortem n'est pas une enquête judiciaire. C'est un outil d'apprentissage collectif. -#### Mutualisation des achats (optionnel) -**Idée en exploration :** -Négocier collectivement avec fournisseurs (hardware, licences, bande passante) pour obtenir de meilleurs tarifs. -**Contrainte :** Ne pas créer de dépendance. Chaque membre reste libre d'acheter seul s'il préfère. ---- -## 6. TRANSPARENCE UTILE VS TRANSPARENCE RADICALE -### 6.1 Le Mythe de la Transparence Totale -**Idéal militant :** "Publier tout, tout le temps, pour garantir la confiance." -**Problème :** La transparence radicale crée plus de problèmes qu'elle n'en résout : -1. **Surcharge informationnelle** - Trop d'informations = aucune information utile (signal noyé dans le bruit). -2. **Exposition de vulnérabilités** - Publier les détails de configuration de sécurité = cadeau pour les attaquants. -3. **Paralysie décisionnelle** - Toute décision publique = risque de débat infini, trolling, manipulation. -4. **Perte d'intimité organisationnelle** - Une organisation a besoin d'espaces de réflexion interne (comme un individu a besoin de vie privée). -**Exemples d'excès de transparence :** -**Cas 1 : Entreprise qui publie tous ses emails internes en temps réel** -→ Résultat : plus personne n'ose écrire franchement. Communication aseptisée. Décisions prises en coulisse. -**Cas 2 : Projet open source qui publie toutes ses failles de sécurité immédiatement** -→ Résultat : exploitation avant correctif. Mise en danger des utilisateurs. -**Cas 3 : Organisation qui filme toutes ses réunions et les publie** -→ Résultat : comportements performatifs. Plus de débat authentique. ---- -### 6.2 La Transparence Utile : Publier ce qui Compte -**Principe de L'Alliance :** -**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.** -**Qu'est-ce qui DOIT être public ?** -✅ **Gouvernance :** -- Décisions des cercles (résumés, pas transcriptions complètes) -- Composition des cercles (qui occupe quel rôle) -- Processus de décision (comment on décide) -- Amendements à la Charte et au Règlement -✅ **Label et conformité :** -- Scores de label (par domaine, par membre) -- Rapports d'audit (synthèse, pas détails techniques) -- Non-conformités majeures et plans d'action -✅ **Incidents majeurs :** -- Post-mortems d'incidents P0/P1 (timeline, causes, actions) -- Statistiques de disponibilité (agrégées) -✅ **Finances :** -- Bilans annuels (revenus, dépenses, réserves) -- Utilisation des fonds (catégories de dépenses) -✅ **Membership :** -- Liste des membres actifs (noms, URLs publiques) -- Membres en probation (si consentement) -- Processus d'admission -**Qu'est-ce qui reste PRIVÉ ?** -🔒 **Sécurité :** -- Configurations de pare-feu, ACL, VPN -- Détails de vulnérabilités non corrigées -- Mots de passe, clés API, certificats privés -- Architecture interne détaillée (topologie Réseau) -🔒 **Intimité organisationnelle :** -- Échanges Matrix privés entre membres -- Brouillons de décisions en cours de discussion -- Évaluations individuelles (probation, audits) -- Conflits interpersonnels en médiation -🔒 **Secrets commerciaux légitimes :** -- Tarifs négociés avec fournisseurs -- Contrats avec partenaires (si clause de confidentialité) -- Innovations techniques en cours de développement (avant publication) ---- -### 6.3 Équilibre Pragmatique -**La transparence est un moyen, pas une fin.** -**Objectif :** Permettre aux membres et au public de **vérifier que L'Alliance respecte ses engagements**, sans compromettre la sécurité ou l'intimité. -**Mécanisme de décision :** -Lorsqu'une information pourrait être rendue publique, on pose 3 questions : -1. **Cette information renforce-t-elle la confiance ?** - Si oui → publier. Si non → garder privée. -2. **Cette information crée-t-elle un risque de sécurité ?** - Si oui → garder privée. Si non → publier. -3. **Cette information est-elle demandée explicitement par un membre ou le public ?** - Si oui → évaluer cas par cas (Cercle Éthique). Si non → défaut = privé. -**Révision annuelle :** -Chaque année, le Cercle Éthique révise la politique de transparence et peut décider de publier davantage d'informations si la maturité de L'Alliance le permet. ---- -## 7. LA FORÊT, PAS L'EMPIRE -### 7.1 Croissance Organique vs Expansion Aggressive -**Deux modèles de développement :** -#### Modèle impérial (mainstream) -**Caractéristiques :** -- Croissance exponentielle visée (doubler chaque année) -- Expansion géographique rapide (conquérir de nouveaux marchés) -- Standardisation forcée (tous les membres doivent utiliser les mêmes outils) -- Centralisation du pouvoir (siège décide pour les filiales) -- Valorisation maximisée pour exit (acquisition ou IPO) -**Avantages apparents :** -- Économies d'échelle -- Pouvoir de négociation accru -- Visibilité médiatique -**Coûts cachés :** -- Dilution de la culture et des valeurs -- Bureaucratie croissante pour gérer la masse -- Dépendance aux investisseurs (perte d'autonomie) -- Fragilité systémique (too big to fail) -**Exemples historiques :** -- Empires coloniaux (expansion rapide, effondrement brutal) -- Startups hyper-croissance (licornes devenues zombies) -- Franchises géantes (uniformisation, perte d'identité locale) -#### Modèle forestier (L'Alliance Boréale) -**Caractéristiques :** -- Croissance lente et soutenue (10-20% par an) -- Enracinement local avant expansion -- Diversité encouragée (chaque arbre à sa forme) -- Pouvoir décentralisé (chaque arbre autonome) -- Pérennité privilégiée sur valorisation -**Avantages :** -- Résilience (pas de single point of failure) -- Qualité des liens (chaque membre connaît les autres) -- Culture préservée (onboarding soigné) -- Adaptation fine au contexte local -**Coûts assumés :** -- Croissance plus lente -- Moins de "buzz" médiatique -- Pas d'économies d'échelle massives -**Exemples inspirants :** -- Coopératives Mondragón (Espagne) : 70 ans, 80 000 travailleurs, croissance organique -- Mouvement Desjardins (Québec) : 120 ans, toujours coopératif -- Linux : 30 ans, aucun propriétaire, modèle décentralisé ---- -### 7.2 Diversité des Acteurs comme Force -**Dans une monoculture (plantation industrielle) :** -- Tous les arbres de la même espèce -- Même âge, même taille -- Vulnérables aux mêmes parasites -- Si un arbre tombe malade, tous tombent malades -**Dans une forêt naturelle :** -- Dizaines d'espèces différentes -- Âges variés (jeunes pousses, arbres matures, vétérans) -- Résistance croisée (un parasite d'épinette n'affecte pas les bouleaux) -- Si un arbre meurt, les autres compensent -**Dans L'Alliance Boréale :** -**Nous encourageons la diversité :** -**Diversité de taille :** -- Petites structures (<5 personnes) : agilité, innovation -- Moyennes structures (5-20 personnes) : équilibre stabilité/innovation -- Grandes structures (>20 personnes) : ressources, expertise approfondie -**Diversité de modèle économique :** -- OBNL : mission sociale, pas de profit -- Coopératives : propriété collective, gouvernance démocratique -- Entreprises à mission : profit avec impact social -**Diversité technique :** -- Infrastructure : Proxmox, OpenStack, bare metal -- Virtualisation : LXC, Docker, KVM -- Automatisation : Ansible, Terraform, scripts shell -**Diversité sectorielle :** -- Hébergement web classique -- Services collaboratifs (Nextcloud, etc.) -- Développement logiciel sur mesure -- Formation et consulting -**Pourquoi cette diversité est une force ?** -1. **Résilience** : Si un type d'acteur est en crise (ex: OBNL perdant des subventions), les autres compensent. -2. **Innovation** : La diversité technique force à maintenir des standards ouverts (pas de solution unique imposée). -3. **Apprentissage** : Chaque membre apprend des autres (OBNL apprennent des coops, et vice-versa). -4. **Attractivité** : Différents profils trouvent leur place (pas de one-size-fits-all). -**Notre engagement :** -Nous ne cherchons PAS à uniformiser les membres. Nous célébrons leurs différences, tant qu'ils respectent les 5 valeurs cardinales et les standards d'interopérabilité. ---- -### 7.3 Résilience par la Décentralisation -**Centralisation = efficacité à court terme, fragilité à long terme.** -**Exemples :** -**Système bancaire centralisé :** -- Efficace en temps normal (transactions rapides, coûts faibles) -- Fragile en temps de crise (faillite d'une banque → effet domino) -**Énergie centralisée (centrale nucléaire) :** -- Efficace (production massive) -- Fragile (panne → blackout régional) -**Internet centralisé (GAFAM) :** -- Pratique (tout au même endroit) -- Fragile (panne AWS → des milliers de sites down) -**Décentralisation = inefficacité apparente, résilience réelle.** -**Dans L'Alliance Boréale :** -**DNS fédéré :** -- Chaque membre = serveur DNS autoritaire -- Réplication mutuelle via AXFR -- Si un serveur tombe, les autres répondent (pas de single point of failure) -**Identités fédérées :** -- Chaque membre = serveur d'identités (Keycloak) -- Trust mutuel via OpenID/SAML -- Si un serveur tombe, seuls ses utilisateurs directs sont affectés (pas de cascade) -**Monitoring distribué :** -- Chaque membre surveille ses propres Services -- Métriques agrégées pour visibilité collective -- Pas de dépendance à un monitoring central (qui pourrait tomber) -**Gouvernance distribuée :** -- Pas de PDG unique -- Trois cercles avec mandats limités -- Décisions par consentement (pas de dictature de la majorité) -**Résultat :** -L'Alliance peut perdre un ou plusieurs membres (départ, panne, faillite) sans effondrement global. C'est la définition même de la résilience. ---- -### 7.4 Longévité Plutôt que Vitesse -**Mainstream tech :** -- "Move fast and break things" (Facebook/Meta) -- "Blitzscaling" (croissance à tout prix) -- "Fail fast" (échouer vite pour réussir vite) -**Ces mantras glorifient la vitesse au détriment de tout le reste.** -**Résultat :** -- Burnout généralisé -- Dette technique insoutenable -- Entreprises qui explosent (faillites de startups) -- Impact écologique et social ignoré -**L'Alliance Boréale choisit la lenteur.** -**Notre mantra : "Move slow and build things that last."** -**Concrètement :** -**Phase pilote : 1 an (2025)** -Objectif : Prouver le concept, ajuster les processus. -Pas de rush. Mieux vaut bien faire avec 3 membres que mal faire avec 10. -**Constitution en OBNL : 2026** -Pas de précipitation. Nous prenons le temps de comprendre les implications légales, fiscales, administratives. -**Soutenabilité financière : 2027** -Horizon de 3 ans pour atteindre l'équilibre. C'est long, mais c'est réaliste. -**Maturité organisationnelle : 2030+** -Nous ne visons pas à "disrupter" le marché en 2 ans. Nous visons à être encore là dans 10 ans, 20 ans, 50 ans. -**Pourquoi cette lenteur est une force ?** -1. **Qualité** : Le temps permet de bien faire les choses (documentation, formation, gouvernance). -2. **Transmission** : Les nouveaux membres ont le temps d'apprendre et d'intégrer la culture. -3. **Réflexion** : On évite les décisions impulsives qu'on regretterait. -4. **Soutenabilité** : Pas de burnout. Les gens restent longtemps (stabilité). -**Notre engagement :** -Nous évaluons nos décisions à l'horizon de 10 ans, pas de 1 trimestre. Si une action accélère la croissance mais affaiblit la longévité, nous la rejetons. ---- -## 8. NOS ENGAGEMENTS POUR LES GÉNÉRATIONS FUTURES -### 8.1 Laisser un Système Transmissible -**Question fondamentale :** -> *"Si nous disparaissions demain, quelqu'un pourrait-il reprendre L'Alliance et la faire vivre ?"* -**Aujourd'hui (2025) :** Non, trop dépendants des fondateurs. -**Objectif (2027-2030) :** Oui, grâce à : -#### Documentation exhaustive -- **Charte et documents constitutifs** : Pourquoi nous existons, nos valeurs. -- **Règlement de régie interne** : Comment nous fonctionnons, qui fait quoi. -- **Procédures opérationnelles** : Comment gérer DNS, incidents, onboarding. -- **Runbooks techniques** : Pas-à-pas pour les tâches critiques. -- **Post-mortems** : Leçons apprises de nos erreurs. -#### Systèmes autopoïétiques -- **Onboarding structuré** : Formation des nouveaux membres (reproductible). -- **Rotation des rôles** : Pas de dépendance à une personne unique. -- **Banque de temps** : Incitation à contribuer et former. -- **Cercles autonomes** : Pas besoin d'un "chef" pour fonctionner. -#### Culture vivante -- **Valeurs explicites** : Les 5 valeurs cardinales, non négociables. -- **Récits fondateurs** : Pourquoi et comment L'Alliance est née (ce manifeste). -- **Rituels** : Rencontre annuelle, révision de la Charte, ateliers mensuels. -- **Transmission orale** : Histoires partagées lors des événements. -**Notre engagement :** -Chaque décision importante sera documentée. Chaque processus critique aura un runbook. Chaque rôle aura un successeur potentiel formé. -**Nous ne bâtissons pas pour nous. Nous bâtissons pour ceux qui viendront après nous.** ---- -### 8.2 Former Plutôt que Vendre -**Modèle mainstream :** -- Vendre des Services clé en main -- Client dépendant du fournisseur -- Connaissance gardée secrète (avantage compétitif) -- Renouvellement des contrats garanti par la dépendance -**Modèle de L'Alliance :** -- Former les membres et leurs utilisateurs -- Autonomie progressive des utilisateurs -- Connaissance partagée (documentation publique) -- Renouvellement basé sur la confiance, pas la dépendance -**Concrètement :** -**Pour les membres :** -- **Ateliers mensuels** : Montée en compétences technique et gouvernance. -- **Mentorat structuré** : Chaque nouveau membre a un parrain. -- **Documentation collaborative** : On apprend en documentant. -**Pour les utilisateurs finaux (clients de nos membres) :** -- **Guides d'utilisation** : Nextcloud, email sécurisé, bonnes pratiques. -- **Ateliers publics** : Sensibilisation à la souveraineté numérique. -- **Support communautaire** : Forums, FAQ, vidéos tutoriels. -**Philosophie sous-jacente :** -**Si nos utilisateurs deviennent autonomes, ils n'ont plus besoin de nous ?** -→ **Faux.** Ils auront toujours besoin d'infrastructure, de maintenance, de support. Mais la relation sera basée sur la confiance et la compétence, pas la dépendance. -**Former les gens les rend libres de partir ?** -→ **Vrai. Et c'est une bonne chose.** Nous ne voulons pas de clients captifs. Nous voulons des partenaires éclairés qui choisissent de rester parce qu'ils partagent nos valeurs. -**Notre engagement :** -Chaque membre doit consacrer au moins 10% de son temps à la formation (interne ou externe). Utilisation de la banque de temps pour valoriser ces efforts. ---- -### 8.3 Documenter pour Permettre la Relève -**La documentation est l'acte de transmission par excellence.** -**Sans documentation :** -- Connaissances dans les têtes (vulnérabilité) -- Nouveaux arrivants perdus (barrière à l'entrée) -- Erreurs répétées (pas d'apprentissage collectif) -- Dépendance aux "experts" (goulets d'étranglement) -**Avec documentation :** -- Connaissances accessibles (résilience) -- Onboarding fluide (nouveaux membres autonomes rapidement) -- Erreurs documentées (on n'apprend qu'une fois) -- Expertise distribuée (plusieurs personnes peuvent faire la même chose) -**Nos engagements documentaires :** -#### 1. Chaque processus critique a un runbook -**Exemples :** -- Ajouter un nouveau membre (checklist complète) -- Répondre à un incident DNS P0 (étapes, contacts, escalade) -- Renouveler les certificats SSL (procédure, fréquence, tests) -- Réaliser un audit de label (grille, preuves, rapport) -#### 2. Chaque incident majeur a un post-mortem -**Structure obligatoire :** -- Timeline factuelle (ce qui s'est passé, quand) -- Causes racines (pourquoi c'est arrivé) -- Actions correctives (ce qu'on a fait pour réparer) -- Actions préventives (ce qu'on met en place pour que ça ne se reproduise pas) -#### 3. Chaque outil commun a une documentation -**Forge, Registraire, Banque de temps, Matrix :** -- Guide d'utilisation pour débutant -- Référence complète pour utilisateur avancé -- Guide de contribution (comment améliorer l'outil) -- Architecture technique (pour maintenance) -#### 4. La documentation est vivante -**Révision continue :** -- Chaque membre qui détecte une erreur ou une obsolescence la corrige (ou signale) -- Wiki avec historique (Git) : on peut voir qui a changé quoi et pourquoi -- Page "dernières mises à jour" : visibilité sur ce qui évolue -**Notre engagement :** -Nous mesurons la qualité de notre documentation (domaine Opérations du label). Une documentation obsolète ou inexistante est une non-conformité. ---- -### 8.4 Refuser l'Obsolescence Programmée -**Obsolescence programmée = stratégie consistant à réduire délibérément la durée de vie d'un produit pour forcer le renouvellement.** -**Dans le numérique :** -**Hardware :** -- Smartphones qui ralentissent après 2 ans (Apple, Samsung) -- Batteries impossibles à remplacer -- Pièces détachées indisponibles -**Software :** -- Fin du support arbitraire (Windows 7, iOS 12) -- APIs changées volontairement pour casser la compatibilité -- Applications qui exigent toujours plus de RAM/CPU -**L'Alliance Boréale refuse ce modèle.** -#### Pour le hardware -**Nos choix :** -- Serveurs réparables (pas de composants soudés) -- Fournisseurs qui vendent des pièces détachées -- Hardware éprouvé (pas de bleeding edge) -- Utilisation prolongée (8-12 ans si fonctionnel) -**Critère de remplacement :** -- **Panne irréparable** : oui, on remplace. -- **"Trop vieux" (mais fonctionne)** : non, on garde. -#### Pour le software -**Nos choix :** -- Logiciels libres (pas de fin de support arbitraire) -- Standards ouverts (pas de dépendance à un vendor) -- Versions LTS (Long Term Support) privilégiées -- Mise à jour progressive (pas de big bang) -**Exemple concret :** -Debian 12 (Bookworm) : support jusqu'en 2028. -→ Un serveur installé en 2023 peut rester en production 5 ans sans stress. -→ Comparé à Ubuntu non-LTS : support 9 mois (renouvellement forcé tous les 9 mois). -#### Pour les Services -**Nos choix :** -- Pas de shutdown brutal de Services (préavis minimum 6 mois) -- Migration assistée si arrêt de service -- Export de données garanti (pas de prise en otage) -- Standards ouverts (données récupérables même après shutdown) -**Engagement contractuel (dans Contrat d'Adhésion) :** -Si un membre quitte L'Alliance, il doit faciliter la migration de ses utilisateurs vers un autre membre ou un service externe (données exportées, DNS transférés, support durant transition). ---- -## CONCLUSION — LA FORÊT VIVANTE -**Ce manifeste n'est pas un aboutissement. C'est un point de départ.** -Nous avons exploré les racines intellectuelles de L'Alliance Boréale : Illich, Rabhi, Maturana, Ostrom, le principe de subsidiarité. Nous avons explicité notre métaphore fondatrice : la forêt, pas l'empire. Nous avons détaillé nos engagements : sobriété, autopoïèse, souveraineté fédérée, transparence utile, longévité. -**Mais un manifeste n'a de valeur que s'il est vécu.** -Les mots sont faciles. Les actes sont difficiles. -**Nous savons que nous ferons des erreurs.** -Nous savons que nous devrons ajuster notre trajectoire. -Nous savons que certains de nos choix seront critiqués, voire incompris. -**Mais nous savons aussi que cette voie est nécessaire.** -Le numérique mainstream nous mène dans le mur : extraction, centralisation, surveillance, obsolescence. Ce modèle n'est pas soutenable. Il ne nous rend pas heureux. Il détruit la planète. -**L'Alliance Boréale propose une alternative.** -Pas une utopie naïve. Pas un retour à l'âge de pierre. Mais une technologie **conviviale, sobre, fédérée, transmissible**. -Une technologie qui augmente notre autonomie au lieu de créer de nouvelles dépendances. -Une technologie qui respecte la planète au lieu de l'épuiser. -Une technologie qui se transmet de génération en génération au lieu d'être rachetée et fermée. -**Nous ne bâtissons pas pour dominer. Nous cultivons pour durer.** -**Nous ne promettons pas la perfection. Nous promettons la cohérence.** -**Nous ne cherchons pas à convaincre tout le monde. Nous cherchons ceux qui partagent déjà cette vision.** ---- -### Appel Final -**Si vous avez lu jusqu'ici, c'est que quelque chose résonne en vous.** -Peut-être l'envie d'une technologie plus humaine. -Peut-être la frustration face aux géants. -Peut-être la conviction qu'un autre numérique est possible. -**Nous vous invitons à nous rejoindre.** -Pas comme clients. Pas comme spectateurs. -Mais comme **co-constructeurs de cette forêt numérique vivante**. -**L'Alliance Boréale est un organisme autopoïétique.** -Elle existe par et pour ses membres. -Elle n'a pas de "propriétaire". -Elle n'a pas de "chef suprême". -**Elle n'a que des arbres qui grandissent ensemble, reliés par un Réseau invisible de confiance et de solidarité.** -**Bienvenue dans la forêt.** 🌲 ---- -## ANNEXE : POUR ALLER PLUS LOIN -### Références Bibliographiques -**Ivan Illich :** -- *La Convivialité* (1973) — Éditions du Seuil -- *Une société sans école* (1971) — Éditions du Seuil -- *Énergie et équité* (1973) — Éditions du Seuil -**Pierre Rabhi :** -- *Vers la sobriété heureuse* (2010) — Actes Sud -- *Manifeste pour la Terre et l'Humanisme* (2008) — Actes Sud -- *La part du colibri* (2006) — Éditions de l'Aube -**Humberto Maturana & Francisco Varela :** -- *L'Arbre de la connaissance* (1987) — Addison-Wesley France -- *Autopoiesis and Cognition* (1980) — D. Reidel Publishing -**Elinor Ostrom :** -- *Governing the Commons* (1990) — Cambridge University Press -- *Understanding Institutional Diversity* (2005) — Princeton University Press -**Autres inspirations :** -- Suzanne Simard, *Finding the Mother Tree* (2021) — Allen Lane -- David Bollier, *Think Like a Commoner* (2014) — New Society Publishers -- E.F. Schumacher, *Small is Beautiful* (1973) — Blond & Briggs -### Ressources Numériques -**Vidéos (TED Talks, documentaires) :** -- Suzanne Simard : "How trees talk to each other" (TED 2016) -- Pierre Rabhi : "La sobriété heureuse" (interviews diverses YouTube) -**Sites web :** -- The Internet Archive (préservation du patrimoine numérique) -- Low-tech Lab (technologies sobres et résilientes) -- Framasoft (dégooglisons Internet, logiciels libres) ---- -**FIN DU MANIFESTE PHILOSOPHIQUE** ---- -## MÉTADONNÉES -**Document :** 04_Manifeste_Philosophique_LEsprit_Boreal.md -**Version :** 1.0 -**Date de création :** 23 octobre 2025 -**Auteur :** Claude (profils #1 Philosophe, #2 Communication, #12 Documentaliste) -**Révision par :** Cercle Stratégique de L'Alliance Boréale -**Statut :** À valider par membres fondateurs -**Longueur :** ~9 500 mots (10 pages équivalent imprimé) -**Licence :** CC BY-SA 4.0 -**Sources utilisées :** -- `00_Glossaire_et_Definitions.md` -- `01_Charte_Fondatrice_v2_1.md` -- `devis_alliance_boreale_v2.md` -**Prochaine révision prévue :** Octobre 2026 ---- -**Changelog :** -- 2025-10-23 v1.0 : Création initiale du manifeste philosophique - - -## Réalignement — Liste canonique des 8 couches - -**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)**