E-commerce
28 juin 2026
Le client ouvre le guide des tailles, ferme l'onglet, revient au sélecteur S/M/L. Il hésite encore. Un tableau statique ne recommande rien : il affiche des chiffres sans dire « prenez la M ».
Un chatbot IA de recommandation taille transforme vos données produit (mensurations, fit note, avis, stock) en conseil personnalisé avant le panier. Zalando estime que le fit représente jusqu'à la moitié des retours mode en Europe (Zalando, sizing 2025).
Ce guide #199 traite la recommandation taille par IA : données requises, logique de mapping, limites et mesure qualité. Distinct de guide des tailles chatbot (#5) (affichage et réduction retours) et de support humain sizing (#128) : ici, l'architecture recommandation + limites data.
Sommaire
Pourquoi passer du guide des tailles à la recommandation IA ?
Le guide des tailles informe. La recommandation taille décide. Cette différence change la conversion et le taux de retour wrong-size.
Ce que le client attend en 2026
Une taille nommée : « Prenez M », pas « consultez le tableau »
Un pourquoi court : coupe slim, tissu stretch, avis clients
Une alternative : entre deux tailles, quelle privilégier
Un plan B : échange gratuit, retour si écart
McKinsey estime qu'environ 70 % des retours mode viennent du fit ou du style (Vircab, retours apparel 2026). Le NRF place le taux de retour e-commerce autour de 19,3 % en 2025 (NRF, Retail Returns 2025).
Un bot sizing bien calibré ne remplace pas l'essayage. Il réduit le bracketing (commander deux tailles « au cas où ») en convertissant l'incertitude en recommandation traçable.
En quoi diffère-t-il du guide chatbot (#5) et du support humain (#128) ?
Trois contenus voisins, trois niveaux de profondeur.
Guide des tailles chatbot (#5)
Guide tailles chatbot (#5) couvre fit notes, mensurations, bracketing et réduction retours wrong-size. Le #199 approfondit la logique de recommandation et les limites data qui empêchent un bot de « deviner ».
Support humain sizing (#128)
Support tailles (#128) structure macros agents, UX PDP et workflow tickets. Le #199 automatise la recommandation ; le #128 gère l'escalade quand le bot atteint ses limites.
Guided selling général (#150)
Guided selling (#150) oriente vers un produit. Ici : une variante taille sur un SKU déjà ouvert.
Promesse #199
Schéma data, flow questions, règles mapping, cas limites, gouvernance qualité recommandation, KPI fit bot.
Quelles données minimum pour recommander une taille fiable ?
Une recommandation IA sans data produit propre produit des erreurs silencieuses. Le bot ne doit jamais extrapoler au-delà de ce que vous lui fournissez.
Couche produit (obligatoire par SKU pilote)
size_chart : mensurations min/max par variante (cm)
fit_note : taille petit, normal, grand
cut_type : slim, regular, relaxed, oversize
fabric_stretch : rigide, léger stretch, élastique
model_size : taille portée + mensurations mannequin
stock_by_variant : disponibilité temps réel
Couche client (zero-party data)
usual_size : taille habituelle catégorie
reference_brand : « je porte M chez [marque X] »
measurements : poitrine, taille, hanches (optionnel)
fit_preference : ajusté vs confortable
Sur Shopify, structurez via métachamps produit et variante (Shopify, métachamps). Sans fit_note et size_chart structurés, le bot reformule le tableau PDF : aucune valeur recommandation.
Couche feedback (enrichissement continu)
Avis filtrés « taille petit/grand », motifs retour Loop sizing, tickets tag prod_size_fit. Alimente flux data support produit (#198).
Comment structurer le flow de questions sans faire fuir le client ?
Le flow recommandation taille doit tenir en moins de 90 secondes sur mobile, sur une PDP déjà ouverte.
Arbre minimal (4 branches)
Contexte produit : bot connaît SKU, coupe, fit note (pas de question inutile)
Taille habituelle : « Quelle taille portez-vous en [jean/robe] ? »
Préférence fit : ajusté ou confortable (skip si fit note explicite)
Entre deux tailles : oui/non → règle tie-break section 6
Règle d'arrêt précoce
Si usual_size + fit_note produit suffisent à mapper une variante avec confiance > 85 %, recommandez immédiatement. Demander poitrine/taille/hanches seulement si usual_size absent ou produit technique (sport, costume).
Formulation recommandation
Template : « Pour ce [produit], coupe [X], nous recommandons taille M. Raison : [fit note + avis clients]. Si vous préférez plus ample, prenez L. Échange taille gratuit sous 30 j : [lien]. » Une recommandation, un plan B, une policy.
Trigger d'ouverture PDP
Nudge après 25 s sur sélecteur taille sans clic, ou clic « Guide des tailles » sans add-to-cart. Évitez popup immédiate : laissez 10 s de lecture fiche.
Quelle logique de mapping mensurations vers variante SKU ?
Le mapping taille SKU n'est pas une intuition LLM. C'est une règle déterministe alimentée par vos données, que le bot explique en langage naturel.
Algorithme type (deterministic first)
Convertir usual_size référence en fourchette mensurations (table marque interne)
Appliquer offset fit_note : +1 si « taille petit », -1 si « taille grand »
Appliquer offset fit_preference : +1 si confortable sur coupe slim
Matcher variante dont intervalle mensurations contient le client
Vérifier stock ; sinon proposer taille adjacente disponible
Exemple chiffré jean slim
SKU jean slim, fit_note « taille normalement », stretch léger. Client : M habituel, préférence ajustée, tour taille 82 cm. Table : M = 80-84 cm, L = 84-88 cm. Mapping → M. Si fit_note « taille petit » : offset +1 → L. Le bot cite la règle, pas une hallucination.
Rôle du LLM
Le modèle reformule, pose les bonnes questions, gère le ton marque. La taille recommandée vient du moteur règles. Pattern 2026 : LLM + moteur fit déterministe, pas LLM seul.
Comment traiter les cas limites sans sur-promettre ?
Les cas limites sizing génèrent 80 % des escalades humaines. Anticipez-les dans le flow bot.
Entre deux tailles
Règle par défaut : si hésitation S/M, recommander M sur coupe slim + stretch, S sur oversize. Toujours expliquer : « Clients entre deux tailles prennent M sur ce modèle » (si data avis le confirme). Proposer échange gratuit explicite.
Référence marque externe
« Je porte 38 chez Zara » : sans table cross-brand, le bot demande mensurations ou usual_size dans votre marque. Ne jamais mapper Zara → votre grille sans table validée.
Morphologie atypique, grossesse, sport technique
Seuil confiance < 70 % : handoff humain avec contexte (mensurations, SKU, questions posées). Voir transfert contexte bot → humain.
Multi-catégorie
Taille robe ≠ taille jean. Le bot doit demander la catégorie ou lire le product_type Shopify avant de recommander.
Quelles limites data et légales ne pas dépasser ?
Une recommandation taille IA engage votre marque. Les limites doivent être codées, pas laissées au bon vouloir du modèle.
Limites data
Pas de size_chart : bot affiche guide + handoff, pas de taille inventée
Stock zero : ne recommander que tailles disponibles ou alerte retour stock
Produit nouveau sans avis : mentionner incertitude, fit note obligatoire
Confiance < seuil : « Je ne peux pas recommander avec certitude » + agent
Limites légales et éthiques
Ne pas demander poids/taille corporelle si non nécessaire au produit. Éviter commentaires sur morphologie (« pour votre corpulence »). RGPD : mensurations = donnée sensible si liée à identité ; minimiser stockage, consentement clair, durée rétention courte. Voir privacy support e-commerce.
Disclaimers utiles
« Recommandation indicative basée sur vos réponses et notre guide taille. Échange gratuit si la taille ne convient pas. » Réduit charge litige et aligne attente client.
Audit réponses bot
Revue mensuelle 50 conversations sizing : taille recommandée traçable, aucune invention SKU. Audit réponses chatbot.
Comment mesurer la qualité des recommandations taille bot ?
Sans KPI fit, vous ne saurez pas si le bot aide ou aggrave les retours.
KPI primaires (30-90 j)
Fit CSAT post-achat : sondage J+7 « la taille convient ? »
Return rate wrong-size : sessions bot sizing vs contrôle
Conversion add-to-cart : PDP avec recommandation vs sans
Bracketing rate : commandes multi-taille même SKU
Handoff rate : % conversations escaladées humain
Méthode A/B simple
50 % trafic PDP catégorie pilote avec bot sizing, 50 % sans. Durée 4 semaines, minimum 2 000 sessions/bras. Zalando a observé jusqu'à 40 % de retours sizing en moins sur pilots cabine virtuelle (Zalando, virtual fitting).
Boucle retour data
Chaque retour motif « too small/too large » + conversation_id bot → ajuster offset fit_note SKU. Objectif : wrong-size return rate bot-engaged -15 % vs baseline à S+12.
Comment intégrer stock, échange et expérience PDP ?
La recommandation taille vit sur la PDP, pas dans un silo chatbot.
Sync stock temps réel
API Shopify variant inventory avant chaque recommandation. Si M rupture : « M indisponible, L disponible avec fit légèrement plus ample » ou alerte retour stock. Ne jamais recommander une variante sold out.
Policy échange dans le flow
Après recommandation, rappel : « Échange taille sous 30 j, gratuit » avec lien portail retour. Réduit anxiété et bracketing. Aligner avec préqualification retour bot.
UX post-recommandation
Pré-sélection variante : bot clique taille M dans le sélecteur
Sticky recap : « Vous avez choisi M sur conseil assistant »
Re-open flow : « Changer ma taille » sans perdre contexte
Cohérence multi-canal
Même logique sizing sur chat site, Instagram DM et WhatsApp support. Une seule table mapping, plusieurs surfaces.
Quelles erreurs produisent encore des retours wrong-size ?
Même avec un bot, ces erreurs sizing bot reviennent sans gouvernance.
Erreur 1 : LLM seul sans moteur règles
Le modèle « devine » M car le client a dit M ailleurs, sans lire fit_note « taille petit ». Fix : recommandation = output règles, LLM = interface.
Erreur 2 : guide taille obsolète
Collection printemps avec nouvelle coupe, tableau hiver encore en base. Audit trimestriel size_chart vs fiche produit réelle.
Erreur 3 : ignorer avis retours
80 % avis « taille petit » sur SKU, bot recommande quand même S par défaut. Injecter agrégat avis dans offset mapping.
Erreur 4 : pas de handoff
Client complexe, bot boucle 6 questions, abandon. Seuil 3 tours sans confiance → agent avec transcript.
Erreur 5 : zéro mesure post-lancement
Bot déployé, jamais comparé au taux retour sizing N-1. Sans KPI section 8, impossible d'itérer fit_note et offsets.
Comment Qstomy recommande-t-il une taille sur Shopify ?
Qstomy combine conversation PDP et moteur fit branché sur votre catalogue Shopify.
Fonctionnalités recommandation taille
Lecture métachamps : fit_note, size_chart, model_size par SKU
Flow sizing contextuel : questions adaptées au product_type
Recommandation traçable : taille + raison + variante pré-sélectionnée
Handoff humain : transcript + mensurations si confiance basse
Export fit analytics : volume, conversion, retours par SKU
Scénario DTC chiffré
Marque prêt-à-porter femme, 850 commandes/mois, return rate sizing 31 %, guide PDF peu consulté. Déploiement Qstomy sizing sur 40 SKU jeans/robes, métachamps fit + flow 4 questions + sync stock. Après 10 semaines (A/B 50/50) : conversion PDP pilote +12 %, retours wrong-size sessions bot -19 %, bracketing même SKU -24 %, handoff humain 11 % des flows sizing.
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels lancer en 30 jours ?
Playbook 1 : audit data sizing (1 jour)
Sélectionner 20 SKU top CA catégorie fit-sensitive. Vérifier présence fit_note, size_chart, model_size, stock API. Compléter les champs manquants dans Shopify Admin.
Playbook 2 : table mapping (demi-journée)
Sheets : usual_size × fit_note × fit_preference → variante. Valider sur 10 cas réels avec styliste ou lead e-commerce.
Playbook 3 : flow bot 4 questions (2 j)
Rédiger questions, template recommandation, disclaimers, seuil handoff. Tester 15 scénarios : slim, oversize, entre deux tailles, rupture stock.
Playbook 4 : pilote A/B 4 semaines
Activer bot sur collection pilote. Tracker conversion, retour sizing, bracketing. Revue hebdo top 5 SKU wrong-size post-bot.
Playbook 5 : boucle retour S+30
Merge retours Loop + tickets prod_size_fit. Ajuster offset fit_note SKU problématiques. Documenter dans Notion sizing changelog.
Maillage utile
Recommander une taille, ce n'est pas deviner. C'est transformer vos données produit en confiance client, avec des limites claires et une mesure continue.
Enzo
28 juin 2026
