Un client a signalé un comportement déroutant : la première visite d’un utilisateur affichait la bonne langue selon les réglages de son navigateur, mais un deuxième visiteur arrivant juste après, sur le même appareil partagé dans un cybercafé, se retrouvait avec la langue du premier. Le site était pourtant configuré correctement, testé en local, sans erreur visible dans les réglages de Polylang. Le coupable ne se trouvait pas dans l’extension multilingue, mais dans le cache de page installé en amont.
Ce type de panne touche presque tous les sites multilingues dès qu’un cache de page entre en jeu — que ce soit une extension comme WP Rocket, un cache serveur type Varnish, ou un CDN comme Cloudflare. Comprendre pourquoi demande de revenir sur la mécanique même de la détection de langue.
Comment la détection de langue fonctionne, normalement
Polylang et WPML détectent la langue d’un visiteur de plusieurs façons possibles : l’URL elle-même (préfixe /en/), un sous-domaine dédié, ou — c’est le cas qui pose problème — un cookie déposé lors de la première visite, qui mémorise la langue choisie pour les visites suivantes sur la page d’accueil sans préfixe de langue.
Ce cookie fonctionne très bien sans cache : chaque requête PHP est traitée individuellement, WordPress lit le cookie, exécute la logique de redirection ou d’affichage correspondante, et sert la bonne langue. Le problème survient dès qu’une page de cache s’interpose entre le visiteur et WordPress.
Pourquoi le cache casse la mécanique
Un cache de page fonctionne sur un principe simple : la première requête vers une URL donnée génère une page HTML, que le cache stocke et resert ensuite à tous les visiteurs suivants sans repasser par PHP, pour économiser des ressources serveur. Ce mécanisme suppose implicitement que la même URL doit produire le même contenu pour tout le monde.
Or la détection par cookie viole justement ce principe : la même URL (la page d’accueil sans préfixe) doit produire un contenu différent selon la langue mémorisée dans le cookie du visiteur. Le cache, lui, ne regarde pas les cookies par défaut : il sert la première version générée, quelle que soit la langue du visiteur suivant.
- Premier visiteur, cookie « anglais » : la page d’accueil est générée en anglais et mise en cache.
- Deuxième visiteur, cookie « français » ou aucun cookie : le cache sert quand même la version anglaise, sans jamais repasser par la logique PHP de Polylang.
Le diagnostic : comment confirmer que c’est bien le cache
Le test le plus rapide consiste à vider entièrement le cache, puis à visiter le site en navigation privée avec deux langues de navigateur différentes, sans jamais recharger la même page deux fois avant d’avoir changé de langue. Si le comportement redevient cohérent cache vidé, la cause est confirmée.
Un second test consiste à inspecter les en-têtes de réponse HTTP de la page concernée, à la recherche d’un en-tête indiquant une réponse servie depuis le cache (X-Cache: HIT chez beaucoup d’extensions, ou un en-tête équivalent selon la solution utilisée). Une réponse « HIT » sur une page censée varier selon le visiteur confirme le diagnostic.
Trois solutions qui fonctionnent en pratique
1. Exclure la page d’accueil sans préfixe du cache
La solution la plus simple, mais coûteuse en performance : ne pas mettre en cache la page d’accueil non préfixée, en la laissant repasser par PHP à chaque requête. Fonctionne bien sur un site à faible trafic, moins bien dès que cette page devient un point d’entrée massif.
2. Rediriger systématiquement vers une URL préfixée
La solution la plus robuste consiste à ne jamais laisser de contenu accessible sans préfixe de langue dans l’URL : une redirection immédiate vers /fr/ ou /en/ selon la détection initiale, effectuée une seule fois, puis chaque URL préfixée devient parfaitement cachable puisqu’elle correspond à une seule langue, de façon stable.
// Exemple de logique de redirection, une seule fois par visite
add_action('template_redirect', function () {
if (is_front_page() && !isset($_COOKIE['lang_redirected'])) {
$lang = pll_default_language(); // ou détection navigateur
setcookie('lang_redirected', '1', time() + 3600, '/');
wp_redirect(home_url('/' . $lang . '/'));
exit;
}
});
3. Faire varier le cache selon un cookie, côté serveur ou CDN
Certains caches serveur (Varnish notamment) et certains CDN permettent de configurer une clé de cache incluant la valeur d’un cookie précis, pour stocker une version distincte du cache par langue détectée. C’est la solution la plus performante, mais elle demande un accès à la configuration serveur, ce qui n’est pas toujours possible en hébergement mutualisé.
Sur nos projets, la redirection systématique vers une URL préfixée reste la solution la plus simple à maintenir dans la durée, même si elle ajoute une requête HTTP supplémentaire à la toute première visite.
Ce qui ne fonctionne jamais
Vider le cache manuellement après chaque plainte n’est pas une solution : le problème revient dès que le cache se reconstitue. De même, désactiver totalement le cache sur un site multilingue à fort trafic n’est pas viable, la charge serveur devenant vite ingérable. La seule vraie réponse est structurelle : soit éliminer la variabilité (redirection vers URL préfixées), soit apprendre au cache à gérer cette variabilité (clé de cache par cookie).
En résumé
Un site multilingue et un cache de page ne sont pas incompatibles, mais ils ne cohabitent jamais sans réglage explicite. La cause de ce type de panne est presque toujours la même : une page sans préfixe de langue, dont le contenu varie selon un cookie que le cache ignore par construction. Diagnostiquer vite ce cas précis évite des heures perdues à chercher une erreur de configuration côté Polylang ou WPML qui, en réalité, n’existe pas.
