Comment tester une bannière de cookies avant la mise en ligne

Tous les articles

Testez une bannière de cookies sur une URL de préproduction, en navigation privée, avant sa mise en ligne. Vérifiez d'abord qu'elle s'affiche, qu'elle retient les cookies non essentiels jusqu'à un choix et que le signal de consentement de la requête sortante correspond à ce choix. Vérifiez ensuite que le choix est enregistré et qu'il survit à une nouvelle visite et à un retrait. Les trois dernières sont celles où les configurations échouent le plus souvent.

Presque tout test publié est un audit post-lancement

Cherchez comment tester une bannière de cookies et les guides qui remontent sont des audits : ouvrir le site, ouvrir les outils de développement, cliquer sur refuser, regarder si les traqueurs s'arrêtent. C'est un audit raisonnable et nous le ferions aussi. En lisant celles qui se positionnent aujourd'hui, elles sont écrites pour une bannière déjà en ligne, ce qui répond à une autre question que celle du titre ci-dessus.

La différence compte parce que les deux tests ne coûtent pas la même chose lorsqu'ils échouent. Une bannière en production qui s'avère cassée a collecté des données qu'elle n'aurait pas dû, ou manqué des données qu'elle aurait dû avoir, pendant tout le temps qu'il a fallu à quelqu'un pour s'en apercevoir. Une bannière cassée en préproduction a coûté un après-midi.

Que vérifier avant de mettre une bannière cookies en ligne ?

1. Testez en préproduction, pas sur le site en ligne

   La production n'est pas le banc d'essai. Placez la bannière sur une URL de préproduction et déclarez ce domaine dans l'outil de consentement, pour qu'il y serve une vraie bannière au lieu de refuser de se charger. La plupart des outils de consentement disposent d'un mode préproduction ou brouillon pour cela.

2. Ouvrez une fenêtre privée et vérifiez que la bannière apparaît

   Une fenêtre de navigation privée vierge est le seul premier regard honnête. Votre propre navigateur garde un choix fait plus tôt, et une bannière déjà répondue ne revient pas. Vérifiez que la bannière s'affiche au premier chargement, que l'option de refus est visible sans faire défiler et que refuser n'est pas plus difficile qu'accepter.

3. Refusez tout, puis regardez ce que la page envoie

   Ouvrez le panneau réseau et le panneau de stockage du navigateur avant de toucher à la bannière. Aucun cookie non essentiel ne devrait encore être écrit, et aucune balise tierce comme Meta ou Hotjar ne devrait se charger. Les requêtes Google dépendent de votre configuration Consent Mode, traitée dans la section suivante. Refusez ensuite tout et rechargez, sur une page produit et sur une page de paiement également, car les balises sont souvent ajoutées par gabarit et par des personnes différentes.

4. Lisez le signal de consentement sur la requête sortante, pas sur la bannière

   C'est la vérification qui distingue une bannière d'une véritable configuration de consentement, et celle que les check-lists publiées omettent. Là où Consent Mode est implémenté, les balises Google portent l'état de consentement sur la requête elle-même : refusez, puis lisez cet état et confirmez qu'il indique refusé. Ne trouver aucun état de consentement est un constat en soi, et une panne différente, car cela signifie que Consent Mode ne tourne pas, et non que la bannière a échoué.

5. Confirmez que le choix a bien été consigné

   Un consentement que vous ne pouvez pas produire ensuite ne sert pas à grand-chose lors d'un audit. Vérifiez que répondre à la bannière crée un enregistrement stocké que vous pouvez récupérer, indiquant quelles catégories ont été acceptées et quand. Ce qu'il contient d'autre varie selon le fournisseur, et la version de l'avis affiché est le champ dont il vaut la peine de s'enquérir, car sans lui vous ne pouvez pas dire à quoi le visiteur a consenti.

6. Refaites-le en visiteur de retour, après un retrait, et depuis une seconde région

   Les trois sortent cassés régulièrement. Rechargez en tant que visiteur ayant déjà répondu et confirmez que le choix stocké est toujours appliqué. Retirez le consentement et confirmez que les balises tierces s'arrêtent et que les balises Google repassent à un état refusé. Vérifiez ensuite une région où vos règles diffèrent.

Une requête Google avant le consentement est-elle un échec ?

