Deux vendeurs proposent le même lave-linge. Le premier corrige le titre, le second change une photo et chacun renseigne sa propre capacité. Le catalogue publie alors deux fiches presque identiques, tandis qu’une troisième page agrège un prix périmé. Le client hésite entre des copies et l’équipe merchandising ne sait plus quelle donnée corriger.
La duplication vient rarement d’un simple défaut d’import. Elle apparaît lorsque l’identité du bien, sa description et les conditions commerciales vivent dans le même enregistrement. Chaque nouveau vendeur recopie le produit ; toute correction doit ensuite traverser des clones dont les cycles de vie ne coïncident plus.
Le vrai enjeu d’une marketplace opérateur est de conserver une fiche produit commune sans retirer au vendeur la maîtrise de son prix, son stock et sa promesse. Contre-intuitivement, dédupliquer davantage ne suffit pas : il faut rendre les responsabilités explicites avant de rapprocher les données.
Vous allez comprendre comment séparer identités, attributs, offres, variantes et publications. Le modèle relie chaque valeur à un owner et une version ; matching, validation et événements restent rejouables. Le back-office arbitre les conflits et le monitoring détecte orphelins, divergences et projections en retard avant qu’ils n’atteignent l’acheteur.
Tracer la frontière produit-offre
Définir le produit indépendamment du vendeur
Le produit décrit ce qui est vendu : marque, modèle, nature, dimensions, composition, médias de référence et relations de variantes. Il existe même si aucune offre n’est active. Sa clé ne contient ni seller, ni prix, ni entrepôt. Cette indépendance permet de retirer un marchand sans faire disparaître la connaissance catalogue.
La fiche canonique n’est pas nécessairement une vérité figée. Elle possède sources, versions et statut éditorial. Fabricant, opérateur et vendeurs peuvent proposer des valeurs, mais une politique choisit celle qui sera publiée. Le produit garde donc une identité commune tout en conservant la provenance des contributions.
Réserver l’offre aux conditions commerciales
L’offre relie un vendeur, un produit et un marché. Elle porte prix, devise, stock, délai, état, garantie commerciale, condition et restrictions de livraison. Plusieurs offres peuvent pointer vers le même produit sans recopier son titre ou ses caractéristiques. Leur activation suit le contrat et la capacité propres au seller.
La frontière se décide champ par champ. Une garantie fabricant appartient au produit ; une extension vendue par un marchand relève de l’offre. Un poids physique est commun ; un poids facturé par le transport peut dépendre de l’expédition. Les cas ambigus reçoivent un owner et un exemple, jamais une colonne « divers ».
Stabiliser les identités
Créer des identifiants internes immuables
Produit, variante et offre reçoivent chacun un identifiant sans signification métier. Le SKU vendeur reste une référence externe dans un namespace seller ; le GTIN demeure un indice de rapprochement, pas la clé primaire universelle. Un changement de SKU ou une correction de code-barres ne recrée donc pas l’objet.
Le registre d’identités conserve anciennes références, source, période de validité et relation de remplacement. Une fusion ou une scission produit un événement. Commandes, avis et tickets historiques continuent de résoudre l’identité vue à l’époque, ce qui empêche une opération catalogue de rendre le service client aveugle.
Modéliser les liens plutôt que les recopies
Une offre pointe vers une variante vendable, laquelle appartient à un produit. Les relations sont versionnées et contraintes : une offre active ne peut pas viser une variante archivée ; une variante ne possède qu’un parent actif à un instant donné. Le modèle refuse les cycles et les rattachements sans preuve minimale.
Si une variante change de parent après correction, alors le lien précédent reste historisé. Les offres suivent la nouvelle identité après simulation du diff. La publication ne déplace pas silencieusement avis, prix ou commandes. Chaque consommateur reçoit l’événement de remapping et confirme la version qu’il sert.
Attribuer chaque donnée
Classer attributs communs et variables
Marque, gamme, notice et matière sont généralement communs. Couleur ou taille distinguent les variantes. Prix, quantité, état et expédition varient par offre. Une matrice associe chaque attribut à son grain, ses sources autorisées, son format et sa règle de résolution. Le schéma devient ainsi un contrat de responsabilité.
Cette classification protège aussi les performances. Une modification de stock n’a pas à créer une nouvelle version du produit complet ; une correction de matière ne doit pas réécrire toutes les lignes seller. Les projections peuvent assembler les grains au moment opportun sans transformer la base en document géant dupliqué.
Résoudre les sources concurrentes
Fabricant, PIM opérateur et vendeur peuvent fournir un même titre. La politique définit priorité, confiance, fraîcheur et possibilité d’override par catégorie. La valeur gagnante conserve ses candidates et la version de règle. L’équipe explique pourquoi une proposition a été retenue sans effacer les autres sources.
Scénario : le fabricant annonce une capacité de 8 kg et deux vendeurs 9 kg. Si l’écart touche un attribut réglementaire ou dépasse le seuil de tolérance, alors la fiche rejoint une revue. L’offre reste limitée tant que la preuve n’est pas réconciliée ; aucune majorité de vendeurs ne fabrique une vérité technique.
Modéliser les conditions vendeurs
Versionner prix, stock et promesse
Une offre courante est une projection de mouvements datés. Le prix cite devise, taxes, période et motif ; le stock indique quantité, réservation et fraîcheur ; la promesse relie mode de traitement, zone et délai. Écraser ces champs interdit de reconstruire ce que l’acheteur a réellement vu.
Les commandes conservent la version d’offre consommée. Un changement ultérieur n’altère ni le prix engagé ni la promesse. Pour l’affichage, un snapshot associe produit publié et offre éligible au même instant. Cette cohérence évite une photographie ancienne avec une condition commerciale nouvelle et incompatible.
Gérer état, occasion et reconditionné
L’état n’est pas toujours une simple propriété seller. Il peut imposer photos, grade, batterie, garantie ou défauts propres à l’unité. Le modèle crée alors une sous-identité d’exemplaire ou de lot reliée au produit de référence, puis l’offre pointe vers cette entité enrichie.
Dupliquer le produit complet pour chaque occasion rend les attributs communs divergents. À l’inverse, forcer toutes les différences dans l’offre empêche une fiche honnête. La règle est fonctionnelle : une donnée qui décrit durablement l’objet vendu appartient à l’exemplaire ; une condition de transaction reste dans l’offre.
Rattacher sans fusion hasardeuse
Construire des candidats de rapprochement
Le matching combine identifiants forts, marque normalisée, modèle, attributs discriminants et médias. Il produit des candidats avec raisons, pas une fusion opaque. Les clés faibles comme le titre ou la catégorie ne suffisent jamais seules. Chaque famille produit possède ses propres attributs de distinction.
La sortie contient produit proposé, score, contradictions et action : rattacher, créer, mettre en revue ou rejeter. Le score aide à prioriser, tandis que les règles bloquantes protègent des erreurs coûteuses. Un GTIN partagé entre packs différents déclenche une contradiction au lieu d’écraser la quantité.
Borner l’automatisation par le risque
Les rapprochements évidents et réversibles passent automatiquement ; les catégories sensibles ou les écarts matériels exigent une validation. Le seuil dépend du coût d’une mauvaise fusion, de la visibilité et de la capacité de rollback. Une file courte de cas informatifs vaut mieux qu’une revue de tous les imports.
Par exemple, si référence fabricant, marque et trois attributs discriminants concordent sans contradiction, alors le rattachement peut être automatique. Si le modèle diffère d’un caractère mais la puissance de 20 %, le seuil est refusé. L’opérateur compare preuves et population avant de confirmer ou créer un produit.
Représenter les variantes
Définir les axes vendables
Taille, couleur, capacité ou condition deviennent des axes lorsque l’acheteur les choisit et qu’ils déterminent stock ou offre. Une caractéristique informative ne crée pas automatiquement une variante. La taxonomie précise axes autorisés, valeurs, ordre d’affichage et combinaisons impossibles par catégorie.
Chaque variante possède une combinaison unique sous son produit. Une nouvelle couleur réutilise les attributs communs mais reçoit médias et identifiants nécessaires. Les offres visent la variante exacte. Le front peut regrouper les choix sans confondre un stock global avec la disponibilité de chaque combinaison.
Traiter les familles incomplètes
Un vendeur peut envoyer seulement deux tailles sur cinq ou une couleur inconnue. La famille canonique accepte une couverture partielle ; elle ne crée pas des offres fictives. Une valeur hors taxonomie rejoint le mapping ou la revue, avec la proposition source conservée pour correction.
Si une variante perd son parent pendant une migration, alors ses offres passent en état non publiable plutôt que d’être rattachées au premier produit ressemblant. Le runbook retrouve l’ancien lien, restaure le snapshot et rejoue le mapping corrigé. La reprise mesure commandes et pages potentiellement exposées.
Propager les changements
Publier des événements métier ciblés
Une correction produit émet identité, champs modifiés, ancienne et nouvelle version. Un changement d’offre publie seller, marché et condition concernée. Les consommateurs ne relisent pas tout le catalogue après chaque mouvement. Ils invalident uniquement index, cache ou flux dépendant des champs touchés.
Le pipeline reçoit en entrée événements versionnés et graphes de dépendance ; ses sorties sont manifests de projections et accusés de publication. Catalogue possède l’identité, commerce l’offre, plateforme la livraison technique. Journalisation, monitoring et checkpoints rendent chaque reprise idempotente et chaque destination en retard visible.
Empêcher les écrasements croisés
Un import vendeur ne réécrit jamais le document produit assemblé. Il met à jour sa contribution ou son offre avec contrôle de version. Les overrides opérateur vivent dans une couche distincte, portent motif et expiration. Une nouvelle source signale un conflit sans supprimer la correction active.
Les commandes utilisent une clé idempotente et un numéro de version attendu. En cas de concurrence, le service refuse l’écriture et recharge la cible ; il ne garde pas le dernier message par hasard. Cette règle protège notamment le prix et le stock lorsque batch et webhook se croisent.
Valider et modérer
Séparer validité produit et éligibilité offre
Une fiche peut être complète alors qu’une offre reste interdite pour stock, prix ou vendeur. Inversement, une offre techniquement saine ne publie pas un produit sans attribut obligatoire. Deux verdicts distincts évitent qu’un problème seller dépublie toutes les offres ou qu’une fiche vide passe grâce à un bon prix.
Les règles retournent motif, sévérité, population et action. Une correction produit réévalue les offres dépendantes sans remettre à zéro leurs contrôles autonomes. Le statut final assemble les verdicts et expose la cause dominante. Le seller manager sait qui doit agir et sur quel objet.
Organiser une file de conflits utile
La file priorise ventes potentielles, risque, ancienneté et nombre d’offres affectées. Elle groupe les occurrences partageant une cause. L’opérateur voit sources, diff, règle et aperçu public avant décision. Un choix peut devenir mapping réutilisable, override borné ou demande de preuve au vendeur.
Si plus de 50 offres actives dépendent d’un attribut contesté, alors la modification exige une simulation et une double validation. Sous ce seuil, un owner catalogue peut décider avec motif. Toute action conserve avant-après et propose un rollback de la population, pas une correction ligne par ligne.
Contractualiser API et événements
Séparer commandes et projections
Les API d’écriture adressent explicitement produit, contribution, variante ou offre. Elles valident le grain et refusent un prix dans la commande produit. Les API de lecture peuvent fournir une vue assemblée adaptée au front, mais cette commodité ne change pas le modèle de responsabilité sous-jacent.
Chaque commande contient acteur, source, version attendue et clé idempotente. La réponse indique objet modifié, nouveau numéro et contrôles déclenchés. Un traitement asynchrone fournit un identifiant de run. Le client suit son résultat sans supposer qu’un code HTTP accepté signifie déjà visible publiquement.
Versionner les contrats de données
Schémas, enums et règles de nullité évoluent avec compatibilité explicite. Ajouter un axe de variante ou retirer un champ offre demande une période de transition. Les producers et consumers publient leurs versions supportées ; des tests de contrat bloquent les ruptures avant déploiement.
Une quarantine conserve payload, erreur et tentative sans exposer de secret. La reprise lit le checkpoint, applique le nouveau mapping et compare la sortie au lot initial. Les dépendances externes possèdent timeout, retry borné et circuit breaker. L’owner du flux reçoit un runbook exploitable.
Outiller les décisions catalogue
Afficher une vue assemblée explicable
Le back-office montre produit, variantes et offres dans des niveaux distincts. Chaque valeur affiche source gagnante, contributions concurrentes et dernière décision. L’utilisateur passe du rendu public au champ puis au run d’import. Il n’a pas besoin d’interroger trois bases pour comprendre une incohérence.
Les droits suivent les objets : vendeur modifie ses offres et propose des données produit ; catalogue arbitre la fiche ; commerce gère les règles d’éligibilité. Une action de masse annonce la population, les dépendances et le diff. Les champs sensibles nécessitent justification et approbation proportionnées.
Prévisualiser fusion et scission
Avant une fusion, l’écran compare identités, attributs, variantes, offres, avis et commandes. Il signale collisions de SKU, axes incompatibles et données perdues. La simulation produit le nouvel arbre et les redirects. L’opérateur peut exclure un objet ou abandonner sans mutation partielle.
Une scission exige la même discipline. Les offres sont réparties selon preuves, puis les projections passent en canary. Si le taux de pages incohérentes dépasse 0,1 %, alors le rollback restaure les parents précédents. Deux sondes stables et la réconciliation des offres autorisent l’extension.
Mesurer et exploiter le modèle
Suivre santé et valeur catalogue
Les métriques suivent produits dupliqués, offres orphelines, taux de matching automatique, conflits par attribut, délai de revue et projections divergentes. Elles sont segmentées par catégorie, seller et source. Une moyenne globale ne révèle pas une taxonomie incapable de distinguer une gamme importante.
Le coût business relie erreurs à sessions, conversion, annulations et temps opérateur. Une fusion incorrecte sur un best-seller passe avant mille doublons sans trafic. Les seuils déclenchent des actions nommées : stopper un import, réduire l’automatisation, renforcer une règle ou ouvrir un chantier de source.
Préparer incidents et rollback
Le runbook part du symptôme public, retrouve version produit, offre et manifeste, puis identifie le dernier événement cohérent. Il prévoit limitation, restauration et réconciliation. Les snapshots immuables permettent de revenir sans supprimer les contributions reçues pendant l’incident.
Scénario : un mapping rattache 800 offres au mauvais produit. Si des commandes ont consommé la version, alors le checkout est limité pour la population et support reçoit la liste. Le rollback restaure les liens ; un nouveau run corrige le mapping et vérifie index, cache, flux et commandes avant clôture.
Adapter la méthode et éviter les erreurs
Pour qui le modèle produit-offre convient
Il devient essentiel dès que plusieurs vendeurs partagent des biens comparables ou qu’un catalogue alimente plusieurs canaux. Une plateforme de pièces uniques peut conserver une relation presque un-à-un, tout en séparant identité et transaction pour protéger commandes, prix et cycle de vie.
Catalogue possède produit et taxonomie ; seller operations les contributions ; commerce les conditions d’offre ; plateforme les contrats et projections ; support l’enquête. Chaque frontière reçoit owner et SLA. Le modèle ne réussit pas si une seule équipe devient le guichet de toutes les anomalies.
Erreurs fréquentes dans la séparation produit-offre
Copier le produit par vendeur, utiliser le SKU comme identité globale, mettre le stock sur la variante, écraser les contributions et fusionner sur le titre sont les erreurs les plus coûteuses. Elles rendent une correction locale globale ou une correction globale impossible à propager.
Une autre erreur consiste à normaliser sans conserver la source. Le catalogue semble propre jusqu’au premier litige. La valeur canonique doit rester explicable et réversible. Enfin, une vue front assemblée ne doit jamais devenir la nouvelle source réimportée, sous peine de créer une boucle de duplication.
Plan d’action pour séparer produit et offre
Semaines 1 à 4 : grains et responsabilités
La première semaine échantillonne cinquante fiches multi-vendeurs, remonte leurs sources et classe chaque champ. La deuxième dessine produit, variante, offre et contribution avec identifiants stables. Catalogue et commerce signent la matrice d’ownership, les cas ambigus et les règles de suppression.
Les semaines trois et quatre implémentent un flux pilote sur une catégorie : commandes séparées, registre d’identités, matching explicable et snapshots. Les tests couvrent SKU modifié, doublon GTIN, variante orpheline, prix concurrent et vendeur retiré. Le back-office expose le diff et la provenance.
Semaines 5 à 8 : migration et exploitation
La cinquième semaine migre une population en shadow et compare rendu, offres et commandes. La sixième active les événements ciblés, manifests et sondes publiques. L’instrumentation suit rattachements, divergences, latence et consommation de versions ; chaque alerte possède owner, seuil et dépendances.
Les semaines sept et huit ouvrent en canary, provoquent fusion erronée, source tardive et cache résistant, puis exécutent le rollback. Le go exige zéro offre orpheline, liens reproductibles et écart de projection sous 0,1 %. Les anciennes tables deviennent lecture seule avant retrait.
Le dossier final conserve modèle, dictionnaire, mappings, fixtures, décisions, dashboards et runbooks. Toute nouvelle donnée déclare son grain et son owner ; tout nouveau flux prouve idempotence et reprise. Les exceptions temporaires portent date d’expiration et population mesurable.
- À faire d’abord : classer les champs et stabiliser les identités avant de migrer.
- À tester ensuite : fusion, scission, vendeur retiré et publication partielle.
- À différer : l’automatisation des familles sans attributs discriminants fiables.
- À refuser : tout import qui mélange donnée produit et condition commerciale sans provenance.
Ressources complémentaires pour l’opérateur
Structurer catalogue et décisions
Le catalogue PIM marketplace aide à définir attributs, taxonomie et responsabilités.
Les écrans du back-office opérateur rendent provenance et arbitrages exploitables.
Éprouver le modèle sur un périmètre borné
Le MVP marketplace avant ouverture limite les premiers grains et flux.
La méthode pour ouvrir une première catégorie confronte le modèle à des offres réelles.
Conclusion : une identité, plusieurs offres
La séparation produit-offre protège une identité catalogue commune tout en gardant chaque engagement vendeur autonome.
Grains, sources et versions empêchent les corrections de se propager au mauvais niveau ou de perdre leur preuve.
Matching explicable, projections ciblées et rollback transforment la déduplication en capacité opérationnelle durable.
Pour construire ce socle, Dawap peut vous accompagner dans votre marketplace opérateur.
