Module 7 : Gouverner l'accès des IA à son site

Les modules précédents cherchaient à être lu par les IA. Celui-ci pose la question inverse : que voulez-vous autoriser exactement ? Nourrir un modèle, alimenter un index, être consulté en direct : ce sont trois choses différentes, et on peut dire oui à l'une et non à l'autre.

Mis à jour le 17 août 2026

Trois décisions que tout le monde confond

"Est-ce que je laisse passer les IA ?" n'est pas une question, c'en est trois. Les confondre conduit à des décisions absurdes : bloquer par principe et disparaître des réponses, ou tout ouvrir sans savoir ce qu'on a cédé.

Usage	Ce que ça veut dire	Ce que vous gagnez	Ce que vous cédez
Entraînement	Votre contenu sert à entraîner ou affiner un modèle	Votre expertise imprègne la connaissance du modèle, indépendamment de toute recherche web	Aucune citation, aucun lien, aucun contrôle. Votre contenu est digéré, pas référencé
Index de recherche	Vos pages entrent dans le corpus interrogé au moment de la question	Vous devenez candidat à la citation, avec un lien	Peu de choses. C'est l'usage le plus favorable
Visite à la demande	Un agent va lire votre page parce qu'un utilisateur pose une question maintenant	Le signal le plus fort : vous êtes une réponse en train d'être construite	De la charge serveur, rien de plus

💡 L'arbitrage le plus courant

Beaucoup d'éditeurs choisissent non à l'entraînement, oui à la recherche et à la réponse : je ne donne pas mon corpus gratuitement à un modèle, mais je veux être cité quand quelqu'un pose une question. C'est le réglage par défaut proposé par Cloudflare.

Ce site fait l'inverse et l'assume : tout est ouvert, entraînement compris. La logique est cohérente avec le métier exercé, mais elle ne se transpose pas telle quelle à un média ou à un site dont le contenu est le produit. Votre arbitrage dépend de ce que vous vendez.

robots.txt : le socle

Tout part de là. Chaque acteur déclare des agents distincts par usage : c'est ce qui vous permet d'être sélectif au lieu de trancher en bloc.

# Refuser l'entraînement, accepter la recherche et la réponse
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

⚠️ Trois erreurs classiques

Bloquer GPTBot en croyant sortir de ChatGPT. Vous sortez de l'entraînement, pas des réponses : c'est OAI-SearchBot qui décide de votre présence dans l'index de recherche.
Bloquer Google-Extended en croyant sortir des AI Overviews. Impossible : les surfaces génératives de Google s'appuient sur l'index classique. Le seul moyen d'en sortir serait de sortir de Google entièrement.
Compter sur robots.txt pour se protéger. C'est une convention, pas une barrière. Un acteur qui ne la respecte pas passera quand même. Si l'enjeu est réel, il faut du blocage au niveau du pare-feu.

Content-Signal : dire ce que vous voulez, pas seulement qui vous bloquez

Le problème de Disallow, c'est qu'il ne dit rien de vos intentions : il ferme la porte sans expliquer pourquoi. Le standard Content Signals Policy, proposé par Cloudflare en septembre 2025, ajoute une ligne qui exprime l'usage autorisé plutôt que l'accès.

Signal	Ce qu'il régit
`search`	L'usage classique : indexer pour renvoyer vers vous
`ai-input`	L'usage en temps réel dans une réponse générée (RAG)
`ai-train`	L'entraînement et l'affinage de modèles

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no

🔎 Ce que ça vaut vraiment

Soyons clairs : ces signaux sont déclaratifs, pas contraignants. Aucun mécanisme technique ne force un crawler à les respecter. Leur valeur est juridique et politique : vous exprimez formellement une réserve d'usage, ce qui change la nature d'un passage outre.

Le coût d'écriture est de deux lignes. Le bénéfice est incertain mais non nul. C'est typiquement une décision à prendre en connaissance de cause, pas un levier de visibilité.

llms.txt : la vérité sur un standard très commenté

