Synchronisation temps réel des stocks et prix entre ERP et e-commerce

Pourquoi un stock faux coûte cher

La survente est la conséquence la plus visible : le site accepte une commande que l'entrepôt ne peut pas honorer. S'ensuit un traitement SAV, une annulation, un remboursement, et parfois un client qui ne revient pas. Chaque commande fantôme mobilise du temps humain pour réparer une erreur d'affichage.

Le problème inverse est plus silencieux mais tout aussi réel : le sous-affichage. Un stock affiché à zéro alors que la marchandise est disponible, un délai de disponibilité non remonté, un réapprovisionnement invisible en ligne — et la vente est perdue sans que personne ne la compte.

À la longue, un affichage qui ne colle pas à la réalité érode la confiance : les clients doutent des délais, les équipes internes doublent les vérifications manuelles, et le site cesse d'être la source d'information fiable qu'il devrait être.

Les trois patterns de synchronisation

Il existe trois grandes façons de propager une donnée de l'ERP vers la boutique, chacune avec ses compromis.

Le pull : le site interroge l'ERP périodiquement pour rafraîchir stocks et prix. C'est simple à mettre en œuvre et robuste, mais cela introduit une latence (la fraîcheur dépend de l'intervalle d'interrogation) et une charge régulière sur l'ERP, même quand rien n'a changé.

Le push : l'ERP notifie le site dès qu'une donnée bouge. C'est bien plus réactif et cela évite les requêtes inutiles, mais cela suppose que votre ERP soit capable d'émettre ces notifications — ce qui n'est pas toujours le cas des systèmes de niche.

L'event-driven : la propagation passe par des webhooks ou un bus de messages. On combine la réactivité du push avec un vrai découplage : l'ERP et la boutique ne se parlent plus directement, ils échangent des événements que le pipeline absorbe, ordonne et rejoue si besoin.

Choisir le bon niveau de fraîcheur, flux par flux

« Temps réel » est un mot piégé. Dans l'immense majorité des cas, vous n'avez pas besoin de la milliseconde : vous avez besoin d'un quasi temps réel cohérent, où l'écart entre la réalité et l'affichage reste inférieur à ce que votre métier tolère. Viser la milliseconde partout coûte cher sans rien rapporter.

La bonne granularité se décide flux par flux. Un stock à forte rotation, où quelques minutes suffisent à provoquer une survente, justifie une propagation événementielle immédiate. Un prix catalogue, qui change rarement et de façon planifiée, se contente très bien d'un cycle de quelques minutes. On ne calibre pas toute la chaîne sur le flux le plus exigeant : on décide flux par flux.

Architecture technique

Le cœur du dispositif repose sur Symfony Messenger et un système de queues qui découplent l'ERP de la boutique. Chaque changement de stock ou de prix devient un message déposé dans une file ; le pipeline le consomme et propage la mise à jour vers le ou les canaux concernés, généralement en quelques secondes. Ni l'ERP ni la boutique n'attendent l'autre : ils dialoguent à travers la file. Là où la boutique le permet, Mercure pousse même la mise à jour jusqu'à l'interface sans rechargement.

