Préparer son catalogue pour Amazon, Cdiscount et Fnac

Vous voulez ouvrir Amazon, Cdiscount et Fnac avant la haute saison, sans ressaisir trois fois le même catalogue. La difficulté n'est presque jamais la connexion technique : elle se règle avec un connecteur. Elle vient de vos données, parce que chaque marketplace impose ses attributs obligatoires par catégorie, son vocabulaire et ses contrôles à l'entrée. Cet article porte sur la préparation du catalogue en amont : ce qui est commun aux trois, ce qui diffère, et comment modéliser une fois pour diffuser partout.

Le vrai obstacle : trois grammaires, pas trois tuyaux

Brancher un flux prend quelques jours. Faire accepter plusieurs milliers de références par trois opérateurs qui ne demandent pas les mêmes choses prend des semaines si vous l'abordez fichier par fichier. La raison est structurelle : sur ces plateformes, le modèle de données n'est pas global, il est défini par catégorie. Une perceuse et une paire de baskets ne réclament ni les mêmes attributs, ni les mêmes listes de valeurs.

Vous vous heurtez alors à trois murs successifs :

• La taxonomie — votre arborescence interne doit être rapprochée de celle de chaque opérateur. C'est ce rapprochement qui détermine quels attributs deviennent obligatoires. Tant qu'il n'est pas fait, vous ne savez pas ce qui vous manque.
• Le vocabulaire — une valeur libre saisie dans votre ERP ("bleu nuit", "inox brossé") doit tomber dans une liste de valeurs fermée côté marketplace. Les valeurs non reconnues sont rejetées ou ignorées silencieusement.
• Le contrôle à l'entrée — identifiant, format d'image, longueur de titre : les vérifications se font au moment de l'intégration, pas après. Un lot rejeté, c'est corriger puis resoumettre.

Le socle commun : ce qu'aucune marketplace ne pardonne

Avant de regarder les spécificités de chacun, huit blocs doivent être propres dans votre référentiel. Ce sont eux qui provoquent la majorité des blocages, tous canaux confondus.

• Un identifiant unique et stable — votre SKU, immuable, jamais réattribué, identique d'un canal à l'autre. C'est la clé qui rapproche une commande, un stock et une fiche.
• Un code-barres valide — GTIN/EAN dont le chiffre de contrôle est correct et qui correspond réellement au produit vendu. C'est aussi la clé de rattachement au catalogue existant des marketplaces : un EAN juste vous évite de recréer une fiche déjà présente. Le sujet est détaillé dans notre article sur la validation automatique des codes-barres.
• La marque, normalisée — une seule graphie par marque. "BOSCH" et "Bosch Professional" sont deux marques différentes pour un moteur de rapprochement.
• La référence fabricant — le MPN. Avec la marque, c'est le second couple d'identification utilisé quand le code-barres ne suffit pas.
• Une catégorie interne fiable — chaque référence rattachée à une famille unique. Sans cela, aucun mapping vers les taxonomies externes n'est automatisable.
• Un titre structuré — marque, gamme ou modèle et caractéristique distinctive, dans des champs séparés. Composé à partir de champs identifiés, il se recompose au format de chaque canal ; en texte libre, il ne se recompose pas.
• Des images conformes — une image principale détourée sur fond blanc, en haute définition, sans logo ni filigrane, plus des visuels secondaires. Les seuils varient par plateforme, mais 1 600 pixels sur le plus grand côté satisfait tout le monde.
• Poids et dimensions d'expédition — colis emballé, pas produit nu. Ils conditionnent les frais de port affichés et l'éligibilité à certains modes de livraison, et c'est le bloc le plus souvent absent des exports fournisseurs.

Ce qui change d'une plateforme à l'autre

Amazon, Fnac-Darty et Cdiscount reposent sur trois technologies distinctes, ce qui change la manière de s'y connecter et la forme des données attendues.

Amazon : un modèle de données par type de produit

