Un vendeur importe un chargeur « USB-C 65 W ». Le moteur le fusionne avec une fiche 45 W parce que marque, photo et titre se ressemblent. Pendant deux jours, son offre apparaît sur le mauvais produit, les acheteurs reçoivent une puissance différente et le support ne sait plus quelles commandes sont touchées.
Le problème n’est pas une simple mauvaise suggestion. Une fusion fausse les attributs, les prix comparés, les avis, le stock et les obligations produit. La correction manuelle sépare la fiche actuelle, mais elle ne restaure ni les décisions de modération ni les commandes déjà prises depuis l’association erronée.
Le vrai enjeu du matching catalogue dans une marketplace opérateur est de décider quand une offre décrit exactement une variante existante et quand le doute doit rester visible. Contre-intuitivement, réduire le nombre de doublons peut dégrader davantage le catalogue si le système privilégie le rappel au détriment de la précision.
Vous allez comprendre comment distinguer les objets, normaliser les signaux, générer et scorer des candidats, poser des seuils, organiser la revue puis corriger merge et split. Entrées, sorties, owners, instrumentation, monitoring, dépendances, file, retry et rollback rendent chaque association reproductible.
Définir la décision de matching
Nommer les sorties possibles
Le matching ne renvoie pas seulement oui ou non. Il peut relier à une variante, proposer un produit sans variante, créer un candidat canonique, envoyer en revue ou refuser pour information insuffisante. Chaque sortie possède un effet précis.
Le contrat indique si l’offre devient publiable, quels attributs sont hérités et qui possède la prochaine action. Un score élevé sans décision et sans effet ne résout rien dans le flux seller.
Optimiser le coût de l’erreur
Un faux positif fusionne deux objets différents ; un faux négatif conserve un doublon. Le premier peut tromper l’acheteur et contaminer avis ou conformité. Le second fragmente conversion et administration. Leur coût varie par catégorie.
La matrice attribue une tolérance à chaque population. Une pièce automobile ou un produit réglementé exige une précision supérieure à un accessoire décoratif. Le seuil n’est pas identique pour tous les catalogues.
La décision économique inclut aussi le trafic et la capacité de correction. Une offre sans vue peut attendre une revue, tandis qu’une offre qui reçoit mille visites par heure mérite un blocage prudent ou un examen prioritaire. Le coût d’un doublon reste mesuré : acquisition divisée, avis fragmentés et pages concurrentes. L’owner équilibre ces deux pertes avec un budget de revue explicite, pas avec un objectif abstrait de « catalogue propre ».
Séparer produit, variante et offre
Fermer le grain canonique
Le produit porte identité commune, la variante les propriétés qui changent l’achat, et l’offre les conditions seller : prix, stock, livraison et état. Une couleur ou une capacité peut être variante dans une catégorie, simple attribut dans une autre.
La taxonomie définit les axes discriminants par catégorie. Le matching vise la variante lorsque ces axes existent. Relier seulement au produit parent masque les différences que l’acheteur doit choisir.
Bundles, lots et reconditionné exigent un grain distinct. Deux unités du même produit ne constituent pas la même variante qu’une unité, même avec un GTIN composant identique. L’état peut rester une propriété d’offre si le produit canonique décrit le modèle neuf. Ces conventions sont testées sur achat, retour et comparaison afin que le matching ne simplifie pas un objet au prix d’une promesse commerciale fausse.
Préserver la déclaration seller
L’offre conserve titre, description, identifiants, images et attributs bruts. La liaison canonique ne remplace pas la source. Un désaccord reste consultable afin de comprendre si le seller, le produit ou la règle est erroné.
Chaque proposition porte offer_version. Une modification matérielle du seller invalide ou réévalue le match. Changer seulement le stock ne relance pas une décision produit inutile.
Qualifier les signaux
Hiérarchiser identifiants et attributs
GTIN, MPN, marque, modèle, dimensions, capacité, couleur et compatibilité n’ont pas la même force. Un identifiant valide peut être réutilisé ou faux ; un titre proche peut cacher une variante différente. La catégorie attribue fiabilité et caractère discriminant.
Les identifiants passent par format, check digit, namespace et source. Une correspondance exacte n’est forte que si marque et catégorie restent cohérentes. Les exceptions connues sont versionnées.
Le système traite les GTIN réutilisés, génériques ou contrefaits comme une population spécifique. Une fréquence anormale sur plusieurs marques réduit la confiance et ouvre une enquête seller. Le verdict du matching ne décide pas à lui seul d’une fraude. Il conserve le signal et isole l’offre afin que Trust et Catalogue appliquent leurs policies respectives sans confondre identité produit et comportement du compte.
Exploiter texte et image avec prudence
Le contenu descriptif aide à reconnaître modèle et unité, mais les termes marketing sont fréquents. L’image peut détecter un packaging ou une forme, sans prouver capacité ou composition. Ces signaux complètent les faits structurés.
Les embeddings et modèles gardent version, population et score. Ils ne deviennent pas une preuve opaque. Le reviewer voit les caractéristiques qui ont rapproché ou éloigné les objets.
Normaliser sans perdre la source
Unifier formats et unités
La normalisation sépare casse, accents, ponctuation, unités et synonymes. « 0,5 l » devient comparable à « 500 ml » tout en gardant valeur originale. Une conversion impossible produit inconnu, pas zéro.
Les dimensions citent axe et tolérance. Inverser longueur et largeur peut être acceptable pour un tapis, pas pour une pièce orientée. Les règles dépendent du type d’attribut.
La marque et le modèle utilisent un dictionnaire gouverné : aliases officiels, translittérations et changements de nom. Supprimer tous les espaces peut rapprocher deux références réellement différentes. Le normaliseur produit des tokens et une explication, puis le scorer garde la valeur canonique proposée. Toute nouvelle règle est rejouée sur les collisions historiques avant d’être publiée, avec un rollback vers le dictionnaire précédent.
Distinguer absent, inconnu et contradictoire
Absent signifie non fourni, inconnu signifie non interprétable, contradictoire signifie différent du candidat. Les trois états influencent le score autrement. Une donnée manquante ne devient jamais une correspondance.
Le pipeline conserve raw, normalized, rule_version et qualité. Les corrections de dictionnaire peuvent être rejouées. Elles n’écrasent pas l’entrée seller ni les décisions historiques.
Générer les candidats
Réduire l’espace de recherche
La génération filtre catégorie, marque, identifiants et attributs bloquants avant le ranking. Elle utilise plusieurs voies : exact ID, MPN-marque, tokens, voisinage vectoriel ou relations de compatibilité. Chaque voie indique sa provenance.
L’union déduplique par product_variant_id et garde le meilleur rang de chaque retriever. Une limite empêche mille candidats inutiles. Si aucun retriever ne trouve, alors la sortie création ou revue reste explicite.
La qualité du retriever se mesure par recall@k sur la vérité terrain : le bon candidat doit apparaître avant que le scorer puisse le choisir. Une mauvaise génération ne se corrige pas en assouplissant le seuil final. Les tableaux distinguent exact, lexical et vectoriel, puis montrent leur complémentarité. Une voie coûteuse peut être appelée seulement lorsque les signaux structurés ne produisent aucun candidat plausible.
Protéger tenant et catégorie
Un catalogue privé, un pays ou une marque sous restriction peut limiter les candidats. L’index applique ces frontières avant le ranking. Une offre d’un tenant ne découvre pas un produit confidentiel d’un autre.
Les migrations de taxonomie gardent mappings et version. Un candidat dans une ancienne catégorie peut être proposé seulement par une voie contrôlée. Le moteur n’élargit pas silencieusement tout l’espace lors d’un changement.
Calculer un score explicable
Combiner preuves et contradictions
Le score additionne signaux positifs et pénalités. Une contradiction sur puissance, taille ou référence peut bloquer malgré un titre très proche. Les règles critiques passent avant le score agrégé.
Le résultat expose matched_fields, mismatches, missing_fields et model_version. Un agent peut reproduire le verdict. Les poids sont calibrés sur une vérité terrain, pas choisis uniquement par intuition.
La calibration transforme le score en probabilité observée par catégorie et tranche. Un 0,9 ne signifie pas 90 % de justesse sans cette mesure. L’équipe trace reliability curve, précision au seuil et coût pondéré. Les exemples proches des bornes sont revus régulièrement. Lorsqu’un modèle change, les scores historiques gardent leur version et ne sont pas comparés comme s’ils appartenaient à la même échelle.
Comparer premier et second candidat
Un score de 0,94 est moins fiable si le second atteint 0,93. La marge entre candidats mesure l’ambiguïté. Un seuil absolu et un seuil de marge déterminent l’automation.
Par exemple, une correspondance à 0,96 avec GTIN exact, axes cohérents et marge de 0,15 peut être acceptée. À 0,91 avec marge de 0,01, elle rejoint la revue même si le seuil brut est dépassé.
Contractualiser la zone de doute
Créer trois zones de décision
Au-dessus du seuil haut et sans contradiction, le moteur lie. Sous le seuil bas, il refuse ou crée. Entre les deux, il demande une revue. Les bornes dépendent catégorie et voie de candidats.
Le doute a une durée et un effet seller. L’offre peut rester brouillon, être publiée isolément ou attendre selon risque. Le portail explique la donnée manquante au lieu d’afficher « matching en cours » sans échéance.
Limiter la file de revue
La capacité humaine est un input du système. La file priorise impact, volume, risque et âge. Un seuil trop prudent qui crée dix mille dossiers n’est pas une sécurité opérationnelle.
Si la file dépasse deux jours de capacité ou si plus de 20 % des revues confirment un même pattern, alors l’owner ajuste retriever, règle ou formulaire. Il ne baisse pas le seuil uniquement pour vider la queue.
Outiller la revue humaine
Comparer les différences utiles
L’écran place offre et candidat côte à côte, souligne axes discriminants, identifiants, images et sources. Il montre le second candidat. Le reviewer ne parcourt pas la fiche complète à la recherche de la cause.
Les actions sont lier, rejeter, créer, corriger une donnée ou escalader l’objet canonique. Chacune demande un reason code. Les raccourcis clavier ne doivent pas masquer la portée.
Séparer correction et verdict
Corriger une marque normalisée puis relancer n’est pas équivalent à forcer le match. L’écran conserve ces actions séparées. Un override cite approbateur, population et expiration éventuelle.
Les entrées sont offer_version, candidats, preuves et policy ; les sorties verdict, raison et effet. Catalogue Operations est owner. Instrumentation, SLA, file et audit suivent la reprise.
La qualité du reviewer est contrôlée sans chercher la vitesse seule. Un échantillon reçoit une seconde lecture, les désaccords sont arbitrés et les motifs génériques sont renvoyés. Si une personne confirme systématiquement le premier candidat, l’owner vérifie ergonomie, formation et charge. Les résultats deviennent de la vérité terrain seulement après un niveau de confiance défini ; sinon les biais humains entraîneraient le modèle suivant.
Protéger le produit canonique
Gouverner la création
Créer un produit exige un minimum d’attributs, une identité et une catégorie. Le moteur ne crée pas automatiquement depuis chaque offre rejetée. Les candidats proches restent visibles pour éviter une duplication au prochain import.
La provenance de chaque propriété est conservée. Un seller peut proposer une correction sans devenir automatiquement source d’autorité. Le steward décide selon policy et preuve.
Maîtriser l’héritage
Une offre liée hérite des propriétés canoniques utiles à la navigation, mais conserve ses faits commerciaux. Un changement de produit déclenche l’analyse des offres et commandes affectées.
Les attributs conflictuels peuvent bloquer publication ou rester seller-specific selon type. Le front ne choisit pas silencieusement la valeur la plus récente. Il lit une règle de priorité versionnée.
Corriger merge et split
Rendre le merge traçable
Fusionner deux produits crée une décision parent, un mapping et un manifeste d’offres, avis, médias et relations. Les identifiants redirigent vers le survivant sans disparaître. Les conflits sont résolus propriété par propriété.
Le merge commence en shadow puis sur une cohorte. Les commandes historiques gardent leur snapshot. L’index, le cache et les recommandations sont invalidés avec version.
Avant la fusion, une analyse d’impact compte offres, commandes ouvertes, avis, SEO, promotions, compatibilités et règles de conformité. La décision affiche les conflits qui ne peuvent pas être résolus automatiquement. Au-dessus du plafond de population ou en présence d’un litige actif, une double approbation est requise. Le manifeste permet à chaque consommateur de confirmer son traitement avant que l’ancien produit ne redirige.
Préparer le split et le rollback
Le split reconstruit les variantes, réattribue les offres et conserve le lien vers la fusion erronée. Il ne suffit pas de dupliquer une fiche. Avis et contenus sont répartis selon leur grain.
Les entrées sont merge_id, manifeste et règles ; les sorties nouveaux objets, mappings et anomalies. Le runbook prévoit dépendances, retry idempotent, monitoring et rollback. Toute commande impactée rejoint une file support.
Évaluer et surveiller le système
Construire une vérité terrain
Le jeu d’évaluation couvre catégories, marques, variantes proches, données manquantes, sellers et saisons. Deux reviewers tranchent les cas ambigus. Les désaccords enrichissent la policy au lieu d’être retirés du corpus.
La mesure suit précision, rappel, faux positifs critiques, couverture automatique et charge de revue. Elle segmente chaque voie de candidat. Une moyenne globale masque la catégorie dangereuse.
Détecter dérive et régression
Le monitoring observe distribution des scores, marge, zone de doute, taux d’override, splits et plaintes. Un changement de seller mix peut dériver sans release. Chaque signal possède seuil et owner.
Un canary compare ancienne et nouvelle version. Si un faux positif critique apparaît sur mille cas ou si la précision baisse de 0,5 point, alors le trafic revient à l’ancienne policy. Les décisions canary sont réconciliées.
Le shadow run enregistre les divergences sans modifier les offres. Elles sont classées : amélioration attendue, erreur de candidat, changement de score, seuil ou taxonomie. L’équipe examine la population et pas seulement le taux global. Si le nouveau moteur crée moins de doublons mais triple les revues sur la catégorie principale, alors l’ouverture reste limitée jusqu’à ce que capacité ou règle rende le coût soutenable.
Adapter la méthode et éviter les erreurs
Pour qui le matching catalogue convient
Il devient nécessaire lorsque plusieurs sellers décrivent les mêmes produits et que comparaison ou avis exigent une identité commune. Une petite marketplace commence avec identifiants exacts et revue humaine avant le modèle avancé.
Catalogue possède le grain et la policy, Data le scoring, Platform l’index, Operations la revue et les domaines les contraintes. Chaque catégorie a un owner et un jeu d’évaluation.
Erreurs fréquentes du matching
Fusionner sur titre, croire un GTIN sans contrôle, confondre produit et variante, traiter absent comme égal, ignorer le second candidat et baisser les seuils pour vider la file sont les erreurs majeures.
Une autre erreur consiste à mesurer uniquement les doublons supprimés. Enfin, un merge irréversible transforme chaque amélioration du modèle en risque catalogue. Le doute et le split font partie du produit.
Plan d’action pour industrialiser le matching
Semaines 1 à 4 : objets et baseline
La première semaine ferme produit, variante, offre et axes par cinq catégories. La deuxième prélève deux mille paires et construit la vérité terrain. La troisième normalise signaux ; la quatrième génère les candidats exacts.
Les tests couvrent même GTIN incohérent, MPN partagé, unité convertie, variante proche, attribut absent, mauvaise catégorie et tenant privé. Chaque cas possède verdict, preuve et coût d’erreur.
Semaines 5 à 8 : score et exploitation
La cinquième semaine calibre score et marges ; la sixième ouvre les trois zones et la revue. L’instrumentation suit précision, rappel, file, overrides, créations, merges et splits avec seuils et runbooks.
Les semaines sept et huit exécutent un canary, provoquent index indisponible, retry et rollback, puis réconcilient les offres. Le go exige zéro faux positif critique, une file tenable et un split rejoué par Operations.
Le paquet de run conserve taxonomies, dictionnaires, versions, corpus, seuils, fixtures, manifests et procédures de correction. Une personne extérieure au projet doit expliquer dix scores, reprendre une dead letter et séparer un merge erroné. La recette chronométrée vérifie que l’automation reste compréhensible après le départ de l’équipe projet.
La décision d’extension compare aussi charge de revue, délai seller et coût des corrections. Si la précision reste excellente mais que la file bloque une catégorie pendant trois jours, alors l’owner réduit la cohorte ou améliore les signaux d’entrée avant d’ouvrir davantage. En revanche, il ne baisse jamais le seuil d’un axe critique pour atteindre un objectif de débit.
- À faire d’abord : fermer grain, axes, signaux et coût des erreurs.
- À tester ensuite : candidats, contradictions, seuils, revue, merge, split et rollback.
- À différer : le modèle complexe tant que les identifiants exacts sont mal contrôlés.
- À refuser : toute fusion automatique sans preuve, marge et chemin de séparation.
Ressources complémentaires pour l’opérateur
Borner le premier périmètre
Le MVP marketplace avant ouverture aide à choisir les décisions catalogue indispensables.
Une première catégorie ouverte avec ses règles fournit une vérité terrain cohérente.
Structurer produit et revue
Le catalogue PIM marketplace pose taxonomie, attributs et modération.
Les écrans du back-office opérateur outillent comparaison, verdict et correction.
Conclusion : conserver le doute utile
Un matching fiable sépare produit, variante et offre, puis qualifie chaque signal avant de scorer.
Candidats, marge et zone de doute protègent le catalogue contre les fusions seulement plausibles.
Revue, merge traçable, split et évaluation rendent l’automation corrigible à mesure que le catalogue évolue.
Dawap peut vous accompagner pour structurer ce moteur dans votre marketplace opérateur.
