Le projet en un coup d’œil
Rapports Amazon, API Mirakl, flux Octopia et XML Fnac Darty portent des identifiants, états, stocks, prix et paginations différents.
Chaque adaptateur produit une offre normalisée, ensuite reconnue par canal, SKU et état avant d’être reliée au produit et à la fiche marketplace.
Les équipes filtrent et comparent les offres, tandis qu’une collecte complète désactive les absentes seulement si la source a effectivement renvoyé des résultats.
Une offre marketplace paraît simple tant qu’on ne regarde qu’un canal : un SKU, un prix et une quantité. Dès qu’un vendeur réunit Amazon, une marketplace Mirakl, Cdiscount et Fnac Darty, les écarts de formats deviennent un risque métier. Les identifiants ne portent pas le même nom, les conditions produit ne partagent pas les mêmes codes et la disponibilité ne se déduit pas partout de la même façon.
Dawap a construit dans Ciama une chaîne de normalisation qui commence dans chaque API, produit un contrat d’offre commun puis rattache cette offre au bon canal, au produit vendeur et, lorsque l’identifiant existe, à la fiche produit marketplace. Prix source et prix converti, stock, activité, mode logistique et identifiants restent explicables.
Cette fondation de nos connecteurs marketplace ERP a été durcie jusqu’au 8 septembre 2026 avec un garde-fou essentiel : une collecte complète vide ne doit jamais faire croire que tout le catalogue a disparu. La normalisation devient ainsi une preuve de continuité opérationnelle, pas seulement une élégance de données.
1. Ciama, le cockpit Dawap pour les opérations vendeurs
Comparer les offres sans perdre ce qui fait la vérité de chaque canal
Ciama Marketplace réunit les canaux, produits, offres, commandes, stocks et indicateurs d’un vendeur multicanal. Son radar d’offres doit permettre de chercher un SKU, isoler une marketplace, distinguer une offre active ou inactive, regarder le stock, le prix et le mode de traitement logistique.
Le défi n’était pas de dessiner un tableau commun. Il fallait d’abord produire des objets réellement comparables à partir de sources incompatibles : rapports Amazon en plusieurs langues, pages JSON Mirakl, réponses Octopia avec navigation par lien et dialogue XML Fnac Darty.
Le noyau normalisé retient le canal, l’identifiant vendeur, la condition de stock, la quantité, le prix TTC, l’état actif, le mode de traitement par le vendeur ou la plateforme et la devise. Il accepte ensuite des métadonnées facultatives : nom, description, identifiants externes, image, catégorie, marque, GTIN et dates marketplace.
Ce contrat ne gomme pas les limites. Une source peut renseigner le titre et l’image quand une autre n’en fournit pas. Une condition inconnue peut être écartée. Le prix converti peut rester absent si la devise ne peut pas être résolue. L’écran rend ces absences visibles au lieu de les remplacer par une valeur vraisemblable.
2. Faire évoluer la chaîne depuis la collecte Amazon jusqu’au garde-fou de production
Une progression continue entre octobre 2025 et septembre 2026
Le socle moderne commence fin octobre 2025 avec la collecte des offres Amazon et la distinction des offres expédiées par le vendeur ou par Amazon. En mars 2026, la chaîne est restructurée autour des fournisseurs de données et de leurs connexions, puis les résultats de persistance deviennent traçables.
Le 25 avril 2026, une collecte complète acquiert une responsabilité supplémentaire : désactiver les offres encore actives qui ne figurent plus dans l’inventaire remonté par le canal. Le lendemain, le radar gagne le GTIN, la conversion de prix et les contrôles de rafraîchissement au niveau de chaque ligne.
Cette désactivation est utile seulement si l’inventaire reçu est digne de confiance. Le 8 septembre 2026, Dawap ajoute donc la condition qui ferme le risque principal : si le fournisseur répond avec zéro offre, aucune désactivation de masse n’est exécutée. La collecte vide préserve l’état existant pour permettre le diagnostic.
La méthode du projet se lit dans cette chronologie : normaliser les données, relier les objets, rendre le résultat consultable, puis durcir le comportement face aux réponses incomplètes. Le produit ne considère pas qu’une absence de données est automatiquement une preuve d’absence commerciale.
3. Avant le modèle commun : quatre définitions d’une même offre
Des formats différents jusque dans les notions les plus élémentaires
Amazon sépare les rapports vendeur et FBA, et peut livrer leurs colonnes en anglais ou en français. Fnac Darty encode la condition dans un nombre. Cdiscount place la quantité dans la première option de livraison et l’état dans une valeur propre à Octopia. Mirakl propose plusieurs noms de champs selon l’enseigne et la configuration.
Une comparaison directe aurait produit des erreurs silencieuses. Le nombre 11 peut signifier neuf dans un canal, tandis qu’une chaîne New porte la même intention ailleurs. Une quantité peut représenter le stock vendeur ou le disponible total d’un réseau logistique. Un booléen générique ne suffit pas à expliquer ces nuances.
La pagination varie également. Mirakl travaille par blocs de cent et offsets ; Cdiscount suit le lien next de la réponse avec une limite de sécurité ; Fnac Darty annonce le nombre total de pages dans son XML ; Amazon génère et restitue des rapports qui doivent ensuite être décodés.
Enfin, l’absence d’une offre n’a pas toujours la même signification. Elle peut indiquer un retrait réel du catalogue, mais aussi une page vide, une erreur temporaire, un rapport incomplet ou un problème de connexion. La chaîne devait préserver cette incertitude avant de muter les données existantes.
4. Créer une comparaison exploitable sans fabriquer de fausse équivalence
Un noyau obligatoire et des enrichissements facultatifs
Le premier objectif était de définir les informations sans lesquelles aucune offre ne peut être pilotée : canal, SKU vendeur, condition, quantité, prix TTC, activité, mode logistique et devise. Tous les adaptateurs doivent produire ce noyau dans le même ordre et avec les mêmes types.
Le deuxième objectif consistait à garder les identifiants externes nécessaires au rapprochement. Le SKU vendeur reconnaît l’offre dans le canal ; l’identifiant produit marketplace rattache la fiche de catalogue ; l’identifiant externe de l’offre reste disponible quand la plateforme en fournit un distinct.
Le troisième objectif était de ne pas perdre les enrichissements réellement reçus. Un titre, une image, une marque, un GTIN, une catégorie ou une date de mise à jour peuvent alimenter la fiche produit marketplace, sans devenir obligatoires pour accepter toutes les offres.
Le quatrième objectif concernait la sécurité de l’inventaire. Une collecte complète devait pouvoir désactiver les références réellement disparues, tout en distinguant ce cas d’une réponse vide qui ne démontre rien. Cette nuance détermine la confiance que les équipes peuvent accorder à l’automatisation.
5. Faire passer chaque source par un contrat d’offre unique
Des champs communs suffisamment précis pour rester utiles
Chaque adaptateur construit le même objet de transfert. Le canal et l’identifiant situent l’offre ; la condition évite de confondre deux états commerciaux du même SKU ; la quantité et le prix décrivent l’exposition ; l’activité dit si la source considère l’offre exploitable.
Le mode fulfilled by seller porte une distinction opérationnelle majeure. Une valeur vraie signifie que le vendeur traite la logistique ; une valeur fausse indique une prise en charge par la plateforme. Amazon peut produire les deux cas dans une même collecte grâce à ses rapports vendeur et FBA.
La devise n’est pas réduite à un symbole affiché. L’offre normalisée référence une devise connue du produit, ce qui permet de conserver le prix source puis de demander une conversion en euros à l’étape de persistance.
Les champs facultatifs restent distincts du noyau. Cette structure évite deux écueils : rejeter une offre exploitable parce qu’une image manque, ou considérer un champ absent comme une chaîne vide ayant la même valeur qu’une donnée réellement fournie.
6. Traduire quatre écosystèmes sans dupliquer le métier
Amazon, Mirakl, Cdiscount/Octopia et Fnac Darty
L’adaptateur Amazon combine les offres expédiées par le vendeur et les offres FBA. Il reconnaît les variantes de colonnes anglaises et françaises, normalise les conditions, rapproche le stock FBA disponible et attribue le bon mode logistique à chaque ligne.
L’adaptateur Mirakl prend en charge les fournisseurs déclarés sur ce moteur ou configurés comme tels. Il cherche le SKU dans plusieurs champs possibles, récupère la quantité et le prix selon les variantes de réponse, résout la devise et peut transmettre titre, image, catégorie, marque et plusieurs GTIN.
L’adaptateur Cdiscount s’appuie sur l’API vendeur Octopia. Il suit les pages annoncées par les liens de réponse, borne le parcours à cinq cents pages, utilise la référence externe vendeur comme identifiant et traduit les conditions New ou RefurbishedLikeNew dans le modèle commun.
L’adaptateur Fnac Darty dialogue en XML, traite les pages de deux cents résultats et transforme les codes de condition pris en charge en neuf, occasion ou reconditionné vendeur. Les codes inconnus sont écartés au lieu d’être classés arbitrairement.
7. Ramener les conditions produit à trois familles explicites
Neuf, occasion et reconditionné vendeur sans forcer les codes inconnus
Les plateformes emploient des codes numériques, des libellés ou des niveaux détaillés pour décrire l’état du produit. Ciama les ramène aux familles new, used et refurbished_seller lorsque la correspondance est définie.
Cette réduction rend les offres comparables et participe à leur identité. Un même SKU dans le même canal peut être distingué par sa condition, ce qui évite de fusionner une offre neuve avec une offre d’occasion ou reconditionnée.
Lorsque la condition évolue pour un SKU déjà connu, le traitement cherche d’abord l’identité complète canal-SKU-condition. À défaut, il retrouve l’offre par canal et SKU, met à jour sa condition puis reprend le traitement sur cette nouvelle identité.
Une condition impossible à traduire n’est pas transformée en neuf par défaut dans les adaptateurs qui disposent d’un code explicite. L’offre concernée est ignorée pour préserver la qualité du référentiel ; l’ajout d’une nouvelle correspondance demande une décision consciente.
8. Reconnaître l’offre par canal, SKU et condition
Ajouter une fois, mettre à jour ensuite et conserver la continuité
La collecte résout d’abord la connexion fournisseur, vérifie qu’elle est active et que ses identifiants ont été validés, puis contrôle l’état et la disponibilité du fournisseur de données. Seuls les types marketplace et e-commerce sont acceptés dans ce parcours commun.
Le canal peut être fourni explicitement. Dans ce cas, son compte et son fournisseur doivent correspondre à la connexion. S’il n’est pas fourni, Ciama n’accepte la résolution implicite que lorsqu’un seul canal actif correspond ; zéro ou plusieurs canaux produisent une erreur explicite.
Chaque offre reçue est ensuite recherchée par canal, identifiant vendeur et condition. Une offre inconnue déclenche une création ; une offre connue déclenche une mise à jour. Les compteurs de résultats distinguent le volume collecté, les ajouts et les mises à jour demandées.
Le compte n’est jamais déduit du SKU. Il vient du canal relié à la connexion. Deux vendeurs peuvent donc utiliser le même SKU sans partager une offre, et deux marketplaces d’un même compte conservent chacune leur objet même lorsqu’elles publient la même référence.
9. Relier l’offre au produit vendeur et au produit marketplace
Deux identités complémentaires plutôt qu’un unique catalogue écrasé
Après la création ou la mise à jour, Ciama cherche d’abord un alias produit correspondant au SKU dans le compte. Si aucun alias n’existe, il recherche l’identifiant principal. Si le produit vendeur manque encore, un produit minimal est créé avec l’identifiant et la condition pour éviter une offre orpheline.
Lorsque la source fournit un identifiant produit marketplace, Ciama cherche aussi une fiche liée au fournisseur de données. Elle peut être créée puis enrichie avec le nom, la marque, le GTIN, la liste de GTIN, la catégorie, l’image et la matière source disponibles.
Cette seconde mise à jour fonctionne en effort raisonnable : un conflit ou une erreur d’enrichissement ne doit pas annuler l’offre déjà collectée. Si la fiche existe, elle est reliée à l’offre et son image peut alimenter la ligne du radar.
Une fiche marketplace dont l’observation détaillée date de plus de sept jours peut déclencher une demande de rafraîchissement. La collecte d’offres installe ainsi le lien, tandis qu’un traitement spécialisé approfondit ensuite le catalogue sans ralentir toute la chaîne.
10. Conserver le prix source et calculer une référence en euros
Une conversion attachée à la date disponible de l’offre
À chaque ajout ou mise à jour, Ciama conserve le prix TTC et la devise transmis par l’adaptateur. Il demande ensuite une conversion en euros à partir de la date de mise à jour marketplace, ou de la date de création si elle est seule disponible.
Lorsqu’aucune date source n’est fournie, l’instant de collecte sert de référence. Ce repli rend la conversion possible pour les plateformes moins riches, tout en donnant la priorité à la chronologie du canal quand elle existe.
Si la devise source n’est pas reconnue, la conversion reste absente. Le radar affiche alors un prix manquant plutôt que de présenter un euro fictif. Lorsqu’elle existe, l’utilisateur peut ouvrir le détail du prix source, de la conversion et de la date d’application.
Ce montant normalisé facilite la comparaison des prix d’exposition. Il ne représente pas la marge, car aucun coût d’achat, frais logistique ou commission marketplace n’entre dans cette étape. La gestion des offres et du repricing s’appuie sur ce socle mais ajoute ses propres règles.
11. Désactiver une offre absente seulement après une collecte complète crédible
Le garde-fou qui sépare retrait commercial et réponse vide
Une collecte sans bornes temporelles représente un inventaire complet du canal. Ciama mémorise alors tous les identifiants reçus. Lorsque la collecte est terminée et non vide, les offres encore actives du même canal mais absentes de cette liste sont désactivées.
Cette règle permet de refléter un retrait réel sans attendre que la plateforme renvoie explicitement une ligne inactive. Elle ne s’applique pas aux collectes limitées à une période, car l’absence d’un SKU dans un intervalle de modifications ne dit rien de son activité actuelle.
Le cas zéro est traité séparément depuis le 8 septembre 2026. Si une collecte complète ne renvoie aucune offre, Ciama conserve toutes les offres existantes. Une réponse vide peut venir d’un incident ou d’une source momentanément incomplète ; elle n’est pas une preuve suffisante pour fermer le catalogue.
Une erreur levée pendant la lecture est également transformée en résultat d’échec avant le traitement des offres. L’état courant n’est pas balayé par une collecte qui n’a pas produit d’inventaire exploitable. Ce comportement protège directement le run vendeur.
Ajouts et mises à jour seulement
Aucune désactivation
Inventaire reçu et identifiants mémorisés
Désactivation dans le canal concerné
Offre créée ou mise à jour
12. Présenter les offres normalisées dans un radar multi-canal
Cinquante lignes, huit axes de filtre et les ventes récentes en priorité
Le radar limite systématiquement la recherche au compte connecté et au type marketplace. Il affiche cinquante offres par page, classées par quantités vendues sur les trois cent soixante derniers jours, de la plus forte à la plus faible par défaut.
L’utilisateur peut rechercher un identifiant, choisir un canal, filtrer activité, présence de stock, traitement vendeur ou plateforme, année de vente, marque, catégorie et tag. Le filtre annuel exige au moins une ligne de commande positive, non annulée et non remboursée sur l’année choisie.
Chaque ligne rapproche logo du canal, image, SKU, produit, GTIN, traitement logistique, condition, activité, stock, prix converti, état de Buy Box, prix gagnant, nombre de vendeurs, ventes à quatre-vingt-dix, cent quatre-vingts et trois cent soixante jours, puis date de mise à jour.
Deux indicateurs globaux comptent les offres marketplace actives en stock et les produits distincts associés. Ils appliquent le compte, le type marketplace, l’activité et un stock strictement positif ; ils ne dépendent pas des cinquante lignes de la page courante.
13. Les arbitrages qui évitent une normalisation dangereuse
Préserver les écarts de source, les valeurs inconnues et le périmètre du canal
Le premier arbitrage maintient des adaptateurs séparés. Le contrat final est commun, mais Amazon ne doit pas être lu comme Mirakl et un XML Fnac Darty ne doit pas être forcé dans la pagination Octopia. Chaque intégration traduit ses propres garanties.
Le deuxième distingue champ obligatoire et enrichissement. Une offre peut être exploitée sans image ou catégorie, tandis qu’un SKU et une condition sont indispensables à son identité. La qualité du catalogue peut ensuite progresser sans bloquer la visibilité commerciale initiale.
Le troisième garde la conversion distincte du prix source. Une erreur de devise ne modifie pas le montant fourni par la marketplace. L’absence de conversion reste visible et corrigible, au lieu de contaminer silencieusement la donnée d’origine.
Le quatrième refuse d’assimiler zéro résultat à zéro offre. Ce choix renonce à une fermeture automatique séduisante dans un cas ambigu, mais protège les vendeurs contre la conséquence la plus coûteuse d’une intégration : éteindre un catalogue valide à cause d’une réponse défaillante.
14. Ce que le socle ne prétend pas résoudre seul
Ni diagnostic de rejet, ni marge complète, ni vérité absolue sur la Buy Box
Le modèle courant porte un booléen actif, pas une taxonomie universelle de tous les motifs de rejet. Une offre inactive peut demander une lecture complémentaire de la plateforme ; la normalisation ne fabrique pas un message d’erreur si la source n’en fournit pas dans ce flux.
Le prix affiché est un prix TTC source et, si possible, converti. Il ne suffit pas à décider d’un repricing rentable. Coût d’achat, commissions, logistique, retours et objectifs de marge appartiennent à des traitements spécialisés.
La Buy Box et son prix gagnant viennent de la fiche produit marketplace et de ses observations. Ils peuvent être inconnus ou manquer de devise ; le radar l’indique. Leur présence dans la même ligne ne signifie pas que la collecte d’offres les rafraîchit tous au même instant.
Enfin, le tableau permet aujourd’hui des actions de rafraîchissement ou de stock, mais ces capacités ont leurs propres garde-fous et projets. La présente preuve reste centrée sur la collecte, l’identité, la normalisation, le rapprochement et la protection de l’inventaire.
15. Ce qui change après la normalisation
Une comparaison multi-canal traçable et un catalogue plus résilient
Les équipes disposent d’une même grille de lecture pour quatre écosystèmes. Elles peuvent isoler les offres actives sans stock, comparer les modes logistiques et retrouver les références importantes par leurs ventes récentes, sans réinterpréter chaque format à chaque consultation.
Le produit vendeur devient le point commun entre les canaux. Alias et identifiants relient les offres à une même référence interne, tandis que la fiche marketplace conserve l’identité externe et les enrichissements propres à la plateforme.
Les prix gagnent une double traçabilité : montant et devise source restent visibles, montant converti et date d’application facilitent la comparaison. Une conversion impossible produit une absence explicite, ce qui dirige la correction vers la bonne donnée.
Surtout, l’automatisation de l’inventaire ne transforme plus un silence en décision destructive. Les offres réellement absentes d’un inventaire complet peuvent être désactivées ; un inventaire vide déclenche une conservation. Cette différence protège la continuité commerciale.
16. Le scénario terrain qui résume le projet
Une collecte complète revient vide pendant que les offres restent publiées
Une marketplace répond sans offre alors que le vendeur sait que son catalogue est toujours actif. Le traitement reçoit donc zéro résultat pour un canal qui possède déjà plusieurs références dans Ciama.
Avant toute décision, la chaîne distingue ce cas d’un inventaire complet non vide. Comme aucune offre n’a été collectée, elle ne construit pas une liste d’absents et ne désactive rien. Les stocks, prix et états connus restent disponibles dans le cockpit.
L’équipe peut examiner la connexion, relancer la collecte ou utiliser le rafraîchissement ciblé sur une offre. Elle ne doit pas restaurer manuellement tout le catalogue après qu’un incident de lecture a été interprété comme un retrait commercial.
Lorsque la collecte suivante revient avec un inventaire réel, chaque ligne est normalisée puis ajoutée ou mise à jour. Les offres actives absentes de cette liste crédible sont alors désactivées dans ce canal uniquement. Le système retrouve sa capacité de réconciliation sans sacrifier la prudence.
17. Transformer le modèle commun en outils de pilotage spécialisés
Couverture, contrôle qualité, action ciblée et lecture par produit
L’Offer Listing Matrix réutilise les relations produit-canal pour comparer, produit par produit, les offres présentes et les canaux manquants. Elle commence là où la normalisation a déjà rendu les identités cohérentes.
Le tableau de qualité catalogue transforme ensuite plusieurs contrôles produit en lignes de correction. GTIN, relations marketplace et couverture d’offres y deviennent des signaux explicites plutôt que des suppositions.
Le projet de rafraîchissement ciblé d’une offre permet de revenir à la source sans relancer tout le canal. Il prolonge le même contrat avec une opération ponctuelle et contrôlée.
Enfin, la vue produit vendeur unifiée rassemble l’objet interne, ses stocks et ses offres. Ce maillage montre la progression réelle : traduire la source, stabiliser l’identité, relier les produits puis construire les outils de décision.
18. Conclusion
La comparabilité se gagne dans les règles, pas dans le tableau
Ce projet transforme quatre façons de décrire une offre en un noyau exploitable sans prétendre que les plateformes sont interchangeables. Chaque adaptateur garde sa logique de lecture ; le contrat commun donne ensuite au reste de Ciama une identité, un stock, un prix, une devise, un état et un mode logistique cohérents.
La force de la livraison tient aussi aux scénarios défensifs. Un canal ambigu n’est pas choisi arbitrairement, une condition inconnue n’est pas classée au hasard, une devise absente ne produit pas un faux euro et une collecte vide ne ferme pas les offres existantes.
C’est le niveau d’exigence que Dawap apporte aux connecteurs marketplace ERP : collecter chaque source selon ses règles, normaliser seulement ce qui peut l’être, conserver les identifiants utiles et protéger l’activité lorsque le réel sort du scénario nominal.
