Pourquoi un cookie de suivi revient-il après un refus ?

Tous les articles

Le plus souvent parce que le script qui l’a déposé tourne encore. Supprimer un cookie n’arrête pas le code qui l’a écrit : si ce code ne sait pas que le consentement est refusé, il réécrit le cookie à son prochain envoi. Les autres causes sont une suppression qui vise le mauvais domaine ou le mauvais chemin, et un cookie déposé par votre serveur.

Pourquoi un cookie supprimé réapparaît-il après un refus ?

Un cookie est un fichier que garde le navigateur. La balise qui l’a déposé est du code qui s’exécute dans la page, et il continue de tourner après la fermeture de la bannière. Supprimez le fichier, le code reste là, prêt à le réécrire au prochain envoi.

Nous l’avons reproduit avec le vrai gtag.js de Google sur un domaine de test en novembre 2026. Avec l’analytique toujours accordée, nous avons supprimé _ga et _ga_<id> correctement. Les deux avaient disparu. Le premier événement envoyé ensuite par la balise a réécrit le cookie de session, _ga_<id>, aussitôt. Sur le site d’un client avec qui nous travaillions le même mois, un cookie d’analytique est revenu quand la page est passée en arrière plan, et non sur un événement. Les équipes y voient souvent une panne de l’outil de consentement. C’est l’ordre des opérations qui est en cause.

La solution consiste à prévenir la balise d’abord. Dans le même test, envoyer gtag('consent', 'update', { analytics_storage: 'denied' }) puis supprimer les cookies les a tenus à l’écart malgré un nouvel événement et une page masquée simulée. Une balise qui sait que le consentement est refusé cesse d’écrire ; une balise qui l’ignore défera votre suppression.

Pourquoi supprimer le cookie semble-t-il ne servir à rien ?

Parce que la suppression doit correspondre au cookie visé. Un navigateur ne retire un cookie que si le nom, le domaine et le chemin de la suppression correspondent à ceux de sa création, comme le décrit la référence de MDN sur l’en tête Set-Cookie. Les balises Google déposent les leurs au niveau de domaine le plus élevé possible : sur shop.example.com, le cookie _ga se trouve donc sur .example.com.

Dans notre test, une suppression écrite document.cookie = '_ga=; Max-Age=0; path=/', sans domaine, n’a rien retiré du tout. Le script s’est exécuté sans erreur et le cookie est resté. Ajoutez domain=.example.com et il disparaît. Même chose pour le chemin : une suppression sur / n’atteint pas un cookie déposé sur un chemin autre que /.

Et les cookies déposés par le serveur ?

Aucun script de la page ne peut lire ni supprimer un cookie marqué HttpOnly. Les configurations de taggage côté serveur en utilisent souvent un, par exemple le cookie FPID qu’un conteneur serveur peut émettre. Seul le serveur peut le faire expirer : il doit donc être informé du refus et agir à la requête suivante. Si vous utilisez un conteneur serveur, vérifiez que son client lit l’état du consentement et cesse d’émettre le cookie quand il est refusé. Transmettre le signal de consentement à un conteneur serveur traite cette partie.

Le cookie est-il vraiment revenu, ou n’est-il jamais parti ?

Vérifiez avant de corriger. Certains cookies doivent rester : votre enregistrement de consentement, et les cookies strictement nécessaires comme un cookie de session ou de panier. Les cookies du domaine d’une autre entreprise ne peuvent de toute façon pas être supprimés par votre site. Ouvrez ensuite le panneau de stockage du navigateur et regardez la colonne du domaine. Un cookie sur le domaine parent peut appartenir à un autre de vos sites sur le même domaine, et c’est la bannière de ce site qui décide. Un cookie avec une nouvelle valeur a été réécrit. Un cookie avec l’ancienne valeur n’a jamais été supprimé. Et s’il est apparu avant que le visiteur ne choisisse quoi que ce soit, la balise s’est exécutée avant que la valeur par défaut refusée ne soit posée : c’est un problème d’ordre de chargement, pas de suppression. Notre article sur comment vérifier si une balise dépose vraiment des cookies explique comment lire ces panneaux.

Comment empêcher un cookie de revenir après un refus ?

1. Envoyez d’abord le signal de refus

   Prévenez chaque outil dans le format qu’il écoute avant de toucher au stockage : une mise à jour du consentement pour les balises Google, l’appel équivalent pour chaque autre fournisseur. Une balise qui sait que le consentement est refusé cesse d’écrire.

2. Supprimez à chaque niveau de domaine

   Supprimez chaque cookie sur l’hôte actuel et sur chaque domaine parent jusqu’au domaine enregistrable, avec path=/. Une suppression sans domaine manque sans le signaler les cookies déposés sur le parent.

3. Retenez les balises qui n’ont pas encore tourné

   Assurez vous que rien en attente de chargement ne peut démarrer après le refus et réécrire le cookie. C’est le rôle du blocage des balises, pas de la suppression.

4. Faites expirer les cookies serveur sur le serveur

   Pour tout cookie HttpOnly, faites lire l’état du consentement par le serveur et expirer le cookie à la requête suivante. Aucun script de la page ne peut le faire.

5. Testez avec une page masquée et un rechargement

   Acceptez, puis refusez, puis envoyez un événement, changez d’onglet et rechargez. Lisez le panneau des cookies après chaque étape. Un refus qui ne tient que jusqu’au prochain envoi ne tient pas.

Pour l’ordre complet que doit suivre un retrait, y compris la réinitialisation d’identité dont la plupart des bibliothèques ont besoin, voir ce qui se passe quand quelqu’un retire son consentement aux cookies.

Ce que fait Velo

Quand un visiteur refuse une catégorie qu’il avait autorisée, Velo envoie le signal de refus à chaque fournisseur qu’il est configuré pour prévenir, puis supprime les cookies propriétaires connus et les clés de stockage de cette catégorie sur l’hôte actuel et sur chaque domaine parent jusqu’au domaine enregistrable, avec path=/. Il ne peut pas atteindre les cookies HttpOnly ni ceux d’un autre chemin, et il ne touche pas à son propre enregistrement de consentement, car c’est lui qui prouve que le refus a eu lieu.