robots.txt : Google, Microsoft, OpenAI et Anthropic s'accordent sur un jeton commun pour refuser l'entraînement des IA

Le 30 octobre 2026, Google, Microsoft, OpenAI et Anthropic ont publié le même jour quatre annonces qui vont dans le même sens : chacun s'engage à respecter un signal unique dans le fichier robots.txt pour exprimer un refus, ou une autorisation, d'entraînement des modèles d'IA générative. Jusqu'ici, un administrateur de site devait écrire une règle par robot : GPTBot pour OpenAI, Google-Extended pour Gemini, ClaudeBot pour Anthropic, et des balises meta pour Microsoft. Le nouveau mécanisme, décrit dans le brouillon IETF draft-kelley-aipref-training-preference-signal, tient en un groupe User-Agent: __usage_ai-training suivi de lignes Disallow et Allow par chemin. Avant de l'ajouter au robots.txt de votre site internet, qu'il soit servi par Nginx ou Apache sur un VPS Linux, par un hébergement web mutualisé ou par un CMS comme WordPress, deux précisions : ce jeton n'empêche aucun robot d'explorer vos pages web, et aucun des quatre éditeurs ne l'applique encore pleinement. Les règles par robot restent donc nécessaires, au moins jusqu'en 2027.

Sources : Google Search Central Blog, 30 octobre 2026, brouillon IETF draft-kelley-aipref-training-preference-signal-00, Bing Blogs, 30 octobre 2026, OpenAI, 30 octobre 2026, centre d'aide Anthropic, documentation des robots Google, documentation des robots OpenAI, référence WordPress du filtre robots_txt.

Ce que les quatre éditeurs ont annoncé le 30 octobre

Les quatre textes partent du même constat : depuis 2023, chaque éditeur d'IA a inventé son propre jeton robots.txt pour l'entraînement, et un propriétaire de site qui veut refuser l'entraînement doit maintenir une liste de robots qui s'allonge à chaque nouvel acteur. Le groupe de travail AIPREF de l'IETF (Internet Engineering Task Force) planche depuis plusieurs mois sur un vocabulaire commun de préférences d'usage. Le brouillon publié le 30 octobre par Kevin Kelley, ingénieur chez Anthropic, en tire un mécanisme minimal : un jeton de politique (« policy token ») placé là où l'on met d'habitude le nom d'un robot.

Un point de vocabulaire compte pour la suite : il s'agit d'un Internet-Draft individuel, version -00, qui expire le 3 mai 2027 s'il n'est pas renouvelé. Le datatracker de l'IETF précise qu'il n'est ni approuvé ni doté d'un statut formel. Google l'écrit aussi : un futur standard aura besoin du soutien des grands fournisseurs, et c'est exactement ce que ces quatre annonces simultanées cherchent à créer. Pour un administrateur, la conséquence pratique est simple : la syntaxe peut encore bouger, mais quatre acteurs se sont engagés publiquement sur le jeton tel qu'il est écrit aujourd'hui.

La syntaxe exacte du jeton __usage_ai-training

Le brouillon n'introduit aucune nouvelle directive et aucune nouvelle grammaire. Tout repose sur la RFC 9309, qui normalise le fichier robots.txt : les lignes User-Agent, Allow et Disallow gardent leur sens habituel. La seule nouveauté est le jeton __usage_ai-training, construit comme un nom de produit (lettres, tirets et soulignés), que l'on place sur une ligne User-Agent. La comparaison est insensible à la casse, comme pour n'importe quel nom de robot. L'exemple de référence du document, adapté à un site français, ressemble à ceci :

User-Agent: __usage_ai-training
Disallow: /
Allow: /presse/

Ce bloc exprime une préférence contre l'entraînement pour tout le site, et une préférence en faveur de l'entraînement pour tout ce qui se trouve sous /presse/. La résolution suit la logique de la RFC 9309 : pour un chemin donné, la règle la plus longue (la plus spécifique) l'emporte. Le document définit l'entraînement comme le fait d'utiliser un contenu pour modifier les paramètres appris d'un modèle d'IA générative, ni plus ni moins.

Cinq règles de lecture, toutes tirées du brouillon, évitent les mauvaises surprises :

