Décisions Architecture
Ce dossier regroupe les ADR (Architecture Decision Records) du projet DMV / Dans Mon Village.
Un ADR documente une décision structurante : choix d’architecture, principe de sécurité, stratégie d’intégration, arbitrage produit-technique ou contrainte durable. Il sert de mémoire projet et évite de rediscuter régulièrement les mêmes décisions sans contexte.
Rôle des ADR
Les ADR permettent de :
- conserver l’historique des choix importants ;
- expliquer pourquoi une option a été retenue ;
- distinguer les faits observables, les objectifs et les hypothèses ;
- rendre les arbitrages compréhensibles pour les développeurs, les équipes produit et les IA ;
- documenter les risques et les alternatives non retenues.
Quand créer un ADR
Créer ou mettre à jour un ADR lorsqu’une décision :
- engage l’architecture sur plusieurs mois ;
- concerne plusieurs applications de l’écosystème ;
- influence la sécurité, les données, les coûts ou l’exploitation ;
- introduit une dépendance externe importante ;
- remplace une décision antérieure.
Format standard
Chaque ADR suit la structure suivante :
# ADR-XXX — Titre
## Statut
Proposed / Accepted / Deprecated / Replaced
## Date
YYYY-MM-DD
## Contexte
## Décision
## Conséquences
## Alternatives envisagées
## Risques
## Liens associés
Cycle de vie
| Statut | Signification |
|---|---|
Proposed | Décision proposée, en attente de validation ou de retour terrain. |
Accepted | Décision validée comme référence projet. |
Deprecated | Décision encore documentée mais déconseillée ou en fin de vie. |
Replaced | Décision remplacée par un autre ADR plus récent. |
Règles de rédaction
- Rester factuel et explicite.
- Ne pas présenter une vision cible comme déjà livrée.
- Écrire les contraintes et les risques sans les minimiser.
- Citer les documents liés quand ils existent.
- Ne pas modifier rétroactivement le sens d’un ADR accepté : créer un nouvel ADR si la décision change.