Quelle part du trafic de votre boutique en ligne n'est pas humaine

Le chiffre qui ne collait pas

Les statistiques de PrestaShop enregistrent comme une « visite » chaque requête qui atteint la boutique, sauf si un filtre interne la reconnaît d'abord comme un programme automatique et l'écarte. Le premier jour où nous avons réellement vérifié les chiffres de notre propre boutique, la table des statistiques indiquait 43 478 visites. Les vraies personnes, ce même jour, étaient environ 300. Cent quarante-cinq faux visiteurs pour un vrai.

Ce n'est pas un cas rare : c'est ce qui arrive quand le filtre de robots intégré à PrestaShop n'est jamais mis à jour. Et la table qui se remplit de ces chiffres n'est pas gratuite : sur notre boutique, elle avait dépassé 1,3 Go, une ligne inutile après l'autre. Après le nettoyage, elle était descendue à 24 Mo.

Pourquoi le filtre intégré ne suffit plus

PrestaShop propose déjà une méthode destinée à reconnaître les robots, Connection::isBot(), qui fonctionne en comparant le user agent de la requête à une liste écrite dans le code. Le problème, c'est que cette liste n'a jamais été rafraîchie : elle contient des noms comme Scooter (le robot d'AltaVista) et d'autres moteurs de recherche fermés depuis des années, mais aucun des robots construits plus récemment pour entraîner des modèles d'intelligence artificielle, ni les versions à jour des robots des moteurs de recherche qui existent encore aujourd'hui. Un filtre conçu pour le web d'il y a quinze ans laisse passer sans les reconnaître précisément les programmes qui génèrent aujourd'hui le plus de trafic automatique.

La conséquence pratique, c'est que le « nombre de visites » d'une boutique PrestaShop non entretenue ne mesure pas des personnes : il mesure des personnes plus une part, souvent majoritaire, de programmes que le filtre ne sait pas reconnaître. Les décisions prises en regardant ce chiffre, du budget publicitaire au jugement sur une page qui « marche » ou « ne convertit pas », partent d'une donnée fausse.

L'erreur que nous avons faite nous-mêmes, en premier

Mettre à jour cette liste semble anodin : ajouter une règle générique qui reconnaît le mot « bot » dans le user agent, plus les noms propres des robots qui visitent réellement la boutique (moteurs de recherche, Meta, les différents robots d'IA). La première version que nous avons écrite disait, en gros, « si le user agent contient bot, c'est un robot ». Elle fonctionnait parfaitement, à un détail près : elle reconnaissait aussi la fin du mot CUBOT, une marque de téléphones Android.

PrestaShop utilise ce même isBot() non seulement pour les statistiques, mais aussi dans le contrôleur qui ajoute les produits au panier : si une requête semble provenir d'un robot, l'ajout au panier est ignoré en silence, et la boutique répond quand même « c'est fait », sans aucune erreur visible. Résultat : un vrai client avec un téléphone CUBOT cliquait sur « ajouter au panier », voyait le message de confirmation, et le panier restait vide. Aucune erreur dans les logs, aucun avertissement : juste un client qui ne pouvait rien acheter et ne savait probablement pas pourquoi.

Nous l'avons découvert en passant la nouvelle règle sur 153 113 lignes de logs réelles correspondant à cinq jours de trafic de la boutique, en comparant combien de robots l'ancienne règle attrapait par rapport à la nouvelle : la différence correspondait exactement aux 31 requêtes d'un téléphone CUBOT. Nous l'avons corrigé avec une exception explicite pour cette marque, et relancé la même comparaison avant de mettre la règle en production. C'est le genre de bug qui n'apparaît que si on le cherche : un filtre trop strict ne génère pas d'erreur, il produit un client qui s'en va sans vous dire pourquoi.

Un filtre qui fonctionne ne règle pas tout

Reconnaître les robots qui arrivent ne suffit pas si autre chose leur dit ensuite explicitement d'entrer. À la même période, notre log Apache montrait 38 144 requêtes en une seule journée provenant d'un seul robot, celui que Meta utilise pour entraîner ses modèles : 78 % de tout le trafic de la journée. Ce n'étaient pas des accès dispersés : le robot était tombé dans une boucle, en suivant un paramètre de retour après connexion qui s'imbriquait sur lui-même à chaque passage, et chacune de ces requêtes était une page PrestaShop entièrement générée, pas une réponse légère.

La cause n'était pas un bug du robot : c'était un fichier robots.txt qui, dans le cadre d'une configuration destinée à accueillir les « bons » robots d'IA, avait fini par accueillir aussi celui-là, celui qui devrait rester dehors parce qu'il entraîne des modèles au lieu de renvoyer du trafic. Une fois la configuration corrigée, le trafic de ce robot a baissé de 95 % en quinze heures. Là encore, la leçon ne concerne pas le robot : un « bon » filtre écrit à un endroit peut être contredit par une règle écrite ailleurs, et la seule façon de le savoir est de lire réellement les logs, pas de faire confiance à la configuration sur le papier.

Ce qu'il faut vérifier avant de faire confiance à vos statistiques

• Ne regardez pas le nombre de « visites » isolément : comparez-le à une source indépendante (un outil d'analyse côté navigateur, par exemple) pour le même jour. Si l'écart est d'un ordre de grandeur, le filtre de robots ne fait pas son travail.
• Si vous maintenez votre propre liste de robots reconnus, testez-la sur un échantillon réel de logs avant de la mettre en production, pas seulement sur quelques user agents tapés à la main : une marque de téléphone, une bibliothèque, un client HTTP légitime peuvent contenir par hasard le mot qui identifie un robot.
• Vérifiez si le filtre qui alimente vos statistiques est le même que celui qui décide si un client peut acheter. Si c'est le cas, un filtre trop strict ne pollue pas seulement un chiffre : il bloque silencieusement une commande.
• Lisez les logs du serveur, pas seulement la configuration : une règle destinée à ouvrir la porte à un robot peut finir par l'ouvrir à un autre, et seul le trafic réel le prouve.
• Gardez en tête que la liste des robots à reconnaître n'est jamais terminée : de nouveaux robots apparaissent sans cesse, surtout pour l'entraînement des IA, et une liste écrite une fois puis jamais retouchée devient obsolète en quelques mois, pas en quelques années.

En bref

Le nombre de « visites » qu'une boutique en ligne affiche dans son back-office n'est pas une donnée neutre : il dépend d'un filtre qui doit être entretenu, et un filtre mal entretenu peut se tromper dans deux directions opposées, en laissant entrer trop de robots dans les statistiques ou en empêchant trop de vrais clients d'utiliser le panier. Sur notre boutique, le jour où nous avons regardé pour la première fois, le rapport était de 145 fausses visites pour une vraie personne. Le nettoyage n'a pas demandé un projet compliqué, mais il a demandé de lire vraiment les logs, de corriger d'abord une erreur que nous avions faite nous-mêmes, et de tout revérifier sur des données réelles avant de s'y fier.