Support client multilingue avec une seule base de connaissances : mise en place et pièges

Vendre dans trois pays impliquait autrefois l’une de deux options peu attrayantes : recruter une équipe support dans trois langues, ou maintenir l’intégralité de votre centre d’aide en trois exemplaires. Le support par IA appuyé sur des sources change ce calcul, car la recherche et la génération sont deux étapes distinctes : le système peut trouver la réponse dans un article en anglais et la rédiger en néerlandais. Cela fonctionne réellement. La question intéressante n’est donc plus de savoir si c’est possible, mais quelles parties de votre contenu doivent encore être rédigées langue par langue, et comment vous remarqueriez qu’une réponse traduite est discrètement fausse.

Ce qui décide réellement de la langue de la réponse

Le modèle mental avec lequel la plupart des gens arrivent (« il détecte l’allemand et bascule vers la base de connaissances allemande ») ne correspond pas à ce qui se passe, et cette différence détermine la façon dont vous devez rédiger.

1. La question passe d’abord par l’étape de recherche. Dans CustomerEagle, une question qui n’est pas en anglais est traduite en anglais en interne avant la recherche, car l’index fonctionne sur le sens et chercher à partir d’une langue pivot unique est plus fiable. Les noms de produits, les références (SKU) et les numéros de commande restent intacts, et les requêtes très courtes ou ressemblant à du code sautent cette étape.
2. La recherche elle-même n’est pas filtrée par langue. Une question en allemand récupère couramment des passages en anglais. Tout le principe est là : un seul ensemble d’articles sert tous les marchés.
3. Ces passages sont transmis au modèle avec l’instruction de répondre dans la langue du message le plus récent du client, en traduisant le contenu récupéré si nécessaire. Cette instruction est activée par le paramètre « répondre dans la langue du client », activé par défaut. Désactivez-le et l’IA répond en anglais, quelle que soit la langue utilisée par le client.

Trois stratégies, et ce que chacune coûte vraiment

Toute configuration multilingue prend l’une de trois formes. L’erreur courante consiste à en faire une décision unique pour toute la base de connaissances plutôt qu’un choix article par article.

La plupart des équipes finissent sur le modèle hybride, pour une raison qui tient en une phrase : traduire ne coûte rien, tenir à jour coûte tout. Un article traduit une fois puis modifié quatre fois dans l’année, dont deux modifications ne sont jamais parvenues à la copie allemande, est un passif avec une citation en dessous.

Ce qui passe la frontière intact, et ce qui ne passe pas

• Passe : les procédures, le fonctionnement du produit, les étapes de dépannage, les définitions et les politiques énoncées comme des faits. Un délai de retour de 30 jours reste un délai de retour de 30 jours partout.
• Casse : les valeurs qui diffèrent selon le marché. C’est le point majeur, et il fait l’objet de sa propre section ci-dessous.
• Casse : la formulation juridiquement précise, les expressions idiomatiques et tout ce où la formulation est le produit. Une notion légale porte un nom exact dans chaque juridiction, et la voix de marque ne survit pas à l’aller-retour.
• Inégal : les libellés d’interface. Une application en anglais et un client francophone produisent une phrase en français contenant un nom de bouton en anglais : correct, mais d’apparence négligée.

Le problème des valeurs, celui qui fait vraiment mal

Votre article source indique « la livraison prend 1 à 2 jours ouvrés » et « les retours sont gratuits ». Les deux étaient vrais au moment de la rédaction, pour un seul marché. Répondez à un client allemand à partir de cet article et l’IA les énonce avec assurance, en allemand, citation à l’appui. Elle n’hallucine pas. Elle répète ce que vous avez écrit.

C’est la façon la plus courante dont une configuration multilingue dérape, et cela tient entièrement à la rédaction de l’article plutôt qu’à la langue. La solution est structurelle : tout fait qui varie selon le marché doit porter sa condition dans la même phrase.

Notez ce que ce n’est pas : un problème de traduction. Aucune traduction n’aurait pu le régler. C’est la même discipline que celle qui rend un article exploitable tout court (des valeurs réelles écrites en texte, les conditions avant les conclusions), appliquée à un second axe. Si vous n’avez pas lu comment rédiger des articles de centre d’aide exploitables par une IA, commencez par là : un article déjà flou sur ses propres conditions devient carrément trompeur dès qu’il sert quatre marchés.

La détection se trompera parfois : prévoyez une porte de sortie

La détection de langue est une estimation : bonne sur un paragraphe, médiocre sur « ok », « ja » ou un numéro de commande. Les langues qui partagent du vocabulaire (néerlandais et allemand, espagnol et portugais) sont celles que l’on confond le plus souvent sur un message court. Concevez votre dispositif en partant du principe que l’estimation sera parfois fausse.

