Bloquer les cookies avant consentement : le guide technique (script blocking)

Pour être conforme au RGPD, il faut conditionner le chargement des scripts de traçage au consentement de l'internaute (script blocking) : aucun cookie non essentiel ne doit se déposer avant l'accord. Concrètement, vous neutralisez les balises analytics et publicitaires au chargement de la page, puis vous les activez uniquement quand l'utilisateur a coché la catégorie correspondante dans le bandeau cookie.

Ce guide s'adresse aux développeurs et aux agences qui intègrent une solution de consentement. Il détaille la méthode du script blocking (balises text/plain ou blocage géré par la CMP), l'auto-clear des cookies déjà posés après un refus, et la vérification dans les DevTools. Les extraits de code sont volontairement courts et adaptables à n'importe quelle stack.

Pourquoi le blocage préalable est une obligation

Le dépôt d'un cookie de traçage avant le recueil du consentement est une non-conformité directe au RGPD et aux lignes directrices de la CNIL. Le consentement doit être libre, spécifique, éclairé et univoque (article 4-11 du RGPD) : un traceur qui se déclenche pendant le chargement de la page, avant tout clic, ne respecte aucune de ces conditions.

La CNIL nomme ce principe le blocage préalable (ou prior blocking) : les traceurs non essentiels restent inactifs tant que l'internaute n'a pas exprimé son choix. Seuls les cookies strictement nécessaires au fonctionnement du service en sont exemptés (session, panier, préférence de langue, mesure d'audience exemptée sous conditions).

L'enjeu financier n'est pas théorique. Le RGPD prévoit des amendes jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial. En 2025, la CNIL a sanctionné Shein à hauteur de 150 millions d'euros, en partie pour des cookies déposés sans consentement valable. Un bandeau qui affiche un choix pendant que les traceurs tournent déjà en arrière-plan est un cas classique de contrôle.

La méthode du script blocking, étape par étape

Le script blocking consiste à empêcher un script de s'exécuter au parsing de la page, puis à le réactiver après consentement. Deux approches coexistent : la neutralisation manuelle par balise text/plain, et le blocage automatique géré par une CMP.

1. Neutraliser le script au chargement

Un script chargé normalement s'exécute dès que le navigateur le rencontre, et dépose ses cookies immédiatement. Pour l'en empêcher sans le supprimer, passez son attribut type à text/plain : le navigateur le lit comme du texte inerte et ne l'exécute pas.

<!-- Avant : le script s'execute au parsing, le cookie tombe tout de suite -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXX"></script>
 
<!-- Apres : script neutralise, en attente de consentement -->
<script type="text/plain" data-consent="analytics"
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXX"></script>

L'attribut data-consent="analytics" sert de marqueur : il relie le script à une catégorie de consentement (analytics, marketing, etc.). Appliquez la même transformation à chaque script tiers non essentiel : GA4, Meta Pixel, TikTok, chatbots, cartes intégrées.

2. Activer les scripts après le consentement

Quand l'utilisateur accepte une catégorie, parcourez les balises neutralisées correspondantes et remplacez-les par un script exécutable. Un type="text/plain" ne se réactive pas seul : il faut recréer un élément <script>.

function activerScripts(categorie) {
  var selecteur = 'script[type="text/plain"][data-consent="' + categorie + '"]';
  document.querySelectorAll(selecteur).forEach(function (ancien) {
    var script = document.createElement('script');
    Array.from(ancien.attributes).forEach(function (attr) {
      if (attr.name !== 'type') script.setAttribute(attr.name, attr.value);
    });
    script.textContent = ancien.textContent;
    ancien.parentNode.replaceChild(script, ancien);
  });
}
 
// A brancher sur l'evenement emis par votre bandeau cookie
window.addEventListener('consent:analytics', function () {
  activerScripts('analytics');
});

3. Laisser la CMP gérer le blocage

Écrire et maintenir cette logique pour chaque traceur devient vite coûteux, surtout sur un parc de sites clients. Une CMP (Consent Management Platform) automatise le blocage préalable : elle intercepte les scripts, applique le mapping catégorie par catégorie, et gère l'activation selon le choix de l'utilisateur. Vous déclarez vos traceurs une fois, la CMP s'occupe du reste et journalise la preuve de consentement.

C'est aussi la CMP qui transmet les signaux du Google Consent Mode v2 aux balises Google. Le blocage préalable et le GCM v2 sont complémentaires : le premier empêche le dépôt de cookies, le second ajuste le comportement des balises Google selon le consentement. Notre guide pour configurer le Consent Mode dans Google Tag Manager détaille ce branchement.

L'auto-clear : supprimer les cookies déjà posés

L'auto-clear supprime les cookies qui ont été déposés avant un refus ou lors d'un retrait de consentement. Le blocage préalable empêche les nouveaux dépôts, mais il ne nettoie pas ceux qu'un chargement antérieur, un cache ou un tag mal configuré aurait déjà laissés dans le navigateur.

Pour supprimer un cookie côté client, réécrivez-le avec une date d'expiration passée, sur le bon chemin et le bon domaine :

function supprimerCookies(noms) {
  var domaines = [location.hostname, '.' + location.hostname];
  noms.forEach(function (nom) {
    domaines.forEach(function (domaine) {
      document.cookie = nom +
        '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/; domain=' + domaine;
    });
  });
}
 
// Apres un refus ou un retrait du consentement analytics
supprimerCookies(['_ga', '_gid', '_gat']);

Deux limites à connaître. Les cookies posés en HttpOnly ne sont pas accessibles au JavaScript : leur suppression passe par le serveur. Et l'auto-clear reste un filet de sécurité, pas une excuse : la conformité repose d'abord sur le blocage en amont. Une CMP applique cet auto-clear automatiquement à chaque changement de choix.

Comment vérifier que le blocage fonctionne

Pour vérifier le blocage préalable, ouvrez les DevTools sur l'onglet Application, chargez la page en refusant les cookies, et contrôlez qu'aucun cookie non essentiel n'apparaît. Le test se fait toujours en navigation privée pour partir d'un état propre.

1. Ouvrez les DevTools (F12) et allez dans l'onglet Application, section Cookies (et Storage pour le localStorage).
2. Chargez la page sans interagir avec le bandeau, ou en refusant. Seuls les cookies essentiels et celui du consentement doivent être présents.
3. Contrôlez l'onglet Network : les requêtes vers les domaines de traçage (google-analytics.com, facebook.net) ne doivent pas partir avant l'accord.
4. Acceptez, puis rechargez : les cookies analytics et marketing doivent alors apparaître, ce qui confirme que l'activation fonctionne dans les deux sens.

Pour un audit exhaustif sur plusieurs pages, un scanner de cookies automatise ce contrôle : il liste chaque traceur, sa catégorie et le moment de son dépôt, ce qui repère les scripts oubliés qu'un test manuel laisse passer.

Les erreurs fréquentes

• Bloquer l'affichage sans bloquer le dépôt. Cacher le bandeau ou griser un bouton n'empêche pas les scripts de tourner. Le blocage se joue sur l'exécution des traceurs, pas sur l'interface.
• Oublier le Google Tag Manager. Charger GTM avant consentement peut suffire à déclencher des balises. Neutralisez le conteneur lui-même ou pilotez-le via le Consent Mode v2.
• Ignorer le localStorage et les pixels. Le blocage ne concerne pas que document.cookie : un pixel ou une entrée localStorage déposée avant l'accord pose le même problème.
• Ne tester qu'en acceptation. L'erreur se voit surtout au refus. Validez toujours le scénario "je refuse" dans les DevTools.
• Traiter la mesure d'audience comme exemptée par défaut. L'exemption de consentement analytics est conditionnelle (configuration précise, pas de croisement). Sans ces conditions, le traceur reste soumis au blocage.

Questions fréquentes (FAQ)

Faut-il bloquer tous les cookies avant consentement ? Non, seulement les cookies non essentiels : traçage, publicité, réseaux sociaux, chatbots tiers. Les cookies strictement nécessaires au service (session, panier, sécurité, préférence de langue) sont exemptés et peuvent se déposer sans accord préalable.

Quelle différence entre script blocking et Consent Mode v2 ? Le script blocking empêche physiquement le chargement des scripts et le dépôt de cookies tant que l'accord n'est pas donné. Le Google Consent Mode v2 ne bloque pas les balises Google : il ajuste leur comportement selon les signaux de consentement. Les deux se complètent, ils ne se remplacent pas.

La balise text/plain suffit-elle pour être conforme ? Elle neutralise l'exécution du script, ce qui est la bonne base. Mais la conformité demande aussi une réactivation par catégorie, l'auto-clear après refus et la journalisation de la preuve de consentement. C'est l'ensemble que gère une CMP.

Comment savoir si un cookie se dépose avant l'accord ? Ouvrez les DevTools, onglet Application, en navigation privée, et chargez la page sans accepter. Tout cookie non essentiel présent à ce stade est déposé trop tôt. Un scanner de cookies automatise ce contrôle sur l'ensemble du site.

Passez le blocage préalable en automatique

Coder le script blocking à la main reste faisable sur un site, mais devient ingérable sur un parc de sites clients, avec des traceurs qui changent et une preuve de consentement à conserver. ConsentLab bloque les scripts avant consentement, applique l'auto-clear et transmet les signaux du GCM v2, sans code sur mesure à maintenir.