Résumé

  • Le RFC 9945 est bien un Best Current Practice publié et institue une politique de modération pour les espaces publics en ligne de l’IETF. Pourtant, ses changements ne prennent effet qu’après approbation par l’IESG des procédures prévues à la section 4 ; jusque-là, les processus antérieurs restent applicables.
  • La mention bibliographique « obsolète », la nomination d’une équipe, l’existence d’un dépôt et l’usage d’une consigne ne prouvent pas la même chose. Un reçu d’activation doit relier la révision exacte, l’acte et l’heure d’approbation, le champ, les anciens textes remplacés, les responsables et le traitement des dossiers en cours, sans exposer les plaintes.

Deux listes de noms, une seule question d’autorité

La page Datatracker de l’équipe actuelle présente six personnes. Elle reprend le nouveau périmètre : procédures pour les forums publics de l’IETF, administration des espaces pléniers, intervention dans les espaces sans autre administrateur, nomination et responsabilité devant l’IESG.

Le dépôt public ietf/Moderators, observé à la révision figée b907805e15…, raconte une histoire plus étroite. Son README vise surtout la liste générale de discussion de l’IETF sous le RFC 9245. Sa procédure opérationnelle nomme trois personnes, impose l’accord de deux modérateurs et décrit une échelle à trois niveaux. Un autre fichier agrège le nombre d’actions par niveau.

Il serait téméraire de conclure à une faute. Le dépôt peut documenter un dispositif ancien encore utile, un sous-ensemble du nouveau système ou une migration inachevée. La liste des membres peut simplement ne pas avoir été mise à jour. Les procédures communes peuvent aussi être rédigées ailleurs.

Mais l’utilisateur ne devrait pas devoir deviner laquelle de ces hypothèses est vraie. La page d’équipe atteste une nomination. Le dépôt atteste l’existence d’un texte à une révision précise. Les statistiques attestent l’emploi de catégories. Aucun de ces objets, pris isolément, ne démontre que l’IESG a approuvé cette révision pour tous les forums et qu’elle était applicable au moment d’une action.

Le RFC contient un interrupteur externe

Publié en février 2026 sous le numéro BCP 245, le RFC 9945 représente le consensus de l’IETF et a franchi la revue publique et l’approbation de publication par l’IESG. Il déclare obsolètes les RFC 3683 et 3934, remplace certaines parties du RFC 9245 et met à jour le RFC 2418.

La politique nouvelle couvre les listes, les groupes de discussion, les outils collaboratifs comme GitHub ou GitLab, les wikis, les systèmes de tickets et les futurs forums publics adoptés par l’IETF. Elle protège le désaccord respectueux : être en dehors du rough consensus ne suffit pas à rendre une personne perturbatrice. Elle recherche une modération équitable, cohérente et rapide, avec réexamen, appel et équilibre entre transparence et vie privée.

Cependant, le dernier paragraphe de l’introduction pose une condition. Les changements prennent effet lorsque les procédures de la section 4 ont été approuvées par l’IESG. La section 4 précise la chaîne : l’équipe élabore procédures et critères avec la contribution de la communauté ; l’IESG les approuve avant leur entrée en vigueur ; ils sont rendus publics, sans devoir intégrer la série des RFC. Tant qu’ils ne sont pas établis, les processus antérieurs restent en vigueur.

Le dispositif sépare donc le cadre durable de son mode d’emploi adaptable. C’est rationnel : une méthode de traitement, un modèle de notification ou un délai pratique peuvent évoluer sans rouvrir tout un BCP. En contrepartie, l’événement décisif est situé hors du RFC. La publication fournit la constitution du régime ; elle ne contient pas nécessairement la date à laquelle son dispositif opérationnel remplace l’ancien.

« Obsolète » décrit la bibliothèque, pas toute la transition

La fiche du RFC 3934 indique correctement qu’il est obsolété par le RFC 9945. Ce lien aide le lecteur à comprendre la direction du corpus. Il ne porte ni la révision des procédures ni l’horodatage de leur approbation.

Ces deux énoncés peuvent donc coexister : le RFC 9945 a formellement obsolété un document dans la série ; sa propre clause conserve les processus antérieurs jusqu’à l’accomplissement d’une condition. Il n’est pas nécessaire de faire disparaître l’un pour sauver l’autre. Il faut reconnaître qu’ils décrivent deux états différents.

