Les écarts de données marketplace commencent souvent par une phrase banale : « On ne comprend pas, la marketplace annonce 1 248 commandes, notre OMS en affiche 1 210, l’ERP 1 196 et la BI 1 265 ». Tout le monde a des chiffres. Personne n’a le même. Et à ce moment précis, ce n’est pas seulement un sujet de reporting : c’est un sujet de pilotage, de cash, de stock, de relation client et, à terme, de rentabilité.
Sur un mono-canal simple, une divergence peut se corriger à la main. Mais dès que l’on vend sur plusieurs marketplaces, avec un e-commerce, un ERP, un PIM, parfois un WMS et des prestataires de shipping, les données deviennent un système vivant. Chaque brique a ses règles, ses délais, ses formats, ses identifiants, ses statuts et sa logique métier. Ce qui ressemble à « une simple intégration » est en réalité une orchestration de flux où la moindre approximation produit un décalage.
Une marketplace est construite pour faire vendre, exécuter un service et rendre des comptes selon ses propres définitions. Son tableau de bord est souvent orienté opération commerciale (volumes, taux d’acceptation, expéditions, retours, performance vendeur), pas comptabilité analytique (cut-off, reconnaissance du CA, coûts complets, rapprochement bancaire, etc.). À l’inverse, un ERP vise la cohérence interne, la traçabilité et les règles comptables. Comparer les deux “bruts”, c’est comparer deux systèmes qui ne parlent pas la même langue.
Les écarts se créent rarement dans un outil, mais entre les outils : un export incomplet, un statut mal interprété, une commande importée deux fois, un retour non rapproché, une facture générée sans frais, un prix remisé différemment, une TVA calculée sur une adresse non normalisée… La frontière est le lieu où l’information est transformée. Et dès qu’on transforme sans gouvernance, on déforme.
Chez Dawap, on traite ce sujet comme un problème d’architecture de données et de fiabilité des flux, pas comme un simple “connecteur”. L’objectif n’est pas d’avoir “des données qui arrivent”, mais d’avoir des données justes, rejouables, supervisées et exploitables dans la durée (approche API-first, gestion d’erreurs, idempotence, logs, supervision). :contentReference[oaicite:0]{index=0}
Pour comprendre d’où viennent les écarts, il faut d’abord les classer. Dans 90 % des cas, on retrouve toujours les mêmes familles de problèmes, quel que soit le couple marketplace / ERP / OMS. Les symptômes changent, la racine est souvent similaire.
“Commande”, “vente”, “expédié”, “annulé”, “remboursé”… Ces mots paraissent universels. Ils ne le sont pas. Une marketplace peut considérer qu’une vente existe dès la confirmation de l’acheteur, alors que votre ERP n’enregistre une vente qu’après expédition, ou après paiement capturé. Si vous additionnez des objets qui n’ont pas la même définition, vous obtenez forcément des écarts.
Les données sont rarement synchrones. Entre un webhook immédiat, un batch horaire et un export quotidien, vous comparez des instantanés pris à des moments différents. Résultat : les chiffres “du jour” ne correspondent jamais si vous n’alignez pas les fenêtres temporelles.
Un même objet peut avoir plusieurs identifiants : ID marketplace, ID panier, ID commande, ID expédition, ID facture, ID remboursement. Si vous ne mappez pas proprement ces identifiants, vous perdez le fil. Et quand vous perdez le fil, vous dupliquez ou vous oubliez.
La marketplace inclut parfois la livraison dans la base de commission, ou affiche des commandes multi-lignes quand votre OMS les éclate, ou agrège des transactions sur des périodes de versement. Le périmètre n’est pas le même : mêmes ventes, lecture différente.
Taxes, devises, arrondis, remises, prorata, coupons, promotions… De petites différences de calcul produisent de gros écarts à l’échelle du volume. Ce n’est pas un bug spectaculaire. C’est une érosion silencieuse.
Données manquantes, champs non normalisés, adresses mal formatées, EAN incorrect, variantes ambiguës, attributs incohérents : la qualité du catalogue conditionne la qualité des flux. Une donnée de départ fragile se dégrade à chaque étape.
Enfin, il y a l’écart le plus frustrant : celui qui vient de l’exploitation. Un script lancé deux fois, un batch relancé sans idempotence, un export fait manuellement, une correction dans Excel, une règle modifiée sans versioning… Les systèmes ne mentent pas : on leur demande souvent de fonctionner dans un cadre non maîtrisé.
La première source d’écarts, c’est la commande. Tout le monde regarde le nombre de commandes. Mais une commande est un objet complexe : elle vit, elle change, elle peut être partiellement expédiée, partiellement remboursée, re-facturée, regroupée, éclatée. Et les marketplaces ont souvent des statuts intermédiaires qui ne correspondent pas à votre modèle interne.
Beaucoup de vendeurs comparent “commandes validées” marketplace à “commandes importées” OMS. Or, une marketplace peut : créer une commande, puis la modifier (adresse, mode de livraison, promesse), puis la annuler, ou déclencher un litige, ou un remboursement après coup. Si votre flux ne gère pas ces transitions (et pas uniquement la création), vous ne suivez qu’un début d’histoire.
L’écart classique : la marketplace affiche 100 commandes “passées” sur la journée, mais votre ERP n’en a facturé que 92. Les 8 restantes ? Souvent des annulations post-achat, des échecs de paiement, ou des commandes non expédiées dans le SLA qui basculent en litige. La marketplace compte l’activité commerciale, l’ERP compte l’exécution et la facturation.
Sur certaines plateformes, une commande est un panier multi-lignes. Dans votre OMS, vous gérez des orderLines (lignes) comme unité de stock et d’expédition. Si un article est expédié en retard, c’est la ligne qui bouge, pas forcément l’ensemble de la commande. Si vous comparez des niveaux différents (commande vs lignes), vous créez des écarts “fantômes”.
Même lorsque la commande “existe”, le cash n’est pas toujours immédiat. Les marketplaces déclenchent des versements, appliquent des retenues, des compensations, des réserves, des corrections de frais. Le “montant commande” n’est pas le “montant encaissé”, et il peut être réparti sur plusieurs cycles.
La clé ici : séparer clairement trois objets dans votre modèle de données : commande (événement commercial), expédition (événement logistique), transaction (événement financier). Tant que ces objets sont mélangés, les écarts sont inévitables.
Deuxième zone critique : le stock. C’est souvent là que l’entreprise “sent” le problème avant même de le mesurer : ruptures alors que l’ERP dit qu’il reste du stock, survente, commandes impossibles à honorer, promesses de livraison non tenues. Les écarts de stock ne sont pas seulement des chiffres : ce sont des incidents opérationnels.
L’ERP connaît souvent le stock physique. La marketplace a besoin du stock disponible à la vente. Entre les deux, vous avez les réservations (commandes en cours), les allocations, les stocks de sécurité, les quarantaines, les retours en contrôle qualité, les préparations en cours, les multi-entrepôts, les délais de réapprovisionnement. Si vous exposez le stock physique comme stock disponible, vous fabriquez de l’erreur.
Avec des modèles type fulfilment, la marketplace gère une partie du stock. Vous avez alors au moins deux stocks : stock “chez vous” et stock “chez la plateforme”. Et parfois un troisième : stock chez un 3PL. Les sources de vérité divergent : votre ERP pense “global”, la marketplace pense “local” à son entrepôt. Si vous ne réconciliez pas ces stocks avec des règles explicites, vous pilotez à vue.
Le stock change tout le temps. Pourtant, beaucoup de flux d’intégration le traitent comme un export périodique. Entre deux exports, vous avez vendu, réservé, annulé, réceptionné. La marketplace “voit” un état obsolète. Et l’obsolescence sur un SKU rapide suffit à générer des surventes.
Une approche robuste consiste à traiter le stock comme un événement (mouvements) ou à minima comme un état recalculé avec des règles de disponibilité centralisées, puis diffusées. C’est là que l’architecture compte : si chaque canal recalcule sa vérité, vous n’aurez jamais une vérité unique.
Les prix sont une autre source d’écarts à haute intensité. Sur une marketplace, le prix n’est pas “un nombre”. C’est une décision : prix public, prix remisé, coupon, promo événementielle, prix barré, prix “membre”, prix par pays, frais de livraison inclus ou non, et parfois des règles de compétitivité.
Une marketplace peut appliquer des promotions automatiques, des mécanismes d’arrondis, des coupons sponsorisés, ou des bundles qui modifient la valeur effective de la commande. Dans votre système, vous enregistrez un “prix de vente” et une “remise”. Mais côté marketplace, vous avez parfois plusieurs remises empilées, et un partage de contribution (vendeur vs plateforme). Sans un modèle détaillé, vous “aplatissez” l’information… et vous perdez la vérité.
Les arrondis sont sous-estimés. Une marketplace peut arrondir au niveau ligne, votre ERP au niveau commande. Une conversion de devise peut être faite au moment de l’achat, vous la refaites au moment de la facturation. Sur une commande, l’écart est insignifiant. Sur 50 000 commandes, il devient une ligne comptable qui ne “tombe” jamais juste.
Beaucoup d’écarts viennent d’une question simple : le prix que vous envoyez est-il HT ou TTC ? Et le prix que vous recevez est-il HT ou TTC ? Les marketplaces mélangent parfois les deux selon le pays, le type de vendeur, le régime fiscal, le mode de livraison. Sans contrat de données clair (contrôle des champs, validation, versioning), on intègre des prix “qui ont l’air bons”… jusqu’au jour où la marge ne correspond plus.
Le reporting marketplace est souvent centré sur le chiffre d’affaires. Mais la rentabilité se joue dans les frais. Or, les frais marketplace sont rarement un simple pourcentage. Ils peuvent varier par catégorie, par pays, par service, par mode de livraison, et inclure des coûts fixes, des paliers, des frais “hors cycle”, des corrections, des pénalités. C’est ici que les écarts deviennent douloureux : ils touchent directement la marge.
Une commission peut être calculée sur le produit seul, ou sur produit + livraison, ou sur le TTC, ou sur le HT, ou sur un montant après remise. Et votre ERP, lui, n’a pas toujours la granularité pour recomposer cette base. Résultat : vous comparez une commission “attendue” à une commission “prélevée”, et ça ne colle pas.
Les frais logistiques (stockage, préparation, expédition, surcharge carburant, volumétrie, zone géographique) peuvent changer sans que votre modèle interne soit mis à jour. Si vous calculez une marge “standard”, vous ne verrez pas l’érosion progressive. Et lorsque vous verrez l’écart, vous ne saurez plus quand il a commencé.
Un retour implique : transport retour, traitement, reconditionnement, perte de valeur, parfois destruction. La marketplace peut afficher “remboursé” avec un montant, mais les coûts réels se trouvent dans votre WMS, votre 3PL, votre compta. Si le retour n’est pas rapproché à la commande et à la ligne, vous ne pouvez pas calculer une marge nette fiable.
Le point technique crucial : les frais doivent être modélisés comme des lignes de coûts rattachées à des objets (commande, ligne, expédition, période), pas comme un total mensuel “à répartir”. Tant que vous répartissez, vous estimez. Tant que vous estimez, vous pilotez sur du flou.
La fiscalité amplifie les écarts, parce qu’elle ajoute une couche de règles externes et non négociables. Entre OSS, pays de livraison, taux réduits, catégories spécifiques, règles post-Brexit, et documents de douane, la TVA n’est plus une “case à cocher”. C’est une dimension du modèle de données.
Une vente sur une marketplace “FR” peut être livrée en Belgique. Le taux de TVA, la collecte, et le régime applicable peuvent changer. Si votre commande n’embarque pas proprement les informations de destination, vous calculez une TVA théorique, puis vous corrigez… puis vous n’avez plus de cohérence.
Selon la plateforme et le type de flux, la marketplace peut être “collecteur” ou non. Cela impacte le montant “net vendeur”, les écritures et la manière de rapprocher les versements. Si votre modèle interne ne distingue pas ces cas, vous aurez des écarts structurels, pas des anomalies ponctuelles.
Les conversions de devises ajoutent un décalage temporel : le taux appliqué n’est pas toujours celui de votre comptabilité. Certaines plateformes appliquent un taux “maison” ou un taux du jour au moment de l’opération. Si votre BI reconvertit à un autre taux, vous fabriquez un écart permanent.
On parle beaucoup des commandes et des stocks, mais les écarts commencent souvent plus tôt : au catalogue. Une fiche produit marketplace n’est pas votre fiche PIM. Une offre marketplace n’est pas votre SKU. Et dès que vous confondez “produit”, “variante”, “offre”, “EAN” et “référence interne”, les erreurs se propagent partout.
L’EAN est censé être stable. Dans la réalité, on voit des EAN dupliqués, des EAN génériques, des EAN de pack utilisés comme EAN d’unité, des variantes couleur ou taille qui partagent un identifiant. La marketplace va créer des rapprochements “logiques” de son côté, mais votre système va s’y perdre.
Un attribut manquant ou mal mappé peut provoquer : refus de catalogue, catégorisation incorrecte, mauvaise TVA, commission erronée, et même des restrictions logistiques. Le catalogue, ce n’est pas “du marketing”. C’est un socle opérationnel. Plus votre mapping est fragile, plus vous aurez des exceptions… et donc des écarts.
L’offre marketplace (SKU + prix + stock + conditions + canal + pays) est souvent l’objet central. Si votre architecture ne modélise pas l’offre comme un objet de premier rang, vous vous retrouvez à “déduire” l’offre à partir de la commande, puis à tenter de recalculer les règles. C’est coûteux, approximatif, et rarement fiable.
Les systèmes ne travaillent pas au même rythme. Une marketplace peut envoyer un webhook instantané sur la création de commande, puis publier les détails financiers plus tard. Votre ERP peut intégrer en batch nocturne. Votre WMS peut mettre à jour le stock toutes les 15 minutes. Et votre BI peut agréger en fin de journée. À la fin, vous comparez des données qui ne sont pas alignées temporellement.
Avant de dire “il y a un écart”, il faut définir : on compare quoi, sur quelle période, selon quel fuseau horaire, avec quel cut-off ? Beaucoup d’écarts disparaissent quand on aligne la fenêtre : par exemple, comparer “commandes de 00:00 à 23:59 UTC” sur la marketplace avec “journée locale Europe/Paris” dans l’ERP est une recette parfaite pour des écarts quotidiens.
Même avec des webhooks, certains événements sont différés : remboursement, correction de frais, litige clos, compensation. Si votre modèle BI ne gère pas les événements “après coup”, vous aurez des écarts “rétroactifs” : le mois N change au mois N+1. Ce n’est pas un bug : c’est la nature du système… à condition de l’avoir modélisée.
Ici, on passe du métier à l’ingénierie. Beaucoup d’écarts viennent d’un point simple : vos flux ne sont pas conçus pour être fiables dans un monde réel. Un incident réseau, une API qui répond lentement, un timeout, une relance manuelle : tout cela arrive. Si votre intégration n’est pas idempotente, vous dupliquez. Si elle n’est pas rejouable, vous perdez des données.
L’idempotence, c’est la capacité à rejouer un message sans changer le résultat final. Sans idempotence, une simple relance de batch peut créer des commandes en double, des écritures en double, des mouvements de stock en double. Et ensuite, vous “corrigez” à la main… ce qui crée un autre écart, ailleurs.
Un flux fiable doit permettre de rejouer un segment (un jour, un vendeur, un SKU, une commande) de façon contrôlée, avec un historique et une traçabilité. Sans replay, chaque incident devient une opération manuelle. Et l’opération manuelle est l’usine à incohérences.
Quand une équipe passe des heures à “comparer des exports”, c’est souvent parce qu’il manque un journal d’événements clair : quel message a été reçu, quand, transformé comment, envoyé où, accepté ou rejeté pourquoi. La supervision n’est pas un bonus. C’est un prérequis pour arrêter de subir les écarts.
À ce stade, une question revient toujours : « Quelle est la source de vérité ? » La mauvaise réponse est : “la marketplace”. Ou “l’ERP”. Ou “l’OMS”. La bonne réponse est : la source de vérité dépend de l’objet. Le stock physique est souvent vérité dans le WMS/ERP, la commande peut être vérité côté marketplace à la création, l’expédition vérité côté WMS, et la transaction vérité côté PSP ou marketplace selon le modèle. Ce qu’il faut, c’est un système qui sait orchestrer ces vérités partielles.
La solution la plus robuste consiste à définir un modèle canonique (un schéma de référence) pour les objets clés : produit, offre, stock, commande, ligne, expédition, retour, transaction, frais, taxes. Chaque système se connecte au canonique via une couche d’adaptation. Vous arrêtez de faire du “point à point” fragile, et vous construisez une architecture maintenable.
Les règles changent : commission par catégorie, seuil de livraison gratuite, politique de retour, TVA, arrondis. Si vos règles sont codées “en dur” dans des scripts ou des automatisations dispersées, vous ne savez plus ce qui a changé ni quand. Versionner les règles métier, c’est transformer un chaos en système pilotable.
Une architecture API-first permet de standardiser les échanges, d’industrialiser la gestion d’erreurs (retries, DLQ, alertes), et d’automatiser ce qui est trop souvent manuel : contrôles, rapprochements, recalculs, export BI. C’est exactement l’approche de Dawap : industrialiser des opérations digitales via des APIs fiables, maintenables et supervisées. :contentReference[oaicite:1]{index=1}
Même la meilleure architecture n’empêche pas les incidents. Elle les rend visibles, mesurables et corrigeables. C’est le rôle de la supervision : transformer “on pense qu’il y a un écart” en “on sait exactement quel flux, quel objet, quel champ, quelle cause”.
On met en place des contrôles simples mais puissants : nombre de commandes reçues vs envoyées, taux d’erreurs par API, détection de doublons, écarts de montants au-delà d’un seuil, commandes sans expédition après X heures, retours sans remboursement, frais manquants. Ces contrôles doivent tourner en continu, pas “quand on a un doute”.
Une alerte utile est actionnable. Elle doit préciser : périmètre, objet, cause probable, et chemin de correction. Une alerte bruitée finit ignorée. L’enjeu est de calibrer des seuils et des priorités, et de relier l’alerte au mécanisme de replay/correction.
Un vrai cap de maturité, c’est de parler en SLA de données : “Les commandes sont synchronisées à 99,9% en moins de 5 minutes”, “Le stock est mis à jour toutes les 10 minutes, avec un écart max de 2 unités”, “Les frais sont complets à J+2”. Tant que vous n’avez pas de SLA, vous n’avez pas d’objectif de fiabilité.
Si vous subissez des données marketplace non fiables, la tentation est de “refaire un export propre” ou “changer d’outil”. Mais la plupart du temps, le problème est structurel : modèle de données, règles, flux, supervision. Voici un plan d’action pragmatique, orienté résultats.
Listez les objets (produit, offre, stock, commande, expédition, transaction, retours, frais, taxes), et pour chacun : la source de vérité, les statuts, les identifiants, le rythme de synchronisation. Puis alignez les définitions : “vente”, “encaissé”, “expédié”, “remboursé”. Rien ne se fiabilise sans ce socle.
Mesurez les écarts par famille (temps, statut, identifiant, calcul, qualité, exploitation). Un écart sans classification devient un chantier infini. Un écart classé devient une correction ciblée.
C’est non négociable. Toute intégration critique doit supporter : retries contrôlés, idempotence, replays, et une journalisation fine. Sans ces mécanismes, vous ne “corrigez” pas : vous recommencez.
Vous standardisez les objets et vous réduisez le point à point. À court terme, cela demande de la rigueur. À moyen terme, cela économise énormément : moins de bugs, moins de corrections manuelles, plus de scalabilité.
Enfin, vous rendez la fiabilité visible : tableaux de bord, alertes, contrôles, SLA. À partir de là, les écarts cessent d’être un mystère : ce sont des incidents gérés comme tels.
Nous accompagnons les opérateurs et les vendeurs dans la création, la gestion et l’évolution de leurs marketplaces. Notre mission : construire un écosystème performant, fluide et durable, où technologie et stratégie avancent ensemble.
Vous préférez échanger ? Planifier un rendez-vous
SELLERLOGIC est une solution de repricing pour les vendeurs Amazon exigeants, combinant analyse, automatisation et stratégie afin d’ajuster les prix avec précision, protéger la marge et renforcer durablement la compétitivité.
Feedvisor est un repricer avancé destiné aux vendeurs à fort volume, combinant intelligence tarifaire, analyse concurrentielle, pilotage des performances et suivi de rentabilité pour optimiser durablement les prix sur les marketplaces.
Le repricing est devenu essentiel pour rester compétitif sur les marketplaces. Ce guide 2025 vous aide à comprendre les leviers, stratégies et outils pour optimiser vos prix sans sacrifier votre rentabilité.
Marketplace Reporting offre une vision consolidée des ventes multi-marketplaces. Centralisez performances produits et publicitaires pour piloter vos marges avec précision et agilité.
Nous accompagnons les opérateurs et les vendeurs dans la création, la gestion et l’évolution de leurs marketplaces. Notre mission : construire un écosystème performant, fluide et durable, où technologie et stratégie avancent ensemble.
Vous préférez échanger ? Planifier un rendez-vous
