aipref : le chantier IETF encore bloqué à deux catégories

Tapez « aipref IETF » en français et vous ne trouverez rien. Zéro article, zéro guide. La niche a pourtant un nom et un dossier : c'est un chantier de l'IETF, l'organisme qui a écrit le standard robots.txt lui-même, en train de redéfinir comment un site déclare ce qu'une IA a le droit de faire de son contenu. Sauf que ce chantier n'a rien d'un standard fini. J'ai lu les deux textes source plutôt que les résumés qui en parlent, et l'écart entre les deux est le sujet de cet article.

En clair : aipref est un travail en cours à l'IETF, pas un standard publié. Au 3 septembre 2026, deux Internet-Drafts existent (vocab-07, attach-05), zéro RFC. Le vocabulaire ne définit que deux catégories d'usage, train-ai et search, encodées via un en-tête HTTP Content-Usage ou une règle du même nom dans robots.txt. La section qui les définit porte elle-même la mention « pas de consensus ».

Le problème que l'IETF a mis sur la table est concret. Officiellement, le motif tient en une phrase du billet fondateur du groupe de travail : « les vendeurs d'IA utilisent un ensemble confus de signaux non standard dans robots.txt et ailleurs pour guider leurs décisions de crawl et d'entraînement ». Chaque plateforme a inventé son propre jeton, sa propre syntaxe, sa propre logique. Résultat : un éditeur qui veut autoriser l'entraînement mais refuser le grounding se retrouve à jongler avec des directives incompatibles selon le bot en face.

La réalité du terrain, je l'ai vue en épluchant des robots.txt publics ces derniers mois : des blocs entiers de Disallow empilés user-agent par user-agent, sans logique d'usage derrière, juste une liste de bots recopiée d'un guide à l'autre. C'est exactement le symptôme que l'IETF dit vouloir traiter. Le groupe de travail aipref a été chartré le 7 janvier 2025, avec Mark Nottingham et Suresh Krishnan comme présidents, sous l'autorité de zone Web and Internet Transport.

Voici l'histoire du vocabulaire, version par version. Personne ne la raconte en français, et elle explique à elle seule pourquoi le sujet reste flou.

Quatre catégories à la version 03, deux à la version 05, et ça n'a plus bougé depuis. bots (traitement automatisé générique) et ai-output sont passés à la trappe entre v04 et v05. train-genai a disparu dès la v04, remplacé par ai-output avant de disparaître à son tour. Le libellé de la catégorie d'entraînement, lui, a changé deux fois : « AI Training », puis « Foundation Model Production », puis « AI Model Training ». Si vous avez lu un article qui parle encore de quatre catégories dont train-genai, il décrit un état périmé depuis la version 04, c'est-à-dire depuis fin octobre 2025.

Le point qui mérite d'être dit sans détour : le vocabulaire courant ne couvre que deux usages.

train-ai (AI Model Training) désigne l'utilisation d'un contenu pour modifier les paramètres appris d'un modèle qui génère du contenu synthétique. search désigne une application dont la finalité première est de sélectionner des ressources et de diriger l'utilisateur vers elles, avec une exclusion explicite : la génération de résumés n'entre pas dans cette catégorie.

Ce que ça laisse dehors, c'est l'usage après entraînement : le RAG, le grounding, l'inférence à la volée qu'un modèle fait sur votre page au moment de répondre à une requête. L'omission n'a rien d'un oubli de rédaction : elle traduit un désaccord ouvert. Selon les minutes de la réunion IETF 126 du 24 juillet 2026, le périmètre de cet usage reste en débat, et aucun WG Last Call n'était annoncé à cette date. On croise régulièrement l'idée que aipref distinguerait déjà trois usages, entraînement, recherche et un troisième pour l'après-entraînement. C'est faux à la date de cet article, et la nuance vaut la peine d'être posée noir sur blanc : c'est précisément l'absence de cette troisième catégorie qui bloque le groupe.

Chaque préférence prend l'une de trois valeurs : allowed, disallowed, unknown, avec unknown par défaut en l'absence de déclaration. Dans le protocole, elles s'encodent en un seul caractère, y pour allow et n pour disallow. L'exemple donné par le draft lui-même : train-ai=y, search=n.

