Résumé

  • draft-fengfar-led-01 conseille aux participants de l’IETF de former leur position avant de recourir à l’IA, de vérifier la fidélité du résultat et d’être toujours transparents. Il s’agit toutefois d’un Internet-Draft individuel actif, pas d’une politique de l’IETF.
  • Son périmètre comprend les courriels, les diapositives et les échanges sur les dépôts, mais exclut le texte des Internet-Drafts et des RFC, également soumis aux BCP 78 et 79.
  • Une divulgation exploitable doit relier une personne responsable, une fonction de l’outil, une partie précise de la contribution, des contrôles humains, l’approbation finale et une voie de correction. La mention « IA utilisée » ne suffit pas.

Trois textes, trois niveaux d’autorité

Un lecteur pourrait croire qu’une règle commune est en train de se former. Le projet de l’IETF dit « Always be transparent ». Le code de conduite de l’IRTF exige la divulgation de quantités importantes de contenu généré. Une note du groupe consultatif du W3C recommande une étiquette lorsque le contenu provient principalement d’un LLM.

Ces formulations se ressemblent, mais elles ne sont pas interchangeables. RFC 9775 représente le consensus de l’Internet Research Steering Group et précise qu’il n’est ni un produit de l’IETF ni une norme. La note du W3C est approuvée par son Advisory Board, non par le W3C dans son ensemble ou par ses membres. Quant à draft-fengfar-led-01, Datatracker le classe comme projet individuel actif, dans l’état I-D Exists, sans flux RFC, directeur de zone responsable ni date de téléconférence de l’IESG.

L’autorité est donc la première donnée de gouvernance. Copier un seuil depuis une institution voisine ferait disparaître la frontière que chacun de ces textes prend soin de publier.

Le projet a été présenté le 31 juillet comme un travail préliminaire, non prescriptif et sans autorité. La version 01, annoncée le 6 août, intègre des remarques de la liste générale de discussion. Elle qualifie ses recommandations concrètes d’extrêmement provisoires et conclut qu’il est trop tôt pour trancher. Cela ne constitue ni une adoption par un groupe de travail, ni un rough consensus, ni une décision de l’IESG.

Le 26 août, un billet de George Michaelson sur APNIC Blog a élargi l’attention portée au sujet. Il relie l’assistance par IA au coût de la participation en anglais dans les travaux de normalisation et de politique des RIR. La page indique cependant que ces vues sont celles de l’auteur et ne représentent pas nécessairement APNIC. C’est un signal de débat, pas une nouvelle règle.

Une frontière de périmètre qui doit rester visible

Le titre du projet peut donner l’impression qu’il porte sur toute utilisation de l’IA dans la normalisation. Son objet est plus étroit : le texte utilisé dans les discussions de l’IETF, notamment les messages de liste, les diapositives de réunion, les issues et pull requests GitHub, et peut-être la messagerie instantanée.

Le texte placé dans un Internet-Draft ou une RFC est explicitement hors périmètre. Ces contributions rencontrent aussi les dispositifs de droits et de propriété intellectuelle des BCP 78 et BCP 79. Une future règle de liste ne réglerait donc pas automatiquement l’attribution dans un document de normalisation. Inversement, une mention dans les remerciements d’un projet ne décrirait pas nécessairement la façon dont les messages qui l’entourent ont été traduits, résumés, rédigés ou envoyés.

Le conflit initial montre pourquoi cette séparation compte. Un participant s’est servi de l’IA pour mieux exprimer des idées déjà formées. Un lecteur, percevant une prose typique d’un LLM sans pouvoir discerner l’apport humain, a cessé de lire. Les deux auteurs exposent ces perspectives sans transformer l’une d’elles en verdict.

Leur terrain commun est solide : définir sa position avant de solliciter l’outil, contrôler que le résultat lui reste fidèle et assumer entièrement ce qui est envoyé sous son nom. Mais un principe de responsabilité ne devient une preuve durable que lorsqu’il est relié à une contribution identifiable.

Le coût ne disparaît pas, il change de côté

L’assistance linguistique peut corriger une inégalité réelle. Une idée technique précise n’entraîne pas automatiquement une expression idiomatique en anglais. Traduction et révision peuvent permettre à un participant de consacrer plus d’attention au protocole et moins à sa forme linguistique.

La même capacité peut transférer le coût aux lecteurs. Un expéditeur produit en quelques minutes une réponse longue et polie que plusieurs personnes devront contrôler lentement : vérifier les références, retrouver le désaccord réel et déterminer si la personne comprend ce qu’elle affirme. Des agents qui se répondent peuvent créer le volume apparent d’une communauté sans ajouter de jugement indépendant.

