ADR : Architecture Decision Record
Infrastructure
ADR : Architecture Decision Record. « Fiche de décision d'architecture », par analogie avec le procès-verbal d'une réunion de copropriété, qu'on relit dix ans plus tard pour comprendre pourquoi l'ascenseur s'arrête au troisième.
Contenu : Un document court qui consigne le contexte, les options envisagées, la décision retenue et ses conséquences. Une décision par fiche, datée, jamais réécrite : on la remplace par une nouvelle qui la rend caduque.
Pourquoi l'écrire : Une règle de sécurité dont on a perdu la raison devient une relique : on n'ose plus la toucher, ou on la supprime au premier désagrément. L'homme oublie vite ; l'organisation, qui est faite d'hommes, oublie plus vite encore.
Où le ranger : Idéalement dans le dépôt de code, à côté de ce qu'il justifie, versionné et relu comme le reste ; il suit ainsi le projet au lieu de mourir dans un wiki orphelin.
Ce qui arrive si on s'en passe
Sans trace écrite des décisions d'architecture, les choix de sécurité perdent leur justification au fil des départs et des réorganisations. Une règle de filtrage, un chiffrement imposé ou une séparation de réseaux finissent alors supprimés parce que personne ne sait plus ce qu'ils protègent, ou conservés par superstition alors que la menace a changé. Les audits et analyses de risques repartent de zéro, et une même option écartée pour de bonnes raisons revient sur la table tous les deux ans. Consigner chaque décision sensible, avec ses alternatives et ses conséquences, permet de vérifier plus tard qu'elle tient toujours.
Explication de la marmotte
Dans un projet, on prend sans cesse des décisions : quel outil utiliser, comment ranger les données, quelle protection mettre en place. Des mois plus tard, plus personne ne se souvient pourquoi. Une fiche de décision est une courte note écrite au moment du choix : quelle était la situation, quelles solutions on a comparées, laquelle on a gardée et ce que ça implique. C'est comme le carnet d'entretien d'une voiture : on y retrouve ce qui a été fait et pourquoi, sans devoir deviner.
Où ce terme est utilisé
- Gérer un désaccord technique sans bloquer un projet (9 occurrences)
- Comment structurer un mentorat technique sans dogme (7 occurrences)