Écrire des RFCs Techniques qui Sont Vraiment Lus et Orientent les Décisions
Les décisions techniques les plus coûteuses dans une organisation d'ingénierie se prennent dans des fils Slack qui disparaissent, dans des réunions où la moitié des parties prenantes est absente, ou dans la tête d'un ingénieur senior sans l'apport de personne d'autre. Puis six mois plus tard, quand l'architecture grince et que quelqu'un demande "pourquoi l'avons-nous construit comme ça ?", personne ne s'en souvient. Ou pire, tout le monde s'en souvient différemment.
Les RFCs — documents de Demande de Commentaires — résolvent ce problème. Ce sont l'un des outils les plus puissants disponibles pour les équipes d'ingénierie, et l'un des plus sous-utilisés. Je les ai vus transformer la façon dont les équipes prennent des décisions, s'alignent entre les fuseaux horaires et construisent une mémoire institutionnelle. Je les ai aussi vus mal utilisés, devenant des romans de 40 pages que personne ne lit et qui ralentissent tout.
Voici comment les faire correctement.
Pourquoi les RFCs sont Importants
Un RFC est une proposition écrite pour une décision technique significative, partagée avec l'équipe pour obtenir des retours avant le début de l'implémentation. C'est tout. Pas une spécification. Pas de la documentation. Une proposition qui invite des contributions.
La valeur vient de trois choses :
Clarté de pensée forcée. Écrire vous force à structurer votre raisonnement. L'idée vague qui semblait géniale dans votre tête est testée quand vous devez l'expliquer sur papier. J'ai écrit des RFCs où l'acte d'écrire a révélé que ma solution proposée avait un défaut fondamental que je n'avais pas remarqué. C'est le but — il est moins cher de trouver le défaut dans un document que dans du code de production.
Alignement asynchrone. Dans une équipe distribuée couvrant plusieurs fuseaux horaires, les réunions synchrones sont coûteuses et exclusives. Quelqu'un rejoint toujours à une heure inconfortable, quelqu'un est toujours absent. Un RFC permet à chacun de contribuer son point de vue à son propre rythme. L'ingénieur à Buenos Aires et celui à Berlin lisent le même document et ajoutent leurs commentaires sans avoir besoin de trouver un créneau commun de 30 minutes.
Mémoire institutionnelle. Dans six mois, un nouveau membre de l'équipe demandera pourquoi le système utilise l'event sourcing plutôt qu'un pattern CRUD traditionnel. Au lieu de s'appuyer sur l'histoire orale ("je crois que Maria a décidé ça, mais elle est partie en mars"), vous les pointez vers le RFC-047. Le contexte, les alternatives et le raisonnement sont tous là. Ça seul vaut le coût d'écrire des RFCs.
La Structure de RFC qui Fonctionne
J'ai itéré sur des templates de RFC dans plusieurs équipes et organisations. Voici la structure qui produit de façon cohérente des documents utiles sans être une charge :
1. Titre et métadonnées
- Numéro de RFC et titre. La numérotation séquentielle (RFC-001, RFC-002) facilite les références.
- Auteur(s) et date.
- Statut. Brouillon, En Révision, Accepté, Rejeté, Remplacé.
- Reviewers. Nommez les personnes dont vous avez spécifiquement besoin de l'apport.
2. Contexte et énoncé du problème (1-2 paragraphes)
Quelle est la situation ? Quel problème résolvons-nous ? Pourquoi maintenant ? Cette section ancre le lecteur. Ne supposez pas qu'il a le même contexte que vous. Liez aux tickets, métriques ou incidents pertinents qui rendent le problème concret.
Mauvais : "Nous devons améliorer notre pipeline de données." Bon : "Notre pipeline ETL actuel traite 2M d'enregistrements chaque nuit. Avec notre trajectoire de croissance, nous atteindrons 10M d'enregistrements au T1 2024. L'architecture actuelle prend 4 heures pour traiter 2M d'enregistrements et ne passera pas à l'échelle de façon linéaire. Le mois dernier, nous avons eu deux incidents où le job batch ne s'est pas terminé avant les heures de bureau (INC-234, INC-251)."
3. Solution proposée (le cœur du document)
Décrivez ce que vous voulez construire, comment ça fonctionne et pourquoi cette approche. Incluez :
- Architecture ou design système. Les diagrammes aident. Un simple diagramme de boîtes et flèches communique plus que cinq paragraphes de texte.
- Décisions techniques clés dans la proposition et pourquoi vous les avez prises.
- Périmètre. Ce qui est inclus et, de façon critique, ce qui n'est explicitement pas inclus.
4. Alternatives considérées (section non négociable)
Listez au moins deux alternatives que vous avez évaluées et pourquoi vous les avez rejetées. Cette section fait trois choses : elle montre que vous avez fait vos devoirs, elle prévient les commentaires "mais pourquoi n'avez-vous pas considéré X ?", et elle documente le paysage décisionnel pour les futurs lecteurs.
Si vous ne pouvez pas penser à des alternatives, vous n'avez pas assez réfléchi au problème.
5. Risques et questions ouvertes
Qu'est-ce qui pourrait mal tourner ? Sur quoi êtes-vous incertain ? Quelles hypothèses faites-vous qui pourraient être fausses ? Cette section est là où vit l'honnêteté intellectuelle. Une proposition qui prétend avoir zéro risque n'est pas confiante — elle est naïve.
6. Plan d'implémentation
Un calendrier approximatif et des phases. Pas un plan de projet détaillé — juste assez pour montrer que c'est faisable et identifier les dépendances. "Phase 1 : migrer la couche d'ingestion (2 semaines). Phase 2 : migrer la couche de transformation (3 semaines). Phase 3 : décommissionner l'ancien pipeline (1 semaine)."
7. Décision et résultat (rempli après la révision)
Qu'est-ce qui a été décidé ? Quand ? Par qui ? Des modifications à la proposition originale ? Cela boucle la boucle et transforme le RFC d'une proposition en un enregistrement.
Erreurs Courantes qui Tuent les RFCs
Trop long. Si votre RFC fait plus de 4 pages, la plupart des gens ne le liront pas attentivement. Ils le survoleront, manqueront les nuances et soit l'approuveront sans réfléchir, soit soulèveront des objections déjà traitées dans le texte. Soyez impitoyable dans la coupe. Déplacez les détails d'implémentation, les schémas d'API et les modèles de données en annexe.
Trop abstrait. "Nous devrions adopter une architecture de microservices" sans spécifier quels services, quelles sont les frontières ou comment ils communiquent n'est pas une proposition — c'est un vœu. Les RFCs doivent être suffisamment concrets pour que quelqu'un puisse être en désaccord avec un aspect spécifique.
Pas de point de décision clair. Le RFC devrait indiquer explicitement : "Nous avons besoin d'une décision à ce sujet d'ici [date]. Si aucune objection n'est soulevée d'ici là, nous procédons avec l'approche proposée." Sans délai, les RFCs deviennent des brouillons perpétuels qui ne se convertissent jamais en action.
Écrire des RFCs pour tout. Toutes les décisions n'ont pas besoin d'un RFC. Choisir entre deux packages NPM pour le formatage de dates ne nécessite pas de document. Les RFCs sont pour les décisions difficiles à inverser, qui affectent plusieurs équipes ou qui impliquent un investissement significatif. J'utilise cette règle : si l'implémentation prend moins d'une semaine et est facilement réversible, faites-le simplement. Si ça prend plus d'une semaine ou est difficile à inverser, écrivez un RFC.
Utiliser les RFCs comme des permis. Le processus RFC devrait concerner l'obtention de contributions, pas d'approbations. Si chaque RFC doit être "approuvé" par un comité, vous avez construit un conseil de révision des changements avec des étapes supplémentaires. L'objectif est de meilleures décisions grâce aux contributions collectives, pas la bureaucratie de l'approbation.
Développer l'Habitude RFC Sans Bureaucratie
Le plus grand défi n'est pas d'écrire un RFC — c'est d'en faire une habitude d'équipe. Voici ce qui fonctionne :
Commencez avec un template léger. Ne créez pas un template à 15 champs dès le premier jour. Commencez avec Problème, Proposition, Alternatives, Risques. Quatre sections. Vous pourrez ajouter de la structure plus tard quand l'équipe verra ce qui est utile.
Faites des premiers RFCs des victoires visibles. Choisissez une décision sur laquelle l'équipe tergiversait. Rédigez-la comme un RFC. Quand ça mène à une décision claire avec un raisonnement documenté, l'équipe voit la valeur. Ça vend la pratique mieux que n'importe quel mandat de processus.
Stockez les RFCs là où les gens travaillent déjà. Un dossier Google Drive partagé que personne ne visite est l'endroit où les RFCs vont mourir. Mettez-les dans votre dépôt (un répertoire /rfcs), dans Notion si c'est la maison de votre équipe, ou dans Confluence si vous en êtes coincé. Où que l'équipe cherche déjà de l'information.
Assignez des reviewers explicitement. "Merci de relire" adressé à personne est adressé à personne. Nommez 2-3 reviewers spécifiques dont l'expertise est pertinente. Donnez-leur un délai. Relancez s'ils ne répondent pas.
Gardez la période de révision courte. Cinq jours ouvrés est suffisant pour la plupart des RFCs. Si un RFC est en révision pendant trois semaines, l'auteur a déjà continué mentalement et le document devient obsolète.
Célébrez les bons RFCs. Quand quelqu'un écrit un RFC qui sauve l'équipe d'une mauvaise décision ou mène à une architecture notablement meilleure, soulignez-le. "Le RFC d'Alejandro sur la stratégie de cache nous a sauvés d'un design qui se serait cassé à 10x de charge" fait que l'écriture de RFCs semble précieuse, pas comme un devoir.
Les RFCs pour les Équipes Distribuées
Les RFCs deviennent encore plus précieux quand votre équipe est distribuée. Ils sont le grand égalisateur — l'ingénieur qui est plus silencieux dans les réunions a une voix égale dans un document écrit. Le membre de l'équipe dans un fuseau horaire différent ne manque pas la discussion parce qu'il n'y a pas de discussion à manquer. Tout le monde contribue de façon asynchrone.
Chez Conectia, nous avons vu la pratique RFC faire une différence tangible dans la façon dont les équipes distribuées opèrent. Quand nos ingénieurs seniors rejoignent l'équipe d'un client, avoir un processus RFC clair signifie qu'ils peuvent contribuer à la réflexion architecturale dès le premier jour, pas seulement du code. Ils comprennent le contexte derrière les décisions existantes (parce que c'est écrit) et peuvent proposer des améliorations via le même processus structuré. C'est comme ça que les équipes distribuées prennent des décisions aussi bien — ou mieux — que les équipes co-localisées.
L'investissement est petit : un template, un emplacement de stockage et un engagement à écrire avant de construire pour les décisions significatives. Le retour est énorme : de meilleures décisions, moins de conversations "pourquoi a-t-on fait ça ?" et une équipe qui réfléchit avant de coder.
Vous construisez une équipe distribuée qui prend de solides décisions techniques de façon asynchrone ? Parlez à un CTO — nos ingénieurs seniors LATAM apportent la pensée structurée et les compétences de communication dont les équipes distribuées ont besoin.
