alliance-boreale/docs/architecture/10 - Constitution des couches du modèle Boréal.md

# 🌲 Constitution des couches – Modèle boréal à 8 couches (C1–C8)
**Version :** 1.1  
**Date :** 25 janvier 2026  
**Statut :** Référence normative (SSOT)  
**Portée :** Définir, justifier et cristalliser la **constitution** de chaque couche du modèle à 8 couches de l’Alliance Boréale, ainsi que les règles d’interface et de gouvernance associées.

---

## 0. Pourquoi ce document existe
Le modèle à 8 couches sert de **contrat d’architecture** entre :
- la **Fédération** (C1–C4),
- le **Pivot** (C5),
- les **Tenants** (C6–C8).

Sans une constitution explicite par couche, le modèle dérive : les responsabilités se mélangent, les flux “sautent” des couches, la portabilité s’érode, et la conformité devient invérifiable.  
Ce document fixe donc, **une bonne fois pour toutes**, les limites, responsabilités et artefacts attendus de chaque couche.

---

## 1. Définitions et conventions normatives

### 1.1 Terminologie
- **Couche (Cx)** : “organe” fonctionnel du système. Chaque couche a un périmètre, des responsabilités, des interfaces et des preuves attendues.
- **Fédération** : ensemble des capacités mutualisées et opérées pour héberger l’écosystème (C1–C4).
- **Tenant** : entité logique ou organisationnelle qui déploie des services/produits/connaissances dans la canopée (C6–C8).
- **Pivot** : membrane opérationnelle (C5) reliant fédération et tenants, régulant les flux.
- **ADN numérique** : ensemble minimal d’artefacts permettant la **reconstruction** (descripteur, IaC, artefacts signés, SBOM).

### 1.2 Langage normatif
Les termes **DOIT / NE DOIT PAS / DEVRAIT / PEUT** sont utilisés au sens normatif.

### 1.3 Principes transversaux non négociables
1) **Adjacency-only** : une couche communique uniquement avec sa voisine immédiate (Cx ↔ Cx±1). Toute exception est une anomalie à traiter (voir §2).  
2) **Séparation fédéré / tenant** : la Fédération n’opère pas les charges applicatives tenant ; les tenants ne modifient pas les fondations fédérées.  
3) **Portabilité intégrale** : tout tenant (C6–C8) **DOIT** pouvoir migrer entre membres fédérés sans perte de fonctionnalité, et sans réécriture de code structurelle.  
4) **Régénération** : toute composante essentielle **DOIT** être reconstruisible à partir d’artefacts signés et versionnés (ADN numérique).  
5) **Traçabilité** : tout flux structurant (artefacts, identités, décisions de conformité) **DOIT** produire des preuves vérifiables.

---

## 2. Schéma d’interface (contrat des membranes)

```
C1 ⇄ C2 ⇄ C3 ⇄ C4 ⇄ C5 ⇄ C6 ⇄ C7 ⇄ C8
```

### 2.1 Règles d’interface
- **Cx ↔ Cx±1** : seul chemin normal.
- **Routage obligatoire** : tout flux transversal (ex. tenant → forge) est médié par la couche intermédiaire (ex. C6 → C5 → C4).
- **C5 comme membrane** : tout échange Fédération ↔ Tenant passe par C5.
- **C3 comme système nerveux** : tout mécanisme de gouvernance, audit, conformité et supervision globale passe par C3 (et s’alimente via les couches adjacentes).

### 2.2 “Une seule instance” vs haute disponibilité
- Les couches **C1–C5** sont des **services fédératifs uniques** au niveau du modèle (un SSOT et un contrat).  
- Elles **PEUVENT** être déployées en **réplicas** (HA), sans cesser d’être “une seule instance” au sens de gouvernance et d’interface.
- Les couches **C6–C8** sont **multiples**, car elles existent **par tenant**.

---

## 3. Modèle de fiche (à utiliser pour toute couche)
Chaque couche est documentée selon le format suivant (appliqué ci-dessous) :

