Ce qui se passe quand quelqu'un retire son consentement aux cookies

Tous les articles

La collecte s'arrête pour les catégories révoquées, et les cookies déjà présents sur l'appareil restent pour la plupart où ils sont. Trois choses doivent suivre. L'enregistrement reçoit un événement de retrait au lieu de perdre l'accord initial. Un signal de refus part vers chaque outil qui en accepte un. Et chaque outil réinitialise l'identité avant que la collecte ne soit coupée.

La réponse que tout le monde donne porte sur les fichiers cookies

Cherchez cette question et vous obtenez la réponse à une question plus étroite : le retrait supprime-t-il les cookies déjà présents sur l'appareil ? La réponse est non, et le raisonnement est solide. Un script ne peut toucher qu'aux cookies de son propre domaine : rien sur votre site ne peut donc atteindre un cookie qu'une autre entreprise a déposé sur le sien. C'est une règle de sécurité du navigateur, pas une lacune de votre outil de consentement. Les cookies propriétaires (first party) comme _ga font exception : ils se trouvent sur votre propre domaine, et votre site peut donc les effacer. Une plateforme de consentement bloque plutôt les scripts qui lisent et écrivent ces cookies.

Cette réponse est juste, et c'est la plus petite partie de la transition. Supprimer un fichier après coup protège très peu : le moment qui compte est celui où les données circulent, c'est-à-dire quand un cookie est déposé et quand il est lu. Le blocage arrête les deux. Effacer les fichiers, non.

Il existe une vraie exception. Avec ads_data_redaction activé et ad_storage refusé, Google expurge les identifiants de clic des pings qu'il envoie encore, comme l'indique le guide de Google sur le mode de consentement. C'est le seul levier de la chaîne qui retire quoi que ce soit de ce qui est envoyé, et c'est un réglage de Google, pas une action de votre bannière.

Ce que presque personne ne met par écrit, c'est ce que votre chaîne de mesure doit faire à ce moment-là. C'est là que le retrait déraille, et il déraille sans bruit : la bannière se ferme et tout semble normal.

Ce qui doit se passer, dans l'ordre

Le retrait est une séquence, et l'ordre compte plus que n'importe quel appel isolé.

1. Enregistrez le retrait comme un nouvel événement, pas comme une modification

   Un retrait n'est pas une correction de l'accord initial. C'est un second fait : ce visiteur a consenti à un moment et a révoqué son consentement à un autre, et les deux sont vrais. Stockez-le comme une nouvelle ligne qui renvoie à l'accord qu'il remplace, dans une table où rien ne peut être modifié ni supprimé. L'article 7(3) du RGPD prévoit qu'un retrait ne compromet pas la licéité du traitement effectué avant lui, et l'accord initial en est votre preuve. Écrasez-le et vous détruisez la seule preuve que la collecte antérieure était licite. Velo enregistre un retrait comme un nouvel événement qui fait référence au précédent, conservé indéfiniment même lorsque les enregistrements d'accord ordinaires arrivent à expiration.

2. Envoyez un signal de refus, ne vous taisez pas

   Le réflexe est de tout faire cesser. Avec Consent Mode, c'est une erreur. La balise doit rester en place et recevoir une mise à jour qui passe analytics_storage et les trois signaux publicitaires à denied. Elle envoie alors un ping sans cookie, sans aucun identifiant, et ce ping maintient la modélisation et les rapports de base. Retirer complètement la balise n'envoie rien, et rien n'équivaut pas à un refus enregistré. L'un est un visiteur qui a dit non ; l'autre est un visiteur qui n'existe pas.

3. Parlez à chaque outil dans le dialecte qu'il comprend

   Il n'existe pas d'API de consentement unique. Les balises de Google lisent un appel gtag('consent', 'update', …), celles de Microsoft un push vers uetq, celles de Meta un appel fbq. Et les déclencheurs de Google Tag Manager ne voient pas un CustomEvent du navigateur : un retrait qui ne déclenche que celui-ci laisse donc tous les déclencheurs d'événement personnalisé muets. Poussez aussi un événement nommé dans le data layer. Notre propre SDK fait passer chaque chemin qui modifie le consentement par une seule fonction qui émet les quatre : un clic dans la bannière, une décision enregistrée rejouée, un signal Global Privacy Control qui désactive des catégories. Un retrait ne peut donc pas emprunter une autre route qu'un accord.

