Intégration d’un WMS pour une petite activité e-commerce
La question de savoir quand un système de gestion d’entrepôt vaut la peine d’être intégré se pose plus tôt que la plupart des petites activités e-commerce ne le prévoient. Les feuilles de calcul fonctionnent bien jusqu’à un certain point — et le point de rupture n’est généralement pas le volume de commandes mais la complexité des commandes : plusieurs références produit (SKU) avec suivi des variantes, des lots de produits, des commandes en attente de réapprovisionnement sur plusieurs sites de traitement des commandes, ou le besoin de chiffres précis de stock disponible à la vente (ATP) au moment du paiement. Cet article couvre notre expérience d’intégration de GreaterWMS avec une petite activité e-commerce, ce qui a bien fonctionné, ce qui a nécessité plus de conception que prévu, et les cas où les feuilles de calcul restent la bonne réponse.
Pourquoi GreaterWMS
GreaterWMS est un système de gestion d’entrepôt open source avec une API REST, un backend Django et un frontend Vue. Il prend en charge la gestion des stocks multi-entrepôts, le suivi des lots, la gestion des ordres d’entrée et de sortie, et des rapports de base. La base de code est activement maintenue et la documentation API, bien que non exhaustive, couvre les opérations essentielles.
Nous l’avons choisi plutôt que des alternatives hébergées pour deux raisons. Premièrement, nous exploitions déjà une infrastructure auto-hébergée et ne voulions pas ajouter une autre dépendance SaaS avec une tarification par commande à grande échelle. Deuxièmement, la nature open source signifiait que nous pouvions étendre le modèle de données sans attendre qu’un fournisseur traite une demande de fonctionnalité. Pour une petite activité avec des besoins spécifiques en matière de suivi des dates de péremption par lot, cette flexibilité comptait.
Notre déploiement est une pile Docker Compose avec l’application Django, PostgreSQL et Redis ; le fichier Compose du projet d’origine ne fournit que les conteneurs frontend et backend, et les paramètres par défaut utilisent SQLite. Sur un VPS modeste, il tourne confortablement aux côtés d’autres services. La configuration initiale prend quelques heures ; le travail d’intégration prend beaucoup plus de temps.
Schémas d’intégration de l’API
GreaterWMS utilise l’authentification par jeton. Chaque utilisateur possède un jeton (la valeur openid), que vous transmettez dans un en-tête de requête personnalisé token plutôt que comme jeton Bearer dans l’en-tête Authorization. Il n’existe pas de flux OAuth ni de mécanisme de rotation des clés API intégré, ce qui signifie que vous devriez créer un utilisateur de service dédié avec des permissions minimales plutôt que d’utiliser un compte administrateur.
L’API est globalement RESTful avec des charges utiles JSON. Les principales ressources avec lesquelles vous interagissez pour une intégration e-commerce sont : les marchandises (votre catalogue de produits en termes WMS), les stocks (niveaux de stock actuels par entrepôt et marchandise), les ordres d’entrée (bons de commande et retours) et les ordres de sortie (commandes clients pour traitement logistique).
Un principe que nous avons établi dès le début : ne jamais appeler l’API WMS de manière synchrone depuis le parcours de paiement. Le WMS ne se trouve pas sur votre parcours critique de la transaction, et s’il est lent ou temporairement indisponible, cela ne devrait pas affecter la capacité de votre client à finaliser un achat. Toutes les interactions WMS passent par une file d’attente asynchrone. Le paiement enregistre la commande dans votre base de données principale et publie un événement. Un worker en arrière-plan récupère l’événement et crée l’ordre de sortie dans GreaterWMS. Le worker relance les opérations échouées avec une temporisation exponentielle et déclenche une alerte si l’échec persiste. Ce découplage est non négociable.
Synchronisation des commandes
L’appel de création d’ordre de sortie prend un identifiant de marchandise, une quantité et des informations d’adresse de destination. La correspondance entre les lignes de commande de votre e-commerce et les identifiants de marchandises WMS doit être maintenue explicitement. Nous stockons l’identifiant de marchandise WMS comme champ supplémentaire sur chaque variante de produit dans notre base de données de catalogue. Cette correspondance est définie manuellement lors de la création d’un nouveau produit et vérifiée dans le worker de synchronisation avant d’envoyer la requête de création d’ordre de sortie.
La synchronisation des statuts se déroule dans le sens opposé : GreaterWMS met à jour le statut de l’ordre de sortie à mesure que l’entrepôt le traite, et votre système e-commerce doit refléter cela. GreaterWMS ne transmet pas les changements de statut ; vous devez interroger le système. Nous exécutons une tâche d’interrogation périodique toutes les quelques minutes qui interroge les ordres de sortie avec un statut « en cours » et vérifie si le statut a changé en « expédié » ou « annulé ». Lorsque c’est le cas, nous mettons à jour la commande correspondante dans notre base de données e-commerce et déclenchons toute action en aval — e-mails de notification clients, mises à jour des numéros de suivi.
L’idempotence lors de la création d’ordres de sortie est importante. Si le worker en arrière-plan effectue une nouvelle tentative après un échec transitoire, il ne doit pas créer d’ordres de sortie en double dans GreaterWMS. Nous stockons l’identifiant d’ordre de sortie WMS sur notre enregistrement de commande interne immédiatement après un appel de création réussi. Lors d’une nouvelle tentative, le worker vérifie si un identifiant WMS existe déjà avant d’effectuer l’appel de création. Si c’est le cas, le worker saute la création et procède à l’action en aval qu’il tentait. Cette vérification ne couvre pas un appel de création qui réussit dans GreaterWMS mais dont la réponse est perdue avant l’enregistrement de l’identifiant ; ces cas nécessitent encore un rapprochement avec le WMS avant une nouvelle tentative.
Mises à jour des stocks
Maintenir la synchronisation des quantités en stock de votre e-commerce avec le WMS est la partie qui nécessite le plus d’attention continue. Il y a deux directions : votre plateforme e-commerce a besoin de niveaux de stock précis pour éviter les ventes au-delà du stock disponible, et le WMS doit refléter les achats et les retours qui lui sont extérieurs.
Pour la lecture des niveaux de stock, nous récupérons à intervalles réguliers des instantanés des stocks depuis l’API de gestion des stocks de GreaterWMS et écrivons les chiffres dans un cache Redis que la boutique en ligne lit. L’intervalle d’interrogation dépend de votre vitesse de vente. Pour les produits à rotation lente, une interrogation par heure suffit. Pour les produits qui se vendent par rafales, vous avez besoin soit d’un intervalle plus court, soit d’un modèle de réservation — où un client qui ajoute un article au panier réserve temporairement le stock quel que soit le cycle de synchronisation WMS.
Les retours constituent le cas le plus complexe. Un article retourné peut réintégrer le stock, être dirigé vers un emplacement de quarantaine pour inspection, ou être passé en perte. GreaterWMS dispose d’un flux d’ordres d’entrée pour les retours, mais la correspondance entre vos états de retour e-commerce et les états d’ordres d’entrée WMS nécessite une conception explicite. Nous avons créé une machine à états qui traduit les codes de motif de retour du système e-commerce en codes de traitement du WMS, et nous examinons la correspondance avec l’équipe de l’entrepôt chaque fois qu’un nouveau motif de retour est ajouté. Sans cette correspondance, le stock retourné ne réapparaît pas dans les stocks disponibles, sans qu’aucune alerte ne soit émise.
Conditions de concurrence et stock tampon
Même avec une synchronisation des stocks basée sur l’interrogation périodique, des conditions de concurrence sont possibles. Si deux commandes arrivent simultanément et que les deux lisent le même niveau de stock mis en cache avant que l’une ou l’autre ait été reflétée dans le WMS, vous pouvez vendre au-delà du stock disponible à hauteur du nombre d’unités vendues pendant l’intervalle d’interrogation. Pour les produits où la survente est inacceptable — articles en édition limitée, produits périssables avec des contraintes de lot strictes — la bonne approche est une couche de réservation qui décrémente une quantité disponible locale au moment du paiement et effectue un rapprochement asynchrone avec le WMS.
Une mesure plus simple est le stock tampon : maintenir une quantité disponible dans votre base de données e-commerce qui correspond au niveau de stock WMS moins une petite réserve. Les commandes épuisent ce tampon. Lorsque le tampon atteint zéro, le produit apparaît comme en rupture de stock même si le WMS montre encore des unités. Cela crée un petit risque de détenir des stocks que les clients ne peuvent pas commander, mais cela réduit le risque de survente et ne nécessite aucune logique de réservation. Pour la plupart des petites opérations, l’approche tampon est le bon compromis.
Quand choisir un WMS plutôt qu’un tableur
Un système de gestion d’entrepôt ajoute une complexité d’intégration, une charge opérationnelle et un nouveau système à maintenir. Avant de s’engager dans une intégration, il faut évaluer honnêtement si les problèmes que vous essayez de résoudre nécessitent réellement un WMS.
Les feuilles de calcul sont adéquates lorsque : votre nombre de SKU est petit et stable, vous avez un seul entrepôt ou site de traitement des commandes, les commandes sont traitées manuellement et le volume est faible, et vous n’avez pas besoin d’un stock disponible à la vente (ATP) en temps réel au moment du paiement. Dans ce cas, une intégration WMS coûte plus cher à construire et à maintenir que les problèmes qu’elle résout.
Un WMS commence à être rentable lorsque : vous avez plusieurs entrepôts ou emplacements de prélèvement, vous avez besoin d’un suivi des lots pour des raisons de conformité ou de qualité, votre taux de retour est suffisamment élevé pour que les articles retournés doivent être traités de façon systématique, ou votre traitement des commandes est automatisé et nécessite une réservation de stock précise pour éviter les ventes au-delà du stock disponible. Ce sont des problèmes opérationnels que les feuilles de calcul ne peuvent pas résoudre avec un niveau de rigueur raisonnable.
Le travail d’intégration décrit dans cet article a pris plusieurs semaines de travail d’ingénierie, y compris les tests. Ce temps aurait pu financer une quantité significative de travail manuel de coordination de l’entrepôt. Soyez précis sur les problèmes que vous résolvez et sur la question de savoir si le logiciel est le bon outil avant de commencer.