# Polylang : la clé de cache qui oublie parfois la langue du visiteur > Un cache de page mal configuré face à un site multilingue Polylang peut afficher la mauvaise langue à un visiteur. Fonctionnement de la détection de langue et pièges de son interaction avec le cache. - Auteur : WordPress Développement - Publié le : 2021-01-11 - Mis à jour le : 2021-01-11 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/polylang-cache-page-langue-visiteur/ ## L’essentiel - Polylang détermine la langue par l'URL, un cookie ou l'en-tête Accept-Language selon le réglage - Un cache de page qui ignore cette variable peut mélanger les langues servies - La clé de cache doit intégrer explicitement la langue courante Deux visiteurs, deux langues de navigateur différentes, une seule et même URL sans préfixe de langue dans le chemin : c'est le scénario qui révèle le plus souvent un problème d'interaction entre Polylang et un cache de page, quand la structure d'URL choisie ne distingue pas les langues visuellement. ## Comment Polylang détermine la langue affichée Polylang propose plusieurs structures d'URL pour un site multilingue : un préfixe de langue dans le chemin (`/fr/`, `/en/`), des domaines ou sous-domaines distincts, ou une racine partagée où la langue est déterminée autrement. Dans ce dernier cas, la détection s'appuie sur un cookie posé lors d'un précédent choix de langue, ou à défaut sur l'en-tête HTTP `Accept-Language` envoyé par le navigateur, correspondant à la préférence linguistique du visiteur. Cette mécanique fonctionne bien tant qu'aucun cache ne s'intercale entre le visiteur et WordPress. Le problème survient dès qu'un cache de page enregistre une réponse générée pour un cookie ou un en-tête donné, puis la ressert telle quelle à un visiteur différent, sans réévaluer la langue. ## Le piège : une clé de cache qui ignore la langue Un cache de page construit sa clé, par défaut, à partir de l'URL demandée. Si l'URL ne contient pas la langue de façon visible, la clé de cache est identique pour un visiteur francophone et un visiteur anglophone arrivant sur la même URL de racine. Le premier arrivé impose sa langue à tous les suivants, jusqu'à expiration du cache. > L'essentiel à retenir : Polylang détermine la langue par l'URL, un cookie ou l'en-tête Accept-Language selon le réglage ; Un cache de page qui ignore cette variable peut mélanger les langues servies ; La clé de cache doit intégrer explicitement la langue courante Ce piège reste invisible en développement, où un seul poste de test consulte généralement le site avec les mêmes préférences de navigateur d'une fois sur l'autre. Il n'apparaît qu'en production, avec une diversité réelle de visiteurs, et se manifeste par des signalements confus : « le site s'affiche parfois dans la mauvaise langue », sans schéma reproductible évident pour qui ne connaît pas la cause. ## Cas d'usage où le risque est le plus élevé - Structure d'URL à racine partagée, sans préfixe de langue ni sous-domaine dédié. - Détection reposant sur l'en-tête `Accept-Language` plutôt que sur un cookie explicite. - Cache de page à durée de vie longue, qui amplifie la durée pendant laquelle une mauvaise langue reste servie. ## La correction : rendre la langue explicite dans la clé de cache La solution la plus robuste consiste à adopter une structure d'URL avec préfixe de langue visible, ce qui rend la langue partie intégrante de l'URL elle-même et donc de la clé de cache par défaut de la plupart des solutions de cache. Quand ce choix n'est pas possible pour des raisons de référencement déjà en place, il faut explicitement faire varier la clé de cache selon le cookie de langue de Polylang, généralement nommé selon le préfixe défini dans les réglages du plugin. Sur un cache géré par un serveur web, cela se traduit par une règle de variation explicite sur ce cookie plutôt que sur l'en-tête `Accept-Language`, ce dernier étant trop variable d'un visiteur à l'autre pour former une clé de cache exploitable sans explosion du nombre de variantes stockées. ## Comment vérifier concrètement le comportement en place La vérification la plus fiable consiste à modifier manuellement la préférence de langue du navigateur, ou à supprimer le cookie de langue posé par Polylang, puis à recharger plusieurs fois la même URL de racine partagée en observant l'en-tête indiquant si la réponse provient du cache ou d'une génération fraîche. Si la langue affichée reste identique quel que soit le cookie envoyé, la clé de cache ignore effectivement la langue, et le correctif décrit plus haut doit être appliqué avant toute mise en production. Un test complémentaire consiste à consulter les statistiques du cache lui-même, quand l'outil utilisé les expose : un nombre de variantes stockées pour une même URL cohérent avec le nombre de langues actives sur le site est un bon indicateur que la variation fonctionne comme prévu, alors qu'une seule variante stockée pour plusieurs langues actives trahit le problème. ## Ce que ce point ne couvre pas Le référencement multilingue, les balises `hreflang` et la structure des permaliens par langue relèvent d'un chantier distinct, purement lié au référencement, et ne sont pas traités ici : la question posée est uniquement celle de la cohérence entre le cache et la langue réellement affichée. > Un site multilingue sans préfixe de langue visible dans l'URL doit traiter la langue comme une variable de cache à part entière, au même titre que l'appareil ou la connexion. ## En résumé L'interaction entre Polylang et un cache de page se joue entièrement sur un point : la langue fait-elle ou non partie de la clé de cache ? Une structure d'URL avec préfixe de langue règle la question par construction ; une racine partagée exige une configuration explicite du cache sur le cookie de langue, faute de quoi certains visiteurs verront un site figé dans une langue qui n'est pas la leur.