1) **Rôle vital (justification)** : pourquoi la couche existe, et ce que son absence casse.
2) **Constitution (périmètre)** : inclus / exclus.
3) **Responsabilités** : fonctions attendues.
4) **Invariants** : règles non négociables propres à la couche.
5) **Interfaces adjacentes** : entrées/sorties et contrats.
6) **Artefacts & preuves** : ce qui DOIT être versionné, signé, auditable.
7) **Exigences opérationnelles** : disponibilité, résilience, sauvegarde, SLO/SLA (selon maturité).
8) **Anti‑patterns** : erreurs fréquentes à interdire.
9) **Exemples de mise en œuvre** : technologies possibles (non prescriptif).

---

# 4. Constitution détaillée des couches

## C1 — Racines physiques (Fédération)
### 1) Rôle vital (justification)
C1 existe pour **ancrer** l’écosystème dans le réel : énergie, climatisation, sécurité physique, serveurs, stockage brut.  
Sans C1 : aucune résilience réelle, aucun contrôle de souveraineté matérielle, aucune capacité de reconstruction.

### 2) Constitution (périmètre)
**Inclut :**
- Sites physiques (salles, cages, racks), contrôle d’accès, surveillance.
- Énergie (alimentation, onduleurs, génératrices), câblage, environnement.
- Matériel : serveurs, switches physiques, liens, stockage primaire, pièces.
- Inventaire, étiquetage, cycle de vie (acquisition → décommission).

**Exclut :**
- Routage logique et services réseau (C2).
- Identité, audit, gouvernance (C3).
- Forge, registres, pipelines (C4).
- Toute exposition applicative tenant (C6–C8).

### 3) Responsabilités
- Garantir l’intégrité physique et la continuité énergétique.
- Assurer la capacité d’hébergement (compute, storage brut) et la redondance.
- Documenter l’inventaire matériel et l’état de santé.

### 4) Invariants
- Les tenants **NE DOIVENT PAS** dépendre de détails matériels non portables.
- Toute ressource C1 doit être **remplaçable** par équivalent standard.

### 5) Interfaces adjacentes (C1 ↔ C2)
- Sortants : connectivité physique, liens, VLAN/L2, temps (NTP matériel si applicable).
- Entrants : exigences de capacité, topologie réseau, contraintes de sécurité.

### 6) Artefacts & preuves
- Inventaire matériel (CMDB), schémas de câblage, plans de redondance.
- Procédures d’intervention (runbooks), preuves de tests (UPS/génératrice).
- Journal de changement (déploiements, remplacements).

### 7) Exigences opérationnelles
- Objectif : tolérance de panne (au minimum N+1 sur énergie critique selon maturité).
- Sauvegarde : n/a (C1 fournit le support, pas les sauvegardes logiques).

### 8) Anti‑patterns
- “Serveur spécial” indispensable à un tenant.
- Absence de CMDB / inventaire.
- Mélange des accès physiques tenant/fédéré sans contrôle.

### 9) Exemples de mise en œuvre
- Datacenter membre, colocation souveraine, micro‑datacenter maillé.

---

## C2 — Système vasculaire (Fédération)
### 1) Rôle vital (justification)
C2 existe pour assurer la **circulation** : adressage, DNS racinaire autoritatif, PKI de transport, liens inter‑DC, segmentation.  
Sans C2 : pas d’interconnexion fiable, pas de souveraineté de nommage, pas de chiffrement cohérent.

### 2) Constitution (périmètre)
**Inclut :**
- Réseau logique : routage, segmentation, interconnexion, politiques réseau.
- DNS **autoritatif** fédéré (racine de nommage).
- PKI de transport (certificats pour interconnexions et services fédérés).
- Protection réseau (DDoS, filtrage, ACL, egress control) au niveau fédéré.

**Exclut :**
- Gestion d’identité et audit (C3).
- Registres d’artefacts/pipelines (C4).
- Proxy/API gateway tenant-facing (C5).

### 3) Responsabilités
- Assurer la connectivité est‑ouest fédérée (entre sites) et nord‑sud vers C3/C4.
- Maintenir un nommage fédéré cohérent (DNS autoritatif).
- Fournir des primitives réseau standardisées aux couches supérieures.

