Une IA peut-elle lire votre site ? Trois couches

J’étais à quelques paragraphes d’un billet sur le changement du 15 septembre chez Cloudflare quand je me suis arrêté pour vérifier mon propre site, parce qu’écrire « voici ce que fait votre périphérie » sans regarder sa propre périphérie, c’est la façon la plus sûre de publier une correction ensuite.

Trois commandes.

dig +short NS amirmousavi.com
dig +short amirmousavi.com
curl -sI https://amirmousavi.com | grep -iE "^(server|cf-|x-vercel)"

Les serveurs de noms ont répondu vern.ns.cloudflare.com. et paige.ns.cloudflare.com., ce à quoi je m’attendais. Les enregistrements A ont répondu 64.29.17.1 et 216.198.79.1, ce à quoi je ne m’attendais pas : ce sont des adresses Vercel, pas des adresses Cloudflare. Les en-têtes de réponse ont donné server: Vercel et x-vercel-id: yul1::…, et rien d’autre. Aucun cf-ray. Aucun cf-cache-status. Pas un seul en-tête Cloudflare sur toute la réponse.

Cloudflare gère mon DNS et rien de plus. Les requêtes se résolvent par les serveurs de noms de Cloudflare puis filent directement vers Vercel. Tous les contrôles de robots IA que Cloudflare propose, y compris les catégories dont tout le monde parle ce mois-ci et le réglage par défaut qui change le 15 septembre, se trouvent sur une périphérie que mon trafic ne touche jamais.

Mon robots.txt ne dit pas cela. Il ne le peut pas : c’est un fichier texte de préférences, servi par la même origine dans les deux cas. La consultation des serveurs de noms ne le dit pas non plus, et c’est là le piège, parce que les serveurs de noms indiquent qui pourrait être dans le chemin de la requête plutôt que qui y est. Seules les deuxième et troisième commandes tranchent.

Voilà le billet, démontré sur un seul domaine : trois surfaces différentes vous raconteront chacune une histoire différente sur qui peut lire votre site, et une seule d’entre elles se trouve dans le chemin de la requête.

Les citations de documentation sont reproduites en anglais, langue de leurs sources ; la traduction entre parenthèses est la mienne.

Réponse courte

Trois couches décident si un moteur IA peut lire votre site, et elles ne s’accordent pas entre elles. Le robots.txt est indicatif : Perplexity documente que son récupérateur déclenché par l’utilisateur « generally ignores robots.txt rules » (ignore généralement les règles du robots.txt), et Google documente le même comportement pour toute sa classe de récupérateurs déclenchés par l’utilisateur, y compris le jeton Google-Agent ajouté le 20 mars 2026. Le CDN ou la périphérie applique : il renvoie un 403 quelles que soient les promesses d’un robot, et un vérificateur qui se contente d’analyser le robots.txt ne peut structurellement pas le voir. Web Bot Auth est cryptographique et expérimental : la documentation de Google indique elle-même « Not all Google user agents are using Web Bot Auth » (tous les agents utilisateurs de Google n’utilisent pas Web Bot Auth). Ce que je fais plutôt que de me fier à un vérificateur : lancer dig et curl sur mon propre nom d’hôte d’abord, traiter le robots.txt comme une préférence publiée plutôt que comme un contrôle, et garder ai-input=yes dans mon Content-Signal parce qu’être lisible par les moteurs de réponse est justement l’objectif du site.

Que m’ont appris trois commandes sur ma propre périphérie ?

Elles m’ont appris quelle couche est réelle sur mon domaine, et il en a fallu deux sur trois pour y arriver.

dig +short NS amirmousavi.com renvoie des serveurs de noms Cloudflare. Prise isolément, cette phrase est compatible avec deux architectures complètement différentes : un site dont le trafic passe par le mandataire de Cloudflare, et un site qui n’utilise Cloudflare que comme hébergeur DNS faisant autorité. Le raccourci du métier parle de nuage orange contre nuage gris, et c’est invisible de l’extérieur du tableau de bord tant qu’on ne regarde pas vers quoi l’enregistrement se résout.

dig +short amirmousavi.com est justement l’endroit où il se résout. Un enregistrement en mode mandataire répond par une adresse anycast de Cloudflare, prise dans les plages que Cloudflare publie à cloudflare.com/ips-v4. Le mien répond 64.29.17.1 et 216.198.79.1, qui ne figurent pas dans cette liste. www se résout via 1c2f67713588e1c5.vercel-dns-017.com. vers 64.29.17.65 et 216.198.79.65. C’est une périphérie Vercel, atteinte directement.

