Comment savoir si une balise dépose vraiment des cookies avant le consentement

Tous les articles

Ouvrez la page dans une fenêtre privée avec les outils de développement déjà lancés, et ne touchez pas à la bannière. Tout ce qui apparaît sous Application, Cookies, et tout ce qui part dans Network, s'est produit avant le consentement. Attribuez ensuite chaque élément : mettez en pause la balise que vous soupçonnez, rechargez, et regardez s'il revient malgré tout. Un audit du conteneur répond à une autre question : quelles balises ne sont pas conditionnées, et non lesquelles ont réellement fait quelque chose.

Ce que vous dit vraiment une liste d'audit

Un audit du consentement, qu'il vienne d'un scanner ou de quelqu'un qui lit un export de conteneur, répond à une seule question : quelles balises n'ont aucune condition de consentement attachée. C'est une question légitime. Ce n'est pas la même que de savoir si quelque chose a quitté le navigateur avant que le visiteur ne choisisse.

Cette année, sur un parc de sites en production, le client nous a remis une liste de constats de onze balises non conditionnées, avec une plainte en pièce jointe et une échéance. Confrontés à un seul chargement de page propre, trois des onze étaient des balises de fournisseurs qui lisaient elles-mêmes l'état de consentement et n'en faisaient rien, deux étaient des écouteurs dataLayer qui ne déposaient aucun cookie et n'émettaient aucun appel réseau, et six étaient de vraies fuites. Cinq constats sur onze relevaient de l'hygiène de configuration. À corriger, certes, mais ce n'était pas l'objet de la plainte.

Le constat qui expliquait la plainte ne figurait même pas sur la liste.

Comment vérifier si une balise dépose vraiment des cookies

1. Partez d'un profil qui ne se souvient de rien

   Une fenêtre privée, extensions désactivées, outils de développement ouverts avant le chargement de la page, avec Preserve log activé. Si le profil contient déjà un enregistrement de consentement, la page vous traite comme un visiteur connu et le chargement ne prouve absolument rien.

2. Lisez ce qui s'est passé avant de toucher à la bannière

   Application, puis Cookies, pour chaque domaine listé. Network, filtré sur les hôtes qui ne sont pas les vôtres. Notez les deux listes avant d'accepter ou de refuser quoi que ce soit. Ce relevé constitue le constat. Tout ce qui suit cette étape relève du rapprochement, pas de la découverte.

3. Attribuez à chaque balise signalée l'un de trois verdicts

   Fuite : elle a écrit un cookie ou envoyé une requête. Inerte : elle s'est déclenchée et n'a fait ni l'un ni l'autre. Autoconditionnée : elle s'est déclenchée, a lu elle-même l'état de consentement et s'est arrêtée. Seul le premier verdict est une fuite, et les deux autres méritent d'être consignés pour que personne ne les soulève à nouveau le trimestre suivant.

4. Confirmez chaque fuite suspectée en mettant en pause un élément à la fois

   Mettez la balise en pause, rechargez la fenêtre privée et cherchez à nouveau le même cookie ou la même requête. S'il est toujours là, cette balise n'a jamais été la source, et le prochain endroit où regarder est le code source de la page lui-même : un extrait collé dans le head s'isole exactement de la même façon, en le retirant puis en rechargeant.

5. Remontez les cookies que personne n'a signalés jusqu'à ce qui les a chargés

   Pour chaque cookie ou requête de votre liste qu'aucune balise n'explique, lisez la colonne Initiator. Une requête dont l'initiateur est le script d'un autre fournisseur est arrivée en aval, n'est pas dans votre conteneur, et survivra à toutes les modifications que vous y ferez.

6. Classez selon ce qui a réellement quitté le navigateur

   Une requête intersite portant un identifiant publicitaire est un constat d'un tout autre ordre qu'un cookie propriétaire contenant un identifiant de session. Corrigez dans cet ordre, et mettez ce classement dans la réponse plutôt que le total brut de onze.

Les étapes un et deux constituent toute la méthode. Le reste est de la tenue de comptes, mais une tenue de comptes qui répond à la question que le client a réellement posée : non pas combien de balises ne sont pas conditionnées, mais lesquelles font quelque chose.

Pourquoi un audit de conteneur ne peut pas produire cette liste

Deux raisons structurelles, et aucune n'est un défaut des outils.

Un conteneur connaît ses propres balises, et rien d'autre. Il ne sait pas ce que fait un script une fois chargé, et il ne voit rien de ce qui est collé directement dans le head du site, là où vivent en général les extraits de fournisseurs les plus anciens et les moins relus. Savoir si un extrait donné peut seulement être déplacé dans le conteneur est une décision à prendre script par script.

Non conditionnée et qui fuit sont deux propriétés différentes. De plus en plus de balises de fournisseurs lisent elles-mêmes l'état de Consent Mode et se retiennent d'elles-mêmes : une balise peut donc ne porter aucune condition dans le conteneur et se comporter correctement. L'inverse est vrai aussi, et c'est pire : une balise peut porter une condition parfaite et fuir quand même, parce que ce qui dépose le cookie se trouve en aval. Attribuer la bonne catégorie à chaque script est un exercice à part entière, et le test de décision pour cela se trouve ici.

Le constat qui ne figurera sur aucune liste

Dans cet audit, le cookie qui comptait était déposé par un pixel tiers qu'aucune balise du conteneur ne référence. Le script d'un autre fournisseur l'avait demandé après son chargement : une chaîne qu'un export de conteneur ne peut pas montrer et qu'un scanner lisant la configuration des balises ne signalera pas.

C'est la colonne Initiator du panneau Network qui le trouve. Remontez la requête jusqu'au script qui l'a demandée, et vous tombez généralement sur un outil approuvé il y a des années pour tout autre chose. Mettre des balises en pause ne sert à rien ici, car la balise n'a jamais été la source. Le mécanisme derrière ce schéma mérite d'être lu en entier : une fois que vous l'avez vu, vous le vérifiez à chaque fois.

Ce qu'il faut renvoyer

Répondez par des verdicts plutôt que par un total. Six fuites, classées selon ce qui a quitté le navigateur. Cinq balises non conditionnées et inertes, avec la preuve qu'elles sont inertes. Une fuite qui ne figurait pas sur votre liste, avec le nom du script qui l'a chargée. Cette réponse est plus courte que la liste d'origine, et c'est celle sur laquelle on peut agir.

Il faut être rigoureux sur ce point parce que les deux erreurs coûtent de l'argent réel, dans des sens opposés. Conditionner une balise qui n'a jamais fuité supprime de la mesure pour rien. Passer à côté d'une balise qui fuit laisse la plainte sans réponse. Et le critère juridique porte sur ce que la page a fait, pas sur ce que dit le conteneur : les lignes directrices de l'EDPB sur le champ d'application technique de l'article 5(3) incluent les pixels de suivi au même titre que les cookies, et c'est pourquoi la liste des requêtes compte autant que la liste des cookies.

Refaites le même chargement propre après chaque correction, car c'est la seule chose qui prouve la correction. La séquence complète d'avant mise en ligne se trouve ici, et c'est la même discipline appliquée plus tôt. Velo bloque par catégorie avant qu'une balise puisse s'exécuter et enregistre ce qui a été accordé au moment où cela s'est produit, ce qui raccourcit nettement cet exercice. Cela ne le supprime pas : les scripts que chargent vos fournisseurs restent à vous de les trouver.