Ciama : identifier les vendeurs qui disputent la Buy Box Amazon

1. Ciama, le cockpit vendeur développé par Dawap

Relier la performance d’une offre à la concurrence qui l’entoure

Ciama Marketplace centralise les offres, commandes, produits, stocks et indicateurs dont une équipe vendeur a besoin pour exploiter plusieurs canaux. Son rôle n’est pas seulement d’aligner des lignes de données : il doit préserver le contexte qui explique pourquoi une offre gagne, perd ou mérite une action.

Sur Amazon, plusieurs vendeurs peuvent proposer le même produit. La fiche produit concentre alors une compétition que le seul prix local ne décrit pas. La Buy Box désigne un gagnant au moment de l’observation ; le nombre de concurrents, le prix gagnant et le fulfilment éclairent la situation sans pour autant dicter une réponse automatique.

Le besoin produit était donc précis : donner aux équipes une vue concurrentielle depuis les références qu’elles exploitent déjà dans Ciama. Le projet devait fonctionner sans constituer une base commerciale parallèle ni inventer des attributs qu’Amazon ne renvoie pas. L’identité technique du vendeur devient le point d’ancrage ; les fenêtres Buy Box apportent le contexte et le temps.

2. Construire une mémoire concurrentielle à partir de faits bornés

Identifier, observer, normaliser puis relier à l’offre du vendeur

Le premier parcours, livré le 8 mars 2026, a posé le modèle de données, la collecte Amazon Europe et la consultation des fenêtres depuis le Product Explorer. Une observation pouvait dès lors créer les vendeurs inconnus, enregistrer le gagnant et conserver une ligne par offre concurrente.

Le 14 mars, la collecte est devenue exploitable au quotidien : mise en file des produits à observer, exécution planifiée en production et intégration au BuyBox Tracker. Les faits journaliers permettent de suivre la couverture globale tandis que les fenêtres conservent le détail utile au diagnostic d’un produit.

Le dispositif a ensuite été resserré autour de la réalité opérationnelle. La production effectue aujourd’hui un passage quotidien, uniquement pour les offres marketplace actives dont le stock est strictement positif. Chaque connexion fournisseur active explicitement la collecte Buy Box ; un changement de stock ou de configuration est revérifié avant l’appel externe.

3. Avant le projet : la Buy Box réduite à un état

Gagnée, perdue ou inconnue, sans toujours pouvoir expliquer pourquoi

L’offre locale pouvait indiquer si elle détenait la Buy Box. Cette information répondait à une première question, mais elle laissait le reste de la scène hors champ. Une perte pouvait venir d’un concurrent moins cher, d’un avantage logistique ou simplement d’une observation devenue ancienne. Ces situations n’appellent pas la même réponse.

Le vendeur devait alors quitter son cockpit, retrouver la fiche Amazon concernée et observer manuellement les offres visibles. Cette vérification ponctuelle ne devenait pas une donnée Ciama. À la prochaine analyse, il fallait recommencer, sans savoir si le même vendeur était déjà gagnant la veille ni si l’écart de prix s’était resserré.

Une base générique de noms de vendeurs n’aurait pas résolu le problème. Le sens vient de la relation entre quatre éléments : un produit, un instant, les offres concurrentes et le gagnant désigné. Sorti de cette fenêtre, un identifiant vendeur n’explique ni la pression commerciale ni le résultat Buy Box.

Le projet a donc été pensé depuis la décision à prendre. Avant d’envisager un ajustement, l’équipe devait pouvoir ouvrir la situation concurrentielle exacte, comparer les valeurs dans une devise commune et replacer ce constat dans une suite d’observations.

4. Transformer un statut en diagnostic concurrentiel

Montrer qui est présent, qui gagne et à quelles conditions observées

L’objectif central était de conserver la composition d’une compétition Buy Box au lieu de sauvegarder uniquement son résultat. Pour chaque produit éligible, Ciama devait demander les offres Amazon, reconnaître les vendeurs, enregistrer leurs prix et marquer celle que le canal désigne comme gagnante.

