Robots IA : que bloquer dans votre WAF sans rendre le site invisible ?

Le même blocage peut protéger un compte et masquer une fiche produit

Le marketing souhaite que les assistants lisent le catalogue. L’équipe sécurité observe des accès automatisés au compte client. Une règle générale « laisser passer les agents IA » ne répond à aucun des deux besoins : elle mélange lecture publique et action authentifiée. Une règle « bloquer toute IA » peut aussi empêcher un usage souhaité. Commencez par nommer les ressources concernées.

Dans votre cartographie, séparez les pages publiques, la recherche interne, les API de prix, la connexion, le panier et le paiement. Pour chacune, indiquez la donnée exposée, le coût de traitement et l’effet d’une requête. Le même robot peut être toléré sur une page publique et refusé sur une route privée. Le droit d’indexer un catalogue n’autorise pas à tester des identifiants.

Avant d’autoriser un robot déclaré comme moteur de recherche, vérifiez qu’il s’agit réellement de Googlebot : le nom envoyé dans le user-agent ne suffit pas.

Les agents atteignent aussi les pages de connexion

Dans sa synthèse 2026, DataDome rapporte 52,7 milliards de requêtes d’agents IA et de crawlers LLM sur douze mois, pour sa clientèle. Les requêtes IA vers les pages de connexion passent de 11,9 millions en janvier à 99,7 millions en juin 2026. Ce sont des volumes sur un périmètre fournisseur, pas une part de tout Internet. (DataDome, 2026)

Le rapport combine une télémétrie de plus de 75 000 sites clients et un test distinct de plus de 20 000 sites. Ne mélangez pas ces populations. Une requête classée IA sur une connexion ne prouve pas à elle seule une attaque ; le constat justifie d’examiner les actions demandées et les protections applicables. Les données brutes n’ont pas été auditées par TalkWeb.

Lire une page publique et agir sur un compte appellent des contrôles différents

Saltzer et Schroeder fondent la sécurité sur des autorisations limitées et contrôlées. AgentDojo étudie des agents exposés à des contenus hostiles ; ce benchmark ne mesure ni les performances d’un WAF ni la part de trafic malveillant de votre site. Il ajoute néanmoins une distinction utile : un système qui lit une page et un système qui exécute une action n’ont pas le même périmètre de risque. (Jerome H. Saltzer et al., 1975)(Edoardo Debenedetti et al., 2024)

Séparez les règles d’accès aux contenus publics des opérations authentifiées. Pour chaque exception demandée par le marketing, précisez les routes nécessaires et le comportement attendu. Pour les actions, maintenez les contrôles serveur indépendamment de l’identité annoncée de l’agent. Examinez les faux positifs avec des traces vérifiables avant d’ouvrir ou de fermer une famille entière de robots.

Classer les robots selon leur fonction, puis vérifier leur identité

Notre typologie opérationnelle distingue l’indexeur de recherche, le collecteur de corpus, le robot qui récupère une page pour répondre à une question et l’agent qui tente une action au nom d’un utilisateur. Ajoutez les automates légitimes que vous exploitez vous-même, comme une supervision. Les attaques peuvent imiter chacune de ces catégories ; une étiquette n’est donc jamais un droit d’accès.

Pour les robots Google, la documentation prévoit une vérification par plages IP publiées ou par résolution DNS inverse puis directe. Contrôler seulement une chaîne de user-agent laisse passer une usurpation triviale. Utilisez les mécanismes de vérification propres au fournisseur et maintenez-les à jour ; ne généralisez pas la procédure Google à un opérateur qui ne publie pas les mêmes signaux. Documentation de l’outil ↗

robots.txt exprime une politique de collecte pour les robots qui la respectent ; ce n’est pas un contrôle d’accès à des données confidentielles. Ces dernières doivent être protégées par l’application. Le WAF complète ce contrôle, mais ne décide pas à la place du serveur quel client peut lire quel devis.

