Ciama : classer les offres marketplace par fuite de marge et potentiel de récupération

1. Ciama, du calcul financier à une file d’offres à examiner

Le détecteur réutilise la donnée transactionnelle au lieu de créer une comptabilité parallèle

Ciama conserve sur les lignes de commande les montants financiers convertis : chiffre d’affaires hors taxes, marge calculée ou estimée, coût de commission, coût de transport et coût d’achat. Le Profit Leak Detector ne recalcule pas ces écritures depuis des hypothèses isolées ; il agrège les valeurs disponibles pour le compte connecté.

Chaque agrégat garde le contexte de l’offre : identifiant, canal marketplace, produit, marque, catégorie, nombre de lignes et dernière date de commande. Le résultat peut ainsi être filtré et rouvert au niveau de l’offre qui porte réellement le problème.

Le seuil de comparaison vient du taux de marge du canal. Lorsque cette valeur est absente ou non positive, le module utilise 15 %. Une valeur supérieure à 80 % est ramenée à 80 %. La règle est visible et stable, mais elle ne remplace pas le paramétrage métier du canal.

Cette frontière distingue le projet de la lecture de marge par produit, marque et catégorie. Cette dernière explore la performance ; le détecteur construit une priorité au niveau de l’offre et mémorise ce que l’utilisateur décide de faire.

2. Rendre chaque étape du classement vérifiable

Sélection, agrégation, écart, cause, score, action puis nouvelle observation

Le parcours commence par sélectionner uniquement les lignes du compte, rattachées à une offre et à un canal de type marketplace. Une marge calculée ou une estimation de marge doit être disponible, et la date d’achat doit entrer dans la période choisie.

La requête regroupe ensuite les montants par offre, canal, produit, marque et catégorie. Le moteur compare la marge agrégée à la marge cible, puis applique ses règles de cause dans un ordre déterminé. Il ne produit donc pas une explication opaque.

Le score combine quatre signaux documentables. Une cause, une sévérité et une estimation de récupération complètent le résultat. Le contrôleur écarte les offres sans impact, sauf celles qui manquent de données, puis applique les filtres et le tri demandés.

Enfin, une action crée un événement daté avec l’offre, la cause et l’impact observé. Le tableau de récupération peut comparer cette valeur initiale à l’agrégat courant. Le lien entre mesure et action reste consultable, sans attribuer automatiquement toute amélioration à cette action.

3. Partir des montants financiers déjà portés par les commandes

Le détecteur ne fabrique pas une deuxième définition de la marge

La source est la ligne de commande. Elle doit être reliée à son objet finance, à son offre et à son canal. Cette exigence garde une chaîne courte entre la vente observée et la priorité présentée.

Le chiffre d’affaires utilise le prix de ligne hors taxes converti. La marge prend d’abord la valeur calculée et, si elle manque, sa valeur estimée. La même préférence réel puis estimé s’applique aux coûts de commission, de transport et d’achat.

Une ligne n’entre dans l’analyse que si le calcul ou l’estimation de marge est marqué comme effectué. Le module ne transforme donc pas une valeur absente en résultat fiable.

Le mélange possible entre montants calculés et estimés reste une limite à lire offre par offre. La confiance du détecteur décrit surtout la présence de revenu, le volume de lignes et la cause ; elle ne certifie pas le statut comptable de chaque composante.

4. Limiter la lecture au compte, aux marketplaces et à la période demandée

Trois horizons cadrent le détecteur : trente, quatre-vingt-dix ou cent quatre-vingts jours

L’utilisateur choisit 30, 90 ou 180 jours. Toute autre valeur revient à 90 jours. La date de départ est fixée à minuit, puis seules les commandes achetées depuis cette borne participent au calcul.

Le compte courant constitue la première frontière d’isolation. Le canal doit porter le type marketplace et la ligne doit posséder une offre. Les ventes e-commerce ou les lignes non rattachées ne sont pas silencieusement fusionnées à cette analyse.

La requête prépare au maximum deux mille agrégats avant le score. Après qualification, filtrage et tri, l’écran en conserve au maximum cinq cents.

Ces limites protègent la vue opérationnelle. Elles signifient aussi que le tableau est une sélection priorisée, pas un export financier exhaustif lorsque le périmètre dépasse les bornes.

