Ciama : consolider les fiches produit des marketplaces sans les confondre avec le PIM

1. Ciama, un cockpit vendeur qui doit parler le langage de chaque canal

Conserver une vue commune sans prétendre que les marketplaces sont identiques

Ciama Marketplace réunit des produits externes, des offres vendeurs, des fenêtres Buy Box et des données opérationnelles. Le produit marketplace n’y est pas une copie du produit interne : il représente la fiche telle qu’un fournisseur externe permet de la retrouver et de la décrire.

Cette nuance est structurante. Un EAN peut conduire à un ASIN Amazon ; Cdiscount renvoie une référence associée au GTIN demandé ; Fnac Darty expose un identifiant de produit au travers des offres du vendeur. Une colonne unique appelée « référence » aurait masqué ces différences au lieu de les résoudre.

Le projet a donc créé une couche de traduction. Elle réunit les champs transverses utiles à la lecture — nom, marque, fabricant, GTIN, références, catégorie, variation et images — tout en conservant les identifiants propres au canal et sa réponse détaillée. Les équipes gagnent un point de comparaison sans perdre la possibilité de revenir à la source.

2. Construire un contrat commun, puis respecter chaque API

Une même sortie fonctionnelle, trois stratégies de collecte

La première version du parcours de fiche a été livrée le 11 mars 2026 avec Amazon. Elle a posé le contrat commun, l’écriture de la fiche, sa date d’observation et l’actualisation depuis le Product Explorer. Le 15 avril, les lecteurs Cdiscount et Fnac Darty ont complété le dispositif avec leurs propres règles de recherche et de décodage.

Chaque connecteur produit le même objet de sortie, mais il ne fabrique pas les données absentes. Amazon peut renseigner fabricant, numéro de pièce, modèle ou thème de variation ; Cdiscount apporte notamment sa référence, sa marque et sa classification ; Fnac Darty fournit surtout le nom, le type, le visuel et le lien de la fiche rencontrée.

Les contrôles automatisés s’appuient sur des réponses représentatives de ces canaux. Ils vérifient le support du bon fournisseur, le décodage des formats, le mapping des champs, la conservation de la fiche détaillée et les cas de refus du service. La cohérence est sécurisée sans gommer les limites propres à chaque source.

3. Avant le projet : des fiches visibles, mais aucune lecture commune

Changer de marketplace changeait aussi la manière d’identifier et de décrire le produit

Une offre vendeur ne suffit pas à décrire correctement le produit auquel elle se rattache. Elle porte un prix, une quantité, un état commercial et des identifiants utiles à la vente. Le catalogue du canal détient, lui, le titre public, la marque, la classification, les visuels et parfois plusieurs références constructeur.

Lorsque ces informations restent seulement dans les réponses de chaque API, le cockpit sait qu’une offre existe sans toujours pouvoir présenter son produit de façon lisible. Deux lignes peuvent sembler étrangères alors qu’elles partagent un GTIN ; à l’inverse, un intitulé ressemblant peut donner une fausse impression de correspondance.

Le format aggravait le problème. Amazon fournit du JSON de catalogue et distingue ASIN, marketplace et identifiants externes. Cdiscount répond par une collection de produits filtrée par GTIN. Fnac Darty utilise un échange XML d’offres où la fiche doit être retrouvée par son identifiant produit.

Le besoin réel était donc une consolidation de lecture, pas un générateur de contenus. Ciama devait reconnaître ce que chaque canal sait fournir, conserver une structure commune pour l’interface et ne jamais transformer une absence de champ en information supposée.

4. Donner une fiche de reconnaissance au produit marketplace

Identifier, comprendre et vérifier avant toute décision catalogue

Le premier objectif était de stabiliser les identités. Ciama devait distinguer la clé utilisée pour rechercher le produit, son identifiant propre sur la marketplace et, lorsque la source le permet, le périmètre ou l’URL qui donne un contexte supplémentaire.

Le deuxième était de rendre les résultats comparables. Un écran commun devait pouvoir afficher le nom, le GTIN, la marque, le fabricant, les références, la catégorie, la variation et les images sans imposer à chaque page la structure native du fournisseur.

Le troisième était de préserver la profondeur. La normalisation facilite le pilotage quotidien, mais une anomalie se comprend parfois dans un attribut non retenu par le modèle commun. La réponse utile du fournisseur devait donc rester consultable à côté des champs résumés.

Enfin, cette collecte devait rester une observation. Elle devait éclairer le pilotage du catalogue marketplace, sans se faire passer pour un outil qui corrige ou rediffuse la fiche sur le canal.

