Visitor Control : bloquer les mauvais bots et le trafic indésirable

Ouvrez le back-office de votre boutique PrestaShop, allez dans Statistiques → Visiteurs en ligne lors d’un après-midi calme, et vous verrez peut-être plus de « visiteurs » que de vrais clients. Une part importante du trafic de n’importe quelle boutique est automatisée, robots d’exploration, scrapers, scripts et sondes qui n’ont aucune intention d’acheter quoi que ce soit. Une partie de cette automatisation est vitale pour votre activité : Googlebot doit explorer votre site pour vous faire apparaître dans les résultats. Le reste vous coûte de l’argent. Il consomme du CPU et de la bande passante sur votre hébergement, remplit vos tables de paniers de déchets, fausse tous vos chiffres de conversion et, dans le cas des attaques par bourrage d’identifiants et des scanners de vulnérabilités, constitue la première étape d’une véritable attaque. Ce guide explique comment distinguer ces deux populations sur une boutique PrestaShop, repérer la mauvaise dans vos propres journaux et votre base de données, puis l’écarter sans bloquer accidentellement Google ni un vrai client.

C’est le chapitre bots et automatisation de notre dossier sécurité. Il reste volontairement dans son périmètre : le blocage par IP des fauteurs de troubles humains est traité dans Customer Extra Info and IP Bans ; l’arrêt du spam de formulaires avec un défi est expliqué dans reCAPTCHA for PrestaShop ; la surcharge spécifique de la recherche à facettes provoquée par les robots d’exploration a son analyse dédiée dans survivre au déluge de ?q= ; et les règles du serveur web se trouvent dans les règles de sécurité PrestaShop pour .htaccess. Pour replacer le filtrage des bots dans une vue d’ensemble, commencez par la checklist complète de durcissement de la sécurité.

Relu en juin 2026 au regard du comportement actuel des Statistiques PrestaShop et du Gestionnaire SQL, ainsi que des recommandations toujours en vigueur pour vérifier Googlebot par DNS inverse.

Tous les bots ne sont pas des ennemis, et bloquer les mauvais vous pénalise

L’erreur la plus coûteuse que commettent les marchands avec le blocage des bots, c’est d’en faire trop. Bannissez Googlebot dans un élan de « stop aux bots » et vous n’obtenez pas une boutique plus sûre, vous obtenez une boutique qui disparaît des résultats de recherche. La première tâche consiste donc à établir une taxonomie claire, car vos règles de blocage traiteront ces deux groupes de manière opposée.

Remarquez la conséquence : un outil brutal qui bloque les « bots » sur la seule base de leur réputation est dangereux, car les bons et les mauvais utilisent souvent les mêmes techniques. Un filtrage efficace repose sur l’identité et le comportement, pas sur un simple interrupteur marche/arrêt.

Repérer le trafic de mauvais bots dans PrestaShop, concrètement

Vous n’avez pas besoin d’un tableau de bord tiers pour voir le problème, PrestaShop enregistre déjà l’essentiel, et votre hébergement consigne le reste. Voici les trois endroits à regarder, par ordre d’effort.

1. Les statistiques du back-office (la vérification en deux minutes)

Dans Statistiques, les panneaux Origine des visiteurs, Pages introuvables et Pages les plus vues sont des signaux discrets mais révélateurs. Une avalanche de 404 sur des chemins que votre boutique n’a jamais eus (/wp-login.php, /.env, /administrator/) indique un scanner de vulnérabilités qui déroule une liste générique d’exploits. Ce ne sont même pas des chemins PrestaShop, et c’est précisément ce qui montre qu’il s’agit d’un bot indiscriminé. Une « page la plus vue » qui devient soudain votre page de connexion ou de récupération de mot de passe, plutôt qu’un produit, est une signature de bourrage d’identifiants.

2. La base de données (les chiffres honnêtes)

PrestaShop journalise les sessions dans ps_connections et ps_guest. Notez que ps_guest stocke des attributs analysés du navigateur et de l’OS (navigateur, version, système d’exploitation, résolution d’écran), et non la chaîne User-Agent brute, il n’existe pas de colonne http_user_agent dans PrestaShop standard, donc ne vous attendez pas à lire l’agent littéral depuis la base de données. Ce que ces tables vous donnent en revanche, c’est le volume de requêtes par IP, ce qui suffit à faire remonter une source qui martèle la boutique. Une requête comme celle ci-dessous (exécutez-la dans Paramètres avancés → Gestionnaire SQL, en adaptant le préfixe) classe les visiteurs récents par nombre de hits :

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

