Interface WMS/ERP B2B : vos revendeurs commandent en autonomie, votre ADV se concentre sur ce qui compte
Traiter les commandes EDI à la main, répondre aux appels de revendeurs qui veulent connaître leur stock disponible, ressaisir les bons de commande dans l'ERP : ces tâches mobilisent une grande part du temps de vos équipes ADV. Une interface WMS/ERP bien construite les automatise entièrement et donne à vos revendeurs l'autonomie qu'ils attendent.
Nos clients types
Le e-commerce B2B a longtemps été traité comme un e-commerce B2C avec quelques fonctionnalités supplémentaires : un compte client dédié, des tarifs par palier, et une facture à la place d'un ticket de caisse. Cette vision sous-estime considérablement la complexité opérationnelle d'un réseau de distribution B2B et les attentes réelles des revendeurs professionnels. La première douleur opérationnelle est le traitement manuel des commandes. Dans la majorité des distributeurs B2B non intégrés, les commandes revendeurs arrivent par plusieurs canaux : email (bon de commande PDF joint), portail EDI externe non connecté à l'ERP (l'opérateur exporte un CSV manuellement), téléphone (l'ADV saisit la commande directement dans l'ERP), ou fax pour les entreprises les moins numérisées. Chaque commande nécessite une intervention humaine : vérification de la disponibilité stock, validation des conditions commerciales du revendeur, saisie dans l'ERP, retour de confirmation. À fort volume de commandes, cela mobilise plusieurs ETP en ADV — pour des tâches dont aucune ne crée de valeur commerciale. La deuxième douleur est la désynchronisation des stocks. L'ERP (SAP B1, Sage X3, Cegid) expose typiquement les stocks avec un décalage de plusieurs heures lié aux cycles de batch de synchronisation avec le WMS. Un revendeur qui commande sur la base d'un stock affiché disponible peut recevoir une confirmation de rupture 24 heures plus tard — ce qui déclenche un appel SAV, une perte de confiance et, à terme, un changement de fournisseur. Dans un contexte où les revendeurs professionnels gèrent leurs propres stocks en flux tendu, ce délai est inacceptable. La troisième douleur est l'absence d'autonomie pour les revendeurs. Un revendeur professionnel qui doit appeler pour connaître son solde de compte, la date de livraison de sa dernière commande, ou la disponibilité d'un produit en rupture chez son propre client perd un temps précieux. Les meilleurs distributeurs B2B ont compris que le portail self-service n'est pas un luxe — c'est un argument commercial différenciant. Ceux qui ne l'offrent pas perdent des revendeurs au profit de concurrents qui le font. La quatrième douleur est la gestion des retours et des avoirs. Sans interface intégrée, une demande de retour marchandise (RMA) déclenche un processus entièrement manuel : email du revendeur, validation par le commercial, bon de retour émis manuellement, réception physique au dépôt, contrôle qualité, avoir saisi dans l'ERP. Ce processus prend plusieurs jours ouvrés et génère une insatisfaction directe chez le revendeur qui attend son avoir pour commander à nouveau.
L'architecture Nehos pour une interface WMS/ERP e-commerce B2B repose sur trois couches : le middleware d'intégration (orchestrateur central), le portail revendeurs (interface utilisateur), et les connecteurs WMS/ERP (adaptateurs système). Le middleware d'intégration est développé en Nest.js (TypeScript), déployé chez un hébergeur français (par exemple sur OVHcloud Managed Kubernetes) avec haute disponibilité et auto-scaling. Il expose une API REST interne consommée par le portail revendeurs et orchestre tous les flux entre le WMS, l'ERP et les partenaires EDI. L'API de disponibilité stock interroge le WMS en temps réel (pas en batch) : chaque requête de stock depuis le portail déclenche un appel WMS avec un cache Redis de courte durée pour les SKUs à faible rotation, et aucun cache pour les SKUs à fort mouvement durant les pics de commandes. Les flux EDI sont gérés selon le standard EDIFACT D96A ou X12 selon les revendeurs partenaires. Les messages traités : ORDERS (commande entrante revendeur), ORDRSP (confirmation de commande avec disponibilités confirmées), DESADV (avis de départ marchandise avec numéro de suivi transporteur), INVOIC (facture électronique). Le traitement est entièrement automatisé : un ORDERS entrant déclenche une vérification de disponibilité temps réel dans le WMS, une réservation de stock, une insertion commande dans l'ERP (via SAP BAPI ou API Sage), et un ORDRSP de confirmation rapide. Le portail revendeurs est développé en Next.js App Router (TypeScript, Tailwind CSS). Il est accessible sur desktop et tablette, avec une authentification sécurisée (JWT + refresh tokens, MFA optionnel). Chaque compte revendeur a accès à son catalogue avec disponibilités temps réel, ses conditions commerciales personnalisées (remises, délais de paiement, franco de port), son tableau de bord de commandes (en cours, expédiées, facturées, retours en cours), ses factures et avoirs téléchargeables, et un formulaire de demande de retour (RMA) déclenché automatiquement dans le WMS. Le module de gestion des retours est particulièrement utile aux revendeurs : le revendeur soumet sa demande en quelques minutes (références, quantités, motif, photos optionnelles), reçoit un bon de retour PDF automatiquement généré, et suit le statut de son avoir en temps réel depuis le portail. Le délai de traitement des retours baisse nettement.
Middleware d'intégration
Nest.js, orchestre les flux entre WMS, ERP et partenaires EDI sans les remplacer
EDI EDIFACT
ORDERS, ORDRSP, DESADV, INVOIC (D96A) ou X12 850/855, traités automatiquement
Stock temps réel
interrogation directe du WMS, sans batch nocturne
Portail revendeurs
Next.js : catalogue, commandes, suivi, factures et avoirs, retours (RMA), conditions commerciales par revendeur
#Le problème : pourquoi interface WMS/ERP B2B est un enjeu critique
Le e-commerce B2B a longtemps été traité comme un e-commerce B2C avec quelques fonctionnalités supplémentaires : un compte client dédié, des tarifs par palier, et une facture à la place d'un ticket de caisse. Cette vision sous-estime considérablement la complexité opérationnelle d'un réseau de distribution B2B et les attentes réelles des revendeurs professionnels.
La première douleur opérationnelle est le traitement manuel des commandes. Dans la majorité des distributeurs B2B non intégrés, les commandes revendeurs arrivent par plusieurs canaux : email (bon de commande PDF joint), portail EDI externe non connecté à l'ERP (l'opérateur exporte un CSV manuellement), téléphone (l'ADV saisit la commande directement dans l'ERP), ou fax pour les entreprises les moins numérisées.
Chaque commande nécessite une intervention humaine : vérification de la disponibilité stock, validation des conditions commerciales du revendeur, saisie dans l'ERP, retour de confirmation. À fort volume de commandes, cela mobilise plusieurs ETP en ADV — pour des tâches dont aucune ne crée de valeur commerciale.
La deuxième douleur est la désynchronisation des stocks. L'ERP (SAP B1, Sage X3, Cegid) expose typiquement les stocks avec un décalage de plusieurs heures lié aux cycles de batch de synchronisation avec le WMS. Un revendeur qui commande sur la base d'un stock affiché disponible peut recevoir une confirmation de rupture 24 heures plus tard — ce qui déclenche un appel SAV, une perte de confiance et, à terme, un changement de fournisseur. Dans un contexte où les revendeurs professionnels gèrent leurs propres stocks en flux tendu, ce délai est inacceptable.
La troisième douleur est l'absence d'autonomie pour les revendeurs. Un revendeur professionnel qui doit appeler pour connaître son solde de compte, la date de livraison de sa dernière commande, ou la disponibilité d'un produit en rupture chez son propre client perd un temps précieux.
Les meilleurs distributeurs B2B ont compris que le portail self-service n'est pas un luxe — c'est un argument commercial différenciant. Ceux qui ne l'offrent pas perdent des revendeurs au profit de concurrents qui le font.
La quatrième douleur est la gestion des retours et des avoirs. Sans interface intégrée, une demande de retour marchandise (RMA) déclenche un processus entièrement manuel : email du revendeur, validation par le commercial, bon de retour émis manuellement, réception physique au dépôt, contrôle qualité, avoir saisi dans l'ERP. Ce processus prend plusieurs jours ouvrés et génère une insatisfaction directe chez le revendeur qui attend son avoir pour commander à nouveau.
#Notre approche en 4 phases
#Phase 1 : Audit des flux et cartographie SI (semaines 1-4)
Inventaire des systèmes en présence (ERP, WMS, TMS, outil de gestion des revendeurs), cartographie des flux de commandes actuels (EDI, email, fax, portail legacy), identification des points de saisie manuelle et des délais de traitement. Définition des flux cibles et des règles métier (règles d'allocation stock, règles de priorisation commandes, conditions commerciales par revendeur).
Voir notre expertise : intégration ERP e-commerce.
#Phase 2 : Développement du middleware d'intégration (semaines 5-10)
Développement du middleware de bus d'intégration (Nest.js + TypeScript, déployé chez un hébergeur français, par exemple sur OVHcloud Managed Kubernetes). Connexion WMS (Manhattan Associates, Hardis Reflex, ou WMS custom) via API REST ou webhook. Connexion ERP (SAP Business One, Sage X3) via API ou IDocs. Implémentation des flux EDI ORDERS (réception commandes), ORDRSP (confirmation), DESADV (avis d'expédition), INVOIC (facture) selon le standard EDIFACT D96A ou X12 850/855.
Voir notre expertise : portail revendeurs B2B.
#Phase 3 : Développement du portail revendeurs (semaines 11-16)
Développement du portail B2B en Next.js App Router (TypeScript, Tailwind CSS). Fonctionnalités : catalogue produits avec disponibilité stock temps réel, passation de commandes (panier, conditions commerciales personnalisées, bon de commande PO), suivi de commandes en temps réel (statuts WMS), historique de commandes et factures, gestion des retours (RMA). Authentification multi-niveaux (revendeur, commercial, DSI distributeur). Interface responsive desktop/tablette.
Voir notre expertise : traitement EDI e-commerce B2B.
#Phase 4 : Tests de charge, recette et déploiement (semaines 17-20)
Tests de charge (k6 ou Gatling) simulant les pics de commandes (période de lancement catalogue, salons professionnels). Recette avec un panel de revendeurs bêta. Formation des équipes ADV et logistique. Déploiement progressif : une première vague de revendeurs, puis tous les revendeurs après stabilisation.
Voir notre expertise : guide intégration e-commerce B2B.
#Repères
| Repère | Ce que c'est |
|---|---|
| Middleware d'intégration | Nest.js, orchestre les flux entre WMS, ERP et partenaires EDI sans les remplacer |
| EDI EDIFACT | ORDERS, ORDRSP, DESADV, INVOIC (D96A) ou X12 850/855, traités automatiquement |
| Stock temps réel | interrogation directe du WMS, sans batch nocturne |
| Portail revendeurs | Next.js : catalogue, commandes, suivi, factures et avoirs, retours (RMA), conditions commerciales par revendeur |
#Exemple de situation
#Contexte
Un distributeur B2B d'équipement professionnel avec un large réseau de revendeurs, un WMS Manhattan Associates SCALE et un ERP SAP Business One. Les commandes arrivent par EDI via un portail AS2 non intégré à SAP, par email (PDF ressaisi) et par téléphone, le stock exposé aux revendeurs est celui d'un batch nocturne et il n'existe aucun portail self-service.
#Défi
Automatiser le traitement des commandes pour réduire la ressaisie par l'ADV, exposer les stocks du WMS en temps réel aux revendeurs, et déployer un portail self-service sans remplacer le WMS ni l'ERP.
#Approche
Middleware Nest.js hébergé en France avec haute disponibilité. Connecteur WMS via API REST (disponibilité, réservation, réception des retours), connecteur ERP via l'API Service Layer (commandes, avoirs, compte revendeur). Traitement EDI EDIFACT : ORDERS, ORDRSP, DESADV, INVOIC. Portail Next.js avec authentification JWT, catalogue, commandes, suivi, factures, RMA. Déploiement progressif : phase bêta avec un échantillon de revendeurs, puis déploiement général.
#Ce qu'on mesure
Le volume de commandes traité manuellement, la précision du stock exposé, le taux de service revendeurs, le délai de traitement des retours, la part de commandes traitées sans intervention humaine, la satisfaction des revendeurs. On mesure ces points quelques mois après le déploiement, sans résultat promis à l'avance.
#Pourquoi Nehos pour interface WMS/ERP B2B
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes. Nos expertises connexes : traitement EDI e-commerce B2B, guide intégration e-commerce B2B, synchronisation stocks temps réel WMS.
Côté hébergement, nous pouvons déployer chez un hébergeur français (par exemple OVHcloud, datacenters en France) et recourir à des modèles open source (Mistral) quand la performance le permet. Le choix se fait avec vous, selon vos contraintes de souveraineté.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur l'interface WMS/ERP pour e-commerce B2B
L'architecture middleware Nehos est conçue pour s'adapter aux systèmes existants, pas pour les remplacer. Côté WMS : Manhattan Associates SCALE et WMoS, Hardis Reflex, Generix WMS, Mecalux Easy WMS, et les WMS custom exposant une API REST ou des fichiers d'échange SFTP. Côté ERP : SAP Business One (API Service Layer), SAP S/4HANA (OData), Sage X3 (API REST), Cegid Y2 (API), Microsoft Dynamics 365 Business Central (API REST native). Pour les ERP sans API moderne (ERP legacy avec seulement des interfaces SFTP ou des connexions base de données), un adaptateur de données est développé. L'audit initial identifie précisément les mécanismes d'interface disponibles pour chaque système. Voir notre service intégration ERP e-commerce.
Le flux EDI automatisé fonctionne en cinq étapes. 1) Réception du message ORDERS (commande) via AS2, SFTP ou API REST selon le protocole du partenaire commercial. 2) Parsing et validation du message (format EDIFACT D96A ou X12 850) par le middleware : vérification des références SKU, des quantités, de l'identité du revendeur. 3) Interrogation temps réel du WMS pour vérification des disponibilités et réservation du stock (si disponible) ou gestion de la rupture partielle (substitution, backorder selon les règles métier configurées). 4) Création de la commande dans l'ERP et association au compte revendeur. 5) Émission du message ORDRSP (confirmation avec disponibilités confirmées et date de livraison estimée) rapidement. Les cas d'exception (rupture totale, revendeur bloqué pour impayé, article restreint) déclenchent une alerte manuelle vers le commercial responsable.
Oui — c'est même une fonctionnalité centrale du portail revendeurs Nehos. Les conditions commerciales (remises sur catalogue, remises par famille produit, franco de port, délais de paiement, conditions de paiement : virement 30 jours fin de mois, prélèvement, traite) sont importées depuis l'ERP au niveau du compte revendeur et appliquées automatiquement dans le portail. Chaque revendeur voit ses prix nets (après application de sa remise) directement dans le catalogue et le panier. Un revendeur qui n'a pas encore de conditions commerciales accordées par son commercial voit les prix catalogue publics et peut demander un devis. Pour les distributeurs avec des structures de tarification très complexes (paliers par volume mensuel, prix contractuels par appel d'offre), un moteur de pricing middleware est développé en amont de l'interface ERP.
La gestion des ruptures partielles est configurée selon les règles métier de chaque distributeur. Trois comportements sont possibles pour une commande partiellement en rupture : livraison partielle avec backorder automatique (envoi immédiat du disponible, livraison du solde dès réapprovisionnement), attente de la disponibilité complète avant expédition (règle préférable pour les commandes à usage immédiat), ou substitution automatique par un produit équivalent (si le WMS expose des produits de substitution). Ces règles sont paramétrables par famille produit et par revendeur. Le portail revendeurs affiche le statut de chaque ligne de commande en temps réel : expédiée, en préparation, en backorder avec date de réapprovisionnement estimée. Une alerte email ou SMS est envoyée au revendeur dès que le statut change.
Un site e-commerce B2C adapté au B2B (Shopify B2B, WooCommerce avec un plugin B2B) gère correctement les cas simples : compte client dédié, tarifs personnalisés, facture en PDF. Mais il atteint rapidement ses limites sur les cas B2B avancés : processus d'approbation des commandes (un acheteur soumet, un responsable approuve), gestion des budgets par centre de coût, commandes sur bon de commande (PO) avec référence obligatoire, rapprochement comptable automatique entre facture fournisseur et bon de réception. Le portail revendeurs Nehos est conçu dès le départ pour ces cas avancés : workflow d'approbation configurable, champ PO obligatoire, accès multi-utilisateurs par compte revendeur (acheteur, responsable, comptable), export des factures en format compatible avec le logiciel comptable du revendeur (Quadratus, Ciel, Sage Compta).
La sécurité du portail revendeurs est dimensionnée en fonction de la sensibilité des données exposées (conditions commerciales confidentielles, volumes d'achats, niveaux de remise). L'authentification repose sur JWT avec refresh tokens de courte durée (durées définies avec la DSI), MFA optionnel ou obligatoire selon le profil de risque. L'isolation des données revendeurs est garantie par un middleware de contrôle d'accès qui vérifie à chaque requête que le revendeur authentifié ne peut accéder qu'à ses propres données (row-level security). Les logs d'accès sont conservés pendant une durée conforme au RGPD et analysés pour détecter les comportements anormaux (connexion depuis une IP inhabituelle, volume de téléchargement anormal). Les connexions sont chiffrées TLS 1.3, les données sensibles chiffrées au repos (AES-256).