# Le module WooCommerce Analytics : d’où viennent vraiment les chiffres affichés > Le tableau de bord Analytics n'interroge jamais directement les commandes. Comprendre ses tables de lookup évite bien des rapports incohérents pour un client pressé. - Auteur : Clément Hadrot - Publié le : 2022-04-20 - Mis à jour le : 2022-04-20 - Catégorie : E-commerce - URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/module-woocommerce-analytics-origine-donnees/ ## L’essentiel - Des tables de lookup dédiées, distinctes des commandes - Une synchronisation asynchrone via Action Scheduler - Un import manuel indispensable pour l'historique Un client a un jour demandé pourquoi le chiffre d'affaires affiché dans WooCommerce Analytics ne correspondait pas à la somme des commandes visibles dans la liste classique « Commandes ». La différence n'était que de quelques dizaines d'euros, mais suffisante pour semer le doute sur la fiabilité de l'outil. La réponse ne se trouve pas dans un bug, mais dans l'architecture même du module. WooCommerce Analytics n'est pas une simple mise en forme des commandes existantes : c'est un système de reporting qui vit dans ses propres tables, alimentées en tâche de fond, avec ses propres règles de recalcul. Comprendre ce mécanisme change la façon dont on diagnostique un écart, et surtout dont on explique la situation à un client qui pointe du doigt un chiffre qui ne « colle » pas. ## Un module né du plugin WooCommerce Admin Avant d'être intégré au cœur de WooCommerce, ce système de rapports a vécu plusieurs années sous la forme du plugin séparé WooCommerce Admin, fusionné définitivement à partir de WooCommerce 4.0. Cette origine explique une partie de son architecture : plutôt que de recalculer des agrégats à chaque affichage en interrogeant la table `wp_posts` et ses métadonnées, comme le faisaient les anciens rapports de WooCommerce, le module maintient des tables dédiées, conçues pour être interrogées rapidement même sur un catalogue de plusieurs dizaines de milliers de commandes. ## Les tables de lookup, cœur du système Concrètement, cinq tables personnalisées portent l'essentiel des données affichées dans les rapports : `wp_wc_order_stats` pour les montants agrégés par commande, `wp_wc_order_product_lookup` pour le détail par produit vendu, `wp_wc_order_coupon_lookup` pour l'usage des coupons, `wp_wc_order_tax_lookup` pour la ventilation fiscale, et `wp_wc_customer_lookup` pour les données clients agrégées. > L'essentiel à retenir : Des tables de lookup dédiées, distinctes des commandes ; Une synchronisation asynchrone via Action Scheduler ; Un import manuel indispensable pour l'historique Ces tables sont remplies au moment où une commande change de statut, via des classes de type `Automattic\WooCommerce\Admin\API\Reports\Orders\Stats\DataStore`, elles-mêmes déclenchées par des actions programmées avec Action Scheduler plutôt qu'en synchrone dans la requête HTTP. C'est ce découplage qui explique un premier phénomène courant : juste après le passage d'une commande à l'état « Terminée », il peut s'écouler quelques secondes, voire plus sur un serveur chargé, avant que le chiffre apparaisse dans le tableau de bord. ### Le rôle d'Action Scheduler dans la synchronisation Chaque modification de commande programme une tâche visible dans **WooCommerce › État › Tâches planifiées**, sous un groupe généralement nommé autour de `wc-admin-data`. Sur une boutique avec un volume de commandes important et un cron WordPress mal configuré, ces tâches peuvent s'accumuler sans être exécutées, ce qui produit exactement le symptôme observé au début : des chiffres Analytics en retard sur la réalité des commandes. ## Les cas où l'écart n'est pas un simple retard Un remboursement partiel, une commande annulée puis remise en attente, ou une modification manuelle des lignes de commande depuis l'administration peuvent laisser les tables de lookup dans un état légèrement décalé si la resynchronisation associée échoue silencieusement. WooCommerce prévoit un outil de réparation pour ce cas précis, accessible depuis **WooCommerce › État › Outils**, avec l'action « Recalculer les statistiques de rapport de la boutique ». - Un écart de quelques commandes récentes : très souvent une tâche Action Scheduler en attente, à vérifier avant toute autre hypothèse. - Un écart sur des commandes anciennes, antérieures à l'activation du module : il faut lancer manuellement l'import historique proposé lors de la première configuration d'Analytics. - Un écart persistant après recalcul : signe probable d'un hook tiers qui modifie les montants de commande après la synchronisation initiale. ## Ce que cela change pour un développeur Comprendre cette architecture évite une erreur fréquente : requêter directement les tables de lookup dans un développement personnalisé sans passer par les data stores officiels. Ces tables ne sont pas documentées comme une API stable et leur structure a déjà évolué entre les versions majeures de WooCommerce. Pour un rapport personnalisé, il reste préférable de s'appuyer sur les classes `Automattic\WooCommerce\Admin\API\Reports` exposées par le module, plutôt que sur des requêtes SQL directes qui casseront silencieusement à la prochaine mise à jour. > Sur un projet client, expliquer que les deux écrans (« Commandes » et « Analytics ») ne consultent tout simplement pas la même source suffit souvent à désamorcer l'inquiétude, bien avant d'avoir trouvé la cause exacte de l'écart. ## Notre verdict WooCommerce Analytics reste un outil fiable pour le suivi quotidien d'une boutique, à condition d'accepter sa contrainte principale : une latence de synchronisation qui n'est pas un défaut mais un choix d'architecture assumé pour préserver les performances des rapports. Pour un développeur qui doit exploiter ces chiffres dans un tableau de bord maison ou un export comptable, la règle est simple : ne jamais lire directement les tables de lookup dans du code métier, toujours passer par les classes de reporting officielles, et prévoir un bouton de recalcul visible pour les cas où la synchronisation a pris du retard.