• Le joker ne s'applique pas au jeton. Un groupe User-Agent: * ne doit jamais être interprété comme couvrant __usage_ai-training. Un site qui bloque tout avec * n'a donc exprimé aucune préférence d'entraînement.
• Pas de groupe, pas de préférence. Si le fichier ne contient aucun groupe pour le jeton, le document considère qu'aucune préférence n'a été exprimée. Microsoft en tire une lecture explicite : l'autorisation est le comportement par défaut, aucune ligne n'est nécessaire pour autoriser l'entraînement.
• Le spécifique l'emporte sur le général. Une règle qui nomme un robot précis (ClaudeBot, Google-Extended) prime sur la préférence commune. C'est ce qui permet d'autoriser un éditeur et de refuser les autres.
• Plusieurs jetons par groupe sont permis. Un groupe peut nommer plusieurs jetons de politique, et mélanger jetons de politique et noms de robots, même si rien n'y oblige.
• Un accord privé peut primer. Le brouillon précise qu'un contrat entre un éditeur de contenu et un fournisseur d'IA peut remplacer la préférence exprimée dans le fichier.

Pour refuser l'entraînement sur une partie du site seulement, par exemple un blog et une documentation, sans toucher au reste, on inverse la logique :

User-Agent: __usage_ai-training
Disallow: /blog/
Disallow: /docs/

Ce que le jeton ne fait pas : il ne bloque pas le crawl

C'est la phrase la plus importante du brouillon, et elle est sans ambiguïté : ce jeton de politique n'est pas une directive de comportement d'exploration. Un robot qui lit Disallow: / sous __usage_ai-training peut continuer à télécharger chaque page du site. Le document admet qu'un consommateur peut s'abstenir de récupérer une ressource dont il sait qu'il ne pourra pas l'utiliser, mais rien ne l'y oblige. Pour limiter réellement le passage d'un crawler, il faut toujours un groupe qui nomme son user-agent, ou des mesures côté serveur (limitation de débit, pare-feu).

Il faut aussi distinguer trois usages que les éditeurs séparent soigneusement : l'entraînement (modifier les paramètres d'un modèle), la recherche (indexer vos pages pour les afficher dans des résultats) et l'ancrage, ou « grounding » (fournir le contenu d'une page à un modèle au moment où il répond). Le jeton commun ne couvre que le premier. Les conséquences concrètes :

• Google rappelle dans sa documentation que Google-Extended n'a aucun effet sur l'inclusion d'un site dans la recherche Google ni sur son classement. Le jeton commun, traité comme un Google-Extended refusé, hérite de cette limite : il porte sur l'entraînement et l'ancrage des modèles Gemini, pas sur Googlebot.
• Microsoft écrit que ces préférences d'usage ne changent pas l'éligibilité aux résultats de recherche Bing classiques. L'ancrage fait l'objet d'une préférence distincte (ai-grounding), réglable uniquement page par page, jamais dans robots.txt.
• OpenAI maintient deux robots séparés : GPTBot pour l'entraînement, OAI-SearchBot pour la recherche dans ChatGPT. Chaque réglage est indépendant. Refuser l'entraînement ne vous retire pas des résultats de recherche de ChatGPT.
• Anthropic fait la même séparation entre ClaudeBot (entraînement), Claude-SearchBot (recherche) et Claude-User (requêtes lancées par un utilisateur).

Autrement dit, ajouter le jeton ne fera baisser ni votre trafic de recherche ni la charge de votre serveur. Si votre problème est un robot d'IA qui sature un petit VPS, la réponse est ailleurs : règles par robot, Crawl-delay là où il est respecté (Anthropic indique le prendre en charge), et limitation de débit dans Nginx ou dans le pare-feu.

D'ici 2027, gardez vos règles par robot

Aucun des quatre éditeurs ne retire ses contrôles existants, et trois d'entre eux ne lisent pas encore le jeton : Google vise le début de 2027, Microsoft commence le 1er février 2027, OpenAI parle des « prochains mois ». Seul Anthropic indique le reconnaître depuis le 30 octobre, avec un déploiement progressif. Un fichier robots.txt qui ne contiendrait que le jeton commun n'exprimerait donc, aujourd'hui, un refus effectif qu'auprès d'un seul acteur. Le tableau suivant récapitule les user-agents à connaître.

