La pièce convient-elle ? Bien lire référence OE, référence croisée, affectation véhicule et contrôle VIN

La question « la pièce convient-elle ? » décide, dans le commerce comme à l’atelier, des retours, des reprises et des réclamations, et une mauvaise réponse n’apparaît le plus souvent qu’au montage. Les données censées étayer la réponse se ressemblent à s’y méprendre : une référence croisée, une référence successeure, une liste de types de véhicules, une liste de pièces pour un VIN, un fits=true. Elles disent pourtant des choses différentes, et seule une partie se rapporte à un véhicule. Cet article classe six données selon ce qu’elles prouvent pour un véhicule concret et montre où la pièce elle-même doit encore être contrôlée. La manière dont ces champs alimentent un article est décrite dans De la référence OE à l’article prêt pour la marketplace ; il s’agit ici de la décision avant la vente, la commande ou le montage.

Pourquoi le modèle et le code type ne suffisent pas

Le raccourci évident est le modèle : « convient à la série X, année Y ». Il ne mène pas loin, et les raisons figurent déjà dans le droit de la réception par type. Selon l’article 3, point 32, du règlement (UE) 2018/858, un type de véhicule est un groupe de véhicules partageant au moins les caractéristiques visées à l’annexe I, partie B ; selon cette même partie B, chaque type comprend au moins une variante et une version. Pour les voitures particulières de catégorie M1, l’annexe I, partie B, fixe ce que ces niveaux doivent avoir en commun. Niveau de finition, options, code moteur et modifications en cours de production n’en font pas partie. Deux véhicules de la même version peuvent donc nécessiter des pièces différentes — et le code type allemand désigne un type de véhicule, pas le véhicule individuel. Pour la logique d’ensemble, voir Réception par type, homologation et attestation : quel papier signifie quoi.

Niveau référence : références croisées et rechange indépendante

GET /parts/oe/{oeNumber} renvoie sous references les références et références croisées confirmées, regroupées par fabricant, et les fusionne dans referenceNumbers.oe_oem_reference_numbers, y compris la référence confirmée elle-même. GET /parts/oe/{oeNumber}/aftermarket-references ajoute les références des fabricants indépendants. Les deux listes répondent à la question de savoir sous quelles références une pièce est tenue ou recherchée — aucun véhicule n’y figure. La description du service le dit expressément : une référence adaptable ne garantit ni compatibilité technique, ni interchangeabilité, ni ajustement, ni aptitude, et une liste vide est une réponse réussie. L’erreur typique en boutique est donc une liste « convient aussi à » construite à partir de références croisées. Pourquoi une référence croisée renvoie à une application et pas forcément à une pièce identique est expliqué dans Référence OE : bien lire une référence d’origine ; le versant marché est décrit dans IAM : le marché indépendant et la place des démolisseurs.

Remplacement : l’arête a un sens

replacementChain contient des arêtes de remplacement confirmées, directes et orientées : from est remplacé par to. Une liste vide signifie qu’aucun remplacement orienté n’est documenté. L’arête parle de références, pas d’un véhicule, et elle est documentée dans le sens de la flèche. Conclure de « B remplace A » que A convient partout où B est monté revient à lire l’arête à contresens ; elle ne documente pas cela. Même dans le sens de la flèche, elle ne garantit, selon la description du service, ni l’interchangeabilité ni l’ajustement. Pourquoi un remplacement ne vaut pas toujours dans les deux sens est expliqué dans Référence OE : bien lire une référence d’origine. Point important en pratique : le contrôle du panier intègre déjà les références de remplacement documentées. fits=true est renvoyé lorsque la référence contrôlée elle-même ou une référence de remplacement documentée figure dans la liste de pièces du véhicule. Par ligne, la réponse n’indique toutefois que oe et fits, et non la manière dont la correspondance a été établie. Dès qu’un remplacement peut entrer en jeu, l’indice et les connecteurs sont donc à contrôler sur la pièce.

Niveau type : l’affectation véhicule et ses critères

fitment contient des affectations à des types de véhicules : par entrée un vehicleTypeKey et les criteria documentés. C’est la première donnée liée à un véhicule, mais au niveau du type. Les critères sont la partie qui se perd le plus facilement lors d’un transfert : l’exemple documenté de l’API indique pour un type de véhicule le critère « Aerodynamikpaket » (pack aérodynamique) et aucun pour un autre. Ne reprendre que les types transforme une affectation restreinte en affectation générale. Si le véhicule remplit le critère, fitment ne le dit pas ; les équipements identifiés sont renvoyés par le rapprochement véhicule GET /vin/{vin}/vehicle avec includeEquipments, dans la mesure où ils ont été identifiés. Selon le contrat, une liste fitment vide n’est pas une affirmation sur les véhicules non documentés — elle ne signifie pas « ne convient à rien ».