### 4) Invariants
- Les tenants ne parlent **jamais** directement à C2 : tout accès traverse C5.
- Le DNS fédéré est la source de vérité des zones racines fédérées.

### 5) Interfaces adjacentes
- **C1 ↔ C2** : liens physiques, disponibilité, contraintes de site.
- **C2 ↔ C3** : exposition des métriques réseau, événements de sécurité, services de résolution/PKI pour la gouvernance.

### 6) Artefacts & preuves
- Topologies, politiques réseau, zones DNS (IaC recommandé).
- Journaux de changements réseau, tests de résilience inter‑sites.
- Inventaire des certificats de transport et rotations.

### 7) Exigences opérationnelles
- Redondance des composants réseau critiques.
- RTO/RPO réseau définis selon criticité des services fédérés.

### 8) Anti‑patterns
- “DNS sauvage” géré par un tenant.
- Règles réseau ad‑hoc non versionnées.
- Contournement de segmentation pour “aller plus vite”.

### 9) Exemples de mise en œuvre
- BGP/EVPN, firewalls, PowerDNS autoritatif, PKI interne.

---

## C3 — Système nerveux central (Fédération)
### 1) Rôle vital (justification)
C3 existe pour gouverner, superviser et auditer : c’est le **centre de décision** et de rétroaction.  
Sans C3 : absence de cohérence de sécurité, impossibilité de conformité, aucun mécanisme d’apprentissage global.

### 2) Constitution (périmètre)
**Inclut :**
- Gouvernance : politiques, règles, contrôles, arbitrages.
- Identité fédérée (IAM/SSO), annuaire, RBAC/ABAC fédératifs.
- Journalisation/audit central (preuves, événements structurants).
- Supervision/observabilité fédérée (métriques, alertes, incidents).
- Conformité : critères, attestations, trajectoires de maturité.

**Exclut :**
- Build/release et stockage des artefacts (C4) — C3 dicte les règles, C4 exécute le métabolisme.
- Exposition aux tenants (C5 gère la surface).

### 3) Responsabilités
- Définir et appliquer les politiques communes (sécurité, portabilité, traçabilité).
- Opérer l’identité fédérée et les permissions de contribution.
- Centraliser la détection d’anomalies systémiques et déclencher la remédiation.

### 4) Invariants
- Toute décision de conformité doit être traçable (qui/quoi/quand/pourquoi).
- Les identités privilégiées doivent être gouvernées (MFA, just‑in‑time si maturité).

### 5) Interfaces adjacentes
- **C2 ↔ C3** : flux réseau et signaux de sécurité ; services de nommage/PKI.
- **C3 ↔ C4** : règles de signature, politiques SBOM, exigences de pipelines, attestations.

### 6) Artefacts & preuves
- Politiques publiées (SSOT), journaux d’audit, registres de décisions.
- Catégorisation d’incidents, post‑mortems, indicateurs de résilience.
- Référentiels d’exigences (ex. Label / conformité).

### 7) Exigences opérationnelles
- Haute disponibilité logique (au minimum redondance des composants IAM/audit).
- Rétention des logs conforme à la politique boréale.

### 8) Anti‑patterns
- Gouvernance “orale” non documentée.
- Supervision uniquement locale, sans vue fédérée.
- Identités partagées (“comptes génériques”).

### 9) Exemples de mise en œuvre
- Annuaire + SSO (OpenLDAP/Keycloak), SIEM léger, OTel/Prometheus, portails de conformité.

---

## C4 — Métabolisme commun / Forge mutualisée (Fédération)
### 1) Rôle vital (justification)
C4 existe pour produire, signer, stocker et distribuer les artefacts : c’est le **métabolisme** de l’écosystème.  
Sans C4 : pas de chaîne d’approvisionnement vérifiable, pas d’ADN numérique partagé, pas de reconstruction fiable.

