<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ADR on Simple Enough Blog</title><link>https://blog-dev.simpleenough.net/fr/tags/adr/</link><description>Recent content in ADR on Simple Enough Blog</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Mon, 23 Feb 2026 11:00:00 +0100</lastBuildDate><atom:link href="https://blog-dev.simpleenough.net/fr/tags/adr/index.xml" rel="self" type="application/rss+xml"/><item><title>ADR (Architecture Decision Record) : documenter des décisions utiles</title><link>https://blog-dev.simpleenough.net/fr/blog/adr/</link><pubDate>Mon, 23 Feb 2026 11:00:00 +0100</pubDate><guid>https://blog-dev.simpleenough.net/fr/blog/adr/</guid><description>&lt;p>Les équipes techniques passent beaucoup de temps à discuter, arbitrer, choisir… puis à oublier &lt;em>pourquoi&lt;/em> elles ont choisi certaines décisions.&lt;br>
Le résultat est connu :&lt;/p>
&lt;ul>
&lt;li>les mêmes débats reviennent tous les 3 mois,&lt;/li>
&lt;li>on re-questionne des décisions sans le contexte de l’époque,&lt;/li>
&lt;li>l’onboarding dépend de “ceux qui savent”,&lt;/li>
&lt;li>et des migrations inutiles naissent d’une simple perte de mémoire.&lt;/li>
&lt;/ul>
&lt;p>Un &lt;strong>ADR (Architecture Decision Record)&lt;/strong> sert à éviter cela. Ce n’est pas une “grosse doc d’architecture”, ni un cahier des charges : c’est une &lt;strong>note courte&lt;/strong> qui capture une décision importante, avec le minimum de contexte pour qu’elle reste compréhensible et réutilisable.&lt;/p></description></item></channel></rss>