Refuser que ses contenus servent à entraîner des modèles d’intelligence artificielle relève aujourd’hui du patchwork : une ligne pour Google, une autre pour chaque développeur d’IA, à condition de connaître le nom de chacun de leurs robots. Google a annoncé le vendredi 30 octobre sur son blog Search Central qu’il prendrait en charge un signal commun, inscrit dans le fichier robots.txt et issu des travaux de l’IETF, l’organisme qui normalise les protocoles d’Internet.
Plan de l'article
Un seul « jeton » pour tous les fournisseurs d’IA #
Le principe, détaillé par John Mueller, Search Advocate chez Google, repose sur un « policy token », un jeton de préférence que l’on place dans robots.txt comme s’il s’agissait d’un robot. Au lieu de multiplier les instructions par fournisseur, l’éditeur exprime une préférence générale valable pour tous les acteurs qui adhèrent au mécanisme.
Le jeton est défini dans un brouillon déposé à l’IETF dans le cadre du groupe de travail AIPREF, consacré aux préférences d’usage par les IA. Son nom : __usage_ai-training. Le double tiret bas en tête est voulu : il rend très improbable une collision accidentelle avec le nom d’un vrai robot.
À lire Aperçus IA de Google : cinq organisations d’éditeurs français portent plainte à Bruxelles
Concrètement, pour signaler que l’ensemble du site ne doit pas servir à l’entraînement, le brouillon prévoit d’écrire un groupe robots.txt ordinaire :
User-Agent: __usage_ai-training
Disallow: /Aucune directive nouvelle, aucune grammaire nouvelle : la syntaxe des chemins, la règle de la correspondance la plus longue et la structure en groupes du robots.txt restent celles de la norme existante. On peut donc refuser l’entraînement sur un répertoire précis et l’autoriser ailleurs.
Comment Google va l’interpréter #
Google explique que si un site utilise ce jeton pour refuser l’entraînement, et qu’il ne mentionne pas explicitement Google-Extended, le moteur traitera la situation comme si l’éditeur avait bloqué Google-Extended. Pour rappel, Google-Extended est le contrôle qu’il propose depuis 2023 pour encadrer l’usage des contenus par ses modèles d’IA.
Les contrôles propres à chaque entreprise ne disparaissent pas. Ils continuent de fonctionner à côté du signal commun : un éditeur pourra exprimer un choix global avec le jeton partagé, puis l’affiner fournisseur par fournisseur. Le brouillon de l’IETF va dans le même sens, puisque les expressions les plus spécifiques doivent primer sur les plus générales.
À lire Connected Apps Platform : Google ouvre Search et Gemini aux applications tierces
Ce que le jeton ne fait pas
Deux précisions du brouillon méritent l’attention des responsables SEO. D’abord, le jeton n’est pas une consigne d’exploration : il exprime une préférence d’usage, pas une interdiction de visiter les pages. Un robot peut continuer à crawler un site, et c’est toujours avec les groupes au nom des robots eux-mêmes qu’on limite le passage. Ensuite, un groupe générique User-Agent: * ne doit pas être interprété comme visant ce jeton. Un Disallow: / général n’exprime donc aucune préférence sur l’entraînement : il faut nommer le jeton explicitement.
Enfin, en l’absence de toute ligne User-Agent: __usage_ai-training, le brouillon considère qu’aucune préférence n’a été exprimée.
Le calendrier : pas avant 2027 #
Rien ne change dans l’immédiat. Google indique viser une prise en charge de ce contrôle en 2027, conjointement avec d’autres fournisseurs d’IA, et promet de communiquer sur l’avancement. Le texte de l’IETF reste un brouillon de travail. Il expire le 3 mai 2027 s’il n’est pas mis à jour, et sa forme peut encore évoluer.
Google rattache aussi cette démarche au code de bonnes pratiques européen destiné aux fournisseurs de modèles d’IA à usage général, adopté dans le cadre de l’AI Act, qui reconnaît le robots.txt comme moyen principal pour les éditeurs d’exprimer des préférences lisibles par les machines. La proposition répond, selon Google, aux demandes d’éditeurs, d’organisations de la société civile et de régulateurs qui réclamaient des contrôles valables pour toute l’industrie.
À lire Aperçus IA et Mode IA : Google documente le réglage pour en exclure son site
Ce que cela change pour votre visibilité #
Le point le plus sensible concerne le lien entre entraînement et visibilité. Google précise que les sites qui autorisent explicitement Google-Extended peuvent apparaître dans les réponses des applications Gemini et y recevoir des clics, grâce au mécanisme de « grounding », l’ancrage des réponses sur des sources web. Refuser l’entraînement à l’échelle de toute l’industrie n’est donc pas un choix neutre pour qui cherche à être cité par les assistants conversationnels.
Pour une marque, une TPE ou un média, la question devient stratégique : faut-il protéger ses contenus ou miser sur la présence dans les réponses générées ? Le futur signal permettra de trancher en une ligne, puis de nuancer. Une entreprise pourrait par exemple refuser l’entraînement par défaut tout en autorisant explicitement les fournisseurs dont elle attend du trafic.
Que faire dès maintenant
D’ici 2027, l’essentiel est de faire l’inventaire. Ouvrez votre robots.txt et repérez les règles déjà en place pour les robots d’IA. Vérifiez qu’un blocage pensé pour un fournisseur ne coupe pas, par ricochet, le robot d’exploration classique dont dépend votre référencement. Et documentez votre position : protéger les contenus, être visible dans les réponses des IA, ou un mélange des deux. Le jour où le jeton commun sera reconnu, il suffira de traduire cette décision en quelques lignes.
Le standard n’est pas encore figé et son adoption dépendra du nombre d’acteurs qui suivront Google. Mais pour la première fois, un mécanisme unique et ouvert se dessine. Il simplifiera la vie des éditeurs qui, jusqu’ici, devaient suivre la liste mouvante des robots d’IA.
À lire Bing Webmaster Tools : l’onglet Topics Portfolio montre sur quels thèmes l’IA vous cite
