Architecture Decision Records (ADR)
Trace pourquoi chaque choix structurant du dépôt — pas le comment
(couvert par la documentation thématique sous docs/architecture/,
docs/quality/ et
docs/collaboration/), mais le contexte,
l’alternative écartée et les conséquences assumées.
Format léger inspiré de Michael Nygard :
- Contexte — ce qui a forcé une décision.
- Décision — ce qui a été acté.
- Statut — Accepted / Superseded by
NNNN/ Deprecated. - Conséquences — gain, prix à payer, garde-fous à connaître.
Chaque ADR est numéroté en séquence (NNNN-titre-en-kebab-case.md).
Une fois acté, un ADR n’est pas réécrit : il est superseded par un
nouvel ADR qui décrit la nouvelle posture et référence l’ancien.
Nouveau venu ? Le parcours thématique regroupe ces décisions par sujet et propose un tour cohérent — par où commencer, comment elles s’articulent. L’index ci-dessous reste la référence par numéro.
Frontière avec le cluster ? L’index des décisions système recense les ADR qui décrivent la frontière
cluster ↔ atlas(préfixésCL-/AT-pour lever la collision des numéros entre les deux dépôts).
Quand ouvrir un ADR
Section intitulée « Quand ouvrir un ADR »Un ADR se justifie quand :
- la décision est durable (~ trimestres, pas semaines) ;
- une alternative crédible a été écartée et le « pourquoi » se perdrait dans l’historique Git sans note explicite ;
- une tension est assumée (compromis, dette acceptée, exception à une règle générale) que les contributeurs futurs doivent retrouver.
Un ADR n’est pas le bon endroit pour : une convention de code (→
docs/quality/code-style.md), un guide
opérationnel (→ README de paquet), une décision opérationnelle court-terme
ou un chantier actionnable (→ une issue GitHub, label enhancement
ou tech-debt).