curl -sI le confirme par l’autre bout. L’apex renvoie HTTP/2 308 vers https://www.amirmousavi.com/, j’ai donc vérifié aussi la destination ; www renvoie HTTP/2 200 avec server: Vercel, x-vercel-cache: HIT et x-vercel-id: yul1::…. Un mandataire Cloudflare ajoute cf-ray sur pratiquement toutes les réponses. Il n’y a aucun cf-ray ici.

Voici donc les trois couches, plus une quatrième surface que presque personne ne regarde, et l’endroit où chacune se trouve :

Couche	Ce qu’elle contrôle	Indicatif ou appliqué	Qui la respecte	Source et date
`robots.txt`	Les chemins qu’un robot devrait demander, par jeton d’agent utilisateur	Indicatif. Un fichier que le client choisit de lire	Les robots de recherche, largement. Les récupérateurs déclenchés par l’utilisateur, largement pas : Perplexity-User « generally ignores robots.txt rules » ; les récupérateurs de Google « generally ignore robots.txt rules »	Documentation des robots de Perplexity (consultée le 21 août 2026) · Récupérateurs déclenchés par l’utilisateur, Google (mise à jour le 19 août 2026)
Règles de robots au CDN ou en périphérie	Si la requête obtient une réponse, par catégorie, IP, signature et agent utilisateur	Appliqué. La décision se prend dans le chemin de la requête	Personne n’a à la respecter. Elle leur est appliquée	Cloudflare : Block AI Bots (mise à jour le 1er juillet 2026) · Groupe de règles AWS WAF Bot Control (consulté le 21 août 2026)
Balise meta robots `NOARCHIVE` / `NOCACHE`	Si Microsoft utilise une page déjà indexée dans les réponses de Bing Chat et pour l’entraînement	Indicatif, et propre à un fournisseur. Vit dans le `<head>` de la page, pas dans un fichier à l’échelle du site	Microsoft, pour ses propres surfaces	Blogue Bing Webmaster, Fabrice Canel (22 septembre 2023)
Web Bot Auth	Si un robot peut prouver cryptographiquement son identité, requête par requête	Ni l’un ni l’autre pour l’instant. C’est un signal d’identité sur lequel une périphérie peut agir	Google le teste ; Cloudflare et AWS WAF savent le consommer	Google : Web Bot Auth (expérimental) (mise à jour le 4 mai 2026)

Quatre lignes pour trois couches : la balise meta de Bing est une quatrième surface plutôt qu’une quatrième couche, et c’est celle qui surprend le plus. Trois des quatre sont invisibles pour un audit du robots.txt. Google inscrit lui-même la ligne de la périphérie dans sa documentation. Sa page sur les fonctionnalités IA et votre site, mise à jour le 10 décembre 2025, inscrit parmi les bonnes pratiques SEO : « Ensuring that crawling is allowed in robots.txt, and by any CDN or hosting infrastructure » (s’assurer que l’exploration est autorisée dans le robots.txt, et par toute infrastructure de CDN ou d’hébergement). Cette formule dort dans la documentation de Google depuis au moins huit mois et je ne l’ai jamais vue citée dans une liste de vérification GEO.

Le robots.txt contrôle-t-il encore qui lit votre site ?

Il n’a jamais rien contrôlé. Il déclare, et le client décide. Ce qui a changé en 2026, c’est qui a rejoint cette classe : un client qui ne se contente pas de récupérer, mais qui navigue et agit.

La documentation de Perplexity sépare son trafic en deux. PerplexityBot est le robot d’indexation, et la consigne de Perplexity est directe : « To ensure your site appears in search results, we recommend allowing PerplexityBot in your site’s robots.txt file » (pour que votre site apparaisse dans les résultats de recherche, nous recommandons d’autoriser PerplexityBot dans votre robots.txt). Perplexity-User est le récupérateur qui s’exécute quand quelqu’un pose une question. De celui-là, Perplexity écrit : « Since a user requested the fetch, this fetcher generally ignores robots.txt rules » (comme un utilisateur a demandé la récupération, ce récupérateur ignore généralement les règles du robots.txt). Pas « peuvent ne pas s’appliquer ». Ignore.

Google documente une catégorie entière de la même façon. Sa page sur les récupérateurs déclenchés par l’utilisateur, mise à jour le 19 août 2026, indique : « Because the fetch was requested by a user, these fetchers generally ignore robots.txt rules » (comme la récupération a été demandée par un utilisateur, ces récupérateurs ignorent généralement les règles du robots.txt). Neuf récupérateurs se trouvent dans cette classe, et le plus récent est le plus important. Google-Agent a été ajouté le 20 mars 2026 ; l’entrée du journal des modifications le décrit comme se déployant « over the next few weeks » (au cours des prochaines semaines), pour « be used by Google agents hosted on Google infrastructure to navigate the web and perform actions upon user request » (être utilisé par des agents Google hébergés sur l’infrastructure de Google pour naviguer sur le Web et agir à la demande d’un utilisateur). Un agent qui navigue et qui agit, dans une classe qui ignore le robots.txt, sous un jeton dont la plupart des listes de blocage n’ont jamais entendu parler.

