Cloudflare, WAF et pare-feu anti-bots : les blocages involontaires qui vous effacent des IA.

Le blocage involontaire, première cause d'absence sur des sites bien référencés

Dans nos audits, quand un site bien positionné sur Google n'apparaît dans aucune réponse de ChatGPT, de Claude ou de Perplexity, la cause la plus fréquente n'est ni le contenu ni le robots.txt. C'est une couche de protection, placée entre le robot et le serveur, qui traite les robots de recherche IA comme des menaces. Le robots.txt dit « bienvenue », le pare-feu dit « non », et c'est le pare-feu qui a le dernier mot, parce qu'il répond avant que la page ne soit servie.

Ces protections ne sont pas absurdes. Les robots IA ont généré, depuis 2023, un volume de requêtes que beaucoup de sites n'avaient pas anticipé, des extracteurs anonymes se font passer pour eux, et les fournisseurs de CDN ont répondu par des outils simples : une case à cocher, un mode de défi, une règle de débit. Le problème est que ces outils ont d'abord traité « les robots IA » comme une catégorie unique, alors que les quatre conditions d'une citation décrites dans notre méthode pour être cité commencent par l'accès des robots de recherche, et non des robots d'entraînement. Les interfaces se sont affinées depuis, mais les réglages pris à l'époque restent en place.

Trois mécanismes, trois symptômes

Les blocages involontaires se ramènent à trois mécanismes. Chacun laisse une trace différente dans les journaux et dans la réponse HTTP, ce qui permet de les distinguer sans accès à la configuration.

Le premier mécanisme est le plus répandu, parce qu'il est le plus simple à activer. Cloudflare a proposé dès 2024 un blocage en un clic des robots d'IA et, d'après ses annonces de 2025, l'applique par défaut aux nouveaux domaines, avec depuis un contrôle robot par robot qui classe les agents selon leur finalité. Les autres fournisseurs, comme AWS, Akamai, Fastly ou Vercel, proposent des règles gérées comparables. Le réglage n'est donc pas une erreur en soi ; il le devient quand il englobe OAI-SearchBot, Claude-SearchBot et PerplexityBot avec les robots d'entraînement, ou quand il a été fait avant que l'interface ne permette de les distinguer.

Le deuxième mécanisme est le plus sournois. Un défi géré est conçu pour laisser passer les humains sans les déranger et pour arrêter les automates ; il exige l'exécution de JavaScript. Les robots de recherche IA n'en exécutent pas, comme l'explique notre article sur le rendu JavaScript. Ils reçoivent donc la page de défi à la place du contenu, souvent avec un code 403, parfois avec un 200 trompeur. Le troisième mécanisme, la limitation de débit, ne bloque pas le site mais le rend inexplorable : le robot lit vingt pages, reçoit des 429, et passe à un autre site.

Diagnostiquer en une heure

Le diagnostic commence par les journaux, parce qu'ils montrent ce qui s'est réellement passé, et non ce que la configuration laisse supposer. Il continue par des requêtes de test, qui reproduisent la chaîne User-Agent d'un robot et lisent la réponse. Il se termine dans la configuration, quand on sait ce que l'on cherche.

Tableau : faites défiler horizontalement.

Dans les journaux du serveur ou dans le journal des événements de sécurité du CDN, filtrez sur les agents de recherche IA et regardez la répartition des codes de réponse sur trente jours. Un agent absent des journaux d'origine mais présent dans les événements du CDN est bloqué à la bordure ; un agent absent des deux n'a jamais atteint le site, ou ne l'a jamais découvert. Les requêtes de test complètent cette lecture : la commande ci-dessous affiche les en-têtes de réponse, où se lit la signature d'un défi.

# En-têtes de réponse pour un robot de recherche IA
curl -s -D - -o /dev/null \
  -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot" \
  https://www.exemple.fr/guide/

# Ce que l'on cherche dans la sortie :
HTTP/2 403
cf-mitigated: challenge        # défi Cloudflare : le robot ne passera pas
server: cloudflare
cf-ray: 8c1f…-CDG              # identifiant à donner au support

Une précaution d'interprétation : vos tests partent de votre adresse IP, pas de celles des éditeurs. Une règle fondée sur la réputation de l'adresse, sur sa géographie ou sur le statut de robot vérifié ne se reproduit pas depuis un poste de travail. Un test qui passe ne prouve donc pas que le robot passe ; un test qui échoue, lui, désigne à coup sûr une règle fondée sur la chaîne d'agent. Le juge de paix reste le journal, dont l'exploitation détaillée fait l'objet de notre article sur les logs serveur.

Corriger sans ouvrir la porte à tous

La correction ne consiste pas à désactiver la protection, mais à la rendre discriminante. Le principe : les robots de recherche IA authentifiés passent sans défi ni limite, les robots d'entraînement suivent la politique exprimée dans le robots.txt, et tout le reste du trafic automatisé reste soumis aux règles existantes. Trois réglages y suffisent dans la plupart des CDN.

• Une règle d'exemption placée avant les règles de blocage. Elle reconnaît les agents de recherche IA voulus et les fait sauter les règles gérées, le défi et la limitation de débit. L'ordre compte : une exemption placée après un blocage ne s'applique jamais.
• L'authentification par le statut de robot vérifié. Les grands CDN tiennent un annuaire de robots dont ils vérifient l'origine ; celui de Cloudflare recense les agents d'OpenAI, d'Anthropic et de Perplexity. Conditionner l'exemption à ce statut, et non à la seule chaîne d'agent, ferme la porte aux imitateurs.
• Le contrôle robot par robot, quand il existe. Là où l'interface classe les agents par finalité, la bonne configuration se lit en une ligne : entraînement selon votre politique, recherche et consultation à la demande autorisées.

