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 | TaxAuthorityAdapter comme abstraction multi-juridiction FISCAL — doctrine Acceptée, implémentation DÉMARRÉE 2026-06-30 (FISC-PORT-001/002/003 livrés ; reste 003b/004/005/006) |
2026-05-07 (revue 2026-06-21) | Acceptée | A |
| ADR-0002 | JWT minimal scopé par realm (aud = b2b/b2c-<app>/internal/tracking), sans rôles ni produits dans le token (backfill) |
2026-05-07 | Acceptée | A |
| ADR-0003 | dynors-entitlements source-agnostique, projection runtime alimentée par events multi-producteurs (backfill) |
2026-05-07 | Acceptée | A |
| ADR-0004 | Périmètre figé FISCAL / BOOKS / DYNORS PAIEMENT — frontières opposables en revue (backfill) | 2026-05-07 | Acceptée | A |
| ADR-0005 | Patron API B2B « façon Stripe » standard DYNORS (FISCAL référence ; <prefix>_live_*, route SLY /v1/<app>/**, webhooks signés) (backfill) |
2026-05-07 | Acceptée | A |
| ADR-0006 | Cookies HttpOnly Secure SameSite exclusivement pour les tokens — pas de fichier séparé | 2026-06-17 | Remplacée par ADR-0014 | A |
| ADR-0007 | Gouvernance architecte : trois catégories de décisions A (autonome) / B (proposée 5j) / C (exclusivité CTO) (backfill) | 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 SIRRAT, library chart dynors-app v0.2.0 (workload.kind élargi, deployment_audience, targetCluster, rollback DB documenté, gate statefulset) |
2026-06-10 (amendée 2026-06-21) | Acceptée | A |
| ADR-0013 | JWT asymétrique (RS256) + kid/JWKS et rotation — palier 1 livré ; palier 2 briques livrées + buildées vertes (émetteur+JWKS, JwksClient, verrou allow-hs256-in-prod, runbook) ; reste l'exécution ops par cercle |
2026-06-14 (clarifiée 2026-06-21, MAJ 2026-07-01) | Acceptée P1 / P2 briques livrées | 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 — implémentation autoritaire = dynors-platform/sly-portal-service ; prototype claude-handoff-dynors/sly-portal/ à archiver (PORT-MIG-001…004) |
2026-06-17 (clarifiée 2026-06-21) | 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é V3 HKDF (X-Sly-Environment/X-Sly-Lane), LaneContext, politique stricte + whitelist SIRRAT, Sprint 0 immédiat, butoir 2026-11-30 |
2026-06-17 (amendée 2026-06-21) | Acceptée | A |
| ADR-0021 | Transit SLY M2M vers SN Adresse (BAN2BAL) — route /sn-adresse/** côté SLY, mode DUAL cible ; BAN2BAL différé |
2026-06-24 | Acceptée (prépa Dynors) | A |
| ADR-0022 | Hub PSP : cartes en agrégateur-first (PayTech), acquisition carte native (licence EP BCEAO + GIM-UEMOA) en cible flaggée catégorie C ; canal piloté par PspRoutingService |
2026-06-30 | Acceptée | B |
| ADR-0023 | Intégration FISCAL ↔ BOOKS : Modèle C (API partagée, FISCAL source / BOOKS consomme) ; transport MVP HTTP synchrone via SLY /books/**, bus dynors-events optionnel |
2026-04-12 (formalisée 2026-06-30) | Acceptée | A |
| ADR-0024 | Gouvernance IA opérationnelle (DYNORSAI) : assistance auditée, pas de décision IA sur données sensibles sans DPO, gateway SLY unique — lève le DEFERRED tv-3 à l'acceptation |
2026-06-30 | Proposée (gate : DYNORSAI P0 figé) | B |
| ADR-0025 | Comptoir : application distincte (sœur de RED), référentiel transverse des tiers externes /comptoir/**, intégrations BOOKS/PAIEMENT/notify via SLY ; amendé 2026-07-03 (spec SPEC_TECHNIQUE_COMPTOIR_MVP.md, achats promus MVP, scaffold lot 1) |
2026-06-30 | Acceptée sous réserve (spec ✅ ; reste vérif marque) | B |
| ADR-0026 | Dérogation temporaire au gel FISCAL phase 2 : Comptoir autorisé à consommer /supplier-payments (règlement fournisseur), endpoint existant only, RAS hors périmètre, caveat contrat TRACIUM à généraliser |
2026-07-03 | Acceptée (temporaire ; révision au prochain gate FISCAL) | B |
| ADR-0027 | Cadre transverse : OWASP Top 10:2025 (A01–A10 → contrôles DYNORS), politique RGAA 4.1 / WCAG 2.2 AA par surface (S0–S3), responsivité par classe (R1–R4) — opposable revue / gate RMOA→PROD | 2026-07-29 | Acceptée | A |
| ADR-0028 | Quand acheter + migration sans perte ; v1.2 2026-07-31 : .sn = dawalale/medisen (+ elisa opt.) ; SuperGest/TRACIUM/JARAAF sous *.dynors.com sans mail dédié |
2026-07-29 | Acceptée | A |
| ADR-0029 | Auth SIRRAT via LDAP/dynors-auth + autorisation opérateur↔projet (on ne déploie que ce à quoi on a accès) : identité annuaire, accès = groupes LDAP réconciliés GitLab, enforcement dans DeploymentAuthorizationService + scoping dashboard ; login local = échafaudage smoke |
2026-08-09 | Proposée | B |
| ADR-0030 | Cible d'exécution : l'axe serveur est orthogonal au cercle (0016) et au couloir (0017) — le champ target du contrat d'agent transportait "ref", soit le couloir, et aucun modèle ne portait l'hôte. Cible déclarée sur la stack, tracée sur le déploiement ; une instance SIRRAT par cercle protégé, pas par serveur |
2026-08-11 | Proposée | B |
| ADR-0031 | Affectation TAKKU → décision entitlements → projection locale SIRRAT ; droits bornés au projet, expiration fail-closed, aucune dépendance sortante dans le chemin d'autorisation | 2026-08-29 | Acceptée | B |
| ADR-0032 | Résolution déterministe USER + GROUP par projet, surcharge individuelle, conflit au plus restrictif et projections ordonnées par révision | 2026-08-29 | Acceptée | B |
| ADR-0033 | Capacité comme unité d'autorisation, catalogue ouvert, contexte optionnel, octroi direct ; amende ADR-0003 §1 (politique déclarée, versionnée, auditée) | 2026-08-29 | Acceptée (amendée par ADR-0034) | A |
| ADR-0034 | Identité & Accès gouverne le modèle d'autorisation, dynors-entitlements en est le moteur d'évaluation ; capacités d'administration par scope global/application/project ; frontière Tenant IAM ≠ IAM interne ; tranche la réserve « spec policy point ABAC » de l'ADR IAM du 2026-06-21 |
2026-08-30 | Acceptée | A |
| ADR-0035 | Granularité et contrat du Layer 3 (CODEX_APP_TECH_CODE) |
2026-09-01 | Acceptée | B |
| ADR-0036 | Accès contextualisé aux logs applicatifs depuis SIRRAT — contrat de contexte corrigé sur un mécanisme déjà livré | 2026-09-03 | Proposée | B |
| ADR-0037 | Capacités de déploiement déclarées par template Forge, cible choisie sous contrainte de faisabilité — audit : la dérivation socle\|pod d'ADR-0009 n'est pas implémentée et CODEX_DEPLOY_TARGET porte aujourd'hui un nom d'hôte. Contient une contradiction assumée avec ADR-0009 (« jamais saisi à la main ») laissée à l'arbitrage |
2026-09-09 | Proposée | A |
Backfill 0002–0007 — terminé (2026-06-30)¶
Les décisions implicites listées au démarrage du registre ont été rédigées rétroactivement au format ADR :
- ADR-0002 à 0005 et 0007 : fichiers créés et Acceptés (voir registre ci-dessus). Date logique conservée au 2026-05-07 (date d'acte d'origine), mention « backfill » dans chaque en-tête.
- ADR-0006 : pas de fichier séparé — la décision « cookies HttpOnly, jamais localStorage » est entièrement couverte et durcie par ADR-0014 (cookies host-only
__Host-, token distinct par app). Le numéro 0006 est marqué Remplacée par ADR-0014 et n'est pas réattribué (numérotation séquentielle préservée).
Série « Groupe technologique DYNORS » (2026-05-15) — ADR stratégiques¶
En complément de ce registre numéroté (décisions techniques transverses), une série d'ADR
stratégiques « structuration en groupe technologique » vit dans le dépôt workspace sous
docs/adr/ (hors arbre MkDocs). Adoptés en lot le 2026-06-21 par l'instance bootstrap : 19
ADOPTÉ / ADOPTÉ AVEC RÉSERVE, 1 maintenu DEFERRED (gouvernance-IA opérationnelle — levée prévue par
ADR-0024). Thèmes : bounded contexts, RAGNAR cockpit,
IAM RBAC+ABAC, moteur de workflow, multi-entités/juridictions, JARAAF, gouvernance financière,
operating model, knowledge/enterprise-graph, registre des risques, CDP/DR/audit-trail (SEVERE).
Références (workspace) : docs/adr/README.md (index de la série), docs/adr/DECISION_ADOPTION_LOT_2026-06-21.md
(verdicts + amendements A→I + 15 invariants pentest). (Ces fichiers ne sont pas dans le site MkDocs — ils
sont dans le dépôt du workspace.)
Traçabilité d'implémentation — mise à jour 2026-07-01¶
ADR désormais appliqués dans le code et vérifiés par build (JDK 21, 192 tests verts — dynors-core) :
| ADR | Application / vérif | Commit(s) |
|---|---|---|
| ADR-0002 | Résolution tenant sécurisée : X-Tenant-Id/?tenant= bannis par défaut ; tenant = JWT validé ou transit SLY signé ; JwtAuthFilter pose TenantContext |
3d44706 |
| ADR-0008 | Marqueur SlyTransitFilter.ATTR_TRANSIT_VERIFIED (source de confiance) + script smoke test signé (docs/security/sly-smoke-test.sh) |
3d44706, cd621be |
| ADR-0013 | Palier 2 : JwksClient (consommateur JWKS) + verrou allow-hs256-in-prod — buildés verts |
be73c0b, 67922fd |
| ADR-0014 | Fix défaut cookie → base neutre sid (__Host-sid, aligné émetteur) |
3d44706 |
Corrections d'intégration associées (audit Medisen, mêmes releases core) : démarrage stateless sans
TenantService, RateLimitService à QuotaService optionnel, dynors-db allégé (Mongo/MySQL/LDAP),
dynors-events transports compileOnly. Détail : AUDIT_PACKAGES_PUBLIES_DYNORS.md §1.1.
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.