5. Regrouper les ventes par offre sans perdre leur contexte commercial

Canal, produit, marque et catégorie accompagnent chaque agrégat

Les sommes sont constituées au niveau de l’offre et de son canal, avec le produit, la marque et la catégorie associés. Une même référence commerciale diffusée par deux canaux reste donc représentée par deux offres distinctes.

Le résultat additionne le chiffre d’affaires, la marge, la commission, le transport et l’achat. Il compte également les lignes de commande et retient les dates de commande et de mise à jour les plus récentes.

Cette granularité répond à une décision concrète : faut-il examiner cette offre sur ce canal ? Elle évite qu’une bonne performance sur une marketplace compense visuellement une fuite sur une autre.

Le tag n’entre pas dans le regroupement permanent, mais une jointure dédiée l’utilise lorsqu’un filtre de tag est demandé. La marque et la catégorie servent également de portes d’entrée vers une famille de situations.

6. Comparer la marge observée à l’objectif du canal

Le manque à gagner commence par une cible explicite

Le taux cible provient du canal de l’offre. Si sa valeur est nulle ou négative, Ciama retient 15 %. Si elle dépasse 80 %, le calcul la borne à 80 %.

Le montant cible correspond au chiffre d’affaires hors taxes multiplié par ce taux. Pour mille euros de revenu et une cible de vingt pour cent, le repère atteint deux cents euros.

Le taux de marge observé divise la marge agrégée par le revenu. Il n’est calculé que lorsque le revenu est strictement positif ; sinon, le dossier bascule vers la cause de donnée manquante.

La cible s’applique actuellement au canal. Le code ne lit pas ici un seuil spécifique à la marque, à la catégorie, à la saison ou au produit. Ces dimensions servent au filtrage, pas à modifier la règle de comparaison.

7. Mesurer uniquement l’écart positif entre la cible et la marge

Une offre au-dessus de son objectif ne génère aucune fuite

L’impact correspond au montant cible moins la marge, avec un plancher à zéro. Une marge supérieure à la cible ne crée jamais un impact négatif qui viendrait compenser une autre offre.

Lorsque le taux observé atteint ou dépasse le taux cible, la cause devient NO_LEAK. Le contrôleur écarte alors la ligne puisque son impact est nul.

À l’inverse, une marge négative agrandit l’écart : le montant cible reste positif tandis que la marge passe sous zéro. Cette situation reçoit une cause prioritaire avant l’analyse détaillée des frais.

Le total affiché additionne les impacts des offres qui survivent aux filtres et à la limite finale. Il doit donc être lu avec la période, les filtres et le nombre de lignes visibles.

8. Attribuer cinq causes dans un ordre déterministe

Une cause principale oriente le contrôle sans prétendre remplacer l’enquête

Un revenu nul ou négatif produit MISSING_DATA. Une marge négative produit NEGATIVE_MARGIN. Une offre au-dessus de sa cible produit NO_LEAK et sort de la file active.

Pour une offre sous sa cible, le moteur examine ensuite les ratios de coûts. Une commission au moins égale à 20 % du revenu ou un transport au moins égal à 15 % produit HIGH_FEES.

Si les frais n’ont pas déclenché cette règle mais que le coût d’achat atteint 70 % du revenu, la cause devient PRICE_GAP. Les autres écarts sous la cible sont classés LOW_MARGIN.

L’ordre compte : une marge négative reste qualifiée comme telle même si les frais sont élevés. De même, HIGH_FEES précède PRICE_GAP. La cause est donc le premier diagnostic compatible, pas une décomposition exhaustive de tous les facteurs.

9. Construire un score sur cent avec quatre signaux

L’impact pèse la moitié de la priorité

Le premier signal transforme le ratio impact sur revenu en score. Un ratio de vingt pour cent atteint le plafond de cent ; ce signal représente 50 % du résultat final.

La fréquence transforme le nombre de lignes en score, avec cinquante lignes pour atteindre cent. Elle pèse 25 %. Une fuite répétée remonte ainsi devant un cas comparable observé une seule fois.

La récence pèse 15 %. Une dernière commande vieille d’au plus sept jours vaut cent, puis le signal passe à soixante-dix jusqu’à trente jours, quarante-cinq jusqu’à soixante jours et vingt au-delà.

