Vérifier qu’un cache de page sert bien la bonne langue avant chaque campagne

Une campagne publicitaire multilingue programmée sur trois marchés européens simultanément met à l’épreuve un aspect du cache de page rarement testé en conditions normales : la capacité à servir, à la même URL, un contenu différent selon la langue détectée du visiteur. Cette checklist a été constituée après un incident où plusieurs visiteurs néerlandophones avaient reçu, pendant une vingtaine de minutes, une version française d’une page d’atterrissage, servie depuis un cache qui n’avait pas correctement varié sur la langue.

La cause de cet incident tenait à un détail de configuration : l’extension de cache de page utilisée générait une clé de cache basée uniquement sur l’URL, sans tenir compte du cookie ou de l’en-tête utilisé par l’extension multilingue pour déterminer la langue à afficher. Le premier visiteur à charger l’URL après une purge fixait, sans le savoir, la langue de toutes les visites suivantes jusqu’à l’expiration du cache.

1. Vérifier que la variation de cache inclut bien la langue

La documentation de l’extension de cache utilisée doit confirmer explicitement que la clé de cache varie selon le cookie ou le paramètre porteur de la langue. Un test simple consiste à charger la même URL depuis deux navigateurs configurés dans des langues différentes, juste après une purge, et à vérifier que chacun reçoit bien le contenu attendu.

2. Confirmer le comportement juste après une purge

C’est précisément dans les premières secondes suivant une purge que le risque de mélange des langues est maximal, avant que chaque variante linguistique n’ait été individuellement régénérée en cache. Le script suivant, exécuté juste après une purge programmée, permet de vérifier la cohérence sur chaque langue avant l’ouverture de la campagne :

for lang in fr nl en; do
  curl -s -H "Accept-Language: ${lang}" \
       -o "test_${lang}.html" \
       "https://exemple-campagne.test/atterrissage/"
  grep -o 'lang="[a-z]*"' "test_${lang}.html"
done

3. Vérifier la cohérence entre CDN et cache applicatif

Lorsqu’un CDN est placé devant le cache de page WordPress, sa propre configuration de variation de cache doit être alignée avec celle du plugin : un CDN qui ignore l’en-tête ou le cookie de langue peut resservir une version incorrecte même si le cache applicatif, lui, fonctionne correctement.

4. Tester le comportement du premier visiteur après le déploiement de la campagne

Le déploiement des pages spécifiques à la campagne, souvent réalisé juste avant son lancement, doit être suivi d’un test explicite simulant le tout premier visiteur de chaque langue, avant l’ouverture officielle au public, pour garantir que chaque variante est déjà chaude au moment du pic.

5. Vérifier le comportement des redirections automatiques de langue

Certaines extensions multilingues redirigent automatiquement un visiteur vers la version correspondant à la langue de son navigateur lors de sa première visite. Un cache de page mal configuré peut mettre en cache cette redirection elle-même, redirigeant ensuite tous les visiteurs suivants vers la même langue, indépendamment de leur configuration.

6. Contrôler les liens internes générés dans les gabarits de campagne

• Vérifier que les liens vers d’autres pages du site, présents dans la page d’atterrissage, pointent vers l’équivalent dans la bonne langue et non vers une URL générique.
• Vérifier que les formulaires de contact ou d’inscription soumettent bien vers un point de terminaison qui préserve la langue d’origine du visiteur.
• Vérifier que les messages de confirmation après soumission d’un formulaire s’affichent dans la langue attendue, un point souvent oublié car géré par un traitement distinct du cache de page.

7. Documenter et répéter la vérification à chaque campagne

Cette checklist, formalisée après l’incident, est désormais exécutée systématiquement trente minutes avant le lancement de toute campagne impliquant plusieurs langues, avec un compte-rendu archivé pour chaque campagne, permettant de repérer rapidement si une régression a été introduite entre deux campagnes successives.

Un cache de page multilingue qui fonctionne un jour donné ne garantit rien pour le lendemain : chaque mise à jour de l’extension de cache ou de l’extension multilingue mérite une nouvelle vérification.

En résumé

Servir la mauvaise langue à un visiteur, même pendant quelques minutes, abîme la crédibilité d’une campagne multilingue dès son lancement. Une checklist de sept vérifications, exécutée systématiquement avant chaque campagne, a permis d’éviter que l’incident initial ne se reproduise, sans nécessiter de changement structurel de la configuration de cache.