
Une request for comments (RFC) désigne le processus par lequel une organisation sollicite publiquement des retours de la part du public ou des parties prenantes concernées avant de finaliser une proposition ou un plan. L’objectif est de garantir la prise en compte des intérêts variés et des risques potentiels, afin d’améliorer la qualité et la faisabilité de la décision.
Dans le domaine de la gouvernance, la « gouvernance » fait référence à la manière dont une communauté ou une organisation prend et applique des décisions sur des sujets majeurs. Les RFC sont couramment utilisées avant des changements de règles, des ajustements de frais, des mises à niveau techniques ou des dépenses importantes. Les canaux de RFC incluent généralement les annonces officielles sur le site, les forums communautaires, les formulaires en ligne ou les réunions. Contrairement au vote direct, les RFC privilégient la discussion ouverte et la collecte d’éléments probants ; les votes interviennent généralement après la clôture de ces échanges.
La RFC désigne le processus en lui-même, tandis que le projet de RFC est le document qui sert de support à ce processus. Ce projet est généralement structuré et présente le contexte, la situation actuelle, les changements proposés et une liste de points soumis à l’avis du public sur chaque aspect.
En pratique, les régulateurs ou plateformes publient souvent un projet de RFC avant d’introduire de nouvelles règles, invitant les parties prenantes à réagir point par point. Les projets Web3 publient également des projets de RFC avant d’importantes mises à niveau techniques ou des changements de règles afin de limiter les malentendus et de faciliter le suivi des retours et des amendements.
Les RFC jouent un rôle clé dans la gouvernance Web3, car la décentralisation repose sur une large participation et la recherche de consensus, et toute modification des règles techniques ou économiques peut avoir des effets importants et durables.
À titre d’exemple, les DAO (Decentralized Autonomous Organizations) sont des organisations communautaires gérées collectivement par les détenteurs de jetons ou les contributeurs, via des votes on-chain ou off-chain. Sans solliciter d’abord des retours par le biais d’une RFC, toute modification de l’allocation des fonds, de la structure des frais ou des paramètres du protocole pourrait entraîner des conséquences inattendues. Les discussions ouvertes permettent à la communauté d’identifier les risques en amont, de fournir des données et des alternatives, et d’établir la légitimité et la transparence pour les votes et la mise en œuvre ultérieurs.
En 2024, de nombreuses grandes DAO adoptent un processus en deux étapes : d’abord la collecte de commentaires, puis le vote sur les propositions majeures. Cette méthode permet de limiter les litiges de procédure et la fragmentation de la gouvernance.
Dans une DAO, les RFC associent généralement forums communautaires et outils de vote. Le processus comprend en général une pré-discussion, la rédaction du document RFC, la collecte de retours, la révision, le vote et l’exécution.
Étape 1 : lancer une pré-discussion sur le forum communautaire. Les membres exposent le sujet et son impact anticipé pour recueillir les premiers avis.
Étape 2 : préparer le projet de RFC. Présenter séparément les informations contextuelles, les changements proposés, les risques et les alternatives afin de recueillir des retours ciblés.
Étape 3 : recueillir les retours et réviser le projet. Présenter clairement les éléments probants et les sources, répondre aux objections et, si nécessaire, effectuer des tests pilotes ou des simulations à petite échelle.
Étape 4 : organiser un sondage d’opinion ou un vote Snapshot. Snapshot est un outil de vote off-chain largement utilisé qui permet de sonder l’opinion de la communauté sans frais de gas.
Étape 5 : organiser un vote officiel on-chain et exécuter la décision. Les décisions et modifications finales sont mises en œuvre via des smart contracts, des programmes qui appliquent automatiquement les règles.
Dans le processus EIP (Ethereum Improvement Proposal) d’Ethereum, les RFC interviennent à chaque étape, de la soumission à la mise en œuvre. Un EIP est une proposition décrivant des modifications du protocole Ethereum ou des standards de la couche applicative.
Les auteurs soumettent d’abord leur projet sur GitHub, une plateforme collaborative de gestion de versions de code. La communauté et les équipes clientes discutent ensuite de la faisabilité technique, des risques et des stratégies de mise en œuvre dans les forums et dépôts. Après la collecte des retours, la proposition est testée sur des testnets avant que les équipes clientes et les développeurs principaux ne décident de son intégration. Les modifications concernant les mécanismes de frais ou les formats de transaction font souvent l’objet de nombreux commentaires publics et de plusieurs cycles de test.
Dans la communauté Gate, les RFC sont généralement publiées dans le Centre d’annonces, sur les canaux communautaires ou lors d’événements de vote. Les sujets fréquents incluent les explications des règles avant lancement de nouvelles fonctionnalités, les ajustements de la structure des frais et les appels à commentaires sur les propositions communautaires.
Lors de votre participation, vérifiez toujours les canaux d’annonces officiels de Gate pour authentifier la source et les échéances, afin d’éviter les liens de phishing. Pour les changements affectant les actifs ou les mécanismes de trading, il est recommandé de répondre avec des retours structurés—contexte, problématiques, suggestions, impact anticipé—et de suivre les mises à jour et notifications d’adoption.
La participation à une RFC ne requiert pas de compétences techniques, mais demande une préparation rigoureuse et une communication claire.
Étape 1 : vérifier l’authenticité de la source. Assurez-vous que l’annonce provient d’un canal officiel ou de confiance en contrôlant les noms de domaine, numéros d’annonce et délais.
Étape 2 : lire attentivement le projet de RFC. Repérez les changements proposés majeurs et identifiez les utilisateurs ou cas potentiellement concernés.
Étape 3 : rassembler les preuves et exemples. Utilisez des données, des captures d’écran ou des retours d’utilisateurs pour étayer vos suggestions.
Étape 4 : soumettre via les canaux spécifiés. Répondez sur les forums, remplissez les formulaires de retour ou joignez votre point de vue lors du vote sur Snapshot.
Étape 5 : conserver des traces et suivre l’évolution. Sauvegardez les liens et horodatages pour suivre les mises à jour et l’adoption ; fournissez d’autres retours si nécessaire.
Une RFC n’est pas une décision finale mais une « discussion ouverte » ; le vote et la mise en œuvre interviennent généralement par la suite. Une confusion fréquente consiste à considérer les résultats des discussions comme des décisions définitives ou à négliger les avis divergents.
Les principaux risques sont :
Une RFC efficace présente un périmètre et un calendrier clairs, des canaux de retour et des mécanismes d’adoption bien définis, ainsi que des mises à jour transparentes expliquant les décisions après clôture.
Des sources crédibles, des descriptions précises des problématiques, une divulgation complète des données et la transparence sur les risques contribuent à la qualité des échanges. Si les organisateurs expliquent pourquoi certaines suggestions n’ont pas été retenues et proposent des alternatives ou des étapes suivantes, les participants peuvent mieux évaluer la transparence et la responsabilité de la gouvernance.
Les RFC rendent publiques les discussions précédant une décision afin de limiter les risques et d’améliorer la qualité de l’exécution en impliquant activement les parties prenantes. Dans la gouvernance Web3—des DAO à Ethereum—elles jouent un rôle central dans le développement des protocoles et l’ajustement des règles au sein des communautés d’échange. Pour maximiser votre impact : vérifiez la crédibilité des sources, structurez clairement vos retours, suivez l’état d’adoption et restez vigilant quant à la sécurité des fonds lors de la signature de transactions ou de l’interaction avec des propositions.
La RFC désigne l’ensemble du processus de collecte de retours ; le projet de RFC est le document précis utilisé dans ce cadre. En résumé : le projet sert de version de travail pour les commentaires ou votes communautaires. Le premier est une action, le second est son support—ils sont étroitement liés mais portent sur des aspects distincts.
Commencez par comprendre le contexte : lisez le résumé et les objectifs du projet de RFC. Fournissez ensuite des retours précis—évitez les commentaires vagues en ciblant les axes d’amélioration ou les problèmes potentiels. Enfin, suivez les discussions ultérieures : surveillez les réponses officielles et les changements pour que votre contribution ait un réel impact.
L’objectif d’une RFC est de recueillir l’intelligence collective—toutes les suggestions ne peuvent être acceptées. Les principaux motifs de rejet sont l’inadéquation avec les objectifs du projet, l’irréalisme technique ou un faible soutien des parties prenantes. Un processus décisionnel transparent est essentiel—une bonne gouvernance expliquera pourquoi certaines suggestions ont été acceptées ou refusées.
Un bon projet de RFC doit exposer clairement le contexte du problème, le contenu proposé et l’impact potentiel. Vérifiez si les objectifs sont explicites, les modifications proposées spécifiques et mesurables, la rétrocompatibilité prise en compte et si la fenêtre de retour est raisonnable. Les projets vagues ou précipités sont généralement de moindre qualité.
Vérifiez d’abord si votre contribution a été enregistrée (en consultant les journaux de discussions officiels). Si elle a été prise en compte mais non retenue, vous pouvez demander la justification de cette décision. Si elle a été omise, exprimez votre point de vue lors des votes de gouvernance communautaire ou soumettez-le à nouveau lors de cycles ultérieurs—une implication régulière et argumentée est souvent plus influente qu’un commentaire isolé.



Qu’est-ce qu’une Request for Comments ?