Recherche à facettes et bots IA : quand vos filtres transforment votre boutique en buffet à volonté

On nous a suggéré d’ouvrir cet article avec une boule à facettes. Une première version a été retoquée par le comité de relecture, motif : « trop petite et pas assez funky ». Voilà qui est corrigé :

Profitez-en, c’est la seule fantaisie de la page. Le reste est nettement moins festif, parce que la recherche à facettes de votre boutique en ligne est probablement en train de servir un buffet à volonté à des robots que vous n’avez pas invités, sur une infrastructure que vous payez.

Le sujet n’est pas théorique. Nous le voyons passer régulièrement en supervision chez nos clients e-commerce : un serveur qui charge sans raison apparente, des pics de requêtes SQL en pleine nuit, une bande passante qui gonfle. Et presque à chaque fois, la même signature dans les logs : des milliers d’URLs de filtres combinés, aspirées méthodiquement par des crawlers.

L’explosion combinatoire, en chiffres

La recherche à facettes, ce sont ces filtres qui bordent vos pages catégories : taille, couleur, marque, prix, matière. C’est un excellent outil pour vos visiteurs. Le problème, c’est que chaque combinaison de filtres produit une URL distincte, et qu’une URL distincte est une page crawlable.

Faisons le calcul sur un cas modeste : une page catégorie avec 4 facettes de 10 valeurs chacune, où l’on ne peut choisir qu’une valeur par facette. Chaque facette a donc 11 états possibles (10 valeurs, plus « non filtré »). Cela donne 11 × 11 × 11 × 11 = 14 641 URLs pour une seule catégorie.

Autorisez la multi-sélection au sein d’une facette, comme le font la plupart des modules, et chaque facette passe à 2¹⁰ = 1 024 états. Soit 1 024⁴, c’est-à-dire plus de mille milliards de combinaisons. Pour une catégorie. Ajoutez le tri (prix croissant, décroissant, nouveautés) et la pagination, et vous multipliez encore.

Évidemment, aucun bot ne visitera mille milliards de pages. Mais il n’en a pas besoin : il lui suffit de suivre les liens qu’il trouve, de page filtrée en page filtrée, indéfiniment. Pour un crawler, une navigation à facettes est un labyrinthe sans sortie qui génère ses propres couloirs. Un catalogue de 500 produits devient un site de plusieurs millions de pages apparentes.

Qui aspire ces millions d’URLs

Il y a encore cinq ans, la question se résumait à Googlebot, qui gère plutôt bien son budget de crawl. Le paysage a changé de nature. Aujourd’hui, trois familles de robots se servent au buffet :

Pour donner un ordre de grandeur de la lame de fond : sur datacampus.fr, qui est un simple site vitrine sans la moindre facette, nous avons mesuré au premier semestre 2026 7 567 hits du seul ChatGPT-User, contre environ 6 060 visites humaines. Le trafic des agents IA dépasse désormais le trafic humain sur un site qui n’a rien d’un aimant à bots. Nous avons détaillé la méthode de mesure dans notre guide Matomo sur le tracking des agents IA.

Maintenant, transposez cette pression sur une boutique dont chaque page catégorie expose des milliers de combinaisons de filtres. C’est là que le buffet devient un problème d’infrastructure.

Ce que ça coûte vraiment

Le trafic de facettes est le pire trafic qui soit, pour une raison précise : il contourne tous vos caches. Votre page d’accueil est en cache, vos fiches produits aussi. Mais « chaussures + rouge + 42 + moins de 80 € + tri prix croissant », personne ne l’a demandée avant le bot, et personne ne la redemandera après. Chaque hit descend jusqu’à la base de données et exécute des requêtes de filtrage parmi les plus coûteuses du site.

• Charge serveur : des pics de CPU et d’I/O base de données sans aucune visite humaine en face. Le site ralentit pour vos vrais clients, ceux qui achètent.
• Surdimensionnement : on finit par payer un serveur plus gros pour servir des robots. Nous préférons vendre de la capacité utile que de la capacité gaspillée, votre budget aussi.
• SEO : le budget de crawl de Googlebot se disperse sur des millions d’URLs filtrées quasi identiques au lieu de vos fiches produits. Contenu dupliqué, indexation ralentie des nouveautés.
• Analytics faussés : les bots les moins polis exécutent le JavaScript et polluent vos statistiques de fréquentation, donc vos décisions.
• Énergie : des cycles CPU brûlés pour rien. Chez un hébergeur qui mesure son PUE à la décimale, voir des serveurs chauffer pour alimenter des combinaisons de filtres que personne ne lira, ça agace.

