ETUDE DE CAS
Amore OMS
OMS personnalisé pour des opérations e-commerce multi-marchés.
Aperçu
- Industrie : E-commerce
- Taille de l'entreprise : Opérateur multi-marchés gérant plusieurs boutiques en ligne dans les pays de l'UE
- Livrable : OMS personnalisé (application web opérationnelle)
- Rôle : Architecture système, implémentation full-stack, intégrations, outillage opérationnel
- Points d'intégration : Webhooks de boutique en ligne, APIs/SDKs de transporteurs, exports/imports de tracking, documents opérationnels
- Statut : Système de production actif
- Calendrier : Livraison itérative avec déploiement progressif
Contexte
Le client exploite plusieurs boutiques en ligne et expédie vers différents marchés européens. La prise de commande, l'exécution et l'expédition par transporteur étaient réparties entre des outils spécifiques à chaque plateforme et des workflows propres à chaque transporteur. À mesure que le volume augmentait, la charge opérationnelle augmentait également. Le principal problème n'était pas l'absence de fonctionnalité, mais l'absence d'une vue opérationnelle unique et d'une gestion d'état prévisible.
Problème
Le problème principal n'était pas un manque de fonctionnalités, mais un manque de contrôle et de fiabilité.
- Les commandes étaient ingérées depuis les boutiques sans représentation interne normalisée.
- L'expédition par transporteur nécessitait des étapes différentes selon le fournisseur (étiquettes, formats, tracking).
- Les workflows d'entrepôt (picking/packing) étaient difficiles à standardiser sans outillage.
- Les formats d'adresse et de téléphone variaient selon les pays, créant des échecs de livraison évitables.
- L'opération manquait d'un moyen fiable pour réconcilier les commandes "bloquées" (payées mais non expédiées, expédiées mais non trackées).
Objectifs du projet
- Centraliser la gestion des commandes de toutes les boutiques dans un système opérationnel unique.
- Créer un cycle de vie de commande prévisible avec des états et exceptions explicites.
- Standardiser les flux d'entrepôt (batching, scanning, packing) pour réduire les erreurs humaines.
- Intégrer plusieurs transporteurs avec un comportement d'expédition et de tracking cohérent.
- Permettre l'expansion vers de nouveaux marchés/transporteurs sans réécrire le système central.
Contraintes et défis
- Aucun temps d'arrêt pour la réception des commandes en boutique.
- Multiples taux de TVA et règles d'expédition/exceptions spécifiques par pays.
- Multiples types de paiement (y compris COD) et variantes opérationnelles par marché.
- Différentes APIs de transporteurs, formats d'étiquettes et identifiants de tracking.
- Données héritées et charges utiles incohérentes provenant de systèmes externes.
La solution devait coexister avec l'environnement existant avant de devenir progressivement le système opérationnel principal.
Aperçu de la solution
Nous avons conçu et développé un OMS personnalisé qui agit comme une couche de contrôle opérationnel entre les boutiques et la logistique. L'OMS ne remplace pas les boutiques. Il orchestre l'exécution : ingestion, normalisation, suivi d'état, expédition, tracking et workflows opérationnels.
- Source unique de vérité pour l'état des commandes
- Transitions d'état et réconciliation explicites
- Événements entrants vérifiés (webhooks) et mises à jour déterministes
- Séparation claire entre ingestion, opérations et intégrations de transporteurs
Architecture et approche technique
Le système est implémenté comme une application web opérationnelle pragmatique soutenue par une base de données relationnelle. Le cœur de la conception est le modèle de données : commandes, sites, statuts, lots, produits et artefacts de transporteurs.
- Ingestion des commandes : webhooks vérifiés pour les événements de boutique et la création de commande, avec protection contre les doublons.
- Normalisation : représentation interne cohérente (adresses, numéros de téléphone, règles pays/TVA, SKUs).
- Gestion d'état : statuts explicites et gestion des exceptions pour une prévisibilité opérationnelle.
- Interface opérationnelle : filtrage, triage, préparation de lots et actions par commande pour l'équipe opérationnelle.
- Outillage entrepôt : scan de codes-barres et workflows de lots pour packing/expédition.
- Couche transporteur : intégrations pour génération d'étiquettes, attribution de tracking, annulation et mises à jour de tracking.
- Tâches de fond : réconciliation planifiée et mises à jour de tracking pour finaliser les états opérationnels "en attente".
Chaque intégration est isolée, permettant des modifications sans impacter le système central. Cette structure supporte un déploiement progressif et des extensions prévisibles (nouvelles boutiques, transporteurs, marchés).
Stack technologique
- Backend : PHP
- Base de données : MySQL
- UI : Interface web interne rendue côté serveur (MDL + utilitaires JS)
- Tâches de fond : Tâches planifiées basées sur Cron
- Intégrations : Webhooks Shopify + multiples APIs/SDKs de transporteurs (DPD, GLS, Packeta, UrgentCargus, BRT), exports/imports de tracking
- Documents : Génération PDF pour artefacts opérationnels (étiquettes, documents)
Les choix technologiques ont priorisé la stabilité, la maintenabilité et la familiarité de l'équipe plutôt que des solutions expérimentales.
Processus d'implémentation
- Analyse et cartographie des processus métier
- Définition du cycle de vie et des états des commandes
- Implémentation incrémentale de l'ingestion, du modèle de données interne et de l'interface opérationnelle
- Intégrations de transporteurs ajoutées une par une avec abstractions cohérentes et fallbacks
- Déploiement progressif de l'outillage entrepôt (batching, scanning) et de la réconciliation en tâche de fond
Des points de contrôle réguliers avec le client ont assuré l'alignement entre les décisions techniques et la réalité opérationnelle.
Résultats et impact
- Réduction du traitement manuel des commandes et moins d'erreurs d'expédition.
- Meilleure transparence pour les équipes opérationnelles et support (un seul endroit pour voir l'état des commandes).
- Intégration plus rapide de nouveaux transporteurs/marchés grâce à des frontières d'intégration explicites.
- Une base stable pour l'automatisation et le reporting opérationnel.
L'OMS est devenu une partie critique des opérations quotidiennes.
Réflexion
La décision de se concentrer sur l'orchestration plutôt que le remplacement s'est avérée cruciale. Elle a minimisé les risques et permis au client d'obtenir de la valeur tôt dans le projet. Avec du recul, l'investissement le plus impactant a été la modélisation détaillée en amont des états et transitions de commandes, qui a réduit l'ambiguïté opérationnelle tout au long du développement et des changements futurs.
Résumé
Ce projet démontre comment un système personnalisé bien conçu peut apporter ordre et stabilité à des opérations e-commerce complexes sans perturber l'activité existante. Il illustre une approche pragmatique, pilotée par l'architecture, pour résoudre de vrais problèmes opérationnels.