Le défi de la synchronisation WordPress / ERP
Sur les projets e-commerce B2B, la question de la synchronisation entre WordPress/WooCommerce et un ERP externe est quasi systématique. Les données qui doivent circuler sont multiples : produits et leurs attributs, niveaux de stocks, tarifs (souvent différenciés par client ou par groupe), commandes, statuts de livraison. Chaque flux a ses propres contraintes de fréquence, de volume et de criticité. La solution généraliste — utiliser un plugin de synchronisation tout-en-un du marché — couvre rarement les spécificités d’un ERP métier sur mesure. J’ai dû développer des plugins de synchronisation from scratch sur plusieurs projets, et voici la méthode qui a émergé de ces expériences.
Architecture du plugin de synchronisation
Un plugin de synchronisation WordPress/ERP bien conçu s’articule autour de plusieurs composants distincts. Le connecteur API gère les appels vers l’ERP — authentification, construction des requêtes, gestion des erreurs et des timeouts. L’importeur traite les données reçues, les valide, les transforme si nécessaire et les persiste dans WordPress. Le planificateur orchestre les synchronisations automatiques via WP-Cron ou Action Scheduler. Le logger enregistre chaque opération de synchronisation avec son statut, ses métriques et ses éventuelles erreurs. L’interface d’administration donne une visibilité sur l’état de la synchronisation et permet les déclenchements manuels.
La connexion à l’API de l’ERP
La première étape est de comprendre et documenter l’API de l’ERP. Les ERPs modernes exposent généralement une API REST documentée, mais les ERPs plus anciens peuvent utiliser des protocoles différents — SOAP, FTP de fichiers CSV, ou même des exports de base de données directe. Quelle que soit la méthode, la logique est la même : créer une classe PHP dédiée qui encapsule toute la logique de communication avec l’ERP.
class Mon_ERP_Connector {
private $api_url;
private $api_key;
public function get_products( $page = 1, $per_page = 100 ) {
$response = wp_remote_get( $this->api_url . '/products', array(
'headers' => array( 'Authorization' => 'Bearer ' . $this->api_key ),
'timeout' => 30,
'body' => array( 'page' => $page, 'per_page' => $per_page ),
) );
if ( is_wp_error( $response ) ) return false;
return json_decode( wp_remote_retrieve_body( $response ), true );
}
}
La gestion de la synchronisation incrémentale
Synchroniser l’intégralité d’un catalogue à chaque passage de cron est inefficace et potentiellement problématique sur les gros volumes. La synchronisation incrémentale — qui ne traite que les données modifiées depuis la dernière synchronisation — est systématiquement préférable. La plupart des APIs ERP exposent un paramètre de filtre par date de modification (updated_since ou équivalent). En stockant le timestamp de la dernière synchronisation réussie dans les options WordPress, on peut ne récupérer et traiter que les données qui ont changé.
La stratégie de logging : visibilité et debugging
Un système de logging robuste est indispensable sur un plugin de synchronisation en production. J’utilise systématiquement une table dédiée en base de données pour stocker les logs de synchronisation — plus efficace que les fichiers log pour les requêtes et le filtrage. Chaque entrée de log contient : le type d’opération (import produits, mise à jour stocks, import commandes…), le timestamp de début et de fin, le nombre d’éléments traités, le nombre d’erreurs, et le détail des erreurs le cas échéant. Une interface d’administration expose ces logs avec filtres et pagination, permettant à l’équipe technique de diagnostiquer rapidement un problème sans accès SSH au serveur.
Les points de vigilance critiques
Plusieurs pièges récurrents méritent d’être anticipés. Les timeouts sur les appels API longue durée — diviser les imports en batches de taille raisonnable et utiliser Action Scheduler plutôt que WP-Cron natif pour les traitements lourds. Les conflits de concurrence — deux synchronisations qui tournent simultanément peuvent créer des incohérences ; implémenter un verrou (transient WordPress) pour s’assurer qu’une seule synchronisation tourne à la fois. La gestion des suppressions — quand un produit est supprimé dans l’ERP, comment le site WordPress réagit-il ? Supprimer, désactiver, ou archiver ? La réponse dépend du contexte métier et doit être explicitement définie. Et surtout, toujours prévoir un mode dry-run qui simule la synchronisation sans écrire en base de données — indispensable pour valider le comportement avant le premier passage en production.
