Le projet en un coup d’œil
Activité, validité des accès, commandes et offres en stock devaient être rapprochées avant d’ouvrir l’analyse d’un canal.
La recherche montre cinquante canaux par défaut, sépare actifs et désactivés et fait remonter les plus contributeurs dans chaque groupe.
Revenus HT, commandes, pipeline, remboursements, années, tops et dernières commandes donnent plusieurs niveaux de lecture sans fabriquer une note automatique.
Une équipe présente sur plusieurs marketplaces a besoin de deux focales. La première doit signaler rapidement les canaux actifs, les accès devenus invalides, le volume de commandes et la profondeur d’offres réellement en stock. La seconde doit expliquer la trajectoire commerciale du canal retenu, année après année et jusque dans ses produits.
Dawap a relié ces deux focales dans Ciama. Le radar marketplace est limité au compte connecté et ordonne les canaux actifs avant les désactivés, puis les classe par nombre de commandes. Chaque ligne ouvre un espace canal avec revenus HT, pipeline, remboursements, objectifs, évolution annuelle, meilleurs produits, marques, catégories, tags et dernières commandes.
Cette chaîne de lecture a été livrée le 11 mars 2026 avec la consolidation des vues canal. Elle transforme le reporting marketplace vendeur en parcours d’investigation : repérer un canal, vérifier la qualité de son entrée, comprendre ses années et descendre vers les objets qui composent sa performance, sans prétendre qu’un indicateur unique dicte l’arbitrage.
1. Ciama, un cockpit où le canal relie configuration et résultat commercial
Une marketplace n’est ni un simple logo, ni une seule courbe de chiffre d’affaires
Le canal porte une identité, un compte, un type, un état actif et la validité de ses accès. Il conserve également des compteurs de commandes, d’offres actives, d’offres actives en stock et plusieurs agrégats de revenus ou de marge.
Les performances historiques sont calculées séparément dans des faits mensuels. Cette matière permet de reconstituer une courbe depuis le premier mois connu, une synthèse par année et des classements par produit, marque, catégorie ou tag.
Les objectifs ajoutent une troisième source. Ils sont enregistrés par mois, compte, univers et canal, puis additionnés par année pour mesurer un écart entre le revenu observé et la cible attribuée à cette marketplace.
Le projet devait réunir ces données sans les confondre. Le radar emploie les compteurs courants du canal ; la fiche détaillée s’appuie principalement sur l’historique mensuel et renvoie vers les commandes, offres ou analyses de profit lorsque la question devient plus précise.
2. Construire un entonnoir de lecture plutôt qu’un score opaque
État opérationnel, contribution, tendance puis détail des ventes
La première étape filtre strictement le compte et le type marketplace. Les canaux actifs remontent, puis le nombre de commandes les départage. Ce choix donne une priorité de lecture simple sans prétendre mesurer la valeur future du canal.
La deuxième étape ouvre une fiche protégée par le même compte. Quatre KPI résument les faits mensuels disponibles : revenus hors taxes, nombre de commandes, montants restant à expédier et montants remboursés.
La troisième étape rétablit le temps. Les mois absents entre la première activité et aujourd’hui sont complétés par zéro dans les graphiques ; la table annuelle compare chaque exercice à son objectif et à l’année précédente lorsque la base de comparaison existe.
Enfin, les classements et les dernières commandes expliquent la composition du résultat. Cette descente évite de confondre un canal en croissance avec un canal porté par une seule référence ou par quelques commandes exceptionnelles.
3. Avant le projet : tous les canaux se ressemblaient dans une liste
Le nom de la marketplace ne suffit pas à qualifier son état ni sa contribution
Une liste de logos confirme la présence d’un vendeur sur plusieurs marketplaces, mais elle ne révèle pas si le canal est encore actif, si ses accès sont valides, s’il a collecté des commandes ou si ses offres disposent de stock.
À l’inverse, un tableau trop ambitieux peut mélanger chiffre d’affaires, marge, incidents, potentiel et décisions commerciales dans une note difficile à expliquer. Une telle note aurait caché les données manquantes et les arbitrages propres au vendeur.
Le besoin était plus concret : disposer d’une entrée courte pour choisir le canal à examiner, puis retrouver une fiche assez riche pour comprendre son histoire commerciale sans repartir d’exports séparés.
Le projet a donc gardé le radar volontairement factuel. Il signale l’état et quelques volumes disponibles ; la suite du parcours ouvre la chronologie, les objectifs, la composition des ventes et les commandes concernées.
4. Limiter le radar aux marketplaces du compte connecté
Deux filtres obligatoires appliqués avant la recherche libre
Le contrôleur récupère le compte de l’utilisateur et l’ajoute systématiquement aux critères. Il ajoute ensuite le type marketplace. Un canal B2B ou e-commerce du même compte ne vient donc pas brouiller cette page.
Les canaux désactivés ne sont pas supprimés du résultat. Ils restent utiles pour comprendre le patrimoine de connexions et éviter qu’une marketplace historique disparaisse de la lecture au moment où elle cesse de tourner.
Le total affiché par la pagination compte toutes les lignes qui respectent le compte, le type et l’éventuelle recherche. Il permet de savoir si la page courante représente l’ensemble ou seulement une tranche.
Ce cloisonnement est répété à l’ouverture du détail. Connaître l’identifiant d’un canal d’un autre compte ne donne pas accès à ses ventes : la fiche répond par un refus avant de calculer les indicateurs.
5. Faire remonter les canaux actifs, puis ceux qui ont le plus de commandes
Une priorité de consultation simple et reproductible
Le tri par défaut commence par l’état actif en ordre décroissant. Les canaux utilisés apparaissent donc avant ceux qui ont été désactivés, sans qu’une recherche ou un filtre supplémentaire soit nécessaire.
À état égal, le nombre de commandes est trié du plus élevé au plus faible. Le radar met ainsi en tête les marketplaces qui pèsent le plus dans l’historique de commandes conservé sur l’objet canal.
Cette règle n’est pas un classement de rentabilité. Un canal très actif peut encore avoir une marge faible, beaucoup de remboursements ou un objectif non atteint. Le tri indique où commence la lecture, pas quelle décision prendre.
La recherche sait aussi trier par nom, date de mise à jour, nombre de commandes, commandes expédiées et montant TTC. L’écran actuel ne rend toutefois pas toutes ces options sous forme de contrôles visibles.
6. Rapprocher contribution et état opérationnel sur une seule ligne
Revenus HT, commandes, offres en stock, activation, accès et fraîcheur
Chaque ligne affiche le revenu hors taxes converti du canal lorsqu’il est non nul, puis son nombre de commandes et son nombre d’offres à la fois actives et en stock. Ces trois valeurs donnent un premier ordre de grandeur commercial.
L’état actif et la validité des accès sont affichés séparément. Un canal peut donc être actif avec des identifiants invalides, ou rester désactivé alors que ses accès ont déjà été validés.
La date de mise à jour aide à qualifier la fraîcheur de l’objet canal, sans être présentée comme la date de dernière commande ou de dernière synchronisation réussie. Ces notions possèdent leurs propres champs et parcours.
Le type marketplace et le logo complètent l’identité. Le logo dépend de l’identifiant de catalogue ; il n’est pas utilisé comme preuve de validité et n’influence aucun tri.
7. Retrouver un canal par son nom
Une correspondance partielle combinée au compte et à la famille
Le champ libre applique une correspondance partielle sur le nom du canal. Il ne recherche ni identifiant externe, ni provider, ni état des accès, ni montant de ventes.
La valeur saisie est reprise dans une facette visible. L’utilisateur conserve ainsi la raison pour laquelle sa liste est réduite et peut revenir à la vue complète sans interpréter un résultat partiel comme l’inventaire du compte.
La page charge cinquante résultats par défaut. Le total et le nombre de pages sont calculés avec exactement les mêmes filtres que les lignes, ce qui maintient la cohérence de la pagination.
Le compteur « canaux actifs » de l’en-tête est, lui, calculé en parcourant seulement les lignes chargées. Sur plusieurs pages, il ne représente donc pas le total des canaux actifs du compte ; cette limite reste explicitement assumée.
8. Relancer un historique de commandes depuis le canal choisi
Six plages proposées et une distribution qui exige une connexion valide
L’action commandes ouvre une fenêtre avec six choix : aujourd’hui, sept jours, trente jours, trois mois, un an ou une période personnalisée. Le choix par défaut porte sur la journée courante.
Pour sept et trente jours, le calcul inclut aujourd’hui en retranchant respectivement six et vingt-neuf jours puis en revenant au début du premier jour. Une période personnalisée fixe le début à minuit et la fin à 23 h 59 min 59 s.
Le serveur vérifie le jeton CSRF, l’existence du canal et son appartenance au compte. Il refuse aussi une borne de début postérieure à la fin avant de demander la distribution au service d’historique.
Le résultat indique le nombre de tranches envoyées. Si aucune connexion provider active et valide ne correspond au canal, aucun message n’est distribué et l’interface l’annonce au lieu de présenter une collecte fictive.
9. Collecter les offres avec ou sans période
Une action distincte qui crée sa trace avant la mise en file
La fenêtre des offres reprend les six plages mais ajoute un choix sans période, sélectionné par défaut. Le message peut ainsi demander l’état courant des offres ou une lecture historique bornée lorsque l’adaptateur l’accepte.
Le contrôleur vérifie le jeton, le compte, le provider lié au canal et l’existence d’au moins une connexion provider active dont les accès sont valides. Sans ces conditions, il s’arrête avant la distribution.
Chaque connexion admissible produit un message. Celui-ci contient la connexion, le canal, les bornes éventuelles et un identifiant de trace créé avec le mode historique et la fonction de synchronisation des offres.
La réussite de toutes les connexions valides signifie que plusieurs messages peuvent partir pour le même provider si les données en contiennent plusieurs. La page restitue leur nombre ; elle ne prétend pas qu’un clic correspond toujours à une seule requête distante.
10. Ouvrir la fiche seulement après avoir choisi le canal
Une page protégée qui recharge son propre historique analytique
Le nom du canal mène vers son overview. Le contrôleur recharge l’objet par identifiant, vérifie son existence puis compare le compte propriétaire à celui de l’utilisateur connecté.
Cette étape ne reprend pas aveuglément les agrégats du radar. Elle interroge les faits mensuels propres au canal, les objectifs, les commandes récentes et quatre dimensions de classement.
Le bandeau conserve le nom, l’identifiant catalogue, l’état actif, le type, le nombre de commandes et le nombre d’offres actives. Ces repères empêchent de perdre le contexte lorsque l’analyse devient plus profonde.
Quatre onglets structurent ensuite le parcours : vue d’ensemble, offres, commandes et profit. L’utilisateur peut changer d’angle sans devoir rechercher à nouveau la marketplace.
11. Commencer la fiche par quatre indicateurs de vente
Revenus HT, commandes, pipeline à expédier et remboursements
Les revenus HT additionnent les montants hors taxes des faits mensuels du canal. Le compteur de commandes additionne leurs volumes sur la même série, ce qui donne un périmètre cohérent aux deux premiers KPI.
Le pipeline additionne les montants associés aux commandes ou lignes encore à expédier. Les remboursements rassemblent les montants marqués comme remboursés dans la série mensuelle.
Les quatre valeurs ne sont affichées que si la vue annuelle trouve des faits. En leur absence, l’interface montre un tiret plutôt que de transformer une absence d’historique en zéro certain.
Ces KPI couvrent toute la période disponible dans le graphique, du premier mois ayant du revenu ou des commandes jusqu’au mois courant. Ils ne constituent donc pas une photographie limitée à l’année en cours.
12. Reconstituer chaque mois depuis la première activité connue
Des zéros explicites entre les points réellement présents
La chronologie cherche d’abord le premier mois où le canal possède un revenu ou des commandes. Elle prépare ensuite chaque mois jusqu’à la date courante avec des valeurs initiales à zéro.
Les faits réels remplacent ces zéros pour le revenu HT, les montants expédiés, à expédier ou remboursés, et le nombre de commandes. Un mois absent reste ainsi visible dans la continuité du graphique.
Trois onglets graphiques présentent les revenus, les commandes et les états de commande. La série temporelle évite de comparer uniquement deux totaux cumulés qui pourraient cacher une rupture récente.
Un zéro complété signifie qu’aucun fait mensuel n’a alimenté ce point. Il ne permet pas à lui seul de distinguer une absence de ventes d’un retard de calcul analytique ; la fraîcheur des collectes doit être vérifiée séparément.
13. Résumer chaque exercice et conserver le lien vers les mois
Revenus HT et commandes groupés par année, de la plus récente à la plus ancienne
La table annuelle additionne les faits de granularité canal pour chaque année. Elle affiche les revenus hors taxes et le nombre de commandes, puis ajoute une ligne de total sur toutes les années présentes.
Les années sont classées de la plus récente à la plus ancienne. Chaque libellé ouvre une vue dédiée qui permet de descendre au détail mensuel de l’exercice choisi.
Un second jeu de données alimente un graphique annuel dans l’ordre chronologique. La page peut ainsi présenter la tendance sans imposer le même sens de tri au tableau de consultation.
Le total général n’additionne ni objectifs ni écarts interannuels, car ces valeurs ne seraient pas interprétables comme un simple cumul. Les cellules correspondantes restent volontairement vides.
14. Comparer chaque année à son objectif et à l’exercice précédent
Deux références différentes pour deux questions de pilotage
Les objectifs mensuels rattachés au compte, à l’univers canal et à cette marketplace sont additionnés par année. Une cible absente ou égale à zéro est affichée comme non renseignée.
Lorsque la cible est positive, l’écart correspond au revenu annuel moins l’objectif. Une valeur positive montre un dépassement ; une valeur négative mesure le montant restant sous la cible.
La comparaison à l’année précédente calcule d’abord l’écart de revenu, puis son pourcentage si le revenu précédent existe et n’est pas nul. Une base nulle ne produit pas un taux infini ou artificiel.
Objectif et évolution répondent à deux questions différentes. Un canal peut progresser par rapport à l’année précédente tout en restant sous son objectif, ou dépasser une cible prudente malgré un recul.
15. Expliquer les ventes par quatre classements de dix lignes
Produits, marques, catégories et tags ordonnés par revenus HT
La fiche calcule un top dix des produits à partir des faits de granularité canal-produit. Chaque ligne réunit l’identifiant, une vignette lorsqu’elle existe, le revenu hors taxes et la quantité issue du nombre de lignes agrégé.
Trois classements équivalents regroupent les faits par marque, catégorie et tag. Ils utilisent chacun leur granularité analytique et excluent les dimensions dont l’identifiant est absent.
Tous sont classés par revenu HT décroissant. La marge totale est disponible dans les résultats techniques mais n’est pas affichée dans ces quatre tables ; la fiche ne transforme donc pas ces tops en classements de rentabilité.
Cette lecture révèle la concentration du canal. Une trajectoire positive peut être portée par quelques références, une marque dominante, une catégorie saisonnière ou un ensemble de tags cohérent.
16. Rapprocher la synthèse des dix dernières commandes
Une vérification transactionnelle sous les agrégats
La fiche charge les dix commandes du canal ayant les dates d’achat les plus récentes. Chacune conserve un lien vers son détail, sa date et son statut.
La table montre également le mode de préparation par le vendeur ou la plateforme, le pays de livraison, le revenu HT et les coûts disponibles : commission, expédition et achat.
La marge et son taux complètent la ligne lorsque les données nécessaires existent. L’identifiant d’intégration ERP et la date de mise à jour permettent de relier la vente à son parcours opérationnel.
Cette liste n’est pas un échantillon statistique et ne remplace pas l’historique complet. Elle sert à vérifier rapidement si la tendance agrégée correspond aux transactions les plus récentes observables.
17. Séparer overview, offres, commandes et profit
Une même identité canal, plusieurs questions métier
L’overview répond à la question de trajectoire. L’onglet offres liste le catalogue diffusé sur ce canal ; l’onglet commandes descend dans les lignes de vente ; l’onglet profit cible les données dont la marge est calculable.
La vue profit sélectionne les lignes expédiées avec calcul de marge et les charge par groupes de cent. Elle distingue la marge observée de la marge estimée grâce au résolveur commun du cockpit.
Le graphique de profit suit les agrégats mensuels du canal. Une fenêtre dédiée peut détailler, mois par mois, la marge totale, la part réelle et la part estimée au lieu de les mélanger dans un chiffre non qualifié.
Cette navigation justifie de ne pas surcharger le radar initial. Une information de marge sérieuse demande son périmètre, son état de calcul et sa profondeur de données ; elle mérite donc un espace spécifique.
18. Rendre visibles les limites de la version livrée
Un radar factuel, pas un moteur automatique de stratégie canal
La colonne Buy Box du radar affiche encore un tiret pour toutes les lignes. Aucun pourcentage n’est calculé dans cette vue, même si d’autres briques Ciama suivent la compétition Buy Box.
Le compteur de canaux actifs compte uniquement les cinquante lignes chargées par défaut ou la page courante. Le total voisin couvre, lui, tout le résultat paginé ; les deux valeurs ne doivent pas être comparées comme si elles avaient le même périmètre.
Un revenu de zéro et une valeur non renseignée produisent le même tiret dans la liste. La fiche détaillée et la fraîcheur analytique doivent être consultées avant de conclure à une absence réelle de ventes.
Le lien « Update » du menu de ligne n’ouvre aucune édition dans cette version. Surtout, aucun score ne recommande de pousser, suspendre ou fermer un canal : la décision reste fondée sur les données ouvertes dans les vues suivantes.
19. Ce qui change après la livraison
Une revue canal part d’un repère commun et descend sans rupture
L’équipe commence par les marketplaces actives qui concentrent le plus de commandes. Elle repère immédiatement un accès invalide ou un faible nombre d’offres en stock avant d’interpréter la performance commerciale.
L’ouverture du canal remplace le total isolé par une trajectoire. Les mois, années, objectifs et écarts permettent de distinguer un ralentissement ponctuel, une croissance durable ou une cible devenue irréaliste.
Les tops expliquent ensuite d’où vient le revenu. Les dix dernières commandes donnent un contrôle concret et les onglets spécialisés prolongent l’analyse vers les offres, les ventes détaillées ou la marge.
Ce parcours renforce le reporting marketplace vendeur sans fabriquer de verdict : une donnée observable conduit à la vue suivante, puis l’équipe arbitre avec le contexte commercial réel.
20. Le scénario terrain qui résume le projet
Un canal très contributeur apparaît actif mais ses accès sont invalides
Le radar place une marketplace en haut de la liste parce qu’elle est active et possède beaucoup de commandes. La même ligne affiche pourtant des accès invalides et un nombre d’offres en stock plus faible qu’attendu.
L’équipe ouvre la fiche. La courbe montre une baisse sur les derniers mois, tandis que l’année reste au-dessus de la précédente mais sous l’objectif. Le top produits révèle qu’une part importante du revenu repose sur quelques références.
Les dix dernières commandes confirment que les transactions récentes se raréfient. Avant de conclure que le canal perd son intérêt, l’équipe dispose d’un autre signal : la collecte peut être fragilisée par la connexion.
Elle corrige d’abord les accès, lance une collecte ciblée de commandes et d’offres, puis contrôle leur exécution. La décision commerciale vient après la remise à niveau de la donnée, pas à partir d’un tableau incomplet.
21. Livrer la lecture canal en couches cohérentes
Recherche, vues détaillées, objectifs et actions de collecte reliés dans le même parcours
Le socle de canaux et leurs compteurs existait avant la nouvelle fiche. Le lot de mars 2026 a ajouté les vues overview, année, mois, offres, commandes et profit autour d’une navigation commune.
Les requêtes analytiques ont été séparées par granularité : canal pour la chronologie, canal-produit, canal-marque, canal-catégorie et canal-tag pour les classements. Cette séparation évite de sommer indistinctement des lignes déjà agrégées.
Les contrôleurs revérifient la propriété du canal avant chaque vue. Les actions de collecte ajoutent leurs propres contrôles de compte, de jeton, de dates et de connexion provider valide.
Les évolutions suivantes ont aligné les routes et les tris sans changer la promesse centrale. Le parcours reste maintenable parce que chaque écran répond à une question limitée et partage seulement l’identité du canal.
22. Relier le canal à l’histoire globale du vendeur
Trois preuves complémentaires pour comparer, superviser et expliquer
La fiche historique des ventes par canal détaille la mémoire mensuelle qui rend possibles les courbes, les exercices et les comparaisons dans le temps.
Le projet dashboard multicanal Ciama reprend une focale plus large pour comparer marketplace, e-commerce et B2B dans un même ensemble.
Le journal des synchronisations apporte la preuve d’exécution nécessaire lorsqu’une donnée canal paraît absente, ancienne ou incohérente.
Ensemble, ces briques séparent correctement trois questions : quel canal examiner, comment évolue-t-il et les traitements qui l’alimentent ont-ils réellement terminé ?
23. Conclusion
Le canal devient un chemin d’analyse, pas une note qui remplace la décision
Le radar Ciama hiérarchise la consultation avec une règle vérifiable : actifs d’abord, puis volume de commandes. Il rapproche ensuite revenu, offres en stock, validité des accès et date de mise à jour sans prétendre résumer la valeur d’une marketplace.
La fiche canal ajoute le temps, les objectifs, les classements et les transactions récentes. Les limites restantes sont visibles : Buy Box absente du radar, compteur actif limité à la page, zéro non distingué d’une absence et décision stratégique laissée à l’équipe.
Pour construire cette lecture sur vos propres ventes, notre accompagnement Reporting marketplace vendeur part des sources réellement disponibles, qualifie leurs périmètres puis organise la descente du signal global jusqu’à l’action vérifiable.
