E-commerce
12 juillet 2026
« J'ai besoin de la charnière droite pour mon modèle 2021. » « La pièce 14 sur le schéma, c'est quelle référence ? » « Je ne trouve pas mon numéro de série, pouvez-vous quand même confirmer ? » Ces questions arrivent des mois ou des années après l'achat, quand le catalogue spare compte des centaines de SKU et des révisions incompatibles.
iFixit rappelle que le lookup modèle avant commande pièce évite les erreurs sur smartphones, consoles et électroménager (iFixit, compatibility checker).
Ce guide #344 formalise le chatbot IA pièces détachées : identifier le modèle, croiser compatible_models, proposer le SKU spare exact sans halluciner une référence. Il complète support spare ops (#343) (policy, macros humaines) avec l'angle cas d'usage IA pour catalogues techniques et références complexes.
Sommaire
Pourquoi automatiser le lookup pièces détachées par bot ?
Une mauvaise pièce commandée coûte un retour, un ticket SAV supplémentaire et parfois un client perdu. Sur un catalogue spare de 400 SKU, l'agent humain ne peut pas mémoriser chaque matrice de compatibilité.
Trois risques sans bot spare structuré
Hallucination ref : LLM invente une pièce compatible
Temps agent : 10-18 min de lookup manuel par ticket
Wrong part rate : retour spare incompatible, litige
Le règlement UE sur l'écoconception renforce le droit à la réparation et la disponibilité pièces pour certains produits (UE, ESPR écoconception).
Angle #344
Le #343 documente policy spare, macros SPARE et workflow agents. Le #344 définit le bot dédié lookup référence spare avec data Shopify, arbres spare_* et garde-fous anti-erreur.
Moment du parcours
Post-achat J+30 à J+1825. Client sait quelle pièce remplacer ou cite un numéro sur schéma exploded. Bot confirme compatibilité avant lien checkout.
Exemple DTC
Marque électroménager : 95 tickets spare/mois, lookup agent 14 min moyenne, wrong_part_rate 19 %. Après bot spare_compat_check + metafields : 74 % auto-résolus, wrong_part_rate 5 %, temps agent spare -58 %.
Catalogues techniques
Mobilier modulaire, outdoor, vélo, lunettes, petit électronique : même nom marketing, révisions v1/v2/v3 incompatibles. Le bot lit la data, il ne devine pas.
En quoi diffère-t-il du support spare et des autres bots ?
Sept contenus voisins, sept rôles.
Support spare ops (#343)
Guide #343 : policy, macros SPARE, KPI wrong_part_rate côté équipe. Le #344 implémente la couche IA lookup référence.
Diagnostic panne (#342)
Diagnostic (#342) : qualifie la panne. Le #344 intervient quand la pièce à remplacer est identifiée ou quand le client demande directement une ref spare.
Compatibilité produit (transverse)
Compatibilité produit : matrice générale pré-achat. Le #344 approfondit catalogue spare post-achat et part_number.
Électronique pré-achat (#148)
Électronique (#148) : aide choix produit neuf. Le #344 = pièce détachée, pas produit complet.
Bot manuels (#230)
Bot manuels (#230) : PDF notice. Le #344 lie manuel + schéma exploded + SKU spare commandable.
Grand catalogue (#87)
Assistant grand catalogue (#87) : recherche produit large. Le #344 filtre sur collection spare-parts et compatible_models strict.
Promesse #344
Intents spare_*, arbre lookup modèle, data metafields, anti-hallucination ref, lien PDP spare, handoff si doute, KPI bot wrong_part.
Enchaînement #342 → #344
Diagnostic panne identifie part_number probable → bot spare confirme compatible_models + stock → lien commande. Payload handoff inclut modèle + ref validée.
Quels intents spare le bot doit-il classifier ?
Cartographier les intents spare parts bot avant construction des flows.
Dix intents spare post-achat
spare_catalog : vendez-vous des pièces détachées ?
spare_compat_check : cette ref est-elle compatible mon modèle ?
spare_model_lookup : où trouver mon numéro modèle ?
spare_part_number : pièce N sur schéma → SKU ?
spare_available : stock et délai pièce X
spare_oos : rupture, date réappro
spare_obsolete : pièce arrêtée, alternative
spare_install : guide montage pièce
spare_wrong_part : pièce reçue incompatible
spare_warranty : pièce gratuite sous garantie
Champs session obligatoires
model_id, revision, spare_sku_candidate, compatible_confirmed (bool), part_number_schema, stock_status, order_id si post-achat. Voir taxonomie (#135).
Mining tickets 90 j
Export « pièce détachée », « compatible », « référence », « schéma », « modèle ». Regrouper par SKU parent top 20. Prioriser flows spare sur 80 % volume.
Verbatims prioritaires
« Charnière rechange modèle X », « pièce 14 exploded view », « numéro série illisible », « même produit 2020 vs 2022 compatible ? ». Cinq formulations couvrent 70 % des tickets spare DTC équipement et mobilier.
Distinction spare vs repair
Intent spare_order = client commande pièce DIY. repair_request (#341) = atelier répare. Bot route repair si client ne veut pas monter seul.
Comment construire l'arbre lookup spare ?
L'arbre lookup spare mène de « quelle pièce ? » à une ref validée ou escalade.
Six gates séquentielles
Gate intent : spare_catalog, compat, part_number, OOS
Gate produit parent : SKU ou nom produit identifié
Gate modèle : model_id + révision (photo étiquette si doute)
Gate pièce : ref client, part_number schéma ou symptôme panne
Gate compat : croisement compatible_models metafield
Gate sortie : lien PDP spare, OOS, obsolete, handoff_agent
État session persistant
JSON : {model_id, revision, spare_sku, compat_ok, stock, source}. LLM reformule, arbre décide. Voir anti-hallucination.
Règle max tours
5-7 questions max avant sortie. Client demande humain : handoff avec modèle et ref candidate déjà collectés.
Branche spare_model_lookup
Bot envoie visuel « où trouver le numéro » par catégorie produit. Attend photo étiquette ou saisie model_id. Pas de compatibilité sans modèle confirmé.
Branche spare_part_number
Client cite « pièce 14 » → bot lit table part_number → spare_sku. Puis gate compat avec model_id. Si incompatible : message clair, pas de lien achat.
Branche spare_compat_check
Client cite ref SP-4421 + modèle KitchenPro X200 rev B → bot lit compatible_models → oui/non + lien PDP si oui et stock OK.
Documentation arbre
Chaque branche SPARE documentée : questions, data source, sortie, macro équivalente (#343). Mise à jour à chaque lancement révision produit v2.
Quelles sources de data le bot doit-il lire ?
Le bot spare ne répond que depuis des sources vérifiables, jamais depuis la mémoire du LLM seul.
Cinq sources Shopify
Metafield spare.compatible_models : JSON array model_id
Metafield spare.part_number : ref usine et numéro schéma
Metafield spare.parent_product : lien product parent
Inventory API : stock live par location spare
Collection spare-parts : périmètre bot strict
Shopify documente les metafields produit pour enrichir le catalogue (Shopify, metafields 2025).
Table part_number → SKU
CSV ou metafield JSON : exploded item 14 = SP-HINGE-R-v2. Bot lookup table, pas génération LLM.
Schémas exploded PDF
Lien manuel si spare_install. Bot cite page PDF, ne décrit pas une pièce absente du schéma officiel.
Historique commande
Si client connecté : order line SKU parent → pré-remplit model_id depuis variant acheté. Réduit erreur « j'ai le mauvais modèle ».
Sync hebdo catalogue
Import fournisseur : nouvelles refs, obsolescence, compatible_models mis à jour. Bot stale data = wrong part. Voir entraînement data Shopify.
RAG sur notices
Chunks manuel indexés pour spare_install uniquement. Compatibilité = metafield, pas RAG. Séparer les deux évite confusion bot.
Comment empêcher le bot d'inventer une référence ?
L'anti-hallucination spare est non négociable : une ref inventée = commande erronée garantie.
Cinq règles strictes
Whitelist SKU : bot ne cite que SKU présents collection spare-parts
Compat gate : pas de lien achat si model_id absent de compatible_models
Pas de « je pense » : oui confirmé data ou escalade
Stock live : pas promettre disponible sans inventory API
Fallback : « je ne trouve pas cette combinaison » + handoff
Prompt system spare
Instruction : « Tu ne confirmes jamais compatibilité sans lecture compatible_models. Tu ne génères jamais un SKU. Tu escalades si model_id introuvable. » Voir system instructions (#310).
Tests régression
20 scénarios : modèle connu OK, modèle inconnu, révision v1 vs v2, ref inexistante, OOS, obsolete. Taux hallucination ref cible 0 %.
Double confirmation client
Avant lien checkout : « Confirmez : modèle [X] rev [Y], pièce [REF]. » Bouton oui/non. Réduit wrong part côté client.
Logging audit
Chaque spare_compat_check loggue model_id, spare_sku, source metafield, decision. Revue hebdo des refus compat pour enrichir compatible_models.
Modèles rares et custom
Si model_id absent catalogue : handoff expert produit, pas de tentative LLM. Macro SPARE-ESCALATE avec SLA 24 h.
Quels flows bot pour spare sur PDP et chat ?
Le bot spare intervient sur plusieurs points de contact, pas seulement le widget chat général.
Flow PDP produit parent
Bloc « Besoin d'une pièce ? » : dropdown modèle acheté ou saisi → liste spare filtrée compatible_models → add to cart.
Flow page /pieces-detachees
Lookup modèle central. Bot widget répond aux mêmes intents que la page self-service (#343).
Flow post-diagnostic #342
Payload failure inclut part_number probable → bot spare valide compat + stock → lien commande ou SPARE-OOS.
Flow Instagram / WhatsApp
Client envoie photo étiquette → OCR ou agent async valide model_id → bot reprend spare_compat_check. Limiter promesse si OCR incertain.
Messages proactifs
Sur collection spare-parts : « Indiquez votre modèle pour voir les pièces compatibles. » Voir messages proactifs.
Handoff payload spare
model_id, revision, spare_sku_tried, compat_result, photos[], order_id. Agent ne repose pas les questions bot.
Exemple réponse bot validée
« Votre modèle Outdoor Tent Pro 3 (révision 2022) est compatible avec la charnière SP-HINGE-R-v2. Stock : 12 unités, expédition 48 h. Commandez ici : [lien]. Guide montage pièce 14 : [PDF]. »
Comment brancher le bot spare sur Shopify ?
Le setup bot spare Shopify repose sur metafields, collection et intents configurés.
Checklist technique
Créer namespace spare.* metafields sur products spare
Renseigner compatible_models JSON pour top 50 SKU spare
Tag spare_part + collection spare-parts
Connecter inventory API au bot
Indexer table part_number si schémas exploded
Configurer intents spare_* dans Qstomy ou équivalent
Tester 20 scénarios section 6
Widget PDP parent
App block ou snippet : bouton chat pré-rempli intent spare_compat_check avec product_id parent.
Shopify Flow alertes
Si spare_oos > 30 j sur SKU top 10 : alerte ops + message bot SPARE-OOS mis à jour.
Storefront API
Bot query products collection spare-parts filtré metafield compatible_models contains model_id. Pas de search full catalog LLM.
Multi-location spare
Entrepôt spare séparé : inventory par location. Bot lit stock location spare, pas stock produit neuf.
Lancement progressif
Phase 1 : top 20 SKU spare 80 % volume. Phase 2 : catalogue complet. Phase 3 : OCR photo étiquette si taux handoff model_lookup > 40 %.
Quels KPI mesurer sur le bot spare ?
Sans KPI bot spare, impossible de prouver ROI ou détecter hallucinations résiduelles.
Sept métriques clés
spare_bot_resolution : résolu sans agent / tickets spare bot
spare_compat_bot_rate : compat confirmée bot / lookups
bot_wrong_part_rate : retours mauvaise pièce après bot
spare_handoff_rate : escalades / sessions spare
time_to_spare_link : ouverture chat → lien PDP envoyé
spare_conversion_bot : commandes spare post-lien bot
CSAT intent spare_bot : satisfaction post-lookup
Benchmark DTC
Objectif spare_bot_resolution > 65 %, bot_wrong_part_rate < 3 %, spare_handoff_rate < 35 %, time_to_spare_link < 90 s.
Corrélation wrong_part
Comparer bot_wrong_part_rate vs wrong_part_rate global (#343). Si bot plus bas : preuve valeur IA. Si égal : revoir gates compat.
Revue mensuelle
Top 10 handoff reasons : model_id missing, obsolete, custom. Enrichir metafields ou schémas selon cause dominante.
A/B test double confirmation
Mesurer impact bouton confirmer modèle+ref sur conversion et wrong_part. Souvent +5 pt conversion, -2 pt wrong_part.
Quels cas limites et escalades prévoir ?
Cinq edge cases spare bot exigent règles explicites, pas improvisation LLM.
Modèle introuvable
Photo étiquette demandée. Si toujours absent : handoff expert, pas de ref proposée. Tag spare_model_unknown.
Révision ambiguë v1 vs v2
Bot liste différences visuelles (couleur clip, forme connecteur). Client choisit. Si doute persiste : handoff.
Pièce obsolete
Bot lit flag obsolete + alternative_sku metafield. Pas vendre ref arrêtée. Macro SPARE-OBSOLETE bot.
Pièce garantie gratuite
Intent spare_warranty : bot vérifie order date + policy garantie (#62). Ne pas envoyer lien payant si couvert.
B2B volume pièces
Quantité > 10 ou compte wholesale : router wholesale bot (#334).
Pièce dangereuse DIY
Batterie, gaz : bot refuse vente DIY, propose atelier repair (#341). Policy #343 alignée.
Wrong part claim post-bot
Si client a commandé via lien bot : auditer log compat. Erreur data → retour gratuit. Erreur client model_id → policy retour #343.
Comment Qstomy gère le lookup pièces détachées ?
Qstomy traite les intents spare_* depuis compatible_models, inventory Shopify et collection spare-parts.
Capacités bot spare
spare_compat_check : model_id → ref validée ou refus
spare_part_number : schéma → SKU via table
Stock live : OOS avec date si metafield restock
Lien PDP spare : checkout direct
Handoff payload : modèle, ref, photos, decision log
Scénario DTC chiffré
Marque mobilier modulaire, 110 tickets spare/mois, lookup agent manuel.
Après Qstomy spare bot + metafields : 76 % tickets spare auto-résolus, bot_wrong_part_rate 4 %, spare_handoff_rate 24 %, CSAT spare bot 4,7/5, temps agent spare -61 %.
Le bot filtre les lookups standards ; l'expert catalogue intervient sur modèles rares et litiges wrong part avec dossier pré-rempli.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer le bot spare parts ?
Checklist bot spare (10 étapes)
Auditer tickets spare 90 j et prioriser top SKU
Créer metafields spare.compatible_models et part_number
Peupler compatible_models top 50 refs spare
Configurer intents spare_* et arbre 6 gates
Rédiger prompt anti-hallucination spare section 6
Brancher inventory API et collection spare-parts
Tester 20 scénarios régression
Activer double confirmation avant lien checkout
Dashboard spare_bot_resolution hebdo
Revue mensuelle handoff reasons et enrichissement metafields
En bref
#344 = bot lookup spare, pas policy ops (#343)
Data first : compatible_models, jamais LLM seul
10 intents spare_* : compat, part_number, OOS
Anti-hallucination : whitelist SKU, compat gate
KPI bot_wrong_part_rate : cible < 3 %
FAQ
Différence avec support spare #343 ?
#343 = équipe, macros, policy. #344 = bot IA lookup référence sans erreur.
Le bot peut-il confirmer compat sans metafield ?
Non. Escalade ou refus. Jamais de « probablement compatible ».
Comment lier diagnostic panne #342 ?
Payload failure → part_number → bot spare valide compat + stock → lien commande.
Faut-il un catalogue spare séparé ?
Oui, collection spare-parts + metafields. Bot ne cherche pas dans tout le shop.
Que faire si OCR photo étiquette échoue ?
Demander saisie manuelle model_id ou handoff agent avec photo jointe.
Aller plus loin
Testez vous-même cinq lookups spare sur votre boutique staging : modèle connu, inconnu, OOS, obsolete, wrong revision.
Partagez ce guide #344 avec l'équipe produit et ops catalogue : des metafields compatible_models à jour valent plus qu'un prompt LLM long.
Synchronisez compatible_models à chaque lancement révision : un bot spare sur data stale multiplie wrong_part_rate en 30 jours.
Enzo
12 juillet 2026