Le fichier recommandé pendant la transition combine donc le jeton commun et les règles par robot. Il reste lisible, et chaque éditeur y trouve la ligne qu'il sait lire aujourd'hui :

# Préférence commune d'entraînement (lue par Anthropic dès maintenant,
# par Microsoft à partir de février 2027, par Google et OpenAI ensuite)
User-Agent: __usage_ai-training
Disallow: /

# Règles par robot, nécessaires tant que le jeton n'est pas appliqué partout
User-Agent: GPTBot
Disallow: /

User-Agent: Google-Extended
Disallow: /

User-Agent: ClaudeBot
Disallow: /

# Les robots de recherche classiques restent libres
User-Agent: *
Allow: /

Deux nuances. Si vous souhaitez autoriser un éditeur en particulier, nommez-le avec Allow: / : la règle spécifique prime sur le jeton général, et Google confirme qu'une mention explicite de Google-Extended l'emporte sur la préférence commune. Et pour les sites qui servent du contenu depuis plusieurs hôtes, pensez que la RFC 9309 et Google s'accordent sur ce point : un fichier robots.txt ne vaut que pour le protocole, l'hôte et le port où il est publié. Un sous-domaine docs.example.fr ou un site encore servi en HTTP a besoin de son propre fichier.

Avant de modifier robots.txt : ce qu'il faut savoir de votre hébergement

Le jeton se dépose dans un simple fichier texte, mais le bon endroit dépend de la façon dont votre site internet est servi. Quatre points à vérifier avant d'ouvrir une connexion SSH ou FTP :

• L'URL exacte du fichier. Le fichier répond à l'adresse formée du nom de domaine suivi de /robots.txt, au même niveau que la page d'accueil. Chaque hôte a le sien : example.fr, www.example.fr et docs.example.fr sont trois hôtes distincts, même si leurs enregistrements DNS pointent vers la même adresse IP. Si vous redirigez le domaine nu vers www, c'est le fichier de l'hôte final qui compte.
• Qui répond vraiment. Si un CDN, un pare-feu applicatif ou un reverse proxy est placé devant votre serveur web, c'est lui que les robots interrogent. Un curl -sI https://example.fr/robots.txt lancé depuis l'extérieur montre l'en-tête Server et le code HTTP réellement renvoyés.
• Votre accès au serveur. Sur un VPS ou un serveur dédié, une connexion SSH avec un compte admin et sudo suffit pour déposer le fichier et recharger la configuration. Chez un hébergeur mutualisé, le fichier se téléverse en SFTP ou FTP, ou depuis le gestionnaire de fichiers du panneau (httpdocs sous Plesk). Sur un CMS, l'interface d'administration ou une extension SEO fait souvent le travail.
• Le fichier de configuration à toucher, s'il y en a un. Un fichier physique à la racine est servi tel quel par Nginx comme par Apache, sans modifier les fichiers de configuration. On n'ouvre /etc/nginx/sites-available/example.fr ou /etc/apache2/sites-available/example.fr.conf que pour un cas particulier : reverse proxy, fichier partagé entre plusieurs sites, journaux à couper. Après une telle modification, un reload suffit, un restart n'est pas nécessaire.

Ajouter le fichier sur un VPS : Nginx, Apache, WordPress

Le fichier doit s'appeler exactement robots.txt, être encodé en UTF-8 et se trouver à la racine de l'hôte, donc répondre à https://example.fr/robots.txt. Un site n'en a qu'un seul. La mise en place dépend de ce qui sert vos pages.

Nginx

Sur un VPS où Nginx sert directement un site statique ou une application PHP, il suffit de déposer le fichier dans le répertoire déclaré par la directive root du bloc server. Un bloc location à correspondance exacte, recommandé par la documentation WordPress pour Nginx, évite de polluer les journaux et garantit que la requête ne part pas dans une réécriture :

sudo nano /var/www/example.fr/public/robots.txt
# coller le contenu, enregistrer, puis dans le bloc server :

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

sudo nginx -t && sudo systemctl reload nginx

Si Nginx fait office de reverse proxy devant une application (Node.js, conteneur Docker, panneau de serveur de jeu), servez le fichier depuis Nginx plutôt que de le confier à l'application, en ajoutant un root dans la même location :

location = /robots.txt {
    root /var/www/example.fr;
    access_log off;
}

Nginx cherchera alors /var/www/example.fr/robots.txt et renverra ce fichier sans passer par proxy_pass.

Apache

Avec Apache, un fichier physique à la racine du DocumentRoot (par défaut /var/www/html sur Debian et Ubuntu) suffit. Si le site tourne sous WordPress, le bloc standard du fichier .htaccess contient les conditions RewriteCond %{REQUEST_FILENAME} !-f et !-d : la réécriture vers index.php ne s'applique qu'aux requêtes qui ne correspondent à aucun fichier ni répertoire existant. Un robots.txt réel est donc servi tel quel par Apache, avant que WordPress ne voie la requête. Sur un hébergement web Plesk, le même fichier se dépose à la racine du domaine, dans httpdocs, depuis le gestionnaire de fichiers.

Un seul fichier pour plusieurs sites : alias Nginx et Alias Apache

Un VPS héberge souvent plusieurs sites internet qui partagent la même politique d'entraînement. Plutôt que de copier le fichier dans chaque racine, servez un fichier commun depuis chaque hôte virtuel. Avec Nginx, la directive alias placée dans une location exacte remplace l'URI demandée par le chemin complet du fichier :

location = /robots.txt {
    alias /var/www/commun/robots.txt;
    access_log off;
}

Avec Apache, la directive Alias du module mod_alias fait la même chose. Comme le fichier se trouve hors du DocumentRoot, la documentation Apache rappelle qu'il faut autoriser explicitement l'accès au répertoire de destination :

Alias "/robots.txt" "/var/www/commun/robots.txt"
<Directory "/var/www/commun">
    Require all granted
</Directory>

sudo apache2ctl configtest && sudo systemctl reload apache2

Dans les deux cas, le fichier doit rester lisible par l'utilisateur Unix du serveur web (www-data sous Debian et Ubuntu) : des droits 644 suffisent. Le jour où un site doit se distinguer des autres, par exemple pour autoriser l'entraînement sur une documentation publique, retirez la ligne d'alias de son hôte virtuel et donnez-lui son propre fichier.

WordPress sans fichier physique

Quand aucun fichier n'existe, WordPress génère un robots.txt virtuel via la fonction do_robots(), et le filtre robots_txt permet d'y ajouter des lignes. Le filtre reçoit le contenu généré et un booléen indiquant si le site est public (le réglage « Visibilité pour les moteurs de recherche »). Un mu-plugin de quelques lignes suffit, et il survit aux changements de thème :

<?php
// wp-content/mu-plugins/preference-entrainement-ia.php
add_filter('robots_txt', function ($output, $public) {
    $output .= "\nUser-Agent: __usage_ai-training\nDisallow: /\n";
    $output .= "\nUser-Agent: GPTBot\nDisallow: /\n";
    $output .= "\nUser-Agent: Google-Extended\nDisallow: /\n";
    $output .= "\nUser-Agent: ClaudeBot\nDisallow: /\n";
    return $output;
}, 10, 2);

Les extensions SEO courantes proposent aussi un éditeur de robots.txt ; vérifiez simplement qu'elles n'écrasent pas un fichier physique que vous auriez déposé par ailleurs. Et puisqu'on touche à un site WordPress exposé, c'est l'occasion de contrôler que le cœur est à jour, comme le rappelait la mise à jour de sécurité WordPress 7.1.4.

Vérifier que le fichier est bien servi

Un robots.txt mal servi fait pire que pas de robots.txt. Google traite une réponse 4xx (sauf 429) comme l'absence de fichier, donc comme l'absence de toute restriction. Une réponse 5xx est plus coûteuse : Google cesse d'explorer le site pendant les douze premières heures en attendant de récupérer le fichier. Testez donc depuis l'extérieur, avec le protocole et l'hôte exacts que voient les robots :

curl -sI https://example.fr/robots.txt
curl -s https://example.fr/robots.txt | grep -i -A 2 'usage_ai-training'

