Tracking avant consentement : ce que c'est et pourquoi les régulateurs le considèrent comme une infraction

Le tracking avant consentement est une catégorie de constat de notre scanner. Il se déclenche lorsque, entre le début d'un nouveau chargement de page et le moment où l'utilisateur agit sur la bannière de consentement, le navigateur envoie une ou plusieurs requêtes réseau porteuses d'identifiants, contenant des charges utiles d'analyse non essentielles ou déposant des cookies non essentiels.

C'est le défaut le plus fréquent que nous détectons. Lors de notre analyse de 97 000 sites européens, la majorité des classifications à haut risque étaient dues au tracking avant consentement, et non à des bannières manquantes ou à des boutons de refus défectueux.

Ce que le scanner recherche

Le détecteur surveille le réseau à partir du moment où le navigateur émet la requête de document, jusqu'à l'un de ces trois événements :

L'utilisateur clique sur un bouton de la bannière de consentement (accepter, refuser, paramètres).
Un cookie ou une entrée localStorage mesurable, traduisant un état de consentement, est écrit.
Un délai s'écoule (8 secondes par défaut) sans aucun signal de consentement.

Toute requête déclenchée dans cette fenêtre est examinée selon trois signaux :

Empreinte de traceur connue. Le domaine de destination, le chemin de la requête ou le motif de la charge utile correspond à une entrée de notre base de traceurs. Cela inclut Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, les pixels de conversion X, et bien d'autres.
Charge utile portant un identifiant. La requête transporte un identifiant client stable (cookie, hash d'empreinte, ou paramètre de requête persistant entre les pages).
Écriture de cookie non essentiel. La réponse dépose un cookie qui, par classification, n'est pas strictement nécessaire au fonctionnement du site.

Un seul de ces signaux suffit à déclencher le constat. Les trois ensemble correspondent au schéma typique d'un conteneur Google Tag Manager qui se déclenche avant la barrière de consentement.

Le cadre juridique, en bref

Nous ne sommes pas votre avocat. Les faits bruts :

GDPR Art. 6(1)(a) exige une base légale valide pour le traitement de données personnelles. Pour les traceurs non essentiels, cette base est le consentement.
GDPR Art. 7 fixe le standard d'un consentement valide : libre, spécifique, éclairé, univoque et révocable.
ePrivacy Directive Art. 5(3) exige spécifiquement le consentement avant tout stockage ou accès à des informations sur l'équipement terminal d'un utilisateur — c'est-à-dire avant la lecture ou l'écriture de cookies et identifiants similaires. Savoir si une requête réseau précédant le consentement franchit le seuil de l'infraction dépend de ce qu'elle lit ou écrit sur l'appareil, des identifiants qu'elle transporte et de sa qualification possible comme « strictement nécessaire » — autant de questions que les régulateurs pèsent.

Les transpositions nationales diffèrent dans le détail. Le TTDSG allemand (devenu TDDDG) et la transposition française par la Loi Informatique et Libertés, telle que mise en œuvre par la CNIL, ont produit la pratique répressive la plus visible. Des DPAs à travers l'UE ont mis en garde contre les schémas de tracking avant consentement ; les seuils d'application concrets varient selon les juridictions. Le principe sous-jacent est partout le même : consentement d'abord, traceur ensuite.

Ce que les régulateurs ont effectivement fait

Une chronologie courte et partielle de décisions où le tracking avant consentement était le constat central :

CNIL contre Google (décembre 2020) : 100 millions EUR pour avoir déposé des cookies publicitaires sur google.fr sans consentement préalable.
CNIL contre Amazon Europe Core (décembre 2020) : 35 millions EUR pour le même schéma sur amazon.fr.

Ce ne sont pas les seules affaires — ce sont les plus structurantes. Le schéma commun est constant : le régulateur a mesuré le comportement réseau et a traité la réalité technique comme déterminante, indépendamment du texte de la politique.

Les scripts qui en sont le plus souvent à l'origine

À peu près dans l'ordre où nous les rencontrons comme cause principale d'un scan à haut risque :

Conteneurs Google Tag Manager configurés sans gating de consent mode, ou avec un consent mode mal configuré dont l'état par défaut est « granted ».
Meta Pixel chargé directement via <script src> plutôt qu'encadré par un callback de consentement.
Enregistrement de session Hotjar démarré avant la fermeture de la bannière.
LinkedIn Insight pour le retargeting B2B, en particulier sur les sites d'agences et de SaaS.
TikTok Pixel sur l'e-commerce grand public.
Implémentations d'analytics first-party qui lisent les propriétés de navigator ou déposent des cookies de fingerprinting avant toute action utilisateur.

Le facteur commun n'est presque jamais le script lui-même — c'est son déploiement. Chacun de ces fournisseurs publie une méthode documentée pour conditionner le déclenchement à un signal de consentement ; les instructions d'installation par défaut, en revanche, ne le mentionnent souvent pas.

À quoi ressemble un scan propre

Un site qui passe notre vérification avant consentement fait l'une des choses suivantes :

Ne charge aucun tracking tiers tant que le consentement n'est pas donné. Les cookies fonctionnels (session, préférence de langue, CSRF) sont acceptables.
Charge le tag manager dans l'état « denied », avec tous les tags non essentiels conditionnés à des signaux de consentement explicites, et met à jour l'état via Google Consent Mode v2 ou un mécanisme équivalent après l'action de l'utilisateur.
Charge des stubs de traceurs qui ne transmettent pas d'identifiants tant que le drapeau de consentement n'est pas levé.

Dans notre corpus du premier trimestre 2026 portant sur 97 000 sites de l'UE, 68 % avaient un service de tracking actif avant toute décision de consentement. La minorité de sites qui passent la vérification avant consentement partage un profil : le réseau dans la fenêtre pré-consentement est dominé par le document lui-même, des fichiers CSS et de polices, et un favicon — rien qui ne transporte un identifiant hors de l'appareil.

Sample scan

78 / 100

High Risk · 23 trackers · pre-consent tracking: yes

See sample report →

Comment corriger

La version honnête : il n'y a pas de raccourci. Chaque tag doit être audité pour vérifier s'il se déclenche avant que le signal de consentement ne soit posé. Étapes qui fonctionnent en pratique :

Ouvrez le site dans un profil de navigateur propre, outils de développement ouverts.
Filtrez le réseau sur « tiers » et rechargez.
Tout ce qui se déclenche avant un clic sur un bouton de la bannière est un candidat.
Pour chaque candidat, trouvez le loader (généralement une balise script, un déclencheur de tag manager, ou un snippet inline) et conditionnez-le au signal de consentement.
Re-testez. Répétez jusqu'à ce que la fenêtre pré-consentement soit vide de traceurs.

Si vous utilisez une plateforme de gestion du consentement, son mode « bloquer jusqu'au consentement » est nécessaire mais pas suffisant — beaucoup de CMP ne bloquent que l'écriture du cookie, pas la requête. L'Article 5(3) de l'ePrivacy Directive exige le consentement avant tout stockage ou accès à des informations sur l'appareil de l'utilisateur (cookies, local storage, identifiants similaires). Savoir si une requête réseau précédant le consentement déclenche cette obligation dépend de ce que la requête lit sur l'appareil ou y écrit — une question liée aux faits.

Pour un exemple sur votre propre domaine, lancez un scan et consultez le panneau « réseau pré-consentement » du rapport. Chaque requête en infraction y est listée avec sa pile d'initiateurs, vous permettant de la retracer jusqu'au fichier source dans votre code.