Historique des décisions techniques majeures du projet SPAN SG.
Format: MADR (Markdown Any Decision Records)
Version: 1.0.2 Dernière mise à jour: 2025-10-23
| ADR | Titre | Date | Statut |
|---|---|---|---|
| 001 | Adoption thème DSFR vs Material | 2025-10-08 | ✅ Accepted |
| 002 | Migration synthèse Markdown → HTML DSFR | 2025-10-08 | ✅ Accepted |
| 003 | Isolation build PDF avec --site-dir | 2025-10-10 | ✅ Accepted |
| 004 | Architecture hooks Python vs JavaScript | 2025-10-08 | ✅ Accepted |
| 005 | Seuil coverage 89%+ enforced | 2025-10-10 | ✅ Accepted |
| 006 | Migration 31 → 33 critères DINUM officiels | 2025-10-11 | ✅ Accepted |
| 007 | Divergence mkdocs-dsfr locale vs language | 2025-10-14 | ✅ Accepted |
| 008 | Exclusion temporaire search label tests WCAG | 2025-10-14 | ✅ Accepted (temporaire) |
| 009 | Migration Architecture 2 Branches → GitHub Environments | 2025-10-20 | ✅ Accepted |
| 010 | Gestion dépendances sans lockfile | 2025-10-23 | ✅ Accepted |
- ✅ Accepted: Décision adoptée et implémentée en production
- ⏳ Proposed: En discussion, pas encore implémentée
- ❌ Deprecated: Remplacée, ne plus utiliser
- 🔄 Superseded: Remplacée par ADR-XXX (voir lien)
Pour créer un nouveau ADR, copier template.md et suivre la structure MADR :
# ADR-XXX: [Titre court]
**Date**: YYYY-MM-DD
**Statut**: ⏳ Proposed / ✅ Accepted / ❌ Deprecated / 🔄 Superseded
**Décideurs**: [Noms]
**Sponsor**: [Chef projet/Sponsor]
## Contexte
[Problème à résoudre, contraintes, contexte métier]
## Décision
[Solution choisie, justification courte]
## Alternatives considérées
### Option A: [Nom]
- Avantages: ...
- Inconvénients: ...
- **Rejeté**: [Raison]
### Option B: [Nom choisi]
- Avantages: ...
- Inconvénients: ...
- **Choisi**: [Raison]
## Conséquences
**Positives:**
- [Bénéfices]
**Négatives:**
- [Coûts, limitations]
## Validation
- [Critères succès]
- [Tests validation]
## Références
- [Commits, issues, docs]- Immutables: Un ADR ne se modifie pas après acceptation
- Traçables: Chaque décision technique majeure → ADR
- Contextuels: Expliquer le "pourquoi", pas seulement le "quoi"
- Concis: 1-2 pages maximum
- Datés: Date décision pour historique chronologique
Créer un ADR pour:
- ✅ Choix technologiques structurants (frameworks, libs majeures)
- ✅ Changements architecture (formats, workflows, CI/CD)
- ✅ Standards projet (coverage, conventions, process)
- ✅ Décisions impactant > 20% du code
Ne pas créer pour:
- ❌ Petits bugfixes
- ❌ Refactoring localisés
- ❌ Ajout features mineures
- ❌ Changements réversibles facilement
- Rédiger ADR avec statut
⏳ Proposed - Discussion équipe (review, alternatives)
- Décision validée → Statut
✅ Accepted - Implémentation (commits référencent ADR-XXX)
- Si déprécié plus tard → Créer nouvel ADR + statut
🔄 Superseded by ADR-YYY