Cette photographie devait rester consultable après la collecte suivante. Une fenêtre possède donc son heure d’ouverture et peut porter une heure de fermeture lorsque la source la fournit. Les lignes concurrentes appartiennent à cette fenêtre ; elles ne remplacent pas celles d’une observation antérieure.

Le deuxième objectif concernait l’offre du client. Si son identifiant vendeur apparaît dans la fenêtre, Ciama peut mettre à jour son état Buy Box avec le résultat réellement observé. Le suivi concurrentiel ne reste donc pas isolé dans une table d’analyse : il corrige aussi le signal opérationnel affiché sur les offres concernées.

Enfin, les observations détaillées devaient alimenter une lecture agrégée. Une équipe peut examiner une référence particulière et, dans le même espace, suivre la part d’offres avec Buy Box, sans Buy Box ou encore inconnues. Le détail explique ; l’agrégat oriente la priorité.

5. Assumer un périmètre Amazon Europe explicite

Ne jamais confondre une architecture extensible avec une couverture universelle

Le collecteur livré prend en charge neuf identifiants de marketplace Amazon : France, Espagne, Italie, Allemagne, Royaume-Uni, Belgique, Pays-Bas, Pologne et Suède. Chaque canal est relié à son identifiant SP-API exact afin d’interroger le bon marché et de ne pas mélanger des offres de pays différents.

Un produit peut être connu par son ASIN ou par un EAN à treize chiffres. Dans le second cas, Ciama tente d’abord de résoudre l’ASIN dans le catalogue Amazon du pays concerné, puis interroge les offres neuves attachées à cette référence. Si la résolution n’aboutit pas, le flux conserve un comportement contrôlé au lieu d’inventer une correspondance.

Le registre de connecteurs refuse les fournisseurs qu’il ne sait pas lire. Une connexion active à une autre marketplace ne suffit donc pas à produire une fausse fenêtre vide. Cette distinction est essentielle : « aucune offre observée » et « source non prise en charge » ne racontent pas la même réalité.

Le modèle interne reste compatible avec plusieurs fournisseurs, mais la preuve opérationnelle de ce projet est Amazon Europe. Présenter cette limite clairement rend le dispositif plus crédible et donne une règle simple pour l’étendre : un nouveau connecteur devra restituer les mêmes faits, avec la même qualité d’erreur et de traçabilité.

6. Donner une identité stable à chaque vendeur observé

Dédupliquer sans fabriquer un profil commercial

Amazon renvoie un identifiant externe pour chaque vendeur présent dans la fenêtre. Ciama le recherche avec le fournisseur concerné. S’il existe déjà, la nouvelle observation réutilise la même identité ; sinon, une fiche vendeur minimale est créée. La contrainte fournisseur plus identifiant externe évite de multiplier le même acteur à chaque passage.

L’identité vendeur peut accueillir un nom, un pays ou les métadonnées disponibles, mais le collecteur Buy Box ne les suppose pas. Lorsque la source ne fournit qu’un identifiant, Ciama conserve seulement cet identifiant. Une donnée absente reste absente : elle n’est ni déduite d’un libellé ni complétée artificiellement.

Le résultat est un référentiel d’identité, pas un CRM de la concurrence. Il sait dire qu’un même vendeur a été vu dans plusieurs fenêtres du même fournisseur. Il ne prétend pas connaître son chiffre d’affaires, l’ensemble de son assortiment, son stock global ou ses ambitions par catégorie.

Cette sobriété rend les rapprochements solides. Au lieu de bâtir des profils fragiles à partir d’indices, Ciama rattache chaque fait à la clé renvoyée par la marketplace. Les analyses futures peuvent enrichir ce socle, mais la donnée d’origine et son niveau de connaissance restent lisibles.

7. Conserver toute la fenêtre, pas seulement le gagnant

Une ligne par vendeur et un contexte commun pour l’observation