La confiance fournit les 10 % restants. Le total est arrondi à une décimale et borné à cent. Les dossiers MISSING_DATA reçoivent malgré tout un plancher de quarante afin de rester visibles dans la file de correction.

10. Traduire le score en quatre niveaux de sévérité

Les seuils rendent la lecture immédiate et reproductible

Un score d’au moins 75 est critique. Entre 55 et 74,9, il est élevé. Entre 35 et 54,9, il est moyen. En dessous de 35, il est faible.

Cette sévérité dépend du score composite, pas seulement du montant en euros. Une petite fuite très récente et répétée peut donc être mieux classée qu’un écart plus ancien avec peu de lignes.

L’interface affiche les nombres de cas critiques, élevés, moyens et faibles. Un filtre permet ensuite d’isoler chaque niveau.

Le seuil n’exécute aucune action automatique sur une offre. Il ordonne l’attention ; l’utilisateur conserve la décision de vérifier la donnée, de préparer un prix ou de différer le sujet.

11. Distinguer la force du signal de sa sévérité

Le volume de lignes et la présence de revenu modulent la confiance

Une donnée manquante reçoit une confiance de trente-cinq. Un revenu ou un nombre de lignes non positif vaut quarante. Une offre fondée sur moins de trois lignes vaut soixante-cinq.

À partir de trois lignes, lorsque la cause n’est pas MISSING_DATA et que les données minimales sont présentes, la confiance vaut cent.

Ce signal reste volontairement simple. Il ne mesure ni la qualité d’une source ERP, ni le rapprochement d’une facture de commission, ni l’exhaustivité des coûts indirects.

L’écran affiche la confiance de chaque ligne et sa moyenne sur le résultat courant. L’équipe peut ainsi séparer un impact sévère mais peu étayé d’un écart observé sur plusieurs ventes.

12. Présenter un potentiel de récupération sans le confondre avec une prévision

Un coefficient conventionnel aide à ordonner les opportunités

L’estimation multiplie l’impact par un taux associé à la cause : 55 % pour une marge négative, 50 % pour un écart de prix, 40 % pour une marge faible et 30 % pour des frais élevés.

Lorsqu’il existe moins de trois lignes, le montant est encore réduit de 15 %. Une donnée manquante produit zéro, puisque le moteur ne possède pas de base monétaire fiable.

L’interface nomme cette valeur « récupération estimée à trente jours ». Le calcul ne projette toutefois ni cadence future, ni élasticité du prix, ni délai réel de correction. Il applique un coefficient au manque observé sur la période.

La fiche la présente donc comme un repère de tri. Un montant affiché ne constitue ni une promesse de marge récupérée ni une mesure financière validée.

13. Retrouver une offre par son identifiant et son contexte

Recherche, canal, marque, catégorie et tag agissent avant ou après le score

La recherche textuelle porte sur l’identifiant de l’offre, le SKU vendeur de la ligne et l’identifiant du produit. Elle permet de revenir à un cas connu sans parcourir toute la liste.

Le canal, la marque, la catégorie et le tag sont appliqués dans la requête financière. La sévérité, la cause et la file de priorité sont appliquées une fois le score calculé.

Le tri accepte l’impact, le score, le revenu, le taux de marge réel, la dernière commande, la mise à jour, la récupération estimée ou la confiance. Le sens croissant ou décroissant est contrôlé.

Par défaut, le tri place l’impact le plus élevé en premier. La période et tous les filtres restent indispensables pour interpréter le total de la page.

14. Organiser les dossiers en files de travail

Confiance élevée, données à corriger et surveillance sont opérationnelles

Une cause MISSING_DATA rejoint la file data_fix_needed. Les autres dossiers dont la confiance atteint quatre-vingt-cinq rejoignent high_confidence.

Les autres situations basculent dans monitoring. Cette file conserve les dossiers dont la cause mérite d’être suivie sans disposer du niveau de confiance requis pour passer devant les contrôles plus solides.

Les compteurs de chaque file restent reliés aux offres visibles. L’utilisateur peut ouvrir une file, ajouter une cause ou une sévérité, puis trier les lignes par impact ou par récence.

Le classement ne déclenche aucune action. Il transforme une liste financière en ordre de lecture, tout en laissant la vérification et la décision à la personne responsable du canal.