Amazon ne publie pas une liste unique d'attributs obligatoires. Il expose, via SP-API, un schéma JSON par product_type : l'API Product Type Definitions retourne pour chaque type les attributs attendus, leurs formats et leurs contraintes. Ces exigences sont dynamiques — renseigner un attribut peut en rendre d'autres obligatoires. C'est le travail qu'automatise le module décrit dans notre article sur Amazon SP-API et Code2ASIN.

Deux points appellent une attention particulière. La hiérarchie parent-enfant d'abord : les déclinaisons (taille, couleur, capacité) se déclarent comme des enfants rattachés à un parent non achetable, avec un axe de variation (variation_theme). Si votre référentiel ne distingue pas déjà le modèle de ses variantes, vous ne produirez pas cette structure proprement. Le titre ensuite : depuis janvier 2025, Amazon applique à toutes les catégories une politique plus stricte — plafond de 200 caractères espaces comprises (plus bas dans certaines catégories textile), interdiction de répéter un même mot plus de deux fois, caractères spéciaux prohibés hors nom de marque. Un titre concaténé depuis des champs se met en conformité en une règle ; un titre libre se corrige référence par référence.

Côté visuels, l'image principale attend un fond blanc pur (RVB 255, 255, 255), le produit occupant au moins 85 % du cadre, aux formats JPEG, PNG, GIF ou TIFF. Le minimum est de 500 pixels sur le plus grand côté, mais il en faut 1 000 pour activer le zoom et 1 600 pour un rendu optimal.

Fnac et Darty : la logique Mirakl, produits et offres séparés

Les marketplaces Fnac et Darty sont opérées sur la technologie Mirakl. Conséquence utile : la même intégration ouvre l'accès à un large écosystème d'enseignes, sujet détaillé dans notre article sur le connecteur Mirakl et les 400 marketplaces accessibles avec un seul raccordement.

La spécificité à retenir est la séparation entre produit et offre. Le produit porte le contenu descriptif : titre, marque, description, catégorie, attributs techniques, images. L'offre porte les conditions commerciales : votre sku, le prix, la quantité, l'état du bien (state) et la classe logistique (logistic-class). Les deux sont reliés par un couple product-id / product-id-type, ce dernier précisant la nature de l'identifiant utilisé pour le rattachement.

Il faut donc savoir répondre, par référence : est-ce que je crée la fiche, ou est-ce que je pose une offre sur une fiche existante ? Fnac-Darty fonctionne avec un référentiel de fiches standardisées identifiées par EAN ou ISBN. Si le produit y figure, seule l'offre est nécessaire ; sinon, vous soumettez d'abord le produit avec les attributs et listes de valeurs définis par l'opérateur. Votre PIM doit produire les deux flux et savoir lequel déclencher.

Cdiscount : le passage à l'API REST Octopia

Cdiscount opère sa marketplace avec sa propre technologie, portée par sa filiale Octopia. L'ancienne API SOAP a été retirée progressivement en 2025 au profit d'une API REST : si votre intégration date de plusieurs années, vérifiez ce point avant la haute saison.

Sur le fond des données, deux règles structurent la préparation. Le rattachement par EAN est possible : si un autre vendeur a déjà créé la fiche, vous n'avez pas à fournir l'intégralité du contenu produit. Mais le mapping de catégorie reste obligatoire dans tous les cas, y compris en rattachement par EAN — beaucoup de vendeurs supposent l'inverse et bloquent là. À noter aussi : les produits à déclinaisons demandent une étape d'insertion dans le référentiel de variantes, même lorsque le produit existe déjà.

Un référentiel unique, des jeux d'attributs par canal

La tentation, quand on ouvre un troisième canal, est de créer un troisième fichier maître. C'est le début de la divergence : six mois plus tard, trois versions de la même description coexistent. L'alternative tient en trois principes.

