Une PR générée par un agent arrive en review. Le code est propre, les tests passent, le pattern choisi est cohérent. Tu approuves. Trois semaines plus tard, un bug de fuseaux horaires casse la facturation. Pourquoi ce pattern ? L'agent l'a inféré depuis l'historique du repo. Personne ne l'a tranché. Et le senior qui aurait dit non est parti il y a six mois.

Scène réelle. Une réunion du lundi, trois seniors, une heure de débat sur le format d'une date. Personne ne sait pourquoi ISO 8601 a été choisi partout, sauf dans la facturation. Le choix avait été fait deux ans plus tôt, avec un bon argument. Perdu. Le dev qui l'avait porté est parti huit mois avant.

Pendant quinze ans, le bus factor portait sur le code : si la personne qui connaît le système disparaît, l'équipe est en danger. En 2026, ce risque s'est déplacé. Le code est dans le repo, versionné, relu par des outils. Ce qui reste prisonnier des têtes, c'est le pourquoi. Pourquoi cette librairie a été écartée. Pourquoi ce pattern bizarre est conservé. À quelle condition on peut le reprendre.

Michael Nygard l'écrivait dès 2011, dans le texte fondateur des ADR : "l'une des choses les plus dures à suivre pendant la vie d'un projet, c'est la motivation derrière certaines décisions." Quinze ans plus tard, le problème n'a pas disparu. Il s'est déplacé vers un acteur qui ne pose jamais la question.

Nygard décrit les deux seules options d'un dev face à une décision qu'il ne comprend pas.

Accepter aveuglément. Ça passe tant que le contexte n'a pas changé. Mais une équipe qui empile des décisions acceptées sans les comprendre finit par avoir peur de toucher quoi que ce soit. Le projet s'enfonce sous son propre poids.

Changer aveuglément. Ça passe tant que la décision était vraiment obsolète. Sinon on casse de la valeur sans le voir : la décision soutenait peut-être une exigence non testée.

Et la phrase qui reste, celle que tout dev a déjà pensée devant du code sans contexte : "What were they thinking?" Personne ne devrait avoir à deviner ce que l'équipe pensait.

Un agent IA ne demande pas. Il infère. Il lit l'historique git, les conventions du repo, les patterns existants, et il choisit tout seul. Une décision non écrite devient une décision re-prisée à ta place, puis appliquée partout, vite, dans chaque fichier généré.

Le code humain avait une limite naturelle : tu pouvais demander à l'auteur. Le code généré n'a pas d'auteur à interroger. Le seul support du pourquoi qui reste, c'est ce qui est écrit dans le repo.

Résultat : l'ADR change de statut. Ce n'est plus de la documentation pour les nouveaux arrivants. C'est l'interface de lecture de tes décisions par tes agents. Un ADR dans docs/adr, référencé dans les instructions du repo, c'est lu à chaque session d'agent. La même trace sert l'onboarding humain et le contexte machine.

La condition est documentée : les études 2026 sur les context files montrent que les agents suivent les instructions spécifiques, mais ignorent les résumés génériques. Un ADR pointé comme une règle explicite se fait obéir. Un ADR glissé dans une overview devient de la documentation au sens péjoratif : lu, pas appliqué.

Le format de Nygard tient en 5 champs. Titre : une phrase nominale courte. Contexte : les forces en jeu, technologiques et locales, sans jugement de valeur. Décision : la réponse, en phrases actives, "nous allons…". Statut : proposé, accepté, superseded. Conséquences : toutes, pas seulement les positives.

Les règles de gestion comptent autant que les champs : un fichier par décision, numéroté (adr-001, adr-002), dans le repo sous doc/arch/adr-NNN.md. Les numéros ne se réutilisent jamais. Une décision remplacée se marque "superseded", avec un lien vers son remplaçant : l'ancienne trace reste utile, elle raconte le chemin.

Nygard fixe la ligne de conduite : "nous écrirons chaque ADR comme une conversation avec un développeur futur". Des phrases complètes, une page maximum par fichier. Pas un compte-rendu de réunion : une trace du pourquoi, lisible seule.

Le moment : au moment de la décision, dans la PR qui la porte. Dix minutes. Pas une soirée de documentation le vendredi.

Le lead est le seul qui voit passer les décisions structurantes : il tient la revue, l'architecture, les arbitrages. Son mouvement de départ : la prochaine décision qui compte devient l'ADR 001. Template minimal copié dans le repo, 5 champs, écrit pendant la PR.

L'argument à porter en équipe tient en une phrase : la même trace sert l'onboarding et les agents. Le bus factor ne descend pas à zéro. Il devient N : chaque décision écrite est connue de toute l'équipe, et de chaque agent qui lit le repo.

Le template minimal de MADR, copié dans docs/decisions de ton repo. Pas d'outil à installer, pas de licence : un fichier markdown de 20 lignes. Ajoute une ligne dans les instructions d'agent du repo ("avant de choisir un pattern, lis docs/decisions") et le même fichier devient du contexte machine. La documentation qui marche est celle que tes agents lisent à ta place.

Réponds-moi. Et si tu veux le template ADR en français, prêt à coller dans ton repo, réponds "ADR" et je te l'envoie.