5. Un modèle commun pour treize informations de catalogue

Normaliser ce qui aide réellement la lecture, conserver le reste dans la fiche source

Le contrat de collecte accepte treize champs normalisés : identifiant article marketplace, identifiant de périmètre, nom, marque, fabricant, GTIN, numéro de pièce, numéro de modèle, identifiant et libellé de catégorie, thème de variation, image principale et miniature. Chacun reste optionnel parce qu’aucune API ne garantit l’ensemble.

Ciama conserve séparément l’identifiant externe qui a déclenché la recherche. Cette clé n’est pas remplacée silencieusement par l’identifiant découvert. Un produit retrouvé par EAN sur Amazon peut ainsi garder sa clé de départ tout en mémorisant l’ASIN résolu.

La fiche détaillée du fournisseur est enregistrée en parallèle des champs normalisés, avec sa date d’observation. L’écran présente donc une synthèse stable pour le quotidien et un bloc JSON pour l’investigation. Le modèle commun n’oblige pas à renoncer aux particularités de la source.

Les textes courts sont bornés à 255 caractères et les URL de visuels à 1 024 caractères avant écriture. Cette contrainte protège la persistance face à une réponse externe démesurée. La réponse structurée, elle, reste disponible dans le champ de fiche lorsque le connecteur la fournit.

6. Amazon : résoudre l’identité avant de lire le catalogue

Passer de l’EAN à l’ASIN quand la clé de départ le demande

Le lecteur Amazon reconnaît les fournisseurs dont l’identifiant commence par le préfixe Amazon marketplace. Il traduit ensuite le canal en identifiant de marketplace attendu par Selling Partner API. Une connexion Amazon valide fournit le jeton nécessaire à la lecture du catalogue.

Lorsque la clé externe est un EAN13, Ciama lance d’abord une recherche catalogue limitée à un résultat pour tenter de retrouver l’ASIN. Si la clé n’est pas un EAN13, elle est utilisée directement comme ASIN. Cette étape sépare clairement l’identifiant vendeur ou standard de l’identifiant article Amazon.

La lecture de la fiche demande les résumés, images, identifiants et attributs. Le connecteur extrait alors les éléments disponibles : nom, marque, fabricant, EAN, numéro de pièce, modèle, classification, variation et visuels. Pour les images, il privilégie une image principale de grande taille et une miniature adaptée lorsque les variantes le permettent.

La réponse Amazon complète reste attachée à la fiche. Si un champ utile se cache dans une structure spécifique à une catégorie, l’équipe peut donc examiner le matériau reçu sans attendre une extension immédiate du modèle commun.

7. Cdiscount : retrouver la bonne fiche par GTIN

Comparer les identifiants sans laisser un zéro initial casser le rapprochement

Le connecteur Cdiscount interroge l’API vendeur Octopia avec le GTIN du produit et l’identifiant du vendeur connecté. Il demande explicitement la référence, le libellé, le GTIN, la langue, la catégorie, la marque, la description, les images et les permissions disponibles.

La réponse peut contenir plusieurs éléments. Ciama cherche celui dont le GTIN correspond à la clé externe en normalisant les zéros placés en tête. Cette règle répond à un cas réel : la même valeur peut être représentée avec ou sans son zéro de préfixe selon la réponse et le référentiel.

La fiche commune reçoit notamment la référence Cdiscount, le libellé, la marque, la référence et le nom de catégorie, le GTIN et le premier visuel. Une URL relative issue du CDN Cdiscount est reconstruite avec sa base publique ; une URL déjà absolue n’est pas modifiée.

Le produit Cdiscount sélectionné est aussi conservé dans sa forme structurée. Les champs de description ou de permission peuvent ainsi rester consultables même lorsqu’ils ne deviennent pas une colonne transversale dans Ciama.

8. Fnac Darty : retrouver le produit dans les offres du vendeur

Respecter un protocole XML et une recherche paginée par identifiant exact

Fnac Darty impose un parcours différent. Ciama authentifie la boutique avec son partenaire, son identifiant de shop et sa clé, puis interroge les offres vendeur au format XML. Le produit n’est pas lu par le même type de endpoint catalogue qu’Amazon ou Cdiscount.

Le connecteur parcourt les pages de résultats, jusqu’à 200 offres par page, et compare l’identifiant produit Fnac de chaque ligne à la clé recherchée. Il s’arrête dès que la correspondance exacte est trouvée ; sinon, il poursuit jusqu’à la dernière page avant de signaler une absence.

