# Architecture Decision Record

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | Architecte ou développeur porteur de la décision |
| **Destinataires** | Équipe technique, architectes, mainteneurs futurs |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Titre

<!-- Un numéro et une phrase qui énonce la décision, pas le sujet. -->

<!-- Points à couvrir :
     - Numérotation continue et immuable (ADR-014)
     - « Utiliser un format Parquet pour les fichiers d'échange » plutôt que « Choix du format de fichier »
-->

*à compléter*

## 2. Statut

<!-- L'état de la décision dans son cycle de vie. -->

<!-- Points à couvrir :
     - Proposée, acceptée, rejetée, dépréciée, remplacée par ADR-nnn
     - Date de changement de statut
-->

*à compléter*

## 3. Contexte

<!-- Les forces en présence au moment de la décision. Le passage le plus utile trois ans après. -->

<!-- Points à couvrir :
     - Problème à résoudre et contraintes applicables
     - Contraintes non techniques : délai, compétences, budget, politique interne
     - Ce qui est tenu pour acquis au moment de décider
-->

*à compléter*

## 4. Options envisagées

<!-- Les alternatives réellement étudiées, avec ce qui plaidait pour et contre chacune. -->

<!-- Points à couvrir :
     - Option, avantages, inconvénients
     - Raison de l'écarter
-->

*à compléter*

## 5. Décision

<!-- Ce qui est retenu, formulé à l'affirmative et sans conditionnel. -->

*à compléter*

## 6. Conséquences

<!-- Ce qui devient plus facile, ce qui devient plus difficile, ce qu'il faudra surveiller. -->

<!-- Points à couvrir :
     - Conséquences positives
     - Conséquences négatives acceptées
     - Impacts sur les autres composants, sur l'exploitation, sur les compétences à acquérir
     - Conditions qui justifieraient de revenir sur la décision
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- Pour tout choix coûteux à défaire : découpage, protocole, base de données, framework, format d'échange.
- Quand deux options défendables ont été comparées et qu'il faut mémoriser pourquoi l'une a gagné.
- Quand une contrainte externe impose un choix qui paraîtra incompréhensible plus tard.
- Quand on décide sciemment de ne pas faire quelque chose. Les non-décisions se perdent encore plus vite.

**Erreurs les plus fréquentes**

- Écrire l'ADR trois mois après la décision. La fiche fait partie de la décision, pas de son archivage : passé un délai, les contraintes réelles ont déjà été oubliées.
- Supprimer ou réécrire un ADR devenu faux. Il passe au statut « remplacé » : l'historique des choix est précisément ce qui a de la valeur.
- Ne consigner que les conséquences positives. Un ADR sans coût accepté n'a pas décrit un arbitrage, il a décrit une justification.
- En faire un document de dix pages. La brièveté est ce qui rend la pratique tenable dans la durée.

**Référentiel de rattachement**

Format Nygard, repris par arc42. Le format proposé par Michael Nygard (contexte, décision, statut, conséquences) est le plus répandu, et celui recommandé par arc42 en section 9. Sa contrainte de brièveté est délibérée : un ADR qu'on n'a pas le temps d'écrire n'est pas écrit.

---

Modèle « ADR - Architecture Decision Record » (Conception technique), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/adr/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.