Une entreprise de fournitures industrielles gérait déjà son catalogue, ses stocks et sa comptabilité dans un ERP historique, utilisé aussi par ses commerciaux terrain et son service de facturation. L’ouverture d’une boutique WooCommerce en complément de la vente directe posait une question structurante avant même le premier développement : comment faire vivre deux systèmes sans qu’ils se contredisent, ni que l’un ignore ce que fait l’autre.
Ce type de projet revient très régulièrement pour des entreprises qui digitalisent une activité déjà structurée en interne. L’architecture qui fonctionne le mieux repose sur trois principes simples à énoncer, mais qui demandent une vraie discipline pour être tenus dans la durée.
Désigner clairement la source de vérité, système par système
Contrairement à une idée reçue, il n’est pas nécessaire (ni souhaitable) qu’un seul des deux systèmes soit maître de tout. La bonne pratique consiste à désigner une source de vérité différente selon le type de donnée : l’ERP reste maître du catalogue produit et des stocks (parce qu’il consolide les mouvements de plusieurs canaux de vente), tandis que WooCommerce reste maître des commandes créées en ligne, qui remontent ensuite vers l’ERP pour la facturation et la comptabilité. Cette répartition évite les conflits d’écriture bidirectionnelle sur une même donnée, source classique d’incohérences difficiles à déboguer.
Choisir une clé de rapprochement stable
La référence produit (SKU) doit servir de clé de rapprochement entre les deux systèmes, jamais l’identifiant interne WooCommerce (post_id ou identifiant HPOS), qui n’a aucune signification côté ERP et pourrait changer en cas de réimport ou de migration future. Chaque appel de synchronisation doit donc systématiquement chercher le produit par SKU :
function trouver_produit_par_sku_erp( $sku_erp ) {
$produit_id = wc_get_product_id_by_sku( $sku_erp );
return $produit_id ? wc_get_product( $produit_id ) : null;
}
Synchroniser le catalogue depuis l’ERP vers WooCommerce
La synchronisation catalogue et stock s’effectue via l’API REST WooCommerce, dans sa version stable wc/v3, appelée directement depuis l’ERP ou via un middleware intermédiaire, à intervalle régulier ou déclenchée par un événement côté ERP :
curl -X PUT https://exemple.fr/wp-json/wc/v3/products/1842 \
-u cle_consommateur:secret_consommateur \
-H "Content-Type: application/json" \
-d '{
"stock_quantity": 240,
"regular_price": "89.50",
"manage_stock": true
}'
Pour un catalogue volumineux, l’API expose aussi un point d’entrée de traitement par lots (/wc/v3/products/batch), qui permet de mettre à jour plusieurs centaines de références en un seul appel plutôt que d’enchaîner des centaines de requêtes individuelles, nettement plus lent et plus fragile en cas de coupure réseau en cours de synchronisation.
Faire remonter les commandes vers l’ERP de façon asynchrone
Transmettre chaque commande WooCommerce vers l’ERP au moment précis de sa validation, de façon synchrone et bloquante, est une erreur fréquente : si l’ERP est temporairement indisponible ou lent à répondre, le client reste bloqué sur la page de confirmation de commande, ou pire, voit son paiement validé sans confirmation finale. La bonne pratique consiste à planifier l’envoi via Action Scheduler, la bibliothèque de tâches asynchrones déjà utilisée en interne par WooCommerce :
add_action( 'woocommerce_order_status_processing', function ( $order_id ) {
if ( false === as_next_scheduled_action( 'envoyer_commande_vers_erp', [ $order_id ] ) ) {
as_enqueue_async_action( 'envoyer_commande_vers_erp', [ $order_id ], 'integration-erp' );
}
} );
add_action( 'envoyer_commande_vers_erp', function ( $order_id ) {
$order = wc_get_order( $order_id );
$reponse = wp_remote_post( 'https://erp.exemple.local/api/commandes', [
'body' => wp_json_encode( construire_payload_commande( $order ) ),
'headers' => [ 'Authorization' => 'Bearer ' . get_option( 'erp_api_token' ) ],
'timeout' => 15,
] );
if ( is_wp_error( $reponse ) || wp_remote_retrieve_response_code( $reponse ) >= 400 ) {
// Échec : Action Scheduler permet de consulter et de rejouer la tâche manuellement
throw new Exception( 'Échec de transmission de la commande ' . $order_id . ' vers l\'ERP.' );
}
} );
Lever une exception dans le callback permet à Action Scheduler de marquer la tâche en échec plutôt qu’en réussite silencieuse, et de la retrouver facilement dans WooCommerce > État > Tâches planifiées pour un rejeu manuel ou automatique selon la politique de nouvelle tentative configurée.
Superviser la synchronisation dans la durée
- Un tableau de bord interne, même sommaire, doit lister les dernières synchronisations réussies et échouées, avec leur horodatage ;
- Une alerte doit se déclencher si aucune synchronisation catalogue n’a eu lieu depuis un délai anormal, signe probable d’une tâche planifiée silencieusement bloquée ;
- Un rapprochement périodique (hebdomadaire, par exemple) entre le nombre de commandes créées côté WooCommerce et le nombre de commandes reçues côté ERP permet de détecter une dérive avant qu’elle ne s’accumule sur plusieurs semaines.
Sur ce type de projet, la robustesse ne vient jamais de la sophistication du code d’intégration lui-même, mais de la capacité à détecter rapidement qu’une synchronisation a échoué, et à la rejouer sans perte de données.
En résumé
Connecter WooCommerce à un ERP est avant tout un exercice de gouvernance des données : désigner clairement quel système fait autorité sur quoi, s’appuyer sur une clé de rapprochement stable comme le SKU, traiter la remontée des commandes de façon asynchrone et rejouable, et superviser activement la chaîne de synchronisation. C’est cette discipline, plus que le choix de l’API elle-même, qui détermine si l’intégration tient dans la durée une fois la boutique en pleine activité.