J’ai déjà publié le relevé complet des jetons d’OpenAI, d’Anthropic, de Meta et de Google Search plutôt que de le réimprimer ici, dans mesurer le trafic de la recherche IA, avec les phrases exactes que chaque fournisseur emploie au sujet du robots.txt et les endroits où leurs politiques divergent. La version courte, qui tient toujours à la relecture d’aujourd’hui : parmi les trois fournisseurs d’assistants de ce relevé, deux — OpenAI et Meta — publient une exemption du robots.txt pour les récupérations déclenchées par l’utilisateur, et Anthropic n’en publie aucune. Les traiter comme un seul lot de « robots IA » est l’erreur qui se trouve sous la plupart des listes de blocage en circulation.

Reste le cas où la déclaration a été respectée et où la requête est arrivée quand même. Le 4 août 2025, Cloudflare a rapporté que « Perplexity uses not only their declared user-agent, but also a generic browser intended to impersonate Google Chrome on macOS when their declared crawler was blocked » (Perplexity utilise non seulement son agent utilisateur déclaré, mais aussi un navigateur générique destiné à se faire passer pour Google Chrome sur macOS lorsque son robot déclaré était bloqué), et qu’en réponse « we have de-listed them as a verified bot and added heuristics to our managed rules that block this stealth crawling » (nous l’avons retiré de la liste des robots vérifiés et avons ajouté des heuristiques à nos règles gérées pour bloquer cette exploration furtive). Quelle que soit votre lecture de cet incident précis, il établit proprement le point général : une règle écrite contre une chaîne d’agent utilisateur est une règle écrite contre une valeur que le client choisit.

AWS a discrètement encodé le même skepticisme dans sa taxonomie. Son groupe de règles Bot Control applique une étiquette, bot:user_triggered:verified, pour « a bot that is similar to a verified bot, but that might be directly invoked by end users » (un robot semblable à un robot vérifié, mais susceptible d’être invoqué directement par des utilisateurs finaux), puis précise ce qu’il en fait : « This category of bot is treated by the Bot Control rules like an unverified bot » (cette catégorie de robot est traitée par les règles de Bot Control comme un robot non vérifié). Un fournisseur qui écrit un pare-feu applicatif a déjà décidé que « déclenché par l’utilisateur » signifie « non fiable ».

Qu’est-ce qui change réellement en périphérie le 15 septembre 2026 ?

Cloudflare classe le trafic IA par comportement : Search, Agent, Training. Et à partir du 15 septembre 2026, un robot à usage mixte compte comme Training.

Cette phrase résume le changement. La documentation Block AI Bots de Cloudflare, mise à jour le 1er juillet 2026, définit les trois préréglages. Search désigne « crawlers that collect or index your content to answer questions about it later » (les robots qui recueillent ou indexent votre contenu pour répondre plus tard à des questions à son sujet). Agent désigne « automated activity acting in real time on a person’s behalf, such as chat fetch bots and browser-use agents » (une activité automatisée agissant en temps réel pour le compte d’une personne, comme les robots de récupération de conversation et les agents pilotant un navigateur). Training désigne « crawlers taking your content to train or fine-tune a model, including mixed-purpose crawlers that are used both for Training and for Search » (les robots qui prennent votre contenu pour entraîner ou affiner un modèle, y compris les robots à usage mixte servant à la fois au Training et au Search). Relisez cette dernière proposition. La reclassification se trouve à l’intérieur de la définition de Training, pas seulement dans un réglage par défaut qui bascule à une date.

Deux choses distinctes se produisent le 15 septembre, et la couverture les soude constamment l’une à l’autre.

