Dix entrepôts, un seul panier d’achat, une seule vérité sur le stock disponible : voilà le problème à résoudre, et il ne se résout pas avec une synchronisation périodique par cron. Dès qu’un produit est présent dans plusieurs dépôts physiques, la question n’est plus « quel est le stock ? » mais « quel est le stock à l’instant T, compte tenu des réservations en cours ailleurs ? ».
La tentation classique consiste à faire remonter un total agrégé toutes les cinq minutes vers WooCommerce. Cela fonctionne tant que le volume de commandes reste faible. Dès que plusieurs canaux de vente puisent dans le même stock physique — boutique en ligne, revendeurs, point de vente physique — la fenêtre de cinq minutes devient une fenêtre de survente garantie sur les produits à rotation rapide.
Le principe : des événements, pas des snapshots
La bonne architecture ne transporte pas un état de stock complet à chaque synchronisation, elle transporte des mouvements. Chaque entrepôt émet un événement à chaque variation réelle : réception de marchandise, prélèvement pour expédition, casse, retour client. Ces événements alimentent une file unique, consommée par un service central qui maintient l’état agrégé consulté par WooCommerce.
Entrepôt Lille ─┐
Entrepôt Lyon ─┤
Entrepôt Nantes ─┼──▶ File d'événements (stock.mouvement)
... ─┤ │
Entrepôt Metz ─┘ ▼
Service d'agrégation de stock
│
▼
wc_update_product_stock() (WooCommerce)
Réservation locale contre stock affiché global
Le point le plus délicat n’est pas la remontée du stock, c’est la réservation au moment du paiement. Si le stock affiché est un total agrégé de dix entrepôts, il faut décider, au moment où une commande est validée, quel entrepôt honore réellement l’expédition. Deux approches coexistent selon la maturité logistique du client :
- Réservation optimiste centralisée : le service d’agrégation décrémente immédiatement le total global et notifie ensuite l’entrepôt choisi ; simple, mais nécessite une file capable d’absorber un pic sans latence.
- Réservation par appel synchrone à l’entrepôt : WooCommerce interroge en direct l’entrepôt candidat avant de confirmer la commande ; plus fiable localement, mais fragile si un entrepôt répond lentement.
Sur les architectures qui tiennent la charge, la réservation optimiste centralisée l’emporte presque toujours, à condition d’accepter un mécanisme de compensation : si l’entrepôt choisi ne peut finalement pas honorer la commande, un événement de correction repart dans la file et déclenche une reventilation automatique vers un autre entrepôt.
Résoudre les conflits d’écriture concurrente
Avec dix sources qui écrivent potentiellement au même instant sur le même produit, les conflits sont une certitude statistique, pas une exception. La règle qui fonctionne consiste à horodater chaque événement à la source et à appliquer une résolution par dernière écriture gagnante sur le mouvement, jamais sur l’état final : on rejoue les mouvements dans l’ordre de leurs horodatages, on ne compare jamais deux totaux entre eux.
{
"evenement": "stock.mouvement",
"entrepot": "lyon",
"sku": "REF-4471",
"delta": -3,
"horodatage": "2026-02-05T09:12:41.203Z",
"id_commande": "wc_order_88213"
}
Ce format minimal suffit à reconstruire un état cohérent tant que le service d’agrégation traite les événements dans l’ordre de leur horodatage et non dans l’ordre d’arrivée réseau, qui peut varier d’un entrepôt à l’autre selon la qualité de leur connexion.
Ce que WooCommerce doit voir, et ce qu’il ne doit jamais voir
WooCommerce n’a pas besoin de connaître l’existence des dix entrepôts. Il doit uniquement recevoir, via update_post_meta() sur la clé de quantité ou via l’API du Store correspondant à la version en place, un total déjà consolidé. Faire remonter la complexité multi-entrepôt jusque dans le thème ou dans les hooks de la fiche produit est une erreur récurrente : elle transforme chaque montée de version de WooCommerce en risque de casse sur la logique métier logistique.
Le stock affiché sur la fiche produit doit rester la chose la plus simple du système : un nombre. Toute la complexité doit vivre en amont, jamais dans le thème.
Surveillance et dérive du stock agrégé
Un système événementiel peut dériver silencieusement si un événement se perd. La parade consiste à programmer une réconciliation nocturne, hors heures de commande, qui recompare le total agrégé de chaque entrepôt avec un relevé physique ou avec l’export du WMS local, et qui journalise tout écart supérieur à un seuil défini plutôt que de le corriger automatiquement sans trace.
En résumé
Synchroniser dix entrepôts avec WooCommerce en temps réel n’est pas un problème d’intégration mais un problème d’architecture événementielle : des mouvements plutôt que des états, une réservation centralisée compensée en cas d’échec, une résolution de conflits par horodatage, et un stock exposé à WooCommerce toujours réduit à sa plus simple expression.
