Détecter automatiquement la langue d'un chatbot : préférences, fallbacks et choix utilisateur

Un chatbot multilingue pour site web ne devrait pas envoyer un visiteur sur la mauvaise piste linguistique dès sa première réponse. Pourtant, détecter automatiquement la langue d'un chatbot implique bien plus que de reprendre la première valeur du navigateur. Les paramètres du navigateur peuvent être obsolètes, un appareil peut être partagé et une personne peut préférer lire des contenus techniques en anglais alors que son système d'exploitation est en français.

Une solution robuste ne traite donc la détection automatique que comme un signal de départ. Le choix explicite de l'utilisateur reste prioritaire, la disponibilité de l'interface, de la base de connaissances et des processus de transfert fixe des limites, et un fallback visible évite qu'une langue apparemment adaptée ne conduise à des réponses incomplètes ou inventées.

Pourquoi la langue du navigateur n'est qu'un indice

Les navigateurs envoient souvent l'en-tête HTTP Accept-Language. Il contient des plages linguistiques et peut exprimer un ordre de priorité via des valeurs de qualité, par exemple de-AT,de;q=0.9,en;q=0.7. La norme RFC 9110 décrit expressément ces préférences comme une aide pour le choix d'une représentation, et non comme une certitude sur la personne.

Dans le navigateur, navigator.languages fournit une liste ordonnée de étiquettes de langue BCP-47 préférées. Selon MDN , les navigateurs peuvent toutefois limiter ces préférences pour des raisons de confidentialité. De plus, un navigateur peut ajouter des variantes plus générales : à partir de de-AT , la valeur de peut également devenir pertinente pour la correspondance.

La conséquence pratique pour les chatbots est claire : Accept-Language et navigator.languages sont de bons candidats pour la première proposition. Ils ne doivent cependant remplacer ni la localisation géographique ni la nationalité. Une adresse IP ne révèle aucun souhait linguistique fiable. De même, le domaine ou la langue de la page seule ne suffisent pas si un visiteur est passé délibérément à une autre version linguistique.

Une chaîne de priorités claire évite les mauvaises surprises

La sélection doit être déterministe. Un ordre attribuant un poids clair à chaque source a fait ses preuves :

1. Choix explicite lors de la session en cours : si l'utilisateur clique sur le français, la prochaine réponse du chatbot doit être en français.
2. Préférence enregistrée et toujours valide : un choix antérieur peut s'appliquer à nouveau lors d'une visite ultérieure, à condition que le stockage soit transparent et techniquement autorisé.
3. Langue de la page actuelle : le chatbot ne devrait pas s'écarter sans raison de la version linguistique sciemment ouverte.
4. Préférences du navigateur : la liste est comparée aux locales réellement prises en charge par le chatbot.
5. Langue par défaut documentée : si rien ne correspond, le système applique une langue de base choisie délibérément plutôt qu'un résultat aléatoire.

Cette chaîne sépare la détection de la décision. Elle peut être journalisée et testée : source=user, source=stored, source=page, source=browser ou source=default. Pour l'analytique, la source et la locale choisie suffisent généralement. La liste complète des langues du navigateur ne doit pas être stockée inutilement, car la norme RFC 9110 souligne les risques potentiels pour la confidentialité et le fingerprinting liés aux préférences linguistiques détaillées.

Normaliser les étiquettes BCP-47 sans perdre le sens

Les étiquettes de langue ne se composent pas seulement de deux lettres. pt-BR et pt-PT partagent une langue, mais peuvent différer en termes de tonalité, de vocabulaire, de formats et de termes juridiques. Les systèmes d'écriture peuvent aussi être décisifs. L'application doit donc normaliser syntaxiquement les étiquettes reçues avant de les vérifier par rapport à une liste explicite de locales prises en charge.

De l'étiquette spécifique au fallback sécurisé

