Le projet en un coup d’œil
Un chiffre de vente, une commande, une offre et un signal de Buy Box ne demandent ni la même lecture ni le même niveau de détail.
Ciama relie une vue d’ensemble, trois espaces opérationnels et des outils spécialisés depuis une navigation Marketplace stable.
Le vendeur peut prendre la température, ouvrir le canal ou la commande concernée, puis utiliser un outil spécialisé lorsque le diagnostic le demande.
Un cockpit marketplace perd vite sa valeur lorsqu’il cherche à faire tenir toutes les décisions dans un seul écran. La direction veut connaître le chiffre d’affaires et son évolution. La personne qui gère les commandes doit retrouver un statut et une référence. Le responsable des offres vérifie prix, stock et canal. Une analyse de présence catalogue, de Buy Box ou de fuite de marge demande encore une autre profondeur. Les réunir ne signifie donc pas les confondre.
Dawap a structuré dans Ciama un univers Marketplace qui assume ces niveaux. Une vue d’ensemble donne la température commerciale du compte. Trois espaces permanents — Canaux, Commandes et Offres — portent la matière opérationnelle. Cinq outils spécialisés sont accessibles depuis la même navigation, tandis qu’un catalogue de découverte explique sept fonctions et sépare ce qui est actif de ce qui reste en feuille de route.
Cette architecture constitue une preuve concrète de notre accompagnement d’agence marketplace pour vendeurs. Elle ne promet pas qu’un algorithme sait pourquoi les ventes baissent. Elle organise plutôt un chemin vérifiable : partir du bon indicateur, choisir la bonne vue, ouvrir l’objet concerné et seulement ensuite décider. Le projet vaut autant par ce qu’il relie que par ce qu’il refuse de résumer trop tôt.
1. Ciama, un produit commerce confronté à plusieurs profondeurs de décision
Prendre la température, examiner une opération et enquêter sur un produit sont trois gestes différents
Ciama réunit plusieurs univers de vente dans un même back-office : B2B, marketplaces et e-commerce. Le périmètre raconté ici concerne la spécialisation marketplace. Il s’appuie sur des commandes, des lignes de commande, des offres, des canaux et des dimensions PIM telles que produits, marques, catégories et tags. Ces objets existaient déjà ; le chantier devait leur donner une organisation qui reste compréhensible lorsque les fonctions se multiplient.
Le besoin n’était pas celui d’un client fictif dont tous les irritants auraient été connus à l’avance. Il venait de la trajectoire du produit lui-même. Au fil des vues, des connecteurs et des outils, le risque était de fabriquer une collection de pages indépendantes. Un utilisateur aurait dû connaître le nom exact de chaque fonctionnalité avant même de savoir quelle question elle pouvait résoudre.
Le choix a été de donner à Marketplace sa propre entrée dans la navigation. Elle s’ouvre sur un aperçu, puis sépare les outils spécialisés des trois registres fondamentaux : les canaux qui donnent le contexte de diffusion, les commandes qui matérialisent les ventes et les offres qui portent prix, disponibilité et présence commerciale.
Cette structure ne remplace ni les droits ni le cloisonnement. Le dashboard récupère le compte de la personne connectée et transmet son identifiant à chaque requête. Les agrégats, classements et séries temporelles restent donc dans la frontière du compte. La navigation commune rapproche les usages ; elle ne rapproche jamais les données de plusieurs clients.
2. Construire une hiérarchie de lecture avant de multiplier les indicateurs
Le dashboard oriente, les recherches prouvent, les outils spécialisés approfondissent
Le premier arbitrage a consisté à définir le rôle de la vue d’ensemble. Elle devait répondre à des questions brèves : quel volume de ventes sur la période, combien de commandes, quelle part est expédiée ou encore à expédier, comment l’activité se répartit-elle dans le temps et quels objets concentrent le plus de chiffre d’affaires ? Elle n’avait pas à devenir une seconde page de recherche des commandes ou des offres.
Le deuxième arbitrage a porté sur la navigation. Neuf points d’entrée sont regroupés sous Marketplace : Overview, cinq outils spécialisés, puis Channels, Orders et Offers. La profondeur reste volontaire. Une alerte supposée sur une offre ne remplace pas la fiche de cette offre ; un classement de produit ne remplace pas sa vue PIM ; un total mensuel ne remplace pas les commandes qui le composent.
Le troisième arbitrage a séparé disponibilité technique et maturité produit. Le catalogue Resources référence sept fonctions marketplace, mais n’en marque que trois comme actives : Product Explorer, Stock Dispatcher et Listing Gap Matrix. Auto Process Order, Catalog Dispatcher, BuyBox & Repricing et Profit Leak Detector restent marqués Roadmap. Un lien ou une route présents dans le produit ne suffisent pas à transformer une fonction en capacité finalisée.
Enfin, chaque niveau a été testé selon sa responsabilité actuelle. Un test d’application vérifie que la route du dashboard Marketplace répond avec un utilisateur et des données autonomes. Un autre couvre le catalogue de fonctionnalités, ses statuts et ses parcours d’onboarding. Ces contrôles sécurisent le rendu et l’accès ; ils ne sont pas présentés comme une réconciliation comptable exhaustive de chaque chiffre affiché.
3. Quand chaque nouvelle vue améliore le produit mais fragilise son usage
La richesse fonctionnelle devient un problème si personne ne sait où commencer
Une application marketplace grandit rarement de manière linéaire. Une première vue affiche les canaux ; une autre reçoit les commandes ; une troisième suit les offres. Viennent ensuite la marge, la Buy Box, les écarts de listing, l’exploration produit ou la répartition de stock. Chaque ajout répond à une question valable, mais l’ensemble peut devenir plus difficile à utiliser que les outils dispersés qu’il remplace.
Le problème ne se résume pas au nombre de pages. Il tient à la nature différente de leurs preuves. Le chiffre d’affaires répond à une question de tendance. La commande répond à une question de traitement. L’offre décrit une position commerciale à un instant donné. La fiche produit relie plusieurs objets dans le temps. Un outil de listing compare présence et absence. La bonne décision dépend du passage maîtrisé entre ces niveaux.
Une vue unique aurait donné une impression de simplicité, au prix de nombreux raccourcis. Elle aurait dû réduire une commande à son statut, une offre à son prix, un stock à un nombre et une marge à un voyant. Dès qu’une source manque, qu’un calcul est estimé ou qu’un canal emploie un statut particulier, ce résumé peut devenir trompeur.
Le chantier a donc traité la dispersion par l’architecture de navigation et par des points d’entrée clairement nommés. Le dashboard ne remplace pas les espaces détaillés. Il sert de carte. Les recherches opérationnelles conservent les objets. Les outils spécialisés prennent le relais lorsque la question nécessite une logique dédiée.
4. Une architecture en trois étages pour passer du signal à la preuve
Vue d’ensemble, registres opérationnels, enquêtes spécialisées
Le premier étage est Overview. Il donne le revenu affiché, le nombre de commandes, trois compteurs de statuts, une lecture temporelle et quatre classements. Sa fonction est de faire apparaître une direction ou un écart : activité concentrée sur certains produits, progression ou recul face au mois précédent, marge portée par quelques marques, volume encore à expédier.
Le deuxième étage contient Channels, Orders et Offers. Ces trois espaces ne sont pas des annexes. Ils constituent les registres nécessaires pour vérifier le signal. Le canal précise la source et son contexte ; la commande conserve identifiant, date, statut et montant ; l’offre rattache un produit à un canal, un prix et un stock. La décision revient toujours à ces objets concrets.
Le troisième étage regroupe les outils spécialisés. Product Explorer ouvre le contexte d’une fiche et de ses vendeurs. Stock Dispatcher traite la répartition de disponibilité vers les offres. BuyBox & Repricing suit la compétitivité et la trajectoire de prix. Listing Gap Matrix repère les absences de catalogue. Profit Leak Detector cherche les zones de marge à examiner. Chacun possède sa route et sa logique.
Cette hiérarchie évite deux erreurs opposées. La première serait de rester dans les agrégats sans ouvrir la preuve. La seconde serait de commencer chaque journée dans une table de milliers de lignes sans savoir ce qui mérite une enquête. Ciama garde les deux profondeurs et rend leur enchaînement explicite.
5. Neuf points d’entrée sous une seule identité Marketplace
Une navigation stable qui ne gomme pas la spécialisation des écrans
Le menu Marketplace contient précisément neuf destinations. Overview ouvre la synthèse. Un sous-menu Features donne accès à Product Explorer, Stock Dispatcher, BuyBox & Repricing, Listing Gap Matrix et Profit Leak Detector. Les entrées Channels, Orders et Offers ferment le groupe avec les trois objets opérationnels de base.
Ce nombre n’est pas utilisé comme un argument de volume. Il montre plutôt la responsabilité de la navigation : permettre à une personne de retrouver un outil à partir de son univers métier, sans parcourir des sections techniques ou transverses. Tous les écrans spécialisés partagent ainsi le même voisinage et la même porte d’entrée.
L’état du menu suit les familles de routes Marketplace et Features. Une personne qui ouvre une recherche de commandes, un écran d’offre ou un outil spécialisé reste dans le contexte du module. Cette continuité réduit le coût cognitif du passage d’un diagnostic à sa vérification, même si les données et les interfaces restent séparées.
Une limite subsiste sur la route Overview générique. Elle utilise une route partagée par plusieurs univers, avec un paramètre marketplace, alors que l’ouverture visuelle du menu repose principalement sur des préfixes de routes. Le contenu est bien dédié à Marketplace, mais le comportement de navigation peut encore être harmonisé pour conserver tous les repères du sous-menu.
6. La vue d’ensemble donne une température, pas un verdict
Revenu, commandes, état d’exécution et objets qui concentrent les ventes
Le hero identifie explicitement Marketplace et présente deux premiers repères : le revenu du mois sélectionné et le nombre de commandes. Une carte complémentaire décompose le volume entre expédié, à expédier et erreurs ou remboursements selon les faits disponibles. Cette première lecture sert à repérer une tension d’exécution autant qu’un niveau d’activité.
Le dashboard ajoute ensuite une courbe de revenu face à un objectif, une série temporelle par univers et quatre tables de classement. Toutes les requêtes reçoivent le type marketplace. L’écran ne mélange donc pas silencieusement les ventes B2B ou e-commerce avec le périmètre que la personne pense observer.
Le résultat ne doit pas être interprété comme un diagnostic automatique. Une baisse dans la série ne dit pas si la cause vient d’une rupture, d’une offre, d’un prix, d’une fiche ou d’un changement de demande. Elle fournit le point de départ et la période. L’enquête se poursuit dans les classements puis dans les objets opérationnels ou les outils spécialisés.
Cette distinction rend le tableau de bord plus robuste commercialement. Il ne prétend pas remplacer le jugement du vendeur. Il réduit le champ de recherche, donne une comparaison et ouvre les fiches classées lorsque leur identifiant est disponible. La décision reste attachée à une preuve que la personne peut relire.
7. Dix plages temporelles, avec une granularité adaptée à la durée
Heures pour la journée, jours pour les séquences courtes, mois pour la tendance
Le service de séries accepte dix plages : aujourd’hui, sept jours, quinze jours, un mois, deux mois, quatre mois, trente jours, trois mois, six mois et douze mois. La liste peut sembler redondante entre un mois et trente jours, mais les bornes diffèrent : le mois suit le calendrier courant, alors que trente jours constitue une fenêtre glissante.
La journée est découpée par heure. Les fenêtres de sept, quinze et trente jours, ainsi que le mois courant, utilisent des points quotidiens. Les périodes de deux à douze mois utilisent des points mensuels. Le tableau ne force donc pas trois cent soixante-cinq barres sur une vue annuelle ni une moyenne journalière sur une journée en cours.
Les longues périodes s’appuient sur des tables de faits mensuels. Le mois courant utilise directement les commandes afin de conserver le bon nombre de jours, y compris les mois de vingt-huit, vingt-neuf, trente ou trente et un jours. Les autres courtes fenêtres lisent les lignes de commande et leur finance associée.
Sur la route Marketplace, la plage par défaut des graphiques et des classements est aujourd’hui, tandis que les cartes supérieures portent sur le mois choisi. Cette différence doit rester visible dans l’interprétation. Elle permet une lecture immédiate du jour dans un contexte mensuel, mais elle interdit de comparer deux blocs sans regarder leur période.
8. Séparer activité commerciale et état des commandes
Le même revenu ne raconte pas la même chose selon ce qui reste à expédier
Le revenu et le nombre total de commandes décrivent l’activité. Les compteurs shipped, to ship et erreurs apportent une lecture d’exécution. En mode mensuel, l’interface présente surtout des volumes de commandes pour ces états. En mode annuel, le template prévoit des montants par statut. Cette différence évite en principe de comparer un nombre de dossiers à une valeur financière.
Les données proviennent des faits mensuels regroupés au niveau du canal puis réunis par type marketplace. Le compte et l’année-mois font partie du filtre. La carte n’interroge pas toutes les commandes de la base avant de les filtrer dans le navigateur ; le cloisonnement intervient dans la requête.
Un compteur d’erreurs ne suffit toutefois pas à qualifier la nature du problème. Il peut regrouper des états annulés ou remboursés selon la construction des faits. Il ne précise ni la responsabilité, ni la possibilité de reprise, ni la conséquence client. La page de commandes reste nécessaire pour lire chaque cas.
L’écran ne déclenche aucune relance depuis ces cartes. Il ne possède pas de seuil d’alerte et ne construit pas une liste de priorités. Ce choix protège la sémantique du dashboard : montrer un état agrégé. Une action automatique demanderait une règle propre à chaque canal, statut et politique opérationnelle.
9. Comparer le revenu à un objectif sans fabriquer une trajectoire cumulée
Une référence mensuelle répartie sur les points de la période
Le compte peut posséder des objectifs mensuels par canal. Le contrôleur récupère l’objectif du mois sélectionné et le transmet au dashboard. Lorsque cette valeur est positive, le script la divise par le nombre de points de la période et trace une ligne de référence constante. Chaque jour reçoit donc une part égale de l’objectif mensuel.
Cette représentation répond à une question simple : le revenu du point observé se situe-t-il au-dessus ou au-dessous d’un rythme uniforme ? Elle ne représente pas une progression cumulée vers cent pour cent. Elle ne pondère pas les week-ends, les jours fériés, la saisonnalité, les opérations commerciales ou les différences de potentiel entre canaux.
Pour le mois et l’année, une série Y-1 peut également être ajoutée lorsque les données existent. Le revenu actuel, l’objectif et la référence précédente partagent ainsi le même axe temporel. Une absence de données produit une série vide plutôt qu’un chiffre estimé.
L’arbitrage reste prudent : cette courbe guide la lecture, elle ne calcule pas une prévision d’atterrissage. Pour passer d’un rythme constaté à un forecast, il faudrait modéliser jours restants, saisonnalité, stock, campagnes et événements de catalogue. Ce projet ne présente pas cette capacité comme livrée.
10. Quatre Top 10 pour trouver où l’activité se concentre
Produits, marques, catégories et tags partagent la même logique de comparaison
Le dashboard construit quatre classements limités à dix lignes : produits, marques, catégories et tags. Chaque table affiche un libellé, une quantité lorsque le chemin de données la fournit, un total de ventes, une évolution face au mois précédent et une marge. Le tri porte sur les ventes décroissantes.
Ces quatre dimensions transforment le même signal selon le niveau de décision. Le produit permet une enquête précise sur une référence. La marque révèle une concentration commerciale. La catégorie montre un déplacement de demande. Le tag laisse l’équipe analyser une segmentation propre à son catalogue sans ajouter une nouvelle structure métier.
Lorsque la personne clique sur un objet identifié, la vue correspondante peut s’ouvrir dans le PIM : produit, marque, catégorie ou tag. Ce passage est essentiel. Un rang seul peut être expliqué par une opération ponctuelle, un petit nombre de commandes à forte valeur ou une variation de marge. La fiche donne le contexte nécessaire avant toute action.
Le Top 10 ne prétend pas être une file de risques. Une première place signifie un volume de ventes élevé, pas une anomalie. Une baisse face à M-1 n’est pas automatiquement mauvaise si le produit est saisonnier ou arrêté. La page rend la concentration visible ; la qualification reste une enquête métier.
11. Canaux, commandes et offres restent les trois registres de vérification
Le module rapproche les accès sans écraser la profondeur opérationnelle
Channels répond à la question de provenance. Un canal possède une identité, un type, une connexion et un contexte de collecte. Lorsqu’une série du dashboard change, vérifier le canal concerné permet de distinguer un mouvement commercial d’une interruption de données ou d’un périmètre désactivé.
Orders répond à la question de réalisation. La commande porte sa référence, sa date d’achat, son statut, son montant et ses lignes. Un total à expédier devient compréhensible seulement lorsque les commandes concernées sont identifiées. La recherche dédiée offre cette granularité sans surcharger l’Overview.
Offers répond à la question de présence commerciale. Une offre rattache un produit à un canal et conserve ses informations de prix et de disponibilité. Elle sert de point de passage vers les opérations de rafraîchissement, de stock ou d’analyse concurrentielle lorsque ces fonctions sont couvertes.
Cette séparation évite une promesse fréquente mais fragile : « comprendre une baisse sans ouvrir plusieurs écrans ». Dans la réalité, plusieurs écrans sont parfois indispensables parce qu’ils portent des preuves différentes. Le gain vient de leur organisation et de leurs liens, pas de la disparition artificielle de la vérification.
12. Cinq outils spécialisés dans la navigation, cinq enquêtes distinctes
Explorer, répartir, comparer, détecter les absences et examiner la marge
Product Explorer est centré sur le produit observé sur une marketplace. Il relie la fiche collectée, les vendeurs et les fenêtres de Buy Box lorsque la source les fournit. Il répond à une enquête concurrentielle que la simple offre interne ne peut pas résoudre.
Stock Dispatcher traite une décision différente : la quantité à publier vers les offres. Il s’appuie sur les stocks et les règles de dispatch, puis conserve l’historique des tentatives dans son propre périmètre. Sa présence dans le module ne signifie pas que le dashboard calcule ou pousse lui-même le stock.
BuyBox & Repricing, Listing Gap Matrix et Profit Leak Detector couvrent respectivement la compétitivité prix, les absences de listing et les zones de rentabilité à examiner. Leur valeur vient de modèles et de filtres dédiés. Les réduire à trois voyants dans l’Overview ferait perdre les hypothèses et les détails qui expliquent leurs résultats.
Les cinq routes sont visibles dans le menu, mais le catalogue de fonctionnalités apporte une nuance décisive sur leur statut. La navigation montre la trajectoire et permet les parcours prévus ; le catalogue indique ce qui est marqué actif ou roadmap. La fiche publique reprend cette distinction au lieu de compter chaque lien comme une livraison complète.
13. Trois fonctions actives et quatre fonctions de roadmap clairement nommées
Un catalogue statique qui décrit la trajectoire sans simuler un état temps réel
Le catalogue Resources référence sept fonctions marketplace. Product Explorer, Stock Dispatcher et Listing Gap Matrix portent le statut Active. Auto Process Order, Catalog Dispatcher, BuyBox & Repricing et Profit Leak Detector portent le statut Roadmap. La page affiche ce statut à côté de la famille, du niveau et des indicateurs attendus.
Cette séparation protège le discours produit. Auto Process Order peut avoir une intention, un titre et un parcours d’onboarding sans être présenté comme un traitement automatique disponible. De même, un écran de Buy Box ou de profit peut exister à un stade de travail tout en restant explicitement classé dans la feuille de route.
Le statut est défini dans un catalogue PHP. Il n’est pas recalculé depuis les connexions actives du compte, les droits de la personne ou la présence réelle de données. « Active » décrit donc la maturité déclarée de la fonction, pas son activation chez chaque client. Le centre de contrôle des connexions reste responsable de cette autre vérité.
La distinction évite aussi une confusion commerciale. La roadmap n’est pas une promesse de date, et Active n’est pas une garantie de pertinence pour tous les vendeurs. Le cadrage d’un accompagnement marketplace doit encore vérifier les canaux, les sources, le volume et la décision attendue.
14. Un parcours de découverte avant l’ouverture de chaque outil
Comprendre le problème, la valeur attendue et la première action
Chaque entrée du catalogue peut ouvrir une page d’onboarding. Le parcours présente la douleur métier, la promesse, les indicateurs attendus, le fonctionnement, un scénario de démonstration, les risques d’inaction et les pages connexes. L’objectif est de donner du contexte avant de déposer la personne dans une interface spécialisée.
La progression de découverte est enregistrée dans le stockage local du navigateur sous une clé dédiée. Lorsqu’une fonction est marquée découverte, son score de connaissance est ajouté, le statut visuel change et le bouton d’accès direct remplace le bouton d’onboarding. Cette mécanique ne nécessite pas une écriture serveur.
Cette simplicité a une conséquence : le score n’est pas une mesure d’adoption collective. Il ne suit pas plusieurs appareils, ne prouve pas qu’une équipe utilise réellement la fonction et ne contrôle aucun droit. Effacer le stockage du navigateur remet la progression à zéro. Il s’agit d’un repère pédagogique local.
Le catalogue ne remplace donc ni la formation, ni le paramétrage, ni les autorisations. Il répond à un problème plus précis : faire comprendre pourquoi un outil existe et quelle première action essayer. La différence est importante pour ne pas transformer un élément d’interface en prétendu système de gouvernance.
15. Le compte connecté reste la frontière de chaque agrégat
L’unification de l’expérience ne doit jamais devenir un mélange de données
Le contrôleur récupère la personne authentifiée, puis l’identifiant de son compte. Cet identifiant est transmis aux requêtes de KPI mensuels, de séries par canal et de Top 10. La sélection marketplace est ajoutée comme filtre d’univers. Les deux dimensions — compte et type de canal — encadrent donc la lecture.
Ce choix est plus structurant qu’un filtre visuel. Une liste envoyée au navigateur puis réduite en JavaScript aurait exposé inutilement un périmètre plus large. Ici, la base produit directement les agrégats du compte demandé. La vue reçoit des valeurs déjà cloisonnées.
La même logique permet de réutiliser les services pour B2B ou e-commerce. Le contrôleur générique accepte seulement trois valeurs d’univers et choisit un template correspondant. Une valeur étrangère à cette liste ne peut pas sélectionner arbitrairement un type de canal supplémentaire.
L’article sur le centre de contrôle des connexions Ciama complète cette preuve : le compte détermine aussi quels fournisseurs et quelles fonctions peuvent alimenter les objets. L’Overview montre le résultat ; il ne contourne pas cette gouvernance.
16. Tester l’accès et les contrats visibles sans surévaluer la couverture
Des contrôles ciblés sur les routes, le catalogue et les agrégats sous-jacents
Le test d’application du dashboard crée un compte, un utilisateur authentifié et des données autonomes, puis ouvre la route Marketplace. Il suit les redirections éventuelles, exige une réponse HTTP 200 et vérifie qu’un rendu HTML contient au moins un lien navigable. Il protège ainsi le parcours minimal.
Le test du catalogue va plus loin sur son contrat d’interface. Il vérifie les marqueurs Ciama Discover, le score de connaissance, les colonnes, les identifiants de fonctions, les statuts Active et Roadmap, les boutons d’onboarding et d’ouverture. D’autres scénarios ouvrent les parcours de Product Explorer et BuyBox & Repricing.
Les requêtes financières possèdent par ailleurs des tests de régression sur les montants convertis, les statuts et la marge. Ces contrôles sont utiles parce que les classements mélangent ventes et finance. Ils ne prouvent toutefois pas, à eux seuls, qu’une copie de production réconcilie chaque source avec la comptabilité.
La page publique nomme cette limite. La qualité logicielle observée couvre la disponibilité des routes et plusieurs contrats de calcul ; elle ne devient ni un taux de couverture inventé, ni un résultat client chiffré. Une recette financière complète devrait comparer un échantillon de commandes et d’avoirs à leurs sources.
17. Ce que l’interface prépare sans encore le rendre pleinement utilisable
Un composant présent dans un template n’est pas forcément une fonction livrée
Le template contient un bloc intitulé Totals By Day By Channel. Le dashboard global sait construire ces séries, mais le contrôleur de l’univers Marketplace ne fournit pas aujourd’hui cette donnée à la vue dédiée. Sur ce parcours, le graphique reçoit donc sa valeur vide par défaut. La présence du conteneur ne suffit pas à annoncer une ventilation active.
Deux modales sont également décrites : commandes récentes et ventilation annuelle par univers. Leur HTML, leurs états de chargement et leurs fonctions de rendu existent. Le script de cette vue ne branche cependant ni déclencheur, ni appel réseau vers les URL préparées. Elles ne sont pas retenues parmi les gains du projet.
Les boutons Revenue et Orders du graphique empilé reflètent le paramètre sélectionné, mais sont affichés comme désactivés. Le service sait retourner les deux séries et le paramètre d’URL accepte les deux valeurs ; l’interface actuelle ne permet pas de basculer directement en cliquant sur ces boutons.
Enfin, le sélecteur de mois et d’année construit les routes du dashboard global. Changer la période depuis la vue dédiée quitte donc le chemin Marketplace au lieu de conserver automatiquement son filtre. Ces limites sont localisées et corrigibles, mais elles empêchent de décrire la vue actuelle comme un cockpit entièrement achevé.
18. Ce que les libellés financiers doivent encore clarifier
La précision fiscale compte davantage qu’un intitulé rassurant
Plusieurs composants portent le libellé Revenue HT. Pourtant, le chemin des KPI mensuels additionne actuellement le champ total_taxed des faits. Les classements de périodes mensuelles utilisent eux aussi total_taxed pour leur total de ventes. La série du mois courant, elle, repose sur price_untaxed_converted. Ces chemins ne doivent pas être décrits comme fiscalement identiques.
La bonne lecture publique consiste à parler du revenu affiché tout en signalant que la qualification HT doit être corrigée ou validée avant un usage financier. Changer seulement le texte serait insuffisant si le besoin cible est hors taxes ; changer seulement la requête serait risqué sans vérifier la construction historique des faits.
Les classements présentent aussi une colonne de quantité. Sur les fenêtres courtes, la requête additionne bien les quantités des lignes. Sur les périodes qui passent par les faits mensuels, la valeur est initialisée à zéro dans le résultat. Une lecture mensuelle ne doit donc pas comparer quantité et revenu comme si les deux provenaient du même agrégat complet.
Ces écarts ne rendent pas le module inutile. Ils définissent la prochaine exigence de fiabilisation : aligner libellé, source fiscale et granularité, puis ajouter des tests de présentation qui vérifient le contrat de chaque période. La transparence sur ce point protège mieux la décision qu’une affirmation générale de données fiables.
19. Des gains observables sans inventer de temps économisé
Une meilleure orientation, une enquête reproductible et une roadmap lisible
Le premier gain est la lisibilité de l’entrée Marketplace. Les personnes n’ont plus besoin de chercher commandes, offres et outils dans des familles sans rapport. Neuf destinations sont rassemblées sous le même univers, avec une séparation nette entre synthèse, fonctions spécialisées et registres opérationnels.
Le deuxième gain est la continuité entre agrégat et objet. Les quatre classements peuvent ouvrir les vues PIM correspondantes. Le menu garde les recherches Canaux, Commandes et Offres à proximité. Une observation peut ainsi être transmise à une autre personne avec une période, une dimension et une fiche à vérifier, plutôt qu’avec une impression générale.
Le troisième gain est la distinction explicite entre actif et roadmap. Trois fonctions sont présentées comme actives, quatre comme trajectoire. Cette information évite de cadrer une intervention sur une capacité supposée déjà disponible. Elle permet aussi de discuter la prochaine priorité sans réécrire l’histoire du produit.
Aucun pourcentage de gain, délai de traitement ou hausse de ventes n’est attribué à cette architecture. Ces résultats n’ont pas été mesurés dans le périmètre disponible. La transformation démontrée est structurelle : les niveaux de lecture sont nommés, accessibles et reliés, et leurs limites peuvent être transformées en travaux précis.
20. Scénario : une marque recule dans le classement Marketplace
Partir du signal, vérifier la période, puis choisir l’enquête appropriée
Une personne ouvre Overview en début de journée. Le revenu du mois donne le contexte, tandis que les graphiques et Top 10 utilisent la plage aujourd’hui par défaut. Dans le classement des marques, une marque apparaît avec un recul face au mois précédent. Cette observation n’est pas encore une cause : les périodes et les bases de comparaison diffèrent.
La première action consiste à confirmer la fenêtre souhaitée et à ouvrir la marque. Ses produits permettent de voir si le recul est diffus ou concentré. Le classement produit peut ensuite isoler les références qui portent la différence. À ce stade, la personne dispose d’objets précis plutôt que d’une simple variation de courbe.
Si les produits sont absents de certains canaux, Listing Gap Matrix devient l’enquête pertinente. Si leur stock doit être réparti vers des offres, Stock Dispatcher apporte une autre lecture. Si la question concerne les vendeurs et la Buy Box, Product Explorer donne le contexte concurrentiel. Le module n’impose pas un diagnostic unique.
Enfin, la commande ou l’offre concernée reste accessible dans son registre. La personne peut documenter le canal, la référence et le statut qui justifient son action. Si aucune de ces preuves ne confirme le problème, le recul reste une observation commerciale à surveiller, pas une anomalie fabriquée par le dashboard.
21. Faire évoluer le module à partir de ses frontières réelles
Fiabiliser la lecture avant d’ajouter une nouvelle couche de décision
La première évolution utile consiste à aligner les montants et leurs libellés. La vue doit choisir explicitement la base hors taxes ou toutes taxes comprises, appliquer cette règle aux KPI, séries et classements, puis la tester. Cette correction donne une base plus solide que l’ajout prématuré d’un nouveau voyant.
La deuxième évolution consiste à terminer les interactions déjà préparées : alimenter la ventilation quotidienne par canal sur la route Marketplace, brancher ou retirer les modales inactives, permettre le changement Revenue/Orders et conserver le filtre marketplace lorsque la période change. Le périmètre est précis et observable.
La troisième évolution concerne le catalogue. Les statuts Active et Roadmap peuvent rester éditoriaux, mais ils gagneraient à être séparés de la disponibilité réelle par compte. Une fonction pourrait être mature dans le produit tout en restant indisponible faute de connexion ou de droit. Les deux informations ne répondent pas à la même question.
Enfin, toute priorité automatique devrait être construite comme un projet distinct. Elle demanderait des règles explicites, une source de vérité, une explication du score, un propriétaire et une action réversible. L’architecture actuelle fournit les objets nécessaires, mais elle ne revendique pas encore ce moteur de décision.
22. Relier l’architecture du module à ses preuves spécialisées
Le dashboard, le contrôle produit et les connexions racontent chacun une partie du système
Le projet dashboard de ventes B2B, marketplace et e-commerce détaille la couche de reporting transverse dont la vue Marketplace réutilise les agrégats. Il explique comment comparer les univers sans perdre leur type de canal.
La matrice produit, stocks et offres par canal montre ce qui se passe après un classement : ouvrir une référence, comparer sa disponibilité et vérifier sa présence commerciale. Elle complète Overview sans lui attribuer ses propres capacités.
Le centre de contrôle des connexions décrit l’autre frontière du module. Une fonction active dans le catalogue ne produit des données que si le compte possède une connexion valide et la capacité correspondante.
Pour un besoin de direction ou de suivi commercial, notre page de reporting marketplace vendeur transforme ces preuves en cadrage de service. La page Ciama Marketplace présente, elle, la trajectoire produit qui relie ces différents projets.
23. Conclusion : un bon cockpit sait où s’arrête la synthèse
Organiser les décisions vaut mieux que promettre un écran omniscient
Ce projet donne à Ciama un univers Marketplace identifiable et navigable. Neuf points d’entrée réunissent Overview, cinq outils spécialisés, Canaux, Commandes et Offres. Le dashboard apporte le revenu affiché, les volumes de commandes, les séries temporelles et quatre Top 10 ; les autres espaces conservent la profondeur nécessaire pour vérifier chaque observation.
Sa force tient aussi à la distinction des états. Trois fonctions du catalogue sont marquées actives et quatre restent en roadmap. La progression d’onboarding demeure locale au navigateur. Les composants non alimentés, les interactions non branchées et les ambiguïtés HT/TTC sont nommés. Aucun de ces éléments n’est transformé en fausse preuve client.
La prochaine décision est ainsi plus simple à cadrer : corriger la sémantique financière, terminer les interactions préparées, relier la disponibilité au compte ou construire une règle spécialisée. C’est cette discipline que Dawap apporte comme agence marketplace vendeurs : faire du produit un chemin de décision vérifiable, sans masquer la complexité utile derrière une promesse de cockpit magique.
