Comment concevoir la sélection de langue d’un WebChat multilingue sans orienter les clients vers le mauvais service
Un WebChat multilingue doit permettre de choisir à la fois une interface lisible et la langue dans laquelle obtenir de l’aide. Découvrez comment recueillir clairement cette préférence, ne router que vers des équipes disponibles et proposer un relais humain transparent lorsqu’aucune file correspondante n’est accessible.
Traitez la langue du widget et la langue d’assistance comme deux choix distincts
La sélection de langue d’un WebChat multilingue implique deux choix opérationnels différents. Le premier est la langue d’affichage du widget : celle utilisée pour les boutons, les invites, les textes de confidentialité, les messages d’erreur et les autres éléments d’interface. Le second est la langue d’assistance préférée du client : celle dans laquelle il souhaite expliquer son problème et recevoir l’aide d’une personne.
Ces choix peuvent coïncider, mais il ne faut pas présumer qu’ils coïncident. Un client peut préférer une interface en anglais tout en demandant une assistance en arabe, utiliser un navigateur partagé configuré dans une autre langue, ou choisir une langue d’interface familière pour une tâche technique tout en souhaitant parler à un agent dans la langue qu’il maîtrise le mieux.
Concevez et stockez ces informations dans des champs distincts. La « langue d’affichage du widget » contrôle la présentation. La « langue d’assistance préférée » est une préférence de service déclarée, qui peut être utilisée pour le routage lorsque les règles de couverture le permettent. Séparer ces champs évite qu’une interface lisible devienne une promesse non tenue de couverture humaine dans cette langue.
- N’appelez pas simplement un réglage d’interface « Langue » s’il peut influencer le routage ; distinguez « Langue d’affichage du chat » et « Langue d’assistance préférée ».
- Affichez les langues de service prises en charge avant que le client n’emprunte un parcours propre à une langue.
- Permettez au client de modifier l’un ou l’autre choix pendant la conversation.
- N’assimilez pas un widget traduit à la garantie d’une assistance par un opérateur humain parlant couramment cette langue.
Ne devinez pas la langue d’assistance préférée d’un client
Les paramètres linguistiques du navigateur peuvent être utiles comme indication de présentation, mais ils ne constituent pas une déclaration définitive de la préférence de lecture ou d’assistance d’une personne. Les navigateurs peuvent envoyer une liste ordonnée de préférences Accept-Language, et les personnes peuvent utiliser des appareils partagés, des paramètres hérités ou une configuration de navigateur qui ne correspond pas au contenu qu’elles souhaitent lire.
La localisation est également un indicateur peu fiable. La localisation d’une personne à partir de son adresse IP ne correspond pas nécessairement à la langue qu’elle préfère lire ou utiliser pour l’assistance. Les noms, les champs de compte et les messages précédents sont eux aussi des raccourcis risqués : ils peuvent être incomplets, obsolètes, ambigus ou sensibles.
Utilisez tout signal technique uniquement pour suggérer une langue d’affichage par défaut réversible. Proposez toujours un choix visible et n’utilisez pas une langue déduite seule pour placer quelqu’un dans une file linguistique spécifique. Le routage doit reposer sur un choix explicite et une couverture opérationnelle vérifiée.
- Utilisation sûre : présélectionner une langue d’affichage du widget tout en laissant le choix visible et facile à modifier.
- Utilisation non sûre : router selon le pays, l’adresse IP, le nom ou l’en-tête du navigateur sans confirmation.
- Évitez de demander aux agents de déduire une capacité linguistique à partir de champs liés à l’identité.
- Si le client écrit dans une autre langue, permettez à un agent ou à un flux de proposer une mise à jour de préférence plutôt que de modifier silencieusement le routage.
Publiez une politique des langues prises en charge avant de créer les routes
Un menu de langues constitue un engagement de service. Définissez ce que signifie concrètement chaque langue répertoriée avant de l’afficher dans le widget. La politique doit couvrir les services, les horaires d’ouverture, les niveaux de service, la responsabilité des transferts et ce qui se passe lorsque des opérateurs qualifiés ne sont pas disponibles.
Un modèle utile comporte trois catégories. Les langues entièrement prises en charge bénéficient d’une couverture assurée par des personnes formées ou désignées pour le service et le créneau concernés. Les langues à prise en charge limitée peuvent n’être disponibles que pour certains sujets, services ou horaires. Les langues de relais sont celles dans lesquelles l’équipe peut proposer une alternative clairement décrite, comme une file générale, une option de contact ou une demande de suivi ultérieur conformément à votre propre politique opérationnelle.
Maintenez l’alignement entre le menu public et cette politique. Si une langue n’est disponible qu’à certaines heures, indiquez-le avant que le client ne s’engage dans ce parcours. Si l’entreprise ne peut pas fournir d’assistance dans la langue demandée, ne présentez pas un texte automatisé, une file générique ou un widget traduit comme l’équivalent d’une assistance humaine qualifiée dans cette langue.
- Pour chaque langue, désignez le responsable des décisions de couverture.
- Définissez la couverture par service, et non uniquement à l’échelle globale de l’entreprise.
- Documentez les horaires, les exigences de compétence des opérateurs, les règles de débordement et le message de relais.
- Révisez la liste des langues chaque fois que les effectifs, les services ou les horaires changent.
Rendez la sélection de langue claire, accessible et peu contraignante
Utilisez un langage simple ainsi que les noms et écritures natifs des langues dans le sélecteur, comme « Español », « Français » et « العربية ». Les noms natifs aident les clients à reconnaître leur choix sans devoir comprendre la langue actuelle de l’interface. Si utile, ajoutez une explication dans la langue de l’interface actuelle, mais ne remplacez pas le nom natif.
Chaque contrôle doit disposer d’un libellé indiquant sa fonction et associé au contrôle pour les technologies d’assistance. Assurez-vous que l’ensemble du sélecteur fonctionne au clavier, y compris l’ouverture du contrôle, le déplacement parmi les choix, la sélection d’une option, sa fermeture et le passage à l’étape suivante. Conservez un indicateur de focus visible et évitez tout menu qui piège le focus.
Définissez correctement la langue déterminable par programmation du contenu du widget et identifiez les changements de langue significatifs dans le contenu, le cas échéant. Testez le sélecteur sur des écrans mobiles étroits et avec des noms de langues longs afin que les options ne soient ni tronquées, ni masquées, ni difficiles à activer.
- Utilisez un contrôle libellé, par exemple « Choisissez votre langue d’assistance ».
- Présentez les noms natifs ; n’utilisez pas les drapeaux comme seul indicateur de langue.
- Conservez une option par défaut ou de relais lorsque la langue demandée n’est pas disponible.
- Proposez « Continuer dans la langue actuelle » ou une option équivalente qui ne bloque pas.
- N’exigez pas une sélection de langue pour accéder à une aide humaine urgente, sauf si cette exigence est réellement nécessaire au service.
Ne recueillez que la préférence nécessaire à la fourniture du service
Expliquez pourquoi vous posez la question. Un message concis tel que « Nous utilisons votre choix pour tenter de vous mettre en relation avec la bonne équipe d’assistance pour cette conversation » fournit une raison liée à la prestation du service sans exagérer les capacités du système. La clarté de l’objectif aide les équipes à déterminer quelles informations sont nécessaires et soutient la minimisation des données.
Habituellement, la donnée nécessaire est une langue d’assistance préférée choisie dans une liste contrôlée, accompagnée d’une option « Autre / J’ai besoin d’aide pour choisir » lorsque cela est approprié. Évitez de demander la nationalité, l’origine ethnique, le lieu de naissance ou d’autres informations liées à l’identité pour prendre une décision de routage. Ces données ne sont pas nécessaires pour établir une préférence conversationnelle.
Au cours d’un même processus, ne demandez pas aux clients de répéter une langue qu’ils ont déjà indiquée. Affichez le choix enregistré pour confirmation ou permettez de le sélectionner à nouveau lorsqu’il est nécessaire. Cela réduit les frictions sans imposer que la préférence soit conservée entre des sessions distinctes.
- Indiquez l’objectif au moment de la collecte.
- Recueillez une préférence linguistique, et non des données d’identité.
- Faites en sorte que les parcours « Je ne sais pas » et « Autre » aboutissent à une action plutôt qu’à une impasse.
- Donnez aux clients un moyen de corriger une sélection erronée.
- Définissez les pratiques de conservation, d’accès et de révision conformément aux obligations et politiques de confidentialité applicables à votre organisation.
Ne routez que lorsque la règle de couverture est satisfaite
Une règle de routage par langue exige davantage qu’une étiquette linguistique. Elle nécessite un service éligible, un horaire, une exigence de compétence de l’opérateur et une condition de disponibilité actuelle. Dans les termes d’un centre de contact, la langue demandée est une propriété de la demande ; les opérateurs qualifiés sont éligibles selon leurs compétences ou capacités ; et la disponibilité détermine si un opérateur éligible peut recevoir une nouvelle conversation.
Dans webchat.vip, les équipes peuvent organiser les opérateurs, les services, le routage, les horaires et les niveaux de service dans une boîte de réception partagée pour les conversations WebChat et WhatsApp. Utilisez ces contrôles opérationnels pour mettre en œuvre uniquement les règles de routage que votre équipe peut maintenir. Par exemple, « assistance de facturation en espagnol pendant les horaires publiés » est plus sûr qu’une règle générale qui envoie toute préférence pour l’espagnol vers un service ne disposant d’aucun opérateur qualifié disponible.
Ne créez pas une file uniquement parce qu’une langue est apparue dans un menu. Testez toute la chaîne : préférence déclarée, service correspondant, couverture par des opérateurs éligibles, état de l’horaire, disponibilité, condition de débordement et message adressé au client.
- Routez en fonction d’une préférence explicite et d’une condition de couverture active.
- Faites correspondre la couverture linguistique au service ou au sujet demandé.
- N’attribuez pas des conversations à des opérateurs qui n’ont pas été approuvés pour ce rôle de service linguistique.
- Définissez un délai d’attente maximal ou un déclencheur de débordement selon votre propre politique de service.
- Maintenez la responsabilité du relais : un débordement n’est pas terminé tant qu’une personne ou une prochaine étape viable n’en est pas responsable.
Créez un relais transparent plutôt qu’un mauvais routage silencieux
Le mode de défaillance critique survient lorsqu’un client choisit une langue et est placé silencieusement dans une file inadaptée. Cela entraîne des explications répétées, des transferts évitables, des attentes plus longues et une perte de confiance. Un relais doit indiquer au client ce qui est disponible maintenant, ce qui ne l’est pas et comment joindre une personne ou poursuivre sa demande.
Un bon relais peut proposer une file humaine dans une langue générale, une demande d’attendre la prochaine période de couverture publiée ou un autre moyen de contact humain que votre organisation exploite réellement. Le libellé doit distinguer une file propre à une langue d’une assistance générale. Ne dites jamais qu’un agent parlera la langue demandée, sauf si la règle d’attribution confirme cette condition.
Lorsque l’automatisation n’a pas fourni de réponse satisfaisante après plusieurs tentatives, rendez accessibles les coordonnées d’un contact humain ou un transfert vers une personne. Un seuil pratique est de trois tentatives infructueuses, associé à une option visible « Parler à une personne ». Si personne n’est disponible, indiquez quand l’assistance humaine devrait être disponible au lieu de laisser les clients dans une boucle automatisée indéfinie.
- Informez immédiatement le client lorsque la langue choisie n’est pas disponible pour le service ou l’horaire sélectionné.
- Proposez une prochaine action réelle : file humaine générale, heure de retour publiée ou autre moyen de contact doté de personnel.
- Gardez un parcours « Parler à une personne » visible et permettez de fermer puis de rappeler le chat.
- Enregistrez le motif du relais : absence de couverture, hors horaires, aucun opérateur qualifié disponible ou changement demandé par le client.
- Escaladez les cas urgents, impliquant une vulnérabilité, une réclamation, la sécurité ou des échecs répétés vers le responsable humain désigné conformément à vos procédures internes.
Utilisez l’automatisation pour aider au choix et au transfert, pas pour piéger les clients
Les flux automatisés de webchat.vip peuvent envoyer des messages et des fichiers, recueillir des réponses validées, créer des embranchements, transférer et passer les conversations à des personnes. Utilisez cette capacité pour présenter les choix linguistiques, confirmer la préférence sélectionnée, vérifier la condition de routage appropriée et transmettre le message correspondant de file ou de relais.
La validation doit empêcher les valeurs inutilisables, et non forcer un client à fournir une réponse artificielle. Un sélecteur contrôlé est généralement préférable au texte libre pour le routage, mais il doit inclure une issue pour les clients dont la langue est absente ou qui ne peuvent pas se décider. Si une saisie en texte libre est utilisée, ne la traitez pas comme un code de routage fiable sans règle de révision.
Concevez pour les interruptions. Les clients peuvent arriver avec un problème différent, modifier leur langue sélectionnée ou demander immédiatement à parler à une personne. À chaque embranchement, conservez l’accès à un parcours humain et évitez les invites circulaires, comme demander à plusieurs reprises la même langue après que le client a répondu.
- Confirmez la langue d’assistance choisie dans un message court et compréhensible.
- Transmettez ce choix comme contexte de conversation à l’équipe qui reçoit la demande.
- Proposez une action visible d’escalade vers un humain à chaque étape automatisée.
- Après des tentatives d’automatisation répétées et infructueuses, cessez de réessayer le même parcours et proposez une aide humaine.
- Testez les réponses non valides, vides, modifiées et concernant une langue indisponible.
Questions fréquentes
Le WebChat doit-il router automatiquement les clients selon la langue du navigateur ?
Non. La langue du navigateur peut constituer un indice réversible pour la langue d’affichage du widget, mais elle n’est pas une indication fiable de la langue d’assistance préférée du client. Laissez le client choisir, puis routez uniquement si les règles d’effectif et d’horaires permettent ce choix.
Pouvons-nous utiliser le pays ou la localisation IP pour sélectionner une langue d’assistance ?
N’utilisez pas la localisation comme signal déterminant. Elle ne correspond pas nécessairement à la langue de lecture ou d’assistance préférée d’une personne. Proposez un choix de langue explicite et conservez un relais clair.
Que doit-il se passer lorsqu’aucun agent n’est disponible dans la langue demandée ?
Informez rapidement le client. Proposez la prochaine option dotée de personnel que votre organisation peut réellement fournir, comme une file d’assistance humaine générale, une heure de disponibilité future publiée ou un autre moyen de contact doté de personnel. Ne transférez pas silencieusement la conversation vers une file inadaptée.
Comment les préférences linguistiques doivent-elles être stockées dans une conversation ?
Conservez la langue d’assistance préférée déclarée comme contexte de conversation utile, distinct de la langue d’affichage du widget. Permettez aux clients de la modifier, transmettez-la à l’équipe qui reçoit la demande et appliquez des règles de révision documentées lorsque la conversation écrite ou la demande explicite du client signale une exception.
Que devons-nous mesurer après le lancement ?
Utilisez les journaux de conversation, les analyses opérationnelles, les évaluations et les rapports exportables pour examiner l’exactitude du routage selon la langue déclarée, les transferts après la sélection linguistique, les explications répétées, les résultats d’attente, les motifs de relais, les abandons et le recours à l’escalade humaine. Ne traitez pas la préférence linguistique comme un indicateur de l’identité ou de la valeur d’un client.
Quelle est la checklist de lancement pour la sélection de langue d’un WebChat multilingue ?
Confirmez la politique des langues prises en charge ; séparez les réglages de langue d’affichage et de langue d’assistance ; vérifiez les libellés, l’utilisation au clavier, le comportement avec les lecteurs d’écran, la mise en page mobile et les métadonnées linguistiques ; testez les horaires et la couverture des opérateurs éligibles par service ; testez le relais hors horaires et sans opérateur ; vérifiez l’escalade humaine après des échecs répétés de l’automatisation ; testez les changements de préférence et les conversations multilingues ; révisez les formulations destinées aux clients afin d’éviter les promesses non prises en charge ; et attribuez des responsables pour le routage, les effectifs, la confidentialité, l’accessibilité et le reporting continu.
Sources et lectures complémentaires
Références primaires et reconnues utilisées pour vérifier la base factuelle de ce guide.
- Guiding users to translated pages — W3C Internationalization
- When to use language negotiation — W3C Internationalization
- Internationalization Quick Tips for the Web — W3C Internationalization
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- Labeling Controls — W3C Web Accessibility Initiative
- Understanding Success Criterion 3.2.6: Consistent Help — W3C Web Accessibility Initiative
- Understanding Success Criterion 3.3.7: Redundant Entry — W3C Web Accessibility Initiative
- Core concepts: Routing — Twilio Documentation
- Configure Skill-Based Routing — Twilio Documentation
- Principle (b): Purpose limitation — Information Commissioner's Office