Niveau véhicule : liste de pièces du VIN et contrôle du panier

Ce n’est qu’avec le VIN que le véhicule individuel devient le point de départ. GET /vin/{vin}/parts renvoie les positions OE identifiées pour le VIN ; matchLevel décrit la portée du résultat, car même une liste établie pour un VIN peut ne contenir que des candidats au niveau du type de véhicule. Une missingCategories non vide signifie que la liste de pièces est incomplète. La lecture des trois valeurs de matchLevel est détaillée dans Du VIN à l’analyse de rentabilité : la voie véhicule. POST /vin/cart-check pose la question dans l’autre sens : il prend d’une à 30 positions OE et les contrôle face au VIN — avec mode=type au niveau du type de véhicule, avec mode=vehicle pour le véhicule concret. La réponse conserve l’ordre et les doublons de la saisie et porte une seule fois complete : la liste de pièces exploitable était-elle complète.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: <IDEMPOTENCY_KEY>' \
  -d '{"vin":"TAPSANDBX00000001","country":"de","mode":"vehicle","oeNumbers":["SBX0001A","SBX0002B"]}' \
  'https://api.tapinomahub.com/vin/cart-check'

L’ordre des contrôles au quotidien

1. Clarifier la référence. GET /parts/oe/normalize répond par matched, unresolved, ambiguous ou invalid. Seul matched poursuit sans question ; le paramètre facultatif manufacturer transmet le contexte constructeur. Si l’on ne dispose que d’une désignation, d’une étiquette ou d’une référence client, POST /parts/identify détermine des références OE possibles et distingue matched, candidates et unresolved — un candidat n’est pas encore une correspondance.
2. Situer la pièce. Appeler GET /parts/oe/{oeNumber} et ranger references, fitment et replacementChain dans des champs distincts. C’est la seule façon de dire ensuite sur quelle donnée repose une indication. 404 oe_part_not_found signifie : aucune correspondance confirmée — le champ reste alors vide.
3. Contrôler face au véhicule. Envoyer toutes les lignes ensemble à POST /vin/cart-check, avec mode=vehicle pour une commande destinée à un véhicule précis. Si le service répond 202, GET /vin/cart-check/jobs/{jobId} renvoie le même format de résultat une fois terminé.
4. Classer le constat. Trois issues au lieu de deux : prouvé, exclu, ouvert. Un fits=false avec complete=false reçoit un statut propre dans votre système et ne s’affiche pas comme « ne convient pas ». Les lignes ouvertes sont examinées de façon ciblée : consulter la liste de pièces et le matchLevel du VIN, confronter les criteria de l’affectation à l’équipement du véhicule et poser au client une question précise — sur la caractéristique nommée dans criteria, par exemple — plutôt que « est-ce que ça convient ? ».
5. Confirmer sur la pièce et enregistrer la preuve. Comparer référence, indice, côté et connecteurs sur la pièce en main. La donnée qui porte la décision — fits=true avec mode et complete, une affectation avec critères ou le contrôle visuel de la pièce — appartient à la ligne de commande. En cas de réclamation, c’est la réponse à la question de savoir sur quoi l’on s’est appuyé.

Où la pièce doit encore être contrôlée

• Équipement et options. Une affectation avec criteria ne vaut que si le véhicule remplit le critère. La disponibilité des équipements identifiés dépend de la source.
• Côté et position de montage. Des pièces symétriques pour la gauche et la droite sont des pièces différentes. Le contrôle dit si une référence appartient au véhicule — savoir si le côté commandé est le bon est une autre question. Exemples dans Projecteurs : la variante compte plus que le modèle.
• Modifications du véhicule individuel. Réparations, transformations ou remplacement antérieur d’une pièce peuvent limiter le résultat. Pour le montage, c’est la pièce réellement montée qui compte.
• Variantes de moteur et de boîte. Les pièces périphériques diffèrent selon l’organe ; le code fait partie du contrôle — voir Code moteur : l’identifiant qui distingue les variantes et Boîtes de vitesses : codes, état et la phrase qui évite les retours.
• Électronique. Une référence concordante ne dit rien de la nécessité de coder ou d’adapter un calculateur dans le véhicule — voir Calculateurs d’occasion : codage, antidémarrage, annonce.
• Pièces d’occasion. On contrôle la référence, pas l’exemplaire. Seul le marquage sur la pièce montre si celle proposée porte cette référence et cet indice.

L’intégration du contrôle dans les systèmes existants est décrite sur les pages consacrées aux logiciels d’atelier, aux marketplaces et systèmes de boutique et à la gestion commerciale. Tous les champs et codes d’erreur figurent dans Vérifier un panier OE avec un VIN et dans la documentation développeur.