La synthèse conserve l’identifiant Fnac, le nom du produit, le libellé de type, le visuel et l’URL publique de la fiche. Les informations de marque, de fabricant ou de GTIN restent vides si cette réponse ne les expose pas. Le modèle assume cette différence de profondeur.

La réponse utile est transformée en structure consultable, mais les identifiants propres à l’offre et au vendeur sont retirés de la fiche produit conservée. Ciama évite ainsi de mélanger le descriptif du produit avec les clés commerciales de la ligne qui a permis de le retrouver.

9. Garder trois niveaux d’identité au lieu d’une référence ambiguë

Clé de recherche, article marketplace et périmètre restent distingués

La clé externe identifie le produit connu de Ciama pour un fournisseur donné. L’identifiant article marketplace peut être découvert pendant la collecte : ASIN chez Amazon, référence chez Cdiscount ou identifiant produit Fnac. Le périmètre externe peut encore ajouter le contexte Amazon ou l’URL publique Fnac.

Cette séparation protège les rapprochements. Si un EAN conduit à un ASIN, le système n’efface pas la manière dont le produit a été demandé. Si une URL Fnac accompagne son identifiant, elle ne devient pas pour autant la clé de jointure. Chaque valeur reste utilisable pour la fonction qu’elle remplit.

Le couple fournisseur–identifiant externe est unique dans le référentiel des produits marketplace. La même chaîne peut donc exister chez deux canaux sans collision, tandis qu’un doublon au sein du même fournisseur est empêché par le modèle de persistance.

Dans le Product Explorer marketplace, ces repères permettent de passer du résultat de recherche à la fiche, puis de comprendre quel canal l’a fournie et quel identifiant doit être utilisé pour une nouvelle lecture.

10. Conserver la réponse source pour expliquer les différences

La normalisation accélère la lecture ; le détail protège le diagnostic

Deux marketplaces peuvent remplir le même champ « catégorie » avec des concepts différents. Amazon distingue un identifiant de classification et son libellé ; Cdiscount renvoie la référence et le nom de sa catégorie ; Fnac Darty expose ici un type de produit sans identifiant de taxonomie équivalent.

Réduire ces réponses à une seule colonne suffit pour afficher une carte, mais pas toujours pour expliquer un écart. La fiche source permet de voir ce que le canal a réellement renvoyé à la date de collecte, y compris les attributs qui ne sont pas encore projetés dans le modèle commun.

Cette double lecture évite deux écueils. L’interface n’a pas besoin de connaître chaque structure d’API pour présenter les informations courantes ; l’équipe technique n’est pas privée du détail lorsqu’elle doit vérifier une réponse, ajouter un mapping ou comprendre pourquoi une valeur manque.

La date de synchronisation accompagne la fiche. Elle ne prouve pas que le contenu public est resté identique depuis cette observation, mais elle empêche de présenter une ancienne réponse comme si elle venait d’être lue.

11. Actualiser en arrière-plan sans marteler les APIs

Une action visible, un traitement asynchrone et une fenêtre de sept jours

Depuis la page produit, le bouton d’actualisation place une demande dans la file de traitement. L’utilisateur revient immédiatement à la fiche au lieu d’attendre la réponse distante dans sa requête web. Le connecteur travaille ensuite avec le compte, le produit et le canal concernés.

Avant tout appel externe, le service vérifie que le compte est présent, que le produit existe, que son fournisseur est bien une marketplace, qu’un canal correspondant est configuré pour le compte et que ses informations de connexion peuvent être décodées.

Si la fiche a déjà été observée depuis moins de sept jours, la collecte s’arrête sans nouvelle écriture. Ce garde-fou limite les appels répétés sur une donnée considérée comme encore fraîche. Il faut en connaître la conséquence : le bouton confirme la mise en file, mais une fiche récente ne sera volontairement pas relue.

Un connecteur non pris en charge ou une erreur de source ne produit pas une fiche partielle présentée comme réussie. Le traitement remonte une erreur contextualisée dans ses journaux. La donnée précédente reste alors le dernier état connu, avec son ancien horodatage.

12. Propager les visuels sans confondre produit et offre

Une image de fiche peut améliorer la lecture des lignes commerciales liées

Une fois la fiche normalisée, Ciama met à jour le produit marketplace puis propage son image principale et sa miniature aux offres qui lui sont déjà rattachées. Le nom, la catégorie ou la marque ne sont pas recopiés arbitrairement dans le modèle commercial.

Ce choix répond à un besoin d’interface : une offre est beaucoup plus facile à reconnaître lorsqu’elle affiche le produit qu’elle représente. La mise à jour reste fondée sur une relation déjà établie avec le produit marketplace ; elle ne tente pas de rapprocher des offres au moyen d’une image ressemblante.

