80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Chaque bannière de cookies fait la même promesse implicite : cliquez sur « Refuser » et le suivi s'arrête. La bannière disparaît et vous naviguez en paix. C'est le marché sur lequel repose le modèle de consentement -- l'idée que les utilisateurs disposent d'un choix significatif et exécutoire.

Nous avons testé cette promesse sur 28 891 sites web de l'UE. Sur 80,4 % d'entre eux, la promesse est rompue. Le suivi continue après que l'utilisateur a explicitement cliqué sur refuser. Les cookies persistent. Les pixels publicitaires continuent de se déclencher. Et sur 1 642 sites, les cookies que l'action de refus supprime initialement reviennent lors du prochain chargement de page -- un schéma que nous appelons la réapparition du consentement.

Ce n'est pas un constat marginal concernant quelques sites mal configurés. Cela pointe vers un problème systémique dans le mécanisme sur lequel des centaines de millions de résidents de l'UE comptent pour leurs droits à la vie privée.

Ce que « Refuser » est censé faire -- juridiquement

Le cadre juridique est clair. En vertu de l'article 5(3) de la directive ePrivacy, le stockage ou l'accès à des informations sur l'équipement terminal d'un utilisateur nécessite un consentement préalable, avec une exception étroite pour les cookies strictement nécessaires à un service que l'utilisateur a explicitement demandé. L'article 7(3) du GDPR ajoute que le retrait du consentement doit être aussi facile que son octroi, et le responsable du traitement doit agir sur ce retrait.

Les lignes directrices 05/2020 de l'EDPB sur le consentement sous le GDPR précisent ce que cela signifie pour les boutons de refus : si un site web offre une option « Tout accepter », il doit également offrir une option tout aussi visible et tout aussi accessible pour refuser. Et ce refus doit être effectif -- il doit réellement empêcher le traitement que le consentement aurait autorisé.

Le CJEU a renforcé cela dans Planet49 (C-673/17) : le consentement nécessite un acte affirmatif clair, et les cases pré-cochées ne constituent pas un consentement valide. Le corollaire logique est qu'un refus -- un acte négatif explicite -- doit être respecté aussi définitivement qu'une acceptation. Si cliquer sur « Accepter » active le suivi, cliquer sur « Refuser » doit le désactiver. Pas partiellement. Pas temporairement. Complètement et de manière persistante.

Voilà ce que dit la loi. Nos données montrent ce qui se passe réellement.

Comment nous testons le flux de refus

Notre test du flux de refus est conçu pour être aussi proche que possible de l'expérience d'un véritable utilisateur humain cliquant sur refuser, avec l'ajout d'une instrumentation complète. Voici le processus étape par étape :

Étape 1 : Session de navigateur propre. Le scanner lance une instance Chromium propre -- pas de cookies, pas de stockage local, pas de ressources mises en cache, pas d'historique de navigation. C'est un véritable visiteur première fois sans état de consentement antérieur. Étape 2 : Navigation et enregistrement de l'état pré-consentement. Le scanner charge l'URL cible et attend que la page se stabilise. Avant toute interaction, il enregistre chaque cookie présent dans le navigateur, chaque requête réseau effectuée et chaque domaine tiers contacté. C'est la ligne de base pré-consentement -- ce que le site fait avant que l'utilisateur ait la moindre opportunité de faire un choix. Étape 3 : Détection de la bannière de consentement. À l'aide de notre bibliothèque de détection couvrant 45 CMP connus et des heuristiques génériques, le scanner identifie le mécanisme de consentement et localise le bouton de refus. Cette étape utilise une approche multicouche : d'abord la vérification des signatures de scripts CMP connus et de leurs structures DOM associées, puis le recours à la détection générique d'éléments à position fixe avec du texte lié au consentement et des libellés de boutons comme « Tout refuser », « Décliner », « Refuser » ou des traductions équivalentes. Étape 4 : Clic sur refuser. Le scanner clique sur le bouton de refus et attend que la page se stabilise. « Se stabiliser » signifie attendre que les requêtes réseau en cours se terminent, que les mutations DOM cessent et que les animations ou transitions se terminent. Nous utilisons des délais d'attente généreux pour éviter les faux positifs dus à des implémentations CMP lentes. Étape 5 : Instantané post-refus. Le scanner enregistre à nouveau l'état complet : tous les cookies, toute l'activité réseau, tous les domaines tiers. Cet instantané est comparé à la ligne de base pré-consentement pour déterminer ce qui a changé. Étape 6 : Rechargement et vérification de la réapparition. Le scanner recharge la page et attend à nouveau sa stabilisation. Il prend ensuite un dernier instantané. Cette étape est cruciale : elle révèle si l'action de refus est persistante (respectée à travers les chargements de page) ou si les cookies et le suivi se réactivent lorsque la page se charge à nouveau. Si des cookies supprimés à l'étape 5 réapparaissent à l'étape 6, c'est une réapparition du consentement.

Chaque étape produit des preuves horodatées et archivables : inventaires complets de cookies avec noms, valeurs, domaines, dates d'expiration et drapeaux ; journaux complets de requêtes réseau avec URL, méthodes, codes de réponse et timing ; et captures d'écran pleine page. Cette chaîne de preuves permet de vérifier et de contester tout constat individuel.