• Ne détectez jamais la langue à partir de la seule adresse IP. Un néerlandophone en Allemagne, un expatrié à Amsterdam et toute personne derrière un VPN se retrouvent avec la mauvaise langue, et être interpellé dans la mauvaise langue fait une pire première impression qu’une formule neutre.
• Laissez le client changer de langue, de manière visible. La langue d’interface du widget peut être fixée par page, définie une fois pour tout l’espace de travail, ou laissée en automatique, en suivant le réglage du navigateur du visiteur.
• Rappelez-vous que la langue de l’interface et la langue de réponse de l’IA sont décidées séparément : l’interface suit le navigateur, la réponse suit ce que le client a tapé. Quand elles divergent, c’est la langue de la réponse que le client remarque.
• Rédigez votre message d’accueil pour chaque langue et vérifiez les textes qui entourent l’IA. Messages d’accueil, messages de transfert, avis hors horaires et formulaires avant chat sont les éléments qui restent le plus souvent obstinément en anglais au milieu d’une conversation par ailleurs fluide.

Le centre d’aide est une décision distincte

Les équipes supposent que passer au multilingue dans le chat implique de passer au multilingue dans le centre d’aide public le même jour. Ce n’est pas le cas, et l’économie est différente. Le bot répond à une question qui vient d’être posée ; le centre d’aide est une bibliothèque consultable et indexable que quelqu’un doit tenir à jour. Quatre langues, ce sont quatre sites à maintenir, et il est tout à fait raisonnable de le laisser en une ou deux langues bien plus longtemps que le bot.

Lorsque vous publiez en natif, gardez les versions liées plutôt qu’isolées. Dans CustomerEagle, un article du centre d’aide porte sa propre langue, et les traductions d’un même article peuvent être regroupées pour que l’ensemble apparaisse comme un ensemble ; c’est ce qui empêche la version allemande d’accumuler discrètement trois changements de politique de retard. Gardez aussi la maîtrise de ce qui est indexé pour les réponses de l’IA : un article destiné aux personnes n’a pas forcément à servir de source de réponse.

Mesurer par langue, là où la plupart des configurations s’arrêtent trop tôt

Un taux de résolution global masque complètement un problème propre à une langue : trois marchés qui fonctionnent et un quatrième gravement défaillant produisent un chiffre global qui ressemble à une légère lacune de contenu. Dans la plupart des outils, le remède est un travail manuel : prévoyez-le dans votre budget plutôt que d’attendre qu’un tableau de bord vous le fournisse.

• Échantillonnez plutôt qu’agréger. Vingt conversations par langue et par mois, lues par quelqu’un qui parle cette langue, valent mieux que n’importe quel tableau de bord ; c’est le seul moyen de repérer des réponses fluides, assurées et fausses.
• Regroupez les transferts par motif et par langue. Une baisse sur un marché correspond presque toujours à un article manquant propre à ce marché plutôt qu’à un problème de modèle.
• Surveillez les réponses en langue mixte : une réponse en français citant mot pour mot une phrase de politique en anglais. Cela signale un passage source trop rigide pour être traduit proprement.
• Relancez votre jeu de tests par marché, et suivez ce que chaque marché demande, pas seulement comment il le demande. Le premier sujet de votre deuxième marché ne figure souvent pas dans votre propre top 10.

Un ordre de mise en place qui fonctionne

1. Choisissez une langue source et rédigez ce contenu correctement. Un article source flou devient une réponse floue en quatre langues au lieu d’une.
2. Passez en revue chaque article à la recherche de valeurs propres à un marché et intégrez les conditions dans les phrases. Faites-le avant d’activer quoi que ce soit : c’est ce qui détermine si les réponses d’une langue à l’autre sont sûres ou dangereuses.
3. Vérifiez ce que fait réellement le réglage de langue automatique, puis rédigez des messages d’accueil par langue et contrôlez les textes de transfert et hors horaires dans chaque langue que vous servez.
4. Testez chaque marché avec un locuteur natif et des formulations réelles avant toute annonce. Évaluez d’abord la couverture, puis le ton.
5. Rédigez en natif les cinq principaux articles par marché, dans l’ordre dicté par vos résultats de test, puis mettez en place un échantillonnage mensuel par langue.

Dans cet ordre, ajouter un marché devient une décision de contenu plutôt qu’une décision de recrutement, ce qui est précisément l’objectif. Le fonctionnement côté réponses dans le produit est présenté sur la page des fonctionnalités. Le moyen le plus rapide de savoir comment votre contenu tient dans une deuxième langue est de lui poser une question dans cette langue et de lire la réponse.