Rfc

Situation réelle Pourquoi cette décision a été prise ? Qui l’a validée ? La documentation ne le dit pas… ou elle est obsolète. Cette situation n’est pas une fatalité. Les ADR et RFC résolvent ce problème de façon élégante. Ce que j’ai observé : beaucoup d’équipes ont une documentation morte. Symptômes classiques (README.md last updated 2 years ago “We use microservices…” mais personne ne sait pourquoi microservices quelles alternatives considérées qui a décidé). Résultat: décisions refaites plusieurs fois, contexte perdu, nouveaux arrivants perdus. Avec ADR/RFC, documentation vivante : toujours à jour archives immutables, contexte préservé, décisions traçables. Métriques adoption mesurée (Avant ADR/RFC décisions documentées 10% “Pourquoi ?” répondu rarement onboarding nouveau 2 semaines, Après ADR/RFC décisions documentées 95% “Pourquoi ?” dans ADR toujours onboarding nouveau 3 jours). ...

Situation réelle “On doit choisir entre PostgreSQL et MongoDB. Le débat dure depuis 1 semaine, 2 camps s’opposent, aucun consensus.” Sans processus structuré, ces débats s’éternisent ou se terminent par une décision frustrante. Ce que j’ai observé : la RFC (Request for Comments) est un outil remarquablement efficace pour décider collectivement sans paralysie. Mais mal utilisée, elle devient bureaucratique. Le faux problème Le faux problème serait de croire que la RFC est juste “un doc technique”. En réalité, c’est un outil de gouvernance qui structure la prise de décision collective. ...