Pourquoi les ERP modernes échouent encore à maîtriser parfaitement le Drop Shipment B2B international
Le Drop Shipment (ou livraison directe) est devenu un modèle incontournable dans le commerce B2B international.
Il promet souplesse, réduction des stocks, et agilité commerciale.
En 2024, selon une étude publiée par DHL Supply Chain et Forrester Research, environ 25 à 30 % des transactions B2B mondiales utilisent déjà un modèle de livraison directe (Drop Shipment), notamment dans les secteurs industriels, de la distribution spécialisée, et de l’électronique.
Et la tendance s’accélère :
Selon Gartner et Statista, ce pourcentage devrait atteindre 40 à 45 % d’ici fin 2025, à mesure que les entreprises cherchent à optimiser leur capital immobilisé et à raccourcir leurs chaînes d’approvisionnement.
Mais derrière cette adoption massive se cache une réalité :
la plupart des ERP, même les plus puissants, ont encore du mal à gérer proprement le Drop Shipment.
Entre responsabilités juridiques croisées, incoterms multiples, attentes clients en matière de conformité et logistique éclatée, le modèle révèle toute sa complexité.
Voyons en détail où les ERP plafonnent, et comment contourner ces limites intelligemment.
1 – Modèle opérationnel : double flux, double responsabilité
Dans le Drop Shipment B2B international, deux flux coexistent :
L’achat fournisseur (toujours en FOB) : Tu achètes en Free On Board : la marchandise devient ta propriété dès qu’elle est chargée sur le navire, au port de départ.
La vente client (en POO, POE ou MDP) :
- POO (Port of Origin) : le client prend la marchandise au port de départ.
- POE (Port of Entry) : tu gères l’import, et le client récupère au port d’arrivée.
- MDP (Modified Duty Paid) : tu avances certains frais douaniers avant transfert de propriété.
Cette double responsabilité suppose une parfaite coordination des flux physiques, financiers, et contractuels.
2 – Où les ERP montrent leurs limites
A. Suivi du stock en mer : un angle mort stratégique :
Un achat en FOB implique que tu es propriétaire d’un stock en mer bien avant qu’il n’arrive à ton client ou dans ton entrepôt.
Mais dans les faits :
- Très peu d’ERP proposent un entrepôt virtuel « en transit » pour enregistrer ce stock.
- La valorisation comptable de ce stock est souvent ignorée ou approximative.
- Il n’y a pas de visibilité native sur :
- Les quantités en transit,
- Les statuts d’expédition (en route, en attente, en dédouanement),
- Les dates d’arrivée estimées.
Cela peut générer :
- Des écarts d’inventaire,
- Une vision floue du besoin réel d’approvisionnement,
- Des erreurs dans les prévisions financières et les facturations.
Et même lorsqu’un entrepôt virtuel en mer est mis en place, une autre complexité apparaît : La nécessité de tracker précisément l’arrivage des marchandises à travers différents couloirs maritimes, avec leurs propres contraintes :
- Itinéraires variables,
- Temps de transit fluctuants,
- Retards logistiques,
- Réassort par différents ports d’escale.
Un simple entrepôt en mer ne suffit pas : il faut un vrai moteur de suivi logistique dynamique.
Comment les entreprises réagissent aujourd’hui :
- Des développements spécifiques sont souvent nécessaires dans l’ERP pour suivre les conteneurs au niveau voyage et non plus seulement au niveau stock.
- Certains déploient des extensions spécialisées comme des modules d’Inbound Container Management (ICM) pour :
- Suivre chaque conteneur individuellement,
- Mettre à jour automatiquement les statuts d’avancement,
- Anticiper les impacts sur le planning d’approvisionnement et la planification client.
Mon avis :
Ne pas traiter sérieusement le stock en mer, c’est avancer à l’aveugle sur toute la supply chain amont. Un ERP moderne devrait nativement intégrer :
- Le suivi multi-couloirs,
- Les statuts d’avancement des conteneurs,
- La mise à jour dynamique des dates (SC, ETD, ETA) et de la disponibilité réelle.
A ce jour, seuls les ERP disposant d’un module Supply Chain avancé, ou connectés à des TMS/SCM externes, parviennent à le faire efficacement.
B. Incoterms croisés : une gymnastique juridique mal modélisée
La majorité des ERP ne gèrent pas bien :
- Les transferts de responsabilité différés (FOB vs POE).
- Les obligations fiscales et douanières en MDP.
- Le découplage entre réception comptable, livraison physique, et facturation client.
Résultat : des anomalies entre ce que voit le service logistique, ce que déclare le service comptable, et ce que vit le client final.
C. Étiquetage d’expédition : réservé aux ERP haut de gamme
L’étiquetage logistique est essentiel dans le drop shipment, notamment pour les clients distributeurs ou retail. Mais très peu d’ERP standards permettent :
- De générer automatiquement des étiquettes d’expédition (UCC, GS1-128, QR…),
- De lier l’étiquetage au bon de livraison,
- De transmettre les étiquettes au fournisseur à temps.
- Seuls les ERP avancés s’en sortent :
- Microsoft Dynamics 365 SCM (avec son Warehouse Management)
- SAP S/4HANA avec EWM
- Oracle SCM, Infor CloudSuite
Ils intègrent des Shipment Label Managers natifs, capables de :
- Générer les étiquettes selon les formats attendus,
- Les lier à des règles de packing,
- Les pousser automatiquement aux fournisseurs.
Pour les autres ERP ? Il faut passer par des outils externes (SendCloud, EasyPost, etc..) ou effectuer des développements spécifiques avec toute la complexité d’intégration que cela implique.
D. Packing Rules : une exigence logistique trop souvent ignorée dans le Drop Shipment
avant d’aborder ce point, qu’est-ce que les Packing Rules ?
Les Packing Rules sont un ensemble de règles d’emballage imposées par le client sur la manière dont les produits doivent être :
- Conditionnés (nombre de pièces par carton),
- Groupés (nombre de cartons par palette),
- Pesés (limite de poids par unité logistique),
- Séparés (pas de mélange de références sur une même palette).
Ces règles ne sont pas des caprices client mais elles permettent de préparer la réception, recevoir, scanner, ranger et vendre efficacement la marchandise dans ses entrepôts ou points de distribution.
Qui impose ces règles ?
Ce sont généralement :
- Des centrales d’achat (retail, grande distribution),
- Des réseaux logistiques très industrialisés (automobile, cosmétique, pharma…),
- Ou des distributeurs B2B qui doivent respecter eux-mêmes des contraintes en aval.
Les clients imposent ces règles dans le cahier des charges logistique, qui fait partie intégrante du contrat commercial.
Un fournisseur qui respecte ces exigences clients (qui ne sont souvent pas obligatoire) :
- Montre qu’il comprend le besoin de son client,
- Qu’il est intégré dans son fonctionnement logistique,
- Et qu’il peut être considéré comme un partenaire durable.
Et côté ERP ?
Malheureusement, la plupart des ERP ne proposent aucun contrôle natif sur ces règles :
- Pas de validation automatique des contraintes à la création de la commande fournisseur.
- Pas d’alerte lors du packing si les seuils sont dépassés.
- Aucun rejet automatique en cas de non-conformité.
Seuls certains systèmes WMS avancés ou extensions tierces permettent :
- D’enregistrer les Packing Rules client par produit ou famille de produits,
- De les intégrer dans le processus de commande,
- Et de valider dynamiquement la conformité avant expédition.
Mon Avis :
Les Packing Rules ne sont pas un détail : ce sont un pilier de la relation client dans les opérations B2B.
Les ignorer, c’est :
- Compromettre l’efficacité opérationnelle,
- Mettre en danger la satisfaction client,
- Et s’exposer à des ruptures commerciales, parfois brutales.
Un ERP moderne devrait pouvoir intégrer ces contraintes comme des règles métier à part entière, au même titre que les prix ou les délais.
E. Flux physique vs flux financier : désynchronisation chronique en Direct Shipment
Le distributeur devient responsable avant même d’avoir physiquement touché la marchandise.
Mais :
- L’ERP attend souvent une réception physique pour déclencher la facture fournisseur.
- La facturation client est bloquée faute d’un événement logistique déclencheur.
- Les écritures comptables sont souvent manipulées manuellement pour s’aligner.
Cela crée une situation fragile, avec des risques fiscaux, des écarts d’audit, et une comptabilité d’engagement mal maîtrisée.
3 – Pourquoi cette situation persiste ?
Pour comprendre pourquoi la majorité des ERP échouent encore à gérer correctement le Drop Shipment, il faut revenir à leur ADN même. Une architecture historiquement pensée pour des flux linéaires.
Les ERP classiques ont été conçus dans les années 80-90 pour accompagner :
- Des industries manufacturières traditionnelles,
- Des réseaux de distribution physique standardisés,
Leur logique fondamentale est simple :
Acheter ➔ Réceptionner ➔ Stocker ➔ Vendre
Tout le modèle repose sur une chaîne d’opérations séquentielles et localisées :
- Tu achètes un produit auprès d’un fournisseur.
- Tu le réceptionnes physiquement dans ton entrepôt.
- Tu le stockes et tu le valorises.
- Tu le vends et tu le livres depuis ta propre réserve.
Le Drop Shipment casse cette séquence traditionnelle
Le modèle Direct Shipment (Drop Shipment) introduit des ruptures majeures :
- Tu vends avant même d’avoir réceptionné.
- Tu délègues totalement ou partiellement la livraison à un tiers (fournisseur).
- Tu ne stockes jamais physiquement la marchandise.
- Tu portes une responsabilité commerciale et financière sur une marchandise que tu ne manipules pas.
Cela remet en cause plusieurs piliers sur lesquels reposaient les ERP :
- Le lien automatique entre réception physique et entrée en stock.
- Le lien automatique entre stock disponible et capacité à vendre.
- Le lien entre livraison propre et satisfaction client.
En Drop Shipment, ces trois liens sont brisés. Et ça, peu de systèmes sont nativement capables de le comprendre et de l’orchestrer. Même les ERP cloud modernes héritent des réflexes anciens, Au point qu’on pourrait croire que les nouveaux ERP cloud (ex : Dynamics 365, SAP S/4HANA Cloud, Oracle NetSuite) corrigent ce biais. Ce n’est que partiellement vrai.
Pourquoi ?
Parce que même dans les architectures cloud :
- La structure de base reste souvent modélisée autour des flux traditionnels.
- Les modules logistiques avancés (inbound shipment, warehouse management, etc.) sont encore pensés pour gérer du stock physique avant de gérer des flux indirects.
- L’intégration entre flux commerciaux, flux logistiques et flux financiers reste fragile sans extensions spécialisées.
En clair :
- Le Cloud apporte de la flexibilité technique (connectivité, API, scalabilité),
- Mais pas nécessairement une révolution fonctionnelle sur la manière dont les flux drop shipment devraient être pensés.
Pourquoi les ERP n’ont pas encore basculé complètement ?
Pour trois raisons principales :
- Le poids historique : Les ERP restent lourdement attachés à leur logique initiale de manufacturing et distribution classique.
- La complexité métier : Le Drop Shipment impose des logiques conditionnelles complexes, difficiles à standardiser sans perdre en robustesse.
- La fragmentation du besoin client : Tous les secteurs n’ont pas encore massivement basculé sur le modèle direct shipment, donc peu d’éditeurs ERP veulent investir massivement pour une minorité (même si cette minorité devient stratégique).
4. Que faire pour contourner intelligemment ces limites ?
Le Drop Shipment, malgré ses défis, peut être maîtrisé si l’entreprise met en place les bonnes stratégies dès l’amont.
Voici les cinq axes majeurs à activer pour construire un modèle robuste et fiable :
Créer un entrepôt virtuel « en mer » dans l’ERP
Il est indispensable de créer un entrepôt dédié pour le stock en transit maritime, afin de :
- Enregistrer précisément les quantités en propriété mais non réceptionnées.
- Valoriser le stock en transit pour une comptabilité plus fiable (impact direct sur le bilan et le calcul du BFR).
- Gérer des statuts dynamiques comme « embarqué », « en mer », « attendu au port », « en douane ».
Cet entrepôt virtuel doit être enrichi de dates d’embarquement réelles (ETD), temps de transit estimé, et dates d’arrivée prévues (ETA) pour :
- Mieux piloter l’approvisionnement,
- Prendre des décisions commerciales en fonction de la disponibilité prévisionnelle.
Sans cette visibilité, toute la supply chain devient aveugle pendant des semaines (en mer)
Cartographier et modéliser finement les Incoterms dans les flux croisés
Un ERP efficace doit pouvoir :
- Identifier clairement l’incoterm de l’achat fournisseur (FOB),
- Et celui de la vente client (POO, POE, ou MDP).
Cela signifie paramétrer chaque commande (vente et achat) pour :
- Définir précisément où se situe le transfert de risque et de propriété.
- Adapter les règles fiscales, de facturation et de suivi logistique.
Une cartographie fluide des incoterms est essentielle pour : - Éviter des écarts juridiques ou fiscaux,
- Harmoniser les flux physiques et financiers,
- Limiter les litiges avec les partenaires ou les administrations douanières.
Intégrer un module d’étiquetage d’expédition
Pour respecter les standards clients (GS1-128, UCC, QR code, étiquettes internes), deux solutions :
- Utiliser un Shipment Label Manager natif (SAP EWM, D365 SCM, etc.) pour générer et pousser automatiquement les étiquettes aux fournisseurs.
- Ou intégrer des outils spécialisés (Bartender, NiceLabel) via API, directement liés aux commandes d’expédition.
Pourquoi c’est stratégique ?
Parce qu’un étiquetage non conforme peut :
- Bloquer la marchandise à l’arrivée,
- Générer des coûts de rework élevés,
- Dégrader immédiatement la qualité de service perçue par le client.
Modéliser et contrôler les Packing Rules dans le workflow fournisseur
Les Packing Rules (nombre de pièces par carton, poids max par unité, pas de mélange de références) doivent être :
- Enregistrées comme des contraintes métier dans l’ERP.
- Contrôlées dynamiquement à la commande et à l’expédition.
- Validées automatiquement ou rejetées en cas de non-conformité.
Cela garantit :- Des réceptions rapides,
- Une conformité douanière facilitée,
- Une satisfaction client renforcée.
Ne pas contrôler les Packing Rules, c’est accepter des surcoûts logistiques et des risques de pénalités commerciales.
Réconcilier le flux logistique et le flux comptable
Enfin, il est essentiel de synchroniser les événements physiques et financiers :
- Poser des statuts intermédiaires clairs : « en transit », « réception virtuelle », « prêt à facturer », « livré client ».
- Créer des déclencheurs automatiques pour la facturation fournisseur et la facturation client, sans attendre un événement physique.
Un flux désynchronisé = des erreurs de trésorerie, des litiges financiers, et une perte de crédibilité.
Conclusion
Le Drop Shipment est bien plus qu’un simple flux logistique : C’est une révolution structurelle dans la manière de vendre, de piloter l’approvisionnement, et de gérer la relation client. C’est aussi une puissante opportunité pour les entreprises B2B afin de :
- Réduire les stocks immobilisés,
- Gagner en agilité,
- Étendre leur catalogue sans contrainte physique.
Mais c’est aussi une mécanique fine, exigeante, et truffée de pièges invisibles pour qui n’est pas préparé :
- Stock fantôme,
- Facturation bloquée,
- Conformité logistique dégradée,
- Relation client détériorée.
Les ERP modernes ne sont pas (encore) naturellement prêts pour tout orchestrer parfaitement. Il faut les étendre, les adapter intelligemment, et surtout avoir une compréhension opérationnelle pointue de toute la chaîne.
Ceux qui le font :
- Gagnent en fluidité,
- Sécurisent leur croissance,
- Fidélisent leurs clients.
Ceux qui y vont à la légère :
- Plongent dans un chaos silencieux,
- Subissent des ruptures invisibles,
- Et abîment leur image à long terme.