<?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, 20 Jul 2026 15:00:00 +0200</lastBuildDate><atom:link href="https://blog.dev.simpleenough.net/fr/tags/adr/index.xml" rel="self" type="application/rss+xml"/><item><title>Transmettre en asynchrone : revue de code, ADR et docs-as-code</title><link>https://blog.dev.simpleenough.net/fr/blog/modeasynchrone/</link><pubDate>Mon, 20 Jul 2026 15:00:00 +0200</pubDate><guid>https://blog.dev.simpleenough.net/fr/blog/modeasynchrone/</guid><description>&lt;p>Dans le guide des modes de collaboration, nous avons posé une règle : le savoir explicite se transmet en asynchrone. Là où les modes synchrones font passer l&amp;rsquo;intuition par le contact, les modes asynchrones fixent ce qui peut être écrit — et produisent une trace qui &lt;strong>survit aux départs&lt;/strong>. Encore faut-il éviter le piège classique : une documentation que personne ne lit et que plus personne ne met à jour. Cet article détaille les pratiques qui marchent, et pourquoi.&lt;/p></description></item><item><title>ADR (Architecture Decision Record) : documenter des décisions utiles</title><link>https://blog.dev.simpleenough.net/fr/blog/adr/</link><pubDate>Tue, 10 Mar 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>