Six files de support distinctes, sans le moindre routage automatique entre elles : c’était la situation, sur un site institutionnel accompagné pour ce projet, avant qu’un ticket mal classé par la détection automatique de Zendesk ne passe plusieurs heures en moyenne dans la mauvaise file, le temps qu’un agent identifie la langue réelle du client derrière une détection qui se basait uniquement sur la langue déclarée du navigateur du visiteur.
Ce sujet ne traite pas de la configuration de Zendesk lui-même, largement documentée par l’éditeur, mais précisément de l’intégration entre l’extension multilingue WordPress et le widget de support, pour que la langue transmise au ticket soit la langue réellement consultée sur le site, pas une approximation issue du navigateur.
Pourquoi la détection navigateur ne suffit pas
Le widget Zendesk propose une détection automatique de la langue de l’interface basée sur l’en-tête Accept-Language du navigateur. Ce réglage fonctionne pour l’interface du widget lui-même (libellés des boutons, formulaire de contact), mais ne dit rien sur la langue du contenu que le visiteur consultait au moment d’ouvrir un ticket. Un visiteur avec un navigateur configuré en anglais qui navigue volontairement sur la version française d’un site — cas fréquent chez les expatriés ou les utilisateurs multilingues — se voit proposer un widget en anglais alors qu’il souhaite un support en français, et son ticket est ensuite routé vers la mauvaise file si le routage se base sur cette même détection.
Transmettre la langue Polylang réellement active
La méthode fiable consiste à ignorer la détection automatique du widget et à transmettre explicitement la langue active du site, déterminée côté serveur par Polylang, au moment de l’initialisation du widget Zendesk :
<?php
$current_lang = function_exists( 'pll_current_language' ) ? pll_current_language( 'locale' ) : 'fr_FR';
?>
<script>
window.zESettings = {
webWidget: {
locale: '<?php echo esc_js( $current_lang ); ?>'
}
};
</script>
Ce réglage force le widget à s’afficher dans la langue réellement consultée. Il ne suffit cependant pas à lui seul pour le routage du ticket vers la bonne file d’agents : il faut aussi transmettre cette information dans les champs personnalisés du ticket créé, via l’API des champs personnalisés du widget Zendesk (zE('webWidget', 'updateSettings', ...) ou un champ de ticket dédié configuré côté administration Zendesk).
Router vers le bon groupe d’agents
Une fois la langue correctement transmise dans un champ personnalisé du ticket, la configuration côté Zendesk (déclencheurs et règles d’automatisation, hors du périmètre de cet article car propres à l’outil) peut affecter automatiquement chaque ticket au groupe d’agents compétent dans la langue concernée. C’est cette combinaison — langue transmise fidèlement depuis WordPress, règle de routage configurée côté Zendesk — qui élimine le délai d’attente lié à une réaffectation manuelle du ticket.
Le cas des visiteurs qui changent de langue en cours de navigation
Un visiteur qui commence sa navigation en anglais puis bascule vers le français avant d’ouvrir le widget doit voir son ticket refléter la langue au moment de l’ouverture, pas celle de son arrivée sur le site. Comme le widget est réinitialisé à chaque changement de page dans WordPress via Polylang, ce comportement fonctionne naturellement tant que le script d’initialisation du widget est bien exécuté à chaque chargement de page plutôt que mis en cache côté navigateur de façon trop agressive.
Vérifier que le champ personnalisé remonte bien à chaque ticket
Un point de vérification simple, souvent négligé après la mise en production, consiste à contrôler périodiquement un échantillon de tickets créés pour s’assurer que le champ de langue est bien renseigné et cohérent avec la langue du site d’origine. Un widget mis à jour côté Zendesk sans que l’équipe technique du site en soit informée peut renommer un champ personnalisé, ce qui casse silencieusement la transmission de la langue sans provoquer d’erreur visible.
- Ne jamais se fier à la détection automatique du navigateur pour le routage du ticket
- Transmettre la langue Polylang réellement active au moment de l’ouverture du widget
- Configurer le routage côté Zendesk sur un champ personnalisé fiable, pas sur la locale du widget seule
- Auditer périodiquement un échantillon de tickets pour vérifier la cohérence de la langue transmise
En résumé
Router correctement un ticket de support selon la langue du site consulté ne dépend pas d’un réglage caché dans Zendesk, mais d’une transmission fiable de l’information de langue depuis WordPress, au moment précis où le visiteur ouvre le widget. Une fois cette transmission fiabilisée, le reste du routage relève de la configuration standard de Zendesk, sans complexité technique supplémentaire côté site.
