Customer Extra Info and IP Bans : protéger votre boutique des visiteurs problématiques

La plupart de vos visiteurs sont bien ceux qu'ils prétendent être. Mais toute boutique finit par rencontrer l'exception : le « client » qui passe dix commandes sans jamais payer, celui qui conteste un paiement auprès de sa banque après réception du colis, la personne qui se réinscrit avec une nouvelle adresse e-mail jetable chaque fois que son dernier compte a été annulé, ou le concurrent qui se connecte discrètement depuis le même bureau pour surveiller vos prix. Le back-office de PrestaShop ne vous montre presque rien de tout cela. Vous voyez une commande, un nom, une adresse e-mail — et rien sur la machine, le réseau ou l'historique qui se cache derrière. Ce guide explique comment combler cet angle mort de deux façons : collecter assez d'informations supplémentaires sur les visiteurs pour reconnaître un profil problématique, et disposer d'un blocage d'IP prêt à l'emploi afin que, lorsque vous en identifiez un, vous puissiez lui fermer la porte sans développeur et sans mettre toute la boutique hors ligne.

Dernière mise à jour : juin 2026.

Ce que PrestaShop vous dit sur un visiteur — et ce qu'il masque

Par défaut, PrestaShop enregistre le nom du client, son adresse e-mail, sa date de naissance facultative et les adresses qu'il saisit au moment de la commande. Il journalise les connexions dans Statistiques → Visiteurs en ligne et dans la table connections, et associe une adresse IP aux sessions invité. Ce qu'il ne fait pas, en revanche, c'est relier ces points pour vous. Aucun écran ne vous dit « ce compte s'est connecté depuis six IP différentes dans trois pays cette semaine », ni « ces quatre comptes partagent tous la même IP et la même empreinte navigateur ». Les données brutes existent par fragments ; le schéma qui permettrait de détecter la fraude tôt n'apparaît nulle part à l'endroit où vous iriez réellement le chercher.

Cette lacune compte, car les abus sont presque toujours un schéma, pas un événement isolé. Un article retourné, c'est un client. Vingt retours provenant de comptes qui remontent tous à la même IP, c'est un problème que vous voulez voir au troisième jour, pas après la troisième lettre de rétrofacturation envoyée par votre acquéreur. La première tâche consiste donc à rendre les choses visibles — enrichir ce que vous savez sur chaque visiteur pour que le schéma devienne lisible.

Les « informations supplémentaires » qui signalent vraiment un visiteur problématique

Les « informations client supplémentaires » ne signifient pas forcément un formulaire d'inscription plus long (les formulaires plus longs convertissent moins bien — c'est un coût réel). Les informations qui repèrent les abuseurs sont les métadonnées techniques que la requête transporte déjà, mais que vous n'enregistrez tout simplement pas. Notre module Customer Extra Info & IP Ban les collecte passivement, visite par visite, et les rattache à la fiche client afin que vous puissiez les consulter depuis la page d'administration du client :

• Adresse IP et pays — la vraie adresse, pas celle de votre proxy. Derrière Cloudflare ou un équilibreur de charge, la recherche IP naïve de PrestaShop enregistre souvent l'IP du CDN. Le module lit CF-Connecting-IP, X-Real-IP et X-Forwarded-For (en validant chaque valeur), afin que l'adresse que vous bloquez soit celle du visiteur, pas celle de votre point d'entrée réseau.
• Pays — déduit de l'en-tête CF-IPCOUNTRY de Cloudflare lorsqu'il est présent, ou de la base GeoIP de PrestaShop en solution de repli. Une vague soudaine d'inscriptions depuis un pays vers lequel vous n'expédiez pas est déjà un signal.
• Navigateur, système d'exploitation et type d'appareil — analysés à partir de l'agent utilisateur. Cinq « clients différents » utilisant tous la même version inhabituelle de navigateur, ce ne sont pas cinq clients.
• IP uniques par client, avec première vue / dernière vue et nombre de visites — c'est le détecteur de fraude multi-comptes. Un compte qui saute entre une douzaine d'IP, ou une IP qui porte une douzaine de noms de compte, ressort immédiatement dans cette vue.

