Le projet en un coup d’œil
Une offre interne connaît un SKU et un stock. L’analyse externe exige aussi l’ASIN ou l’identifiant marketplace, le GTIN, la marque, la classification, les vendeurs présents et la Buy Box observée.
Ciama recherche le catalogue Amazon par mot-clé, conserve le fournisseur et l’identifiant, enrichit une fiche détaillée et rattache des fenêtres concurrentielles datées.
L’utilisateur retrouve la donnée normalisée et la réponse source, peut rafraîchir la fiche, parcourir l’historique des fenêtres et vérifier chaque vendeur avant toute analyse de prix.
Un produit présent sur Amazon ne se résume pas au SKU que le vendeur connaît dans son ERP. La marketplace lui attribue un identifiant, le rattache à un catalogue local, expose des images et une classification, puis réunit autour de lui plusieurs vendeurs dont l’un peut remporter la Buy Box. Sans objet dédié, ces informations finissent mélangées au PIM ou dispersées dans des réponses API difficiles à relire.
Dawap a développé dans Ciama un Product Explorer consacré à cette réalité externe. Une recherche par mot-clé interroge le catalogue Amazon du fournisseur choisi. Les résultats sont enregistrés par couple fournisseur-identifiant, puis présentés en cartes ou en tableau. La fiche d’un produit peut ensuite être enrichie avec son GTIN, sa marque, son fabricant, ses références et sa catégorie.
Le module va plus loin lorsque le produit possède une offre active en stock et que la collecte concurrentielle est autorisée pour la connexion. Il ouvre une fenêtre Buy Box, identifie les vendeurs observés, conserve les prix dans leur devise source et en euros lorsque la conversion est disponible, distingue Amazon FBA du vendeur, puis construit un historique. Cette réalisation donne à l’analyse concurrentielle marketplace un point d’entrée précis : partir d’un produit réellement identifié avant de comparer les vendeurs et les prix.
1. Ciama, un cockpit qui distingue le produit interne du produit marketplace
L’intelligence catalogue externe complète le PIM sans le remplacer
Ciama centralise des produits, des offres et des ventes pour des comptes vendeurs. Le PIM porte le référentiel interne ; l’offre relie ce référentiel à un canal commercial. Le Product Explorer ajoute un troisième regard : l’objet tel qu’il est publié et identifié par la marketplace.
Cet objet externe possède un fournisseur et un identifiant unique dans ce fournisseur. Il peut conserver un ASIN ou autre identifiant marketplace, un scope de catalogue, un ou plusieurs GTIN, un nom, une marque, un fabricant, une référence fabricant, un modèle, une catégorie, un thème de variation et des images.
Le même objet reçoit ensuite les dernières informations Buy Box : présence d’un gagnant, identifiant du vendeur, prix source, devise, montant converti, nombre de concurrents et date d’observation. Les réponses complètes du fournisseur restent accessibles dans deux charges JSON distinctes, l’une issue de la découverte et l’autre de la fiche.
Cette séparation rend le module complémentaire au catalogue PIM marketplace. Le premier décrit la réalité externe observée ; le second organise les données que le vendeur maîtrise et diffuse.
2. Faire progresser la connaissance du produit par couches
Découverte, fiche détaillée puis fenêtre concurrentielle
La première couche répond à une question simple : quels produits la marketplace retourne-t-elle pour cette recherche ? Le lecteur Amazon demande les résumés, images et identifiants, puis crée ou actualise les candidats reconnus.
La deuxième couche enrichit un candidat précis. Elle interroge la fiche détaillée seulement si la dernière observation date de plus de sept jours, extrait les champs catalogue disponibles et propage les nouvelles images aux offres déjà rattachées.
La troisième couche observe le marché à un instant donné. Elle vérifie l’éligibilité, collecte la fenêtre Buy Box, crée les vendeurs inconnus, mémorise les lignes de prix puis met à jour le résumé du produit et les offres concernées.
Cette progression évite d’exiger le coût maximal dès la recherche initiale. Une liste de candidats reste légère ; le détail et la concurrence sont collectés pour les produits qui justifient réellement l’analyse.
3. Créer un objet pour la réalité externe de la marketplace
Le produit exploré n’est ni la fiche PIM ni l’offre du vendeur
Mélanger la réponse catalogue Amazon avec le produit interne aurait rendu la provenance des champs ambiguë. Un nom, une image ou une catégorie observés sur la marketplace ne sont pas nécessairement ceux que le vendeur veut conserver dans son référentiel.
Le Product Explorer utilise donc une entité dédiée. Son unicité repose sur le fournisseur et l’identifiant externe. Deux catalogues peuvent partager une valeur textuelle sans fusionner leurs produits ; un même fournisseur ne peut pas créer deux objets pour le même identifiant.
L’objet garde le payload de découverte et la fiche détaillée en plus des champs normalisés. Le lecteur peut ainsi afficher rapidement les informations fréquentes tout en conservant la matière source utile pour comprendre un mapping.
Les offres peuvent se rattacher à cet objet sans perdre leur propre canal, leur stock et leur prix. Le produit externe devient un pivot d’observation, pas un remplacement du modèle commercial.
4. Interroger le catalogue Amazon par mot-clé
Une recherche externe produit au maximum vingt candidats par appel
Le lecteur Amazon Catalog Items reçoit l’identifiant du fournisseur, la requête et les informations d’accès. Il résout le scope marketplace, obtient un jeton puis appelle le catalogue avec le mot-clé.
La demande fixe une taille de page de vingt et réclame trois familles de données : résumés, images et identifiants. Chaque ligne doit posséder un ASIN ; une réponse sans cet identifiant est ignorée plutôt que transformée en produit impossible à retrouver.
Le nom provient du premier résumé lorsqu’il existe. Les images sont parcourues pour privilégier une grande image principale et une miniature ; une autre image exploitable sert de repli si la variante principale manque.
Le résultat conserve la réponse de l’item dans son payload. L’exploration ne se limite donc pas à quatre colonnes extraites : le contexte retourné reste disponible pour un contrôle ultérieur.
5. Garder un scope explicite pour chaque catalogue Amazon
Seize identifiants fournisseur sont associés à leur Marketplace ID
Le lecteur possède une table explicite de seize identifiants Amazon et de leurs Marketplace IDs. Elle couvre notamment la France, l’Espagne, l’Italie, l’Allemagne, le Royaume-Uni, la Belgique, les Pays-Bas, la Suède, la Pologne et d’autres scopes reconnus par l’intégration.
La présence du préfixe Amazon ne suffit pas à lancer l’appel. L’identifiant doit aussi exister dans cette table ; sinon, le traitement retourne une erreur de scope introuvable.
Cette double condition évite d’envoyer silencieusement une recherche française vers un catalogue voisin. Le produit conserve ensuite le fournisseur qui a servi sa découverte et, lorsque la fiche le fournit, son identifiant de scope.
La liste est une capacité technique, pas la promesse que tous les comptes utilisent les seize pays. Seuls les fournisseurs et connexions réellement configurés participent à une recherche.
6. Contrôler le compte, le fournisseur, le canal et les accès avant la recherche
Une requête vide ou une connexion invalide ne devient pas un résultat vide
Le service exige un compte, un identifiant fournisseur et un mot-clé non vide. Le fournisseur doit exister, appartenir au type marketplace, rester actif et disponible.
Ciama recherche ensuite un canal marketplace du compte pour ce fournisseur, puis sa connexion. La connexion doit être active et ses informations d’accès valides.
Les credentials JSON sont décodés avant l’appel. La clé API chiffrée, l’hôte, la base et l’utilisateur peuvent compléter les champs de connexion lorsque le fournisseur les utilise.
Un échec du lecteur est capturé avec un message propre à l’exploration. La différence reste visible entre « aucun candidat retourné » et « recherche impossible à exécuter ».
7. Ajouter ou actualiser le produit selon le couple fournisseur-identifiant
Une même recherche peut être rejouée sans dupliquer les candidats
Chaque candidat est compté, puis son identifiant externe est nettoyé. Une ligne sans identifiant est écartée avant toute écriture.
Ciama cherche un produit possédant le même fournisseur et le même identifiant. Si rien n’existe, le service distribue un message d’ajout ; sinon, il distribue un message de mise à jour.
Les deux messages transportent le compte, l’identifiant fournisseur, le candidat normalisé et le journal d’exécution éventuel. La lecture distante n’effectue pas toutes les écritures dans la même boucle synchrone.
La réponse distingue le nombre de candidats collectés, d’ajouts programmés et d’actualisations programmées. Une relance devient mesurable et idempotente à l’échelle de la clé fonctionnelle.
8. Retrouver les produits déjà découverts dans une vue dédiée
Fournisseur, identifiant, nom ou GTIN servent la recherche locale
L’index charge les produits les plus récemment actualisés, avec une limite comprise entre un et cinq cents et fixée à cent par le contrôleur. Un fournisseur peut restreindre la liste.
La requête textuelle porte sur l’identifiant externe, le nom et le GTIN. Elle sert à retrouver une référence déjà collectée ; le bouton de rafraîchissement déclenche séparément une nouvelle recherche distante.
La vue propose un affichage par cartes et un tableau. Les deux modes montrent le fournisseur, l’identifiant, le GTIN, la Buy Box connue, le nombre de concurrents disponible et la date de mise à jour.
Les contrôles visuels de prix, marque et catégorie sont présents dans l’interface. Dans son état actuel, la recherche locale applique réellement le fournisseur et le texte ; les autres contrôles ne sont donc pas présentés ici comme des filtres achevés.
9. Enrichir une fiche catalogue sans écraser la découverte
Amazon, Cdiscount et Fnac Darty possèdent un lecteur de fiche dédié
Le rafraîchissement de fiche part du produit externe et de son fournisseur. Trois adaptateurs sont disponibles pour le détail : Amazon, Cdiscount et Fnac Darty.
La réponse peut compléter l’identifiant marketplace, le scope, le nom, la marque, le fabricant, le GTIN, la référence fabricant, le modèle, la catégorie, le thème de variation et les images.
Les chaînes destinées aux colonnes classiques sont nettoyées puis bornées à 255 caractères ; les URL d’image sont bornées à 1 024. Une valeur vide devient une absence au lieu d’une chaîne blanche.
Après l’écriture de la fiche, les images principale et miniature sont propagées aux offres déjà rattachées à ce produit marketplace. L’enrichissement bénéficie ainsi aux écrans opérationnels sans recopier tout le payload.
10. Éviter de rappeler la fiche lorsqu’elle a moins de sept jours
La date d’observation sert de garde-fou aux appels détaillés
Avant de charger le fournisseur, le service lit la date de dernière observation de la fiche. Si elle est postérieure ou égale à la date courante moins sept jours, il termine sans écriture.
Ce délai empêche une série de clics ou de messages rejoués de rappeler inutilement une donnée catalogue fraîche. Il réduit aussi l’exposition aux quotas des sources externes.
Lorsque le délai est dépassé, la collecte repart depuis le canal marketplace du compte et ses informations d’accès. La fiche obtenue reçoit une nouvelle date d’observation indépendante de la date de découverte du produit.
Sept jours représentent la règle actuelle du module, pas une garantie contractuelle de fraîcheur. Une source indisponible peut laisser une observation plus ancienne jusqu’à la prochaine collecte réussie.
11. Conserver deux réponses source pour rendre le mapping relisible
Découverte et fiche détaillée ne racontent pas le même appel
Le payload de découverte contient l’item renvoyé pendant la recherche. La fiche JSON contient la réponse du lecteur détaillé. Les deux sont stockés séparément avec leurs champs normalisés.
L’écran de détail affiche ces charges au format JSON. Un identifiant, une marque ou une image peut ainsi être rapproché de sa source lorsqu’une donnée normalisée surprend.
Cette visibilité est particulièrement utile quand les structures diffèrent. Amazon peut exposer des résumés et des attributs imbriqués ; les autres connecteurs utilisent leurs propres contrats.
La réponse brute reste une preuve technique, pas une donnée directement actionnable. L’interface place d’abord l’identité, le catalogue et le suivi ; le JSON arrive en dernier pour le diagnostic.
12. Vérifier cinq conditions avant d’ouvrir une fenêtre Buy Box
Produit, fournisseur, support, offre active et fonction autorisée
La collecte concurrentielle commence par retrouver le produit et son fournisseur. Le fournisseur doit être de type marketplace, actif et disponible.
Le dispatcher vérifie ensuite qu’un adaptateur Buy Box prend en charge cet identifiant. Dans l’état actuel du module, le lecteur disponible couvre les identifiants Amazon configurés.
Le compte doit posséder au moins une offre marketplace active et en stock liée à ce produit et à ce fournisseur. Observer la concurrence d’un produit qui n’est pas réellement vendable par le compte est ainsi écarté.
Enfin, une connexion active et valide doit avoir la fonction de synchronisation des fenêtres Buy Box explicitement activée. Depuis le 10 août 2026, cette autorisation s’applique aux déclenchements manuels comme planifiés.
13. Photographier la Buy Box comme une fenêtre datée
Un gagnant et plusieurs lignes vendeurs partagent le même instant d’observation
Le lecteur ouvre une fenêtre à la date courante, résout l’ASIN puis demande les offres compétitives. La fenêtre porte une date d’ouverture, une éventuelle date de fermeture, le vendeur gagnant, son prix, sa devise et le nombre de lignes observées.
Chaque ligne rattache un vendeur, un prix, une devise, l’indicateur Buy Box, la présence de la marketplace elle-même et le mode d’expédition Amazon ou vendeur.
Un identifiant vendeur vide est ignoré. Un vendeur inconnu est créé une seule fois pour le fournisseur, puis réutilisé dans toutes les lignes de la fenêtre.
Le nombre de concurrents du résumé est calculé comme le nombre de lignes moins une, avec un minimum de zéro. L’écran conserve aussi le nombre brut de lignes afin de ne pas masquer la règle.
14. Construire un référentiel vendeur à partir des observations
L’identité concurrentielle est unique dans son fournisseur
Les lignes de fenêtre arrivent avec un identifiant vendeur externe. Le service cherche d’abord cet identifiant dans le fournisseur concerné et crée un vendeur seulement lorsqu’il manque.
Le gagnant suit la même règle, y compris lorsqu’il n’apparaît pas encore dans la collection préparée. La fenêtre pointe alors vers l’entité vendeur plutôt que conserver uniquement une chaîne.
La fiche affiche le nom connu, l’identifiant, le prix original, le prix converti, le statut Buy Box, le fulfilment et la date d’observation pour chacune des dix fenêtres récentes détaillées.
Cette construction alimente la base de vendeurs concurrents, qui constitue une preuve distincte consacrée à leur identité et à leur historique.
15. Conserver le prix source et préparer une comparaison en euros
La date de la fenêtre fixe le contexte de conversion
Le prix gagnant et chaque prix vendeur gardent leur montant et leur devise source. Le service normalise l’identifiant de devise avant de chercher le référentiel Ciama.
Lorsque la conversion est possible, le montant est converti en euros à la date d’ouverture de la fenêtre. La devise convertie est enregistrée séparément de la devise source.
L’écran utilise la même logique de normalisation pour afficher les historiques. Un ancien montant converti sert de repli seulement avec sa devise connue ; une absence ne devient pas arbitrairement un prix en euros.
Cette distinction est indispensable avant toute lecture de concurrence multi-pays. Elle ne constitue toutefois pas un moteur de repricing : la fenêtre observe et historise, elle ne choisit pas un nouveau prix de vente.
16. Passer de la dernière Buy Box à une trajectoire
Prix gagnant, volume de vendeurs et absence de gagnant deviennent datés
La fiche charge tout l’historique des fenêtres pour construire deux séries : prix gagnant et nombre de lignes concurrentes. Elle conserve aussi, pour chaque point, la présence ou l’absence d’un gagnant.
Le résumé affiche le nombre de fenêtres, la première et la dernière observation et la devise de lecture. Une absence de donnée produit un état vide explicite plutôt qu’un graphique plat.
Les dix fenêtres les plus récentes sont ensuite détaillées dans un sélecteur vertical. Chaque onglet restitue le gagnant, les dates, le nombre de lignes et le tableau des vendeurs observés.
Une tâche de production parcourt chaque nuit à 1 h 30 les cibles éligibles en stock. Les produits peuvent aussi être collectés à la demande depuis leur fiche, avec le même contrôle d’éligibilité.
17. Reporter la dernière observation Buy Box sur les offres du compte
Le vendeur gagnant est rapproché de l’identifiant externe de son canal
Après l’écriture de la fenêtre, Ciama remet d’abord à faux l’indicateur Buy Box des offres rattachées au produit. Il constitue ensuite une table des vendeurs observés à partir de leurs identifiants externes.
Les canaux du fournisseur dont l’identifiant de compte externe correspond à un vendeur observé sont retrouvés. Seuls ces canaux reçoivent l’état Buy Box de leur ligne.
Le rapprochement est insensible à la casse après nettoyage. Une ligne sans vendeur ou un canal sans identifiant de compte externe ne produit aucun mapping implicite.
La date d’observation accompagne la mise à jour. L’offre peut donc montrer l’état issu de la dernière fenêtre sans confondre ce signal avec son prix, son stock ou sa marge.
18. Tester chaque service d’écriture et les refus les plus importants
L’explorateur possède une couverture unitaire et d’intégration dédiée
Huit suites unitaires couvrent l’ajout, la mise à jour, la collecte par fournisseur, la collecte tous fournisseurs, la fiche, la demande de fenêtre, la collecte Buy Box et le fait quotidien.
Les cas refusés incluent le compte absent, la requête vide, le fournisseur inconnu ou inactif, le mauvais type, le canal manquant, les credentials invalides, le produit absent et le lecteur en erreur.
La fraîcheur de sept jours possède un test qui interdit tout appel et toute écriture lorsque la fiche est récente. Les mises à jour d’images sur les offres sont contrôlées lors d’un enrichissement réussi.
Les tests d’éligibilité ajoutés en août vérifient le fournisseur non supporté, l’absence d’offre active en stock, la fonction désactivée et le contexte complet. Deux suites d’intégration parcourent enfin le cycle de découverte, de fiche et de fenêtre.
19. Faire évoluer le module de la découverte au contrôle d’éligibilité
Mars construit le cœur ; avril affine les interfaces ; août verrouille l’exploitation
Le 8 mars 2026, Ciama reçoit l’objet produit marketplace, sa recherche Amazon, les messages d’ajout et de mise à jour, l’index en cartes et tableau et la première fiche détaillée.
Le même jour, une seconde étape ajoute les vendeurs, les fenêtres Buy Box, leurs lignes et les collectes asynchrones. L’affichage et le mapping Amazon sont affinés dans un troisième jalon.
Le 16 mars, les services d’écriture gagnent une couverture unitaire complète. Le 26 avril, le GTIN apparaît correctement dans l’explorateur et les routes d’index, de fiche, de rafraîchissement catalogue et de collecte Buy Box sont séparées.
Le 10 août, l’éligibilité devient une règle commune : support du fournisseur, offre active en stock et fonction activée sur la connexion. Cette date correspond à l’état publié du projet.
20. Ce qui change avec le Product Explorer
La connaissance externe d’une référence reste accessible et datée
Une recherche Amazon produit des candidats identifiés, illustrés et persistants. Le vendeur peut revenir sur la même référence sans recommencer depuis une réponse API éphémère.
La fiche réunit l’identité marketplace et les attributs catalogue fréquents, tout en laissant les deux payloads source accessibles. Un mapping peut être contrôlé sans réduire le produit à une capture ou à une valeur copiée.
La fraîcheur borne les appels détaillés. Les images enrichies rejoignent les offres liées, ce qui évite de conserver une amélioration seulement dans l’écran d’exploration.
Les fenêtres Buy Box transforment un résultat instantané en historique. Le gagnant, les vendeurs, les prix, la devise, le fulfilment et l’heure d’observation restent liés au même relevé.
Enfin, le contrôle d’éligibilité réserve la collecte récurrente aux produits réellement vendus, en stock, supportés techniquement et autorisés sur la connexion. Le volume d’observation suit ainsi un périmètre commercial explicite.
21. Le parcours d’un produit depuis le mot-clé jusqu’à sa fenêtre concurrentielle
Découvrir, enrichir, vérifier l’éligibilité puis observer
Un utilisateur choisit Amazon France et saisit un mot-clé. Ciama valide son compte, le fournisseur, le canal et la connexion, puis demande au catalogue jusqu’à vingt candidats avec leurs résumés, images et identifiants.
L’ASIN recherché n’existe pas encore pour ce fournisseur : un message d’ajout est distribué. Au retour dans l’index, la carte montre son image, son nom, son identifiant et son GTIN disponible ; la fiche ouvre le payload exact de la découverte.
L’utilisateur demande ensuite le détail catalogue. Si aucune fiche n’a été observée depuis sept jours, le lecteur complète marque, fabricant, référence, modèle, catégorie, variation et images. Les offres déjà rattachées reçoivent les images mises à jour.
Le produit possède une offre Amazon active et en stock, et la fonction Buy Box est autorisée. La demande est mise en file, puis une fenêtre crée les vendeurs inconnus et mémorise chaque ligne avec son prix source, sa conversion disponible, son fulfilment et son indicateur Buy Box.
Lors d’une visite suivante, la fiche montre la trajectoire du prix gagnant, le nombre de lignes par fenêtre et le détail des dix observations récentes. L’analyse part d’objets datés et identifiés, pas d’une impression isolée.
22. Les limites qui gardent l’exploration exacte
Observer le catalogue et la Buy Box ne suffit pas à décider un prix
La recherche de produits possède aujourd’hui un adaptateur Amazon. Les lecteurs de fiche couvrent aussi Cdiscount et Fnac Darty, mais cette différence de couverture reste explicite ; tous les fournisseurs affichés dans le cockpit ne promettent pas la même profondeur.
L’appel Amazon demande vingt candidats et ne parcourt pas ici une pagination complète du catalogue. Le Product Explorer sert une investigation ciblée, pas un export exhaustif de millions de références.
Une fenêtre Buy Box dépend de la réponse externe, de la connexion, d’une offre active en stock et de la fonction activée. Une absence d’observation n’est pas la preuve qu’aucun concurrent n’existe.
Le nombre de concurrents est dérivé des lignes reçues moins une. Il décrit la fenêtre collectée, pas l’ensemble garanti des vendeurs présents à tout instant.
Enfin, le module n’intègre pas à lui seul la marge, le stock multi-entrepôts ou une règle de repricing. Ces données et décisions appartiennent à d’autres briques qui peuvent utiliser l’identité et les observations produites ici.
23. Relier l’exploration aux autres preuves marketplace
Identité produit, vendeurs, offres et décision de prix gardent chacun leur rôle
La fiche sur la consolidation des fiches produit marketplace approfondit la différence entre le PIM et la donnée externe collectée chez Amazon, Cdiscount, Fnac Darty ou Mirakl.
La base des vendeurs concurrents prend le relais lorsque l’analyse porte sur l’identité d’un vendeur à travers plusieurs fenêtres.
La vue produit croisant offres et stocks par canal reconnecte le produit marketplace aux objets du vendeur. Elle répond à la question « où sommes-nous présents ? », tandis que l’explorateur répond à « que montre la marketplace ? ».
Le projet Buy Box et repricing couvre ensuite la décision de prix et ses garde-fous. Le Product Explorer fournit une observation datée ; il ne transforme pas seul cette observation en action tarifaire.
24. Conclusion
Avant d’arbitrer un produit, il faut pouvoir revenir à son identité et à l’observation exacte
Le Product Explorer donne à Ciama un objet dédié à la réalité des catalogues marketplace. La recherche Amazon découvre les candidats ; la fiche enrichie organise leur identité ; les payloads conservent la source ; les fenêtres datées montrent vendeurs, prix, Buy Box et fulfilment.
La réalisation est volontairement progressive. Vingt candidats suffisent à une recherche ciblée, sept jours protègent les appels de fiche, dix fenêtres récentes restent détaillées et la collecte concurrentielle est réservée aux offres actives en stock dont la connexion autorise cette fonction.
Cette précision renforce l’analyse concurrentielle marketplace : ne pas confondre le produit interne, l’offre du vendeur et l’objet de la marketplace, puis dater chaque observation avant de chercher une cause ou de préparer une décision.