Chaque collecte crée une fenêtre liée au produit marketplace et au fournisseur. Elle conserve le vendeur gagnant, son prix source, sa devise, le nombre de lignes observées et l’instant de la photographie. Cette entête donne le résultat général sans perdre le détail qui l’explique.

Une ligne est ensuite enregistrée pour chaque vendeur exploitable. Elle porte son prix, sa devise, le signal Buy Box, le mode expédié par Amazon lorsqu’il est fourni et l’heure d’observation. La réponse d’origine peut aussi être conservée pour permettre un diagnostic plus fin si le format externe évolue.

Le nombre de concurrents affiché sur le produit est calculé à partir des offres de la fenêtre, en retirant la position gagnante. Ce repère aide à distinguer une confrontation directe d’un marché plus dense. Il décrit l’observation courante ; il ne devient pas une estimation du marché total.

La fenêtre fournit ainsi une unité de sens. Comparer deux prix provenant de collectes différentes sans leur date conduirait à un diagnostic trompeur. En gardant ensemble vendeurs, prix, statut et instant, Ciama permet de lire chaque compétition telle qu’elle a réellement été observée.

8. Comparer les prix sans effacer leur devise d’origine

Préserver la preuve source et produire une lecture commune en euros

Le prix gagnant et chaque prix concurrent sont enregistrés dans la devise renvoyée par Amazon. Cette valeur source reste attachée à sa monnaie ; un montant britannique n’est donc pas présenté comme un montant français simplement parce que le cockpit consolide plusieurs pays.

Ciama calcule en parallèle un montant converti en euros à la date de la fenêtre. Les taux du référentiel permettent d’obtenir une lecture comparable pour les analyses transverses, tout en gardant la possibilité de revenir au prix que la marketplace a réellement communiqué.

Si la devise ne peut pas être résolue, le flux n’enregistre pas silencieusement une conversion arbitraire. La ligne concernée est écartée ou le résultat expose l’erreur selon l’endroit où l’information manque. Cette prudence évite qu’une facilité d’affichage devienne une donnée commerciale fausse.

Le double stockage sert un diagnostic concret : l’utilisateur voit le prix gagnant dans une base commune, puis peut consulter le montant source. Il dispose du contexte nécessaire pour préparer une décision de prix sans confondre conversion analytique et prix réellement publié sur le canal.

9. Relier la concurrence aux offres que l’équipe exploite déjà

Mettre à jour le signal Buy Box sans créer un silo d’analyse

Après l’enregistrement de la fenêtre, Ciama retrouve les offres locales du même compte, du même fournisseur et du même produit marketplace. Il compare leur identifiant vendeur aux lignes collectées. Une correspondance permet de savoir directement si l’offre du client est celle qu’Amazon a désignée gagnante.

L’état Buy Box de l’offre est alors mis à jour avec la valeur observée et sa date. Cette synchronisation évite qu’un écran montre un gagnant concurrent tandis qu’un autre conserve un ancien statut. Le fait détaillé et le signal opérationnel proviennent du même passage.

Ciama ajoute également un point quotidien pour les offres concernées. Cette granularité quotidienne limite l’accumulation de doublons dans les indicateurs de tendance, tandis que les fenêtres conservent la scène concurrentielle plus détaillée. Les deux niveaux répondent à des questions différentes.

Le projet renforce ainsi le pilotage Buy Box et repricing marketplace. L’analyse décrit ce qui se passe ; la configuration de repricing, séparée, encadre ce que le vendeur accepte éventuellement de changer.

10. Passer de photographies isolées à une mémoire exploitable

Détailler une fenêtre et suivre la couverture au fil des jours

Une nouvelle observation ne met pas à jour l’ancienne fenêtre. Elle en crée une autre, avec son gagnant et ses lignes. Cette approche préserve les changements de concurrence : apparition d’un vendeur, variation du prix gagnant, évolution du nombre de propositions ou bascule du mode de fulfilment.

