Résumé

  • Le rapport public de l’Executive Director pour la réunion du Board du 1er septembre indique qu’un outil a été créé pendant l’IETF 126 afin d’analyser les e-mails des listes pour y détecter du contenu généré par IA, au moyen d’API publiques et d’un service commercial.
  • Le rapport ajoute que l’IETF Chair envisage un usage plus large de l’information, sans préciser les listes, les données transmises, le prestataire, la version, la validation, la signification du score ni les décisions visées.
  • Rien dans le dossier public ne montre une utilisation pour la modération, une sanction ou une attribution d’auteur. Le résultat demeure un signal expérimental dépourvu de fonction institutionnelle publiée.
  • Avant toute extension, l’IETF devrait publier une fiche d’usage expérimental : finalité, corpus, flux externe, évaluation, usages permis et interdits, accès, conservation, correction, autorité et date d’extinction.

La mesure existe avant son mandat

Le rapport de l’Executive Director ne consacre qu’un court passage au sujet. Pendant l’IETF 126 à Vienne, explique-t-il, le dirigeant a créé, à titre de projet parallèle, un outil chargé d’analyser les messages envoyés aux listes de diffusion de l’IETF. Des API publiques et un service commercial de détection d’IA ont été utilisés. Puis vient la phrase décisive : l’IETF Chair examine comment employer plus largement l’information produite.

Une expérimentation technique n’est pas en soi une politique. Elle peut servir à comprendre un service, à éprouver une hypothèse ou à observer une tendance. Le changement de nature intervient lorsque son résultat circule : un responsable consulte un score, compare des listes, sélectionne un message, demande une explication ou déclenche une procédure. La mesure commence alors à influer sur une relation institutionnelle.

Or le score ne porte pas en lui son mandat. Le rapport ne dit pas quelles listes ont été traitées, sur quelle période, avec quel échantillon. Il n’identifie ni les champs envoyés à l’extérieur, ni le fournisseur, ni le modèle, ni les langues évaluées. Il ne décrit pas de jeu de validation, de seuil, de taux d’erreur, de durée de conservation ou de groupe d’utilisateurs.

Il serait abusif d’en conclure que ces précautions n’existent nulle part en interne. Un compte rendu opérationnel succinct n’a pas vocation à devenir un article scientifique. La conclusion vérifiable est plus limitée : le public ne dispose pas encore du document qui permettrait de relier cette mesure à un objectif, une méthode et une autorité.

Le 1er septembre reste au futur

Le statut de la source impose une discipline de temps. Le document est le rapport préparatoire de la réunion no 99 du Board de l’IETF LLC, prévue le 1er septembre 2026. Cet article paraît le 30 août. La réunion n’a pas encore eu lieu et le site du Board précise que les procès-verbaux officiels sont publiés après approbation.

L’ordre du jour place le rapport de l’Executive Director dans la partie ouverte. Il ne comporte pas de résolution distincte sur le détecteur. Cette absence indique seulement qu’aucune décision autonome n’est visible sous ce titre. Elle ne permet pas de prédire les questions du Board, d’exclure une discussion dans le cadre du rapport ou de connaître d’éventuelles instructions non publiques.

Les faits tiennent donc en trois propositions. L’expérience a été menée. L’IETF Chair considère un usage plus large. Aucune règle publique attribuant un rôle au résultat n’a été identifiée. Transformer cette réflexion en décision adoptée reviendrait à écrire le procès-verbal avant le Board.

Un message ouvert ne donne pas tous les droits au résultat

L’ouverture des archives IETF est réelle. L’organisation indique administrer plus de 500 listes, sur lesquelles s’effectue l’essentiel du travail de normalisation. La plupart donnent accès à leurs archives et à leur téléchargement. La page Open records facilite même l’accès massif et fournit des adresses stables pour les messages.

En juillet, l’Executive Director a par ailleurs rejeté l’affirmation selon laquelle la direction vendrait les textes des listes à des entreprises d’IA. Il a rappelé que les archives sont publiées pour être utilisées conformément aux dispositions juridiques de l’IETF Trust, et que l’IETF ne vend ni ne monétise ces données.

Il n’y a donc aucun fondement pour raconter ici une vente secrète du corpus. L’expérience n’a pas découvert clandestinement des textes supposés fermés. Mais l’ouverture de l’entrée ne décide pas de la légitimité de toutes les sorties.

Quiconque peut télécharger un message public et lui appliquer un classificateur. La situation change lorsque l’institution se sert du résultat pour qualifier une personne, orienter l’attention d’un chair, nourrir la modération ou réduire la crédibilité d’une contribution. Dans ce cas, le score n’est plus une lecture privée : il devient un élément d’action dont les effets, les responsables et les voies de correction doivent être connus.

La déclaration sur les données personnelles inclut messages, en-têtes et certaines interactions, et quelques listes sont contrôlées. Le rapport ne prouve pas l’analyse d’une liste restreinte et ne précise pas les champs transmis. Il manque une cartographie publique du flux, pas une preuve de violation.