4. Réinitialisez l'identité avant de couper la collecte, jamais après

   La plupart des bibliothèques d'analyse exposent deux appels : l'un efface l'identité du visiteur, l'autre coupe la collecte. Presque tout le monde les range dans cet ordre dans sa tête, arrêter la collecte puis l'oublier, et presque tout le monde écrit un bug. Dans de nombreuses bibliothèques, l'indicateur de consentement et l'identité partagent le même stockage, si bien que la réinitialisation efface l'opt-out que vous venez de poser. Réinitialisation d'abord, coupure de la collecte en dernier.

5. Réappliquez le filtre, puis rechargez la page

   Le blocage porte sur ce qui ne s'est pas encore exécuté. Un script déjà chargé reste en mémoire, avec ses propres minuteurs, et peut réécrire son cookie à la prochaine interaction, quoi que dise désormais votre bannière. Réappliquer le filtre arrête ce qui vient ensuite ; seul un rechargement garantit proprement que plus rien de l'état de consentement précédent ne tourne encore. Il rejoue aussi la décision enregistrée depuis le début, le chemin que suit un visiteur qui revient, ce qui teste ce cas sans effort supplémentaire.

Quelle étape se passe mal le plus souvent ?

Nous avons trouvé l'étape quatre dans notre propre stack, pas chez un client. Notre bannière refuse l'analyse ; la branche de refus appelait d'abord l'opt-out, puis la réinitialisation de l'identité. Cela se lit correctement : arrêter la collecte, puis oublier le visiteur.

Dans les données, cela a produit deux personnes : l'une identifiée, l'autre anonyme, partageant un même identifiant d'appareil à quelques minutes d'intervalle. La cause se trouvait dans la bibliothèque, pas dans la bannière. Dans posthog-js 1.424.1, l'appel de réinitialisation réinitialise aussi l'état de consentement enregistré : l'exécuter après l'opt-out effaçait donc l'opt-out, et la collecte reprenait sous un nouvel identifiant anonyme et dans une nouvelle session. Chaque visiteur qui se rétractait était compté deux fois, sans le moindre signal.

Inverser les deux appels a réglé le problème, vérifié dans un navigateur vierge et pas seulement en revue de code. Acceptez, et un identifiant apparaît. Refusez, et l'indicateur d'opt-out vaut true, sans aucune requête sortante pour un événement forcé. Acceptez de nouveau plus tard, et c'est le même identifiant qui revient, pas un troisième.

Que doit pouvoir voir le visiteur ?

Le RGPD prévoit que retirer son consentement doit être aussi simple que le donner. En pratique, cela suppose une commande qui rouvre le panneau des préférences depuis chaque page, pas un lien enfoui dans un document de politique. La décision doit prendre effet sur la page où se trouve le visiteur.

Cela implique aussi une trace que le visiteur pourra invoquer plus tard, le même mécanisme qui répond à la question comment prouver qu'un visiteur a donné son consentement. Un retrait est un enregistrement de consentement comme un autre.

Reste à régler le moment où vous redemandez. Un retrait n'autorise pas à relancer la question à la page suivante ; le traiter ainsi, c'est faire de la bannière une nuisance. Le moment a sa propre réponse : combien de temps dure le consentement aux cookies et quand la bannière doit reposer la question.

Comment tester un retrait ?

Presque toutes les bannières ont été testées à l'arrivée. Presque aucune ne l'a été à la sortie, et c'est pourquoi les bugs de retrait survivent des mois alors que le parcours d'acceptation reste parfait. Acceptez, parcourez deux pages, puis retirez votre consentement, et surveillez trois choses : ce qui quitte le navigateur, si l'opt-out est toujours en place une minute plus tard, et combien de personnes votre outil d'analyse voit derrière ce seul navigateur.

Velo fait passer chaque changement de consentement, accord ou retrait, par un seul chemin qui enregistre l'événement, met à jour Consent Mode, pousse l'événement data layer sur lequel votre conteneur se déclenche et appelle l'API de consentement de chaque fournisseur. Cela supprime l'écart entre les deux sens. Cela ne supprime pas le test : l'ordre dans lequel vos propres outils attendent leurs appels reste à vous de le régler.