En parallèle, Ciama calcule des faits Buy Box journaliers à l’échelle du compte. Le cockpit représente le nombre d’offres avec Buy Box, sans Buy Box ou encore inconnues sur les quinze derniers jours. Un indicateur instantané complète cette courbe pour lire la situation actuelle.

L’historique ne prétend pas expliquer automatiquement la cause d’une variation. Il fournit la matière qui permet de la qualifier : le détenteur observé, son prix, les autres vendeurs et la date. Une équipe peut alors confronter ce signal à sa marge, son stock ou ses règles commerciales.

Cette séparation entre observation et interprétation protège la décision. Ciama ne transforme pas toute baisse concurrente en ordre de repricing. Il rend la pression visible et documentée, puis laisse les contraintes du vendeur déterminer si une action est pertinente.

11. Collecter assez pour décider, sans appeler Amazon sans limite

Un passage quotidien sur un périmètre réévalué avant chaque demande

La collecte de production s’exécute une fois par jour. Elle cible les offres marketplace actives, rattachées à un produit, à un canal, à un fournisseur et à un compte actifs. Le stock doit être strictement positif : une référence inactive ou indisponible ne consomme pas le même effort de surveillance.

La connexion au fournisseur doit être valide et porter explicitement la fonctionnalité de synchronisation Buy Box. L’absence de cette activation vaut désactivation. Chaque installation on-premise peut ainsi contrôler les appels réalisés avec ses accès au lieu de subir une collecte implicite.

L’éligibilité n’est pas vérifiée seulement lors de la sélection initiale. Elle l’est encore au moment où le traitement consomme la demande. Si une offre passe hors stock, si un fournisseur est désactivé ou si la fonctionnalité est retirée entre les deux étapes, l’appel Amazon n’est pas exécuté.

Un ancien parcours de dispatch ciblé reste disponible pour une exécution explicite, mais il n’alimente plus artificiellement la file chaque heure en production. Ce réglage, consolidé après la livraison initiale, aligne la cadence sur la valeur réelle de l’observation et sur les contraintes de l’API.

12. Rendre la concurrence lisible au même endroit que l’offre

Tableau de pilotage, filtres, prix gagnant et détail des vendeurs

Le BuyBox Tracker présente les offres actives en stock. L’équipe peut rechercher une référence puis filtrer par canal, mode de fulfilment, marque, catégorie, tag ou état Buy Box. Ce périmètre replace la concurrence dans les axes de travail déjà utilisés pour piloter le catalogue.

Chaque ligne rapproche le prix de l’offre, son état Buy Box, le prix gagnant converti et le nombre de vendeurs observés. Un accès au détail ouvre la dernière fenêtre : vendeur, prix source, prix converti, statut gagnant et fulfilment deviennent lisibles sans quitter le cockpit.

Une actualisation peut être demandée pour une offre ou pour l’ensemble du périmètre filtré. Le bouton ne contourne pas les règles d’éligibilité : il passe par le même service de collecte et signale les demandes effectivement acceptées. L’interface reste une commande métier, pas un appel direct incontrôlé à l’API.

Deux graphiques complètent le tableau. Le premier suit la couverture Buy Box quotidienne ; le second répartit la situation instantanée entre gagnée, perdue et inconnue. Le responsable peut d’abord repérer une dégradation globale, puis descendre jusqu’aux vendeurs présents sur une référence précise.

13. Les arbitrages qui rendent la donnée défendable

Préférer une vérité bornée à une intelligence marché surpromue

Le premier arbitrage a été de séparer identité vendeur et profil vendeur. L’identifiant externe suffit pour rattacher les observations. Un nom ou un pays n’est enregistré que s’il existe réellement. Cette règle empêche une simple clé technique d’être présentée comme une connaissance exhaustive du concurrent.

Le deuxième a été de conserver toutes les lignes de la fenêtre, même lorsque le besoin immédiat concerne le gagnant. Sans les autres offres, le nombre de vendeurs, l’écart de prix et la densité concurrentielle disparaîtraient. La donnée serait plus légère, mais beaucoup moins utile au diagnostic.

