Note : Ceci est une note de recherche complétant le livre L’ère de la post-pénurie, désormais disponible à l’achat. Ces notes approfondissent les concepts du texte principal. Commencez ici ou procurez-vous le livre.

RFC (Request for Comments) : Comment Internet a été bâti en demandant gentiment

En avril 1969, un étudiant diplômé nommé Steve Crocker était assis dans son appartement à UCLA, terrifié.

Il faisait partie d’une petite équipe construisant quelque chose appelé ARPANET — le précurseur d’Internet. Ils devaient documenter leurs idées. Mais Crocker faisait face à un problème particulier : il avait 25 ans, entouré d’ingénieurs brillants venant d’universités concurrentes, et personne n’était officiellement en charge. S’il publiait quelque chose qui semblait trop autoritaire, les autres équipes pourraient avoir l’impression qu’il « prenait le dessus ». S’il restait silencieux, rien ne serait documenté.

Sa solution ? Il intitula son document « Request for Comments ».

Le nom était délibérément humble. Nous ne vous disons pas quoi faire. Nous demandons juste… ce que vous en pensez. C’était une façon de publier des idées sans en revendiquer la propriété. Une façon d’inviter le désaccord au lieu de le faire taire.

Ce geste nerveux et modeste est devenu la fondation de comment tout Internet a été construit. Et cinquante-cinq ans plus tard, il reste l’une des expériences de gouvernance les plus réussies de l’histoire humaine.

Le document qui a mangé le monde

RFC 1, publié le 7 avril 1969, s’intitulait « Host Software ». Il décrivait comment les ordinateurs pourraient se parler. Il était tapé sur une machine à écrire manuelle et envoyé par la poste sous forme papier à une douzaine de chercheurs. Le format était intentionnellement informel — pas de comités, pas de votes, pas de bénédiction officielle. Juste des idées, documentées, partagées et ouvertes à la critique.

Au moment où vous lirez ceci, il y aura plus de 9 900 RFC. Elles définissent essentiellement tout sur comment Internet fonctionne :

RFC 791 (1981) : Protocole Internet (IP) — comment les paquets trouvent leur chemin
RFC 793 (1981) : Protocole de Contrôle de Transmission (TCP) — comment les données arrivent de manière fiable
RFC 821 (1982) : SMTP — comment fonctionne le courrier électronique
RFC 2616 (1999) : HTTP/1.1 — comment les pages web se chargent
RFC 5321 (2008) : SMTP mis à jour — toujours comment fonctionne le courrier électronique

Chaque fois que vous chargez une page web, envoyez un e-mail, regardez une vidéo en streaming ou pestez contre votre routeur, vous utilisez des systèmes définis par les RFC. Le format de document qu’un étudiant diplômé nerveux a inventé pour éviter de paraître présomptueux régit maintenant plus de communications humaines que n’importe quel gouvernement ne l’a jamais fait.

La gouvernance qui n’en est pas une

Voici ce qui rend le système RFC remarquable : il n’a aucune autorité légale. Zéro. Aucune.

Personne n’a à suivre un RFC. Il n’y a pas de police d’Internet qui vous arrêtera pour avoir mal implémenté HTTP. Il n’y a pas de traité international qui lie les nations au TCP/IP. Les documents sont publiés par une organisation de volontaires (l’Internet Engineering Task Force) qui n’a aucun pouvoir de taxation, aucune armée permanente et aucun mécanisme d’application de la loi quel qu’il soit.

Et pourtant, presque tout le monde les suit. Des milliards d’appareils. Des milliers d’entreprises. Tous les pays sur Terre.

Pourquoi ? Parce que suivre les standards est utile. Si votre client de messagerie n’implémente pas correctement SMTP, il ne peut pas envoyer d’e-mails. Si votre navigateur n’implémente pas correctement HTTP, il ne peut pas charger de sites web. Le mécanisme d’application n’est pas la punition — c’est la réalité. Vous vous conformez parce que la non-conformité signifie que vos trucs ne fonctionnent pas.

C’est de la gouvernance sans autorité. Coordination sans coercition. Ordre sans ordres.

« Nous rejetons les rois, présidents et votes »

En juillet 1992, le professeur du MIT Dave Clark a donné une présentation à la 24e réunion de l’IETF à Cambridge, Massachusetts. L’organisation était sous pression pour adopter certains protocoles de l’organisme de normalisation OSI concurrent — un effort descendant soutenu par les gouvernements pour créer des standards réseau « officiels ».

Clark a résumé la philosophie de l’IETF dans ce qui est devenu son hymne non officiel :

« Nous rejetons : les rois, présidents et votes. Nous croyons en : consensus approximatif et code fonctionnel. »