Le fichier llms.txt propose de fournir aux modèles une carte lisible de votre site : vos pages importantes, en texte structuré, sans navigation ni publicité. L'idée est séduisante et beaucoup de sites l'ont adopté.

⚠️ Aucun moteur ne le consomme aujourd'hui

C'est le point que la plupart des contenus sur le sujet passent sous silence. Google a confirmé publiquement ne pas l'utiliser, ni pour la recherche ni pour les surfaces génératives, et a même précisé que ce type de fichier n'a aucun effet sur le classement. Aucun des grands moteurs de réponse n'a annoncé le contraire à ce jour.

Autrement dit : c'est un pari sur l'avenir, pas un levier actuel. Le fichier coûte peu à produire et vous positionne si le standard s'impose. Mais si on vous vend une prestation "llms.txt" comme un levier de visibilité immédiat, vous savez maintenant quoi en penser.

La bonne posture : le produire si c'est peu coûteux, le tenir à jour, et ne jamais lui confier ce que votre HTML devrait déjà faire. Un llms.txt impeccable sur un site illisible pour les machines ne sert à rien.

Le piège du JavaScript

C'est le problème technique le plus fréquent, et le plus coûteux. La plupart des crawlers IA n'exécutent pas le JavaScript. Là où Googlebot sait rendre une page côté client, les agents d'OpenAI, d'Anthropic ou de Perplexity récupèrent généralement le HTML brut et s'arrêtent là.

Conséquence concrète : si votre contenu principal est injecté après le chargement, votre page est vide pour eux. Vous pouvez être premier sur Google et totalement absent des réponses IA, sans que rien dans vos rapports SEO ne le signale.

✅ Le test en dix secondes

Récupérez votre page sans exécuter de JavaScript et regardez ce qui reste :

curl -s https://votre-site.fr/votre-page | grep -c "votre phrase clé"

Si le compte est à zéro alors que la phrase s'affiche dans le navigateur, votre contenu n'existe pas pour les IA. La correction relève du rendu serveur ou du pré-rendu, pas du GEO.

Vérifier au lieu de croire

Toute cette configuration ne vaut rien sans contrôle. Les logs serveur, vus au module 5, sont votre seule preuve. Trois vérifications suffisent :

Les agents autorisés passent-ils vraiment ?

Cherchez OAI-SearchBot, Claude-SearchBot, PerplexityBot dans vos logs des 30 derniers jours. Silence total sur un agent autorisé = problème technique, pas problème de contenu.

Que reçoivent-ils comme code de réponse ?

Des 200, ou des 403, 429 et 499 ? Un agent rate-limité ou timeouté par votre serveur cesse rapidement de revenir. Beaucoup de sites bloquent involontairement les IA via leur pare-feu applicatif.

Les agents refusés respectent-ils le refus ?

Si vous avez bloqué l'entraînement, vérifiez que ces agents ont bien cessé de passer. Sinon, votre décision n'est qu'une intention et il faut passer au niveau pare-feu.

Ce qu'il faut retenir

Entraînement, index de recherche et visite à la demande sont trois usages distincts qui se décident séparément
Bloquer GPTBot ne vous sort pas des réponses de ChatGPT, et bloquer Google-Extended ne vous sort pas des AI Overviews
Content-Signal exprime une intention d'usage : déclaratif, peu coûteux, non contraignant
llms.txt n'est consommé par aucun moteur à ce jour : un pari, pas un levier
Un contenu injecté en JavaScript est invisible pour la plupart des agents IA
Une configuration non vérifiée dans les logs est une hypothèse, pas une décision

🔗 Pour aller plus loin

llms.txt : nouveau standard ou faux espoir ? - l'analyse complète du sujet
Les crawlers IA et le JavaScript - pourquoi vos pages peuvent être vides pour les IA
Le tableau de bord des bots IA de ce site - les mêmes vérifications, en conditions réelles

Votre site est désormais lisible et vos règles d'accès sont posées. Reste la question qui décide vraiment de la citation : le moteur sait-il qui vous êtes ? C'est l'objet du module suivant.