Tester une règle DataDome sur un périmètre que le SEO peut vérifier

Avant de changer une politique dans DataDome ou un autre WAF, exportez les décisions utiles : catégorie détectée, route, réponse servie, action du filtre et motif. Les fonctionnalités exactes dépendent de votre configuration ; vérifiez la documentation et les possibilités de votre contrat. L’objectif n’est pas d’ouvrir une exception générale à un nom de robot, mais de comprendre ce qui est réellement refusé.

Préparez une liste de pages publiques à préserver avec le SEO et une liste de parcours sensibles avec la sécurité. Testez la règle sur un périmètre limité ; utilisez une observation sans blocage si votre outil le permet et si le risque est acceptable. Comparez les requêtes réellement reçues, les erreurs et les challenges. Un test effectué depuis le poste du SEO ne reproduit pas nécessairement le traitement d’un robot.

Conservez une version de la règle et une condition de retour arrière : perte d’accès d’un indexeur vérifié, augmentation d’erreurs sur un parcours client ou hausse d’abus. Si une route de recherche est trop coûteuse, limiter la pagination ou mettre en cache peut être plus pertinent que transformer chaque requête en épreuve anti-bot.

Traiter un faux positif sans créer une porte ouverte

Exemple fictif : après une modification du WAF, un robot vérifié reçoit un challenge sur des fiches produit. Le SEO observe une baisse de lecture ; la sécurité craint une collecte massive. Ne retirez pas la protection sur tout le domaine. Vérifiez d’abord les décisions du filtre sur les routes concernées, la cadence et la réalité de l’identité. Puis testez une exception limitée à la lecture publique, avec quota et journalisation.

Le compte rendu distingue l’accès autorisé de l’effet de visibilité. Le fait que le robot reçoive de nouveau une page ne prouve pas qu’elle sera citée demain. Le premier contrôle appartient à l’exploitation ; le second relève du suivi éditorial et SEO, sur un horizon différent. Cette séparation évite de refermer une exception utile simplement parce que le marketing n’observe pas immédiatement une vente.

À l’inverse, si les erreurs de connexion augmentent sur un parcours agentique autorisé, l’équipe produit examine les reprises, les expirations de session et les messages d’erreur. Elle ne demande pas automatiquement la suppression du filtre. Un agent qui relance sans fin une opération invalide peut produire une charge abusive sans intention malveillante ; le système doit limiter cet effet et donner une issue compréhensible.

Sécurité et visibilité ont besoin de deux lectures du résultat

Le marketing suit l’accessibilité des pages utiles, la présence des contenus et les visites identifiables. La sécurité suit les tentatives, les actions refusées et les incidents réellement confirmés. Ne calculez pas un taux de conversion à partir de toutes les requêtes IA : un crawler peut lire une page sans correspondre à une session humaine ou à un achat.

Organisez une revue commune après chaque changement important. Une demande de déblocage doit préciser la finalité, les chemins et les preuves d’identité ; un refus doit expliquer le risque concret et l’alternative possible. C’est cette précision qui évite le débat stérile entre « tout ouvrir pour le GEO » et « tout fermer pour la sécurité ».

Pour les agents capables d’agir, exposez des opérations limitées et conservez les autorisations côté serveur. Une politique anti-bot et un contrat d’outil agentique sont complémentaires : la première gère l’accès et les abus, le second définit ce que l’application accepte de faire.

Autoriser l’accès à un agent ne suffit pas à lui donner des droits d’action. Un simulateur peut exposer des opérations WebMCP avec des autorisations distinctes.

Documentation & terrain

Les limites de cette analyse

• Échantillon fournisseur, pas tout Internet.
• Classification et données brutes non auditées.

Sources et résultats utilisés dans cet article

Les passages et le périmètre de lecture sont consultables ci-dessous. L’accès à un texte intégral ne signifie pas que chaque résultat a été audité.