Cloudflare veut simplifier un arbitrage devenu sensible pour les éditeurs : refuser l'entraînement des modèles d'IA tout en conservant leur présence dans les moteurs de recherche. Annoncé le 15 septembre 2026, son réglage Disallow AI Training combine une préférence inscrite dans le fichier robots.txt et le blocage de certains robots. Son efficacité dépend toutefois des contrôles proposés par chaque opérateur. Chez Bing, une intervention supplémentaire reste nécessaire.
L'enjeu vient des robots qui servent plusieurs usages. Googlebot, Applebot et Bingbot peuvent recueillir des pages pour la recherche, tandis que leur opérateur les utilise aussi dans certains services d'IA. Les bloquer entièrement compromet l'exploration du site pour l'indexation. Le nouveau réglage laisse passer les robots mixtes retenus par Cloudflare et transmet aux opérateurs concernés le refus des usages d'entraînement pris en charge.
Une préférence déclarée et un blocage réseau
Le dispositif distingue deux niveaux de contrôle. Bot Preference Sync traduit les choix du propriétaire en directives dans robots.txt. Ce fichier indique les préférences du site, mais n'empêche pas matériellement un robot de télécharger une page. Le blocage au niveau du réseau sert, lui, à arrêter les robots d'entraînement que Cloudflare identifie et auxquels le site refuse l'accès.
La séparation est plus simple lorsque l'opérateur utilise des robots différents pour la recherche et l'entraînement. Cloudflare cite Amazon, Anthropic, Meta et OpenAI : le robot d'entraînement peut être bloqué sans bloquer celui affecté à la recherche. Un refus dans robots.txt et une interdiction technique d'accès restent donc deux opérations distinctes.
Le changement modifie aussi la signification du réglage Block de la catégorie Training. Il s'applique désormais aux robots mixtes, Googlebot compris. L'option Block on pages with ads les bloque sur les pages où Cloudflare détecte des annonces. Un propriétaire qui cherche seulement à refuser l'entraînement doit tenir compte de cet effet possible sur l'exploration pour la recherche.
Google sépare l'entraînement de la présence dans les réponses
Chez Google, le jeton Google-Extended permet de contrôler l'utilisation des contenus pour entraîner les générations futures de Gemini et pour fournir des sources à certaines réponses de Gemini Apps et de Vertex AI. Il ne correspond pas à un robot autonome : Google applique cette préférence aux contenus recueillis par ses agents existants.
La documentation précise que ce réglage ne détermine ni l'inclusion d'un site dans Google Search ni son classement. Son périmètre doit néanmoins être respecté : refuser Google-Extended ne revient pas à supprimer toute utilisation d'IA dans les produits de Google.
La présence des contenus et des liens dans les AI Overviews, le mode IA et les fonctions génératives de Discover relève d'un autre contrôle. Search generative AI, disponible dans Search Console et déployé mondialement depuis le 31 août selon Google, permet de les en exclure. Il ne modifie pas le classement dans les autres parties du moteur et ne règle pas l'entraînement.
Cette exclusion a une contrepartie commerciale explicite : le site ne reçoit plus de liens, d'impressions ni de trafic provenant des fonctions génératives concernées. L'éditeur doit donc distinguer la protection de ses contenus d'entraînement et son choix de distribution dans les réponses. Google fournit un rapport de performance spécifique pour apprécier ce second usage.
Apple dispose d'un refus dédié, Bing conserve sa balise
La documentation Applebot distingue également l'exploration et l'utilisation des données. Applebot-Extended ne visite pas lui-même les pages : le jeton indique si les contenus collectés par Applebot peuvent servir à entraîner les modèles de fondation d'Apple. Le refus n'empêche pas les pages de figurer dans la recherche et n'entre pas dans le classement.
La directive nosnippet couvre un autre usage : elle empêche Apple de reprendre le contenu comme contexte pour certaines réponses générées. Les suggestions de visite peuvent alors conserver le titre de la page, sans description. Apple documente aussi un marquage des contenus payants qui permet leur présence dans la recherche tout en les excluant du contexte utilisé pour produire les réponses.
Chez Microsoft, Cloudflare indique que la lecture d'une préférence de non-entraînement dans robots.txt est visée pour début 2027. D'ici là, Disallow AI Training ne transmet pas automatiquement ce choix à Bing. Le refus passe notamment par la balise NOARCHIVE : Microsoft précise que les pages ainsi marquées restent dans les résultats de recherche, mais que leur contenu n'est pas utilisé pour l'entraînement de ses modèles génératifs ni inclus dans les réponses de Bing Chat.
Un détail de configuration peut changer ce résultat. La documentation Bing indique que si NOARCHIVE et NOCACHE sont présents ensemble, NOCACHE prévaut. Ce dernier permet encore certains usages des URL, titres et extraits. Ajouter une balise sans examiner celles qui existent déjà peut donc produire un résultat différent du refus recherché.
Des engagements dont une partie reste à livrer
Cloudflare attribue la désignation Accountable aux opérateurs qui proposent certains contrôles ou s'engagent à les livrer dans un délai déterminé. Le cadre associe refus de l'entraînement, contrôle des résumés, visibilité à l'échelle des URL et maintien de la recherche classique. Cette désignation commerciale ne constitue pas une certification indépendante du respect des préférences.
Le billet annonce ainsi de futurs outils de transparence liés à Google-Extended, une solution d'inspection chez Apple prévue en 2027 et le mécanisme robots.txt de Bing. Ces échéances sont rapportées par Cloudflare. Elles doivent être distinguées des fonctions documentées et déjà accessibles chez les trois opérateurs.
Les propriétaires de sites peuvent exprimer plusieurs de ces préférences directement, sans Cloudflare : Google-Extended et Applebot-Extended dans robots.txt, NOARCHIVE dans les pages pour Bing, puis les contrôles propres aux réponses génératives. Ils doivent en revanche organiser eux-mêmes l'identification et le blocage des robots lorsque la simple déclaration ne suffit pas.
Cloudflare annonce une migration automatique des anciens réglages afin de préserver leur effet pratique. Un contrôle du fichier robots.txt servi et des règles de sécurité reste utile après cette migration. L'intérêt du service est de centraliser une partie de ces opérations; sa limite immédiate demeure la diversité des mécanismes et des calendriers des moteurs.