Le troisième a été de découpler la collecte du repricing. Voir un concurrent moins cher n’autorise pas, à lui seul, une baisse. Les bornes de marge, le mode manuel ou automatique et la demande de changement de prix appartiennent à un autre parcours, visible et configurable.

Enfin, la couverture a été déclarée fournisseur par fournisseur. Le modèle peut accueillir d’autres marketplaces, mais un canal non implémenté échoue explicitement. Cette franchise évite le défaut le plus dangereux d’un cockpit multi-marketplaces : donner l’impression que toutes les colonnes ont partout la même fraîcheur et la même source.

14. Sécuriser une collecte dépendante d’une API externe

Contrôles d’éligibilité, erreurs maîtrisées et gestion du débit Amazon

Le parcours refuse les demandes sans compte ou sans produit, les produits rattachés à un autre compte, les fournisseurs inactifs, les canaux indisponibles et les connexions qui n’ont pas activé la fonctionnalité. Il vérifie aussi qu’une offre active en stock justifie encore la collecte au moment de l’exécution.

Amazon impose des limites de débit. Le connecteur reconnaît les réponses de limitation, tient compte des indications de délai et augmente progressivement l’attente, avec une borne maximale et un nombre fini de tentatives. Une saturation persistante remonte comme un échec identifiable au lieu de disparaître derrière une fenêtre vide.

Si un incident intervient après épuisement des tentatives, le traitement le conserve comme erreur. Pour d’autres indisponibilités ponctuelles, le connecteur peut restituer le dernier gagnant déjà connu afin de maintenir une réponse bornée. Cette solution de repli ne crée pas de nouveaux vendeurs imaginaires et garde le contexte du produit.

Les contrôles automatisés couvrent le cœur du domaine, l’éligibilité, la persistance, les commandes planifiées, les réponses Amazon et les parcours du back-office. La qualité ne repose donc pas sur le seul affichage final : elle vérifie la frontière du compte, la source, la conversion et les effets sur l’offre.

15. Livrer le socle, puis durcir son exploitation réelle

Du premier détail produit à une collecte quotidienne gouvernée

Le 8 mars 2026 marque la livraison du socle : entités vendeurs et fenêtres, connecteur Amazon Europe, collecte métier, persistance et consultation depuis le Product Explorer. Cette première tranche a validé le modèle essentiel : un vendeur stable peut être relié à plusieurs observations sans perdre le détail de chaque compétition.

Le 14 mars, Dawap a ajouté la mise en file quotidienne, l’exécution en production et l’intégration au BuyBox Tracker. La fonctionnalité est alors passée d’une consultation ponctuelle sur un produit à un outil de suivi pour les offres exploitées par le vendeur.

En juin, la cadence de production a été ramenée à un passage quotidien pour maîtriser la charge et ne pas entretenir une file plus rapide que le besoin métier. En août, les critères ont été durcis : uniquement les offres actives en stock et uniquement les connexions ayant activé la collecte.

Ces évolutions ne changent pas la promesse initiale ; elles la rendent soutenable. Un projet de données externes ne s’arrête pas lorsque la première réponse apparaît à l’écran. Sa valeur dépend aussi de la sélection, de la fréquence, des limites fournisseur et de la capacité à désactiver proprement un flux.

16. Ce que l’équipe gagne dans son pilotage quotidien

Moins de suppositions, plus de contexte avant une action prix

Une perte de Buy Box n’est plus seulement un badge. Le responsable voit le vendeur gagnant, son prix, le nombre d’acteurs observés et, lorsque l’information existe, si le gagnant est expédié par Amazon. Il peut qualifier la pression avant de toucher à son offre.

La consultation reste dans le périmètre de travail Ciama. Les filtres par canal, marque, catégorie ou tag permettent d’ordonner les vérifications selon l’enjeu commercial. Le détail par produit évite de confondre une dégradation générale avec quelques références très disputées.

