← Actualités

Actualités · 35

Après vingt ans de oui/non, le robots.txt apprend à nuancer

Dans un nouveau brouillon, l'IETF (Internet Engineering Task Force) propose aux sites un vocabulaire commun pour dire ce que les IA peuvent faire de leurs pages : s'entraîner, répondre, renvoyer vers la source. Le texte date de septembre 2026, reste sans consensus et ne force aucun crawler à obéir, mais il oblige les éditeurs à écrire précisément ce qu'ils acceptent.

Pendant vingt ans, un site n'a eu que deux mots à dire aux robots : oui ou non. Le fichier robots.txt, normalisé par le RFC 9309, règle qui a le droit de lire quoi, et s'arrête là. Ce qu'on fait du contenu ensuite lui échappe. L'IETF publie un brouillon pour combler ce trou : le draft-ietf-aipref-vocab-08, « A Vocabulary For Expressing AI Usage Preferences », daté du 14 septembre 2026. Huit révisions déjà, et toujours pas de consensus.

Le sujet n'arrive pas par hasard. Cloudflare a lancé en juillet 2026 sa « Content Signals Policy », quelques signaux ajoutés à robots.txt et présentés comme une réservation de droits, c'est-à-dire une déclaration explicite que le site garde la main sur certains usages. L'IETF reprend l'idée sans le format, et cherche à en faire un standard ouvert à tous les crawlers.

Trois catégories au lieu d'un verrou

Le vocabulaire tient aujourd'hui en trois mots-clés :

  • train-ai : modifier les paramètres d'un modèle génératif avec le contenu.
  • ai-use : fournir le contenu en entrée d'un modèle, sans que l'utilisateur l'ait apporté lui-même.
  • search : proposer le contenu pour renvoyer l'utilisateur vers sa source, avec lien et extrait.

Chaque catégorie accepte y (autorisé), n (interdit) ou rien du tout, ce qui laisse l'usage non précisé. Un site peut ainsi refuser l'entraînement, accepter la recherche et ne rien dire du reste.

Attention à la catégorie search, plus large qu'elle n'en a l'air : l'autoriser couvre aussi l'entraînement et l'usage interne des modèles de l'application, tant que les sorties servent seulement à renvoyer vers la source. Un « oui » à la recherche n'est pas un petit oui.

Une préférence reste une préférence

Le document est net : la spécification ne garantit pas que les préférences soient suivies. Les mécanismes « techniques, légaux, contractuels » qui créeraient une obligation plus forte sont hors de son champ. Un crawler qui ignore la déclaration ne viole rien ; il passe son chemin.

Un robots.txt n'a jamais arrêté un robot mal élevé, et un « train-ai=n » n'y changera rien du jour au lendemain. Ce qui change, c'est la traçabilité : la volonté d'un site devient une phrase qu'une machine comprend et qu'un avocat peut citer dans un contrat ou un litige. Aucun éditeur ni juriste n'a encore commenté publiquement ce point, et c'est bien là que se jouera la valeur du texte.

Après vingt ans de oui/non, le robots.txt apprend à nuancer — illustration 2

Où ça s'écrit : Content-Usage

Le vocabulaire seul ne s'applique à rien. Un second brouillon, draft-ietf-aipref-attach-05, « Associating AI Usage Preferences with Content in HTTP », daté du 19 août 2026, prévoit une règle Content-Usage dans les groupes de robots.txt, et un en-tête HTTP du même nom. Il met à jour le RFC 9309 pour cela. Concrètement, deux lignes suffisent pour refuser l'entraînement à tous les robots :

User-Agent: * — Content-Usage: train-ai=n

Le premier champ désigne les robots concernés, le second leur interdit d'entraîner un modèle avec les pages du site. La recherche et le reste ne sont pas mentionnés : ils restent non précisés.

Bloquer « les IA » ne veut rien dire

Chaque grande plateforme fait tourner plusieurs agents, sous des noms et des règles distincts. L'ingénieur Peter Martin, dans une enquête du 8 septembre 2026, le montre pour Anthropic, qui l'indique lui-même : bloquer ClaudeBot ne bloque ni Claude-SearchBot ni Claude-User. Chez OpenAI, même logique, avec un quatrième agent, OAI-AdsBot. Dire « on a bloqué les robots IA » ne décrit donc rien de précis.

Après vingt ans de oui/non, le robots.txt apprend à nuancer — illustration 3

Même enquête, autre enseignement, très concret : un crawl est une seule requête HTTP, qui s'arrête là où commence le JavaScript. Si les horaires, les prix ou les disponibilités d'un site s'affichent après le chargement, ces robots ne les voient pas, quelles que soient les préférences déclarées. Pour un commerce local, cela pèse autant que n'importe quelle ligne de robots.txt.

Et maintenant ?

Trois inconnues demeurent. L'adoption d'abord : il s'agit d'un Internet-Draft, pas d'un RFC, sans consensus, et aucune statistique publique d'usage n'existe. L'implémentation ensuite : elle peut traîner des mois, ou ne jamais venir si les grands acteurs préfèrent leurs signaux maison ou un cadre purement contractuel. Le poids juridique enfin : personne ne sait ce qu'un « n » vaut devant un juge, et le document renvoie les cas sérieux à des accords explicites.

Pour un éditeur, l'intérêt est ailleurs que dans une ligne à copier : écrire, usage par usage, ce qu'il accepte, et garder une trace datée de cette déclaration. Premier geste utile : ouvrir le robots.txt que son site sert réellement, et vérifier ce qu'il dit, ou s'il existe.

Partager