Une seule IP avec des centaines de hits dans la même journée n’est pas un client. Un vrai acheteur charge quelques pages ; un scraper parcourt tout votre catalogue dans l’ordre. Pour voir le User-Agent réellement envoyé par chaque IP, là où les scrapers se trahissent avec des agents vides, génériques ou typiques de scripts, lisez le journal d’accès brut du serveur (voir plus bas) ou utilisez un module qui enregistre le User-Agent brut, puisque les tables natives de PrestaShop ne le conservent pas mot pour mot.

3. Les tables de paniers (l’indice typiquement PrestaShop)

Voici un symptôme presque propre à PrestaShop, qui déroute des milliers de marchands : des dizaines de paniers abandonnés sans client et sans produit, visibles dans Commandes → Paniers. PrestaShop crée une ligne de panier via ses flux de panier et de session dès qu’un point d’entrée d’ajout au panier est sollicité. Les paniers invités vides peuvent être générés par plusieurs choses, bots et robots d’exploration, modules qui précréent des paniers, ou comportement normal de session, donc ne supposez pas qu’un robot précis en est responsable. Confirmez dans vos journaux quelle source a réellement touché le point d’entrée avant d’accuser, de bloquer ou de mettre en liste blanche un robot particulier. Les paniers sont de vraies lignes de base de données, mais dans ces cas-là ce sont des artefacts, pas des ventes perdues, et la solution consiste à les reconnaître puis à les purger plutôt qu’à bloquer un robot dont vous n’avez pas confirmé qu’il les a créés. Nous avons décortiqué ce sujet dans notre note sur les paniers créés par des bots ; l’idée pratique à retenir est que les paniers invités vides sont généralement une bizarrerie de journalisation, pas une urgence.

4. Le journal d’accès du serveur (la vérité terrain)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Votre journal d’accès brut affiche chaque requête avec son IP, son User-Agent et son horodatage. La vérité terrain que vos statistiques ne peuvent pas simuler, parce que les outils d’analyse basés sur JavaScript ne se déclenchent même pas pour la plupart des bots. Cherchez une IP qui demande les pages produit dans un ordre parfaitement séquentiel, des requêtes sans User-Agent, et des rafales de hits sur /login, /password-recovery et create-account. C’est aussi dans ce journal que vous confirmerez si un « Googlebot » est authentique, le vrai Googlebot se résout vers un hôte googlebot.com / google.com lors d’une recherche DNS inverse ; un faux prétend porter ce nom mais se résout vers une IP quelconque de centre de données.

L’échelle de défense : commencer par le moins coûteux et le plus large

Le filtrage des bots fonctionne par couches, et l’ordre intelligent consiste à commencer par les contrôles qui stoppent le plus de trafic avec le moins d’effort et le plus faible risque de faux positif. Vous ne montez l’échelle qu’aussi haut que votre problème l’exige.

robots.txt, fixer les règles du jeu, pas dresser une barrière

PrestaShop peut générer pour vous un robots.txt pertinent dans Paramètres de la boutique → Trafic & SEO → SEO & URLs → Générer le fichier robots.txt. Il indique aux robots bien élevés d’éviter votre panier, le tunnel de commande, les résultats de recherche et les pages de compte, ce qui réduit le gaspillage de crawl pour les bots que vous voulez conserver. Comprenez clairement sa limite : il est respecté par les bons bots et ignoré par les mauvais, c’est donc un outil de budget de crawl, jamais un contrôle de sécurité. N’y listez pas un chemin dans l’espoir de le cacher ; vous publieriez une carte de ce que vous préféreriez que les autres ne voient pas.

Le WAF en périphérie, l’étape au meilleur rendement

Placer Cloudflare (ou un WAF comparable) devant la boutique déplace le combat hors de votre hébergement : les IP connues comme malveillantes, les requêtes qui ne ressemblent pas à celles d’un vrai navigateur et les vagues volumétriques sont filtrées en périphérie avant d’atteindre PHP. L’offre gratuite vous donne le mode de lutte contre les bots, une base de réputation IP, des contrôles d’intégrité du navigateur et des règles de base de limitation de débit, assez pour retirer de votre serveur la majorité de l’automatisation inutile. Pour la plupart des petites et moyennes boutiques PrestaShop, ce seul geste fait plus que tout le reste combiné, et c’est la même couche de périphérie sur laquelle vous vous appuierez plus fortement quand le trafic de robots d’exploration se transforme en déluge ?q= de la recherche à facettes capable de faire tomber une boutique.

Limitation de débit, séparer les humains des scripts par la vitesse

Un vrai client qui navigue charge peut-être cinq à dix pages par minute ; un scraper qui parcourt votre catalogue en charge une centaine. Une limite par IP (renvoyant HTTP 429 dès qu’un seuil est dépassé) détecte automatiquement cet écart. Elle est plus fiable en périphérie (Cloudflare) ou au niveau du serveur web. Réglez-la généreusement, placez le plafond nettement au-dessus d’une navigation humaine afin qu’un bureau partagé ou une IP d’opérateur mobile, derrière laquelle se trouvent de nombreux vrais clients, ne soit pas pénalisé pour sa forte activité.

