Résumé

  • La RFC 4714 voyait dans la révision éditoriale postérieure à l’approbation un problème de contrôle des changements : grammaire et lisibilité peuvent infléchir une formulation convenue ou son sens technique.
  • Ce texte informatif de 2006 proposait de tracer les modifications, d’obtenir les validations requises et de distinguer les retouches des corrections techniques. Il visait de futurs contrats et ne constitue pas une évaluation des performances du RFC Editor.

Analyse

La question n’est pas de savoir si la retouche est bien intentionnée, mais si le texte publié reste rattaché à l’approbation qui l’a légitimé.

Après l’accord, le texte reste en mouvement

L’approbation d’une spécification n’arrête pas forcément le travail éditorial. Avant sa publication, il peut encore être nécessaire de corriger une faute, d’harmoniser la mise en page ou d’améliorer une phrase. La difficulté est que le texte a déjà franchi son contrôle technique. La retouche arrive désormais après la décision collective qui l’a validé.

Publiée en octobre 2006, la RFC 4714 est une note informative sur les exigences du service de publication technique de l’IETF. Sa section 3.3 décrit l’examen éditorial après approbation : grammaire, orthographe, lisibilité, formatage, textes de modèle et organisation du document. Le document ne dit pas que toute retouche est dangereuse. Il explique plutôt pourquoi l’intention de l’éditeur ne suffit pas à prouver que la portée d’une phrase n’a pas changé.

La RFC rapporte qu’à certaines périodes, les retouches stylistiques avaient entraîné de nombreuses modifications dans plusieurs documents. Les auteurs devaient les examiner, les accepter ou les refuser, puis relire les versions suivantes. Ce cycle pouvait retarder sensiblement la publication. Il fallait donc comparer ce coût au gain de clarté, parfois marginal. La note ne fournit pas de mesure statistique générale et ne nomme aucun document lésé : elle décrit une tension de processus, pas une étude de performance.

Voir chaque différence, savoir qui tranche

La réponse proposée est de rendre chaque modification visible et de demander l’accord des représentants techniques compétents. Pour les documents du flux de normes de l’IETF, la RFC cite les auteurs, le responsable du suivi du document lorsqu’il existe, et le directeur de domaine. Elle confie à ce dernier l’autorité d’approbation de toutes les modifications. L’éditeur assure l’examen éditorial, sans se substituer à l’examen technique.

Cette règle évite qu’une décision technique passe inaperçue sous l’étiquette d’une correction de style. Elle empêche également qu’un auteur contourne le processus normal au moyen d’une modification non suivie après l’approbation. Si une correction technique demandée paraît suspecte ou excessive, la RFC propose d’en avertir le directeur de domaine et de suspendre le traitement jusqu’à sa réponse.

Certaines phrases ne se prêtent pas à une normalisation stylistique. La RFC 4714 cite les textes de référence adoptés pour des œuvres dérivées et les formulations négociées avec une autre organisation sur un sujet sensible. Dans ces cas, une publication mot pour mot peut être nécessaire. Pour le flux de normes, le groupe de pilotage de l’ingénierie Internet (IESG) peut le demander. L’exactitude de la formulation fait alors partie du compromis, même si elle paraît moins élégante.

Une correction technique suit une autre voie

La section 3.7 distingue les corrections techniques découvertes après approbation des retouches éditoriales. Un défaut technique peut devoir être corrigé avant publication, mais ce travail ne relève pas de la simple relecture du service de publication. La RFC propose l’accord des auteurs et du directeur de domaine, tout en tenant le responsable du suivi informé. La séparation évite que la mise au propre devienne une refonte technique sans contrôle.

Le compromis est réel. Interdire toute modification peut figer des erreurs évitables ; multiplier les retouches peut rouvrir un texte déjà arbitré, allonger les cycles de validation et obscurcir la filiation entre la version approuvée et la version publiée. La RFC demande une édition légère et de la retenue lorsque le gain de lisibilité est faible ou que la formulation du consensus risque de bouger. Elle souligne aussi qu’une révision avant approbation peut être plus efficace, car elle s’insère dans l’examen technique déjà prévu.

La note précise son propre statut. Elle cherche à clarifier les exigences que l’IETF voulait formuler pour son service de publication et devait éclairer de futurs contrats. Elle ne juge pas la qualité du travail du RFC Editor de l’époque. Il serait donc excessif de transformer ses propositions en preuve d’une pratique uniforme.

Des textes ultérieurs, sans causalité supposée

Le guide de style RFC 7322, paru en 2014, formule une règle proche : ne pas modifier le sens voulu et renvoyer le document à l’organisme qui l’a approuvé lorsqu’une modification sûre ne peut être garantie. Cette convergence éclaire le problème, sans démontrer que la RFC 4714 a causé cette règle ni que toutes ses exigences ont été appliquées.

La RFC 9920, modèle de la série des RFC publié en 2026, décrit une répartition plus récente des rôles entre politique éditoriale, production et règlement des désaccords avec les auteurs. Cette évolution institutionnelle est un contexte actuel, pas une preuve rétroactive sur l’usage des propositions de 2006.

L’idée durable tient en peu de mots : après l’approbation, une « simple retouche » modifie tout de même le texte public issu d’un processus collectif. Un historique des changements rend l’écart vérifiable ; une validation nommée rend la responsabilité visible ; la retenue limite le coût de réouverture. Si le sens est en jeu, la décision doit revenir aux personnes autorisées à trancher le texte technique.

Sources