alliance-boreale/docs/architecture/10 - Les 8 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 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.