### 2) Constitution (périmètre)
**Inclut :**
- Forge (code, tickets, docs), registres (containers, paquets), dépôts d’artefacts.
- Pipelines CI/CD fédérés, politiques de build, attestations, SBOM.
- Signature d’artefacts (clé/PKI applicative), politique de provenance.
- Catalogue : modèles, modules, composants de référence, “patterns” portables.
- Stockage de secrets fédérés **si** gouverné (secrets de base, jamais des secrets métier tenant).

**Exclut :**
- Runtime d’exposition tenant (C5).
- Exécution applicative tenant (C6–C8).

### 3) Responsabilités
- Offrir une chaîne de production reproductible (build → scan → signature → publication).
- Héberger la source de vérité des composants mutualisés.
- Garantir la disponibilité et l’intégrité des artefacts.

### 4) Invariants
- Un artefact consommé par C5/C6 **DOIT** être traçable (version, hash, provenance).
- Les pipelines critiques **DOIVENT** être versionnés et audités.

### 5) Interfaces adjacentes
- **C3 ↔ C4** : politiques (signature, conformité, exigences SBOM), droits.
- **C4 ↔ C5** : distribution d’artefacts, configs, descripteurs ; publication de surfaces d’API du pivot.

### 6) Artefacts & preuves
- Descripteurs YAML (ADN), IaC, manifests, SBOM, attestations.
- Clés/empreintes, registres de signatures, journaux de releases.
- Catalogue des modules “boréalisés”.

### 7) Exigences opérationnelles
- Sauvegardes et réplication (C4 est critique : perte = perte d’ADN).
- Contrôles d’intégrité (immuabilité des releases, rétention).

### 8) Anti‑patterns
- Artefacts “binaries” sans sources ou sans SBOM.
- Déploiements manuels non reproductibles.
- Secrets tenant stockés en C4 sans garde‑fous.

### 9) Exemples de mise en œuvre
- Forgejo/Git, registries OCI, Cosign/Sigstore‑like, scanners (Trivy/Grype), IaC (Terraform/Ansible).

---

## C5 — Membrane d’échange / Pivot (Fédération – service commun, multi‑tenant)
### 1) Rôle vital (justification)
C5 existe pour **réguler** l’échange entre racines et canopée : exposition contrôlée, médiation, filtrage, compatibilité de portabilité.  
Sans C5 : les tenants finissent par “toucher” C1–C4 directement (dérive), et la séparation fédéré/tenant s’effondre.

### 2) Constitution (périmètre)
**Inclut :**
- Surface d’entrée/sortie : reverse proxy, API gateway, routage tenant‑aware.
- Médiation d’identité : intégration SSO, tokens, délégation, sessions.
- Politique de flux : rate limiting, quotas, contrats d’API, WAF logique.
- Services de “récursion” et d’accès contrôlé (ex. DNS récursif tenant‑side si prévu).
- Portail d’administration pivot (surfaces d’échange), observabilité exposable.

**Exclut :**
- Stockage d’artefacts (C4).
- Runtime applicatif métier tenant (C6–C8).
- Décision de gouvernance globale (C3).

### 3) Responsabilités
- Fournir un **service unique** de membrane fédérative, multi‑tenant, gouverné.
- Appliquer les politiques de C3 et consommer les artefacts/politiques de C4.
- Garantir que tout accès tenant aux ressources fédérées passe par des contrôles explicites.

### 4) Invariants
- C5 est **un service fédéral** : les tenants ne possèdent pas l’instance, seulement leur **tranche logique** (config/politiques).
- C5 **NE DOIT PAS** contenir de logique métier tenant durable.
- Toute exception de flux non adjacent est **interdite** (elle doit être re‑mappée via C5 ou C3).

### 5) Interfaces adjacentes
- **C4 ↔ C5** : artefacts du pivot, politiques, descripteurs, versions.
- **C5 ↔ C6** : routage vers services tenant, injection d’identité, exposition d’APIs, collecte de métriques.

### 6) Artefacts & preuves
- Configuration “slice” par tenant (YAML/manifest), versionnée et auditable.
- Journaux d’accès (tenant‑aware), politiques appliquées, preuves de déploiement.
- Contrats d’API, règles de quotas, attestations WAF.