Défis de formulaires et honeypots, pour les formulaires ciblés

Les scrapers veulent vos pages ; les bots de spam veulent vos formulaires. Les formulaires d’inscription, de connexion, de contact et de newsletter concentrent les soumissions automatisées, et un défi invisible les arrête sans importuner les vrais acheteurs, c’est le sujet de reCAPTCHA for PrestaShop. Un honeypot le complète : un champ caché qu’un humain ne voit jamais, mais qu’un remplisseur de formulaire stupide complète docilement, se signalant lui-même comme bot sans rien coûter à vos clients.

Bloquer par identité, depuis le back-office PrestaShop

Les couches ci-dessus relèvent de l’infrastructure. Mais il vous faut aussi un contrôle accessible sans SSH ni développeur, un endroit où dire directement depuis l’administration « ce pays ne m’envoie que de la fraude et des scrapers, soumets-le à un défi » ou « ce User-Agent d’une plage d’hébergement martèle ma connexion, bloque-le ». C’est la couche applicative, et c’est là qu’une approche native dans PrestaShop est rentable : le blocage se fait avec tout le contexte de session (il connaît le groupe client, le pays, l’agent), et il survit aux mises à jour de thème et du cœur, car il n’est pas greffé dans des fichiers de configuration serveur que vous finirez par oublier.

Une précaution avant de recourir au blocage IP : soyez chirurgical avec les bannissements d’IP. Les IP résidentielles et mobiles sont recyclées. L’IP d’un scraper aujourd’hui peut être celle d’un client payant demain chez le même opérateur. Ne bloquez des IP résidentielles individuelles que comme mesure courte et réexaminée ; réservez les blocages permanents de plages IP aux centres de données et aux plages VPN où ne se trouve aucun vrai client. (Bannir une personne abusive précise par IP est un autre sujet, traité dans Customer Extra Info and IP Bans.) Pour les mesures larges, les règles par pays et par user-agent sont généralement plus sûres et demandent moins de maintenance que la chasse aux adresses individuelles.

Où Visitor Control intervient

Visitor Control stocke dans le back-office les décisions de blocage propres à la boutique.

La mise en liste blanche des réseaux de confiance empêche les règles de blocage larges de toucher votre propre équipe.

La table des visiteurs collectés est ps_mprvc_info. Cette vérification rapide montre si un pays ou un type d’appareil domine le trafic récent :

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

C’est précisément ce manque que notre module Visitor Control a été conçu pour combler. Il remplit deux rôles depuis le back-office, sans configuration au niveau serveur ni service externe à connecter. D’abord, il bloque les visiteurs indésirables par IP, pays ou User-Agent, vous pouvez ainsi écarter discrètement un agent de scraper connu ou un pays qui ne vous envoie que du trafic de test de cartes bancaires, en utilisant le traitement natif des requêtes PrestaShop plutôt que des lignes .htaccess modifiées à la main. Ensuite, il montre qui sont réellement vos visiteurs : appareil, IP et pays apparaissent directement sur la fiche client, afin que, lorsque vous décidez si un motif correspond à un bot ou à un vrai acheteur, vous vous appuyiez sur des preuves plutôt que sur une intuition. Qu’est-ce que cela vous apporte concrètement ? La décision de bloquer ou d’autoriser cesse d’être une tâche d’administration serveur que l’on repousse ; elle devient un choix de deux minutes depuis le même écran que celui où vous gérez la boutique, et comme il s’agit d’un module, les règles traversent intactes votre prochaine mise à jour PrestaShop.

Pour le bruit propre à PrestaShop lié aux paniers créés par des bots, décrit plus haut, ces paniers invités vides qui faussent les compteurs du back-office, les outils dédiés se trouvent du côté des paniers, avec le marquage et la purge des paniers de bots sans bloquer les robots d’exploration qui les créent légitimement. L’intérêt de séparer ces tâches, c’est la précision : vous filtrez le trafic dont vous ne voulez pas tout en conservant les bots qui vous apportent du référencement, et l’indexation qui vous apporte des ventes.

Une configuration en couches, pratique pour une boutique classique

Vous n’avez pas besoin d’un contrat de gestion des bots de niveau entreprise pour traiter le flot quotidien. Pour une boutique PrestaShop typique, cette pile arrête la grande majorité de l’automatisation indésirable avec peu de configuration et pratiquement aucun risque pour les vrais clients :