Le second draft, attach-05, définit comment attacher ces préférences à un contenu accessible en HTTP. Deux canaux, et seulement deux : un en-tête de réponse Content-Usage, et une règle Content-Usage ajoutée à robots.txt. Ce draft met à jour le RFC 9309, le standard qui régit robots.txt depuis 2022, sans le remplacer.

En en-tête HTTP, ça donne :

Content-Usage: train-ai=n

Dans robots.txt, la règle peut cibler un chemin précis, ce que le header seul ne permet pas :

Content-Usage: train-ai=n
Content-Usage: /ai-ok/ train-ai=y

Deux autres canaux sont évoqués dans le texte du draft, des métadonnées embarquées directement dans le fichier et un registre externe, mais aucun des deux n'est spécifié. Ils sont cités comme pistes, pas comme mécanismes disponibles. Ne construisez rien dessus aujourd'hui, il n'y a rien à construire.

Voici le point que je trouve le plus révélateur, et que le SERP anglophone lui-même sous-représente. Le calendrier du groupe prévoyait de soumettre les deux drafts à l'IESG au 31 août 2026. Au 3 septembre 2026, cette échéance n'est pas tenue : les deux documents restent à l'état I-D Exists, aucun n'a franchi l'étape suivante. Ce n'est pas le premier report. L'échéance initiale, fixée dans la charte approuvée en janvier 2025, était le 31 août 2025 ; elle avait déjà été repoussée d'un an par le directeur de zone en septembre 2025.

Il y a mieux : un appel à consensus (WG Last Call) avait été ouvert sur les deux textes le 4 septembre 2025. Il a été annulé, les documents renvoyés au statut « WG Document », le 3 novembre 2025. Aucun nouvel appel n'a été rouvert depuis. Le draft de vocabulaire porte lui-même, en toutes lettres, un avertissement à ses lecteurs : il ne reflète pas le consensus du groupe de travail, ni en tout ni en partie. Et la section qui définit les catégories, celle qui concentre tout l'enjeu, porte sa propre note distincte disant la même chose. Un texte qui s'auto-désavoue à ce point ne s'adopte pas. Il se suit, comme une base de discussion.

Soyons honnêtes sur ce que vous pouvez faire avec ça maintenant, par opposition à ce qui reste un projet.

Techniquement, rien ne vous empêche de poser dès aujourd'hui un en-tête Content-Usage ou une règle du même nom dans votre robots.txt : la syntaxe est publique, documentée, stable depuis plusieurs versions. Le problème est ailleurs. À la date du 3 septembre 2026, aucun opérateur de crawler majeur, Google, OpenAI, Anthropic, Meta ou Perplexity, ne déclare publiquement respecter cet en-tête ou cette règle en production. Ce n'est pas une preuve que personne ne le fait en coulisses : c'est l'état exact des déclarations publiques à cette date, et c'est la seule chose que je peux affirmer avec certitude.

Ce que les opérateurs font réellement aujourd'hui, ce sont leurs propres grammaires, incompatibles entre elles. Google-Extended couvre d'un seul geste l'entraînement des futurs modèles Gemini et le grounding, sans les distinguer, et n'a aucun effet sur le classement dans Google Search. OpenAI sépare la granularité par bot plutôt que par catégorie déclarée : GPTBot pour l'entraînement, OAI-SearchBot pour la recherche, chacun identifiable à sa propre documentation officielle plutôt qu'à une déclaration d'usage. Cloudflare, de son côté, a publié sa propre grammaire le 24 septembre 2025, Content-Signal, avec trois signaux (search, ai-input, ai-train), distincte de celle de l'IETF, et diffusée par son robots.txt managé, que plus de 3,8 millions de domaines avaient activé à cette date selon Cloudflare. Cloudflare dit explicitement attendre l'aboutissement de la proposition IETF pour aligner son propre mécanisme dessus. C'est le signe le plus net que même les gros acteurs du web considèrent que ce n'est pas encore arrivé à maturité.