Le nombre d’offres dont les visuels ont été mis à jour est conservé dans la réponse du traitement et apparaît dans ses journaux. L’équipe technique peut ainsi distinguer une fiche collectée sans offre liée d’une collecte ayant effectivement enrichi plusieurs écrans commerciaux.

Pour relire prix, stock, statut et réponse commerciale directement depuis une ligne, Ciama dispose d’un parcours séparé de rafraîchissement des offres marketplace. La fiche produit et l’offre restent deux sources et deux opérations différentes.

13. Les arbitrages qui rendent la consolidation crédible

Ne pas égaliser artificiellement des sources qui ne racontent pas la même chose

Premier arbitrage : tous les champs sont optionnels. Un produit Fnac Darty n’obtient pas une marque supposée parce qu’Amazon la renvoie souvent. La fiche commune accepte les trous et l’interface les montre comme des absences, ce qui vaut mieux qu’une donnée fausse.

Deuxième arbitrage : le nom et les images déjà connus servent de repli si une nouvelle réponse ne les fournit pas. Les autres caractéristiques sont remises à la valeur collectée, y compris lorsqu’elle est absente. Ce compromis évite de dégrader la reconnaissance visuelle tout en empêchant des attributs anciens de sembler fraîchement confirmés.

Troisième arbitrage : le GTIN nouvellement lu devient la valeur normalisée et alimente la liste des GTIN. Si la source n’en donne aucun, la liste existante est conservée. Le système protège ainsi les identifiants déjà disponibles sans en inventer un à partir d’un simple nom.

Quatrième arbitrage : la fiche source complète reste séparée du résumé. Le modèle transverse peut évoluer avec parcimonie, tandis que les particularités d’une catégorie ou d’un fournisseur demeurent accessibles pour les cas où elles comptent vraiment.

14. Tester le contrat commun et les particularités de chaque canal

Des cas de domaine complétés par des réponses représentatives des fournisseurs

Les tests du service couvrent les entrées manquantes, le produit inconnu, la fiche encore récente, le fournisseur absent ou de mauvais type, le canal introuvable, les informations de connexion invalides et l’échec du lecteur. Ces cas vérifient qu’une précondition invalide bloque la collecte au bon endroit.

Le scénario nominal contrôle l’écriture des champs normalisés et la propagation des visuels aux offres liées. Il vérifie aussi le comportement de repli : conserver un nom ou une image antérieure lorsque la source ne renvoie pas mieux, tout en enregistrant la date et la fiche nouvellement observées.

Côté connecteurs, les tests Cdiscount et Fnac Darty rejouent des charges représentatives des APIs. Ils vérifient notamment le GTIN avec zéro initial, la reconstruction du visuel Cdiscount, la lecture XML Fnac, la pagination et le retrait des identifiants d’offre de la fiche produit.

Amazon possède ses propres contrôles de parsing sur les résumés, attributs, identifiants et images. Cette séparation facilite les évolutions : une modification de réponse Amazon ne doit pas rendre silencieusement faux le mapping Cdiscount ou Fnac Darty.

15. Livrer d’abord le contrat, puis étendre les sources

Amazon en mars, Cdiscount et Fnac Darty en avril 2026

Le 11 mars 2026, la première livraison a réuni le modèle de fiche, le service de collecte, le lecteur Amazon et la persistance des nouvelles informations catalogue. Ce lot a établi le vocabulaire commun avant de multiplier les variantes de fournisseurs.

Les jours suivants ont consolidé la gestion des erreurs et le parcours asynchrone. Le Product Explorer a reçu sa commande d’actualisation, les informations normalisées, la date de synchronisation et la réponse source consultable sur la page produit.

Le 15 avril, Cdiscount et Fnac Darty ont rejoint la même abstraction. Leur ajout n’a pas consisté à recopier Amazon : chaque intégration possède son authentification, sa recherche, son format et ses règles de mapping, puis produit le contrat partagé par l’interface.

Le 26 avril, les produits issus des flux d’offres Mirakl ont également gagné des informations d’identité et plusieurs GTIN. Cette évolution appartient au flux des offres, pas au bouton de fiche présenté ici. La distinction reste utile pour savoir si une donnée vient d’une lecture catalogue explicite ou d’une synchronisation commerciale.

16. Ce qui change dans le travail quotidien

Moins d’allers-retours entre extranets, plus de contexte sur chaque ligne