La première commande doit renvoyer 200 et un Content-Type en text/plain. La seconde affiche votre groupe. Google met en cache le fichier jusqu'à 24 heures en général, et Bing Webmaster Tools offre un contrôle équivalent au rapport de la Search Console décrit plus bas. Si votre site est encore joignable en HTTP, redirigez-le en HTTPS une bonne fois, en suivant notre guide Certbot et Let's Encrypt sur VPS Linux : un seul hôte canonique, un seul robots.txt à maintenir.

Tester les règles avec un script Python

Pour connaître le verdict que votre fichier donne à un jeton et à un chemin précis, sans attendre le passage des robots, un script Python de quelques lignes suffit : le module urllib.robotparser de la bibliothèque standard lit le fichier à son URL et répond True ou False. Dans Python 3.13, il retient la règle la plus spécifique et fait gagner Allow à égalité, comme la RFC 9309.

#!/usr/bin/env python3
# test-robots.py : à lancer depuis n'importe quelle machine, pas forcément le serveur
import urllib.robotparser

rp = urllib.robotparser.RobotFileParser()
rp.set_url("https://example.fr/robots.txt")
rp.read()

for agent in ("__usage_ai-training", "GPTBot", "Google-Extended", "ClaudeBot", "Googlebot"):
    for path in ("https://example.fr/", "https://example.fr/presse/dossier.html"):
        print(f"{agent:22} {path:45} {rp.can_fetch(agent, path)}")

Lisez le résultat avec le bon vocabulaire : un False sous __usage_ai-training signifie « préférence contre l'entraînement » et non « exploration interdite », et le script ne dit rien de ce que fait réellement un robot, seulement ce que votre fichier lui demande. Il reste précieux pour repérer une faute de frappe dans le jeton ou un chemin mal orthographié avant la mise en ligne.

Côté Google, le rapport robots.txt de la Search Console n'existe que pour une propriété de type Domaine, validée par un enregistrement DNS. Elle couvre tous les sous-domaines et tous les protocoles, et le rapport liste les fichiers trouvés sur les vingt principaux hôtes du domaine, en HTTP comme en HTTPS, avec la dernière version récupérée, les versions des trente derniers jours et les erreurs d'analyse. C'est là que vous verrez si Google a bien lu votre nouveau groupe, et que vous pourrez demander une nouvelle exploration du fichier après une correction.

Enfin, pour constater par vous-même que le jeton ne bloque pas le crawl, surveillez les journaux d'accès quelques jours après la mise en ligne :

grep -E 'GPTBot|ClaudeBot|OAI-SearchBot' /var/log/nginx/access.log | tail -n 20

Les robots nommés dans un groupe Disallow: / doivent disparaître des journaux ; Google-Extended n'y apparaîtra jamais, puisqu'il n'a pas de user-agent propre et que l'exploration de Google passe par Googlebot.

Lexique : les termes à connaître avant de modifier robots.txt

Le sujet mélange le vocabulaire des moteurs de recherche et celui des modèles d'IA. Voici les définitions utilisées dans cet article, telles que les emploient la RFC 9309, le brouillon IETF et les documentations des quatre éditeurs :