Configuration	Comportement avant le 15 septembre 2026	Comportement après	Source
Préréglage historique « Block AI bots », déjà activé	Bloque les robots d’entraînement. « This option excludes mixed-purpose bots that are used both for Training and for Search » (cette option exclut les robots à usage mixte servant à la fois au Training et au Search)	Les robots à usage mixte « will also be blocked by all configurations to block AI training, including the legacy 'Block AI bots' option » (seront aussi bloqués par toutes les configurations bloquant l’entraînement IA, y compris l’option historique). Le préréglage porte l’étiquette « Block AI bots [Deprecating on September 15, 2026] »	Documentation Cloudflare, 1er juillet 2026
Toute configuration qui bloque Training	Robots d’entraînement à usage unique bloqués	« Since the defaults will be enforced by the most restrictive applicable rules, multi-purpose crawlers such as Googlebot, Applebot, and BingBot will be blocked by customers who have selected to block Training » (les valeurs par défaut étant appliquées selon la règle la plus restrictive, des robots polyvalents comme Googlebot, Applebot et BingBot seront bloqués chez les clients ayant choisi de bloquer Training)	Blogue Cloudflare, 1er juillet 2026
Domaine intégré à Cloudflare après la date	Sans objet	« For all new domains onboarding to Cloudflare, the categories of Training and Agent will be blocked by default on the pages that display ads, while Search will remain allowed by default » (pour tous les nouveaux domaines intégrés à Cloudflare, les catégories Training et Agent seront bloquées par défaut sur les pages affichant des publicités, tandis que Search restera autorisé)	Blogue Cloudflare, 1er juillet 2026
Domaine existant, sans nouvelle action	Réglages actuels	Aucun nouveau réglage par défaut n’est énoncé pour les domaines existants. « Before September 15, all customers can opt out of these new defaults » (avant le 15 septembre, tous les clients peuvent se soustraire à ces nouveaux réglages)	Documentation Cloudflare, 1er juillet 2026

Notez quelle ligne porte quelle citation. La page de documentation ne nomme Googlebot, Applebot ni BingBot nulle part ; cette phrase se trouve sur le blogue. J’ai vérifié parce qu’une première version de mes propres notes l’attribuait à la mauvaise URL, et une citation rattachée à la mauvaise source est une citation que le lecteur ne peut pas vérifier.

Voici maintenant la correction qui compte le plus, à mon avis. Une bonne partie de la couverture secondaire décrit les nouveaux réglages du 15 septembre comme touchant « les nouveaux clients, les nouveaux sites de clients existants et tous les clients existants du forfait gratuit ». Le billet de Cloudflare dit « all new domains onboarding to Cloudflare » (tous les nouveaux domaines intégrés à Cloudflare). Je n’ai trouvé la portée élargie énoncée nulle part à la source, donc je ne la reprends pas. Le changement véritablement large pour les clients existants est l’autre : la règle sur les robots à usage mixte, qui atteint quiconque a un jour coché le bouton historique. Quelqu’un qui a activé « Block AI bots » en 2024 comme refus de l’entraînement a pris une décision dont le sens change sans qu’il y touche. C’est une meilleure histoire que celle qu’on raconte, et c’est celle qui est documentée.

Il vaut aussi la peine de savoir ce qui reste autorisé. La page des catégories de robots vérifiés de Cloudflare, mise à jour le 1er juillet 2026, classe OAI-SearchBot dans « AI Search » et Googlebot dans « Search Engine Crawler ». Le trafic classé Search demeure autorisé sous les nouveaux réglages. L’exposition se concentre sur les robots qui font deux métiers avec un seul jeton.

Une précision structurelle qui m’a surpris : « Each blocking option will block Verified bots classified with that behavior, plus additional unverified bots that fall under these classifications » (chaque option de blocage bloquera les robots vérifiés classés avec ce comportement, plus d’autres robots non vérifiés relevant de ces classifications). La page des catégories de Cloudflare confirme le glissement en termes simples : « Historically, Verified bots have been excluded in default bot configurations across all plans. Now, all customers have the option to configure AI bot policies » (historiquement, les robots vérifiés étaient exclus des configurations par défaut sur tous les forfaits ; maintenant, tous les clients peuvent configurer des politiques de robots IA). Le statut de robot vérifié était un laissez-passer. Ce n’est plus qu’une étiquette que la politique lit.

Pourquoi un vérificateur de robots.txt peut-il dire oui pendant que votre périphérie dit non ?

Parce qu’un vérificateur récupère un fichier texte et l’analyse, alors qu’une décision en périphérie se prend requête par requête, contre un agent utilisateur, une adresse IP et, de plus en plus, une signature. Ce ne sont pas les mêmes mesures. Un outil qui analyse le robots.txt ne peut pas plus observer une règle de pare-feu applicatif que la lecture des heures d’ouverture affichées d’un restaurant ne vous dit si la porte est verrouillée.

C’est le même mode de défaillance que celui dont je parlais dans peut-on faire confiance aux scores de visibilité IA : un outil rapporte ce qu’il sait mesurer, l’acheteur y lit ce qui l’intéresse, et personne ne vérifie l’écart. Un crochet vert pour « robots IA autorisés » signifie que le fichier les autorise. Il ne signifie pas qu’une requête arrive.

