E-commerce
30 juin 2026
Votre centre d'aide existe en français. Vous activez l'allemand sur Shopify Markets. Six semaines plus tard, la page retour DE cite encore un délai de 30 jours obsolète depuis la refonte policy FR. Le bot répond en allemand avec une règle fausse.
HappySupport rappelle qu'étendre trop de langues sans fraîcheur locale crée plus de tickets qu'une aide monolingue bien tenue : une langue ne devrait être ouverte que si elle représente au moins 5 % du chiffre d'affaires ou un plan crédible pour y arriver sous 12 mois (HappySupport, help center multilingue 2026).
Ce guide #268 traite la structuration multilingue des réponses support : taxonomie, tiers de contenu, workflow traduction, signalement contenu périmé. Distinct de localisation bot (#267) (ton à la volée) et de maintenance catalogue (#140) (sync SKU).
Sommaire
Pourquoi structurer une base multilingue avant de traduire ?
Une base de réponses multilingue n'est pas un dossier de pages traduites en parallèle. C'est un système : langue source, versions locale, owners, statuts de fraîcheur et métadonnées exploitables par agents et bot.
Trois échecs classiques
Traduction one-shot : lancement DE, jamais revu
Pages orphelines : article FR mis à jour, DE oublié
Chunks bot incohérents : policy FR indexée, réponse ES
Impact support
eDesk note que la plupart des échecs IA support viennent de sources dispersées, contradictoires ou périmées, pas du modèle (eDesk, base IA e-commerce 2026).
Exemple DTC
Marque mode, 4 langues help center. Avant tiers + flag stale : 31 % tickets « info contradictoire site vs email ». Après workflow #268 : −44 %, déflexion self-service DE +22 pts.
En quoi diffère-t-il des guides voisins ?
Cinq contenus, cinq questions.
Localisation bot (#267)
Localisation bot (#267) : ton et prompts à la réponse. Le #268 : architecture articles multilingues en amont.
Bot multilingue (#16)
Bot multilingue (#16) : quand automatiser. Le #268 : quel contenu alimenter le bot par langue.
Structure KB générale
Structure KB : taxonomie monolingue. Le #268 : couche locale par marché et langue.
Maintenance catalogue (#140)
Maintenance catalogue (#140) : drift SKU Shopify. Le #268 : parity traduction quand policy change.
Support international (#100)
International (#100) : ops SAV global. Le #268 : help center et corpus structurés par locale.
Comment choisir langue source et langues prioritaires ?
La langue source KB est celle où vous rédigez et validez avant toute traduction.
Critères de choix
Langue équipe : rédaction native ou quasi-native
Policy maître : juridique validée dans cette langue
CA principal : souvent FR ou EN selon marque
Règle d'ouverture langue
Ouvrir une locale help center si : CA market ≥ 5 %, ou plan 12 mois documenté, ou volume tickets langue > 8 % du total support. En dessous, MT assistée ticket par ticket suffit souvent. Des guides spécialisés en documentation recommandent de ne pas traiter toutes les pages pareil : prioriser par tier et trafic (guide KB multilingue 2026).
Matrice décision
Colonnes : langue, CA %, tickets/mois, pages help existantes, owner nommé, statut (pilote / live / gelé). Maximum 3 langues live tant que parity stale < 10 %.
Quelle taxonomie catégories × langues × marchés ?
La taxonomie KB multilingue aligne navigation client, tags internes et chunks bot.
Niveaux recommandés
Catégorie : Commande, Livraison, Retour, Produit, Compte, Paiement
Sous-catégorie : WISMO, délai pays, portail retour, taille, TVA
Locale : fr-FR, de-DE, en-GB, es-ES (BCP 47)
Market overlay : règle spécifique UK vs EU si policy diverge
Identifiants stables
Chaque article porte un kb_id invariant (ex. KB-RET-001). Les versions DE/ES/EN partagent le même kb_id. Le bot retrieve par kb_id + locale, pas par URL seule.
Shopify Markets
Pages policy Shopify traduites via Translate & Adapt alimentent le help center, mais les articles SAV détaillés restent à structurer dans votre CMS help (Shopify Translate & Adapt).
Quel système de tiers T1, T2 et T3 par article ?
Le système tiers contenu multilingue évite de traduire 200 pages au même niveau de rigueur.
Tier 1 (mission-critical)
Retours, remboursements, garantie légale
Délais livraison par zone export
Portail suivi commande, accès compte
Top 10 questions tickets N-1 par langue
Traduction pro + relecture native + mise à jour sous 48 h si source change.
Tier 2 (usage fréquent)
Guides taille, entretien produit, paiement, échange. MT assistée + relecture échantillon 20 %. Revue trimestrielle.
Tier 3 (long tail)
Articles niche, release notes anciennes. Peut rester langue source avec résumé auto, ou traduction à la demande si trafic search > seuil.
Tag obligatoire
Champ tier sur chaque kb_id. Dashboard : % T1 stale par locale.
Quel modèle d'article KB-MULTI-* et quelles métadonnées ?
Six templates article multilingue couvrent 90 % des besoins SAV DTC.
KB-MULTI-POLICY-01 (policy)
Résumé 2 lignes + conditions numérotées + exceptions + lien portail + date effet. Métadonnées : market[], tier=T1, review_cycle=30j.
KB-MULTI-HOWTO-01 (procédure)
Étapes numérotées, captures UI locale, CTA unique. 1 objectif par article.
KB-MULTI-PRODUCT-01 (fiche produit)
SKU, compatibilité, entretien, lien PDP locale. Sync metafield Shopify.
KB-MULTI-TROUBLE-01 (dépannage)
Symptôme → cause → action → escalade. Chunkable pour RAG.
Champs metadata communs
kb_id, locale, tier, source_version, status (draft/review/live/stale), owner, last_reviewed, market[], search_terms[] par langue.
Termes recherche locale
Le client DE cherche « Rücksendung », pas « return ». Renseigner search_terms natifs pour help search et bot retrieval.
Comment organiser URLs, hreflang et pages Shopify ?
La structure URL multilingue aide SEO, self-service et indexation bot.
Patterns courants
Subfolder : /fr/aide/retours, /de/hilfe/rucksendung
Subdomain : help.de.marque.com (moins fréquent DTC)
Paramètre : ?lang=de (déconseillé SEO)
Hreflang et switcher
Une URL crawlable par locale, balises hreflang croisées, switcher langue visible help center. knowledge-base.software rappelle que sans URLs séparées, analytics par langue devient imprécis (Knowledge Base Software, guide multilingue).
Alignement Shopify
Policy pages Markets = source légale. Articles help = couche pédagogique. Lien croisé bidirectionnel policy ↔ article how-to retour.
Quel workflow traduction source → locale → publication ?
Le workflow traduction KB en huit étapes évite les versions fantômes.
Identif besoin ou changement policy
Rédaction / update article langue source
Validation support lead + legal si T1
Increment
source_versionFlag auto toutes locales liées : status=stale
Traduction selon tier (pro / MT+review / différé)
Relecture native + search_terms locale
Publish + re-index chunks bot sous 24 h
Outils TMS
Lokalise, Crowdin ou Smartling pour mémoire traduction : réutiliser segments passés quand paragraphe source change partiellement. HappySupport insiste : le flag stale ne peut pas rester manuel au-delà d'un trimestre.
SLA par tier
T1 stale → locale live sous 48 h. T2 sous 7 j. T3 sous 30 j ou gel traduction.
Comment détecter contenu périmé et mesurer la parity locale ?
La fraîcheur KB multilingue se mesure, pas se ressent.
Indicateurs
Parity index : % articles T1 locale où source_version = locale_version
Stale backlog : articles flaggés > 7 j
Search no-result : requêtes help par langue sans hit
Ticket « info site fausse » : tag kb_stale suspect
Knowledge Freshness Index (KFI)
Score par locale : fraîcheur T1 (poids 60 %), T2 (30 %), délai moyen stale→publish (10 %). Objectif : KFI ≥ 85 avant d'ouvrir une 4e langue.
Rituel hebdo 30 min
Export stale list. Traiter top 3 T1 par CA market. Log dans Notion #kb-locale. Fin.ai recommande de flaguer gaps depuis le frontline : canal Slack #kb-gap (Fin.ai, base IA).
Comment chunker et synchroniser le corpus bot par langue ?
Le corpus RAG multilingue indexe par locale, pas seulement par kb_id.
Règles chunking
1 chunk = 1 idée ou 1 étape procédure
Metadata : kb_id, locale, tier, market[], source_version
Pas de chunk multilingue mixte
Max 500 tokens, overlap 50 tokens
Retrieve bot
Filtre strict locale=detected_language puis fallback langue source avec mention « traduction automatique » si T3 seulement. Lien nettoyer corpus (#103).
Sync publish
Article locale passe live → webhook re-index sous 15 min. Article stale → retirer chunks locale du index ou marquer deprecated. Voir Markets bot (#157).
Comment Qstomy s'appuie-t-il sur une KB multilingue structurée ?
Qstomy performe quand les sources sont propres, versionnées et filtrables par locale.
Capacités alignées KB #268
Ingest help center : chunks par locale + kb_id
Retrieve filtré : langue client + market Shopify
Stale guard : ignore chunks status=stale
Gap report : questions sans chunk locale
Handoff : kb_id + locale pour agent
Scénario DTC chiffré
Marque skincare, help FR/EN/DE, 180 articles dont 42 T1. Avant structuration #268 : bot cite policy FR sur client DE (18 % erreurs policy). Après kb_id + tiers + stale flag + re-index : erreurs policy −67 %, self-service DE +19 pts, temps rédaction traduction T2 −35 % via TMS mémoire.
Explorez support client IA, Shopify, demander une démo.
Quels playbooks déployer en 2 semaines ?
Playbook 1 : audit langues (1 j)
CA, tickets, pages help par locale. Décider 2-3 langues live max. Matrice section 3.
Playbook 2 : inventaire kb_id (2 j)
Lister articles existants, assigner kb_id + tier. Migrer top 15 T1 en premier.
Playbook 3 : templates KB-MULTI (1 j)
Déployer 4 modèles section 6 dans Notion ou CMS help. Former rédacteurs.
Playbook 4 : workflow stale (4 h)
Automatiser flag stale on source_version change. SLA section 8 dans Slack #kb-locale.
Playbook 5 : traduction T1 pilote (3 j)
10 articles retour/livraison en DE. Relecture native. Publish + re-index bot.
Playbook 6 : dashboard KFI mensuel
Parity index, stale backlog, no-result search. 1 langue gelée si KFI < 75. Lien qualité réponses (#116).
Maillage utile
Une base multilingue durable ne naît pas d'un export DeepL. Elle naît d'une langue source claire, de tiers explicites, d'identifiants stables et d'un workflow qui traite la traduction comme de la maintenance continue, pas d'un projet ponctuel.
Enzo
30 juin 2026