Le piège PrestaShop : actif par défaut

Le détail qui nous a décidés à écrire cet article vient du terrain. En auditant la boutique d’un client avec son agence, nous avons constaté que le module « Navigation à facettes » (ps_facetedsearch) était actif alors que la boutique ne proposait aucun filtre visible. Sur une installation PrestaShop standard, ce module est livré installé et activé par défaut.

Le même symptôme existe ailleurs. Sur WooCommerce, les widgets de filtrage génèrent des URLs en ?filter_color=...&filter_size=... que les bots enfilent avec le même appétit. Sur Magento ou Shopify avec certaines apps de filtres, idem. La première question à se poser est donc brutalement simple : utilisez-vous réellement cette fonctionnalité ? Si non, désactivez le module. C’est la seule protection qui coûte zéro et couvre 100 % du problème.

Trois situations concrètes, pour vous situer

Les mécanismes décrits plus haut paraissent abstraits jusqu’au jour où on les vit. Voici trois situations types, anonymisées mais inspirées de cas réels. Si vous vous reconnaissez dans l’une d’elles, la suite de l’article vous concerne directement.

Cas n°1 — La boutique qui rame toutes les nuits

Le symptôme : une boutique de prêt-à-porter constate que son site est lent chaque matin entre 6h et 9h, en pleine reprise du trafic client. Premier suspect désigné : les sauvegardes nocturnes. À tort.

Ce qui se passe vraiment : les graphes de charge montrent des pics de requêtes SQL entre 2h et 6h du matin, sans aucune visite humaine en face. Dans les logs, un crawler déroule méthodiquement les combinaisons taille × couleur × gamme de prix, page après page. Le cache du site, chaud pour les pages réelles, est froid au réveil pour tout le reste.

Le geste utile : réduire les facettes aux filtres réellement utilisés, interdire les URLs de filtres dans robots.txt, et poser un rate limiting. La charge nocturne disparaît sans toucher au serveur.

Cas n°2 — L’annonce immobilière invisible

Le symptôme : une agence immobilière publie ses nouvelles annonces et met plusieurs jours à les voir apparaître sur Google, quand un concurrent y figure en quelques heures.

Ce qui se passe vraiment : le moteur de recherche interne croise ville × budget × surface × nombre de pièces. Googlebot dépense l’essentiel de son budget de crawl à explorer des dizaines de milliers de pages de résultats filtrés quasi identiques, et n’arrive que tardivement aux vraies fiches d’annonces.

Le geste utile : un sitemap limité aux annonces et aux pages canoniques, et un balisage cohérent des pages de recherche filtrées. Le budget de crawl se reconcentre sur ce qui fait vendre.

Cas n°3 — Le catalogue aspiré par la concurrence

Le symptôme : un vendeur de pièces détachées remarque qu’un concurrent affiche systématiquement des prix légèrement inférieurs aux siens, quelques heures après chacune de ses mises à jour tarifaires.

Ce qui se passe vraiment : un outil de veille tarifaire parcourt le catalogue via les facettes, qui offrent un moyen commode d’énumérer tout le stock par marque et par gamme. User-agent de navigateur classique, adresses IP tournantes : rien ne le distingue d’un visiteur, sauf son comportement.

Le geste utile : rate limiting, détection comportementale (CrowdSec) et filtrage en bordure. Soyons honnêtes : contre un scraper déterminé, on ne bloque jamais tout. L’objectif réaliste est de rendre l’aspiration lente, coûteuse et incomplète, au lieu de gratuite et instantanée.

Les fausses bonnes idées : captcha et CSRF

Quand ce sujet arrive en réunion, deux protections sont généralement proposées avec enthousiasme : le captcha et les jetons CSRF. Les deux sont d’excellents outils. Pour d’autres problèmes.

• Le jeton CSRF protège des actions, pas des lectures. Il empêche un site tiers de faire exécuter un formulaire à l’insu d’un utilisateur connecté : changement de mot de passe, validation de commande. Or le scraping de facettes ne soumet rien : il fait des GET sur des pages publiques. Le jeton ne le gêne pas une seconde.
• Le captcha sur de la navigation publique est un fusil à deux coups… dans votre pied. Premier coup : vous dégradez l’expérience de vos vrais clients, qui détestent prouver leur humanité pour consulter des chaussures. Deuxième coup : vous bloquez aussi Googlebot, et votre référencement avec. Un captcha se justifie sur un formulaire sensible, pas sur un catalogue.

