Ce que le pare-feu cache à vos logs : l'angle mort des blocages en edge

Un responsable de site ouvre ses logs, cherche GPTBot, ClaudeBot ou PerplexityBot, ne trouve rien, et conclut que les IA ne s'intéressent pas à son contenu. La conclusion est souvent fausse, et pour une raison mécanique : quand un pare-feu ou un CDN refuse une requête, celle-ci s'arrête à la périphérie du réseau, en edge, et n'atteint jamais le serveur d'origine. Elle n'existe donc dans aucun log d'origine. Le silence des logs ne signifie pas l'absence des robots ; il peut signifier exactement l'inverse.

Comment une requête peut disparaître

Sur un site servi derrière un CDN comme Cloudflare, chaque requête traverse plusieurs couches avant d'arriver au serveur. Le pare-feu applicatif, décrit dans la documentation du WAF de Cloudflare, évalue des règles et peut bloquer, rediriger ou afficher un challenge. Un module de gestion des robots, détaillé dans la documentation Bots, classe le trafic automatisé et lui applique une politique. Depuis 2024, ces plateformes proposent de bloquer les robots d'IA en un clic, comme l'annonçait Cloudflare dans son billet sur le blocage des robots d'IA, et beaucoup de sites ont activé l'option sans mesurer ce qu'elle faisait.

Toute requête arrêtée à ce niveau reçoit une réponse fabriquée par le CDN, en général un code 403 ou une page de challenge. Le serveur d'origine n'en voit rien. Les logs Apache, nginx ou applicatifs ne la contiennent pas, et un outil d'analyse de logs qui ne lit que l'origine ne peut pas la compter.

Les trois erreurs de raisonnement que cela produit

1. « Aucune IA ne vient chez nous. » C'est la plus courante. Le site est en réalité visité, mais chaque visite est refusée en amont. Une règle activée par précaution, parfois par un prestataire, parfois par une case cochée dans une interface, coupe silencieusement toute possibilité d'être cité.
2. « Notre taux de succès de crawl est de 100 %. » Un tableau de bord qui compte les réponses 200 servies par l'origine affiche un score parfait, puisque seules les requêtes acceptées y arrivent. Le taux réel, blocages compris, peut être très bas.
3. « Le robot ne respecte pas notre robots.txt. » Si le robots.txt lui-même est servi par l'origine mais que la première requête du robot est bloquée en edge, il ne l'a jamais lu. On accuse le robot d'un comportement dont la cause est locale.

Comment vérifier ce qui se passe en edge

Les contrôles, du plus simple au plus complet :

• Relire la configuration du CDN. Règles WAF, mode de gestion des robots, options « bloquer les robots d'IA », listes d'user-agents refusés. Il faut la lire telle qu'elle est, pas telle qu'on croit l'avoir réglée : sur un site que nous avons audité cet été, une règle de blocage héritée d'une configuration précédente coupait des robots que personne dans l'équipe ne pensait bloquer.
• Tester avec les vrais user-agents. Envoyer soi-même une requête vers une page publique en déclarant le user-agent de chaque robot d'IA, depuis l'extérieur du réseau, et regarder le code de réponse et son émetteur. Un 403 signé par le CDN alors que l'origine répond 200 est la preuve directe du blocage en edge.
• Lire les logs du CDN, pas seulement ceux de l'origine. Les grands CDN exposent des statistiques de trafic qui incluent les requêtes refusées, par règle et par user-agent, et parfois par chemin. C'est là que se voient les robots qu'on croyait absents. Sur Cloudflare, ces données sont accessibles par l'interface et par API avec un jeton disposant du droit de lecture Zone Analytics ; sur une offre gratuite, la ventilation par chemin exige de passer par l'API.

Un cas mesuré

Sur un autre site, industriel, audité le même été, les logs d'origine ne montraient aucune requête d'un robot d'IA sur plusieurs semaines, et le tableau de bord de crawl affichait un taux de succès parfait. Les logs du CDN racontaient autre chose : plusieurs centaines de requêtes de robots d'IA refusées en 403 par une règle de pare-feu, dont personne n'avait la trace. La conclusion initiale, « les IA ne viennent pas », était l'exact inverse de la réalité : elles venaient, régulièrement, et repartaient sans rien lire. Le site n'apparaissait dans aucune réponse générée, non par manque d'intérêt des moteurs, mais par un réglage de sécurité. Le diagnostic a pris une heure ; il aurait pu ne jamais être fait.

Le piège de l'adresse IP

Un second effet du CDN complique la lecture des logs d'origine : l'adresse IP que voit le serveur est celle du CDN, pas celle du visiteur, sauf si le serveur est configuré pour lire l'en-tête qui transporte l'adresse d'origine. Quand ce réglage manque, tous les visiteurs, humains et robots, semblent venir de quelques dizaines d'adresses appartenant au CDN. Les vérifications d'authenticité décrites dans notre article sur le reverse DNS et les plages d'IP deviennent impossibles, et un robot authentique peut être pris pour un imposteur, ou l'inverse. Un en-tête propriétaire ajouté par le CDN survit en général à tous les sauts intermédiaires là où un en-tête générique peut être écrasé. Chez Cloudflare, c'est CF-Connecting-IP ; l'en-tête générique, X-Forwarded-For, peut être réécrit par n'importe quel intermédiaire. Demandez à votre hébergeur le nom exact de celui qu'il ajoute, et vérifiez qu'il arrive bien jusqu'au journal de l'origine.

Quelle politique tenir

La question de fond est éditoriale : un média qui veut être cité par les IA n'a aucune raison de bloquer leurs robots de recherche et de lecture en edge. Bloquer l'entraînement est une décision légitime, mais elle se prend dans le robots.txt, user-agent par user-agent, comme nous l'expliquons dans « robots.txt et IA », pas par un interrupteur qui refuse tout ce qui ressemble à une IA. Un blocage en edge n'a de sens que pour du trafic abusif avéré : volumes anormaux, usurpation d'identité, aspirateurs qui ignorent le robots.txt.

Il y a une précaution à garder : ne pas bloquer non plus les usurpateurs par une règle large sur le user-agent. Une règle qui refuse tout « GPTBot » venant d'une adresse hors des plages publiées par OpenAI semble prudente ; en pratique, elle refuse aussi les requêtes légitimes le jour où OpenAI ajoute une plage que la liste locale n'a pas encore. La bonne réponse à l'usurpation est la mesure et le ralentissement, pas le refus aveugle.

Ce que mesurer veut dire, une fois le blocage levé

Quand l'edge laisse passer, les logs d'origine redeviennent une source fiable, à condition de transporter l'adresse d'origine et de conserver le user-agent complet. On peut alors compter, par robot et par usage (entraînement, recherche, lecture à la demande), ce que les IA lisent réellement : quelles pages, à quelle fréquence, avec quel code de réponse. C'est cette lecture, et non un tableau de bord d'origine, qui permet d'affirmer qu'un contenu est atteint par les moteurs génératifs. Nous détaillons la méthode dans « Lire un access log en 30 minutes ».

Le principe est là : un log d'origine ne prouve que ce qui est arrivé jusqu'à l'origine. Tout ce qui a été refusé avant n'y laisse aucune trace, et c'est précisément ce qu'il faut aller chercher ailleurs avant de conclure quoi que ce soit sur les IA.