Des pages rapides, un mauvais consentement

Le cache de pages est l'une des meilleures choses que vous puissiez faire pour la vitesse et les coûts d'hébergement. C'est aussi l'un des moyens les plus faciles de casser un dispositif de consentement sans s'en apercevoir. Un cache fait exactement ce qu'on lui dit : il stocke une réponse une fois et la sert à tous ceux qui correspondent à la même clé. Si cette réponse stockée contient quoi que ce soit de propre au choix de consentement ou à la localisation d'un visiteur, le visiteur suivant la reçoit aussi.

Ce guide passe en revue les couches de cache qui se trouvent généralement devant un site d'éditeur — caches périphériques de CDN, plugins de cache de page complète, reverse proxies, service workers et le navigateur lui-même — et la manière d'éviter que chacune serve le mauvais parcours de consentement.

La règle de base : garder le consentement hors du HTML mis en cache

L'architecture la plus sûre produit une page HTML mise en cache neutre vis-à-vis du consentement. La page contient le chargeur du CMP et vos balises en état bloqué ou en attente, mais aucune décision concernant ce visiteur précis. Le CMP s'exécute ensuite dans le navigateur, lit le choix enregistré, décide s'il faut afficher la bannière et libère les balises en conséquence.

Les problèmes commencent quand le serveur prend des décisions de consentement au moment du rendu, par exemple :

• un thème ou un plugin qui n'imprime les balises publicitaires ou d'analytique que si un cookie de consentement est présent ;
• du code côté serveur qui omet le balisage de la bannière pour les visiteurs ayant déjà choisi ;
• des modèles qui intègrent l'état de consentement d'un visiteur dans une variable de script en ligne.

Une fois cette page mise en cache, l'état du premier visiteur devient celui de tout le monde. Un visiteur qui a refusé le suivi peut recevoir une page dont les balises sont déjà actives, ou un nouveau visiteur peut ne jamais voir de bannière parce que la copie en cache provient de quelqu'un qui l'avait déjà fermée.

Pourquoi « Vary: Cookie » est rarement la réponse

La solution classique pour un contenu propre à chaque visiteur consiste à demander aux caches de varier selon l'en-tête cookie. En pratique, les visiteurs portent de nombreux cookies aux valeurs uniques : varier sur l'ensemble de l'en-tête cookie fait généralement tomber votre taux de succès du cache à presque zéro. Certains CDN permettent de construire la clé de cache à partir d'une seule valeur de cookie, ce qui est envisageable si votre cookie de consentement a peu d'états possibles, mais cela ajoute de la complexité et multiplie quand même le nombre de copies en cache. Déplacer la décision dans le navigateur est plus simple et garde le cache efficace.

La géographie en périphérie

De nombreux éditeurs affichent des bannières différentes selon la région : une bannière d'opt-in pour l'UE et le Royaume-Uni, un avis de refus pour les États américains, et quelque chose de plus léger ailleurs. Si le serveur choisit la variante d'après l'adresse IP du visiteur et que cette page est mise en cache, un lecteur européen peut recevoir une page américaine en cache, ou l'inverse.

Trois approches permettent d'éviter cela :

1. Géolocalisation côté client. Laissez le CMP déterminer la région dans le navigateur, afin que le HTML mis en cache reste identique pour tous.
2. Le pays dans la clé de cache. Si vous devez décider en périphérie, incluez dans la clé de cache le code pays fourni par votre CDN. Vous obtenez une copie en cache par pays, ce qui est prévisible.
3. Logique de périphérie sans cache. Exécutez la décision régionale dans une fonction de périphérie qui injecte une petite valeur non mise en cache dans une page par ailleurs en cache.

Quelle que soit votre option, documentez-la. Les bogues géographiques figurent parmi les plus difficiles à reproduire, car ils n'apparaissent que pour des visiteurs situés à un endroit et qui reçoivent une page mise en cache par quelqu'un d'ailleurs.

Mettre en cache le script du CMP lui-même

Mettre en cache longtemps le chargeur du CMP est bon pour les performances, mais cela a un coût lorsque la configuration change. Si vous mettez à jour les fournisseurs, les finalités ou le texte de la bannière et que le script ou le fichier de configuration est en cache pour un an, certains visiteurs continueront de voir l'ancienne version. Vérifiez comment votre CMP versionne ses fichiers : un nom de fichier ou un paramètre de version qui change permet de mettre en cache de façon agressive tout en déployant immédiatement les modifications. Vérifiez aussi que votre propre CDN ne supprime pas les chaînes de requête des URL de scripts tiers si le CMP s'en sert.

Service workers et caches hors ligne

Les sites dotés d'une couche d'application web progressive mettent souvent du HTML en cache dans un service worker. La même règle s'applique : ne stockez jamais une page reflétant une décision de consentement précise. Excluez du cache du service worker les points d'accès liés au consentement et les pages du centre de préférences, et assurez-vous qu'une configuration de CMP récente peut toujours être récupérée.

Le cache retour/avance

Les navigateurs modernes gardent en mémoire les pages récemment visitées afin que le bouton retour les restaure instantanément. Si un visiteur ouvre le centre de préférences sur une page, retire son consentement, puis appuie sur retour, la page restaurée peut encore avoir des balises actives d'avant. Écoutez l'événement pageshow et vérifiez sa propriété persisted : lorsqu'une page est restaurée depuis ce cache, relisez l'état de consentement enregistré et arrêtez ou démarrez les balises en conséquence.

Une routine de test

• Chargez une page dans une session vierge, refusez, puis chargez une deuxième page et confirmez qu'aucune balise de suivi ne se déclenche.
• Recommencez avec un second navigateur vierge et confirmez que la bannière apparaît, ce qui prouve qu'elle n'a pas été supprimée par le cache.
• Examinez les en-têtes de réponse pour voir si les pages sont servies depuis le cache, et comparez le HTML avec et sans cookie de consentement — il doit être identique.
• Testez depuis au moins deux régions après avoir purgé le cache, puis à nouveau une fois le cache réchauffé.
• Retirez le consentement, utilisez le bouton retour et vérifiez que les balises s'arrêtent.

À retenir

• Le HTML mis en cache doit être neutre vis-à-vis du consentement ; laissez le CMP décider dans le navigateur.
• Évitez de varier sur l'ensemble de l'en-tête cookie ; cela détruit les taux de succès.
• Si les bannières diffèrent selon la région, décidez côté client ou ajoutez le pays à la clé de cache.
• Versionnez les fichiers du CMP pour que de longues durées de cache ne retardent pas les changements de configuration.
• Gérez les service workers et le cache retour/avance, et testez avec un cache chaud, pas seulement après une purge.