Une correspondance pertinente tente d'abord la variante exacte. Si de-AT n'est pas disponible, la valeur de peut suivre. Ensuite, une locale standard connue et validée par l'équipe éditoriale peut s'appliquer. Le simple fait de tronquer tous les sous-tags n'est cependant pas toujours sûr. Pour les langues comportant plusieurs écritures ou des variantes très distinctes, le produit a besoin d'une association définie sciemment.

Le fallback doit être vérifié séparément sur trois niveaux : l'interface de chat est-elle traduite ? Existe-t-il des sources de connaissances adaptées ? Une équipe support humaine peut-elle prendre en charge cette langue ? Un bouton localisé ne garantit pas que la base de connaissances offre la même couverture. Pour découvrir comment séparer les sources selon la langue, la version et les accès, consultez l'article sur les filtres de métadonnées RAG pour chatbots IA.

Proposer l'automatisme, maintenir le choix utilisateur visible

La recommandation d'internationalisation du W3C associe la négociation automatique de la langue à des liens facilement accessibles vers des versions linguistiques alternatives. Si un utilisateur change lui-même de langue, ce choix doit l'emporter sur la préférence du navigateur et, si souhaité, être conservé pour les pages suivantes.

Pour un chatbot, cela signifie que la langue active doit figurer de façon bien visible dans l'en-tête du chat ou dans un menu facile d'accès. Le changement ne doit pas envoyer un brouillon en cours à l'insu de l'utilisateur. Au contraire, le texte saisi est conservé, le bot explique brièvement le changement de langue et poursuit la conversation de manière contrôlée. Si des messages antérieurs existent dans une autre langue, le système doit en préserver le sens pour le contexte, sans traduire l'intégralité de l'historique sans demande explicite.

Une formulation adaptée peut être : « Le français a été repris de cette page. Changer de langue. » En cas de fallback, l'indication peut être plus précise : « Aucune information vérifiée n'est disponible en français sur ce sujet. Je peux utiliser la source en anglais ou vous transférer au support. » L'utilisateur comprend ainsi pourquoi la langue ou la profondeur de réponse change.

Séparer langue de la page, langue du chat et locale du contenu

Trois valeurs sont souvent regroupées à tort dans un champ unique :

• Langue de la page : la langue principale du document HTML ;
• Langue du chat : la langue dans laquelle l'interface et les réponses apparaissent ;
• Locale du contenu : la variante à partir de laquelle le chatbot est autorisé à extraire des informations étayées.

Ces valeurs peuvent être identiques, mais ce n'est pas une obligation. Un utilisateur francophone peut poser une question en français sur une page produit en anglais. Le bot peut répondre en français tout en indiquant clairement une source originale en anglais. Il ne devrait cependant pas prétendre avoir utilisé une source en français si seule la réponse a été traduite.

Pour l'accessibilité, la langue du document et du contenu doit être correctement déclarée. La technique W3C H57 décrit l'attribut langsur l'élément htmlafin que les lecteurs d'écran, entre autres, puissent traiter la prononciation et la syntaxe de manière appropriée. Si une section spécifique change de langue, cette zone nécessite également un marquage adapté. D'autres vérifications sont regroupées dans la liste de contrôle WCAG pour chatbots de site web.

Le cache et les URL doivent respecter la décision linguistique

Toute sélection de contenu côté serveur basée sur Accept-Language doit prendre en compte la stratégie de cache. La norme RFC 9110 explique que Vary: Accept-Language signale aux caches que cet en-tête a influencé la représentation. Sans cette séparation, un cache peut fournir la version allemande à un visiteur anglophone.

Pour les contenus publics et indexables, des URL stables spécifiques à chaque langue sont souvent plus faciles à auditer et à partager. La détection automatique peut alors rediriger vers une URL appropriée sans masquer des contenus différents sous la même adresse. Dans le chat lui-même, la locale doit faire partie de l'état de la session et de chaque requête côté serveur. Un changement de langue doit mettre à jour simultanément les clés de cache, les filtres de recherche documentaire et la génération de réponses.

Les valeurs formatées font également partie de cet accord. Les dates, nombres, devises et fuseaux horaires ne découlent pas automatiquement de la langue du texte. Le guide sur la localisation des réponses de chatbot explique comment traiter ces données de manière séparée et cohérente.

Les fallbacks ne doivent pas masquer les lacunes de contenu

L'erreur la plus risquée est un changement silencieux de la base de connaissances. Si aucun article en français n'existe pour répondre à une question posée en français, le bot peut s'appuyer sur une source en anglais si le produit le permet. Il doit toutefois vérifier la source, la fraîcheur et les autorisations de la même manière que pour une correspondance directe.

Une matrice de fallback sécurisée contient au minimum : locale demandée, locale UI disponible, locale contenu disponible, locale de remplacement autorisée, mode de traduction et cible de transfert. Le résultat n'est pas toujours une réponse. Pour les sujets sensibles ou très dépendants du contexte, l'indication « aucune information vérifiée dans cette langue » est préférable à une traduction fluide mais non étayée. L'article sur les fallbacks en cas de lacunes de connaissances décrit comment interagissent incertitude et transfert.

Cas de test pour la logique linguistique

Un jeu de tests réduit et systématique détecte plus d'erreurs qu'une simple vérification de navigateur. Il devrait couvrir au moins les cas suivants :

• de-AT est proposé, mais seule la valeur de;
• la première préférence du navigateur n'est pas disponible, mais la deuxième l'est ;
• le choix de l'utilisateur contredit la langue de la page et du navigateur ;
• la préférence enregistrée renvoie vers une locale désormais supprimée ;
• l'interface est présente, mais pas la base de connaissances ou le transfert ;
• le changement de langue survient au milieu d'une conversation avec du texte non envoyé ;
• le cache fournit bien la nouvelle locale après le changement ;
• le lecteur d'écran détecte correctement la langue de la page et de la section ;
• les analyses enregistrent la source du choix et le fallback, sans stocker de liste de préférences inutilement détaillée.

Pour chaque combinaison, les équipes doivent consigner la locale attendue, la source de la décision, l'indication visible et l'espace de contenu autorisé. En complément, chaque langue nécessite des tests manuels ciblés. La complétude et la qualité des réponses ne se mesurent pas à la seule présence d'une ligne de traduction.

Checklist d'installation pratique

1. Inventorier séparément toutes les locales gérées pour l'UI, le contenu et le transfert.
2. Documenter une chaîne de priorités claire entre choix utilisateur, choix enregistré, page, navigateur et valeur par défaut.
3. Définir la correspondance BCP-47, y compris les exceptions régionales et d'écriture.
4. Rendre le changement de langue visible et sans perte de saisie.
5. Limiter les fallbacks en fonction de la couverture, de la fraîcheur et des autorisations des sources.
6. lang, les URL spécifiques à la langue, les balises canonicals et le comportement du cache.
7. Ne stocker que les données analytiques nécessaires et fixer leur durée de conservation.
8. Tester sur ordinateur, mobile, clavier et lecteur d'écran avec des listes de préférences réalistes.

La décision produit centrale ne consiste donc pas à se demander : « Quelle est la langue de ce visiteur ? » Elle réside dans cette question : « Quelle langue a été demandée, quels contenus sont disponibles de manière fiable pour celle-ci et comment expliquer un chemin de remplacement nécessaire ? » En répondant séparément à ces trois questions, on obtient un chatbot qui démarre de manière utile et automatique tout en laissant le contrôle à l'utilisateur.

Sources

• RFC 9110 : Accept-Language, Vary et confidentialité
• MDN : Navigator.languages
• W3C Internationalization : Guiding users to translated pages
• W3C WAI : Déclarer la langue du document avec l'attribut lang