• Placez l’offre gratuite de Cloudflare devant la boutique, c’est la plus forte réduction immédiate du trafic inutile, en périphérie, avant qu’il ne vous coûte un cycle CPU.
• Générez un robots.txt correct depuis Trafic & SEO afin que les bons robots d’exploration évitent le panier, la recherche et les pages de compte, et consacrent leur budget aux produits.
• Ajoutez un défi invisible aux formulaires d’inscription, de connexion, de contact et de newsletter.
• Bloquez par pays et par User-Agent les motifs que vous avez confirmés comme étant des bots, depuis le back-office, et gardez les bannissements IP courts et ciblés.
• Parcourez vos journaux et la requête du Gestionnaire SQL chaque mois, bloquez les récidivistes confirmés, et vérifiez tout « Googlebot » suspect par DNS inverse avant de lui faire confiance.

Questions fréquentes

Bloquer les bots peut-il nuire à mon classement Google ?

Seulement si vous bloquez les mauvais. Les robots des moteurs de recherche (Googlebot, Bingbot) et les robots d’aperçu des réseaux sociaux doivent pouvoir vous atteindre, bloquez-les et vos pages disparaissent de la recherche dans les semaines qui suivent, ou vos liens partagés s’affichent sans aperçu. Tout l’enjeu consiste à les distinguer des scrapers, des bots de bourrage d’identifiants et des scanners de vulnérabilités. Bloquez selon une identité et un comportement confirmés, vérifiez tout « Googlebot » par DNS inverse avant de lui faire confiance, et vous réduirez le trafic inutile sans toucher aux bots qui amènent des clients.

Pourquoi ma boutique contient-elle autant de paniers abandonnés vides, sans client ?

PrestaShop crée une ligne de panier dès qu’un point d’entrée d’ajout au panier est sollicité ; les paniers invités vides peuvent donc venir de bots, de robots d’exploration, de modules qui précréent des paniers ou d’un comportement normal de session. Ce sont de vraies lignes, mais généralement des artefacts, pas des ventes perdues. Ne supposez pas qu’un robot précis est responsable. Confirmez dans votre journal d’accès quelle source a réellement touché le point d’entrée, puis purgez le bruit plutôt que de bloquer aveuglément un robot dont vous n’avez pas confirmé qu’il l’a créé.

robots.txt suffit-il à empêcher les mauvais bots d’entrer ?

Non. robots.txt est respecté par les bons robots d’exploration et ignoré par les mauvais, c’est donc un outil de budget de crawl, jamais un contrôle de sécurité. Il vaut la peine de le générer (Trafic & SEO → Générer le fichier robots.txt) pour éviter que les robots polis gaspillent leur budget sur les URL de panier, de recherche et de compte, mais n’y listez jamais un chemin en espérant le cacher, car vous publieriez une carte de ce que vous préféreriez que les autres ne voient pas. Pour les bots qui l’ignorent, il vous faut le WAF en périphérie, la limitation de débit et le blocage fondé sur l’identité.

Quelle est l’action unique qui a le plus d’impact ?

Pour la plupart des petites et moyennes boutiques, placez l’offre gratuite de Cloudflare (ou un WAF comparable) devant la boutique. Elle filtre les IP connues comme malveillantes, les non-navigateurs évidents et les vagues volumétriques en périphérie avant qu’ils n’atteignent PHP, et même dans l’offre gratuite vous disposez du mode de lutte contre les bots, de la réputation IP, des contrôles d’intégrité du navigateur et d’une limitation de débit de base. Ce seul geste en fait généralement plus que tout le reste combiné.

Dois-je bannir définitivement les adresses IP des scrapers ?

Soyez chirurgical. Les IP résidentielles et mobiles sont recyclées. L’IP d’un scraper aujourd’hui peut être celle d’un client payant demain chez le même opérateur, donc ne bloquez les IP résidentielles individuelles que comme une mesure courte et réexaminée. Réservez les blocages permanents de plages aux centres de données et aux plages VPN où ne se trouve aucun vrai client, et privilégiez les règles par pays et par User-Agent pour les mesures larges, car elles sont plus sûres et demandent moins de maintenance que la chasse aux adresses individuelles.

L’état d’esprit qui rend tout cela sûr est celui posé au départ : l’objectif n’est jamais de « bloquer les bots », mais de « bloquer les bots qui vous prennent des ressources tout en accueillant ceux qui vous apportent des clients ». Établissez la bonne taxonomie, lisez les preuves issues de votre propre boutique avant de frapper, et n’ajoutez des couches qu’aussi loin que votre trafic vous y oblige. Procédé ainsi, le filtrage des bots devient l’un des gains les plus discrets de la sécurité d’une boutique, invisible pour les clients qui comptent, tout en arrêtant une fuite continue de ressources, de fiabilité statistique et de surface d’attaque que vous offririez sinon aux scripts. Lorsque vous serez prêt à l’intégrer au reste de vos défenses, la checklist de durcissement de la sécurité et le guide de sécurité en langage clair pour les propriétaires de boutique relient tout le dossier.