• Un seul référentiel canonique — une valeur, une source. Le poids d'expédition d'une référence est une donnée unique, pas trois. Toute contradiction se résout une fois, à la source, et se propage partout.
• Des jeux d'attributs par famille — vous ne modélisez pas un catalogue générique, mais des familles qui portent chacune leurs attributs pertinents. C'est ce découpage qui dit, famille par famille, quoi alimenter pour chaque canal.
• La transformation à la sortie — le canal est une vue, pas un stockage. Le titre Amazon, le titre Fnac et le titre Cdiscount sont trois projections calculées à partir des mêmes champs source. Idem pour les catégories, les unités et les listes de valeurs.

Corollaire : les mappings sont des données à part entière, à stocker, versionner et maintenir. Les taxonomies évoluent, et un mapping obsolète produit des rejets en masse au pire moment.

Le contrôle avant envoi : ne publier que ce qui passera

Le modèle en place, l'objectif est de ne plus découvrir un problème de données côté marketplace. Trois mécanismes suffisent.

• Rendre les attributs obligatoires par famille et par canal — un même attribut peut être facultatif pour un canal et bloquant pour un autre. La règle se déclare une fois et s'applique aussi aux références créées demain.
• Mesurer la complétude par canal — un score global ne sert à rien pour arbitrer. Ce qui compte, c'est de savoir qu'une référence est prête pour Cdiscount mais pas pour Amazon, faute de deux attributs exigés par son type de produit.
• Bloquer la publication des fiches incomplètes — celles qui ne passent pas les règles du canal restent en attente, avec la liste des champs manquants.

À l'approche d'une haute saison, mieux vaut publier 800 références conformes que soumettre 2 000 fiches dont une partie reviendra en erreur.

Après la publication : rejets, performance, prix et stocks

La mise en ligne n'est pas la fin du travail. Trois boucles tournent en continu.

• Le suivi des rejets — chaque plateforme renvoie un statut d'intégration par ligne. Ces retours doivent remonter dans le PIM, rattachés à la référence concernée, plutôt que rester dans un back-office séparé.
• Les indicateurs de performance vendeur — taux d'annulation, retards d'expédition, délai de réponse, litiges. Propres à chaque opérateur, ils conditionnent votre visibilité, et une partie se joue en amont : un délai mal paramétré ou des dimensions fausses produisent mécaniquement des retards et des retours.
• La mise à jour des prix et des stocks — le flux le plus fréquent, et il doit être découplé du contenu : un stock change plusieurs fois par jour, une description quelques fois par an. Sur Mirakl, la séparation est native puisque l'offre est un objet distinct du produit ; sur Amazon, elle passe par les opérations de listing de SP-API.

Questions fréquentes

Dois-je créer les fiches produits ou me rattacher à celles qui existent ?

Rattachez-vous chaque fois que c'est possible : sur Fnac-Darty comme sur Cdiscount, le rattachement par EAN réduit le délai de mise en vente et le volume de données à fournir. La création se réserve aux références que vous êtes le premier à référencer.

Combien de temps faut-il pour préparer un catalogue à trois marketplaces ?

Cela dépend de l'état de départ des données, pas du nombre de canaux. Si les codes-barres sont valides, les marques normalisées et les familles cohérentes, ajouter un canal se résume au mapping des catégories et des listes de valeurs. Sinon, c'est la reprise du socle qui dicte le calendrier — et elle ne se fait qu'une fois.

Un connecteur suffit-il, ou faut-il un PIM ?

Un connecteur transporte des données, il ne les fabrique pas. Il enverra fidèlement à Amazon un catalogue auquel il manque les dimensions d'expédition, et Amazon le refusera. Le PIM sert à constituer le référentiel, à porter les jeux d'attributs par famille, à stocker les mappings et à bloquer ce qui n'est pas prêt. Les deux sont complémentaires : Pixee PIM compte 15 connecteurs e-commerce et marketplaces natifs, dont Amazon SP-API et Mirakl, ce dernier donnant accès à environ 400 places de marché avec un seul raccordement.