Confondre les états crée des erreurs symétriques. Le lecteur peut croire que tout ancien processus a cessé le jour de publication. À l’inverse, il peut considérer le nouveau BCP comme inexistant jusqu’au basculement, alors que le cadre, les limites de champ et l’institution de l’équipe sont bel et bien publiés. Une chronologie d’activation rend ces nuances consultables au lieu de les abandonner à l’interprétation d’une étiquette.

Un appel a rendu le problème concret

Le 30 juin, Andrew Lee a saisi l’IESG au sujet d’une modération pendant le Last Call d’un groupe de travail TLS. L’appel soutenait notamment que le RFC 3934 ne pouvait plus fournir l’autorité, puisqu’il figurait comme obsolété.

La réponse de l’IESG, datée du 9 juillet, rejette l’appel après examen au fond. Sur ce point précis, elle considère l’argument erroné : le RFC 3934 restait en vigueur en vertu de la clause transitoire du RFC 9945, les nouvelles procédures et leurs critères n’ayant pas encore été établis. L’IESG distingue aussi une citation de BCP 9, qui ne conférait pas elle-même le pouvoir de modération, de l’autorité réellement utilisée.

Ce précédent ne sera pas transformé ici en procès des personnes. Il ne démontre ni censure, ni partialité, ni illégalité. Il ne signifie pas non plus que chaque acte de modération passé ou futur est automatiquement juste. L’IESG a répondu à d’autres griefs ; cette analyse ne les rejoue pas.

L’intérêt est probatoire. Pour identifier la règle applicable à une date, l’IESG n’a pas pu s’arrêter à la relation « obsolète ». Il a dû joindre l’événement au prédicat de transition. Voilà exactement la fonction d’un reçu d’activation.

La réponse établit l’état reconnu au 9 juillet, pas pour toujours. Au 11 septembre, aucune approbation publique postérieure de la procédure de section 4 n’a été trouvée dans les sources officielles examinées. Une recherche infructueuse ne prouve jamais une absence. Dans un système qui impose publicité et approbation, elle révèle néanmoins un problème de repérage : un participant raisonnable doit pouvoir découvrir l’acte sans reconstituer des archives dispersées.

L’autorité est distribuée pour de bonnes raisons

Le RFC 9945 ne remet pas tous les leviers à l’équipe centrale. Les administrateurs restent responsables en première ligne. Dans un groupe de travail, les chairs sont administrateurs par défaut ; ils peuvent déléguer mais doivent recevoir, accuser réception et suivre les plaintes. Après consultation de l’équipe, ils peuvent modifier ou annuler une action.

Les modérateurs établissent des procédures communes, conseillent et peuvent agir lorsqu’un administrateur ne répond pas à temps ou lorsqu’un comportement traverse plusieurs forums. Ils administrent directement les espaces pléniers et ceux qui n’ont personne d’autre. Les Area Directors traitent les conflits initiaux. L’IESG nomme et révoque les membres, approuve les procédures, évalue le dispositif et peut entendre un appel. L’IAB intervient plus loin dans la chaîne.

L’Ombudsteam conserve sa mission propre contre le harcèlement. L’IETF Administration LLC possède une capacité d’urgence distincte lorsque des conseils juridiques identifient un risque grave pour l’organisation. Cette capacité a ses propres modalités de notification et de revue. L’IRTF, l’IAB, le RSWG, le RSAB et le flux de soumission indépendant ne sont pas automatiquement placés sous la politique sans accord explicite.

Cette pluralité protège contre la concentration. Elle exige aussi une excellente conservation des versions. Une plainte peut passer d’un forum à un Area Director, puis à l’IESG et à l’IAB. Chaque instance doit revoir la décision selon la règle qui avait force lors de l’acte, pas selon la version la plus commode au jour de l’appel.

Les anciens processus étaient eux-mêmes pluriels

Le RFC 3934 organisait l’action des chairs sur la liste d’un groupe de travail. Le RFC 3683 définissait une action de retrait des droits de publication conduite avec l’IESG et la communauté. Le RFC 9245 réglait la liste générale de discussion. Le RFC 2418 confiait des responsabilités de processus aux chairs. Le RFC 2026 fournit l’architecture plus large des appels.

Le RFC 9945 répond à des faiblesses connues de cet assemblage : critères inégaux, procédures lentes, difficulté à voir un schéma traversant plusieurs listes et absence de dispositif uniforme pour le chat, les dépôts ou les outils collaboratifs. Maintenir temporairement l’ancien ne signifie pas lui donner un pouvoir sans bornes.