L'observabilité n'est pas une option. On mesure la latence de propagation (le temps réel entre un changement dans l'ERP et son affichage en ligne), la profondeur des files en attente, et des métriques par flux : combien de mises à jour de stock, de prix, de disponibilités par période, et où se situent les éventuels retards. En production, on sait à tout moment si la synchronisation tient sa promesse de fraîcheur.

Éviter les surventes en multi-canal

Dès qu'un même stock alimente plusieurs canaux (une boutique, un portail B2B, des marketplaces), le risque de survente change de nature. La règle est simple : il n'existe qu'une seule source de vérité pour le stock — l'ERP — et tous les canaux en découlent.

La propagation vers les canaux doit être ordonnée : une mise à jour ne doit jamais en écraser une plus récente. Selon le métier, on réserve la quantité au moment de la commande, ou on recalcule la disponibilité depuis l'ERP après chaque mouvement. Ce qu'on ne fait jamais, c'est laisser chaque canal soustraire son stock de son côté : ces décomptes indépendants divergent inévitablement, et c'est précisément là que naissent les surventes.

Résilience : que se passe-t-il quand ça tombe

Une chaîne de synchronisation doit être conçue pour l'incident, pas pour le beau temps. Avec Symfony Messenger et ses queues, un message qui n'a pas pu être délivré n'est pas perdu : il est rejoué. L'indisponibilité momentanée d'un côté n'arrête pas l'autre — les messages s'accumulent dans la file en attendant la reprise.

Les messages qui échouent de façon répétée sont isolés dans une dead letter queue, où on les analyse sans bloquer le flux normal. À la reprise, la file se vide, les mises à jour en attente s'appliquent dans l'ordre, et la cohérence se rétablit d'elle-même, sans intervention manuelle ni ré-import complet.

Faut-il un Kafka ? Dimensionner l'outillage

La tentation de la sur-ingénierie est réelle. Un Kafka est un excellent outil pour des volumes massifs et des architectures à très grande échelle, mais il a un coût d'exploitation (infrastructure, expertise, supervision) rarement justifié pour une PME ou une ETI.

Dans l'immense majorité des cas, Symfony Messenger avec un transport adapté — Redis, AMQP ou même Doctrine selon le volume — couvre le besoin sans introduire une brique lourde à maintenir. On dimensionne sur le volume réel de mises à jour, mesuré, pas sur un volume fantasmé. Kafka reste une option si les chiffres l'imposent ; il n'est presque jamais le point de départ.

Cas concrets

Chez un fabricant français de portes vendant en multi-canal, la difficulté venait d'un OMS interne alimentant à la fois la boutique et plusieurs marketplaces aux formats différents. Une seule source de vérité côté OMS, une propagation ordonnée vers chaque canal : c'est ce qui empêche les décomptes de diverger et les surventes d'apparaître.

Chez un e-commerce de pièces détachées d'électroménager, les stocks provenaient d'un ERP de niche via des imports horaires. Le travail a consisté à fiabiliser ces cycles, à surveiller leur fraîcheur et à rendre visible tout retard de propagation, pour que l'affichage reflète l'ERP sans dérive silencieuse.

Chez un fabricant de blocs-portes, le sourcing multi-dépôt (France et Slovaquie) compliquait la notion de disponibilité. Le stock négatif y était même utilisé comme un signal métier de pré-commande : la synchronisation devait donc transporter cette sémantique fidèlement, et non l'écraser au passage.

Phase de cadrage et durée typique

Tout démarre par une phase de cadrage à prix fixe de 1 à 2 semaines : inventaire des flux à synchroniser, contrainte de fraîcheur de chacun, choix du pattern (pull, push ou event-driven), et cartographie des canaux à alimenter.

Un projet typique se déroule ensuite sur 6 à 10 semaines, selon le nombre de flux et de canaux concernés. L'équipe est de 1 à 2 personnes selon la complexité. Le TJM consultant se situe entre 600 et 800 € HT.

Ce que ce service ne couvre pas

Quelques périmètres sont volontairement exclus. Je ne refonds pas l'ERP lui-même : je le synchronise, je ne le remplace pas. L'hébergement et l'exploitation de vos serveurs restent du ressort de votre infogéreur ou de votre cloud existant.

La mise en place d'un WMS (gestion d'entrepôt) ou d'un TMS (gestion du transport) complet n'entre pas dans ce périmètre. Je connecte vos outils de gestion à votre boutique et j'en garantis la cohérence ; je ne reconstruis pas votre chaîne logistique.

Lien avec les autres services

Cette page s'inscrit dans mon offre connecteurs ERP / système ↔ Magento, qui donne la vue d'ensemble du cluster intégration.

Quand la synchronisation suppose une intégration profonde avec un système sans connecteur standard, elle rejoint le connecteur Magento sur mesure. Et lorsqu'il faut propager stocks et prix vers des places de marché, elle s'articule avec le connecteur Magento ↔ marketplaces.