ADR — Architecture Decision Records¶
Registre des décisions d'architecture DYNORS prises en autonomie par le lead architecte (catégorie A) ou proposées avec délai d'objection (catégorie B). Voir
gouvernance-architecte-et-defauts.mdpour le cadre.
Format¶
Chaque ADR fait moins de 2 pages. Format minimaliste :
- Contexte (pourquoi)
- Décision (quoi, précisément)
- Conséquences (bénéfices, coûts, composants impactés)
- Alternatives considérées
- Plan d'exécution
- Suivi (critères de succès)
Registre¶
| Numéro | Titre | Date | Statut | Catégorie |
|---|---|---|---|---|
| ADR-0001 | Introduction de TaxAuthorityAdapter comme abstraction multi-juridiction FISCAL |
2026-05-07 | Acceptée | A |
| ADR-0008 | Secret de transit SLY par application et trajectoire mTLS | 2026-06-10 | Acceptée (palier 1 implémenté 2026-06-11) | A |
| ADR-0009 | Taxonomie des templates : deployment_audience × tenancy × scenario × gouvernance + catalogue élargi 15 templates | 2026-06-10 (amendée 2026-06-21) | Acceptée | A |
| ADR-0010 | Exécution des payouts, FinancialPolicyProvider (table versionnée Groupe), maker-checker, événements d'intégration |
2026-06-10 (amendée 2026-06-21) | Acceptée | B |
| ADR-0011 | Scoping des JWT par audience (realm) et durcissement des tokens | 2026-06-10 | Acceptée (implémentée 2026-06-11) | A |
| ADR-0012 | Helm comme packaging K8s, rendu double depuis SIRRAT | 2026-06-10 | Proposée | A |
| ADR-0013 | JWT asymétrique (RS256) + kid/JWKS et rotation des clés — réalise le palier 2 d'ADR-0011 |
2026-06-14 | Acceptée (implémentée 2026-06) | A |
| ADR-0014 | Cookies isolés par app (host-only __Host-), token distinct par app, pas de SSO implicite par cookie |
2026-06-17 | Acceptée | A |
| ADR-0015 | SSO interne par échange explicite (portail) : code opaque single-use, back-channel, pas de token en URL | 2026-06-17 | Acceptée | A |
| ADR-0016 | Nomenclature environnements LOCAL/DEV/INT/RMOA/PRODUCTION (+ PREPROD réservé), migration recette→RMOA déterministe |
2026-06-17 | Acceptée | A |
| ADR-0017 | Couloir (lane) : unité d'exécution parallèle, explicite, nommée (rejet socle/slot/stack ; ref non implicite) |
2026-06-17 | Acceptée | A |
| ADR-0018 | Exposition hors-prod derrière SLY par chemin (Portal/Edge/Bus), fronts+API same-origin, prod inchangée | 2026-06-17 | Acceptée | A |
| ADR-0019 | Modèle SIRRAT : dimension couloir (lane), clé (project,env,lane), stratégie de données, env client distinct |
2026-06-17 | Acceptée | A |
| ADR-0020 | Propagation du couloir en inter-app par contexte signé (jamais en-tête libre) | 2026-06-17 | Proposée | A |
ADRs à backfiller (décisions implicites déjà prises)¶
Ces décisions ont été actées sans ADR formel et doivent être documentées rétroactivement :
- ADR-0002 — JWT minimal avec
audrealm (B2B / B2C / internal / tracking), pas de rôles dans le token. Source : refactoringdynors-authdu 2026-05-07. - ADR-0003 —
dynors-entitlementssource-agnostique, alimenté par events multi-producteurs (dynors-billing, ELISA, DAWALALE, admin grants). Source : décision modèle entitlements du 2026-05-07. - ADR-0004 — Périmètre figé FISCAL / BOOKS / DYNORS PAIEMENT. Source : note d'architecture cible FISCAL §1 et §7.
- ADR-0005 — Patron API B2B Stripe-style comme standard DYNORS (référence FISCAL, à reproduire pour BOOKS, TRACIUM, etc.). Source :
docs/INTEGRATIONS_FACON_STRIPE.md§6. - ADR-0006 — Cookies HttpOnly Secure SameSite exclusivement pour les tokens (jamais localStorage). Source : règles
.cursor/rules/security-interapp-tenants.mdc. - ADR-0007 — Gouvernance architecte : trois catégories de décisions (A autonome, B proposée 5j, C exclusivité CTO). Source :
gouvernance-architecte-et-defauts.md.
Ces ADRs seront rédigées au fil des sprints suivants, dans l'ordre de priorité ci-dessus.
Conventions¶
- Numérotation séquentielle continue (ADR-0001, 0002, ...).
- Nom de fichier :
NNNN-titre-court-kebab-case.md. - Date au format ISO
YYYY-MM-DD. - Statut :
Proposée|Acceptée|Révoquée|Remplacée par ADR-XXXX. - Une fois acceptée, une ADR n'est pas modifiée — elle est remplacée par une nouvelle ADR qui la référence.
Pourquoi des ADRs¶
Les ADRs préservent la mémoire architecturale au-delà des personnes. Quand un nouveau dev ou un nouveau lead arrive, il peut comprendre pourquoi une décision a été prise, pas seulement quelle elle est. Cela évite de remettre périodiquement en cause des choix qui ont déjà été pesés.
Réf. méthode : Michael Nygard, Documenting Architecture Decisions, 2011.