Décortiquons cela :

Rejeter les rois : Aucune autorité unique ne décide ce que les standards devraient être. Pas le gouvernement américain, pas une entreprise, pas un individu génial.

Rejeter les présidents : Pas d’élus avec des mandats et des missions. L’IETF a des présidents et des groupes de travail, mais ce sont des coordinateurs, pas des commandants.

Rejeter les votes : C’est le plus étrange. La plupart des démocraties utilisent le vote. L’IETF ne le fait explicitement pas. Pourquoi ? Parce que 51 % ne devraient pas pouvoir passer outre 49 % sur des questions techniques. Parce que compter les têtes ne vous dit pas qui a raison. Parce que voter crée des gagnants et des perdants, et les perdants arrêtent souvent de coopérer.

Au lieu de cela, ils pratiquent le consensus approximatif : continuer à discuter jusqu’à ce que la plupart des gens soient satisfaits — pas unanimes, mais pas divisés non plus. L’objectif n’est pas l’accord ; c’est l’absence de désaccord fort.

Et code fonctionnel : Les idées ne gagnent pas en étant éloquentes. Elles gagnent en fonctionnant. Si vous pensez que votre approche est meilleure, implémentez-la. Prouvez-le. Le code est l’argument.

Comment le fredonnement a remplacé le vote

Quand l’IETF doit évaluer le sentiment de la salle, ils ne lèvent pas la main. Ils fredonnent.

Sérieusement.

Le président du groupe de travail demandera aux gens de fredonner pour l’Option A ou l’Option B. Le son qui en résulte donne une idée de la salle sans créer de chiffres comptables, citables, armes que l’on peut utiliser. Comme l’explique RFC 7282 :

« Une tradition à l’appui du consensus approximatif est la tradition de fredonner plutôt que (dénombrables) de lever la main ; cela permet à un groupe de discerner rapidement la prévalence du désaccord, sans faciliter le glissement vers la règle de la majorité. »

Il y a aussi un angle de confidentialité : les participants de l’IETF se représentent en tant qu’individus, pas leurs employeurs. Si l’ingénieur d’IBM doit publiquement lever la main contre la position préférée d’IBM, cela crée un risque de carrière. Mais un fredonnement est diffus, anonyme-esque, niable. L’ingénieur peut suivre sa conscience technique sans que son employeur suive son vote.

Est-ce absurde ? Un peu. Mais ça marche depuis 40 ans. Internet a été construit par des gens qui ont rejeté le vote et ont fredonné à la place.

La guerre des standards : TCP/IP contre OSI

Le processus RFC n’a pas gagné par défaut. Il a mené une guerre.

Dans les années 1980, l’Organisation Internationale de Normalisation (ISO) a développé le modèle OSI — une architecture complète à sept couches pour les réseaux informatiques. Il a été conçu par des comités d’experts. Il avait un soutien gouvernemental. Il était théoriquement élégant.

TCP/IP, émergeant du processus RFC, était plus désordonné. Il violait certaines des abstractions propres d’OSI. Il a été conçu par des étudiants diplômés et des entrepreneurs ARPA plutôt que par des membres distingués de comités.

Sur le papier, OSI aurait dû gagner. Il avait un soutien institutionnel. Il avait un financement. Il avait le prestige des organismes de normalisation internationaux.

Mais TCP/IP avait quelque chose qu’OSI n’avait pas : du code fonctionnel.

Alors que les comités OSI débattaient de la spécification parfaite, les ingénieurs Internet livraient des implémentations. TCP/IP était gratuit à implémenter — les spécifications étaient des RFC publics, aucun achat requis. Les spécifications OSI, en revanche, nécessitaient l’achat de copies papier de l’ISO. Les subventions gouvernementales pour la recherche ARPANET signifiaient que les implémentations TCP/IP proliféraient dans les universités. Au moment où OSI était prêt pour le prime time, TCP/IP avait déjà gagné par adoption.

La « révolte du palais » de 1992 a été l’acte final. Quand les dirigeants de l’IETF ont suggéré d’adopter certains protocoles OSI, les ingénieurs de base ont hurlé de protestation et ont effectivement démis leur propre leadership pour l’hérésie. Le processus ascendant a rejeté ses propres dirigeants désignés lorsque ces dirigeants ont tenté d’imposer des solutions descendantes.

La leçon : Les standards qui émergent de la pratique battent les standards conçus par la théorie. Le code fonctionnel bat la spécification élégante.

La loi de Postel : La philosophie qui a fait fonctionner l’interopérabilité

