# 🌲 Constitution des couches – Modèle boréal à 8 couches (C1–C8) **Version :** 1.1 **Date :** 25 janvier 2026 **Statut :** Référence normative (SSOT) **Portée :** Définir, justifier et cristalliser la **constitution** de chaque couche du modèle à 8 couches de l’Alliance Boréale, ainsi que les règles d’interface et de gouvernance associées. --- ## 0. Pourquoi ce document existe Le modèle à 8 couches sert de **contrat d’architecture** entre : - la **Fédération** (C1–C4), - le **Pivot** (C5), - les **Tenants** (C6–C8). Sans une constitution explicite par couche, le modèle dérive : les responsabilités se mélangent, les flux “sautent” des couches, la portabilité s’érode, et la conformité devient invérifiable. Ce document fixe les limites, responsabilités et artefacts attendus de chaque couche. --- ## 1. Définitions et conventions normatives ### 1.1 Terminologie - **Couche (Cx)** : “organe” fonctionnel du système. Chaque couche a un périmètre, des responsabilités, des interfaces et des preuves attendues. - **Fédération** : ensemble des capacités mutualisées et opérées pour héberger l’écosystème (C1–C4). - **Tenant** : entité logique ou organisationnelle qui déploie des services/produits/connaissances dans la canopée (C6–C8). - **Pivot** : membrane opérationnelle (C5) reliant fédération et tenants, régulant les flux. - **ADN numérique** : ensemble minimal d’artefacts permettant la **reconstruction** (descripteur, IaC, artefacts signés, SBOM). ### 1.2 Langage normatif Les termes **DOIT / NE DOIT PAS / DEVRAIT / PEUT** sont utilisés au sens normatif. ### 1.3 Principes transversaux non négociables 1. **Adjacency-only** : une couche communique uniquement avec sa voisine immédiate (Cx ↔ Cx±1). Toute exception est une anomalie à traiter (voir §2). 2. **Séparation fédéré / tenant** : la Fédération n’opère pas les charges applicatives tenant ; les tenants ne modifient pas les fondations fédérées. 3. **Portabilité intégrale** : tout tenant (C6–C8) **DOIT** pouvoir migrer entre membres fédérés sans perte de fonctionnalité, et sans réécriture de code structurelle. 4. **Régénération** : toute composante essentielle **DOIT** être reconstruisible à partir d’artefacts signés et versionnés (ADN numérique). 5. **Traçabilité** : tout flux structurant (artefacts, identités, décisions de conformité) **DOIT** produire des preuves vérifiables. --- ## 2. Schéma d’interface (contrat des membranes) ``` C1 ⇄ C2 ⇄ C3 ⇄ C4 ⇄ C5 ⇄ C6 ⇄ C7 ⇄ C8 ``` ### 2.1 Règles d’interface - **Cx ↔ Cx±1** : seul chemin normal. - **Routage obligatoire** : tout flux transversal (ex. tenant → forge) est médié par la couche intermédiaire (ex. C6 → C5 → C4). - **C5 comme membrane** : tout échange Fédération ↔ Tenant passe par C5. - **C3 comme système nerveux** : tout mécanisme de gouvernance, audit, conformité et supervision globale passe par C3 (et s’alimente via les couches adjacentes). ### 2.2 “Une seule instance” vs haute disponibilité - Les couches **C1–C5** sont des **services fédératifs uniques** au niveau du modèle (un SSOT et un contrat). - Elles **PEUVENT** être déployées en **réplicas** (HA), sans cesser d’être “une seule instance” au sens de gouvernance et d’interface. - Les couches **C6–C8** sont **multiples**, car elles existent **par tenant**. --- ## 3. Modèle de fiche (à utiliser pour toute couche) Chaque couche est documentée selon le format suivant (appliqué ci-dessous) : 1. **Rôle vital (justification)** : pourquoi la couche existe, et ce que son absence casse. 2. **Constitution (périmètre)** : inclus / exclus. 3. **Responsabilités** : fonctions attendues. 4. **Invariants** : règles non négociables propres à la couche. 5. **Interfaces adjacentes** : entrées/sorties et contrats. 6. **Artefacts & preuves** : ce qui DOIT être versionné, signé, auditable. 7. **Exigences opérationnelles** : disponibilité, résilience, sauvegarde, SLO/SLA (selon maturité). 8. **Anti‑patterns** : erreurs fréquentes à interdire. 9. **Exemples de mise en œuvre** : technologies possibles (non prescriptif). --- # 4. Constitution détaillée des couches ## C1 — Racines physiques (Fédération) ### 1) Rôle vital (justification) C1 existe pour **ancrer** l’écosystème dans le réel : énergie, climatisation, sécurité physique, serveurs, stockage brut. Sans C1 : aucune résilience réelle, aucun contrôle de souveraineté matérielle, aucune capacité de reconstruction. ### 2) Constitution (périmètre) **Inclut :** - Sites physiques (salles, cages, racks), contrôle d’accès, surveillance. - Énergie (alimentation, onduleurs, génératrices), câblage, environnement. - Matériel : serveurs, switches physiques, liens, stockage primaire, pièces. - Inventaire, étiquetage, cycle de vie (acquisition → décommission). **Exclut :** - Routage logique et services réseau (C2). - Identité, audit, gouvernance (C3). - Forge, registres, pipelines (C4). - Toute exposition applicative tenant (C6–C8). ### 3) Responsabilités - Garantir l’intégrité physique et la continuité énergétique. - Assurer la capacité d’hébergement (compute, storage brut) et la redondance. - Documenter l’inventaire matériel et l’état de santé. ### 4) Invariants - Les tenants **NE DOIVENT PAS** dépendre de détails matériels non portables. - Toute ressource C1 doit être **remplaçable** par équivalent standard. ### 5) Interfaces adjacentes (C1 ↔ C2) - Sortants : connectivité physique, liens, VLAN/L2, temps (NTP matériel si applicable). - Entrants : exigences de capacité, topologie réseau, contraintes de sécurité. ### 6) Artefacts & preuves - Inventaire matériel (CMDB), schémas de câblage, plans de redondance. - Procédures d’intervention (runbooks), preuves de tests (UPS/génératrice). - Journal de changement (déploiements, remplacements). ### 7) Exigences opérationnelles - Objectif : tolérance de panne (au minimum N+1 sur énergie critique selon maturité). - Sauvegarde : n/a (C1 fournit le support, pas les sauvegardes logiques). ### 8) Anti‑patterns - “Serveur spécial” indispensable à un tenant. - Absence de CMDB / inventaire. - Mélange des accès physiques tenant/fédéré sans contrôle. ### 9) Exemples de mise en œuvre - Datacenter membre, colocation souveraine, micro‑datacenter maillé. --- ## C2 — Système vasculaire (Fédération) ### 1) Rôle vital (justification) C2 existe pour assurer la **circulation** : adressage, DNS racinaire autoritatif, PKI de transport, liens inter‑DC, segmentation. Sans C2 : pas d’interconnexion fiable, pas de souveraineté de nommage, pas de chiffrement cohérent. ### 2) Constitution (périmètre) **Inclut :** - Réseau logique : routage, segmentation, interconnexion, politiques réseau. - DNS **autoritatif** fédéré (racine de nommage). - PKI de transport (certificats pour interconnexions et services fédérés). - Protection réseau (DDoS, filtrage, ACL, egress control) au niveau fédéré. **Exclut :** - Gestion d’identité et audit (C3). - Registres d’artefacts/pipelines (C4). - Proxy/API gateway tenant-facing (C5). ### 3) Responsabilités - Assurer la connectivité est‑ouest fédérée (entre sites) et nord‑sud vers C3/C4. - Maintenir un nommage fédéré cohérent (DNS autoritatif). - Fournir des primitives réseau standardisées aux couches supérieures. ### 4) Invariants - Les tenants ne parlent **jamais** directement à C2 : tout accès traverse C5. - Le DNS fédéré est la source de vérité des zones racines fédérées. ### 5) Interfaces adjacentes - **C1 ↔ C2** : liens physiques, disponibilité, contraintes de site. - **C2 ↔ C3** : exposition des métriques réseau, événements de sécurité, services de résolution/PKI pour la gouvernance. ### 6) Artefacts & preuves - Topologies, politiques réseau, zones DNS (IaC recommandé). - Journaux de changements réseau, tests de résilience inter‑sites. - Inventaire des certificats de transport et rotations. ### 7) Exigences opérationnelles - Redondance des composants réseau critiques. - RTO/RPO réseau définis selon criticité des services fédérés. ### 8) Anti‑patterns - “DNS sauvage” géré par un tenant. - Règles réseau ad‑hoc non versionnées. - Contournement de segmentation pour “aller plus vite”. ### 9) Exemples de mise en œuvre - BGP/EVPN, firewalls, PowerDNS autoritatif, PKI interne. --- ## C3 — Système nerveux central (Fédération) ### 1) Rôle vital (justification) C3 existe pour gouverner, superviser et auditer : c’est le **centre de décision** et de rétroaction. Sans C3 : absence de cohérence de sécurité, impossibilité de conformité, aucun mécanisme d’apprentissage global. ### 2) Constitution (périmètre) **Inclut :** - Gouvernance : politiques, règles, contrôles, arbitrages. - Identité fédérée (IAM/SSO), annuaire, RBAC/ABAC fédératifs. - Journalisation/audit central (preuves, événements structurants). - Supervision/observabilité fédérée (métriques, alertes, incidents). - Conformité : critères, attestations, trajectoires de maturité. **Exclut :** - Build/release et stockage des artefacts (C4) — C3 dicte les règles, C4 exécute le métabolisme. - Exposition aux tenants (C5 gère la surface). ### 3) Responsabilités - Définir et appliquer les politiques communes (sécurité, portabilité, traçabilité). - Opérer l’identité fédérée et les permissions de contribution. - Centraliser la détection d’anomalies systémiques et déclencher la remédiation. ### 4) Invariants - Toute décision de conformité doit être traçable (qui/quoi/quand/pourquoi). - Les identités privilégiées doivent être gouvernées (MFA, just‑in‑time si maturité). ### 5) Interfaces adjacentes - **C2 ↔ C3** : flux réseau et signaux de sécurité ; services de nommage/PKI. - **C3 ↔ C4** : règles de signature, politiques SBOM, exigences de pipelines, attestations. ### 6) Artefacts & preuves - Politiques publiées (SSOT), journaux d’audit, registres de décisions. - Catégorisation d’incidents, post‑mortems, indicateurs de résilience. - Référentiels d’exigences (ex. Label / conformité). ### 7) Exigences opérationnelles - Haute disponibilité logique (au minimum redondance des composants IAM/audit). - Rétention des logs conforme à la politique boréale. ### 8) Anti‑patterns - Gouvernance “orale” non documentée. - Supervision uniquement locale, sans vue fédérée. - Identités partagées (“comptes génériques”). ### 9) Exemples de mise en œuvre - Annuaire + SSO (OpenLDAP/Keycloak), SIEM léger, OTel/Prometheus, portails de conformité. --- ## C4 — Métabolisme commun / Forge mutualisée (Fédération) ### 1) Rôle vital (justification) C4 existe pour produire, signer, stocker et distribuer les artefacts : c’est le **métabolisme** de l’écosystème. Sans C4 : pas de chaîne d’approvisionnement vérifiable, pas d’ADN numérique partagé, pas de reconstruction fiable. ### 2) Constitution (périmètre) **Inclut :** - Forge (code, tickets, docs), registres (containers, paquets), dépôts d’artefacts. - Pipelines CI/CD fédérés, politiques de build, attestations, SBOM. - Signature d’artefacts (clé/PKI applicative), politique de provenance. - Catalogue : modèles, modules, composants de référence, “patterns” portables. - Stockage de secrets fédérés **si** gouverné (secrets de base, jamais des secrets métier tenant). **Exclut :** - Runtime d’exposition tenant (C5). - Exécution applicative tenant (C6–C8). ### 3) Responsabilités - Offrir une chaîne de production reproductible (build → scan → signature → publication). - Héberger la source de vérité des composants mutualisés. - Garantir la disponibilité et l’intégrité des artefacts. ### 4) Invariants - Un artefact consommé par C5/C6 **DOIT** être traçable (version, hash, provenance). - Les pipelines critiques **DOIVENT** être versionnés et audités. ### 5) Interfaces adjacentes - **C3 ↔ C4** : politiques (signature, conformité, exigences SBOM), droits. - **C4 ↔ C5** : distribution d’artefacts, configs, descripteurs ; publication de surfaces d’API du pivot. ### 6) Artefacts & preuves - Descripteurs YAML (ADN), IaC, manifests, SBOM, attestations. - Clés/empreintes, registres de signatures, journaux de releases. - Catalogue des modules “boréalisés”. ### 7) Exigences opérationnelles - Sauvegardes et réplication (C4 est critique : perte = perte d’ADN). - Contrôles d’intégrité (immuabilité des releases, rétention). ### 8) Anti‑patterns - Artefacts “binaries” sans sources ou sans SBOM. - Déploiements manuels non reproductibles. - Secrets tenant stockés en C4 sans garde‑fous. ### 9) Exemples de mise en œuvre - Forgejo/Git, registries OCI, Cosign/Sigstore‑like, scanners (Trivy/Grype), IaC (Terraform/Ansible). --- ## C5 — Membrane d’échange / Pivot (Fédération – service commun, multi‑tenant) ### 1) Rôle vital (justification) C5 existe pour **réguler** l’échange entre racines et canopée : exposition contrôlée, médiation, filtrage, compatibilité de portabilité. Sans C5 : les tenants finissent par “toucher” C1–C4 directement (dérive), et la séparation fédéré/tenant s’effondre. ### 2) Constitution (périmètre) **Inclut :** - Surface d’entrée/sortie : reverse proxy, API gateway, routage tenant‑aware. - Médiation d’identité : intégration SSO, tokens, délégation, sessions. - Politique de flux : rate limiting, quotas, contrats d’API, WAF logique. - Services de “récursion” et d’accès contrôlé (ex. DNS récursif tenant‑side si prévu). - Portail d’administration pivot (surfaces d’échange), observabilité exposable. **Exclut :** - Stockage d’artefacts (C4). - Runtime applicatif métier tenant (C6–C8). - Décision de gouvernance globale (C3). ### 3) Responsabilités - Fournir un **service unique** de membrane fédérative, multi‑tenant, gouverné. - Appliquer les politiques de C3 et consommer les artefacts/politiques de C4. - Garantir que tout accès tenant aux ressources fédérées passe par des contrôles explicites. ### 4) Invariants - C5 est **un service fédéral** : les tenants ne possèdent pas l’instance, seulement leur **tranche logique** (config/politiques). - C5 **NE DOIT PAS** contenir de logique métier tenant durable. - Toute exception de flux non adjacent est **interdite** (elle doit être re‑mappée via C5 ou C3). ### 5) Interfaces adjacentes - **C4 ↔ C5** : artefacts du pivot, politiques, descripteurs, versions. - **C5 ↔ C6** : routage vers services tenant, injection d’identité, exposition d’APIs, collecte de métriques. ### 6) Artefacts & preuves - Configuration “slice” par tenant (YAML/manifest), versionnée et auditable. - Journaux d’accès (tenant‑aware), politiques appliquées, preuves de déploiement. - Contrats d’API, règles de quotas, attestations WAF. ### 7) Exigences opérationnelles - HA (réplicas) fortement recommandé : C5 est un point de passage critique. - Journalisation et métriques par tenant (au minimum agrégées, idéalement exportables). ### 8) Anti‑patterns - Tenants qui contournent C5 pour parler à C4/C3/C2. - Ajout de logique applicative métier tenant dans la membrane. - Config non versionnée (hotfixes invisibles). ### 9) Exemples de mise en œuvre - Nginx/Traefik/Envoy + OIDC, API gateway, portail admin, DNS récursif contrôlé. --- ## C6 — Tissu fonctionnel (Tenants) ### 1) Rôle vital (justification) C6 existe pour héberger les **services applicatifs génériques** d’un tenant : backends, workflows, APIs internes. Sans C6 : les produits (C7) deviennent monolithiques, non portables, et la connaissance (C8) se détache du runtime. ### 2) Constitution (périmètre) **Inclut :** - Services backend, microservices, jobs, orchestrations, bases de données tenant. - APIs internes et contrats de service. - Observabilité applicative (métriques, logs, traces) côté tenant. **Exclut :** - Exposition publique directe : passe par C5. - UX/fronts (C7) et analytique/IA (C8). ### 3) Responsabilités - Fournir les fonctions métier réutilisables (domain services). - Respecter les contraintes de portabilité (stateless si possible, data migration plan). - Exposer des healthchecks, métriques et contrats d’API. ### 4) Invariants - Aucun secret fédéré n’est copié : usage via mécanismes contrôlés. - Toute dépendance externe doit être déclarée (SBOM/manifest du tenant si requis). ### 5) Interfaces adjacentes - **C5 ↔ C6** : réception d’identité/délégation, trafic entrant, politiques. - **C6 ↔ C7** : APIs produits, BFF, services d’assemblage. ### 6) Artefacts & preuves - Descripteur tenant (YAML), manifests de déploiement, IaC. - Contrats d’API, tests, versions d’images, SBOM (au minimum pour releases). - Plan de migration des données (portabilité). ### 7) Exigences opérationnelles - Sauvegardes et restaurations testées pour données tenant. - SLO propres au produit, mais observables et exportables. ### 8) Anti‑patterns - Endpoint public direct sans C5. - État local non sauvegardé (données “sur disque” sans plan). - Configuration non reproductible (snowflake). ### 9) Exemples de mise en œuvre - Kubernetes/Nomad, bases PostgreSQL/MariaDB, queues, workers, OTel côté tenant. --- ## C7 — Organes sensoriels & moteurs (Tenants) ### 1) Rôle vital (justification) C7 existe pour matérialiser l’expérience : interfaces, produits, interactions humaines. Sans C7 : C6 reste une “boîte noire” inutilisable, et C8 n’a pas de boucle de rétroaction utilisateur. ### 2) Constitution (périmètre) **Inclut :** - Frontends web/mobile, clients, portails, UI kits. - BFF (backend-for-frontend) si pertinent (sinon en C6, mais boundary clair). - Gestion de sessions/UX (sous contraintes d’identité via C5/C3). **Exclut :** - Règles d’accès fédérées (C3) et médiation d’identité (C5). - Analytique/IA et mémoire cognitive (C8). ### 3) Responsabilités - Offrir une UX cohérente, sécurisée, accessible. - Appliquer les contraintes de sécurité (CSP, protections client) en cohérence avec C5. - Produire des signaux d’usage exploitables (télémétrie, événements) vers C8. ### 4) Invariants - Les identités et sessions doivent respecter le cadre fédéré (pas d’IAM “shadow”). - Les données sensibles doivent être minimisées côté client. ### 5) Interfaces adjacentes - **C6 ↔ C7** : consommation des APIs, orchestration des parcours. - **C7 ↔ C8** : émission d’événements, métriques d’usage, feedback. ### 6) Artefacts & preuves - Releases UI versionnées, hashées, reproductibles. - Matrice de compatibilité (navigateurs), preuves d’accessibilité (selon exigences). - Schémas d’événements d’usage. ### 7) Exigences opérationnelles - CDN/cache si nécessaire (via C5 ou services tenant), objectifs de performance. ### 8) Anti‑patterns - Secrets dans le client. - APIs “direct to C4/C3”. - UX qui impose des dépendances non portables (services externes non maîtrisés). ### 9) Exemples de mise en œuvre - SPA/SSR, apps mobiles, design system, analytics events. --- ## C8 — Conscience cognitive (Tenants) ### 1) Rôle vital (justification) C8 existe pour transformer l’usage et les données en **connaissance** : analytique, recherche, IA, décision. Sans C8 : aucun apprentissage, aucune optimisation, aucune “mémoire” structurée. ### 2) Constitution (périmètre) **Inclut :** - Pipelines data, entrepôts/lacs tenant, modèles ML/IA, recherche sémantique. - Gouvernance des données tenant (catalogue, qualité, lineage) au niveau tenant. - Tableaux de bord décisionnels, recommandations. **Exclut :** - Gouvernance fédérée globale (C3) sauf exigences minimales de conformité. - Runtime de produit (C6/C7) — C8 consomme des événements/données. ### 3) Responsabilités - Mettre en place la boucle d’apprentissage (collecte → traitement → décision → action). - Assurer la qualité, la confidentialité et la minimisation des données. - Fournir des signaux remontants utiles (insights) vers C6/C7 et, sous forme agrégée, vers C3 si requis. ### 4) Invariants - Les données tenant restent sous contrôle tenant (politiques, rétention, accès). - Toute dérivation de données doit être justifiable (finalité, minimisation). ### 5) Interfaces adjacentes - **C7 ↔ C8** : réception des signaux d’usage et feedback. - **C8 ↔ (retour vers C7/C6)** : recommandations, scores, décisions (toujours via contrats adjacents). ### 6) Artefacts & preuves - Jeux de données versionnés si applicable, schémas, lineage. - Modèles versionnés, évaluations, cartes de modèles (selon maturité). - Politiques de rétention et accès. ### 7) Exigences opérationnelles - Sauvegardes / réplication des données analytiques selon criticité. - Contrôles d’accès robustes (données sensibles). ### 8) Anti‑patterns - “Aspirer toutes les données” sans finalité. - Modèles non versionnés, non testés, non auditables. - Mélange de données tenants sans cloisonnement. ### 9) Exemples de mise en œuvre - ELT/ETL, lakehouse, BI, vector store, pipelines ML. --- # 5. Annexes (recommandées) ## A) Tableau de responsabilité (ownership) - **C1–C4 : Fédération** (opération + gouvernance). - **C5 : Fédération (service commun) + slices tenant** (config/politiques par tenant). - **C6–C8 : Tenants** (opération + données + produits). ## B) Checklist “preuve minimale” par couche (MVP conformité) - C1 : inventaire + runbooks + tests énergie. - C2 : topologie + DNS autoritatif + journal de changements. - C3 : IAM + audit + politiques publiées. - C4 : forge + registry + signature + sauvegarde + SBOM minimal. - C5 : routage tenant-aware + logs + quotas + config versionnée. - C6 : manifests + sauvegardes données + healthchecks + API contracts. - C7 : releases reproductibles + schéma événements usage. - C8 : politiques données + versioning modèles + lineage minimal.