Pas toujours. Deux tests différents se mélangent ici. Aucun cookie non essentiel avant le consentement est un test de stockage : rien qui ne soit strictement nécessaire n'est écrit ni lu dans le navigateur tant que le visiteur n'a pas accepté. Aucune requête d'analytics avant le consentement est un test réseau plus strict, qui ne tient qu'avec le Consent Mode basique ou pour les balises que vous bloquez complètement.

Avec le Consent Mode avancé, les balises Google se chargent avec tous les signaux refusés et envoient des pings sans cookies, un comportement que Google documente comme attendu. Dans cette configuration, une requête /g/collect avant le consentement est valide si elle porte gcs=G100 et ne pose aucun cookie. Une requête Meta ou Hotjar au même endroit est un échec.

Le test qui s'applique relève d'une décision juridique autant que technique. Les lignes directrices du Comité européen de la protection des données sur l'article 5(3) de la directive ePrivacy l'interprètent comme couvrant plus que les cookies, et certaines équipes choisissent le mode basique sur conseil juridique. Déterminez la configuration que vous utilisez, puis testez celle-là.

À quoi ressemble un vrai test réussi

Quatre de ces vérifications ont une version confortable et une version honnête, et c'est la confortable dont se contentent la plupart des guides de test. L'écart entre les deux colonnes est l'endroit où des configurations que tout le monde avait validées se révèlent fausses des mois plus tard.

La troisième ligne mérite qu'on s'y arrête. Un outil de consentement qui signale avoir appliqué un choix signale son propre état interne, ce qui n'est pas la même chose que ce que vos balises ont reçu. L'endroit où la question se tranche est la requête qui quitte le navigateur, et c'est pourquoi vérifier le signal Consent Mode v2 est une étape à part et non un détail du test de refus.

Quels sont les trois états que personne ne teste ?

Les premières visites sont testées parce qu'elles sont faciles à reproduire. Les états qui sortent cassés sont ceux qui demandent un peu de préparation pour être atteints.

La visite de retour. Un choix stocké doit être relu et réappliqué lors de la visite suivante, et ce chemin passe par un code différent de celui qui l'a enregistré. Quand il échoue, le visiteur revoit la bannière à chaque chargement de page ou, pire, la bannière reste absente pendant que le choix stocké est ignoré en silence et que les balises tournent sur une valeur par défaut que personne n'a choisie.

Le retrait. L'article 7 du RGPD exige que le consentement soit aussi facile à retirer qu'à donner. L'intéressant est ce qui se passe ensuite : les balises tierces qui étaient accordées doivent s'arrêter, et les balises Google doivent repasser à un état refusé. Un retrait peut mettre à jour l'enregistrement stocké tout en laissant tourner les balises déjà chargées jusqu'au chargement de page suivant, ce qu'il vaut mieux savoir avant le lancement qu'après une réclamation.

La seconde région. Les jeux de règles sont configurés pour le marché que quelqu'un avait en tête ce jour-là : une configuration qui affiche une bannière correcte dans un pays peut n'afficher rien du tout dans un autre. La personne qui teste est en général assise dans le premier pays, et c'est pour cela que cela passe inaperçu.

Conservez la preuve

Notez ce que vous avez vu, car la valeur du test se dégrade dès que le site change à nouveau. Conservez la requête sortante montrant un état refusé, l'enregistrement de consentement stocké, et une note des gabarits de page vérifiés. C'est la différence entre dire que la bannière a été testée et pouvoir le démontrer, la même distinction que celle tracée dans comment prouver réellement qu'un visiteur a donné son consentement.

Il vaut la peine d'être honnête sur ce que ce test protège. Les choix de consentement masquent une part des sessions à l'analytics, et cette part varie selon la région, l'audience et le design de la bannière. Le taux d'acceptation de votre outil de consentement vous donne la vôtre. Une bannière défaillante de l'une des façons ci dessus n'est pas seulement une exposition juridique : elle change silencieusement ce que compte chaque rapport en aval, sans le moindre message d'erreur.

Velo est conçu pour que l'essentiel de cette liste soit vrai dès le premier chargement. L'état de consentement est défini par un seul snippet avant l'initialisation de vos balises, le choix est enregistré avec ses catégories et la version de la notice, et une nouvelle visite se comporte comme la première. Le mécanisme est décrit sur la page produit.