### 7) Exigences opérationnelles
- HA (réplicas) fortement recommandé : C5 est un point de passage critique.
- Journalisation et métriques par tenant (au minimum agrégées, idéalement exportables).

### 8) Anti‑patterns
- Tenants qui contournent C5 pour parler à C4/C3/C2.
- Ajout de logique applicative métier tenant dans la membrane.
- Config non versionnée (hotfixes invisibles).

### 9) Exemples de mise en œuvre
- Nginx/Traefik/Envoy + OIDC, API gateway, portail admin, DNS récursif contrôlé.

---

## C6 — Tissu fonctionnel (Tenants)
### 1) Rôle vital (justification)
C6 existe pour héberger les **services applicatifs génériques** d’un tenant : backends, workflows, APIs internes.  
Sans C6 : les produits (C7) deviennent monolithiques, non portables, et la connaissance (C8) se détache du runtime.

### 2) Constitution (périmètre)
**Inclut :**
- Services backend, microservices, jobs, orchestrations, bases de données tenant.
- APIs internes et contrats de service.
- Observabilité applicative (métriques, logs, traces) côté tenant.

**Exclut :**
- Exposition publique directe : passe par C5.
- UX/fronts (C7) et analytique/IA (C8).

### 3) Responsabilités
- Fournir les fonctions métier réutilisables (domain services).
- Respecter les contraintes de portabilité (stateless si possible, data migration plan).
- Exposer des healthchecks, métriques et contrats d’API.

### 4) Invariants
- Aucun secret fédéré n’est copié : usage via mécanismes contrôlés.
- Toute dépendance externe doit être déclarée (SBOM/manifest du tenant si requis).

### 5) Interfaces adjacentes
- **C5 ↔ C6** : réception d’identité/délégation, trafic entrant, politiques.
- **C6 ↔ C7** : APIs produits, BFF, services d’assemblage.

### 6) Artefacts & preuves
- Descripteur tenant (YAML), manifests de déploiement, IaC.
- Contrats d’API, tests, versions d’images, SBOM (au minimum pour releases).
- Plan de migration des données (portabilité).

### 7) Exigences opérationnelles
- Sauvegardes et restaurations testées pour données tenant.
- SLO propres au produit, mais observables et exportables.

### 8) Anti‑patterns
- Endpoint public direct sans C5.
- État local non sauvegardé (données “sur disque” sans plan).
- Configuration non reproductible (snowflake).

### 9) Exemples de mise en œuvre
- Kubernetes/Nomad, bases PostgreSQL/MariaDB, queues, workers, OTel côté tenant.

---

## C7 — Organes sensoriels & moteurs (Tenants)
### 1) Rôle vital (justification)
C7 existe pour matérialiser l’expérience : interfaces, produits, interactions humaines.  
Sans C7 : C6 reste une “boîte noire” inutilisable, et C8 n’a pas de boucle de rétroaction utilisateur.

### 2) Constitution (périmètre)
**Inclut :**
- Frontends web/mobile, clients, portails, UI kits.
- BFF (backend-for-frontend) si pertinent (sinon en C6, mais boundary clair).
- Gestion de sessions/UX (sous contraintes d’identité via C5/C3).

**Exclut :**
- Règles d’accès fédérées (C3) et médiation d’identité (C5).
- Analytique/IA et mémoire cognitive (C8).

### 3) Responsabilités
- Offrir une UX cohérente, sécurisée, accessible.
- Appliquer les contraintes de sécurité (CSP, protections client) en cohérence avec C5.
- Produire des signaux d’usage exploitables (télémétrie, événements) vers C8.

### 4) Invariants
- Les identités et sessions doivent respecter le cadre fédéré (pas d’IAM “shadow”).
- Les données sensibles doivent être minimisées côté client.

### 5) Interfaces adjacentes
- **C6 ↔ C7** : consommation des APIs, orchestration des parcours.
- **C7 ↔ C8** : émission d’événements, métriques d’usage, feedback.

### 6) Artefacts & preuves
- Releases UI versionnées, hashées, reproductibles.
- Matrice de compatibilité (navigateurs), preuves d’accessibilité (selon exigences).
- Schémas d’événements d’usage.