15. Résumer la sélection sans masquer les règles de calcul

Impact, taux, offres, sévérité et confiance restent reliés aux lignes

La synthèse affiche le nombre d’offres impactées, le revenu cumulé, l’impact total, le ratio impact sur revenu, la récupération conventionnelle et la confiance moyenne.

Elle compte également les quatre niveaux de sévérité. Un graphique répartit les offres par cause principale et un panneau montre les files de priorité.

Ces indicateurs sont recalculés sur les lignes conservées après scoring, filtres, tri et limite. Ils ne décrivent pas nécessairement l’intégralité du compte si plus de cinq cents résultats correspondent.

Chaque ligne renvoie vers la vue de l’offre. Le tableau reste donc une porte d’entrée vers le détail, pas une surface qui prétend expliquer seule toute la finance.

16. Associer chaque cause à un contrôle cohérent

Les recommandations encadrent l’enquête avant l’action

Une marge négative appelle la vérification du prix plancher, des frais récents et du coût d’achat relié au SKU. Des frais élevés orientent vers le mode logistique, les surtaxes et la capacité du prix à absorber les coûts.

Un écart de prix invite à comparer prix, achat moyen et frais variables, puis à contrôler TVA et conversion de devise. Une donnée manquante appelle le complément des coûts, du mapping ou des taux avant de relancer le calcul.

Une marge faible sans cause plus précise reste en surveillance, avec un contrôle des variations de coûts et de frais canal.

Ces playbooks sont des listes de vérification issues de la cause déterministe. Ils ne modifient ni prix, ni stock, ni données financières par eux-mêmes.

17. Enregistrer trois décisions sans automatiser silencieusement l’offre

Repricing, garde-fou et report créent un événement daté

Chaque action exige un jeton CSRF valide et appartient au compte connecté. Le contrôleur accepte uniquement open_repricing_prefill, create_guardrail_task et snooze.

L’événement conserve l’utilisateur, l’offre lorsqu’elle existe, la cause, une clé offre-cause, l’impact avant action, la récupération estimée, le type et la date.

L’état enregistré est executed : il atteste que le geste d’interface a été traité. Il ne prouve pas qu’un nouveau prix a été publié ou qu’une marge a déjà été récupérée.

La dernière action des quatre-vingt-dix jours est rapprochée de chaque opportunité. Elle apparaît dans le tableau afin d’éviter qu’un même dossier soit repris sans contexte.

18. Ouvrir le contexte de prix, consigner un garde-fou ou reporter

Chaque bouton possède une portée précisément bornée

L’action Repricing enregistre l’événement puis redirige vers le suivi Buy Box avec l’identifiant de l’offre comme recherche. Elle prépare le contexte ; elle ne change pas automatiquement le prix.

L’action Guardrail écrit une tâche libellée profit_leak_guardrail_followup dans le journal de l’événement. Dans cet état du module, elle constitue une trace de suivi et non un ticket envoyé à un outil externe.

Le report accepte sept ou trente jours. Sa date de fin est stockée dans le payload ; tant que le dernier événement de l’opportunité est ce report actif, la ligne disparaît du détecteur.

Une action plus récente remplace le report comme dernier événement. Cette mécanique simple garde une seule décision courante par couple offre-cause.

19. Comparer l’impact avant action à l’impact courant

Le tableau de récupération mesure un écart, pas une attribution causale

Le tableau de suivi propose des périodes de 14, 30 ou 90 jours. Il recalcule les opportunités courantes et charge les dernières actions Repricing ou Guardrail de la période.

Pour chaque clé offre-cause, il conserve la dernière action. La récupération affichée est le maximum entre zéro et l’impact avant action moins l’impact courant.

La vue additionne les fuites identifiées, actionnées et récupérées, calcule un taux de récupération, compte les opportunités actionnées et rapproche ce nombre du volume courant.

Si une opportunité ne figure plus dans la période courante, son impact est lu comme zéro. Une sortie peut venir d’une amélioration, d’un changement de cause, d’une absence de ventes ou de la fenêtre temporelle. Le tableau décrit donc une évolution à instruire, jamais la causalité certaine de l’action.

20. Tester les règles centrales et les deux vues du module

Les cas critiques, incomplets et sans fuite possèdent des contrôles dédiés