La collecte est volontairement discrète : elle déduplique les données afin de n'écrire qu'un seul enregistrement par couple IP-client et par heure, au lieu de solliciter votre base de données à chaque chargement de page. Et chaque donnée (agent utilisateur, OS, navigateur, résolution d'écran) dispose de son propre interrupteur, pour que vous collectiez exactement ce dont vous avez besoin, et rien que vous préféreriez ne pas stocker. Qu'est-ce que cela vous apporte concrètement ? Lorsqu'un litige arrive, vous ouvrez le profil du client et voyez toute son empreinte — chaque IP, chaque pays, chaque session — au lieu de deviner. C'est la différence entre agir sur des preuves et réagir dans la panique.

La liste des clients affiche chaque client avec son nom, son e-mail, son statut et ses dates d'inscription et de dernière visite.

Si vous devez auditer l'empreinte brute pendant une investigation, le module la stocke dans ps_mprceiipban_info. Remplacez le préfixe si votre boutique n'utilise pas ps_ :

SELECT id_customer, ip_address, country_code, browser_name, device_type, date_add
FROM ps_mprceiipban_info
WHERE id_customer = 123
ORDER BY date_add DESC
LIMIT 50;

Blocage d'IP dans PrestaShop : plus précis que « bloquer l'adresse »

Le cœur de PrestaShop ne propose pas de véritable outil de blocage des visiteurs — la liste des IP autorisées du mode maintenance, sous Paramètres de la boutique → Général → Maintenance, exclut tout le monde sauf les IP listées, soit l'inverse de ce que vous voulez pour un seul mauvais acteur. Le blocage est donc exactement le type de capacité qu'un module peut ajouter. La version naïve d'un blocage d'IP — une adresse, bloquée partout — est aussi la moins utile, car elle est à la fois trop brutale et trop facile à contourner. Un blocage qui mérite vraiment sa place vous donne le contrôle sur quelle adresse est visée, où il s'applique et pendant combien de temps.

Faire correspondre plus qu'une seule adresse

Les mauvais acteurs restent rarement sur une seule IP statique. Le module peut faire correspondre un blocage à :

• Une IP exacte — le cas le plus simple.
• Un joker comme 203.0.113.* — lorsqu'une personne revient sans cesse sur des adresses voisines dans le même bloc.
• Une plage CIDR comme 203.0.113.0/24 — la manière précise de couvrir tout un sous-réseau.
• Une plage d'adresses comme 203.0.113.10-203.0.113.40 — pour un intervalle arbitraire.
• Un code pays — bloquer toute une origine que vous ne servez pas, évaluée selon le pays GeoIP ci-dessus.
• Un motif d'agent utilisateur — correspondance en texte simple ou expression régulière complète, pour un abuseur identifiable par sa chaîne client plutôt que par son adresse.

Choisir où le blocage s'applique

C'est la partie qui transforme la masse en scalpel. Chaque blocage porte une portée :

Cette séparation est importante à cause de la réalité des IP dynamiques et partagées : bureaux, universités et opérateurs mobiles placent de nombreuses personnes réelles derrière une seule adresse publique. Un blocage complet sur une IP partagée peut vous coûter discrètement de vraies commandes. Un blocage limité à la commande ou à l'authentification contient les dégâts exactement à l'action abusive. Et comme la vraie IP du visiteur est correctement résolue derrière votre CDN, vous bloquez la bonne personne, pas un voisin de hasard.

Faire expirer un blocage — et ne jamais vous bloquer vous-même

Deux contrôles supplémentaires empêchent les blocages de devenir un problème en soi. Chaque blocage peut être temporaire, avec une date d'expiration après laquelle il est automatiquement désactivé — utile pour un blocage de temporisation lorsqu'une interdiction permanente serait excessive, et plus propre pour la conservation des données (nous revenons sur l'angle RGPD plus bas). Et une liste blanche gagne toujours : toute IP ou plage CIDR que vous y ajoutez ne peut jamais être bloquée, y compris par une règle automatique. Ajoutez-y d'abord votre bureau, la connexion de votre développeur et vos services de supervision, afin qu'un blocage large défini sous le coup de la colère à 2 h du matin ne puisse pas vous fermer accidentellement la porte à vous.

Chaque ligne de blocage affiche sa portée, son adresse IP et son statut actif côte à côte.

Les adresses de confiance figurent dans la liste blanche tandis que les commandes signalées affichent un score de risque et un motif.

Arrêter les abus automatisés avant qu'ils nécessitent un blocage

Une grande partie du trafic de « visiteurs problématiques » provient de scripts, pas de personnes — et la défense la plus propre consiste à rendre l'attaque automatiquement coûteuse. Le module suit les tentatives de connexion échouées par IP et peut bloquer automatiquement une adresse qui dépasse le seuil que vous avez défini (un certain nombre d'échecs dans une fenêtre de temps), avec un blocage temporaire limité à l'authentification plutôt qu'un blocage permanent. C'est une réponse ciblée au bourrage d'identifiants : l'attaquant par force brute est exclu de la connexion pendant une heure après, par exemple, dix erreurs, tandis qu'un client qui a simplement mal saisi son mot de passe deux fois n'est pas touché.

Le blocage automatique après échecs de connexion est une couche. Le travail plus large de séparation des bons robots et des mauvais — scrapers, scanners de vulnérabilités, clics publicitaires frauduleux — relève d'une discipline à part entière ; nous l'expliquons dans Visitor Control : bloquer les mauvais robots et le trafic indésirable. Et l'action la plus rentable pour arrêter les fausses inscriptions et le spam de formulaires à la source consiste à placer un challenge sur le formulaire lui-même — voir reCAPTCHA pour PrestaShop. Lorsqu'un mauvais acteur martèle vos URL de recherche à facettes jusqu'au déni de service, la première ligne de défense est votre CDN, pas une liste de blocage PrestaShop : survivre au déluge ?q=.

Où le blocage d'IP s'inscrit dans votre durcissement global

Soyez lucide sur ce qu'un blocage d'IP peut faire et ne peut pas faire. Il est excellent contre les abus occasionnels ou négligents — la majorité des abuseurs, qui ne sont pas assez sophistiqués pour s'embêter avec un VPN. Il ne constitue pas un périmètre contre un attaquant déterminé, capable de changer d'adresse plus vite que vous ne pouvez les bloquer. Considérez-le comme un outil bien ciblé, pas comme votre stratégie de sécurité. La stratégie se joue dans l'ensemble :

• Le tour complet — permissions de fichiers, dossier admin, en-têtes, mises à jour — se trouve dans la checklist de durcissement de sécurité PrestaShop, avec une explication plus accessible dans le guide en langage clair pour propriétaires de boutique.
• Le verrouillage du back-office lui-même — les comptes admin sont la vraie cible d'un attaquant — est couvert dans l'authentification à deux facteurs, les politiques de mot de passe et la sécurité admin.
• Si vous êtes bloqué sur une version que vous ne pouvez pas mettre à niveau, le durcissement avancé avec correctifs virtuels est la voie réaliste.
• Et si le pire est déjà arrivé, n'improvisez pas — suivez la réponse à une violation de données : que faire si votre boutique est piratée.

Le volet juridique et la tenue des registres

Bloquer un client dans l'Union européenne relève de votre droit — vous pouvez refuser un service — mais les données que vous conservez pour le justifier relèvent du RGPD. Deux conséquences pratiques en découlent. Premièrement, collectez de manière proportionnée : c'est pourquoi chaque champ de métadonnées du module est un interrupteur individuel, et pourquoi les anciens enregistrements peuvent être purgés selon un calendrier, afin de ne pas accumuler des empreintes d'appareils que vous n'utilisez jamais. Deuxièmement, conservez une raison claire pour chaque blocage (le module stocke un motif et l'employé qui l'a défini), afin que si un client bloqué escalade le dossier auprès de sa banque ou d'une autorité de protection des consommateurs, vous puissiez montrer pourquoi la restriction a été appliquée, et pas seulement qu'elle existe. Si ce client dépose ensuite une demande d'effacement au titre de l'article 17, vous vous y conformez en général — même si vous pouvez conserver ce qui est réellement nécessaire pour des réclamations juridiques ou des obligations de conformité. Vos conditions générales devraient déjà préciser que les comptes peuvent être résiliés en cas de violation des règles ; c'est cette clause qui donne sa base au blocage.

Questions fréquentes

Un blocage d'IP peut-il bloquer par erreur de vrais clients derrière Cloudflare ?

Oui, si vous bloquez la mauvaise adresse — c'est précisément le piège derrière un CDN. La recherche IP naïve de PrestaShop enregistre souvent l'IP de Cloudflare ou de votre équilibreur de charge plutôt que celle du visiteur, si bien qu'un « blocage » peut tomber sur votre propre point d'entrée réseau et exclure tout le monde. Le module lit CF-Connecting-IP, X-Real-IP et X-Forwarded-For (en validant chaque valeur), afin que l'adresse que vous bloquez soit bien celle du visiteur réel, pas celle de votre CDN. Résolvez d'abord la vraie IP ; ce n'est qu'ensuite qu'un blocage devient sûr.

Pourquoi utiliser un blocage « commande » ou « authentification » au lieu d'un blocage complet ?

Parce que les bureaux, les universités et les opérateurs mobiles placent de nombreuses personnes réelles derrière une seule IP publique ; un blocage complet sur une adresse partagée peut donc vous coûter discrètement de vraies commandes. Un blocage limité à la commande permet à un mauvais payeur récidiviste de naviguer, mais pas de passer commande ; un blocage limité à l'authentification stoppe la création de faux comptes et le bourrage d'identifiants depuis une source sans bloquer les invités légitimes sur cette même IP. Faites correspondre la portée à l'action abusive — les blocages complets sont réservés aux abus manifestes que vous voulez exclure entièrement.

Comment arrêter les scripts de bourrage d'identifiants sans bloquer les vrais clients qui se trompent en saisissant leur mot de passe ?

Utilisez le blocage automatique après échecs de connexion avec un seuil raisonnable. Le module compte les tentatives de connexion échouées par IP et peut appliquer automatiquement un blocage temporaire limité à l'authentification dès qu'une adresse dépasse, par exemple, dix erreurs dans une fenêtre de temps — l'attaquant par force brute est alors exclu de la connexion pendant une heure, tandis qu'un client qui a mal saisi son mot de passe deux fois n'est pas touché. C'est une réponse ciblée aux scripts, pas une sanction générale. Le spam de formulaires et les fausses inscriptions se bloquent mieux directement sur le formulaire avec reCAPTCHA.

Comment éviter de me bloquer moi-même avec un blocage large ?

Construisez d'abord la liste blanche. Une liste blanche gagne toujours — toute IP ou plage CIDR que vous y ajoutez ne peut jamais être bloquée, y compris par une règle automatique — alors ajoutez votre bureau, la connexion de votre développeur et vos services de supervision avant de créer un blocage large par pays ou CIDR. Ainsi, un blocage étendu défini sous le coup de la colère à 2 h du matin ne pourra pas vous exclure accidentellement. Associez cela à des blocages temporaires (une date d'expiration les désactive automatiquement) pour les périodes de temporisation où un blocage permanent serait excessif.