Jon Postel a servi comme éditeur de RFC de 1971 jusqu’à sa mort en 1998. Il était la personne qui maintenait le système en marche — recevant des documents, attribuant des numéros, maintenant la qualité. Il a également articulé un principe qui est devenu fondamental pour l’interopérabilité d’Internet :

« Soyez conservateur dans ce que vous faites, soyez libéral dans ce que vous acceptez des autres. »

C’est la loi de Postel, aussi appelée le Principe de Robustesse. Elle apparaît dans RFC 760 et RFC 761, les spécifications TCP/IP originales.

L’intuition : Si chaque implémentation insiste pour recevoir des messages parfaitement formatés, alors un seul bug n’importe où casse tout. Mais si les implémentations sont tolérantes — acceptant des entrées légèrement mal formées, tolérant des écarts mineurs — alors le système dans son ensemble devient résilient. Différentes organisations peuvent construire des produits qui communiquent même lorsqu’elles interprètent légèrement différemment la spécification.

Ce n’est pas seulement un conseil technique. C’est un contrat social. Cela dit : Nous construisons quelque chose ensemble, et nous préférerions le faire fonctionner plutôt que d’insister sur avoir raison sur chaque détail. Cela priorise l’interopérabilité sur la pureté, la collaboration sur la correction.

Certains ont critiqué la loi de Postel à l’ère moderne — la tolérance des entrées mal formées crée des vulnérabilités de sécurité. Mais dans les débuts d’Internet, quand l’objectif était simplement de faire parler divers systèmes entre eux, le principe était essentiel. Il a permis à Internet de croître malgré les bugs, les erreurs et les implémentations incompatibles.

La famille RFC : BIP, EIP et PEP

Le modèle RFC a eu tellement de succès qu’il a engendré des imitateurs dans tout le monde technologique :

Propositions d’Amélioration de Python (PEP)

Quand Guido van Rossum avait besoin d’un processus pour faire évoluer le langage de programmation Python, il a créé les PEP — directement modelés sur les RFC. PEP 1 (2000) a établi le processus : proposer un changement, documenter la justification, recueillir des retours, itérer jusqu’au consensus approximatif, implémenter.

Propositions d’Amélioration de Bitcoin (BIP)

En 2011, Amir Taaki a créé les BIP pour Bitcoin — explicitement dérivés du processus PEP de Python. BIP 0001 reconnaît même la dette : « largement basé sur le processus d’amélioration de Python ».

Le problème de gouvernance de Bitcoin était sévère : comment apporter des changements à une monnaie décentralisée sans PDG, sans conseil d’administration et avec des milliards de dollars en jeu ? Le processus BIP fournit une structure sans centralisation. Les idées sont proposées, débattues, implémentées et activées par un processus qui nécessite — vous l’avez deviné — consensus approximatif et code fonctionnel.

Propositions d’Amélioration d’Ethereum (EIP)

Ethereum a suivi l’exemple de Bitcoin avec les EIP, adaptant le même processus de style RFC pour une plateforme de contrats intelligents plus complexe. Des changements majeurs comme The Merge (transition du proof-of-work au proof-of-stake) sont passés par le processus EIP — des années de propositions, discussions, implémentations et finalement consensus approximatif parmi les développeurs, opérateurs de nœuds et la communauté plus large.

Le modèle est cohérent : quand une communauté a besoin de se coordonner sans autorité centrale, elle réinvente une version du processus RFC. Le format importe moins que la philosophie : documenter les propositions publiquement, inviter les critiques, itérer jusqu’à ce que les objections soient traitées, laisser les implémentations fonctionnelles parler plus fort que les arguments théoriques.

Pourquoi c’est important pour la civilisation

Le processus RFC a résolu un problème avec lequel philosophes et politologues se sont battus pendant des millénaires : Comment prendre des décisions collectives sans tyrannie ni chaos ?

Les réponses traditionnelles tombent dans des catégories familières :

Monarchie/Dictature : Une personne décide. Rapide mais fragile (que se passe-t-il quand elle a tort ?) et oppressif (qu’en est-il des intérêts de tous les autres ?).
Démocratie : Les gens votent. Meilleure représentation, mais vulnérable à la tyrannie de la majorité, la polarisation et les résultats du plus petit dénominateur commun.
Technocratie : Les experts décident. Efficace mais sujet à la capture et à la pensée de groupe.
Anarchie : Personne ne décide. Liberté maximale, coordination minimale.

Le processus RFC trace une voie différente : volontarisme structuré. Personne n’a à participer. Personne n’a à suivre les standards. Mais le processus de développement des standards est ouvert, transparent et conçu pour incorporer le désaccord plutôt que de le passer outre. Le résultat est la coordination sans coercition — des standards que les gens suivent parce que les suivre est utile, pas parce que les suivre est requis.

