Une étiquette créée ne prouve pas qu’un colis a quitté l’entrepôt. Un tracking actif ne prouve pas qu’il a été livré. Un retour reçu ne prouve ni la remise en stock ni le remboursement. Ces raccourcis donnent une vue rassurante du flux, mais ils masquent l’étape qui bloque et le coût de sa reprise.
La logistique e-commerce se pilote comme une chaîne d’événements physiques et économiques. Chaque étape a besoin d’une identité, d’une preuve, d’une exception, d’un propriétaire et d’une unité de coût. Cette carte sert autant à améliorer une organisation interne qu’à rédiger un cahier des charges pour un prestataire.
Le but n’est pas de dessiner un parcours idéal. Il faut pouvoir expliquer une commande réelle, y compris lorsqu’une quantité manque, qu’un colis part en retard ou qu’un retour arrive sans dossier exploitable.
Cartographier le flux de l’inbound au remboursement
Le flux complet dépasse la seule préparation des commandes :
achat ou réapprovisionnement
→ avis de réception
→ contrôle et mise en stock
→ commande confirmée et release
→ picking
→ packing et étiquetage
→ confirmation de sortie
→ transport et livraison
→ retour et contrôle
→ remise en stock, réparation ou rebut
→ remboursement et rapprochement financier
Chaque flèche représente un contrat. La réception doit conserver la référence, la quantité, le lieu, l’état et la preuve du contrôle. La release autorise l’entrepôt à agir ; elle ne prouve pas la préparation. Le scan de sortie confirme un fait différent de la création de l’étiquette. Le remboursement relève encore d’un autre système.
La page sur les responsabilités entre OMS, ERP et WMS attribue les systèmes maîtres événement par événement. Ici, la question porte sur l’exécution : quelle preuve confirme l’étape, quel coût elle déclenche et que fait l’équipe lorsque la preuve manque ?
Réceptionner et stocker sans perdre l’identité
La réception commence avant l’arrivée physique. Un avis attendu permet de comparer ce qui devait arriver avec ce qui a été déchargé. Le contrôle relève les références, quantités, dommages et écarts. Une quantité reçue mais non contrôlée ne devrait pas devenir vendable par simple changement de statut.
Le contrat minimum comprend :
- l’identité du fournisseur, de l’avis ou du transfert ;
- l’identité produit et, si nécessaire, lot ou série ;
- la quantité attendue, reçue, acceptée et écartée ;
- le lieu et l’horodatage ;
- la preuve du contrôle ;
- le motif et le propriétaire de l’écart.
Les identifiants produit doivent rester cohérents avec le catalogue. La gouvernance du PIM traite la source des attributs et des identifiants ; le stock porte la quantité et l’état opérationnel. Les fusionner dans un même champ rend les corrections difficiles à expliquer.
Le stockage ajoute une autre unité économique : emplacement, volume et durée. Un produit compact à forte rotation et un article volumineux conservé plusieurs mois ne consomment pas la même capacité. Le calcul doit refléter l’unité réellement facturée ou supportée, sans transformer un coût moyen global en vérité par SKU.
L’inventaire sert de contrôle. Un écart entre système et quantité observée ouvre une investigation sur les mouvements, réceptions, préparations, retours et corrections. La méthode de synchronisation des stocks multicanaux prolonge ce contrôle vers disponibilité vendable, réservations et copies par canal. L’écrasement du stock pour « remettre le bon chiffre » rétablit l’affichage mais efface la cause. Une correction traçable conserve la valeur précédente, la nouvelle, le motif et l’auteur.
Prouver le picking, le packing et la sortie
La release transmet une commande ou une ligne prête à être exécutée. Le picking transforme cette demande en tâche physique. La preuve vient des scans, du prélèvement, du refus de picking et de la clôture de la tâche.
La documentation SAP EWM sur les livraisons sortantes décrit, dans SAP EWM 9.5, des confirmations échangées avec l’ERP, des refus de picking et certains splits. Elle illustre la différence entre ordre et exécution ; elle ne définit pas tous les WMS.
Un refus de picking doit remonter avec son motif. L’unité est-elle absente, endommagée, mal placée ou déjà engagée ailleurs ? La réponse peut mener à une réallocation, une réduction de quantité, une intervention ou une révision de promesse. Le WMS prouve le fait physique. L’OMS ou le système commercial applique la décision client selon l’architecture retenue.
Le packing forme le colis. Il réunit les lignes, l’emballage, le poids et les dimensions nécessaires au processus. Le contrôle peut vérifier la présence, la quantité et l’association avec l’étiquette. Une erreur de colisage ne se lit pas seulement dans un taux : elle doit être rattachée à la commande, à la ligne, à la tâche et au motif.
La sortie constitue son propre événement. L’étiquette peut exister avant que le colis ne soit fermé ou remis au transporteur. Conservez l’identifiant d’expédition, le colis, le tracking et la confirmation de sortie. Une étiquette sans départ et un départ sans tracking exploitable sont deux exceptions différentes.
Transporter et traiter les exceptions
Le transport ajoute des statuts produits par un autre système. Ils doivent être rapprochés de la sortie et de la promesse exposée au client. Un statut transport ne remplace pas la preuve interne de remise ; la copie interne ne remplace pas la lecture du transporteur lorsqu’un incident survient.
Le contrat nomme :
- le colis et le tracking ;
- le transporteur et le service ;
- la date de remise ;
- les tentatives et motifs d’échec ;
- la preuve de livraison prévue au contrat ;
- le canal d’escalade ;
- l’action possible pour le service client.
Aucun délai acceptable n’est universel. Les cut-offs, destinations, jours ouvrés, produits et engagements contractuels changent la lecture. La promesse visible doit rester cohérente avec l’option, le prix et la date ou le délai. Le chantier qui consiste à auditer la livraison dans le checkout traite ce point côté expérience.
Les exceptions doivent posséder un owner. Un colis bloqué sans propriétaire devient un statut consulté par plusieurs équipes et corrigé par aucune. L’alerte doit mener à une action : relire le transporteur, corriger l’association, informer le client, ouvrir une enquête ou préparer un remplacement selon la politique locale.
Séparer retour, remise en stock, remboursement et avoir
Le retour ne suit pas un état unique. Il peut comprendre une demande, une autorisation, une réception, un contrôle physique, une décision de stock, un remboursement et une écriture financière.
La documentation Odoo 19 sur les retours distingue, dans le processus décrit, l’opération inverse d’entrepôt de la note de crédit nécessaire après facturation. Cet exemple ne fixe pas la règle de toutes les entreprises. Il montre pourquoi « retour remboursé » masque plusieurs faits.
À la réception, contrôlez l’identité du dossier, les lignes, quantités, motifs et état. La décision de stock peut être remise en vente, quarantaine, réparation ou rebut. Le remboursement reste un mouvement du prestataire de paiement ; l’avoir relève du système financier. La page sur les solutions de paiement détaille les preuves de règlement et de remboursement côté PSP.
Les exceptions utiles à suivre sont :
- colis reçu sans dossier de retour ;
- dossier ouvert sans réception après le délai local ;
- quantité ou référence différente ;
- remise en stock sans contrôle ;
- remboursement sans réception attendue ;
- réception validée sans remboursement ou décision documentée.
La reprise ne rejoue que l’action manquante après lecture du système maître. Renvoyer toutes les notifications peut créer une double remise en stock ou un second remboursement.
Calculer le coût complet
Un tarif par commande ne suffit pas pour comparer deux modèles. Les coûts doivent être rattachés aux unités qui les déclenchent.
| Famille | Unités possibles | Éléments à inclure |
|---|---|---|
| Infrastructure | mois, emplacement, volume | espace, équipement, systèmes, pilotage |
| Réception | palette, carton, unité, heure | déchargement, contrôle, écart, mise en stock |
| Stockage | emplacement, volume, jour | occupation, inventaire, mouvements |
| Préparation | commande, ligne, unité | picking, packing, contrôle, consommables |
| Transport | colis, poids, zone, option | tarif, surcharge, assurance ou service contractuel |
| Retour | dossier, colis, ligne | réception, contrôle, remise en stock, réparation, rebut |
| Incident | dossier, heure | support, enquête, correction, remplacement |
| Intégration | mois, flux, évolution | API, monitoring, réconciliation, réversibilité |
Les formules de pilotage gardent leur périmètre visible :
Coût logistique par commande servie = coûts logistiques inclus ÷ commandes servies.
Coût de préparation par ligne = coûts de préparation inclus ÷ lignes préparées.
Coût de retour par dossier clos = coûts de retour inclus ÷ dossiers clos.
Taux d’erreur de préparation = commandes avec erreur confirmée ÷ commandes préparées.
Deux ratios identiques peuvent cacher des définitions différentes. L’un inclut le transport et les retours, l’autre seulement le picking. Le rapprochement exige la même période, les mêmes statuts et la même liste de coûts. L’arbre de KPI e-commerce aide à documenter la formule, la source, le propriétaire et le garde-fou.
Construire les KPI opérationnels
Le dashboard doit permettre une décision, pas collectionner des pourcentages. Commencez par les volumes entre états : commandes libérées, préparées, sorties, livrées et retournées. Une rupture localise la zone à inspecter.
Ajoutez les délais entre événements à partir d’horodatages comparables : réception-contrôle, release-fin de préparation, sortie-premier scan transport, réception retour-décision. Les seuils d’alerte viennent des engagements et horaires locaux.
Les indicateurs utiles peuvent inclure :
- commandes complètes et à l’heure selon une définition écrite ;
- erreurs confirmées par commande ou par ligne ;
- étiquettes sans départ et sorties sans tracking ;
- retours reçus sans dossier ;
- dossiers sans réception ou sans décision ;
- coût par commande, ligne, colis ou retour ;
- écart entre quantité système et contrôle physique ;
- âge des exceptions sans propriétaire.
Chaque fiche KPI indique le dénominateur, la source, l’owner, l’alerte et l’action. « Taux de service » sans ces champs ne permet ni de comparer un prestataire ni de corriger l’exploitation.
Internaliser, externaliser ou hybrider
Le choix ne dépend pas d’un volume universel. Il dépend de la variabilité, des contraintes produit, de la promesse, des données, des coûts et de la capacité à traiter les exceptions.
| Axe | Questions à documenter |
|---|---|
| Variabilité | Quels volumes, lignes, pics et horaires faut-il absorber ? |
| Produit | Fragile, volumineux, personnalisé, suivi par lot ou soumis à une contrainte particulière ? |
| Promesse | Quelles destinations, options, dates et cut-offs sont réellement engagés ? |
| Données | Quels objets, statuts, API, webhooks, journaux et exports sont disponibles ? |
| Économie | Quels coûts fixes, variables, minimums, surcharges et coûts d’incident ? |
| Contrôle | Qui corrige stock, préparation, transport et retour ? |
| Réversibilité | Comment récupérer stock, données, historique et emballages à la sortie ? |
L’externalisation transfère l’exécution de certaines tâches, pas la responsabilité de la promesse faite au client. L’entreprise doit encore suivre les preuves, les coûts et les exceptions. À l’inverse, l’internalisation conserve le contrôle mais exige espace, équipe, systèmes et capacité d’absorber les pics.
Un modèle hybride peut séparer produits, pays, pics ou types de commandes. La frontière doit rester lisible par événement. Sans cela, chaque incident commence par une discussion sur « qui devait le voir ».
Préparer un cahier des charges vérifiable
Le cahier des charges décrit d’abord le processus réel : volumes par unité, catalogue, commandes types, splits, retours, pics et exceptions. Il attribue ensuite les responsabilités et les preuves.
Demandez au minimum :
- les événements, statuts et identifiants disponibles ;
- les unités de facturation et leur périmètre ;
- les contrôles de réception, préparation et sortie ;
- les journaux, exports et procédures de reprise ;
- les responsabilités sur stock, transport, retour et support ;
- les alertes et canaux d’escalade ;
- la procédure de réversibilité.
Les documentations produit montrent des répartitions possibles, pas une frontière universelle. Shopify documente par exemple des Fulfillment Orders capables de représenter plusieurs groupes ou modes pour une commande. Sa documentation sur les webhooks rappelle que leur ordre n’est pas garanti et recommande horodatage, déduplication et réconciliation. Ces précautions valent comme contrat d’intégration ; elles ne prouvent pas la performance d’un prestataire.
Le dispositif est pilotable lorsque chaque opération peut répondre à trois questions : quelle preuve confirme l’état, quel coût elle a déclenché et qui traite l’exception ? Sans ces réponses, un tarif attractif ou un dashboard bien rempli ne protège ni la promesse client ni la marge.








