Pourquoi les chiffres de deux rapports ne concordent-ils jamais exactement ? C’est la question qui revient quand un client compare le chiffre d’affaires affiché dans WooCommerce Analytics avec celui de son export comptable, ou avec un total calculé « à la main » dans un tableur. La réponse tient souvent en une phrase : les deux ne comptent pas la même chose, au même instant, avec la même définition d’une commande valide.
Plutôt que de rajouter une extension de reporting supplémentaire par-dessus WooCommerce, la solution la plus robuste consiste à brancher un outil de BI comme Metabase directement sur la base de données, en lecture seule, avec des vues SQL documentées que le client peut auditer lui-même.
Poser une frontière stricte : un utilisateur MySQL en lecture seule
La première règle, non négociable, est de ne jamais connecter un outil de reporting avec les identifiants d’administration du site. Il faut créer un compte MySQL dédié, limité en lecture, et si possible restreint aux tables nécessaires :
CREATE USER 'metabase_ro'@'%' IDENTIFIED BY 'un-mot-de-passe-genere';
GRANT SELECT ON boutique_wp.wp_wc_order_stats TO 'metabase_ro'@'%';
GRANT SELECT ON boutique_wp.wp_wc_order_product_lookup TO 'metabase_ro'@'%';
GRANT SELECT ON boutique_wp.wp_wc_customer_lookup TO 'metabase_ro'@'%';
GRANT SELECT ON boutique_wp.wp_wc_order_coupon_lookup TO 'metabase_ro'@'%';
FLUSH PRIVILEGES;
Ces quatre tables sont celles que WooCommerce Analytics alimente en tâche de fond : wp_wc_order_stats pour les totaux par commande, wp_wc_order_product_lookup pour le détail par produit, wp_wc_customer_lookup pour la segmentation client, et wp_wc_order_coupon_lookup pour l’usage des coupons.
Construire des vues SQL plutôt que des requêtes ad hoc dans Metabase
Le piège classique est de laisser chaque utilisateur écrire ses propres requêtes SQL natives dans Metabase : chacun filtre les statuts de commande différemment, et les totaux divergent à nouveau. La bonne pratique consiste à créer des vues côté MySQL qui encapsulent la logique métier une fois pour toutes.
CREATE VIEW v_ventes_nettes AS
SELECT
DATE(date_created) AS jour,
SUM(net_total) AS total_net,
COUNT(DISTINCT order_id) AS nb_commandes
FROM wp_wc_order_stats
WHERE status IN ('wc-completed', 'wc-processing')
GROUP BY DATE(date_created);
Cette vue devient la seule source du chiffre « ventes nettes du jour » dans Metabase. Si la définition change (par exemple pour inclure les commandes en statut personnalisé wc-envoyee), on la modifie à un seul endroit, et tous les tableaux de bord qui en dépendent se mettent à jour automatiquement.
Documenter chaque carte avec sa source
Metabase permet d’ajouter une description à chaque question et à chaque tableau de bord. Ne la laissez jamais vide : indiquez la vue SQL utilisée, la période couverte, et les statuts de commande inclus. C’est ce détail qui permet, six mois plus tard, de répondre en trente secondes à la question « pourquoi ce chiffre a-t-il changé ? ».
- Nommez les questions de façon explicite : « CA net encaissé (hors remboursements) », pas « Ventes ».
- Ajoutez un filtre de date sur toutes les cartes, pour éviter les comparaisons involontaires de périodes différentes.
- Isolez dans une collection à part les métriques encore en phase de validation, pour ne pas polluer le tableau de bord principal.
Rafraîchir sans bloquer la boutique
Les tables de lookup sont déjà mises à jour en tâche de fond par WooCommerce via Action Scheduler, il est donc rarement nécessaire de synchroniser Metabase en temps réel. Une synchronisation planifiée toutes les heures, en dehors des pics de charge connus, suffit pour la plupart des boutiques et évite d’ajouter de la pression sur la base de production.
Sur nos projets, la règle appliquée est : aucune requête de reporting ne doit toucher aux tables
wp_postsouwp_postmetadirectement — uniquement les tables de lookup, conçues pour ça.
Notre verdict
Un tableau de bord Metabase fiable ne remplace pas WooCommerce Analytics, il le complète en rendant chaque chiffre traçable jusqu’à sa requête SQL d’origine. La confiance retrouvée ne vient pas d’un outil plus « joli », mais du fait que n’importe qui dans l’équipe peut ouvrir la vue SQL correspondante et vérifier lui-même la définition du chiffre affiché.
