Résumé
- RFC 5385 proposait un modèle Word dont l’aperçu et l’impression pouvaient reproduire la pagination du texte ASCII conforme, tout en exigeant une chaîne distincte : styles contrôlés, pilote texte, fichier
.prnet post-processeur Perl. - La conformité visuelle est donc un test de réception, non un titre de propriété documentaire. La politique actuelle de la Série RFC distingue la version définitive RFCXML des versions de publication HTML, texte et PDF afin d’attribuer clairement l’autorité.
La réception par l’œil n’est qu’une réception
Dans beaucoup de comités, le document est réputé terminé lorsqu’il ne surprend plus. Les titres sont à leur place, les références semblent cohérentes, les pages se succèdent sans rupture. Le regard collectif signe alors une forme d’acceptation silencieuse.
RFC 5385 avait justement pour ambition de rendre ce contrôle utile. Le texte, publié en 2010 dans la série indépendante et avec un statut informatif, décrivait une deuxième version d’un modèle Microsoft Word destiné aux Internet-Drafts et aux RFC. L’auteur pouvait travailler dans un environnement visuel, employer le mode plan, déplacer une section et prévisualiser un résultat presque identique au document ASCII attendu.
Le mot important est « presque », mais la frontière ne se réduit pas aux guillemets courbes. Le fichier affiché dans Word n’était pas le texte conforme. Pour produire ce dernier, il fallait imprimer vers un pilote Generic/Text Only, obtenir un fichier .prn, puis le faire passer dans un programme Perl. Celui-ci retirait les retours chariot, normalisait certains signes, recomposait les frontières de page et signalait les caractères interdits.
L’écran et la sortie pouvaient donc coïncider ligne par ligne tout en étant deux objets différents. Entre eux se trouvait une opération capable de modifier, refuser ou oublier des données. Voir le résultat confirmait une mise en forme ; cela ne disait pas quel fichier source avait été approuvé, quel programme avait été exécuté ni si le même résultat pourrait être reconstruit.
Le modèle organisait aussi ce qui ne se voit pas
Le modèle redéfinissait Normal, Heading1 à Heading9, Header, Footer et Caption. Il ajoutait des styles pour les figures, les listes, les références et les annexes. RFC 5385 insistait : il ne fallait pas employer d’autres styles.
Cette discipline n’était pas décorative. Les styles internes de Word permettaient au mode plan de promouvoir ou rétrograder une section et de renuméroter les titres. Deux paragraphes gras de même apparence pouvaient donc avoir des capacités très différentes : l’un appartenait à la structure, l’autre ne faisait que lui ressembler.
Le même problème existe dans les publications contemporaines. Un texte bleu souligné peut n’être aucun lien. Une grande ligne grasse peut n’être aucun titre pour un lecteur d’écran. Une image peut apparaître correctement tout en ayant perdu sa description alternative. La mise en page est une projection de la structure, pas son certificat.
Un dossier d’acceptation doit descendre sous les pixels : source exacte, version du modèle, styles utilisés, champs automatiques, polices, ressources liées et avertissements. Sans ces éléments, l’organisation peut posséder une page convaincante et pourtant être incapable de prouver le document qui l’a produite.
Le convertisseur exerce un pouvoir éditorial technique
Transformer des guillemets « intelligents » en caractères ASCII paraît anodin. Retirer des lignes entre pied et en-tête paraît mécanique. Pourtant, toute normalisation contient une politique : certaines différences sont effacées, d’autres provoquent une erreur, d’autres encore sont conservées.
Dans le cas de RFC 5385, la contrainte ASCII rendait ce choix visible. Que se passe-t-il lorsqu’un nom, un symbole ou un identifiant ne peut pas être représenté ? Le programme peut refuser, remplacer ou laisser passer. Chacune de ces réactions produit une preuve différente.
Le post-processeur était reproduit dans l’annexe, ce qui rendait ses règles examinables. Mais l’exploitation devait encore conserver la version réellement exécutée, le fichier d’entrée, la sortie, le système et le statut de validation. « Nous avons utilisé l’outil officiel » est une affirmation de marque, pas un reçu reproductible.
Aujourd’hui, le minimum raisonnable est de calculer l’empreinte de la source approuvée, du paquet de génération et de chaque sortie. Il faut conserver les options, les journaux, la date et la décision du relecteur. Si l’outil insère volontairement des éléments variables, la procédure doit distinguer ces variations de toute différence sémantique.
Le modèle changeait alors que le RFC restait fixe
La section de sécurité fournit un indice précieux. Le modèle ne contenait pas de macros tel qu’il avait été conçu et distribué. L’auteur avait envisagé d’inscrire les empreintes MD5 du modèle et du programme. Le script pouvait être stabilisé, mais le modèle devait suivre l’évolution du texte juridique obligatoire ; son empreinte était donc publiée à côté de l’outil vivant plutôt que figée dans le RFC.
MD5 appartient ici à l’histoire, pas aux recommandations actuelles. Le fait durable est la dissociation des cycles de vie. Un RFC stable expliquait un artefact susceptible de changer. Dire « le modèle de RFC 5385 » ne suffisait pas à identifier les octets employés.
Cette ambiguïté se retrouve dans les formulaires réglementaires, les générateurs contractuels et les modèles de rapport. Un nom stable masque plusieurs versions. Deux équipes croient utiliser « le même modèle » alors que les clauses, champs ou comportements diffèrent.
Tout modèle mutable doit donc porter une version, une empreinte, une date d’effet et un historique. Le document produit doit garder cette provenance. Quand le modèle insère du texte obligatoire, le contrôle doit porter sur le texte développé, pas seulement sur le nom du modèle.
Les références montraient le défaut avant même la publication
RFC 5385 modifiait aussi le traitement des références. Dans l’ancien mécanisme fondé sur les notes de fin, supprimer la première citation pouvait supprimer la référence elle-même malgré l’existence de renvois ultérieurs. La nouvelle version utilisait des paragraphes de corps numérotés et proposait aussi des signets pour des étiquettes auteur-année.
Sur papier, les deux solutions pouvaient sembler équivalentes. Lors d’une modification, leur comportement divergeait. C’est précisément ce qu’un contrôle visuel immobile ne peut pas découvrir.
Il faut tester le document en mouvement : déplacer un titre, supprimer une première citation, ajouter une annexe, régénérer la table des matières, exporter plusieurs formats, vérifier l’ordre de lecture et les cibles. La robustesse d’un système documentaire réside dans ses invariants sous transformation, non dans la perfection d’un exemplaire.
La Série RFC a fini par nommer les niveaux d’autorité
Les besoins ont ensuite changé. RFC 6949 a décrit les limites du seul ASCII face à l’accessibilité, aux métadonnées, aux appareils variés et aux caractères internationaux. RFC 7990 a proposé un modèle à source structurée. RFC 9720, qui l’a remplacé en 2025, emploie un vocabulaire plus précis.
RFCXML est le format définitif. Le RFC publié dans ce format est la version définitive. HTML, texte brut et PDF sont des formats de publication ; leurs fichiers sont des versions de publication. La version définitive contient toute l’information destinée au RFC et permet de trancher les questions d’intention.
Il ne faut pas projeter cette politique en arrière sur le Word de 2010. Le rapprochement porte sur la frontière, pas sur le statut historique. RFC 5385 rendait observable la séparation entre atelier d’écriture, conversion et sortie. RFC 9720 attribue aujourd’hui explicitement l’autorité à une source sémantique et traite les autres fichiers comme des rendus officiels mais dérivés.
Toute organisation devrait adopter cette clarté. Pour chaque classe de document, désigner la couche qui fait foi, les représentations distribuées et la procédure de résolution des écarts. Un aperçu CMS, un PDF signé et une ligne de base ne doivent pas devenir trois autorités concurrentes par accident.
Rééditer exige de conserver la trace du temps
RFC 9720 autorise la réédition limitée d’une version définitive ou de ses rendus, notamment lorsque le schéma ou les outils changent. Le sens doit être préservé autant que possible, les anciennes versions doivent rester accessibles et le motif doit être public.
Ce mécanisme reconnaît qu’un archivage sérieux ne consiste pas à nier le changement. Les logiciels vieillissent, les erreurs de rendu existent et les exigences d’accessibilité évoluent. La maîtrise vient de la traçabilité.
Le risque est également nommé : une régénération peut introduire une modification involontaire et altérer une information critique. Une nouvelle page plus régulière peut être sémantiquement moins fidèle. La comparaison doit donc couvrir les exigences, identifiants, références, liens, dessins et ordre logique, pas seulement les pixels.
RFC 9920, modèle actuel de la fonction éditoriale, sépare en outre la définition de la politique, son approbation et sa mise en œuvre par le RFC Production Center. La responsabilité des outils est explicite. Exploiter le convertisseur donne un devoir de fiabilité, non un droit silencieux de réécrire le contenu.
Quatre reçus pour une publication durable
Le premier reçu porte sur l’intention : source sémantique, auteur, portée et approbation. Le deuxième porte sur la transformation : entrées, outils, configuration, avertissements et empreintes de sortie. Le troisième porte sur la publication : autorité, identifiant, statut, adresse publique et date. Le quatrième porte sur l’archive : versions conservées, rééditions et chemin de récupération testé.
La revue visuelle reste nécessaire. Elle protège les tableaux, les figures, les coupures et la lisibilité. Mais elle ne remplace aucun de ces reçus. Une empreinte non plus : elle prouve l’égalité de deux séquences d’octets, pas leur approbation ni leur complétude.
Le test final devrait demander à un tiers de reconstruire une sortie dans un environnement propre, d’expliquer les écarts, puis de retrouver la version antérieure après une réédition simulée. S'il ne peut répondre qu’« elles se ressemblent », la réception de la page est terminée ; celle du document ne l’est pas.
Sources
- RFC 5385 en HTML
- RFC 5385 en texte brut
- Notice de publication de RFC 5385
- Dossier IETF Datatracker de RFC 5385
- RFC 3285 : premier modèle Word
- RFC 9720 : formats et versions des RFC
- RFC 7990 : cadre des formats RFC
- RFC 7991 : vocabulaire RFCXML
- RFC 8153 : préservation numérique
- RFC 6949 : exigences de format
- RFC 7322 : guide de style
- RFC 9920 : modèle actuel de l’éditeur RFC
- RFC 9280 : modèle précédent
- RFC 7992 : format HTML
- RFC 7994 : format texte brut
- RFC 7997 : caractères non ASCII
- RFC Editor : comment un RFC est créé
- Heng Lu, Minimum Initial Specification
- Heng Lu, Running-Code Primacy
- Heng Lu, Reality Layers and Symbolic Power
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
