Un fabricant de mobilier de jardin vendant en France, en Belgique et aux Pays-Bas recevait, chaque semaine, quelques signalements de visiteurs affirmant voir le site s’afficher dans la mauvaise langue, sans lien apparent avec leur pays de connexion. Le comportement semblait aléatoire : parfois la page s’affichait correctement en néerlandais, parfois en français, pour la même URL selon le moment de la visite.
L’origine du problème s’est révélée être une interaction mal anticipée entre WPML, qui gère la langue active via un cookie et un paramètre d’URL selon la configuration retenue, et un plugin de cache de page classique, configuré avec Varnish en amont, qui ne tenait pas compte de cette variation lors de la construction de sa clé de cache.
Comprendre le mécanisme de langue de WPML
Sur ce site, la configuration WPML retenue utilisait des sous-répertoires par langue pour les URL, mais complétait cette logique avec un cookie de préférence de langue, utilisé notamment pour rediriger un visiteur revenant sur la racine du site vers sa langue précédemment choisie. Certaines pages, comme la page d’accueil sans préfixe de langue explicite, dépendaient donc de ce cookie pour déterminer quelle version linguistique afficher.
Pourquoi le cache aggrave ce comportement
Un cache de page classique construit sa clé de cache à partir de l’URL demandée, parfois enrichie de quelques paramètres jugés pertinents, mais ignore par défaut les cookies, considérés comme propres à chaque visiteur et donc généralement exclus de la logique de mise en cache partagée. Sur ce site, cela signifiait que la première version de la page d’accueil générée, disons en français, était mise en cache et servie telle quelle à tous les visiteurs suivants, y compris ceux dont le cookie indiquait une préférence néerlandaise, jusqu’à expiration naturelle du cache.
Le diagnostic pas à pas
Le comportement a été reproduit de façon fiable en videant le cache, puis en visitant la page d’accueil avec un cookie de langue néerlandais actif dans le navigateur, suivi immédiatement d’une seconde visite depuis un navigateur en navigation privée sans cookie de langue défini. La seconde visite affichait bien la version néerlandaise, mise en cache par la première requête, confirmant le mécanisme en cause.
La configuration corrective
La solution a consisté à indiquer explicitement à Varnish, ainsi qu’au plugin de cache côté WordPress, d’intégrer le cookie de langue WPML dans la clé de cache, afin que chaque variante linguistique dispose de sa propre entrée de cache indépendante :
sub vcl_hash {
if (req.http.Cookie ~ "wp-wpml_current_language=([^;]+)") {
set req.http.X-Langue-Cache = regsub(req.http.Cookie, ".*wp-wpml_current_language=([^;]+).*", "\1");
hash_data(req.http.X-Langue-Cache);
}
return (lookup);
}Côté configuration du plugin de cache WordPress, un réglage équivalent a permis d’ajouter ce même cookie à la liste des éléments de variation pris en compte pour la génération de la clé de cache interne, évitant ainsi toute incohérence entre les deux couches de cache actives sur ce site.
Vérifier après correctif
- Reproduire le scénario initial : vider le cache, visiter avec un cookie de langue différent, vérifier que chaque langue obtient bien sa propre version en cache.
- Vérifier le taux de succès du cache après changement, une clé de cache plus fine réduit légèrement ce taux, un compromis attendu et acceptable ici.
- Surveiller les signalements de visiteurs dans les semaines suivant le déploiement, qui sont retombés à zéro après ce correctif.
Ce que ce cas ne traite pas
Ce diagnostic porte spécifiquement sur l’interaction entre WPML et un cache de page à la clé insuffisamment fine. La question de la traduction automatique par intelligence artificielle des contenus, sujet distinct en plein essor pour les sites multilingues, ne fait pas partie de ce cas.
En résumé
Un site multilingue WPML combiné à un cache de page agressif impose de vérifier précisément quels éléments de la requête déterminent la langue affichée, cookie compris, et de s’assurer que la clé de cache en tient compte. Un oubli sur ce point précis peut rester invisible pendant longtemps, jusqu’à ce que les signalements de visiteurs finissent par en révéler la cause.
