Un acheteur saisit le modèle de sa chaudière et commande une pompe annoncée compatible. La marque et la référence commerciale correspondent, mais l’appareil a changé de connecteur au milieu de la même année de production. La pièce arrive, ne se monte pas et immobilise l’installation pendant que vendeur et fabricant se renvoient la responsabilité.
Le problème ne vient pas d’une recherche trop pauvre. Le catalogue a traité un nom de gamme comme une identité technique et une ressemblance comme une preuve. Le retour coûte transport, support et perte de confiance ; sur certaines catégories, une mauvaise pièce peut aussi endommager l’équipement.
Le vrai enjeu d’une marketplace de pièces détachées dans une marketplace opérateur est d’expliquer pourquoi une pièce convient à une version précise et quelles inconnues subsistent. Contre-intuitivement, afficher moins de résultats peut convertir davantage si chaque proposition réduit réellement le risque d’erreur.
Vous allez comprendre comment modéliser équipements et pièces, qualifier les sources, construire le graphe de fitment, guider l’acheteur puis corriger substitutions et retours. Entrées, sorties, owner, instrumentation, monitoring, dépendances, seuils, file, retry et rollback rendent la compatibilité exploitable.
Définir la décision de compatibilité
Nommer les verdicts possibles
COMPATIBLE confirme que les contraintes connues sont satisfaites pour l’équipement identifié. INCOMPATIBLE cite au moins une contradiction. CONDITIONAL demande une option, un adaptateur ou une opération. UNKNOWN indique que les données ne permettent pas de trancher.
Le front ne transforme jamais UNKNOWN en « compatible probable ». Il demande une information, propose une vérification experte ou montre des pièces universelles avec leurs limites. Chaque verdict possède reason codes et sources.
Évaluer le coût d’une erreur
Un faux positif provoque retour, panne ou danger ; un faux négatif cache une pièce utilisable et réduit la conversion. Les seuils dépendent de la catégorie. Un filtre esthétique tolère davantage d’incertitude qu’un composant électrique ou de freinage.
La matrice associe coût, fréquence, réversibilité et expertise nécessaire. Elle décide si une règle peut être automatisée, validée par vendeur, revue par expert ou laissée inconnue. Le volume ne justifie jamais d’abaisser une contrainte critique.
La décision commerciale tient aussi compte du délai d’immobilisation. Une erreur sur un consommable se corrige vite ; une pièce industrielle peut arrêter une ligne. Cette valeur priorise la revue et le support sans changer la vérité technique.
La policy définit enfin qui peut accepter une incertitude. Un particulier peut confirmer une information non critique, tandis qu’un composant soumis à sécurité exige une preuve qualifiée. Dans ce cas, la marketplace bloque la transaction plutôt que de transférer silencieusement la responsabilité vers une case cochée au checkout.
Modéliser machine, version et pièce
Fermer le grain de l’équipement
Marque et modèle ne suffisent pas toujours. L’identité peut inclure série, variante, année, motorisation, puissance, usine, firmware ou plage de numéros de série. La taxonomie définit les axes qui changent réellement le montage.
Le modèle canonique porte équipement, version et instance. L’instance est la machine de l’acheteur avec ses identifiants propres ; elle ne devient pas un produit public. Les données sensibles sont limitées au besoin de compatibilité.
Distinguer pièce, kit et offre
La pièce canonique décrit fonction et caractéristiques. Le kit regroupe composants nécessaires à une intervention. L’offre seller porte prix, stock, état, garantie et livraison. Une même pièce peut avoir plusieurs offres sans dupliquer les relations de compatibilité.
OEM, équivalent, adaptable, reconditionné et occasion sont des relations ou états explicites. « Compatible » ne signifie pas « identique ». Le catalogue montre les différences qui affectent montage, performance et garantie.
Qualifier les identifiants techniques
Hiérarchiser les références
Référence constructeur, MPN, EAN, numéro de série, référence distributeur et code atelier n’ont pas la même autorité. Un EAN peut identifier un emballage ; une référence OEM peut évoluer ou être réutilisée selon marché.
Chaque identifiant conserve namespace, issuer, normalized_value, valid_from et valid_until. La normalisation retire séparateurs autorisés sans fusionner des références distinctes. Les aliases sont versionnés et sourcés.
Traiter plages et suffixes
Un suffixe de référence peut coder couleur, tension ou révision. Une plage de série borne une évolution. Le parser expose chaque composante et sa règle, plutôt que de comparer des chaînes raccourcies par intuition.
Une valeur ambiguë rejoint une revue. Le système montre les candidats et contradictions. Une correction d’alias est rejouée sur l’historique des collisions avant publication, avec rollback vers le dictionnaire précédent.
Les références contrefaites ou surutilisées sont détectées par fréquence, marques et vendeurs. Ce signal ouvre une enquête séparée ; il ne décide pas seul de la compatibilité ni de la fraude.
Structurer les contraintes de montage
Modéliser dimensions et interfaces
Diamètre, longueur, pas de vis, tension, puissance, connecteur, protocole, position et tolérance deviennent des attributs typés avec unité. Une valeur absente reste inconnue ; elle n’est jamais égale à zéro ni à une valeur par défaut.
Les axes ont direction et tolérance. Une pièce de 10 mm avec tolérance de 0,1 ne correspond pas à 10,5. Les conversions d’unités conservent la valeur source et la précision.
Exprimer les conditions composées
Certaines pièces conviennent seulement avec un moteur, un châssis et une option. La règle combine AND, OR, exclusions et plages de série. Elle reste lisible par un expert, pas enfermée dans une expression opaque.
Les dépendances comme adaptateur, joint ou logiciel sont des prérequis visibles. CONDITIONAL cite le composant manquant et permet de construire un kit. Le checkout ne cache pas la condition dans une note vendeur.
Construire le graphe de compatibilité
Créer des relations versionnées
La relation relie part_id, equipment_version_id, verdict, conditions, source et policy_version. Elle possède date d’effet et statut de validation. Un changement ne supprime pas l’ancienne relation utilisée par les commandes historiques.
Les relations peuvent être directes ou héritées d’une version parent, mais l’héritage s’arrête devant une contradiction. Une compatibilité avec une gamme ne descend pas automatiquement vers toutes les sous-versions.
Propager avec prudence
Une règle peut générer des candidats depuis attributs ou supersessions. Le moteur conserve le chemin de preuve et le niveau de confiance. Une relation inférée n’est publiée qu’après seuil ou revue selon risque.
Le graphe détecte conflits : même paire compatible et incompatible, cycle de remplacement ou condition impossible. Les anomalies bloquent la relation concernée et rejoignent une file avec owner.
Le monitoring suit croissance, conflits, relations sans source et versions orphelines. Une importation qui multiplie par dix les compatibilités déclenche un canary avant diffusion aux acheteurs.
Les règles génératives sont évaluées sur un corpus comprenant vrais positifs, contradictions proches et cas incomplets. La précision est mesurée par catégorie et source. Si une règle améliore la couverture mais introduit un faux positif critique, alors elle reste en shadow jusqu’à correction ou réduction de son périmètre.
Gouverner sources et preuves
Classer l’autorité des sources
Catalogue constructeur, documentation technique, mesure atelier, distributeur et déclaration seller sont hiérarchisés par catégorie. La source conserve version, date, périmètre et fichier. Une affirmation commerciale ne vaut pas bulletin technique.
Deux sources contradictoires ouvrent une revue. L’expert choisit, borne ou laisse UNKNOWN avec justification. La décision n’écrase pas les preuves, afin qu’une mise à jour puisse être réévaluée.
Permettre les corrections seller
Le vendeur propose relation, preuve et commentaire. Il ne publie pas directement une compatibilité critique. Le back-office montre impact estimé sur offres, trafic et commandes avant validation.
Les entrées sont paire, faits, sources et policy ; les sorties sont verdict, conditions et prochaine revue. Catalogue possède le grain, l’expert métier le verdict et Operations la file. Chaque action garde reason code.
La file priorise trafic, commandes ouvertes, gravité et ancienneté. Une relation sans visite peut attendre, tandis qu’une pièce déjà commandée déclenche une analyse immédiate. Plutôt que d’approuver en masse les dossiers anciens, l’owner recherche la source ou la règle qui produit leur accumulation.
Identifier l’équipement de l’acheteur
Proposer plusieurs voies d’identification
L’acheteur peut saisir référence, scanner une plaque, choisir marque-modèle-version ou retrouver un équipement enregistré. L’interface confirme les attributs discriminants avant de filtrer. Une reconnaissance OCR incertaine demande validation.
Le garage ou acheteur B2B peut gérer un parc avec plusieurs instances. Les droits limitent les personnes qui voient séries et historique. La marketplace conserve seulement les données nécessaires au service.
Gérer l’équipement inconnu
Si la version reste ambiguë, le parcours pose une question qui sépare réellement les candidats : connecteur, puissance, date ou photo ciblée. Il n’affiche pas vingt champs dès le début.
Une demande experte réunit informations déjà saisies et photos, avec SLA et statut. Le support ne recommence pas le questionnaire. Le verdict enrichit le dossier seulement après validation de sa portée.
Le formulaire protège aussi contre une confiance excessive dans l’image. Une photo peut confirmer un connecteur ou une plaque, mais elle ne prouve pas une option interne invisible. L’expert distingue fait observé, déclaration acheteur et hypothèse, puis demande la donnée déterminante avant de rendre le verdict.
Rechercher et expliquer le résultat
Filtrer avant de classer
La recherche génère des candidats par référence, fonction et attributs, puis élimine les incompatibilités prouvées. Le ranking classe disponibilité, qualité, prix et délai uniquement parmi les résultats dont le verdict autorise l’achat.
Un score lexical élevé ne compense jamais une tension ou dimension contradictoire. Les résultats UNKNOWN sont séparés et demandent vérification. Ils ne se mélangent pas aux pièces confirmées sous un même badge.
Expliquer la compatibilité
La fiche montre l’équipement sélectionné, les contraintes satisfaites, la source et les conditions. Elle indique également ce qui n’a pas été vérifié. L’acheteur peut changer de machine sans conserver un résultat précédent.
Par exemple, « compatible avec série 4000 après janvier 2022, adaptateur A requis » est actionnable. « Convient généralement » ne protège ni la décision ni le support. L’explication fait partie du snapshot de commande.
Figer la compatibilité à la commande
Capturer le verdict et sa source
La ligne conserve equipment_version, part_version, relation_id, conditions, sources et choix acheteur. Une évolution du graphe ne réécrit pas le contrat. Le support retrouve exactement l’information affichée au checkout.
Le stock et l’offre restent seller-specific. Changer de vendeur ne change pas la pièce canonique, mais peut modifier état, accessoires inclus ou garantie. Le checkout revalide ces différences avant confirmation.
Traiter les inconnues explicitement
Si l’acheteur poursuit malgré un verdict conditionnel autorisé, son choix est enregistré avec l’explication. Pour une contrainte critique, le système bloque et propose une revue. Une case générique de décharge ne remplace pas la preuve.
Les commandes en attente conservent prix et disponibilité pendant une durée bornée. Après verdict, elles reprennent sans ressaisie si aucun fait matériel n’a changé. Sinon l’acheteur confirme le nouveau contexte.
Gérer remplacements et supersessions
Distinguer successeur et équivalent
Une supersession constructeur indique qu’une référence remplace une autre, parfois sous conditions. Un équivalent tiers offre une alternative sans devenir le successeur officiel. Le graphe conserve direction, date et preuve.
Le remplacement peut nécessiter kit ou adaptation. Le système ne substitue pas automatiquement au picking si le snapshot commande porte l’ancienne pièce. Il demande l’accord de l’acheteur lorsque promesse ou prix change.
Préparer rollback et correction
Une relation erronée est désactivée, les pages et caches invalidés, puis les commandes concernées identifiées. Le manifeste cite offres, paniers, commandes ouvertes et livraisons. Les effets historiques restent visibles.
La correction peut annuler, proposer une alternative ou ouvrir un retour prépayé. Le retry est idempotent. Une commande déjà corrigée ne reçoit pas une seconde notification lorsque le job est rejoué.
Le rollback de l’import restaure la version précédente du graphe, sans réactiver une relation explicitement invalidée pour sécurité. Les exceptions critiques ont priorité sur le rollback massif.
Mesurer retours et corrections
Construire une boucle de vérité
Les retours distinguent incompatibilité prouvée, erreur d’identification, mauvaise installation, pièce défectueuse et changement d’avis. Le motif seul ne modifie pas le graphe ; il ouvre un dossier avec preuves.
Photos, diagnostic et référence reçue sont rapprochés du snapshot. Un échantillon expert confirme les patterns. Les décisions corrigent relation, fiche, parcours ou vendeur selon la cause réelle.
Piloter qualité et coût complet
Le tableau suit conversion après sélection d’équipement, taux UNKNOWN, retours incompatibles, délai de revue, substitutions et support. Il segmente catégorie, source, vendeur et version.
Une baisse des retours avec effondrement des résultats n’est pas un succès. L’owner équilibre couverture et précision avec coût de retour, immobilisation, marge et confiance. Les seuils critiques restent non négociables.
La boucle surveille également les vendeurs dont les retours incompatibles dépassent le niveau de la catégorie. Le diagnostic compare mauvaise relation, offre mal rattachée, substitution au picking et conseil support. La correction cible alors catalogue, vendeur ou opération au lieu de dégrader toutes les relations similaires.
Adapter la méthode et éviter les erreurs
Pour qui cette architecture de compatibilité convient
Elle devient nécessaire dans l’automobile, l’industrie, l’électroménager, l’énergie ou l’électronique dès que modèle seul ne suffit pas. Une petite marketplace commence avec une catégorie et des références constructeur exactes.
Catalogue possède les objets, experts les règles, Search le filtrage, Sellers les preuves, Operations les revues et Support les dossiers. Chaque catégorie a un owner et un jeu d’évaluation.
Erreurs fréquentes des pièces détachées
Matcher sur titre, ignorer suffixes, propager une relation de gamme, confondre équivalent et successeur et afficher UNKNOWN comme compatible sont les erreurs majeures. Un résultat abondant peut masquer un catalogue dangereux.
Une autre erreur consiste à corriger depuis le motif de retour sans preuve. Enfin, une compatibilité non figée à la commande empêche de défendre le conseil donné. La provenance reste indispensable.
Plan d’action pour lancer les pièces détachées
Semaines 1 à 4 : objets et corpus
La première semaine ferme équipements, versions, pièces et axes. La deuxième normalise références. La troisième collecte mille relations prouvées et contradictions. La quatrième construit graphe, verdicts et tests.
Les scénarios couvrent suffixe, série, plage de dates, option, unité, condition, kit, UNKNOWN, supersession et conflit. Chaque cas attend verdict, raison, source et action acheteur.
Le dossier de sortie conserve taxonomie, mappings, corpus, sources, seuils, files et procédures. La recette finale tire une commande historique, reconstruit le verdict affiché et simule une correction après livraison. Elle vérifie ainsi que le savoir reste dans le système et non dans la mémoire du seul expert initial.
Semaines 5 à 8 : parcours et pilote
La cinquième semaine ouvre identification et recherche. La sixième fige le snapshot et outille la revue. La septième lance un canary vendeur ; la huitième provoque import erroné, correction et rollback.
Les entrées sont équipements, pièces, sources et policies ; les sorties sont relations, verdicts, dossiers et manifestes. L’instrumentation suit couverture, conflits, UNKNOWN, retours et file. Le runbook nomme owners.
Le go exige zéro faux positif critique sur le corpus, sources accessibles, reprise sans ressaisie et rollback réconcilié. Une personne extérieure doit expliquer dix verdicts et corriger une relation contradictoire.
Si plus de 3 % des achats confirmés reviennent pour incompatibilité ou si le p90 de revue dépasse deux jours, alors la catégorie n’est pas étendue. L’équipe renforce les données avant d’augmenter l’offre.
- À faire d’abord : fermer grain, identifiants, contraintes et autorité des sources.
- À tester ensuite : verdicts, parcours, snapshot, substitution, retour et rollback.
- À différer : l’inférence large tant que les relations exactes restent fragiles.
- À refuser : toute compatibilité critique sans raison, source et version.
Ressources complémentaires catalogue
Borner le premier périmètre
Le MVP marketplace avant ouverture aide à choisir les verdicts indispensables.
La méthode pour ouvrir une première catégorie fournit un terrain cohérent.
Structurer catalogue et opérations
Le catalogue PIM marketplace gouverne objets, attributs et preuves.
Les écrans du back-office opérateur réunissent relation, verdict et correction.
Conclusion : vendre une preuve, pas une ressemblance
Une marketplace de pièces fiable sépare équipement, version, pièce et offre avant de promettre une compatibilité.
Contraintes typées, graphe versionné et sources hiérarchisées rendent chaque verdict explicable jusqu’au checkout. Chaque correction peut ainsi retrouver précisément les commandes concernées.
Snapshot, substitutions, retours et monitoring permettent de corriger sans effacer le conseil donné à l’acheteur. La marketplace peut alors identifier les commandes affectées, proposer une solution proportionnée et expliquer la source qui avait fondé le verdict initial. Cette traçabilité protège aussi le vendeur lorsque la donnée erronée provenait d’un référentiel tiers.
Dawap peut vous accompagner pour structurer cette verticale dans votre marketplace opérateur.