### 7) Exigences opérationnelles
- CDN/cache si nécessaire (via C5 ou services tenant), objectifs de performance.

### 8) Anti‑patterns
- Secrets dans le client.
- APIs “direct to C4/C3”.
- UX qui impose des dépendances non portables (services externes non maîtrisés).

### 9) Exemples de mise en œuvre
- SPA/SSR, apps mobiles, design system, analytics events.

---

## C8 — Conscience cognitive (Tenants)
### 1) Rôle vital (justification)
C8 existe pour transformer l’usage et les données en **connaissance** : analytique, recherche, IA, décision.  
Sans C8 : aucun apprentissage, aucune optimisation, aucune “mémoire” structurée.

### 2) Constitution (périmètre)
**Inclut :**
- Pipelines data, entrepôts/lacs tenant, modèles ML/IA, recherche sémantique.
- Gouvernance des données tenant (catalogue, qualité, lineage) au niveau tenant.
- Tableaux de bord décisionnels, recommandations.

**Exclut :**
- Gouvernance fédérée globale (C3) sauf exigences minimales de conformité.
- Runtime de produit (C6/C7) — C8 consomme des événements/données.

### 3) Responsabilités
- Mettre en place la boucle d’apprentissage (collecte → traitement → décision → action).
- Assurer la qualité, la confidentialité et la minimisation des données.
- Fournir des signaux remontants utiles (insights) vers C6/C7 et, sous forme agrégée, vers C3 si requis.

### 4) Invariants
- Les données tenant restent sous contrôle tenant (politiques, rétention, accès).
- Toute dérivation de données doit être justifiable (finalité, minimisation).

### 5) Interfaces adjacentes
- **C7 ↔ C8** : réception des signaux d’usage et feedback.
- **C8 ↔ (retour vers C7/C6)** : recommandations, scores, décisions (toujours via contrats adjacents).

### 6) Artefacts & preuves
- Jeux de données versionnés si applicable, schémas, lineage.
- Modèles versionnés, évaluations, cartes de modèles (selon maturité).
- Politiques de rétention et accès.

### 7) Exigences opérationnelles
- Sauvegardes / réplication des données analytiques selon criticité.
- Contrôles d’accès robustes (données sensibles).

### 8) Anti‑patterns
- “Aspirer toutes les données” sans finalité.
- Modèles non versionnés, non testés, non auditables.
- Mélange de données tenants sans cloisonnement.

### 9) Exemples de mise en œuvre
- ELT/ETL, lakehouse, BI, vector store, pipelines ML.

---

# 5. Annexes (recommandées)

## A) Tableau de responsabilité (ownership)
- **C1–C4 : Fédération** (opération + gouvernance).
- **C5 : Fédération (service commun) + slices tenant** (config/politiques par tenant).
- **C6–C8 : Tenants** (opération + données + produits).

## B) Checklist “preuve minimale” par couche (MVP conformité)
- C1 : inventaire + runbooks + tests énergie.
- C2 : topologie + DNS autoritatif + journal de changements.
- C3 : IAM + audit + politiques publiées.
- C4 : forge + registry + signature + sauvegarde + SBOM minimal.
- C5 : routage tenant-aware + logs + quotas + config versionnée.
- C6 : manifests + sauvegardes données + healthchecks + API contracts.
- C7 : releases reproductibles + schéma événements usage.
- C8 : politiques données + versioning modèles + lineage minimal.

## C) Gouvernance du changement (CRB)
Toute modification de périmètre d’une couche (inclusion/exclusion, interfaces, invariants) doit :
1) être proposée comme **Avis de Réalignement (CRB)**,
2) inclure impact sur portabilité, séparation, conformité,
3) produire une mise à jour versionnée de ce SSOT.

---


---

## 6. Annexe D — Contrôles de conformité (Label Prestige)
Pour l’attribution du Label et l’audit pair-à-pair, utiliser l’annexe dédiée :
- `06_AnnexeD_Controles_Conformite_Label_Prestige_par_Couche_v1.0.md`