Une simple étiquette ne révèle pas ce déplacement. Elle ne dit pas si l’outil a traduit une position achevée, recherché une ancienne discussion, inventé un argument, rédigé tout le message, fourni un fait non vérifié ou publié sans validation humaine.

Le style ne peut pas compléter le dossier. Une prose très lisse, une vitesse inhabituelle ou un score de détecteur sont des inférences, non une provenance. Les traiter comme des preuves pénaliserait précisément les personnes dont l’anglais n’est pas la langue première et celles qui utilisent des outils d’accessibilité. Une déclaration attribuable ne prouve pas davantage la justesse du fond : elle dit qui répond du processus.

Le relevé de responsabilité proposé par Daniel Kade

L’unité minimale utile est un relevé attaché à la contribution, et non un badge attaché à la personne.

Il commence par l’expéditeur humain et un identifiant stable de la contribution. Il qualifie la fonction de l’outil : traduction, révision, résumé, rédaction, recherche, analyse, code, assistance à la modération ou envoi autonome. Il indique ensuite la partie affectée : message entier, section nommée, pièce jointe, fragment de code ou affirmations précises.

Une autre rubrique décrit la frontière des données. L’outil a-t-il travaillé uniquement sur des sources publiques, sur des notes locales ou sur des éléments confidentiels ? Cette classification ne doit pas publier les éléments eux-mêmes. Exiger le prompt complet, des identifiants, des notes privées, un raisonnement interne ou un contexte propriétaire transformerait la transparence en fuite de sécurité.

Le relevé précise enfin le travail humain : quelles sources factuelles et citations ont été contrôlées, si la fidélité à la position réelle a été vérifiée, si une personne a approuvé la version finale et si le système pouvait envoyer seul. Il conserve la version de la politique, sa date et l’adresse où une déclaration ou contribution erronée peut être corrigée ou remplacée.

Le nom du modèle peut fournir un contexte, mais il ne constitue pas le centre du dispositif. Un fournisseur peut modifier le comportement sans changer l’étiquette du produit. Surtout, le modèle employé ne démontre ni la compréhension d’un protocole, ni le contrôle d’une citation, ni l’acceptation de la responsabilité.

Ce relevé est la proposition de Daniel Kade, pas une exigence du projet. Il vise à rendre visible l’exécution de l’outil tout en conservant la décision chez l’être humain.

Définir avant de modérer

RFC 9245 décrit la liste générale de discussion et y place, lorsqu’il n’existe pas de meilleur espace, les questions de direction, de politique et de processus de normalisation de l’IETF. RFC 9945 répartit les responsabilités entre participants, administrateurs de forum, modérateurs, directeurs de zone et IESG. Il limite les mesures de modération aux communications perturbatrices et prévoit procédures publiques, réexamen et appel.

Aucun de ces RFC ne crée de test d’auteur IA. Aucun ne transforme la suspicion stylistique en infraction autonome. Si une future divulgation rejoint un jour la modération, sa définition doit précéder la sanction : seuil, preuve, notification, correction et appel. Autrement, une accusation sur la forme devient un pouvoir procédural.

Le projet lui-même recommande des questions non accusatoires en cas de doute. Il note aussi qu’un nouveau venu peut ignorer la règle à venir et que présumer un accès égal aux outils ajoute une barrière. L’ordre prudent est donc de définir les fonctions et le périmètre, d’essayer un relevé, de mesurer la charge de lecture, puis seulement de décider si l’absence de déclaration relève du conseil, d’un défaut de processus ou d’une conduite perturbatrice.

Ce que les documents ne permettent pas de conclure

L’IETF n’a ni adopté ni rejeté la participation assistée par IA. Rien dans ce dossier n’établit qu’un texte généré a modifié un résultat de consensus. Le projet n’impose pas aujourd’hui une déclaration pour chaque message assisté.

RFC 9775 ne gouverne pas les discussions ordinaires de normalisation de l’IETF. La note du groupe consultatif du W3C n’exprime pas un consensus de ses membres. Le billet d’APNIC Blog n’est pas une politique d’APNIC. Aucun participant nommé n’est montré ici comme ayant déformé son rôle ou autorisé un envoi autonome.

La conclusion bornée est plus utile : le débat a trouvé la bonne personne responsable, mais pas encore le bon objet documentaire. La transparence devient gouvernance lorsque l’objet, l’autorité, la vérification et la voie de correction sont identifiables.

Sources

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179