Un connecteur à sens unique, ERP vers boutique ou boutique vers ERP, reste relativement simple à raisonner : une seule direction, une seule source de vérité. Un connecteur bidirectionnel entre WooCommerce et Odoo change complètement la donne, parce que les deux systèmes peuvent modifier la même donnée quasiment en même temps — un stock ajusté manuellement dans Odoo pendant qu’une commande WooCommerce le décrémente automatiquement — et qu’il faut décider, architecture à l’appui, qui a le dernier mot.
Ce projet concernait une entreprise de vente d’équipements professionnels gérant sa comptabilité et ses achats fournisseurs dans Odoo, tout en vendant en ligne via WooCommerce. Contrairement à une synchronisation en file d’attente générique déjà traitée par ailleurs, l’enjeu ici était spécifiquement la cohérence bidirectionnelle entre deux systèmes qui peuvent tous deux initier un changement.
Le principe directeur : un domaine, une seule source de vérité
La première décision d’architecture, avant toute ligne de code, a consisté à répartir les domaines de données entre les deux systèmes, plutôt que d’imaginer une synchronisation symétrique généralisée. Le stock physique et les fiches produit (prix d’achat, fournisseur, référence interne) restent gouvernés par Odoo, qui centralise déjà les achats. Les commandes clients et leur statut d’expédition restent gouvernées par WooCommerce, plus proche du client final. Chaque système ne fait que lire les données de l’autre domaine, jamais les écrire directement.
┌─────────────────┐ commandes ┌──────────────────┐
│ WooCommerce │ ───────────────────────>│ Odoo │
│ (source: ventes) │ │ (source: stock, │
│ │<─────────────────────── │ achats, compta) │
└─────────────────┘ niveaux de stock, prix └──────────────────┘
│ │
└──────────────── file de messages ────────────┘
(identifiants de corrélation)Le rôle de la file de messages intermédiaire
Plutôt qu’un appel direct et synchrone entre les deux systèmes à chaque changement, l’architecture retenue introduit une file de messages intermédiaire (implémentée ici via une table de queue dédiée, consommée par Action Scheduler côté WordPress et par un cron Odoo côté ERP). Chaque événement — commande créée, stock ajusté, prix modifié — devient un message horodaté et typé, plutôt qu’un appel API bloquant qui échouerait en cascade si l’un des deux systèmes est temporairement indisponible.
L’identifiant de corrélation, pièce centrale du système
Le vrai risque d’un connecteur bidirectionnel est la boucle infinie : WooCommerce notifie Odoo d’un changement de stock, Odoo répercute ce changement, ce qui déclenche une nouvelle notification vers WooCommerce, qui la traite à nouveau comme un changement externe, et ainsi de suite. Pour couper cette boucle, chaque message porte un identifiant de corrélation et un champ d’origine explicite. Quand WooCommerce reçoit une mise à jour de stock en provenance d’Odoo, il l’applique en l’associant à un indicateur « origine externe », ce qui empêche le hook local de stock (woocommerce_product_set_stock) de re-déclencher une notification sortante vers Odoo pour ce même changement.
add_action( 'woocommerce_product_set_stock', function( $product ) {
if ( ! empty( $product->get_meta( '_sync_origine_externe' ) ) ) {
$product->delete_meta_data( '_sync_origine_externe' );
$product->save_meta_data();
return; // Ne pas renvoyer vers Odoo une donnée qui vient d'Odoo
}
// Sinon, mettre en file la notification sortante vers Odoo
file_evenement_sortant( 'stock_modifie', $product->get_id() );
} );La résolution de conflit, décidée à l’avance
Malgré la répartition par domaine, certains conflits restent possibles — par exemple si le stock est ajusté manuellement dans WooCommerce par erreur, en même temps qu’un mouvement de stock légitime a lieu dans Odoo. La règle retenue : en cas d’écart détecté au moment de la synchronisation, Odoo gagne toujours sur les questions de stock, WooCommerce gagne toujours sur les questions de statut de commande. Cette règle est appliquée explicitement dans le code de résolution, jamais laissée au hasard de l’ordre d’arrivée des messages, ce qui aurait rendu le comportement du système imprévisible d’une synchronisation à l’autre.
Ce que l’architecture ne résout pas seule
- Elle ne remplace pas une supervision : un tableau de bord dédié affiche les messages en échec après plusieurs tentatives, pour intervention humaine.
- Elle suppose une tolérance à la latence : un changement de stock côté Odoo met de quelques secondes à une minute pour apparaître côté WooCommerce, ce qui est acceptable pour du stock mais aurait été problématique pour un prix affiché en temps réel lors d’enchères, par exemple.
- Elle demande une convention de nommage stricte des types de messages, documentée une fois pour toutes, pour que les deux équipes (celle qui maintient WooCommerce et celle qui maintient Odoo) parlent le même langage technique.
Un connecteur bidirectionnel n’est jamais un problème de code, c’est un problème de gouvernance des données qu’on résout ensuite avec du code. Décider qui a le dernier mot doit précéder la première ligne écrite.
En résumé
Faire dialoguer WooCommerce et Odoo dans les deux sens exige d’abandonner l’idée d’une synchronisation symétrique et généraliste, au profit d’une répartition claire des domaines de vérité, d’une file de messages découplée et d’un mécanisme explicite pour couper les boucles de rétroaction. Cette rigueur, coûteuse à mettre en place, évite des semaines de débogage sur des incohérences de stock qui, sans cette architecture, deviennent quasiment impossibles à tracer a posteriori.