Les limites restent opposables. La modération ordinaire concerne les communications perturbatrices dans les forums publics en ligne. Elle ne comprend pas le retrait d’un compte Datatracker, l’exclusion d’une réunion, la suppression d’un contenu ni la surveillance de conversations privées ou étrangères à l’IETF. Une procédure de liste ne devient pas, par transition, une compétence générale.

La transition doit donc dire plus que « ancien » ou « nouveau ». Elle doit préciser le forum, le type d’action, la date, les affaires déjà ouvertes et la règle de réexamen. Le RFC prévoit lui-même qu’une suspension indéfinie imposée avant le nouveau processus est réexaminée selon le processus qui existait lors de sa décision. C’est une règle de conservation historique, non une note secondaire.

Le contenu minimal du reçu

Un reçu public d’activation peut rester très court. Il commencerait par l’identité immuable des procédures : révision exacte, empreinte cryptographique, adresse publique et classes de forums couvertes. Un lien vers une branche modifiable ne suffit pas à prouver le passé.

Il conserverait ensuite l’acte d’autorité : période de contribution de la communauté, index des réponses, référence de la décision IESG, heure de décision et heure d’effet. Si le déploiement est progressif, ce décalage doit être dit. Si approbation et effet coïncident, il suffit de le confirmer.

Une table de remplacement nommerait chaque processus ou section antérieure qui cesse de gouverner, ainsi que les exceptions, les actions héritées et les organisations hors champ. La nomination de l’équipe apparaîtrait dans une autre rubrique, avec les intervalles de rôle. Ainsi, une liste de noms ne pourrait plus servir de preuve indirecte de la procédure.

Le reçu traiterait aussi les objets vivants : plaintes pendantes, restrictions actives, appels ouverts et délais de réintégration. La partie publique peut afficher des nombres et des classes de versions. Les identités et le contenu restent dans un dossier protégé. Lorsqu’une affaire traverse la date d’effet, la règle retenue est enregistrée au lieu d’être reconstruite après coup.

Enfin, les administrateurs de forums et les responsables techniques pourraient accuser réception de la nouvelle version. Cet accusé ne confère pas l’autorité ; il montre que l’approbation centrale a été traduite dans les espaces où elle doit devenir opératoire.

Montrer la règle sans exposer la personne

La transparence procédurale ne commande pas la publication des plaintes. Un signalement peut révéler l’auteur, la cible, un contexte privé ou des propos qu’il serait nocif de répéter. Un avis juridique peut imposer une discrétion supplémentaire. La politique cherche précisément un équilibre entre examen public et protection des personnes.

Le reçu n’a donc besoin que de métadonnées institutionnelles : empreinte, approbation, date d’effet, champ, table de remplacement, rôles, quantités de migration et corrections. Les décisions individuelles exigent un autre dossier : notification, classe de motif, portée, durée, décideur, réexamen et appel.

Il faut résister à trois substitutions. Une procédure correctement activée ne prouve pas qu’une décision est équitable. Une notification ne prouve pas, à elle seule, les faits reprochés. Un rapport agrégé ne prouve ni cohérence ni incohérence dans une affaire précise. Relier les dossiers ne signifie pas les fusionner.

Les textes de Heng Lu sont ici une méthode de lecture, pas une source sur l’IETF. Un symbole, une décision exécutable et une observation appartiennent à des couches différentes. La spécification initiale minimale doit fixer la jointure nécessaire, puis laisser les futurs choix locaux évoluer sous l’autorité appropriée.

Le RFC 9945 a choisi une architecture prometteuse : un cadre durable, des procédures publiques adaptables, plusieurs contrôles et une voie d’appel. Pour qu’elle tienne sa promesse, le basculement doit devenir aussi visible que la publication. L’équipe n’est pas le reçu. Le dépôt n’est pas le reçu. Le mot « obsolète » n’est pas le reçu. Le reçu est l’acte daté qui permet à tous de savoir quelle règle avait force.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9945/
  5. https://www.rfc-editor.org/rfc/rfc9945.html
  6. https://www.rfc-editor.org/rfc/rfc3934.html
  7. https://www.rfc-editor.org/rfc/rfc3683.html
  8. https://www.rfc-editor.org/rfc/rfc9245.html
  9. https://www.rfc-editor.org/rfc/rfc2418.html
  10. https://www.rfc-editor.org/rfc/rfc2026.html
  11. https://datatracker.ietf.org/group/iesg/appeals/artifact/314
  12. https://datatracker.ietf.org/group/iesg/appeals/artifact/315
  13. https://datatracker.ietf.org/group/ietfmoderators/about/
  14. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/README.md
  15. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/sop.md
  16. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/stats.md