Connecteur · WooCommerce
Connecteur Odoo ↔ WooCommerce
Commandes, stock et catalogue entre Odoo et WooCommerce : ce que l'API v3 permet vraiment, ce qu'elle ne garantit pas, et les trois pièges qui font tomber les connecteurs en production.
/wp-json/wc/v3order.created / order.updated, signés HMAC-SHA256per_page plafonné à 100wc_orders) ou legacy (posts) — à vérifier avant tout devWooCommerce est le cas que nous voyons le plus, et celui où nous reprenons le plus de connecteurs cassés. La raison est simple : l’API est facile d’accès, donc tout le monde s’y essaie. Faire descendre une commande dans Odoo prend une après-midi. La faire descendre toutes les fois, sans doublon, y compris quand le site ne répond pas, prend un projet.
Ce que l’API expose
L’API REST v3 est native depuis longtemps et couvre l’essentiel : produits et variations, commandes, clients, remboursements, coupons, zones de livraison. L’authentification se fait par une paire clé/secret générée dans WordPress — en HTTPS, une simple authentification Basic suffit.
Trois précisions qui comptent :
- La pagination est plafonnée à 100 enregistrements par appel. Sur un catalogue de 20 000 références, cela fait 200 appels pour un balayage complet : c’est un traitement de nuit, pas une synchronisation à la volée.
- Les champs personnalisés sont accessibles via
meta_data, ce qui permet de récupérer ce qu’ajoutent les extensions — à condition qu’elles écrivent bien dans les métadonnées, ce qui n’est pas systématique. - Il n’y a pas de limite de débit côté WooCommerce. C’est un piège : rien ne vous arrête, donc un connecteur mal écrit martèle le site jusqu’à ce que l’hébergeur mutualisé le coupe. C’est à nous de nous brider.
Les webhooks : nécessaires, pas suffisants
WooCommerce sait notifier order.created et order.updated vers une URL, avec une signature HMAC-SHA256 encodée en base64 dans l’en-tête. La vérification de cette signature n’est pas optionnelle : sans elle, n’importe qui connaissant l’URL peut injecter une commande.
Le point que la plupart des intégrateurs ignorent :
La réponse est toujours la même : webhook plus synchronisation périodique de rattrapage. Le webhook donne la réactivité, le balayage garantit l’exhaustivité. Les deux passent par la même clé d’idempotence, donc une commande arrivée deux fois n’est traitée qu’une fois.
HPOS : la question à poser en premier
WooCommerce a changé son stockage des commandes. Le modèle historique les rangeait dans les tables WordPress génériques (posts, postmeta) ; le stockage haute performance (HPOS) utilise des tables dédiées (wc_orders, wc_orders_meta, et leurs satellites d’adresses et de données opérationnelles).
Pour l’API REST, c’est transparent. Pour tout le reste, non :
| Ce que vous faites | Modèle historique | HPOS |
|---|---|---|
| Lire via REST v3 | fonctionne | fonctionne |
| Requête SQL directe sur les commandes | posts + postmeta | wc_orders + satellites |
| Script d’export maison hérité | souvent OK | retourne zéro ligne, sans erreur |
| Plugin ancien non compatible | OK | comportements imprévisibles |
Le troisième cas est le plus vicieux : le script ne plante pas, il ne trouve simplement rien. Nous vérifions systématiquement le mode de stockage avant de toucher à un existant.
Le sens de synchronisation
C’est la décision qui détermine tout le reste, et elle se prend au cadrage, pas dans le code.
| Donnée | Autorité recommandée | Pourquoi |
|---|---|---|
| Stock | Odoo → Woo | Le stock physique est dans l’entrepôt, pas sur le site |
| Prix | selon le cas | Odoo si tarifs structurés ; Woo si promotions marketing pilotées côté boutique |
| Fiche produit | selon le cas | Woo si le contenu est un actif SEO travaillé ; Odoo si le catalogue est industriel |
| Commande | Woo → Odoo | Le site est le point de saisie |
| Statut d’expédition | Odoo → Woo | La préparation se fait dans Odoo |
Un connecteur « bidirectionnel » sur le même champ, sans arbitre, diverge toujours. Nous ne le faisons pas.
Ce que nous livrons
- Le connecteur, dans un module Odoo distinct, versionné dans votre dépôt.
- Webhooks signés et balayage de rattrapage, avec clé d’idempotence.
- File d’attente avec reprise sur erreur, backoff, et mise en quarantaine des lignes qui échouent — sans bloquer les autres.
- Un journal lisible : quel enregistrement, quel champ, quelle réponse HTTP, quelle action corrective.
- La documentation du mapping, champ par champ.
Les limites, dites franchement
La synchronisation instantanée n’existe pas. Il y a une latence, entre quelques secondes et quelques minutes selon le flux. Sur des pièces uniques, cela se gère par des règles — pas par une promesse.
Les extensions WooCommerce sont un risque permanent. Un plugin qui modifie le calcul du prix, la TVA ou les statuts de commande peut casser un mapping stable depuis deux ans, lors d’une mise à jour que personne ne nous annonce. Nous le documentons et le testons, nous ne pouvons pas l’empêcher.
Un site mutualisé saturé restera saturé. Si l’hébergement plie déjà sous le trafic, le connecteur n’arrangera rien — il ajoutera de la charge. Ce sujet-là se traite avant, côté hébergement.
Pour la partie fonctionnelle — que faire du stock, des tarifs, des marketplaces — la logique de flux est la même que sur les autres boutiques : voir PrestaShop et marketplaces.
Questions fréquentes
Faut-il un plugin sur le site WooCommerce ?
Pas pour l’essentiel : l’API REST v3 est native, il suffit de générer une clé. Un plugin devient utile pour exposer des données que le cœur ne publie pas — champs personnalisés, espace client sur mesure — mais chaque plugin ajouté est une dépendance à maintenir à chaque mise à jour de WordPress.
Les webhooks WooCommerce sont-ils fiables ?
Non, pas seuls. Woo tente la livraison et abandonne : si votre serveur est indisponible trente secondes, la commande est perdue pour le connecteur. C’est pourquoi un webhook doit toujours être doublé d’une synchronisation périodique qui rattrape les manquants. Un connecteur qui n’a que des webhooks perdra des commandes, c’est une question de temps.
Comment éviter les surventes entre le site et les autres canaux ?
En faisant d’Odoo la source de vérité du stock et en poussant vers Woo, jamais l’inverse. La latence de propagation reste : sur des références à l’unité, on ajoute un stock de sécurité ou une réservation à la commande. Personne ne supprime totalement le risque, on le borne.
Que se passe-t-il si le site est en HPOS ?
Rien pour l’API REST, qui abstrait le stockage. En revanche, tout script SQL direct écrit pour l’ancien modèle devient faux : les commandes ne sont plus dans posts et postmeta mais dans wc_orders et ses tables satellites. C’est la première chose que nous vérifions sur un existant.
Combien de temps pour un connecteur commandes + stock ?
Sur une configuration standard, quelques jours de développement et de recette. Le délai vient rarement du code : il vient des décisions — qui fait autorité sur le prix, comment on traite les remboursements partiels, que faire d’une commande passée sur un produit inconnu d’Odoo.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.