• robots.txt : fichier texte UTF-8 placé à la racine d'un hôte web, normalisé par la RFC 9309 (Robots Exclusion Protocol). Il regroupe des règles Allow et Disallow par chemin, sous des lignes User-Agent. Il exprime des consignes aux robots, sans les faire respecter techniquement.
• User-Agent et jeton de produit : le nom par lequel un robot d'exploration (crawler) s'identifie, par exemple Googlebot, Bingbot, GPTBot ou ClaudeBot. Dans robots.txt, la ligne User-Agent désigne le robot auquel s'applique un groupe de règles.
• Jeton de politique (« policy token ») : un identifiant construit comme un jeton de produit mais qui ne désigne aucun robot. __usage_ai-training est le premier et, pour l'instant, le seul jeton de ce type défini par le brouillon IETF. Les règles qui le suivent décrivent un usage du contenu, pas un comportement d'exploration.
• Exploration (crawl) : le téléchargement des pages par un robot. C'est ce que règlent les groupes nommant un user-agent, le Crawl-delay là où il est accepté, et la limitation de débit côté serveur.
• Entraînement (AI training) : selon le vocabulaire du groupe AIPREF repris par le brouillon, l'utilisation d'un contenu pour modifier les paramètres appris d'un modèle d'IA générative. C'est le seul usage couvert par le jeton commun.
• Ancrage (grounding) : la fourniture du contenu d'une page à un modèle au moment où il formule une réponse, par exemple dans Gemini, Copilot ou la recherche ChatGPT. Google l'inclut dans le périmètre de Google-Extended, Microsoft le règle page par page avec ai-grounding, et le jeton commun ne le couvre pas.
• Google-Extended : jeton de contrôle Google, en place depuis 2023, sans user-agent HTTP propre. Il gère l'usage du contenu exploré par Googlebot pour l'entraînement et l'ancrage des modèles Gemini, sans effet sur la recherche Google.
• Internet-Draft : document de travail de l'IETF, valable six mois au plus. Un brouillon individuel comme draft-kelley-aipref-training-preference-signal-00 n'est ni approuvé ni doté d'un statut formel tant qu'il n'a pas franchi les étapes du groupe de travail.
• Hôte, nom de domaine et sous-domaine : un robots.txt vaut pour un hôte, c'est-à-dire la combinaison d'un protocole, d'un nom de domaine et d'un port. Chaque sous-domaine a le sien, quelle que soit l'adresse IP vers laquelle pointent les enregistrements DNS, et la version HTTP d'un site est un hôte distinct de sa version HTTPS.
• Serveur web : le logiciel qui répond aux requêtes HTTP, Nginx ou Apache sur la plupart des VPS, ou le reverse proxy placé devant une application. C'est lui qui sert robots.txt comme n'importe quel fichier statique ; le CMS n'intervient que lorsqu'aucun fichier physique n'existe.
• Exploration, indexation et référencement : robots.txt gère le trafic des robots d'exploration. Google précise qu'il n'est pas un mécanisme pour tenir une page web hors de ses résultats de recherche : pour désindexer une page, utilisez la balise meta noindex ou une protection par mot de passe. Le jeton commun, lui, n'a aucun effet sur le référencement : Google et Microsoft écrivent qu'il ne touche ni l'inclusion dans les résultats de recherche ni le classement.

Ce que ça change pour qui héberge des sites

Pour un administrateur qui gère plusieurs sites sur un VPS Linux ou un serveur dédié, l'intérêt est réel mais différé : à terme, un bloc de deux lignes remplacera une liste de robots à tenir à jour à chaque nouvel entrant. D'ici là, la bonne pratique est d'ajouter le jeton dès maintenant, de garder les règles par robot, et de noter deux échéances : le 1er février 2027 pour Microsoft et, courant 2027, l'activation chez Google. Le signal n'a par ailleurs aucune valeur contraignante en soi ; c'est une déclaration de préférence que les quatre éditeurs s'engagent à honorer, et le brouillon lui-même prévoit qu'un accord privé peut la remplacer. Que vous soyez votre propre hébergeur sur un VPS ou que vous confiiez vos pages web à un hébergement infogéré, la marche à suivre ne change pas : un fichier par nom de domaine, des règles par robot d'ici 2027, le jeton commun en plus dès aujourd'hui.

Les propriétaires de serveurs de jeu sont concernés au même titre : le site vitrine d'un serveur FiveM, le wiki d'un serveur Minecraft ou le forum d'une communauté Rust sont des sites web comme les autres, souvent servis par le même Nginx que le panneau publié en HTTPS. Le fichier s'y ajoute de la même façon. Et si la question de la visibilité de vos contenus communautaires dans les moteurs vous intéresse, elle rejoint celle que nous posions à propos de l'indexation des serveurs Discord par Google : décider ce qui est public, ce qui est indexable et ce qui peut servir à entraîner un modèle sont désormais trois réglages distincts, et robots.txt n'en couvre qu'une partie. Pour sécuriser l'hôte qui sert tout cela, nos guides sur PHP-FPM durci et sur les correctifs Nginx récents complètent utilement cette mise à jour de configuration.