La confusion vient d’un malentendu sur la nature du problème. Le scraping de facettes n’est pas une attaque au sens classique : c’est de la consommation abusive d’un contenu volontairement public. On ne le traite donc pas avec des outils d’authentification, mais avec des outils de gestion de trafic.

Fermer le buffet : la défense en couches

Aucune mesure ne suffit seule. Ce qui fonctionne, c’est l’empilement, du moins coûteux au plus musclé.

1. Réduire la surface

Désactivez ce qui ne sert pas : le module de facettes si vos visiteurs ne filtrent pas, les facettes inutiles si trois filtres suffisent, la pagination profonde au-delà de ce qu’un humain consulte. Chaque combinaison supprimée est une infinité d’URLs en moins.

2. Baliser pour les bots polis

Pour les crawlers qui respectent les règles, dites clairement où ne pas aller :

• robots.txt : interdire les motifs d’URLs de filtres (Disallow: /*?filter_, Disallow: /*selected_filters= selon votre CMS). C’est le levier qui économise réellement le crawl, donc votre serveur.
• Pour l’indexation, choisissez un seul signal : un canonical vers la page catégorie non filtrée, ou un meta robots noindex, mais pas les deux à la fois. Google recommande explicitement de ne pas mélanger ces deux directives, qui se contredisent. Et attention à la cohérence : un noindex posé sur une URL déjà bloquée en robots.txt ne sera jamais lu, puisque le robot n’a plus le droit de venir le voir.
• Sitemap propre : uniquement les URLs canoniques, jamais les combinaisons de filtres.
• Pour les crawlers IA d’entraînement, des directives dédiées dans robots.txt (GPTBot, CCBot, ClaudeBot…) selon votre politique : certains e-commerçants veulent être cités par les assistants IA, d’autres non. C’est un choix éditorial avant d’être technique.

3. Contenir les bots impolis

Pour ceux qui ignorent robots.txt, on passe aux mesures actives, côté serveur web ou en amont :

• Rate limiting : limit_req sur Nginx, mod_security ou mod_evasive sur Apache. Une IP qui demande 40 pages de filtres par seconde n’est pas un client pressé.
• CrowdSec ou fail2ban : détection comportementale et bannissement automatique, avec l’avantage pour CrowdSec de mutualiser les signalements entre sites.
• Filtrage en bordure : les protections anti-bot d’un reverse proxy ou d’un CDN, qui identifient les crawlers IA et les scrapers avant même qu’ils touchent votre serveur.

4. Amortir ce qui passe quand même

Un cache pleine page bien réglé transforme une partie des hits de facettes en réponses servies sans toucher PHP ni la base. On ne supprime pas le trafic, on divise son coût.

5. Mesurer, sinon rien de tout cela ne tient

Impossible de régler ce qu’on ne voit pas. Analyse des logs serveur, suivi des user-agents, tableau de bord des bots dans Matomo : notre guide complet BotTracking détaille la mise en place. C’est cette mesure qui vous dira si le buffet est fermé ou si quelqu’un est encore en train de se resservir.

Ce que nous faisons côté infogérance

Pour nos clients infogérés et les boutiques hébergées via nos agences partenaires, ce sujet fait partie de la supervision de base : nous surveillons la charge et les motifs de trafic, nous alertons quand un crawler se met à table, et nous appliquons les couches de protection adaptées à chaque stack. Le cas du module PrestaShop actif pour rien fait désormais partie de notre check-list d’audit à l’arrivée d’une boutique.

Si votre serveur charge sans que vos ventes ne suivent, c’est un symptôme qui mérite dix minutes de logs. Parlons-en.

TL;DR, ce qu’il faut retenir

• Chaque combinaison de filtres est une URL crawlable : 4 facettes de 10 valeurs suffisent à créer 14 641 pages par catégorie, des milliards avec la multi-sélection.
• Ce trafic contourne les caches et frappe directement la base de données : c’est le pire trafic possible.
• Le trafic des bots et agents IA dépasse désormais le trafic humain sur beaucoup de sites, y compris le nôtre.
• Sur PrestaShop, le module de navigation à facettes est actif par défaut, même si la boutique ne s’en sert pas. Vérifiez.
• Captcha et CSRF ne protègent pas contre le scraping de pages publiques. Les vrais leviers : réduire la surface, baliser (robots.txt, puis canonical ou noindex), limiter la cadence, filtrer en bordure, mettre en cache, mesurer.

FAQ — Recherche à facettes et bots

Pour aller plus loin :
• Sur datacampus.fr : Tracker les agents IA et crawlers avec Matomo · Protection DDoS : Magic Transit et RPKI · Migrer WordPress vers un VPS · Notre offre d’infogérance