Skip to main content
Architecture9 min read

La décision d'architecture que personne ne documente

Nous passons des semaines à choisir entre Kafka et RabbitMQ sans jamais documenter pourquoi. Les ADR prennent 15 minutes et évitent des mois de discussions sur 'pourquoi avons-nous fait cela ?'.

Part ofProduct Systems->
By Jason TeixeiraDecember 20, 2025
ArchitectureDocumentationADRDecision MakingBest Practices
Share:
On this page

Il y a six mois, j'ai choisi Supabase plutôt que Firebase pour Nexural. J'avais de bonnes raisons — PostgreSQL, sécurité au niveau des lignes, auto-hébergeable. Mais j'ai failli oublier ces raisons. La seule chose qui m'a évité de réévaluer la même décision (et de perdre une semaine) a été un fichier markdown que j'ai écrit en 15 minutes.

Le Problème

Chaque équipe d'ingénierie a cette conversation :

"Pourquoi utilisons-nous RabbitMQ au lieu de Kafka ?" "Je crois que Dave a choisi ça. Dave est parti il y a 8 mois." "..." "Devrions-nous passer à Kafka ?"

Et maintenant vous passez un sprint à réévaluer une décision qui avait déjà été évaluée. La connaissance institutionnelle est partie par la porte.

Architecture Decision Records (ADR)

Un ADR est un court document qui capture une décision importante. Les miens sont d'une simplicité absolue :

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Architecture

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed