# Agent qui devine mal la langue avant même de router la question du visiteur

> Tutoriel pour brancher une détection de langue fiable en amont d'un agent conversationnel connecté à un site, plutôt que de la laisser deviner.

- Auteur : Clément Hadrot
- Publié le : 2026-06-25
- Mis à jour le : 2026-06-25
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/agent-devine-mal-langue-avant-routage/

## L’essentiel

- La détection de langue doit précéder l'appel à l'agent, jamais lui être déléguée
- La locale active de Polylang est une source plus fiable que le texte brut de la question
- Un repli explicite vers la langue par défaut vaut mieux qu'une supposition silencieuse

`window.AgentConfig = { siteId: 'site-exemple', apiKey: 'cle-publique-agent' };` : cette poignée de code, chargée en pied de page d'un site multilingue français / anglais / espagnol, ne transmettait à l'origine aucune information de langue à l'agent conversationnel connecté au site. Résultat concret constaté en production : une question posée en français sur la page anglaise du site recevait parfois une réponse en anglais par défaut, l'agent devinant la langue depuis le seul texte reçu, sans tenir compte du contexte de navigation du visiteur.

Ce tutoriel détaille les quatre étapes suivies pour corriger ce comportement sur un projet WordPress utilisant Polylang, en plaçant la détection de langue en amont de l'agent plutôt qu'en la lui laissant deviner depuis un texte parfois ambigu.

## Étape 1 : identifier où l'agent reçoit actuellement la langue

Avant toute correction, il faut localiser précisément le point d'intégration entre le site et l'agent conversationnel. Sur ce projet, l'agent est intégré via un script chargé en pied de page, qui initialise une session avec un jeu de paramètres transmis au moment du chargement :

```
<script>
window.AgentConfig = {
    siteId: 'site-exemple',
    apiKey: 'cle-publique-agent'
};
</script>
```

Dans cette configuration d'origine, aucun paramètre de langue n'était transmis : l'agent recevait uniquement le texte de la question et devait, de son côté, deviner la langue à partir de ce texte seul. C'est précisément ce point qu'il fallait modifier.

## Étape 2 : récupérer la locale active côté serveur

> L'essentiel à retenir : La détection de langue doit précéder l'appel à l'agent, jamais lui être déléguée ; La locale active de Polylang est une source plus fiable que le texte brut de la question ; Un repli explicite vers la langue par défaut vaut mieux qu'une supposition silencieuse

Sur un site Polylang, la fonction `pll_current_language()` retourne le code de la langue active de la page en cours de génération, côté serveur, avant tout affichage. C'est cette valeur, et non une détection après coup côté navigateur, qui constitue la source la plus fiable : elle reflète exactement le mécanisme multilingue déjà en place sur le site, celui que le visiteur a lui-même choisi en naviguant ou qui lui a été assigné par défaut.

```
<?php
$langue_active = function_exists( 'pll_current_language' )
    ? pll_current_language()
    : substr( get_locale(), 0, 2 );
?>
```

Le repli sur `get_locale()` tronqué aux deux premiers caractères sert de garde-fou si Polylang venait à être désactivé temporairement, une situation rare mais qu'il vaut mieux anticiper plutôt que de laisser le script planter faute de fonction disponible.

## Étape 3 : transmettre cette langue à l'initialisation de l'agent

Une fois la langue récupérée côté serveur, elle est injectée directement dans la configuration JavaScript transmise à l'agent, en tant que valeur calculée à chaque chargement de page plutôt qu'en dur :

```
<script>
window.AgentConfig = {
    siteId: 'site-exemple',
    apiKey: 'cle-publique-agent',
    langue: '<?php echo esc_js( $langue_active ); ?>'
};
</script>
```

La fonction `esc_js()` échappe correctement la valeur pour un contexte JavaScript inline, une précaution nécessaire même si la valeur provient d'une source de confiance comme Polylang, par simple discipline de sécurité systématique sur toute donnée insérée dans un attribut ou un script.

## Étape 4 : vérifier que l'agent respecte bien ce paramètre, pas seulement qu'il le reçoit

Recevoir un paramètre de langue ne garantit pas qu'un agent conversationnel tiers en tienne compte pour orienter sa réponse : certaines configurations d'agent continuent, par défaut, à appliquer leur propre détection interne même quand une langue est explicitement fournie. La documentation de l'agent utilisé sur ce projet exposait une option distincte, `forceLanguage`, qu'il fallait activer explicitement pour que le paramètre transmis prime sur la détection interne :

```
<script>
window.AgentConfig = {
    siteId: 'site-exemple',
    apiKey: 'cle-publique-agent',
    langue: '<?php echo esc_js( $langue_active ); ?>',
    forceLanguage: true
};
</script>
```

Sans cette option activée, la correction des trois premières étapes restait sans effet observable : l'agent recevait bien la langue active, mais continuait à la court-circuiter avec sa propre détection interne dès qu'une question ambiguë était posée. Ce point a demandé une lecture attentive de la documentation technique de l'agent, faute de quoi le problème serait resté inexpliqué malgré une intégration apparemment correcte.

## Le test de validation

Une fois les quatre étapes en place, le test de non-régression consiste à reproduire la question d'origine, « où puis-je consulter mes factures ? », en anglais cette fois (« where can I find my invoices? »), sur la version française du site. Avant la correction, l'agent répondait en anglais dans ce cas, en cohérence avec sa détection interne basée sur le texte. Après la correction, l'agent répond en français, conformément à la langue active de la page, même si la question elle-même a été posée dans une autre langue par le visiteur.

> Un agent conversationnel intégré à un site multilingue ne doit jamais avoir à deviner une information que le site connaît déjà avec certitude. La détection de langue côté agent n'a de sens que comme filet de sécurité, jamais comme mécanisme principal quand une source fiable existe.

## Que faire si l'agent ne propose aucune option équivalente à forceLanguage

Certains agents conversationnels tiers ne proposent aucun moyen de forcer la langue de réponse, laissant leur détection interne systématiquement prioritaire. Dans ce cas, la seule option reste de contacter l'éditeur de l'agent pour signaler ce manque, ou d'envisager une solution alternative qui expose ce réglage. Intégrer un agent qui ne peut pas respecter une information de langue déjà fiable et disponible revient à accepter un point de friction structurel avec un site multilingue, un compromis qui mérite d'être évalué avant le choix de l'outil plutôt qu'après son déploiement.

## En résumé

Corriger un agent conversationnel qui devine mal la langue avant de router la question du visiteur suit quatre étapes : localiser le point d'intégration existant, récupérer la locale active via `pll_current_language()`, transmettre cette valeur à l'initialisation de l'agent, puis vérifier dans la documentation de l'agent qu'une option force bien la priorité de ce paramètre sur sa détection interne. La dernière étape est souvent la plus négligée, et pourtant celle qui rend les trois précédentes réellement efficaces.