L’historique apporte une continuité. Lorsque le même identifiant vendeur réapparaît, Ciama le rattache à la même identité. Les fenêtres successives permettent de retrouver les observations sans transformer cette répétition en affirmation hasardeuse sur la stratégie globale du concurrent.

Enfin, le repricing dispose d’un signal mieux qualifié. Le prix gagnant converti peut éclairer une configuration ou une action manuelle, mais les bornes restent indépendantes. L’équipe gagne donc en vitesse de compréhension sans abandonner la maîtrise de sa marge à un indicateur isolé.

17. Le scénario qui fait passer du voyant au diagnostic

Une offre Amazon France perd la Buy Box pendant qu’elle reste en stock

Une responsable ouvre le BuyBox Tracker et filtre les offres Amazon France sans Buy Box. Une référence à fort volume apparaît avec trois vendeurs observés. Son prix local est visible à côté du prix gagnant converti ; l’écart justifie une vérification, mais pas encore une baisse automatique.

Elle ouvre le détail de la dernière fenêtre. Le gagnant possède un identifiant vendeur précis, son offre est marquée Buy Box et Amazon indique un fulfilment FBA. Deux autres vendeurs complètent la scène. L’équipe sait désormais que la compétition ne se résume pas à un seul montant affiché sur la fiche produit.

Avant d’agir, elle consulte les observations précédentes. Le gagnant actuel était déjà présent, mais n’occupait pas nécessairement la même position lors du passage antérieur. Ce fait n’explique pas à lui seul l’algorithme Amazon ; il suffit cependant à écarter l’hypothèse d’une simple donnée locale périmée.

La responsable peut alors utiliser le module Buy Box et repricing avec le bon contexte : maintenir le prix, préparer une valeur manuelle ou appliquer une stratégie encadrée par des bornes. La collecte informe l’arbitrage ; elle ne le remplace pas.

18. Ce que cette preuve ne prétend pas faire

Protéger la confiance en nommant les frontières du projet

La base ne suit pas tous les vendeurs d’Amazon indépendamment des produits du client. Elle se construit au fil des fenêtres collectées pour les offres éligibles. Un acteur absent de ces observations ne peut pas être considéré comme absent du marché au sens large.

Elle ne reconstruit pas non plus la profondeur de catalogue d’un concurrent, sa présence par catégorie, ses ruptures globales ou sa trajectoire de chiffre d’affaires. Ces affirmations demanderaient d’autres sources et un autre dispositif. Le projet reste centré sur la concurrence visible dans une fenêtre Buy Box.

Le prix gagnant observé n’explique pas toutes les règles Amazon. Le fulfilment ajoute un contexte utile, mais la Buy Box dépend de facteurs que la réponse collectée ne transforme pas en causalité certaine. Ciama expose les faits disponibles sans présenter une corrélation comme une recette garantie.

Enfin, une fréquence quotidienne n’est pas une surveillance temps réel. Elle correspond au compromis de production retenu pour les offres actives en stock. Une actualisation ciblée peut compléter ce rythme lorsque l’équipe travaille sur une référence, mais aucune fiche ne doit promettre une vision permanente seconde par seconde.

19. Relier concurrence, produit et décision prix

Trois briques distinctes qui construisent un même parcours vendeur

Le Product Explorer marketplace porte le produit externe et permet de consulter ses informations collectées. La base vendeurs et les fenêtres Buy Box lui ajoutent la scène concurrentielle observée autour de cette référence.

Le BuyBox Tracker rapproche ensuite cette scène des offres du vendeur, de leur statut et de leurs filtres métier. Le projet de repricing marketplace intervient seulement après, avec des modes et des bornes dédiés à la décision de prix.

Dans Ciama Marketplace, ces briques forment une progression lisible : identifier le produit, observer les vendeurs, comprendre la Buy Box, puis décider. Aucune étape n’a besoin de se faire passer pour la suivante.

Pour une équipe qui veut structurer son analyse concurrentielle marketplace, c’est cette continuité qui compte : une source clairement bornée, un historique fidèle et une action commerciale qui reste gouvernée par les objectifs du vendeur.