OUTILS IA — CHOISIR, MESURER, CONTRÔLER · CONTRÔLER LES ROBOTS IA SUR SON SITE
Sources vérifiées au 19 juillet 2026, sur documentation officielle d'éditeur exclusivement.
Votre site est parcouru par des programmes qui n'y viennent pas pour le lire. Certains constituent un corpus d'entraînement. D'autres alimentent un index de recherche conversationnelle. D'autres encore ouvrent une page parce qu'un utilisateur vient de poser une question. Ces intentions n'ont rien en commun, et pourtant la plupart des sites les traitent avec une seule ligne de configuration.
Cet article est la face symétrique de notre dossier sur la citation par les moteurs de réponse IA. Là, il s'agissait d'être repris. Ici, il s'agit de décider ce que vous laissez prendre — et de savoir lesquels de vos refus produisent un effet réel. Rien de ce qui suit ne repose sur une mesure de trafic : uniquement sur ce que les éditeurs publient, et sur ce que vous pouvez vérifier vous-même.
Quatre robots, quatre intentions différentes
Le premier réflexe utile est de cesser de parler des « robots IA » au pluriel indistinct. Les documentations d'éditeurs décrivent quatre intentions clairement séparées, et chacune appelle une décision différente de votre part.
La collecte d'entraînement. Le robot parcourt le web pour constituer un corpus destiné à l'apprentissage des modèles. C'est le rôle documenté de GPTBot chez OpenAI, de ClaudeBot chez Anthropic, de CCBot chez Common Crawl.
L'indexation pour la recherche conversationnelle. Le robot constitue un index qui servira à retrouver et à citer votre page dans une réponse. OAI-SearchBot, Claude-SearchBot et PerplexityBot relèvent de cette intention. La documentation de Perplexity précise même que son robot n'est pas utilisé pour l'entraînement de modèles.
La récupération déclenchée par un utilisateur. Un humain pose une question, l'interface ouvre votre page pour y répondre. ChatGPT-User, Perplexity-User, Claude-User, meta-externalfetcher agissent dans ce cadre. C'est l'intention la plus difficile à contrôler, pour une raison exposée à la section suivante.
Le service annexe. Vérification de l'innocuité d'une page soumise comme publicité (OAI-AdsBot), génération d'aperçu de partage (facebookexternalhit), collecte demandée par le propriétaire du site lui-même pour ses propres agents (Google-CloudVertexBot). Ces robots n'ont ni vocation d'entraînement ni vocation de citation.
Les quatre intentions documentées, et les trois régimes de contrôle qui s'y appliquent. Un même site fait face aux quatre simultanément, mais un seul fichier de configuration — robots.txt — ne les atteint pas toutes : la colonne « déclenché par un utilisateur » y échappe chez la plupart des éditeurs, et deux jetons d'usage n'apparaissent jamais dans les journaux d'accès.
Un cinquième cas mérite d'être nommé pour ce qu'il est : l'éditeur qui ne documente rien. Certains robots largement observés dans les journaux de sites n'ont, à cette date, aucune page de documentation officielle décrivant leur intention ou leur conformité à robots.txt. Ce cas n'est pas anecdotique : il constitue l'argument le plus direct en faveur du contrôle réseau, puisqu'il n'y a rien à quoi adresser une directive.
robots.txt est une pancarte, pas une serrure
Un fichier robots.txt ne bloque rien. Il publie une préférence. Le serveur continue de répondre à qui la demande ; c'est le programme visiteur qui décide, ou non, de s'abstenir. Cette évidence a trois conséquences que la plupart des configurations ignorent.
Première conséquence : plusieurs éditeurs se déclarent explicitement hors de son périmètre pour leur récupérateur utilisateur. OpenAI écrit, à propos de ChatGPT-User : « parce que ces actions sont initiées par un utilisateur, les règles de robots.txt peuvent ne pas s'appliquer ». Perplexity écrit, pour Perplexity-User : « puisqu'un utilisateur a demandé la récupération, ce récupérateur ignore généralement les règles de robots.txt ». Meta va dans le même sens pour meta-externalfetcher, décrit comme pouvant contourner les règles de robots.txt, et pour facebookexternalhit lors de contrôles de sécurité ou d'intégrité. Trois éditeurs indépendants, une même conception : un agent déclenché par un humain n'est pas traité comme un robot.
Anthropic constitue, sur ce point précis, la seule exception documentée du panel. Sa page d'assistance énonce une règle générale pour l'ensemble de ses robots — « les robots d'Anthropic respectent les signaux de non-collecte en honorant les directives standard du secteur dans robots.txt » — sans énoncer d'exception pour son agent utilisateur, là où OpenAI, Perplexity et Meta en publient une. Formulation prudente à retenir : aucune exception documentée n'est une politique publiée, pas une garantie contractuelle.
Deuxième conséquence : certains jetons ne correspondent à aucun robot. Google-Extended n'a pas de chaîne user-agent HTTP propre : vous pouvez l'écrire dans votre fichier, vous ne verrez jamais l'effet de cette ligne dans vos journaux. Applebot-Extended fonctionne de la même manière — il ne collecte rien, il décide seulement si les données déjà collectées par Applebot peuvent servir à entraîner les modèles d'Apple. Ces deux directives sont des préférences d'usage, invérifiables côté serveur.
Troisième conséquence : un user-agent se falsifie en une ligne de commande. Common Crawl documente officiellement l'existence de faux CCBot se réclamant de son nom. Toute règle qui ne s'appuie que sur la chaîne annoncée par le visiteur est donc contournable par le premier acteur de mauvaise foi.
Bloquer l'entraînement coupe-t-il la citation ? Presque jamais
C'est la crainte qui paralyse le plus de décisions, et elle est infondée dans la majorité des cas documentés. Sur les sept éditeurs dont la documentation a été relevée, un seul impose réellement cet arbitrage. Le facteur décisif n'est ni la politique commerciale de l'éditeur ni sa position sur le droit d'auteur : c'est le nombre de jetons qu'il publie.
Un éditeur qui publie un jeton par intention rend l'arbitrage nul : vous refusez l'un, vous gardez l'autre. Un éditeur qui n'en publie qu'un pour deux usages le rend inévitable : le refus est indivisible.
Le nombre de jetons publiés décide de tout. À gauche, le régime à jetons séparés : deux directives distinctes, deux décisions indépendantes, aucun arbitrage. À droite, le régime à jeton unique : une seule directive commande deux usages, et le refus de l'un emporte mécaniquement le refus de l'autre. Le cas de Google forme un troisième régime, où l'un des usages n'est couvert par aucun jeton.
OpenAI l'écrit explicitement. Sa documentation énonce : « chaque réglage est indépendant des autres — par exemple, un administrateur de site peut autoriser OAI-SearchBot afin d'apparaître dans les résultats de recherche tout en refusant GPTBot ». L'exemple donné par l'éditeur est précisément la configuration que beaucoup n'osent pas adopter.
Apple l'écrit aussi. « Les pages web qui interdisent Applebot-Extended peuvent toujours être incluses dans les résultats de recherche. » La séparation entre la collecte et l'usage d'entraînement est nette, et la documentation ajoute un second point utile : autoriser Applebot n'autorise pas Applebot-Extended. Les deux règles sont indépendantes dans les deux sens.
Anthropic publie la séparation la plus lisible : trois jetons pour trois intentions, ce qui rend l'expression du refus d'entraînement sans effet sur la citation directement écrivable. Perplexity est hors sujet : son robot d'index n'est pas un robot d'entraînement, il n'y a donc rien à arbitrer.
Meta est le seul vrai cas. meta-externalagent est documenté comme parcourant le web « pour des usages tels que l'entraînement de modèles d'IA de fondation ou l'amélioration de produits en indexant directement le contenu ». Un jeton, deux usages. Le refuser coupe simultanément la collecte d'entraînement et l'indexation. C'est ici, et seulement ici dans le panel, que la formule « bloquer l'entraînement, c'est perdre la visibilité » est exacte.
Microsoft occupe une position intermédiaire, avec un mécanisme unique : le contrôle passe par une balise méta, pas par un user-agent. NOARCHIVE exclut le contenu des réponses de l'assistant conversationnel et de l'entraînement des modèles génératifs de fondation ; NOCACHE est le palier intermédiaire, qui n'autorise dans la réponse que l'URL, le titre et l'extrait. La documentation précise que dans les deux cas, le contenu continue d'apparaître dans les résultats de recherche classiques. Le curseur est graduel, pas binaire.
| Éditeur | Jetons publiés | Déclare obéir à robots.txt | Arbitrage entraînement / citation | Source officielle |
|---|---|---|---|---|
| OpenAI | GPTBot, OAI-SearchBot, OAI-AdsBot, ChatGPT-User |
Oui (déclaré) pour les trois premiers ; non pour ChatGPT-User |
Nul — « chaque réglage est indépendant des autres » | developers.openai.com — bots |
| Anthropic | ClaudeBot, Claude-SearchBot, Claude-User |
Oui (déclaré) — aucune exception documentée, y compris pour l'agent utilisateur | Nul — trois jetons, trois décisions | support.claude.com |
| Apple | Applebot, Applebot-Extended (jeton d'usage) |
Oui (déclaré) | Nul — « peuvent toujours être incluses dans les résultats de recherche » | support.apple.com — Applebot |
| Perplexity | PerplexityBot, Perplexity-User |
Oui (déclaré) pour le premier ; non pour le second | Sans objet — robot d'index non utilisé pour l'entraînement | docs.perplexity.ai — bots |
Googlebot, Google-Extended (jeton d'usage), Google-CloudVertexBot, GoogleOther |
Oui (déclaré) | Nul, mais périmètre restreint — voir la section suivante | developers.google.com — crawlers | |
| Meta | meta-externalagent, meta-externalfetcher, facebookexternalhit |
Oui (déclaré) pour le premier ; non pour le deuxième ; partiel pour le troisième | Inévitable — un jeton pour l'entraînement et l'indexation directe | developers.facebook.com — bot |
| Microsoft | Aucun jeton — contrôle par balises NOARCHIVE / NOCACHE |
Sans objet (mécanisme méta) | Graduel — deux paliers, présence en recherche conservée | blogs.bing.com — webmaster |
| Common Crawl | CCBot |
Oui (déclaré) | Sans objet — corpus ouvert, réutilisé en amont par des tiers | commoncrawl.org — CCBot |
Le contrôle effectif se joue au niveau du réseau
Puisque le déclaratif dépend de la bonne volonté d'en face, le seul contrôle qui produit un effet vérifiable est celui qui refuse la requête. Il se place devant votre application : pare-feu applicatif, réseau de diffusion de contenu, règle de périphérie. Quatre acteurs documentent officiellement des mécanismes de ce type.
Cloudflare est le plus accessible. Son produit AI Crawl Control, anciennement AI Audit, est en disponibilité générale, présenté comme disponible sur tous les plans et sans configuration pour la partie observation. Le point important est le mécanisme du blocage : choisir « Block » sur un robot crée ou met à jour une règle personnalisée de pare-feu applicatif sur votre zone. Le code de réponse est configurable — 403 Forbidden ou 402 Payment Required — avec un corps de réponse personnalisable, cette personnalisation étant réservée aux plans payants. Le produit compte également les violations de robots.txt par robot : c'est exactement la mesure de l'écart entre ce qui est déclaré et ce qui se passe.
AWS documente AWS WAF Bot Control, avec les actions surveiller, bloquer, limiter le débit, présenter un défi ou un CAPTCHA. À partir de la version 4.0 de son groupe de règles managé, il ajoute une authentification cryptographique d'identité pour les agents IA — un mécanisme que la documentation d'AI Crawl Control ne décrit pas sous cette forme. La facturation relève des frais du groupe de règles managé.
Fastly publie une offre de gestion des robots IA annonçant des actions de blocage, d'interception et de leurre, avec détection à la périphérie. Akamai documente une solution de protection contre les robots d'extraction, avec blocage, défi, limitation et redirection. Pour ces deux dernières offres, le statut produit précis, les dates et les tarifs ne sont pas publiés sur les pages consultées : à citer comme existantes, sans détail chiffré.
Faire payer l'accès : où en est réellement cette promesse
L'idée de facturer la collecte plutôt que de l'interdire circule depuis deux ans. Elle est aujourd'hui à deux stades très différents selon l'acteur, et confondre les deux fausse toute planification.
Chez Cloudflare, c'est une beta fermée. La documentation le dit sans ambiguïté : « le paiement à la collecte est actuellement en beta fermée ». La mécanique est décrite — l'intention de paiement s'exprime dans un en-tête, la requête aboutit alors en 200 ; à défaut, le serveur répond 402 Payment Required assorti de l'information tarifaire. Cloudflare se positionne comme commerçant de référence. En revanche, aucun tarif plancher n'est publié : le propriétaire fixe un prix par zone, sans montant, sans devise et sans minimum documentés. Ce mécanisme ne se planifie pas.
Chez AWS, c'est disponible et chiffré. La fonction de monétisation du trafic IA d'AWS WAF est documentée comme « disponible globalement avec Amazon CloudFront, sans frais supplémentaires au-delà de la tarification standard d'AWS WAF ». Aucune mention de beta ni de préversion. L'action de monétisation n'est utilisable que sur une liste de contrôle d'accès web associée à une distribution CloudFront. Le mécanisme repose sur une réponse 402 contenant les instructions de paiement au format d'un protocole de paiement à la requête, une autorisation signée par le client, une vérification par le pare-feu applicatif et un règlement en chaîne via un facilitateur tiers. Le prix plancher est publié : 0,001 $ USDC par requête, avec un multiplicateur entier de 1 à 100 par règle. La documentation décrit aussi une tarification par intention : tarif réduit pour les robots de recherche vérifiés qui rapportent du trafic, tarif standard pour les usages de récupération augmentée et de résumé, tarif plus élevé pour les agents non vérifiés, blocage ou tarif premium pour la collecte d'entraînement.
Les réserves publiées par l'éditeur lui-même sont substantielles et doivent peser autant que la promesse. La classification du trafic est probabiliste, et un mode de test est recommandé avant mise en production. Les requêtes payées subissent une latence de plusieurs secondes, due au règlement en chaîne. Les paiements peuvent échouer — indisponibilité du facilitateur, congestion réseau. Des limitations de débit s'appliquent sur les gros volumes. Et surtout : une réponse 402 bloque de fait les visiteurs humains si la règle n'est pas restreinte aux étiquettes de robots.
Ce qu'un blocage ne protège pas
Même parfaitement appliqué, un blocage laisse trois voies ouvertes. Les connaître évite de surestimer ce que vous avez obtenu.
Ce qui a déjà été collecté l'est. Une directive écrite aujourd'hui n'agit pas rétroactivement sur les copies constituées hier. Rien, dans les documentations consultées, ne décrit un mécanisme d'effacement du contenu déjà présent dans un corpus.
L'intermédiaire reste ouvert. CCBot alimente un corpus ouvert largement réutilisé en amont par des entraînements tiers. Bloquer les robots des éditeurs de modèles ne bloque pas le collecteur qui alimente leurs sources. Si votre objectif est de sortir des corpus d'entraînement, l'intermédiaire est au moins aussi important que les destinataires — un enchaînement que nous détaillons dans notre article sur l'empoisonnement et la chaîne d'approvisionnement d'un modèle.
L'utilisateur, lui, passe. Un lecteur humain peut copier votre page dans une interface conversationnelle, ou déclencher une visite par sa question — chemin qui échappe à robots.txt chez plusieurs éditeurs, comme vu plus haut. Aucun contrôle serveur ne couvre ce cas, et c'est le même mécanisme qui, côté entreprise, fait sortir des documents internes par le presse-papiers : le sujet est traité dans ce qui quitte réellement votre machine.
Il faut enfin nommer une dernière limite : les modèles à poids ouverts, une fois diffusés, ne se rappellent pas. La distinction entre poids ouverts, code ouvert et modèle fermé, exposée dans notre article dédié, conditionne ce que « retirer un contenu » peut encore signifier une fois l'entraînement passé.
Comment le vérifier vous-même
Aucune des politiques citées n'est une garantie de résultat, et cet article ne rapporte aucune observation de trafic. Le seul moyen de savoir ce qui se passe sur votre site est de le relever. Le protocole ci-dessous demande une demi-journée et se rejoue à l'identique chaque trimestre.
La conclusion est plus confortable qu'il n'y paraît. Dans la plupart des cas documentés, vous n'avez pas à choisir entre protéger votre contenu et rester visible : les éditeurs qui séparent leurs jetons vous laissent faire les deux, et l'exception se compte sur les doigts d'une main. Ce que vous devez trancher, en revanche, c'est le niveau auquel vous voulez que votre refus existe — une préférence publiée, que vous ne pourrez pas vérifier, ou une règle appliquée, qui laissera une trace dans vos journaux. Cette décision-là relève de la gouvernance interne autant que de la technique, et rejoint le cadre général décrit dans encadrer l'usage de l'IA dans son entreprise.
Une question, un projet IA ?
Vous vous demandez ce que les robots IA prennent réellement sur votre site, ou si votre configuration actuelle protège ce que vous croyez protéger — échangeons sur votre contexte.
Prendre contact →Pour aller plus loin : cet article a une face symétrique — être cité par les moteurs de réponse IA traite la même documentation du point de vue de la visibilité, et se lit en paire avec celui-ci. Côté mécanismes, l'empoisonnement et la chaîne d'approvisionnement d'un modèle explique pourquoi l'intermédiaire compte autant que le destinataire ; poids ouverts, code ouvert, modèle fermé précise ce que « retirer un contenu » peut encore vouloir dire ; et ce qui quitte réellement votre machine couvre la voie que nul blocage serveur ne ferme.