Les résultats : 80,4 % d'échec

Parmi les 28 891 sites web où nous avons complété avec succès le test complet du flux de refus :

• 5 650 (19,6 %) ont réussi. Après avoir cliqué sur refuser, les cookies non essentiels ont été supprimés, les requêtes de suivi ont cessé, et le refus a persisté à travers les rechargements de page.
• 23 241 (80,4 %) ont échoué. Le suivi a continué sous une forme ou une autre après que l'utilisateur a explicitement cliqué sur refuser.

Les échecs ne sont pas uniformes. Ils se répartissent en catégories distinctes qui se chevauchent -- un seul site peut présenter simultanément plusieurs modes de défaillance.

Cookies persistants : 10 848 sites

Sur 10 848 sites (37,5 % des sites testés), des cookies non essentiels sont restés dans le navigateur après la fin du flux de refus. Ce sont des cookies classés comme liés à l'analyse, au marketing ou au suivi qui auraient dû être supprimés ou empêchés d'être définis après une action de refus.

Les cookies persistants les plus courants appartiennent à Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) et diverses plateformes publicitaires. Dans de nombreux cas, le CMP supprime avec succès certains cookies mais ne parvient pas à tous les attraper -- suggérant une intégration incomplète entre la plateforme de gestion du consentement et la liste complète des scripts tiers du site.

La présence de ces cookies après le refus n'est pas simplement un problème esthétique. Chacun est un identifiant persistant qui lie la session actuelle de l'utilisateur aux visites passées et futures. Le cookie `_ga`, par exemple, est un identifiant client unique que Google Analytics utilise pour construire un profil longitudinal du comportement de l'utilisateur à travers les sessions. S'il persiste après le refus, la navigation de l'utilisateur continue d'être suivie et agrégée malgré son refus explicite.

Traceurs persistants : 14 547 sites

Sur 14 547 sites (50,3 % des sites testés), les services de suivi sont restés actifs après le refus -- ce qui signifie que le navigateur continuait d'effectuer des requêtes vers des domaines de suivi connus même après que l'utilisateur a cliqué sur le bouton de refus.

C'est un mode de défaillance distinct de la persistance des cookies. Un traceur peut être actif sans définir de cookie : les requêtes de pixels, les appels de balises et les chargements de scripts transmettent tous des informations (au minimum, l'adresse IP de l'utilisateur, la page de référence et les données de timing) aux serveurs tiers, qu'un cookie soit stocké ou non. Cela est parfois appelé « suivi sans cookies » et est de plus en plus courant à mesure que les navigateurs renforcent les restrictions sur les cookies tiers.

L'écart entre le chiffre des cookies (10 848) et le chiffre des traceurs (14 547) est significatif. Il signifie que sur environ 3 700 sites, l'action de refus a supprimé avec succès les cookies mais n'a pas empêché les requêtes de suivi de continuer. Le CMP a géré le nettoyage des cookies mais n'a pas bloqué les scripts qui génèrent le trafic de suivi en premier lieu. Cela pointe vers un problème architectural courant : le CMP est configuré pour gérer les cookies (les supprimer au refus, les empêcher au chargement) mais pas pour gérer l'exécution des scripts.

Réapparition du consentement : 1 642 sites, 4 932 cookies

La réapparition du consentement est le schéma le plus troublant que nous ayons identifié. Sur 1 642 sites, des cookies qui avaient été supprimés avec succès par l'action de refus sont réapparus après le rechargement de la page. Sur ces sites, 4 932 cookies individuels ont présenté ce comportement de réapparition.

La réapparition du consentement n'est pas un bug dans un CMP ou une configuration. C'est un problème structurel dans la façon dont le consentement est implémenté à travers la pile web.

Comment un cookie revient après suppression. Lorsqu'un utilisateur clique sur refuser, un CMP correctement configuré fait deux choses : il supprime les cookies non essentiels existants (en fixant leur expiration à une date passée) et met à jour un enregistrement de consentement (généralement un cookie lui-même ou une entrée localStorage) qui indique à la logique de blocage du CMP d'empêcher les scripts non essentiels de s'exécuter lors des chargements de page futurs. Si les deux fonctionnent, l'utilisateur est propre : pas de cookies de suivi, pas de scripts de suivi.

La réapparition du consentement se produit lorsque la suppression réussit mais que le blocage échoue. Le scénario le plus courant :

1. Le CMP supprime le cookie `_ga` lorsque l'utilisateur clique sur refuser.

2. Le CMP définit un cookie d'état de consentement enregistrant que l'utilisateur a refusé l'analyse.

3. Au chargement de page suivant, le CMP vérifie son état de consentement et sait que l'utilisateur a refusé.

4. Mais : la balise script Google Analytics est intégrée directement dans le modèle de page (en dehors du gestionnaire de balises) ou est chargée par une règle du gestionnaire de balises qui ne vérifie pas l'état de consentement.

5. Le script GA se charge, ne voit pas de cookie `_ga` et en crée un nouveau.

6. La décision de refus de l'utilisateur a été annulée.

Les variations de ce schéma incluent : des scripts tiers chargés via des balises `