Le projet en un coup d’œil
Les commandes, prix, stocks et traitements logistiques devaient être suivis sans multiplier les consoles.
Un même socle reliait produits, offres, commandes, achats, fournisseurs, entrepôts et reporting.
Les équipes retrouvaient le contexte d’une vente et pouvaient agir depuis une vue cohérente.
Vendre sur plusieurs marketplaces donne accès à davantage de clients, mais multiplie aussi les consoles, les formats et les gestes de contrôle. Une commande, une offre ou un mouvement de stock pouvait être compris sur un canal et rester opaque sur un autre.
DaCockpit a été conçu pour remettre de la continuité dans cette exploitation. Produits, offres, commandes, expéditions, stocks, achats, fournisseurs et entrepôts ont été organisés dans un même outil, avec les particularités de chaque canal conservées lorsque les équipes en avaient besoin.
Cette réalisation constitue un projet à part entière : elle précède Ciama et raconte déjà une approche forte de Dawap, celle d’un accompagnement marketplace vendeurs ancré dans les opérations réelles plutôt que dans une simple couche de tableaux de bord.
1. DaCockpit, un produit pensé depuis le quotidien des vendeurs
Faire dialoguer commerce, catalogue et logistique sans perdre les nuances de chaque canal
DaCockpit s’adressait à des équipes qui pilotaient plusieurs comptes et marketplaces. Leur travail ne s’arrêtait pas à consulter des ventes : il fallait comprendre une offre, vérifier son prix et son stock, retrouver une commande, suivre son exécution et rapprocher ces informations des capacités d’approvisionnement.
Le produit devait donc servir plusieurs lectures du même commerce. Une équipe commerciale cherche la performance d’une offre ; une équipe opérationnelle suit les commandes et expéditions ; les achats ont besoin des fournisseurs ; la logistique raisonne par stock et entrepôt.
La valeur venait de la relation entre ces objets. En réunissant leurs contextes dans une application commune, DaCockpit transformait une succession de contrôles isolés en chaîne d’exploitation lisible.
2. Une construction progressive par domaines complets
Poser le socle, connecter les canaux, puis élargir aux achats
La trajectoire de 2021 montre une progression continue : les fonctions de compte et de canal ont d’abord posé le cadre, puis les offres, commandes et historiques ont consolidé la lecture commerciale.
Les connecteurs Amazon Europe, Cdiscount, Fnac, Mirakl et Wizaplace ont été intégrés autour de commandes dédiées. Ce découpage permettait d’adapter l’appel externe sans disperser les règles communes dans toute l’application.
La dernière phase a enrichi le produit avec les fournisseurs, les achats et le réapprovisionnement. Des tests et une intégration continue accompagnaient cette évolution pour préserver les fonctions déjà utilisées.
3. Quand chaque canal impose sa propre lecture
La dispersion coûte du temps et fragilise les décisions
Sans poste de pilotage commun, une anomalie oblige à passer d’un espace à l’autre, puis à rapprocher manuellement commande, offre et stock. Ce chemin ralentit la réponse et augmente le risque d’agir sur une information partielle.
Le problème devient plus sensible avec les achats et les entrepôts : une vente n’est réellement maîtrisée que si sa disponibilité, son approvisionnement et sa préparation restent compréhensibles dans le même contexte.
4. Donner une vue commune sans aplatir les marketplaces
Normaliser ce qui doit l’être, conserver ce qui aide à décider
L’objectif était de rendre comparables produits, offres, commandes et stocks, tout en gardant les identifiants et états spécifiques nécessaires au traitement de chaque canal.
Le second objectif consistait à relier le commerce à l’exécution : retrouver un client, une facture, une expédition, un fournisseur ou un entrepôt depuis une situation opérationnelle concrète.
5. Un cockpit couvrant toute la chaîne opérationnelle
Du catalogue jusqu’au réapprovisionnement
L’application a structuré des espaces dédiés aux comptes, marketplaces, produits GS1, offres, commandes, factures, stocks, fournisseurs, achats et entrepôts. Des vues de reporting complétaient la lecture transactionnelle.
Les traitements Amazon couvraient notamment commandes, logistique, finance et Buy Box ; les flux Cdiscount, Fnac, Mirakl et Wizaplace disposaient de leurs propres points d’entrée. L’utilisateur bénéficiait pourtant d’un vocabulaire commun dans le cockpit.
6. Séparer les connecteurs du cœur métier
Limiter l’impact d’un changement externe
Chaque marketplace évolue à son rythme. Isoler les appels et traitements par canal évitait qu’une adaptation Amazon ou Mirakl ne redéfinisse le produit entier.
À l’inverse, les objets partagés — offre, commande, stock, fournisseur ou entrepôt — restaient stables. Cet arbitrage protégeait la lecture métier tout en laissant de la place aux particularités externes.
7. Une application enrichie sans perdre son fil
Tests, intégration continue et responsabilités séparées
Le produit comportait des contrôles automatisés sur ses services et ses parcours essentiels, ainsi qu’une chaîne d’intégration continue. La séparation des domaines facilitait une évolution ciblée.
Cette discipline comptait particulièrement lors de l’arrivée des achats et fournisseurs : le périmètre gagnait une nouvelle profondeur sans remettre en cause les flux commerciaux déjà structurés.
8. Ce que DaCockpit a changé pour les opérations
Moins de navigation dispersée, davantage de contexte
Les équipes pouvaient suivre une vente avec ses informations de canal, son offre, son état logistique et ses données de stock depuis un environnement cohérent. Les recherches et comparaisons devenaient plus directes.
Le rapprochement avec les fournisseurs, achats et entrepôts donnait aussi une continuité entre constater une demande et préparer la réponse. DaCockpit ne remplaçait pas les marketplaces : il rendait leur exploitation collective plus lisible.
9. Un produit fondateur, mais une histoire qui lui est propre
La preuve qu’un cockpit utile part des opérations
DaCockpit a matérialisé une idée simple : la valeur d’un outil multicanal ne tient pas au nombre de connecteurs affichés, mais à la continuité qu’il crée entre une décision commerciale et son exécution.
Son périmètre — offres, commandes, finance, stocks, achats, fournisseurs et entrepôts — en fait une réalisation autonome, avec ses propres arbitrages et sa propre transformation opérationnelle.
Pour structurer ce même type de pilotage, Dawap accompagne les vendeurs dans la conception de leur organisation marketplace et de leurs outils métier.