Il existe un troisième endroit où regarder, que presque aucun audit ne consulte, et ce n’est même pas un fichier. Le refus de Microsoft pour les réponses génératives est une balise meta robots, dans l’en-tête de la page. Fabrice Canel l’a publié le 22 septembre 2023 : le contenu marqué NOARCHIVE « will not be included in Bing Chat answers, not be linked to in the answers » (ne sera pas inclus dans les réponses de Bing Chat, ni lié dans les réponses), et « we will not use the content for training Microsoft’s generative AI foundation models » (nous n’utiliserons pas ce contenu pour entraîner les modèles de fondation génératifs de Microsoft). Le contenu marqué NOCACHE « may be included in Bing Chat answers. We will only display URL/Snippet/Title in the answer » (peut être inclus dans les réponses de Bing Chat ; nous n’y afficherons que l’URL, l’extrait et le titre). Et la valeur par défaut, énoncée sans détour : « Content without NOCACHE tag and without NOARCHIVE tag may be included in Bing Chat answers » (le contenu sans balise NOCACHE ni NOARCHIVE peut être inclus dans les réponses de Bing Chat).

Ce contrôle vit page par page, en HTML, et un audit du robots.txt à l’échelle du site ne le verra jamais. Un gabarit de CMS, une extension ou un réglage par défaut d’environnement de préproduction peut le poser sur des milliers d’URL sans que personne ne l’ait décidé. Si vous héritez d’un site, c’est une vérification de cinq secondes qui vaut la peine, et c’est le genre de chose que je garde dans la liste de vérification d’architecture SEO plutôt que dans la mémoire de quiconque.

Cloudflare fait-il exception, ou tout le monde fait-il pareil ?

D’après ce que j’ai pu vérifier aujourd’hui, Cloudflare fait exception. C’est la seule des plateformes que j’ai consultées qui déplace un réglage par défaut à une date de calendrier.

Vercel, qui est ma périphérie réelle, l’énonce aussi clairement qu’une documentation le peut. Sur sa page des ensembles de règles gérés du WAF, mise à jour le 17 juillet 2026 : « The ruleset is inactive by default. In the dashboard this is labeled Allow. Matching traffic is not evaluated and reaches your application » (l’ensemble de règles est inactif par défaut ; dans le tableau de bord il porte l’étiquette Allow ; le trafic correspondant n’est pas évalué et atteint votre application). Les actions offertes sont Log et Deny, et vous en choisissez une. Rien n’arrive au trafic IA tant que personne ne l’active.

Netlify livre le blocage sous forme d’extension à installer. Sa documentation, mise à jour le 13 février 2026, décrit « The User Agent Blocker extension is built by Netlify » (l’extension User Agent Blocker est conçue par Netlify), laquelle « can block web requests from a preset list of common AI crawlers, SEO/Search crawlers that you choose from » (peut bloquer les requêtes provenant d’une liste prédéfinie de robots IA et de robots SEO courants, parmi lesquels vous choisissez), implémentée comme « a Netlify Edge Function » (une fonction de périphérie Netlify). Une adhésion volontaire par construction : une extension que vous installez et configurez.

Fastly le place derrière un achat et une configuration. ContentGuard exige d’acheter Bot Management et de « deploy Bot Management using pre-cache inspection » (déployer Bot Management avec l’inspection avant cache) sur chaque service, puis d’écrire des extraits VCL dans vcl_recv contre des variables qui « all start with fastly.bot. » (commencent toutes par fastly.bot.), dont fastly.bot.category.is_ai_crawler. Puissant, et personne n’y arrive par accident.

AWS WAF est le cas intéressant. Je l’avais classé comme non vérifié, alors je suis allé lire la documentation du groupe de règles moi-même. Bot Control est un groupe de règles géré que vous ajoutez à une liste de contrôle d’accès web, et vous êtes « charged additional fees when you use this managed rule group » (facturé des frais supplémentaires lorsque vous l’utilisez). À l’intérieur, une règle se distingue des quinze autres règles de catégorie. CategoryAI « inspects for artificial intelligence (AI) bots. This rule applies the action to all matches, regardless of whether the bots are verified or unverified. Rule action: Block » (inspecte les robots d’intelligence artificielle ; cette règle applique l’action à toutes les correspondances, que les robots soient vérifiés ou non ; action : bloquer). Toutes les autres règles Category* s’appliquent « only to unverified bots » (uniquement aux robots non vérifiés). AWS a isolé le trafic IA, et l’a fait dans un produit auquel il faut adhérer et qu’il faut payer.

Je n’ai pas vérifié Akamai, donc Akamai n’est pas dans cette section. Je préfère laisser un trou que de décrire le réglage par défaut d’un fournisseur à partir d’un résumé.

Qu’est-ce que Web Bot Auth, et est-ce déjà utile ?

C’est la couche qui rendrait les deux autres cohérentes, et elle n’est pas prête.

