Résumé

  • RFC 9592 a retiré le Tao de l’IETF parce qu’un long document unique ne pouvait suivre des sujets, des modes de participation et des besoins de lecteurs qui évoluaient à des rythmes différents.
  • Le passage à des pages ciblées et à plusieurs médias améliore la capacité de mise à jour ; il ne confond pas pour autant actualité, autorité, archive et version effectivement consultée.

L’histoire commence en 1993 avec RFC 1391. Quatre autres éditions sous forme de RFC paraissent durant les dix-sept années suivantes. RFC 4677 est la dernière de cette série, en 2006. En 2012, RFC 6722 organise le Tao comme page web afin de faciliter les révisions. Pourtant, RFC 9592 constate qu’en onze ans seulement quatre nouvelles versions ont été publiées. Le support était modifiable ; l’unité de travail restait lourde.

Un document unique attachait ensemble des horloges différentes

Les règles d’une réunion, la participation à distance, le Hackathon, les usages des groupes de travail et les ressources destinées aux nouveaux venus ne vieillissent pas ensemble. Quand il fallait réexaminer l’ensemble pour corriger une partie, l’effort de lecture et d’approbation devenait le goulot d’étranglement. Un ajout pertinent pouvait aussi disparaître dans la longueur du texte.

RFC 9592 choisit donc une autre architecture : guides ciblés, documents plus courts, vidéos, podcasts, billets, Datatracker et autres canaux. La page actuelle « Getting started » n’essaie pas d’être une encyclopédie. Elle dirige vers une introduction, les RFC, les groupes de travail, l’arrivée d’un nouveau sujet, les réunions, les listes et les enregistrements. Le parcours peut évoluer par module.

Cette décision améliore la maintenabilité. Elle ne délivre pas automatiquement une preuve de version.

RFC 6722 avait rendu la garde éditoriale visible

Le contrat de 2012 était précis. L’IESG désignait les éditeurs. Une liste recevait les propositions. L’éditeur préparait une révision possible ; l’IESG en gardait l’approbation. Chaque édition devait afficher un horodatage. Les versions publiées devaient rester accessibles à des adresses datées, accompagnées d’une liste de révisions.

Ces mécanismes ne transformaient pas le Tao en norme de procédure. RFC 9592 rappelle qu’il s’agissait d’une présentation informelle, développée et entretenue par la communauté. Ils fournissaient cependant trois réponses essentielles : quelle édition, publiée quand, sous quelle garde.

RFC 9592 ne prescrit pas une procédure universelle équivalente pour chaque page, vidéo, billet ou canal qui lui succède. Il faut s’arrêter exactement là. Le texte ne prouve pas l’absence de dépôt, de sauvegarde, de revue interne ou d’historique dans les systèmes actuels. Il montre seulement que la nouvelle architecture ne reçoit pas, par le seul acte de retraite, les reçus publics de l’ancienne.

Cinq vérités qui ne doivent pas se remplacer

Une adresse officielle identifie le publicateur actuel. Une page actuelle expose son explication présente. Une archive datée conserve une formulation antérieure. Une capture établit ce qu’un lecteur précis a vu. Un document formel indique quelle procédure possède un statut normatif. Enfin, la pratique révèle ce que les participants et les systèmes ont réellement fait.

On peut avoir raison aujourd’hui et ne pas pouvoir reconstruire hier. On peut archiver parfaitement un conseil erroné. On peut publier une explication institutionnelle sans créer une compétence sur le reste de l’Internet. L’introduction actuelle de l’IETF conserve d’ailleurs cette limite : les standards sont volontaires et l’IETF ne contrôle ni ne patrouille l’Internet.

La traçabilité utile ne demande donc pas le retour du grand manuel. Chaque module sensible peut garder un petit dossier : propriétaire, périmètre, sources formelles, URL, instant de publication, empreinte ou copie, motif d’une modification importante, revue, référence remplacée et prochain déclencheur de contrôle.

Le lecteur qui prend une décision doit aussi laisser un reçu : page consultée, date, version ou empreinte, texte formel prioritaire en cas de conflit, interprète responsable et échéance de revalidation. Sans cela, une page modifiable risque d’être citée plus tard comme une règle immuable qu’elle n’a jamais été.

La chaîne devient vérifiable : besoin, propriétaire, source, changement proposé, revue, publication, version, archive, observation du lecteur, choix local, résultat opérationnel. La modularité accélère certains maillons ; elle n’en abolit aucun.

La primauté du code en fonctionnement remet enfin la hiérarchie à sa place. Le guide vaut par l’aide qu’il apporte à une participation et à une ingénierie réelles. Son étiquette officielle n’est pas un résultat. La spécification initiale minimale recommande une base commune suffisamment claire, puis des décisions locales identifiées. La discipline des couches de réalité interdit de réduire « page officielle », « processus approuvé », « croyance du participant » et « résultat exécuté » à un même symbole.

Sources