Bloquer un client et stocker ses IP pose-t-il un problème RGPD ?

Refuser un service relève de votre droit, mais les données que vous conservez pour le justifier relèvent du RGPD ; collectez donc de manière proportionnée. Chaque champ de métadonnées est un interrupteur individuel et les anciens enregistrements peuvent être purgés selon un calendrier, afin que vous n'accumuliez pas des empreintes d'appareils que vous n'utilisez jamais. Conservez une raison claire pour chaque blocage (le module stocke le motif et l'employé qui l'a défini), afin de pouvoir montrer pourquoi une restriction a été appliquée si un client escalade le dossier auprès de sa banque ou d'une autorité de protection des consommateurs. Honorez les demandes d'effacement au titre de l'article 17, en ne conservant que ce qui est réellement nécessaire pour des réclamations juridiques — et assurez-vous que vos conditions précisent que les comptes peuvent être résiliés en cas de violation des règles.

Une porte équilibrée, pas une forteresse

Le but de tout cela n'est pas d'accueillir les acheteurs avec suspicion — c'est de faire tourner une boutique accueillante qui garde discrètement des preuves. La plupart des boutiques ont rarement besoin de bloquer qui que ce soit. Mais le bon moment pour mettre cette capacité en place, c'est avant d'en avoir besoin, pas au milieu d'une crise lorsqu'un réseau de fraude est en pleine action et que vous découvrez le back-office sous pression. Activez la collecte des métadonnées visiteurs pour rendre les schémas visibles. Ajoutez d'abord vos propres connexions à la liste blanche. Gardez les blocages d'IP ciblés et expirables comme un outil mobilisable en quelques secondes — un blocage commande pour le mauvais payeur, un blocage authentification pour le créateur de comptes en série, un blocage complet pour l'abus réellement agressif — et laissez le blocage automatique gérer seul les scripts de force brute. C'est exactement ce que Customer Extra Info & IP Ban est conçu pour vous donner : la visibilité nécessaire pour reconnaître un visiteur problématique, et un moyen précis et réversible de l'arrêter — directement depuis votre back-office, sans développeur.