La suite unitaire vérifie qu’une marge négative produit une cause NEGATIVE_MARGIN, une sévérité critique, une action urgente et un potentiel positif.

Elle vérifie aussi qu’un revenu nul produit MISSING_DATA avec un impact et une récupération à zéro, ainsi qu’un playbook de correction.

Un troisième cas confirme qu’une marge au-dessus de la cible produit NO_LEAK et reste en surveillance sans impact.

Deux tests applicatifs ouvrent le détecteur et son tableau de récupération avec un compte authentifié et des données préparées. Ils contrôlent la réponse et la présence de liens navigables. La séparation des routes intervenue ensuite garde les contrôleurs d’index, d’action et de suivi distincts.

21. Suivre une offre récente qui reste sous la cible de son canal

Du calcul de l’écart à une décision relisible

Une offre marketplace totalise mille euros hors taxes sur la période. Son canal vise vingt pour cent de marge, soit deux cents euros, mais les lignes financières n’en conservent que quatre-vingts. L’impact calculé atteint cent vingt euros.

Le coût de commission reste sous vingt pour cent et le transport sous quinze. Le coût d’achat atteint cependant au moins soixante-dix pour cent du revenu : la cause principale devient PRICE_GAP.

Le score combine le ratio d’impact, le nombre de lignes, la récence de la dernière commande et la confiance. L’utilisateur ouvre le contexte Repricing, contrôle le prix et les coûts, puis revient au détecteur lors d’une mesure suivante.

Le suivi compare les cent vingt euros mémorisés au nouvel impact. Une baisse apparaît comme récupération observée, mais l’équipe vérifie toujours si elle vient du prix, du coût, du mix de ventes ou de la période avant de la présenter comme résultat.

22. Ce que le module rend immédiatement observable

Moins de dispersion, davantage de décisions reliées à leur contexte

Une offre sans écart ne surcharge plus la file active. Une absence de revenu reste visible comme problème de donnée au lieu de produire une marge artificielle.

Chaque cause correspond à une règle lisible. Impact, fréquence, récence et confiance expliquent le score ; les seuils de sévérité expliquent la priorité.

Le lien vers l’offre et le flux Buy Box raccourcit le passage du signal au contrôle. Le journal rappelle ensuite la dernière action et sa valeur de départ.

Le tableau de récupération donne un point de comparaison après l’action. Ces gains sont fonctionnels et vérifiables dans le module ; aucun gain de marge client chiffré n’est revendiqué sans mesure externe.

23. Les limites qui empêchent de survendre le détecteur

Une règle explicable reste une hypothèse à confirmer

Le moteur utilise commission, transport et achat agrégés. Il ne possède pas dans cette requête des postes autonomes de retour, remise, support ou coût indirect. Ces causes ne sont donc pas présentées comme détectées.

Une seule cause principale est conservée selon un ordre fixe. Plusieurs facteurs peuvent pourtant coexister sur une offre ; le détail financier doit être consulté avant décision.

Le potentiel à trente jours est un coefficient sur l’impact observé, sans modèle prédictif. Le suivi mesure une différence entre deux états sans groupe de contrôle ni attribution causale.

Les limites de deux mille agrégats puis cinq cents lignes imposent de filtrer les grands comptes pour garantir une lecture complète du sous-périmètre.

Le module ne publie aucun prix, ne désactive aucune offre et ne corrige aucun coût automatiquement. Il détecte, classe, ouvre le bon contexte et mémorise la décision.

24. Relier la fuite à ses preuves voisines sans confondre les rôles

Analyse de marge, détail d’offre et décision de prix se complètent

La marge par produit, marque, catégorie et tag fournit la lecture analytique des performances. Elle aide à comprendre si une situation dépasse une seule offre.

Le projet Offer Margin Detail descend dans les montants et les calculs d’une offre. Il prend le relais lorsque la cause principale doit être vérifiée poste par poste.

Le projet Buy Box et repricing encadre ensuite la décision tarifaire. Le détecteur lui transmet une offre à examiner ; il ne s’attribue pas la modification.

Ensemble, ces preuves soutiennent le pilotage de marge marketplace : calculer, repérer l’écart, comprendre les postes, préparer l’action puis mesurer une nouvelle situation.