Un vendeur présent sur plusieurs marketplaces doit répondre à une question simple : que se passe-t-il réellement sur ses commandes, ses offres et ses stocks ? Les extranets séparés rendent cette lecture lente et morcelée.
Dawap a construit pour 1UP Distribution une application dédiée qui rassemble les opérations Amazon Europe, Fnac, Cdiscount et Origami autour d’un catalogue commun. Cette réalisation illustre le travail d’une agence marketplace lorsqu’il faut transformer plusieurs flux en outil quotidien.
Le projet ne se limite pas à afficher des données : il organise leur collecte, leur import et leur rapprochement avec les produits et les stocks. Cette expérience vendeur a nourri la trajectoire de Ciama Marketplace.
1. Le défi de 1UP Distribution
Voir les ventes et les stocks au-delà de chaque extranet
1UP Distribution devait suivre plusieurs pays Amazon ainsi que des canaux comme Fnac et Cdiscount, chacun avec ses formats et ses identifiants.
Une offre, une ligne de commande et un stock ne racontent pas la même chose lorsqu’ils restent enfermés dans leur canal. Le besoin consistait à les rattacher à une même référence produit.
Le cockpit devait donc donner aux équipes une lecture transversale tout en conservant l’origine marketplace de chaque opération.
2. Construire autour des objets métier
Séparer les canaux sans fragmenter le travail
Le socle a été découpé par domaines : marketplaces et connexions, commandes, offres, PIM, stocks, entrepôts et statistiques.
Des traitements d’import distincts prennent en charge les particularités des canaux avant de les traduire dans les objets communs du cockpit.
L’interface suit cette organisation : elle permet de partir d’une commande, d’une offre ou d’un produit sans perdre le lien avec le canal et le compte concernés.
3. Le problème multicanal
Sortir d’une lecture canal par canal
Amazon Europe, Fnac, Cdiscount et Origami utilisent leurs propres identifiants, états et modèles d’échange.
Sans couche commune, une même référence commerciale se retrouve éclatée entre commandes, offres et stocks difficiles à rapprocher.
Le projet a placé l’usage vendeur au centre : chercher, comprendre et agir depuis un même espace.
4. Le modèle commun
Conserver l’origine tout en unifiant la lecture
Chaque marketplace est rattachée à une plateforme, un type de connexion et un compte vendeur.
Les données importées gardent leur identifiant externe et leur canal d’origine, puis rejoignent les entités communes de l’application.
Cette séparation rend le cockpit extensible sans mélanger les règles propres à chaque API.
5. Commandes et lignes
Centraliser le détail transactionnel
Le cockpit collecte les commandes et leurs lignes depuis les connecteurs Amazon Europe, Fnac, Cdiscount et Origami.
Les vues permettent de retrouver le canal, l’identifiant externe, la date, l’état, les quantités et les montants associés.
Le traitement d’import ajoute ou met à jour les données afin de maintenir une lecture cohérente dans le temps.
6. Offres et variations
Suivre prix et disponibilité dans le même domaine
Les offres sont importées séparément des commandes, avec leurs prix, quantités et références marketplace.
Les variations de prix et de stock disposent de leur propre historique, ce qui prépare une lecture plus fiable de l’évolution d’une offre.
L’équipe peut ainsi relier une offre commerciale à son produit plutôt que la traiter comme une ligne isolée.
7. Catalogue et stocks
Faire du produit le point de rapprochement
Le PIM rassemble les produits et les marques, puis affiche pour chaque référence ses offres marketplace, ses lignes de commande et ses stocks.
Les entrepôts et centres de stockage sont modélisés séparément, notamment pour le stock Amazon FBA Europe.
Cette vue produit donne un point d’entrée stable pour comprendre disponibilité et ventes sur plusieurs canaux.
8. Des imports maîtrisés
Découpler la collecte du travail utilisateur
Les commandes et les offres passent par des files de messages distinctes avant leur import dans le cockpit.
Ce découpage évite de faire dépendre l’interface du temps de réponse d’une marketplace et isole les traitements par famille de données.
Des commandes planifiées couvrent aussi l’actualisation des ventes, des produits et des stocks.
9. Scénario quotidien
Partir d’un produit et retrouver toute son activité
Une opératrice recherche une référence dans le PIM. La fiche produit réunit ses offres, ses lignes de commande, ses volumes de vente et ses stocks.
Elle peut ensuite ouvrir une commande, vérifier son canal et son état, puis revenir au produit sans recouper plusieurs extranets.
Le cockpit transforme ainsi une recherche dispersée en parcours métier continu.
10. Les arbitrages structurants
Unifier le métier, isoler les connecteurs
Le choix majeur a consisté à ne pas faire porter aux objets métier les formats spécifiques d’Amazon, Fnac, Cdiscount ou Origami.
Les collecteurs traduisent chaque réponse externe, tandis que le domaine commun porte commandes, offres, produits et stocks.
Deux parcours d’intégration dédiés à Fnac sécurisent la collecte des commandes et des offres sur cette première version.
11. La trajectoire Ciama
Transformer un besoin client en expérience réutilisable
La version dédiée à 1UP réunit déjà les fondations d’un cockpit vendeur : comptes, plateformes, commandes, offres, PIM, stocks et statistiques.
Ces apprentissages ont contribué à structurer l’approche de Ciama Marketplace autour des usages réels des vendeurs.
Les projets 1UP Sourcing et 1UP vers Odoo racontent deux prolongements distincts de cette collaboration.
12. Un terrain concret pour Ciama Marketplace
Capitaliser une expérience vendeur multicanal
Le projet 1UP montre qu’un cockpit vendeur utile repose d’abord sur des objets métier cohérents : commandes, offres, produits, stocks et entrepôts.
La séparation des connecteurs protège l’expérience utilisateur des différences entre Amazon, Fnac, Cdiscount et Origami, tandis que les imports asynchrones structurent l’exploitation.
Cette logique se prolonge dans nos prestations de reporting vendeur marketplace et dans Ciama Marketplace.
