Bus), prod inchangée¶

Date : 2026-06-17 Catégorie : A (convention transverse) Décideur : Lead architecte DYNORS — validé CTO Statut : Acceptée (cible) — implémentation par paliers S'appuie sur : [[0017-couloir-lane-unite-execution-explicite]], [[0014-cookies-isolation-par-app-pas-de-sso-implicite]], [[0015-sso-interne-echange-explicite-portail]], [[0008-secret-transit-sly-par-app]] Sources : étude §Partie 7 ; claude-handoff-dynors/DYNORS_SLY_URL_GOVERNANCE_PORTAL.md, DYNORS_URL_CONVENTION_RULES.md ; dynors-platform/selebeyone/src/main/java/com/dynors/sly/**

Contexte¶

Trois conventions d'URL hors-prod coexistent et divergent : {sous-app}.{app}-{suffix}.dynors.com, sly.{env}.hp.intranet.dynors.com/{app}/{front}, dev-{app}.dynors.com. Décision actée : hors-prod, plus de DNS par application ; tout passe derrière SLY par chemin ; la prod conserve ses domaines de marque propres (TLD variable). SLY est déjà décomposé (selebeyone gateway + sly-portal-service + sly-ui) avec routes dynamiques en base.

Décision¶

Trois plans SLY distincts. Portal (humains, annuaire + SSO launch, ADR-0015) ; Edge (reverse proxy navigateur hors-prod) ; Bus (inter-app machine-à-machine, HMAC transit ADR-0008, actif aussi en prod). Edge et Bus restent deux classes de routes séparées même si même binaire.
Forme d'URL hors-prod (env + couloir aplatis, un label) — amendée 2026-06-30 pour factoriser le segment /api/ redondant :
```
sly-{env}-{lane}.hp.intranet.dynors.com/{app}/{front}/...      (front)
sly-{env}-{lane}.hp.intranet.dynors.com/{app}/v{n}/...         (API, MÊME ORIGINE, sans /api/)
```
→ un seul certificat wildcard *.hp.intranet.dynors.com ; same-origin front↔API (suppression du CORS hors-prod) ; cookies host-only par (env, lane) (ADR-0014).

Marqueur de distinction API vs front : le premier segment après {app}/ commence par v{N} (v1, v2, v10) = API ; sinon (admin/, pwa/, console/, eleve/, ...) = front. Règle non ambiguë car aucun front ne s'appelle v1. SLY route sur cette règle. Le segment api reste réservé (cf. §4) pour éviter ambiguïté future, mais n'apparaît plus dans le chemin nominal.

Cohérence prod ↔ hors-prod : en prod, api.{app}.{tld-marque}/v{n}/... ; hors-prod, sly-{env}-{lane}.hp.intranet.dynors.com/{app}/v{n}/.... Dans les deux cas, pas de doublon api/v{n} — v{n} est la seule version visible côté URL publique. Le backend Spring continue de servir /api/v{n}/** en interne ; l'edge (SLY hors-prod, edge prod devant api.*) réécrit /v{n}/... → /api/v{n}/... côté origin. 3. Les APIs passent aussi par SLY hors-prod (changement vs doctrine antérieure « api. hors portal »). Retrait des DNS hors-prod b2b.{app}-staging, api.{app}-{dev|staging}, dev-{app}, rmoa-{app}, recette.{app}.{client}. 4. Segments de chemin réservés (figés en gouvernance SLY, contrôlés à la création app/front, à Gate 0 SIRRAT, dans Forge et à la création des routes dynamiques) : api internal health ready live metrics actuator management admin-sly callback oauth login logout assets static. api ne peut jamais être un code de front. 5. Priorité de routage explicite : /{app}/v{N}/** (regex ^/{app}/v\d+/) évalué avant /{app}/{front}/**. Le segment historique /{app}/api/** reste accepté en transition (alias) mais n'est plus la cible normative. 6. Production inchangée : domaines propres {sous-app}.{app}.{tld-marque} (TLD variable .com/.sn/autres, exception CTO par produit) ; SLY invisible au navigateur ; seul le Bus reste actif. 7. Routes dérivées de SIRRAT. SLY abandonne le buildTargetUrl codé en dur au profit des routes dynamiques* (DatabaseRouteDefinitionLocator) alimentées par le sly_route_intent que SIRRAT génère par (env, lane, app, front).

Conséquences¶

Positif : convention unique hors-prod ; un seul wildcard ; suppression CORS hors-prod ; isolation cookies par couloir ; prod préservée ; découplage SLY↔convention. Coût : migration progressive des fronts/API derrière SLY ; routage API par chemin à activer ; retrait coordonné des DNS hors-prod ; liste de segments réservés à appliquer partout.

Composants impactés : selebeyone (routes, filtres, priorité), SIRRAT (sly_route_intent par couloir), DNS interne, certificats, environment.ts Angular (apiBase relatif), DYNORS_URL_CONVENTION_RULES.md, règles Cursor URLs.

Alternatives considérées¶

Garder DNS par app hors-prod → écartée (prolifération DNS/certs, CORS).
Couloir/env en sous-domaines pointés (sly.{env}.{lane}.hp…) → acceptable mais impose un certificat par env → écartée pour la forme aplatie (1 wildcard). Reste ouverte si le coût certs/env est jugé acceptable.
API en accès direct hors-prod → écartée (réintroduit DNS par app + CORS).

Plan d'exécution¶

Réconcilier la doctrine URL (3 sources). 2. Émettre/valider le wildcard *.hp.intranet.dynors.com. 3. Activer routes dynamiques + routage API par chemin + priorité + segments réservés. 4. Basculer app par app (commencer interne, ex. JARAAF). 5. Retirer les DNS hors-prod une fois toutes les apps basculées.

Suivi¶

Succès : 0 DNS par app hors-prod actif après bascule ; 0 CORS hors-prod ; toutes les routes hors-prod sous sly-{env}-{lane} ; segments réservés rejetés à la création ; prod inchangée.