6.7 KiB
ADR-C5-CTRL-001 — ERPLibre “cockpit” en tenant opérateur et FastAPI comme plan de contrôle C5
Version : 1.1
Date : 31 janvier 2026
Statut : Adopté
Portée : Pile opérateur de référence (C1–C5), Gouvernance, Admission tenants, Sécurité, Audit
1) Contexte
La pile opérateur de référence fixe C5 comme membrane (point d’entrée unique) entre la Fédération (C1–C4) et les tenants (C6–C8).
C5 doit porter un plan de contrôle : admission, quotas, RBAC, orchestration (runner), production de preuves.
Dans le même temps, un besoin fort émerge : disposer d’un cockpit (portail “au premier plan”) pour piloter la gouvernance opérationnelle (demandes, onboarding, changements, approbations), sans compromettre la membrane.
2) Problème
Deux impératifs doivent coexister :
- C5 doit rester minimal, durci, audit-friendly : la membrane ne doit pas se transformer en suite applicative riche.
- Le pilotage opérationnel doit être ergonomique et fédérateur : un portail/cockpit central améliore l’adoption et la cohérence.
Le risque à éviter : déplacer des privilèges infrastructurels et des intégrations sensibles dans une application riche exposée, au détriment du non-bypass, de l’auditabilité et de la surface d’attaque.
3) Décision
3.1 ERPLibre est “aux commandes” comme cockpit — mais en tant que tenant
ERPLibre est positionné comme cockpit de gouvernance dans un tenant de l’opérateur fédéré (tenant dédié “Gouvernance/Back-office”).
Il pilote le workflow humain (demandes, approbations, dossiers, suivi), et déclenche les actions par contrat, sans privilèges directs sur les couches internes.
ERPLibre est au premier plan (UX, orchestration métier), mais pas le plan de contrôle de la membrane.
3.2 FastAPI demeure le plan de contrôle en C5
FastAPI est maintenu en C5 comme Pivot API / Plan de contrôle pour :
- l’admission (validation des descripteurs),
- l’application des politiques (quotas, conformité),
- l’orchestration d’exécution (runner C5 OpenTofu/Ansible),
- la gestion d’accès (RBAC via Keycloak et services fédérés),
- la production et l’indexation des preuves (audit).
3.3 Règle d’intégration : “Commander par le contrat, pas par des accès directs”
ERPLibre commande via des mécanismes traçables et contrôlés :
- PR + ΔLog (Git comme source de vérité),
- appels API C5 (demande d’exécution et suivi),
- lecture d’état / preuves (status/evidence).
ERPLibre ne doit pas disposer d’accès directs à C2/C3/C4 (DNS autoritatif, IAM admin, secrets admin, forge admin, etc.).
4) Architecture cible (rôle et flux)
4.1 Déploiement et exposition
- ERPLibre est déployé comme workload applicatif dans le tenant “Gouvernance/Back-office” de l’opérateur.
- Il est exposé via C5 (NGINX+ModSecurity) et protégé par SSO (Keycloak), conformément à la membrane.
- ERPLibre n’est pas un composant de C5 : il est un consommateur du plan de contrôle.
4.2 “Git comme source de vérité” (flux recommandé)
- Une demande est créée et approuvée dans ERPLibre (onboarding / changement).
- ERPLibre génère/édite un TenantDescriptor (YAML) et ouvre une PR dans Forgejo avec ΔLog.
- CI (Forgejo Actions) valide : schéma/politiques, lint, et
tofu plan(si applicable). - Sur merge, FastAPI (C5) récupère le YAML (commit SHA), revalide, puis :
- déclenche le runner C5 (OpenTofu/Ansible),
- orchestre RBAC et intégrations nécessaires,
- produit
run_id, journaux, et preuves (evidence pack).
- ERPLibre consulte l’état via C5 (status/runs/evidence) et présente le suivi au demandeur.
4.3 Flux API (complémentaire)
ERPLibre peut appeler C5 pour :
- demander l’exécution d’un changement référencé par
tenant_id + commit_sha, - suivre un
run_id, - afficher les preuves disponibles.
5) Contraintes de sécurité et de conformité (non négociables)
5.1 Membrane / non-bypass
- Tous les flux exposés passent par C5 (NGINX+ModSecurity).
- Aucun accès direct tenant → C2/C3/C4.
5.2 Principe du moindre privilège
- ERPLibre n’obtient jamais de privilèges “infra” larges.
- Les actions à privilèges sont exécutées uniquement via le runner C5, sous contrôle C5.
5.3 Traçabilité
- Tout changement : PR + ΔLog obligatoires.
- Tout provisioning : PR → run_id → logs → preuves indexées.
5.4 Preuves auditables
- C5 produit des preuves standardisées et indexées dans le dépôt
operator-stack/(evidence pack trimestriel, exports, manifests/hashes si adoptés).
6) Justification (pourquoi c’est la solution la plus robuste)
- ERPLibre est idéal pour être un cockpit : workflow humain, dossiers, demandes, suivi, ergonomie.
- C5 doit rester un plan de contrôle minimal : plus un composant est riche à la membrane, plus il est coûteux à sécuriser, patcher, auditer.
- Cette décision maximise l’adoption (ERPLibre visible) sans diluer la rigueur (FastAPI contrôle et prouve).
7) Alternatives considérées
- ERPLibre en C5 (remplacement complet) : rejeté (surface d’attaque, complexité, périmètre flou, audit alourdi).
- FastAPI seul sans cockpit : acceptable techniquement, mais moins fédérateur et moins ergonomique.
- Cockpit alternatif : possible, tant qu’il reste “tenant” et qu’il commande par contrat via C5.
8) Critères d’acceptation
La décision est considérée opérationnelle lorsque :
- ERPLibre est déployé dans un tenant dédié “Gouvernance/Back-office” de l’opérateur et exposé via C5.
- SSO Keycloak protège ERPLibre (et les portails) via la membrane.
- ERPLibre génère/édite un TenantDescriptor et ouvre une PR + ΔLog dans Forgejo.
- FastAPI en C5 valide et orchestre l’exécution via runner C5, produisant un
run_id. - Les preuves sont déposées et indexées (operator-stack/evidence/…), consultables via C5.
- Un test de non-bypass démontre l’impossibilité d’accès direct tenant → C2/C3/C4.
9) Impacts sur la pile opérateur de référence
- Aucun changement à la pile C1–C5 : FastAPI reste en C5.
- Ajout d’un tenant opérateur dédié (workload) : ERPLibre devient une application “premier plan” consommant le plan de contrôle C5.
10) ΔLog (à compléter au commit)
- Décision : ERPLibre cockpit en tenant opérateur ; FastAPI plan de contrôle C5 ; commande par contrat (PR+ΔLog+API)
- Auteur(s) : __________________
- Référence PR : __________________
- Date d’entrée : __________________