Google en a publié la documentation le 4 mai 2026, sur une page intitulée « Web Bot Auth (Experimental) ». L’idée est simple et attendue depuis longtemps : au lieu qu’un robot affirme une identité dans un en-tête que n’importe qui peut copier, il signe la requête. « Instead of relying solely on self-reported headers and IP addresses, Web Bot Auth allows agents to cryptographically sign their requests » (plutôt que de s’appuyer uniquement sur des en-têtes auto-déclarés et des adresses IP, Web Bot Auth permet aux agents de signer cryptographiquement leurs requêtes). Mécaniquement, les requêtes participantes portent un en-tête Signature-Agent valant g="https://agent.bot.goog", vous récupérez les clés publiques à https://agent.bot.goog/.well-known/http-message-signatures-directory, et vous vérifiez selon la norme HTTP Message Signatures, la RFC 9421.

Google est inhabituellement direct sur l’état de la chose. « Web Bot Auth is currently a draft specification developed by the IETF WBA Working Group, and it may change over time » (Web Bot Auth est actuellement une spécification en projet développée par le groupe de travail WBA de l’IETF, et elle peut évoluer). « Not all Google user agents are using Web Bot Auth » (tous les agents utilisateurs de Google n’utilisent pas Web Bot Auth). « We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification » (nous ne signons pas toutes les requêtes d’un agent donné ; assurez-vous de revenir aux méthodes établies de vérification des robots). Et la consigne opératoire pour quiconque serait tenté de reconstruire ses règles d’accès là-dessus : « We recommend that in addition to Web Bot Auth you continue relying on IP addresses, reverse DNS, and user-agent strings as we gradually roll out signed traffic » (nous recommandons de continuer à vous appuyer sur les adresses IP, le DNS inverse et les chaînes d’agent utilisateur pendant le déploiement graduel du trafic signé).

Les fournisseurs de périphérie sont plus avancés que cela ne le laisse croire. Cloudflare tient une page de référence Web Bot Auth dans sa documentation de vérification des robots, mise à jour le 1er juillet 2026, qui la définit comme « an authentication method that leverages cryptographic signatures in HTTP messages to verify that a request comes from an automated bot » (une méthode d’authentification qui exploite les signatures cryptographiques dans les messages HTTP pour vérifier qu’une requête provient d’un robot automatisé). Bot Control d’AWS WAF émet déjà des étiquettes pour cela : web_bot_auth:verified, web_bot_auth:invalid, web_bot_auth:expired et web_bot_auth:unknown_bot, avec cette note : « When the web_bot_auth:verified label is present, the Category<category_name> and TGT_TokenAbsent rules do not match, allowing verified WBA hosts to proceed » (lorsque l’étiquette web_bot_auth:verified est présente, les règles de catégorie et TGT_TokenAbsent ne correspondent pas, ce qui laisse passer les hôtes WBA vérifiés).

Je ne peux pas déduire de cette documentation comment l’exemption WBA interagit avec CategoryAI, puisque CategoryAI est documentée comme s’appliquant « to all matches, regardless of whether the bots are verified or unverified » (à toutes les correspondances, que les robots soient vérifiés ou non). Ces deux phrases sont en tension et je ne vais pas trancher par supposition. Si vous exploitez AWS WAF et que la réponse vous importe, testez-la plutôt que de la déduire.

Voici pourquoi je pense malgré tout que la troisième couche est celle à surveiller. Les couches un et deux consacrent l’essentiel de leur effort à décider s’il faut croire une chaîne d’agent utilisateur. La couche trois met fin à la dispute. Quand la signature sera généralisée, « qui a le droit de lire ceci » cessera d’être une conjecture sur des agents utilisateurs pour devenir une politique sur des identités vérifiées. Nous n’y sommes pas. Google le dit lui-même.

Comment vérifier votre propre périphérie

Six étapes, dans l’ordre. Chacune a une façon de vous induire en erreur, et la mise en garde est le cœur de l’exercice.

