ADR-0035 — Granularité et contrat du Layer 3 (CODEX_APP_TECH_CODE)¶
Date : 2026-09-01
Catégorie : A (convention d'identité et de sécurité transverse)
Statut : ACCEPTÉE — 2026-09-01, après vérification des six points de contrôle (§27.5)
Réalise / amende : ADR-0008 (secret de transit SLY par app), ADR-0011 (audience JWT),
IDENTITE_APPLICATIVE_3_LAYERS.md
Traite : R-211, R-212, R-213, R-214
1. Contexte¶
IDENTITE_APPLICATIVE_3_LAYERS.md (2026-06-11) définit trois identités applicatives. Un an
d'usage et deux renommages réels ont montré que la granularité du Layer 3 n'a jamais été
tranchée : la table autoritaire §4 raisonne par produit, ADR-0008 raisonne par backend, et deux
seeds récents appliquent deux règles opposées.
2. Problème¶
À quel objet appartient CODEX_APP_TECH_CODE ? Sans réponse, quatre défauts subsistent :
supergest-acquisitionappelle via SLY sans code technique (R-211) ;- deux conventions de chemin Vault coexistent (R-212) ;
- SLY replie silencieusement sur le slug quand le mapping manque (R-213) ;
- la table autoritaire est périmée sans qu'on sache ce qu'elle doit lister (R-214).
3. Invariants déjà établis — non rediscutés¶
name identité métier / marque MUTABLE
appCode identité applicative lisible et routable RARELY_MUTABLE_WITH_MIGRATION
appTechCode identifiant technique opaque, immuable et
non recyclable d'une identité applicative
technique IMMUTABLE
Preuve empirique principale — MEDICONNECT → MEDISEN → DOSALI (2026-07-31, 2026-08-18) :
name change, appCode change (1 871 fichiers, alias SLY en cascade, migration Vault),
med survit. Les deux ADR de rebrand ne mentionnent ni aud, ni techCode : zéro occurrence.
Acquis complémentaires : pas de quatrième identifiant slug — appCode remplit ce contrat.
Et appTechCode ≠ aud : l'audience est un usage du Layer 3.
4. Options¶
| Option | Règle | |
|---|---|---|
| A | Layer 3 = Product | toutes les unités d'un produit partagent le code |
| B | Layer 3 = Deployable Application | chaque unité déployable a le sien |
| C | Granularités multiples | un identifiant par mécanisme (JWT, Vault, SLY, IAM) |
| B′ | Layer 3 = unité de confiance | (proposée ici — voir §11) |
5. Forces en tension¶
| Force | Pousse vers |
|---|---|
| Moindre privilège, blast radius (ADR-0008) | B |
| Opacité du realm (ADR-0011 §5) | indifférent |
| Économie de gouvernance — un code à allouer, unique, non recyclable | A |
| Lisibilité mnémonique du format 3 lettres | A |
| Stabilité au rebranding | indifférent — le Layer 3 est immuable dans tous les cas |
| Simplicité du modèle mental | A |
6. Analyse sécurité¶
Le Layer 3 est la graine de dérivation du secret de transit :
k_app = HKDF-SHA256(forwardRootKey, "sly-transit:" + CODEX_APP_TECH_CODE)
Conséquence directe et non contournable : deux unités partageant un Layer 3 partagent leur clé
de transit. ADR-0008 énonce précisément l'inverse : « chaque backend reçoit uniquement son
propre k_app […] jamais les clés des autres apps », avec pour motif « sensibilité haute,
moindre privilège ».
Appliqué au cas réel : supergest-acquisition est une façade publique — surface d'exposition
maximale, aucune session humaine, donc aucun mécanisme d'authentification à compromettre en amont.
Lui donner sgt reviendrait à placer, sur la machine la plus exposée du produit, la clé qui
authentifie les appels du backend métier. Rotation, compromission et périmètre d'audit
deviendraient communs.
C'est l'argument le plus fort, et il est asymétrique : Option A crée un risque réel ; Option B crée un coût de gouvernance. Un risque de sécurité et un coût administratif ne se compensent pas.
7. Analyse rebranding¶
Le Layer 3 étant immuable par construction, aucune option n'est affectée par un rebranding.
Le rebranding tranche autre chose : il prouve que appCode ne peut pas ancrer les secrets — ce qui
règle R-212 (§23), indépendamment de la granularité.
8. Cas SUPERGEST Acquisition — le discriminant¶
| SuperGest principal | supergest-acquisition |
|
|---|---|---|
| Déploiement | indépendant | indépendant (template dynors-public-facade) |
| Base, session humaine, frontend | oui | non |
| Appelle via SLY | oui | oui (outboundVia: sly:ragnar) |
Besoin d'aud |
oui | non |
| Besoin d'une clé de transit | oui | oui |
| Layer 3 aujourd'hui | sgt |
absent |
Option A : sga n'existe pas, la façade utilise sgt → partage de clé (§6).
Option B : sga, aud absent, clé de transit propre → conforme à ADR-0008.
9. Cas LICENSING — et il faut être honnête : ce n'est pas la preuve qu'il paraissait¶
lic existe (seed 044) hors de la table §4. J'ai d'abord lu cela comme une preuve d'Option B.
C'est contestable. dynors-platform est un monorepo, pas un produit : il contient SLY,
auth, licensing — et ADR-0011 §4 traite déjà SLY comme une ligne à part entière
(SelebeYone | sly | sly). licensing est donc plausiblement un service de plateforme de plein
droit, pas une unité déployable d'un produit « dynors-platform ».
Si cette lecture est la bonne,
licest une application d'Option A à une entité oubliée de la table — pas une preuve d'Option B. Le cas ne discrimine pas. Il ne reste qu'un seul cas discriminant réel :supergest-acquisition.
10. Cas DAWALALE — le contre-exemple qui borne la règle¶
Un projet, 28 stacks (cercles × couloirs), 8 fronts — et une seule identité daw.
Les fronts partagent le processus, la session, le secret. La composition ne crée pas d'identité :
il faut une frontière de déploiement et de secret, pas une frontière d'écran.
name = DAWALALE · appCode = dawalale · appTechCode = daw · tenantCode = dawalale · aud = daw
L'égalité appCode = tenantCode est prévue (CODES_ET_IDENTIFIANTS_PROJETS.md, 2025) et ne
fusionne pas les concepts : appCode dit quel logiciel, tenantCode dit quel espace de
données.
11. Décision recommandée — Option B′¶
Le Layer 3 ne découpe ni les produits, ni les déploiements : il découpe les frontières de confiance.¶
Une unité de confiance est une identité applicative technique nécessitant une isolation de sécurité propre. La détention de secrets, la validation de jetons, l'identité cryptographique ou l'application d'un périmètre IAM distinct en sont des critères observables — non limitatifs.
Définition ouverte, délibérément. Une énumération fermée (« détient un secret ou valide des jetons ») serait juste aujourd'hui et fausse demain : mTLS, signature KMS, attestation matérielle, ou un mécanisme qu'on n'utilise pas encore imposeraient de réécrire l'ADR. Le critère est la nécessité d'isolation ; les mécanismes en sont les manifestations observables.
Critère d'attribution, en une question :
Cette unité a-t-elle besoin d'une isolation de sécurité qui lui soit propre ?
OUI → elle a son Layer 3
NON → elle n'en a pas
Conséquence architecturale majeure¶
appTechCoden'est PAS obligatoire pour toute unité déployable.Une unité peut légitimement avoir un
appCode, être déployée indépendamment, et n'avoir aucun Layer 3. C'est le cas d'un frontend statique : déployable, routable, sans secret ni jeton à valider.
Product SUPERGEST
│
├── Deployable frontend statique
│ appCode = supergest-web
│ appTechCode = ∅ ← aucune isolation propre requise
│
├── Trust Unit backend SuperGest
│ appCode = supergest
│ appTechCode = sgt
│
└── Trust Unit Acquisition
appCode = supergest-acquisition
appTechCode = sga
Pourquoi B′ plutôt que B strict. « Unité déployable » est trop large : un portail Angular
statique (dynors-angular-portal) est déployé indépendamment mais ne détient aucun secret et ne
valide rien — lui allouer un code immuable et non recyclable serait de la bureaucratie sans objet.
Le critère de détention de secret trace la frontière exactement là où ADR-0008 la place.
Pourquoi B′ plutôt que A. §6 : partager le code, c'est partager la clé. Le seul cas réel est précisément une façade publique.
Pourquoi pas C. Multiplier les identifiants par mécanisme démultiplierait la gouvernance
(quatre allocations, quatre tables, quatre risques de dérive) pour résoudre un problème que B′
résout avec un identifiant. Et aud n'est pas un identifiant distinct : c'est la projection du
Layer 3 dans le JWT, présente seulement quand l'unité authentifie des humains. C reposerait sur
une confusion que cet ADR corrige.
Statut de la preuve — principe architectural fort, cardinalité observée faible¶
À inscrire tel quel dans le dossier, et à ne pas confondre :
| Principe | FORT. Une frontière de sécurité démontrée suffit à invalider une règle « un Layer 3 par Product ». Ce n'est pas le nombre d'occurrences qui décide, c'est l'existence d'une frontière qui ne doit pas être franchie. |
| Cardinalité observée | FAIBLE. Un seul cas réel discrimine (supergest-acquisition) ; licensing ne tranche pas (§9). |
Nous ne sursoyons pas. Une seule façade publique qui ne doit pas partager la clé du backend suffit : attendre un second cas reviendrait à maintenir sciemment une règle dont on a déjà la réfutation.
Ce qui rend la décision solide plutôt que spéculative : le catalogue de templates déjà seedé —
dynors-worker, dynors-public-facade, dynors-angular-portal, dynors-pos,
dynors-platform-auth — montre que DYNORS modélise déjà des natures d'unités déployables
au-delà du backend de produit. Ce ne sont pas des applications hypothétiques : ce sont des objets
gouvernés, présents en base. B′ formalise une granularité que le modèle porte déjà.
12–14. Contrats finaux¶
name — identité métier et marque. Casse libre, accents, espaces. Consommateurs : UI,
communication, contrats, catalogue. MUTABLE. Porté par le Product.
appCode — identité applicative lisible et routable. Kebab/snake, minuscules. Consommateurs :
routage SLY, X-Source-App, hostname public, CI/CD, sirrat_projects.application, repo Git,
package Java, chemins Vault applicatifs. RARELY_MUTABLE_WITH_MIGRATION — changement possible,
avec alias déprécié et migration. Porté par l'unité déployable.
appTechCode — identifiant technique opaque, immuable et non recyclable d'une identité
applicative technique. Consommateurs : aud JWT (si applicable), dérivation HKDF du transit SLY,
rôle et chemins de secret Vault, scope IAM machine, champ app des logs d'audit.
IMMUTABLE · UNIQUE · NON RECYCLABLE. Porté par l'unité de confiance.
15. Convention nominale — 3 lettres, et politique d'allocation¶
^[a-z]{3}$
Fondement empirique : les 16 codes réels — boo daw eli fis hei jar lic med pai rag red sgt sir
sly tak tra — font tous exactement 3 lettres. Aucun n'utilise 4 lettres, aucun n'utilise de
chiffre.
15.1 Le vrai risque n'est pas l'épuisement, c'est la collision¶
B′ augmente le nombre de codes par produit. Il faut donc une règle d'allocation. Mais posons d'abord la capacité réelle :
Espace ^[a-z]{3}$ |
17 576 |
| Codes réservés | 41 (sys api www prod test rmoa fra eng wol …) |
| Codes alloués aujourd'hui | 16 |
| Occupation | 0,09 % |
L'épuisement n'est pas un risque — même à 200 unités de confiance, on serait à ~1 %. Le risque
réel est la collision mnémonique : « SuperGest Acquisition » et « SuperGest Admin » réclament
tous deux sga.
15.2 Règle d'allocation retenue — mnémonique dérivée du nom de l'unité¶
C'est la règle déjà appliquée aux 16 codes existants, sans exception :
daw←DAWALALE fis←FISCAL sgt←SuperGesT tak←TAKKU sir←SIRRAT boo←BOOKS
pai←PAIEMENT jar←JARAAF tra←TRACIUM rag←RAGNAR red←RED sly←SLY
hei←HEISENBERG med←MEDISEN eli←ELISA lic←LICENSING
Sous B′, on ne change rien : le code dérive du nom de l'unité de confiance, exactement
comme il dérivait du nom du produit — SuperGest Acquisition → sga. Aucun mécanisme nouveau.
Options écartées, et pourquoi :
| Option | Verdict |
|---|---|
Préfixe produit + lettre d'unité (sg + t/a) |
Rejeté — incompatible avec l'existant (sgt est l'abréviation de SuperGesT, pas sg+t), et plafonne à 676 produits |
Codes séquentiels opaques (a01, a02) |
Rejeté — opacité maximale, mais coût d'exploitation prohibitif : aucun opérateur ne lit un chemin Vault dynors/prod/a07/ |
| Allocation libre sans règle | Rejeté — arbitrages sans critère, débats sans fin |
15.3 Résolution de collision — jamais par un chiffre¶
En cas de collision, on choisit une autre mnémonique (SuperGest Admin → sgm, sad…).
Interdit : suffixer un chiffre pour désambiguïser. Les chiffres sont réservés au mécanisme de filialisation (§16). Les mêler rendrait
sga2ambigu — seconde unité, ou filiale desga? Les deux mécanismes doivent rester orthogonaux.
15.4 Le mnémonique est une commodité d'allocation, pas une propriété permanente¶
med ne veut plus rien dire depuis que MEDISEN est devenu DOSALI. Ce n'est pas un défaut : c'est
le modèle qui fonctionne. Le Layer 3 est opaque par conception (ADR-0011 §5) ; sa lisibilité
initiale n'existe que pour faciliter l'allocation et l'exploitation courante.
Cela dissout l'inquiétude d'« érosion mnémonique » soulevée en §26. Un code qui cesse d'évoquer son unité n'est pas une dette — c'est un identifiant opaque qui a fini de le devenir.
15.5 Mécanismes déjà en place — rien à construire¶
Vérifié : uk_sirrat_projects_app_tech_code (UNIQUE) et
ck_sirrat_projects_app_tech_code_format (format) existent en base depuis la migration 013.
TechCodeValidator (TAKKU) et JwtProductionReadinessValidator (core) valident déjà format et
réservés. La politique d'allocation s'appuie sur l'outillage existant ; aucun mécanisme nouveau
n'est requis.
16. Extension exceptionnelle¶
La regex ^[a-z]{2,4}[0-9]{0,2}$ est une extension volontaire documentée, motivée par la
filialisation (daw → daw2), et explicitement non actée.
Décision : la conserver comme mécanisme exceptionnel, distinct de la convention nominale.
La regex d'implémentation reste inchangée (permissive, donc compatible) ; c'est la doctrine
d'allocation qui impose 3 lettres. Toute allocation hors ^[a-z]{3}$ doit être justifiée et
tracée au registre.
Réserve maintenue :
daw2ne serait pas un code nouveau mais une variante dérivée d'un code parent. Cela pose une question de modèle — une entité ou deux ? — que la convention n'aborde pas. À traiter si la filialisation s'actualise, et sans empiéter sur §15.3.
17–21. Conséquences¶
JWT — appTechCode ≠ aud. L'audience est la projection du Layer 3 dans le token, présente
seulement si l'unité valide des jetons utilisateur. Une unité peut légitimement avoir
appTechCode = sga et aucun aud.
SLY — le routage reste sur le Layer 2 (ADR-0011 §5, inchangé). La dérivation de transit
reste sur le Layer 3. La table SLUG_TO_TECH_CODE devient une table de gouvernance, pas
une commodité (§23, R-213).
Vault — deux familles de chemins, désormais distinguées :
secrets applicatifs → dynors/{env}/{appCode}/… (base, notify, etc.)
secrets d'identité → dynors/{env}/{appTechCode}/… (sly-transit, rôle d'auth)
IAM — le scope machine, quand il sera instancié, s'adosse au Layer 3.
SIRRAT / CI — inchangés : ils raisonnent en Layer 2. sirrat_projects conserve les trois
colonnes ; application reste la clé fonctionnelle d'autorisation (3.G.2b).
22. Migration SHARED → DUAL → PER_APP¶
B′ est compatible et bloquante dans le bon sens : aucune unité ne peut passer en PER_APP sans
Layer 3. La trajectoire d'ADR-0008 devient donc le calendrier d'allocation des codes manquants.
supergest-acquisition est le premier cas.
23. Traitement des dettes¶
R-211 — supergest-acquisition sans code technique.
→ Allouer sga. Sans conséquence en SHARED ; prérequis au passage PER_APP.
R-212 — contradiction Vault {app} vs {techCode}.
→ Tranchée en faveur du techCode pour les secrets d'identité. Motif décisif : le rebranding
DOSALI a imposé « migration des valeurs Vault à planifier » parce que les chemins étaient indexés
sur appCode. Un changement de marque ne doit pas provoquer la rotation d'une identité
cryptographique quand l'unité technique n'a pas changé. ADR-0008 §46/§92 est amendé :
dynors/{env}/{appTechCode}/sly-transit#key. Les secrets applicatifs restent sur appCode.
R-213 — repli silencieux getOrDefault(sourceApp, sourceApp).
→ Doctrine : FAIL CLOSED. Si le Layer 3 est une identité de sécurité gouvernée, l'absence de
mapping est une erreur de gouvernance, pas un cas nominal. Se replier sur le slug annule les
trois propriétés du Layer 3 — opacité, immuabilité, unicité — au moment précis où elles comptent.
En PER_APP, l'absence de mapping doit refuser. (Correctif non appliqué ici.)
R-214 — table §4 périmée. → Elle démontre exactement la thèse : Layer 1 mutable, Layer 2 mutable, Layer 3 stable. La table doit devenir un registre gouverné des unités de confiance, tenu à jour, et le test de contrat de SLY doit s'y adosser.
24–25. Compatibilité¶
ADR-0008 — renforcé sur le fond (moindre privilège par unité détentrice de secret), amendé
sur la forme (chemin Vault en appTechCode).
ADR-0011 — inchangé sur le routage (Layer 2) et sur l'opacité. Précisé sur un point :
la table §4 liste des produits ; elle doit lister des unités de confiance.
26. Risques et questions restantes¶
- Cardinalité observée faible (n = 1). Principe fort, validation empirique mince (§11). Atténué par le catalogue de templates seedé — non supprimé.
- ~~Érosion mnémonique~~ — levée en §15.4. Un code qui cesse d'évoquer son unité est un identifiant opaque qui a fini de le devenir, pas une dette.
- Statut de
licensing(§9) — service de plateforme ou unité déployable ? Non tranché, sans effet sur la décision. - Filialisation (§16) — variante dérivée ou entité nouvelle ?
audabsent — aucun mécanisme ne vérifie qu'une unité sansaudne reçoit pas de jeton utilisateur. À couvrir séparément.- Qui alloue ? §15 fixe comment allouer, pas qui décide. L'ADR-0007 (gouvernance catégories A/B/C) devrait couvrir ce point — non vérifié dans cet ADR.
27. Autorité d'allocation — TAKKU orchestre, le registre canonique attribue¶
27.1 La distinction, et pourquoi elle est structurante¶
TAKKU porte le workflow d'onboarding et la proposition du code. TAKKU n'est PAS propriétaire du registre canonique des identités applicatives.
L'archéologie a établi qu'un concept a un propriétaire (ADR-01, règle 1) et que TAKKU possède Projet, mission, affectation, charge, planning — pas l'identité applicative de l'écosystème. Faire de TAKKU le registre reviendrait à lui attribuer par commodité un concept que la carte des contextes ne lui donne pas.
TAKKU = ORCHESTRATEUR DU WORKFLOW ≠ PROPRIÉTAIRE DE L'IDENTITÉ
27.2 Responsabilités de TAKKU¶
Recueillir les informations · déclencher la création · générer une proposition de
appTechCode · effectuer un pré-check (format, réservé, disponibilité apparente) ·
proposer une autre mnémonique en cas de collision · présenter le résultat · appeler le
propriétaire canonique pour demander l'allocation.
name = SuperGest Acquisition
proposition : appTechCode = sga
pré-check : format ✓ réservé ✗ collision ✗
→ demande d'allocation
La génération est une facilité d'onboarding et de gouvernance, pas une autorité.
27.3 Autorité canonique — responsabilité, pas composant¶
Le registre canonique doit garantir : format valide · non réservé · unique · non recyclé · allocation définitive et atomique.
TAKKU ── propose sga ──▶ Application Identity Registry
├── format ?
├── réservé ?
├── déjà alloué ?
├── historiquement consommé ?
└── allocation ATOMIQUE ──▶ sga
Application Identity Registrydésigne une responsabilité architecturale, pas un composant à créer. Cet ADR n'introduit aucun microservice. Son porteur concret reste à déterminer dans le patrimoine existant.Indice à verser au dossier :
IDENTITE_APPLICATIVE_3_LAYERS.md§6 énonce déjà que l'appTechCode« doit être unique danssirrat_projects» — l'autorité d'unicité de fait est donc la table SIRRAT, tandis que TAKKU est le point de saisie. Le document normatif n'attribue nulle part la propriété canonique à TAKKU (vérification §27.4-6).
27.4 Concurrence — pré-check ≠ réservation¶
Deux onboardings simultanés peuvent proposer le même code. La seule garantie est la chaîne complète :
proposition TAKKU + validation canonique + contrainte UNIQUE / transaction
Le registre refuse la seconde allocation ; TAKKU propose alors une autre mnémonique. La disponibilité calculée par TAKKU n'est jamais une garantie.
27.5 Vérification des six points de contrôle¶
| # | Point | Résultat |
|---|---|---|
| 1 | Contrainte d'unicité en base | ✅ uk_sirrat_projects_app_tech_code (migration 013, changeset 065) |
| 2 | Contrainte de format | ✅ ck_sirrat_projects_app_tech_code_format — CHECK (… ~ '^[a-z]{2,4}[0-9]{0,2}$') |
| 3 | Validateurs | ✅ TechCodeValidator (TAKKU) + JwtProductionReadinessValidator (core) + seed Forge |
| 4 | Suppression physique possible ? | ⚠️ Aucun endpoint DELETE sur ProjectController, et un drapeau active existe (retrait logique). Mais SirratProjectRepository étend JpaRepository : delete() reste techniquement accessible au code. |
| 5 | Non-recyclage historique garanti ? | ❌ NON. Aucune table d'historique des codes consommés. La contrainte UNIQUE porte sur les lignes vivantes : une ligne supprimée libérerait son code. |
| 6 | Un document plus ancien attribue-t-il la propriété canonique à TAKKU ? | ✅ Non. IDENTITE_APPLICATIVE_3_LAYERS.md §6 décrit TAKKU comme point de saisie et nomme sirrat_projects comme autorité d'unicité. Aucune contradiction. |
1–3 confirmés · 4–5 révèlent une dette · 6 sans obstacle ⇒ ADR ACCEPTÉ, dette ouverte, rien corrigé.
27.6 R-215 (nouvelle dette) — le non-recyclage n'est pas garanti¶
UNIQUEgarantit l'unicité actuelle, pas la non-réutilisation historique.ADR-0011 pose pourtant : « pas de recyclage — un audit log porte ce code en histoire ». Cette propriété repose aujourd'hui sur une pratique (« on ne supprime pas de projet ») et non sur une contrainte. Un
delete()programmatique rendrait le code réallouable, et un futur porteur hériterait silencieusement de l'historique d'audit d'un autre.Non corrigé ici. Une garantie réelle demanderait soit un registre d'allocation en append-only, soit l'interdiction explicite de la suppression physique. À traiter avec le porteur du registre canonique (§27.3), pas avant.
27.7 Conséquence UX — constatée, non conçue¶
L'utilisateur ne devrait normalement pas avoir à inventer le code :
Nom SuperGest Acquisition
appCode supergest-acquisition
appTechCode proposé sga ✓ disponible
Aucun écran n'est conçu ici — c'est une conséquence de la décision, pas une spécification.
Décision finale — synthèse normative¶
| Élément | Contrat |
|---|---|
name |
Identité métier/humaine. Mutable. |
appCode |
Identité applicative lisible et routable. Rarement mutable, avec migration. |
appTechCode |
Identité technique opaque d'une unité de confiance. Immuable · unique · non recyclable. Optionnelle pour une unité déployable ne nécessitant aucune isolation de sécurité propre. |
| Unité de confiance | Identité applicative technique nécessitant une isolation de sécurité propre. Mécanismes observables — secret propre, validation de jetons, identité cryptographique, périmètre IAM distinct, mTLS, KMS, équivalents futurs. Cette liste n'est pas la définition. |
| Allocation | TAKKU orchestre et propose ; le registre canonique valide et attribue. |
| Format nominal | 3 lettres minuscules. |
| Collision | Autre mnémonique. Jamais un chiffre. |
| Chiffres | Réservés au mécanisme exceptionnel de filialisation, s'il est un jour acté. |
| JWT | aud est un usage éventuel du Layer 3, pas sa définition. |
| SLY / Vault | Les identités et secrets cryptographiques stables s'ancrent sur le Layer 3 lorsqu'ils représentent l'unité de confiance. |
| Mapping absent | FAIL CLOSED dès qu'un mécanisme de sécurité exige le Layer 3. |
Aucune modification de code, de migration ou de provisioning n'accompagne cet ADR.