Un score sans version ne dit rien de stable

Le fournisseur commercial n’est pas nommé. Il est dès lors impossible d’évaluer honnêtement sa performance. Les échecs connus d’autres détecteurs ne sont pas une mesure de celui-ci ; inversement, la présence d’un produit payant n’est pas une garantie de validité.

La signification d’une sortie dépend du modèle et de sa version, de la base de calibration, de la langue, de la longueur du texte, du genre et du seuil choisi. Les listes de l’IETF contiennent des projets argumentés, des corrections d’une ligne, des citations en cascade, du code, des formules répétitives, des notifications automatiques et de l’anglais écrit par des locuteurs de nombreuses langues. Une évaluation construite sur des dissertations ne décrit pas nécessairement cet ensemble.

Un nombre reproductible n’est donc pas encore une preuve. Il faut pouvoir relier le résultat à l’entrée, au service, à la version, au paramétrage et à une interprétation décidée à l’avance. Même muni de cette chaîne, un score probabiliste ne saurait, à lui seul, établir qu’une personne a utilisé un LLM.

L’administration ne peut déléguer une compétence au logiciel

RFC 8711 trace le partage des rôles. L’IETF Administration LLC assure le soutien budgétaire et administratif du processus de normalisation. Elle n’a pas autorité sur l’élaboration des standards. L’Executive Director dirige les opérations quotidiennes ; le Board fixe la stratégie et exerce sa surveillance.

Cette architecture autorise naturellement l’exploration d’outils administratifs. Elle interdit implicitement qu’un achat logiciel élargisse, à lui seul, la compétence de son utilisateur. Une analyse agrégée et sans conséquence individuelle peut rester dans un périmètre opérationnel. Un classement des contributions, une alerte de modération, une décision d’accès ou une appréciation de l’argument technique concernent d’autres rôles et d’autres garanties.

RFC 9945 fournit un point de comparaison. Il organise la modération communautaire, répartit les responsabilités et prévoit réexamen et appel. Rien n’indique que le détecteur ait été utilisé dans ce dispositif. Si cela devait arriver, la sortie expérimentale ne pourrait ni remplacer la procédure ni supprimer le jugement du responsable désigné.

Un Internet-Draft individuel sur les LLM ne comble pas davantage le vide. Il propose des devoirs de transparence aux participants ; il ne constitue pas une politique IETF adoptée. Surtout, une obligation de déclaration et une méthode institutionnelle d’inférence sont deux objets différents. Même si la première existait, elle ne donnerait pas automatiquement au détecteur une valeur de preuve.

Une fiche d’usage, pas une interdiction de chercher

La réponse proportionnée consiste à documenter la frontière avant d’étendre la circulation du résultat.

Une fiche versionnée devrait nommer le commanditaire, l’opérateur et le décideur responsable. Elle définirait la question testée, les catégories d’accès des listes, la période et la méthode d’échantillonnage. Elle énumérerait les champs transmis à chaque API, le service et sa version, ainsi que les clauses de conservation, de réutilisation ou de suppression.

La partie évaluation indiquerait les langues couvertes, les bases de comparaison, le protocole, les limites d’erreur observées et la définition exacte du score. Elle rappellerait explicitement qu’il ne prouve pas l’auteur d’un texte.

La partie usage listerait les personnes autorisées à voir le résultat et les analyses permises. Elle interdirait, sans décision publique distincte de l’autorité compétente, de transformer le score en déclencheur de modération, sanction, pondération de contribution, condition de participation ou étiquette de réputation. Un délai de conservation et un mécanisme de suppression seraient fixés.

Enfin, toute extension devrait avoir un propriétaire, une consultation requise, une date de révision et une clause d’arrêt. Si une personne identifiable pouvait être affectée, elle devrait être informée, accéder au résultat pertinent et demander sa correction ou son réexamen.

La meilleure défense est celle d’un essai secondaire rendu public sans conséquence individuelle démontrée. C’est donc maintenant que le cadre coûte le moins cher : sans lui, l’habitude peut faire politique à la place d’une décision.

Sources

  1. IETF Executive Director — Rapport public pour la réunion du Board du 1er septembre 2026
  2. IETF Administration LLC — Ordre du jour de la réunion 99, 1er septembre 2026
  3. IETF — Board de l’IETF Administration LLC
  4. RFC 8711 — Structure de l’activité de soutien administratif de l’IETF, version 2.0
  5. IETF — Déclaration concernant les données personnelles
  6. IETF — Listes de diffusion
  7. IETF — Archives ouvertes
  8. IETF Executive Director — Fausse affirmation selon laquelle la direction vendrait les textes des listes aux entreprises d’IA
  9. RFC 9945 — Modération de la communauté IETF
  10. Internet-Draft — Dealing with LLMs in IETF Discussions, révision 01
  11. Lu Heng — The Policy Mirror
  12. Lu Heng — On When the Bookkeeper Auditions for Olympus