# Cloudflare, règle WAF personnalisée, placée en premier
# Action : ignorer (règles gérées, défi, limitation de débit)
(cf.client.bot and http.user_agent contains "OAI-SearchBot")
or (cf.client.bot and http.user_agent contains "Claude-SearchBot")
or (cf.client.bot and http.user_agent contains "PerplexityBot")
or (cf.client.bot and http.user_agent contains "ChatGPT-User")
or (cf.client.bot and http.user_agent contains "Perplexity-User")

# Nginx, sans CDN : aucune limitation de débit pour ces agents
# (une clé vide exclut la requête de la zone)
map $http_user_agent $limite_cle {
    default              $binary_remote_addr;
    ~OAI-SearchBot       "";
    ~Claude-SearchBot    "";
    ~PerplexityBot       "";
}
limit_req_zone $limite_cle zone=generale:10m rate=10r/s;

Le champ cf.client.bot de l'exemple est vrai quand Cloudflare a vérifié l'origine de la requête ; la condition sur la chaîne d'agent précise ensuite lesquels des robots vérifiés sont concernés. Sans CDN, l'équivalent consiste à combiner la chaîne d'agent avec les plages d'adresses que publient OpenAI, Perplexity, Google et Microsoft, faute de quoi l'exemption par chaîne seule devient une porte ouverte aux extracteurs qui l'imitent. Dans ce cas, mieux vaut une exemption limitée à la limitation de débit, qui coûte peu si elle est abusée, qu'une exemption totale.

Les couches que l'on oublie : hébergeur, CMS, géoblocage

Le CDN n'est pas la seule couche. Un site sans Cloudflare peut être tout aussi fermé par des règles plus anciennes, écrites pour d'autres menaces et jamais relues. Les cas suivants reviennent dans nos audits, souvent cumulés.

• Une règle .htaccess qui refuse tout agent contenant « bot », écrite contre les extracteurs il y a des années ; elle bloque OAI-SearchBot, PerplexityBot et, à l'occasion, Googlebot.
• Un module de sécurité du CMS réglé pour bloquer les « faux robots » ou pour limiter les requêtes par adresse, avec des seuils pensés pour des visiteurs humains.
• Un jeu de règles de pare-feu applicatif qui refuse les clients HTTP sans en-têtes de navigateur complets, alors que les robots n'envoient ni cookies ni en-têtes d'acceptation de langue.
• Un blocage géographique qui n'admet que le trafic européen : les adresses publiées par les éditeurs de moteurs sont, pour l'essentiel, situées aux États-Unis au moment où nous écrivons.
• Une protection contre les attaques par déni de service laissée en mode élevé après un incident, qui impose un défi à toute requête non reconnue.
• Une bannière de consentement rendue côté serveur, qui remplace le contenu par une demande d'accord tant qu'aucun cookie n'est présent.

Chacune de ces couches se teste de la même manière : la requête avec chaîne d'agent, la lecture du code de réponse et de la taille, puis les journaux. La difficulté n'est pas technique, elle est organisationnelle : l'hébergeur, l'agence web, le prestataire de sécurité et le service marketing ne se parlent pas, et personne n'a la vue complète de la chaîne. L'inventaire des couches, de la bordure jusqu'au CMS, est le premier livrable d'un audit d'accès.

Bloquer volontairement, mais au bon endroit

Rien n'interdit de refuser certains robots ; ce qui coûte, c'est de le faire au mauvais endroit et avec le mauvais périmètre. La répartition que nous recommandons est simple. Le robots.txt exprime la politique envers les robots déclarés, qui le respectent : c'est là que se décide le sort de GPTBot, de ClaudeBot ou de Google-Extended, selon la stratégie décrite dans notre article sur le robots.txt en deux niveaux. Le pare-feu s'occupe de ce que le robots.txt ne peut pas régler : les extracteurs anonymes, les imitateurs, les rafales anormales. Chaque outil fait ce pour quoi il est conçu, et les journaux restent lisibles.

Le cas des robots d'entraînement mérite une précision. Si votre politique les refuse, le robots.txt suffit pour les éditeurs qui le respectent, et le pare-feu n'a pas à s'en mêler ; les bloquer aussi au CDN ne fait que brouiller les journaux, et n'arrête pas davantage les imitateurs, qui ne portent pas ces noms. Si votre politique les autorise, le pare-feu ne doit pas les contredire. Dans les deux cas, la règle du CDN qui « bloque les robots IA » en bloc n'a plus de raison d'être.

Vérifier, puis surveiller

Un correctif se valide dans les journaux, pas dans l'interface. Après modification des règles, les robots de recherche IA doivent réapparaître dans les journaux d'origine avec des réponses 200 de taille normale, en général sous quelques jours ; s'ils ne reviennent pas, une autre couche les arrête, ou ils n'ont pas de raison de revenir parce que le site ne leur a jamais été présenté. Quelques semaines plus tard, la part de citation sur le panel de questions doit bouger, moteur par moteur.

La surveillance est ensuite hebdomadaire, parce que les réglages changent sans prévenir : un collègue active un mode de protection après une alerte, le fournisseur de CDN modifie un comportement par défaut, un module du CMS se met à jour avec de nouvelles options cochées. Deux indicateurs suffisent : la part de réponses autres que 200 servies à chaque agent de recherche IA, et le nombre de pages distinctes qu'il a lues. Une hausse des 403 ou des 429, ou une chute brutale du nombre de pages, déclenche le diagnostic décrit plus haut. Une règle d'exemption documentée, avec sa raison et son auteur, évite qu'elle ne soit supprimée au prochain nettoyage.

Ce qu'il faut retenir