Lisez vos serveurs de noms. dig +short NS example.com. Cela vous dit qui gère votre DNS. Comment cela trompe : cela ne dit pas qui se trouve dans le chemin de la requête. Le mien renvoie des serveurs de noms Cloudflare sur un site sans mandataire Cloudflare. Si vous vous arrêtez là, vous passerez un après-midi à chercher un tableau de bord que vous n’avez pas.
Résolvez l’enregistrement que vous servez vraiment. dig +short example.com et dig +short www.example.com. Comparez les réponses à cloudflare.com/ips-v4 ou aux plages publiées par votre CDN. Un enregistrement en mode mandataire répond par l’adresse anycast du CDN ; un enregistrement DNS seul répond par votre origine. Comment cela trompe : l’apex et www sont souvent configurés différemment. Les miens diffèrent.
Lisez les en-têtes de réponse sur le nom d’hôte que vous servez vraiment. curl -sI https://www.example.com. Cherchez server, cf-ray, x-vercel-id, x-amz-cf-id, x-served-by. Comment cela trompe : mon apex renvoie une redirection 308, donc les en-têtes à cet endroit décrivent le redirecteur, pas l’application. Suivez jusqu’à la destination. Et l’absence d’un en-tête est une preuve plus faible que sa présence ; certaines configurations les retirent.
Faites une requête comme un robot IA déclaré, puis comparez. curl -A "OAI-SearchBot/1.4" -sI https://www.example.com, puis comparez le code de statut et le content-length à ceux de votre requête avec un agent utilisateur de navigateur. Comment cela trompe, et c’est la mise en garde importante : vous ne testez que la correspondance de chaîne d’agent utilisateur. Les vraies règles de robots vérifient les plages IP, le DNS inverse et de plus en plus les signatures, ce que curl ne peut ni satisfaire ni déclencher. Un 200 ici ne prouve pas que le vrai OAI-SearchBot obtient un 200. Cela prouve que personne n’a écrit de règle naïve sur l’agent utilisateur. Sur mon domaine, les deux requêtes ont renvoyé HTTP/2 200 avec un content-length: 41843 identique.
Cherchez une balise meta au niveau de la page. curl -s https://www.example.com/ | grep -i 'name="robots"'. Vous cherchez noarchive ou nocache, le refus de Microsoft pour les réponses génératives. Comment cela trompe : une URL n’est pas un site. Les gabarits appliquent cela de façon inégale, alors vérifiez un article, une page de catégorie et tout ce qui repose sur un autre gabarit avant de conclure.
Lisez le robots.txt en dernier, et lisez-le comme une déclaration. curl -s https://www.example.com/robots.txt. Comment cela trompe : il vous dit ce que vous avez demandé. Il ne dit rien de ce qui s’est passé. Le lire en premier, c’est laisser un fichier parfaitement correct vous dissuader d’enquêter sur un 403 que vous servez vraiment. Un groupe d’agent utilisateur nommé remplace entièrement le groupe *, donc un groupe ajouté pour un robot l’exempte silencieusement de toutes les règles écrites au-dessus.

Si vous faites cela avant un lancement plutôt qu’en diagnostic, les étapes deux à quatre ont leur place dans la liste de vérification de lancement de site, à côté des autres choses dont personne ne se souvient avant la première semaine de trafic.

Mon avis de travail

Mon site publie Content-Signal: search=yes, ai-input=yes, ai-train=no sur chaque groupe d’agent utilisateur du robots.txt, et le ai-input=yes est délibéré. Il dit que les moteurs de réponse peuvent ancrer leurs réponses dans ce contenu. On me demande pourquoi je ne le mets pas à no, en général par quelqu’un qui y lit une posture défensive. Ce n’en est pas une. Mettre ai-input=no ne protège pas le contenu : les pages sont publiques, les mêmes robots les récupèrent, et la couche d’application n’est de toute façon pas là. Cela ne fait que demander à être exclu des réponses. Pour un site dont tout le travail de llms.txt et de rendus Markdown existe pour être lisible par des machines, ce serait une demande étrange.

Je tiens deux choses à la fois, et elles se contredisent moins qu’il n’y paraît. Je veux être lu, et je veux savoir qui lit. Cela demande des couches différentes. ai-input=yes est une déclaration d’intention à la couche un. Savoir si elle est respectée se passe dans les journaux, ce qui est un problème de mesure plutôt qu’un problème d’accès. Ce billet porte sur qui peut lire votre site ; la question miroir, ce qu’un agent peut écrire dans votre pile une fois connecté, fait l’objet d’un billet distinct.

Ce que je ne sais pas : si un moteur de réponse, quel qu’il soit, analyse Content-Signal. Je n’ai trouvé aucun fournisseur qui documente le lire, et je ne vais pas le déduire d’une absence de preuve. Je le publie parce que c’est une déclaration de conditions lisible par machine et peu coûteuse, et parce que je préfère l’avoir dite publiquement. Si c’est un fichier que personne ne lit, j’aurai perdu cinquante-huit lignes de texte.

Je n’ai pas non plus de périphérie Cloudflare à configurer, ce qui explique l’absence de visite guidée d’un tableau de bord dans ce billet. Mon exposition au 15 septembre est nulle, et je ne le sais que parce que j’ai vérifié au lieu de supposer. C’est la partie transférable. Je ne sais pas combien de gens qui écrivent sur ce changement ont lancé dig sur leur propre apex. Je sais que moi, je ne l’avais pas fait avant les trois premiers paragraphes de ce billet, et que je me trompais sur ma propre réponse.

