Quand WooCommerce natif montre ses limites
WooCommerce est une solution e-commerce remarquablement flexible — jusqu’à un certain point. Sur des projets avec des catalogues de plusieurs milliers de produits aux attributs très spécifiques, l’architecture native de WooCommerce — qui stocke les données produits dans wp_posts et wp_postmeta — commence à poser des problèmes sérieux. Les performances se dégradent, les requêtes en base de données se multiplient, et la table wp_postmeta se retrouve avec des dizaines de millions de lignes. J’ai été confronté à exactement ce problème sur un projet B2B avec un catalogue de près de 4000 références synchronisées depuis un ERP externe. La solution adoptée a été radicalement différente de l’approche conventionnelle — et elle a tenu ses promesses.
L’architecture : des tables MySQL custom à la place de wp_postmeta
Le principe est simple dans sa conception : plutôt que de créer 4000 fiches produits WooCommerce et de stocker leurs données dans les tables standard WordPress, les données du catalogue sont stockées dans des tables MySQL custom créées spécifiquement pour le projet. Ces tables sont optimisées pour les requêtes spécifiques du catalogue — indexes sur les colonnes de recherche, structure relationnelle adaptée aux données métier, pas de surcharge de colonnes génériques inutilisées.
La création des tables s’effectue au moment de l’activation du plugin, via dbDelta() :
global $wpdb;
$sql = "CREATE TABLE IF NOT EXISTS {$wpdb->prefix}catalogue_produits (
id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
reference VARCHAR(50) NOT NULL,
denomination VARCHAR(255) NOT NULL,
prix_ht DECIMAL(10,2) NOT NULL,
stock INT(11) NOT NULL DEFAULT 0,
PRIMARY KEY (id),
UNIQUE KEY reference (reference)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;";
dbDelta( $sql );
L’affichage du catalogue : requêtes directes en base de données
L’interface du catalogue sur le site est alimentée directement depuis les tables custom, via $wpdb->get_results() avec des requêtes SQL optimisées. La pagination, les filtres par catégorie, les recherches par référence ou dénomination sont tous gérés côté base de données — pas via WP_Query. Cette approche offre des performances nettement supérieures à WooCommerce natif sur des volumes importants.
L’ajout au panier dynamique : la pièce centrale du dispositif
C’est la partie la plus délicate de l’architecture. Sans fiche produit WooCommerce, comment ajouter un article au panier ? La solution est de créer un seul produit WooCommerce générique qui sert de conteneur, et de modifier dynamiquement ses données à chaque ajout au panier via les filtres WooCommerce appropriés.
Le produit générique est créé une seule fois en back-office. À chaque ajout au panier, les données de l’article réel (référence, dénomination, prix) sont transmises via des paramètres POST et injectées dans les cart item data via le filtre woocommerce_add_cart_item_data. Les données sont ensuite restituées dans le panier et la commande via les filtres woocommerce_get_cart_item_from_session et woocommerce_cart_item_name.
add_filter( 'woocommerce_add_cart_item_data', 'inject_produit_custom_data', 10, 3 );
function inject_produit_custom_data( $cart_item_data, $product_id, $variation_id ) {
$cart_item_data['reference'] = sanitize_text_field( $_POST['reference'] ?? '' );
$cart_item_data['denomination'] = sanitize_text_field( $_POST['denomination'] ?? '' );
$cart_item_data['prix_ht'] = floatval( $_POST['prix_ht'] ?? 0 );
return $cart_item_data;
}
La synchronisation avec l’ERP : plugin sur mesure
La synchronisation entre l’ERP externe et les tables custom WordPress est assurée par un plugin WordPress dédié qui se connecte à l’API de l’ERP, récupère les données produits (références, dénominations, prix, stocks) et les importe/met à jour dans les tables custom. Cette synchronisation peut être déclenchée manuellement depuis le back-office, ou planifiée via WP-Cron pour une mise à jour automatique à intervalles réguliers. Un journal de synchronisation stocke l’historique des imports, les éventuelles erreurs et les statistiques (produits créés, mis à jour, supprimés).
Les enseignements de ce projet
Cette architecture non conventionnelle a tenu toutes ses promesses en production : performances excellentes même avec 4000 références, synchronisation fiable avec l’ERP, interface d’administration claire pour l’équipe client. Le principal défi a été de maintenir la cohérence entre les données custom et le cycle de vie des commandes WooCommerce — notamment pour les emails de confirmation et l’historique des commandes. Chaque étape du tunnel de commande WooCommerce nécessite une attention particulière pour garantir que les bonnes données s’affichent au bon endroit. C’est un projet qui demande une maîtrise fine des hooks WooCommerce — mais le résultat en vaut largement l’investissement.