Le premier gain est la reconnaissance. Un produit externe peut afficher un nom, un visuel, une marque, une catégorie et ses identifiants disponibles dans la même page que ses éléments de pilotage. L’équipe ne dépend plus uniquement d’une clé opaque pour comprendre la référence observée.

Le deuxième est la comparabilité. Les informations transverses occupent les mêmes emplacements quel que soit le fournisseur, tandis que les champs absents restent clairement absents. Passer d’Amazon à Cdiscount ou Fnac Darty ne demande plus de réapprendre toute la structure pour une vérification de premier niveau.

Le troisième est la capacité d’enquête. Lorsqu’une catégorie paraît surprenante ou qu’un GTIN diffère, la réponse source et sa date sont disponibles. Le diagnostic peut porter sur ce qui a vraiment été reçu, au lieu de partir d’une capture ancienne ou d’un souvenir de l’extranet.

Enfin, la propagation des images améliore la lecture des offres déjà liées. Ce gain reste volontairement borné : la fiche interne devient plus utile, mais aucune promesse de correction, de référencement ou de vente supplémentaire n’est attribuée à une simple collecte.

17. Le scénario qui montre la valeur des identifiants séparés

Un EAN recherché sur Amazon aboutit à une fiche pilotable sans perdre sa trace

Une équipe retrouve dans Ciama un produit Amazon dont la clé externe est un EAN13. Le libellé est ancien et aucun ASIN n’est encore affiché. Depuis la fiche, elle demande une actualisation ; la requête rejoint la file pendant qu’elle poursuit son travail.

Le connecteur utilise le canal Amazon du compte, transforme son jeton de connexion en accès API et cherche d’abord le catalogue avec cet EAN. La réponse désigne un ASIN. Ciama lit alors la fiche de cet article dans la marketplace concernée et récupère les informations exposées par Amazon.

La clé EAN de départ reste visible. L’ASIN devient l’identifiant article marketplace ; le titre, la marque, la classification et les images disponibles complètent la synthèse ; la réponse Amazon et l’heure d’observation restent accessibles. Les offres déjà rattachées au produit reçoivent les nouveaux visuels.

L’équipe peut désormais examiner ce produit dans le Product Explorer avec des repères explicites. Si le titre public doit être corrigé, elle sait aussi que cette action doit repartir du PIM ou du processus catalogue : la collecte n’a jamais prétendu l’effectuer.

18. Les limites qui empêchent de survendre le projet

Une fiche observée n’est ni un audit de qualité ni un flux de publication

La collecte enrichit les attributs disponibles sans calculer de score de complétude par catégorie ni prioriser les corrections par marge, stock ou potentiel commercial. Ces décisions relèvent d’un outil de qualité catalogue construit sur les données consolidées.

Il ne modifie aucun titre, aucune description, aucune image et aucune catégorie sur la marketplace. Les visuels collectés enrichissent Ciama et les offres internes liées ; ils ne sont pas renvoyés au canal. La gestion du catalogue PIM marketplace reste le bon périmètre pour gouverner et diffuser un contenu.

La profondeur dépend de la source. Amazon peut exposer davantage de caractéristiques que Fnac Darty dans le parcours utilisé. Une fiche vide sur certains champs ne signifie donc pas automatiquement que la page publique est incomplète ; elle signifie d’abord que cette collecte ne les a pas obtenus.

Enfin, le garde-fou de sept jours privilégie la maîtrise des appels à la fraîcheur immédiate. Pour une investigation urgente sur une fiche récemment observée, cette règle doit être connue. Le projet fournit un état daté et explicable, pas une surveillance en temps réel du catalogue public.

19. Relier observation, catalogue et exploitation sans brouiller les rôles

Trois étapes complémentaires autour du même produit

Le Product Explorer marketplace organise la recherche et la consultation des produits externes. Le présent projet lui donne la fiche normalisée, les identifiants et le matériau source nécessaires pour comprendre chaque résultat.

Le catalogue PIM marketplace répond ensuite à une autre question : quelles données l’entreprise considère-t-elle comme justes, comment les adapter aux règles des canaux et comment gouverner leur correction ? Observer un contenu externe aide ce travail, mais ne le remplace pas.

Les connecteurs marketplace et ERP transportent enfin les lectures et les écritures autorisées, avec leurs contrats, erreurs et reprises. Séparer ces responsabilités rend le run plus clair : regarder la fiche, décider de la source juste, puis diffuser par le flux approprié.

Dans Ciama Marketplace, cette continuité transforme une référence opaque en objet de pilotage. Produit externe, offre vendeur, analyse Buy Box et donnée interne peuvent se rejoindre sans être artificiellement fondus.