La conclusion ennuyeuse, et je la crois juste : le robots.txt est l’endroit où vous énoncez une préférence, la périphérie est l’endroit où une décision se prend, et tant que Web Bot Auth reste expérimental, tout ce que vous appliquez est appliqué contre une chaîne de caractères. Concevez en conséquence. Vérifiez la couche qui se trouve dans le chemin de la requête, pas celle qui est la plus facile à lire.

Questions fréquentes sur l’accès des robots IA

Bloquer l’entraînement IA dans Cloudflare bloque-t-il Googlebot ?

À partir du 15 septembre 2026, cela le peut. Le billet de Cloudflare du 1er juillet 2026 indique que « since the defaults will be enforced by the most restrictive applicable rules, multi-purpose crawlers such as Googlebot, Applebot, and BingBot will be blocked by customers who have selected to block Training » (les valeurs par défaut étant appliquées selon la règle la plus restrictive, des robots polyvalents comme Googlebot, Applebot et BingBot seront bloqués chez les clients ayant choisi de bloquer Training), que ce soit par les nouvelles options de catégories ou par le service historique « Block AI bots ». Cloudflare précise que les clients peuvent se soustraire aux nouveaux réglages dans leurs paramètres de sécurité avant la date. Cela ne vaut que pour les sites dont le trafic passe réellement par le mandataire de Cloudflare, ce qu’il vaut la peine de vérifier avant d’agir.

Dois-je changer quelque chose avant le 15 septembre 2026 ?

Seulement si votre trafic passe par le mandataire de Cloudflare et que votre configuration bloque Training, y compris par le bouton historique. Confirmez d’abord le mandataire avec dig +short votredomaine.com et une recherche de l’en-tête cf-ray ; les serveurs de noms Cloudflare seuls ne le confirment pas. Si votre trafic passe par le mandataire et que vous bloquez Training, décidez délibérément si vous voulez y inclure les robots de recherche à usage mixte, parce qu’après cette date, ils y sont.

Un vérificateur de robots.txt peut-il me dire si les robots IA sont bloqués ?

Non, et la limite est structurelle plutôt qu’un défaut de qualité. Un vérificateur récupère /robots.txt et analyse les directives ; une règle de périphérie est évaluée requête par requête, contre un agent utilisateur, une adresse IP et potentiellement une signature cryptographique. Rien dans le contenu du fichier ne révèle une décision de pare-feu. Les seuls outils qui peuvent l’observer sont ceux qui envoient de vraies requêtes avec des agents utilisateurs de robots et rapportent le code de statut reçu.

Quels fournisseurs IA disent que leurs récupérateurs ignorent le robots.txt ?

La documentation de Perplexity dit de Perplexity-User : « Since a user requested the fetch, this fetcher generally ignores robots.txt rules » (comme un utilisateur a demandé la récupération, ce récupérateur ignore généralement les règles du robots.txt). Google dit de toute sa classe de récupérateurs déclenchés par l’utilisateur, qui inclut Google-Agent : « Because the fetch was requested by a user, these fetchers generally ignore robots.txt rules » (comme la récupération a été demandée par un utilisateur, ces récupérateurs ignorent généralement les règles du robots.txt). Les politiques divergent plus que les compilations ne le laissent croire, et je les ai comparées jeton par jeton dans mesurer le trafic de la recherche IA.

Devrais-je implémenter Web Bot Auth maintenant ?

Pas comme un contrôle dont vous dépendez. La documentation de Google, mise à jour le 4 mai 2026, qualifie son implémentation d’expérimentale, indique que « Not all Google user agents are using Web Bot Auth » (tous les agents utilisateurs de Google n’utilisent pas Web Bot Auth) et recommande de continuer à s’appuyer sur les adresses IP, le DNS inverse et les chaînes d’agent utilisateur. Si votre CDN sait déjà consommer le signal, comme Cloudflare et AWS WAF, il n’y a aucune raison de le désactiver. Évitez simplement de bâtir une politique d’accès qui suppose la présence de signatures.

Sources utilisées

Vérifié à la source : 21 août 2026.

Réponse courte

Que m’ont appris trois commandes sur ma propre périphérie ?

Le robots.txt contrôle-t-il encore qui lit votre site ?

Qu’est-ce qui change réellement en périphérie le 15 septembre 2026 ?

Pourquoi un vérificateur de robots.txt peut-il dire oui pendant que votre périphérie dit non ?

Cloudflare fait-il exception, ou tout le monde fait-il pareil ?

Qu’est-ce que Web Bot Auth, et est-ce déjà utile ?