Les bugs connus du tableau de bord natif PrestaShop
Le tableau de bord PrestaShop (Dashboard) est l'une des fonctionnalités les plus critiquées de la plateforme, et ce depuis des années. Les problèmes sont documentés sur le forum officiel, GitHub et les communautés de développeurs PrestaShop.
Le premier bug récurrent concerne le comptage des visiteurs et des sessions. Le module natif statsdata enregistre les visites en base de données, mais il comptabilise les bots, les crawlers et les outils de monitoring comme des visiteurs réels. Résultat : votre nombre de visiteurs est systématiquement gonflé, parfois de 50 % ou plus. Le taux de conversion affiché est donc mécaniquement sous-estimé, car le numérateur (commandes) est correct mais le dénominateur (visites) est faux.
Le deuxième problème concerne les décalages avec Google Analytics. Les marchands qui comparent les données du dashboard PrestaShop avec GA constatent des écarts importants : différences sur le nombre de sessions, sur le chiffre d'affaires, sur les sources de trafic. Ces écarts s'expliquent par des méthodologies de comptage différentes, mais ils minent la confiance dans les données PrestaShop.
Le troisième bug touche les graphiques de tendance. Le dashboard affiche des courbes de chiffre d'affaires et de commandes qui ne correspondent pas toujours aux données réelles des tables de commandes. Des problèmes de timezone, de statuts de commande non filtrés et de cache périmé provoquent des incohérences visuelles qui induisent en erreur.
Pourquoi les statistiques PrestaShop ne sont pas fiables
Le problème fondamental vient de l'architecture du système statistique de PrestaShop. Les données sont stockées dans des tables dédiées (ps_statssearch, ps_connections, ps_page_viewed, etc.) qui sont alimentées par des modules natifs : statsdata, statssearch, statsregistrations. Ces modules fonctionnent en hooks, c'est-à-dire qu'ils s'exécutent à chaque chargement de page pour enregistrer la visite.
Cette architecture pose plusieurs problèmes. D'abord, les tables statistiques grossissent très rapidement et finissent par ralentir le backoffice. Une boutique active peut accumuler des millions de lignes en quelques mois. Ensuite, ces tables ne sont pas toujours correctement nettoyées par les tâches CRON, ce qui provoque des données obsolètes ou corrompues.
Deuxième cause : les modules statistiques natifs n'ont pas été maintenus au même rythme que le core de PrestaShop. Certains modules datent de PrestaShop 1.6 et ont été portés vers 1.7 et 8.x sans refonte majeure. Les incompatibilités avec les nouvelles versions de PHP, les thèmes custom et les modules tiers créent des comportements imprévisibles.
Troisième cause : l'absence de filtrage intelligent. PrestaShop ne distingue pas un vrai visiteur d'un bot, ne gère pas correctement les sessions multi-appareils, et ne prend pas en compte le consentement cookies dans ses comptages. Dans un contexte RGPD, ces statistiques sont non seulement fausses mais potentiellement non conformes.
Les corrections classiques du dashboard PrestaShop
La première correction que recommandent les développeurs PrestaShop est de purger régulièrement les tables statistiques. Via phpMyAdmin ou un module de maintenance, vous pouvez vider les tables ps_connections, ps_connections_page, ps_connections_source, ps_guest et ps_page_viewed. Cela allège la base de données et peut corriger certaines incohérences, mais vous perdez tout votre historique.
La deuxième correction consiste à configurer une tâche CRON pour le nettoyage automatique. PrestaShop dispose d'un script de maintenance (cron_currency_rates, par exemple) mais les tâches de nettoyage statistique ne sont pas toujours activées par défaut. Ajouter un CRON qui exécute le nettoyage quotidien des stats peut stabiliser les données.
La troisième approche est de désactiver les modules statistiques natifs et de se reposer uniquement sur Google Analytics ou un outil tiers pour le tracking des visiteurs. Cela résout le problème des bots mais vous prive des métriques directement dans le backoffice.
Ces corrections sont des rustines. Elles améliorent la situation temporairement mais ne résolvent pas le problème de fond : PrestaShop n'a pas été conçu comme un outil d'analytics. Son dashboard est un bonus, pas une fonctionnalité core. Et à chaque mise à jour ou changement de module, les problèmes peuvent réapparaître.
Pourquoi les modules backoffice ne résolvent pas le problème
Face aux limites du dashboard natif, de nombreux marchands se tournent vers des modules statistiques tiers disponibles sur PrestaShop Addons. Ces modules promettent des rapports avancés, des graphiques plus complets et des données plus fiables. En pratique, ils sont limités par l'écosystème même de PrestaShop.
Le premier problème est la source de données. La plupart des modules backoffice exploitent les mêmes tables de commandes et de clients que le dashboard natif. Ils présentent les données différemment mais ne les corrigent pas. Si votre table ps_orders contient des commandes en statut incohérent, le module tiers les affichera aussi.
Le deuxième problème est la performance. Un module qui exécute des requêtes SQL complexes dans le backoffice PrestaShop impacte les temps de chargement de votre administration. Les rapports lourds (cohortes, LTV, marges par produit) nécessitent des calculs intensifs qui ne sont pas faits pour tourner dans le contexte PHP d'un backoffice e-commerce.
Le troisième problème est la maintenance. Chaque mise à jour de PrestaShop risque de casser les modules tiers. Les marchands se retrouvent régulièrement avec des modules statistiques incompatibles après une mise à jour, perdant temporairement l'accès à leurs données.
Enfin, aucun module backoffice ne peut intégrer des données externes comme les coûts publicitaires, les coûts de transaction réels ou les données de tracking cross-canal. Ils restent enfermés dans le périmètre de données de PrestaShop.
L'alternative : une solution SaaS externe dédiée
L'approche la plus fiable consiste à externaliser l'analytics dans une plateforme SaaS dédiée qui se connecte à PrestaShop pour synchroniser les données brutes et les traite dans un environnement optimisé pour l'analyse.
Une solution externe présente plusieurs avantages structurels. D'abord, elle n'impacte pas les performances de votre boutique. Les calculs analytiques sont effectués sur des serveurs dédiés, pas dans le contexte PHP de votre backoffice. Votre PrestaShop reste rapide.
Ensuite, une plateforme SaaS peut croiser des données de sources multiples. Les commandes PrestaShop, certes, mais aussi les données de tracking visiteurs, les coûts publicitaires de vos régies, les frais de transaction de votre PSP, et les données de livraison. Cette vision consolidée est impossible à obtenir dans un module backoffice.
De plus, une solution externe n'est pas affectée par les mises à jour de PrestaShop. Le module de synchronisation est la seule pièce dans votre backoffice, et il se contente de transmettre les données. Toute la logique analytique est côté SaaS, maintenue et mise à jour indépendamment.
Enfin, une solution dédiée peut proposer des analyses avancées que PrestaShop ne supportera jamais nativement : cohortes, LTV, segmentation RFM, marge nette multi-coûts, et synchronisation d'audiences vers les plateformes publicitaires.
Comment Fullmetrix corrige les problèmes du dashboard PrestaShop
Fullmetrix adopte cette approche SaaS externe. Le module PrestaShop (compatible 1.7 à 8.x) se charge uniquement de synchroniser vos commandes, produits et clients vers la plateforme. Il n'exécute aucun calcul dans votre backoffice et n'impacte pas les performances de votre boutique.
Côté tracking, Fullmetrix utilise un script first-party et du tracking server-side qui remplace les modules statistiques natifs de PrestaShop. Ce tracking distingue les vrais visiteurs des bots, respecte le consentement RGPD et produit des données de trafic fiables. Vous n'avez plus besoin de comparer trois sources de données pour savoir combien de visiteurs vous avez réellement.
Le tableau de bord Fullmetrix affiche des métriques vérifiées : chiffre d'affaires, nombre de commandes, panier moyen, taux de conversion, coût d'acquisition, marge nette. Chaque chiffre est calculé à partir des données transactionnelles réelles de PrestaShop, pas à partir de tables statistiques potentiellement corrompues.
Pour les analyses avancées, Fullmetrix génère automatiquement les rapports de cohortes, la segmentation RFM et les lifecycle stages, le calcul de LTV par cohorte, et la marge nette intégrant les 5 types de coûts (COGS, shipping, transaction, opérationnel, ad spend). Les données sont hébergées dans l'Union européenne et la plateforme est conçue pour être conforme au RGPD, contrairement aux modules natifs qui ne gèrent pas le consentement.