Ce n’est pas une nouvelle forme de gouvernement. C’est de l’infrastructure pour la coordination. Et l’infrastructure a des propriétés que la gouvernance traditionnelle n’a pas :

Entrée sans permission : N’importe qui peut proposer un RFC. Aucune accréditation requise. Aucune permission nécessaire.
Sortie plutôt que voix : Si vous détestez la direction d’un standard, vous pouvez le forker. Implémentez le vôtre. Laissez le marché décider.
Légitimité par adoption : Un standard n’est pas légitime parce qu’un gouvernement l’a béni. Il est légitime parce que les gens l’utilisent.
Amélioration continue : Les standards évoluent. RFC 821 (SMTP original) a été remplacé par RFC 5321. HTTP/1.1 a été remplacé par HTTP/2, puis HTTP/3. Le processus ne suppose pas qu’il a bien fait les choses du premier coup.

Les limites : Ce que les RFC ne peuvent pas faire

Soyons honnêtes sur les limites.

Le processus RFC fonctionne bien pour la coordination technique — faire parler les ordinateurs entre eux, s’accorder sur les formats de données, définir les protocoles. Il fonctionne moins bien pour :

Conflits de valeurs : Quand le différend n’est pas « quelle approche technique est meilleure ? » mais « les intérêts de qui devraient prévaloir ? » — les RFC n’offrent aucune résolution. Le débat sur la neutralité du Net n’était pas un désaccord technique ; c’était un débat politique sur le pouvoir et l’argent.
Distribution : Les RFC peuvent spécifier comment les données circulent mais pas qui en bénéficie. L’infrastructure d’Internet a été construite par consensus approximatif, mais la richesse qu’elle a générée a été capturée par une poignée d’entreprises. Les protocoles ouverts ont permis l’abondance, mais l’abondance n’a pas été également partagée.
Sécurité : La loi de Postel a rendu Internet interopérable au début, mais la tolérance aux entrées mal formées est un cauchemar de sécurité. Les protocoles modernes doivent être plus stricts, et cette rigueur entre parfois en conflit avec le biais du processus RFC vers la permissivité.

Le cadre de gouvernance MOSAÏQUE dans L’ère de la post-pénurie apprend des RFC mais ne s’y limite pas. La Garde de la Diversité, par exemple, traite les conflits de valeurs que le consensus technique ne peut pas résoudre — exigeant un accord entre des communautés véritablement différentes avant les décisions majeures. La division Fondation/Ascension traite la distribution — garantissant que l’abondance générée par l’automatisation est universellement accessible, pas privativement capturée.

Mais l’intuition centrale du processus RFC — que la coordination peut émerger d’un processus ouvert et d’implémentations fonctionnelles plutôt que d’une autorité descendante — est fondamentale à la vision de la post-pénurie.

Connexion à la vision de la post-pénurie

Le processus RFC démontre que la coordination à l’échelle de la civilisation est possible sans autorité centrale. Des milliards d’appareils. Des milliers d’organisations. Tous les pays sur Terre. Tous se coordonnant à travers des standards que personne n’est forcé de suivre.

Pour le cadre MOSAÏQUE, c’est une preuve de concept :

Le consensus approximatif s’adapte. L’IETF a des milliers de participants dans des centaines de pays. S’ils peuvent atteindre un consensus approximatif sur les protocoles Internet, les Communs peuvent atteindre un consensus approximatif sur les questions de gouvernance.

Le code fonctionnel bat la théorie. Le cadre constitutionnel des Cinq Lois traite les Zones Libres comme des expériences — du « code fonctionnel » pour la société. Si une approche fonctionne dans la pratique, elle a une légitimité que les arguments théoriques ne peuvent pas fournir.

L’innovation sans permission compte. N’importe qui peut proposer un RFC. N’importe qui peut proposer un changement sur comment un Commun fonctionne. La barrière à l’entrée est « avoir une bonne idée et la documenter », pas « être approuvé par le comité ».

La Garde de la Diversité fait écho au fredonnement de l’IETF. La Garde de la Diversité exige un accord entre des Communs démontrément différents — une version structurelle du principe de l’IETF selon lequel les points de vue minoritaires doivent être véritablement considérés avant d’avancer. Il ne suffit pas que 51 % soient d’accord ; les objections fortes doivent être traitées, pas simplement outrevotées.

Internet n’a pas été construit par des rois ou des présidents. Il a été construit par des gens qui ont demandé des commentaires.

C’est le modèle.

Comment Internet a été bâti en demandant gentiment : processus RFC (1969)