Deux autres initiatives circulent dans le même espace, à ne pas confondre : llms.txt, une proposition individuelle de Jeremy Howard, informelle, qui n'a jamais porté sur le contrôle d'usage mais sur le fait d'aider un agent à comprendre un site ; et RSL (Really Simple Licensing), lancée le 10 septembre 2025 par un collectif d'éditeurs, qui ajoute des termes de licence lisibles par machine là où robots.txt ne connaît que l'autorisation ou l'interdiction, dans le même esprit de réservation de droits que le mécanisme TDMRep de réservation de fouille de textes et de données. Aucune des deux n'est un travail de l'IETF.

Sur le fond, j'hésite encore à trancher si un éditeur a intérêt à poser Content-Usage dès maintenant, en pari sur l'adoption future, ou à attendre qu'un opérateur déclare réellement le lire. L'argument du pari, c'est que la syntaxe ne coûte rien à écrire. L'argument de l'attente, c'est qu'aucune plateforme majeure ne s'engage encore dessus, et que le texte qui la définit annonce lui-même qu'il peut changer. Les deux se défendent, et je ne vois pas d'argument décisif pour trancher entre les deux à cette date.

aipref est-il un standard officiel de l'IETF ?#

Non, pas au 3 septembre 2026. Ce sont deux Internet-Drafts de groupe de travail, draft-ietf-aipref-vocab-07 et draft-ietf-aipref-attach-05, aucun RFC publié. Le draft de vocabulaire porte lui-même la mention qu'il ne reflète pas le consensus du groupe.

Combien de catégories d'usage aipref définit-il ?#

Deux, dans la version 07 : train-ai (entraînement de modèle IA) et search (recherche, qui exclut explicitement la génération de résumés). Une troisième catégorie, l'usage après entraînement comme le RAG ou le grounding, reste en débat selon les minutes de la réunion IETF 126 de juillet 2026 et n'a pas de définition dans le vocabulaire actuel.

Comment déclarer une préférence avec Content-Usage ?#

Deux canaux sont définis : un en-tête HTTP (Content-Usage: train-ai=n) ou une règle robots.txt du même nom, qui peut cibler un chemin précis (Content-Usage: /ai-ok/ train-ai=y). Les valeurs possibles sont allowed, disallowed et unknown, ce dernier s'appliquant par défaut en l'absence de déclaration.

Les crawlers IA respectent-ils déjà Content-Usage ?#

À la date du 3 septembre 2026, aucun opérateur de crawler majeur ne déclare publiquement respecter cet en-tête ou cette règle en production. C'est l'état des déclarations publiques connues à cette date, ni une preuve que personne ne le fait, ni une confirmation que quelqu'un le fait.

aipref remplace-t-il robots.txt ?#

Non. Le draft d'attachement met à jour le RFC 9309, le standard qui régit robots.txt depuis 2022, il ne le remplace pas. Le RFC 9309 continue de régir l'accès des crawlers ; aipref y ajoute une couche de préférence d'usage, sur un mécanisme distinct.

Pourquoi le calendrier de aipref a-t-il déjà pris deux ans de retard ?#

L'échéance initiale de la charte, fixée en janvier 2025, était le 31 août 2025. Elle a été repoussée une première fois au 31 août 2026 par le directeur de zone en septembre 2025, puis un appel à consensus ouvert en septembre 2025 a été annulé en novembre 2025 sans qu'un nouveau soit rouvert depuis. Au 3 septembre 2026, la seconde échéance est également dépassée.

• Groupe de travail aipref, page About, consulté le 3 septembre 2026
• Historique du groupe aipref, consulté le 3 septembre 2026
• draft-ietf-aipref-vocab-07, texte intégral, consulté le 3 septembre 2026
• draft-ietf-aipref-attach-05, texte intégral, consulté le 3 septembre 2026
• Minutes de la réunion IETF 126, session aipref, consulté le 3 septembre 2026
• RFC 9309, Robots Exclusion Protocol, consulté le 3 septembre 2026
• IETF, billet officiel sur le groupe aipref, consulté le 3 septembre 2026
• Google Search Central, crawlers communs, consulté le 3 septembre 2026
• OpenAI, documentation des bots, consulté le 3 septembre 2026
• Cloudflare, Content Signals Policy, consulté le 3 septembre 2026
• Cloudflare, robots.txt managé et attente de l'IETF, consulté le 3 septembre 2026
• llms.txt, la spécification, consulté le 3 septembre 2026
• RSL Collective, lancement du standard RSL, consulté le 3 septembre 2026