Aller au contenu

ADR-0016 — Nomenclature des environnements : LOCAL/DEV/INT/RMOA/PRODUCTION (+ PREPROD réservé)

Date : 2026-06-17 Catégorie : A (convention transverse) Décideur : Lead architecte DYNORS — validé CTO (étude docs/ETUDE_ENVIRONNEMENTS_SLY_UNITES_EXECUTION_CENTRE_SERVICES.md) Statut : Acceptée (cible) — implémentation par paliers S'appuie sur : [[0017-couloir-lane-unite-execution-explicite]], [[0009-taxonomie-templates-deploiement]] Sources : étude environnements §Partie 5 ; SirratEnvironment.java ; .cursor/rules/api-urls-prod-vs-local.mdc

Contexte

L'enum SirratEnvironment actuel (LOCAL, DEV, RMOA_DYNORS, RMOA_CLIENT, PRODUCTION) confond la qualification technique et l'acceptation métier dans RMOA_DYNORS, et fromCode mappe recette → RMOA_DYNORS. Le besoin exprimé sépare une étape technique (E2E, non-régression, intégration, tests SLY/rôles) d'une étape métier (validation MOA, PV). « RECETTE » comme nom de l'étape technique entre en collision avec « RMOA » (= Recette Maîtrise d'Ouvrage).

Décision

Chaîne d'environnements cible :

LOCAL → DEV → INT → RMOA → PRODUCTION
  1. INT (« Intégration & qualification ») est l'environnement technique : E2E, non-régression, intégration complète, tests inter-app SLY, tests de rôles/habilitations, qualification interne avant RMOA. Le mot « recette » est réservé à RMOA (acceptation métier / PV).
  2. RMOA = validation métier. On ne distingue plus RMOA_DYNORS / RMOA_CLIENT comme cercles : l'opérateur, l'hébergement et la responsabilité de recette deviennent des attributs (operated_by, hosting, acceptance) — cf. [[0019-modele-sirrat-dimension-couloir]].
  3. PREPROD est un code d'environnement réservé, non instancié maintenant. Il deviendra un environnement distinct uniquement si l'écart technique RMOA↔PROD devient significatif (topologie, réseau, sécurité, secrets/certs, données/migrations, capacités, supervision, sauvegarde/restauration, rollback, exploitation) ou sur exigence contractuelle/réglementaire. preprod est interdit comme lane_code (éviter l'ambiguïté env vs couloir).
  4. Migration recette déterministe : recette, staging, rmoa-dynors, rmoa-client → RMOA. Aucun déploiement historique ne devient INT automatiquement ; INT n'existe que par création explicite avec le code neuf int.

Conséquences

Positif : séparation nette qualification technique / acceptation métier ; suppression de l'ambiguïté recette/RMOA ; modèle d'environnements stable et extensible (PREPROD prévu sans dette). Coût : amender l'enum + fromCode (alias dépréciés avec date de suppression) ; migrer variables CI/CD et configs SIRRAT ; communication équipes.

Composants impactés : SirratEnvironment, fromCode, templates SIRRAT Forge, pipelines CI, .cursor/rules/api-urls-prod-vs-local.mdc, sirrat-concept.md.

Alternatives considérées

  • Garder RECETTE pour l'étape technique → écartée (collision sémantique avec RMOA).
  • QUALIF au lieu de INT → acceptable, écartée pour la concision ; INT plus universel.
  • Créer PREPROD maintenant → écartée (sur-architecture ; un couloir RMOA rc suffit aujourd'hui).
  • Conserver RMOA_CLIENT comme cercle → écartée (attributs plus souples, cf. 0019).

Plan d'exécution

  1. Ajouter INT à l'enum, réserver PREPROD (non émis). 2. fromCode : alias dépréciés recette/staging/rmoa-dynors/rmoa-client → RMOA avec warning + date de retrait. 3. Inventaire des usages recette (CI, configs SIRRAT, docs). 4. Migration données (déploiements historiques recette restent RMOA). 5. Mise à jour docs/règles.

Suivi

Succès : 0 occurrence de recette ambigu en base après la fenêtre de migration ; INT actif et porteur des E2E ; aucun déploiement recette→INT constaté ; aucun lane_code = preprod.