Les bloqueurs de pub bloquent le suivi, mais aussi les bannières de consentement

Les bloqueurs de publicité peuvent empêcher les scripts CMP de se charger entièrement. Lorsqu'une plateforme de gestion du consentement (CMP) est bloquée, la bannière de consentement n'apparaît pas et l'état de consentement de l'utilisateur n'est jamais enregistré, et les balises dépendant du Consent Mode V2 se déclenchent dans un état indéfini. Cela crée à la fois un écart de conformité au GDPR et un écart de mesure.

Cet article couvre ce qui se passe techniquement, ce que les organismes chargés de l'application du GDPR exigent, et comment le GTM côté serveur avec un hébergement CMP de première partie élimine la vulnérabilité.

Que se passe-t-il lorsqu'un bloqueur de publicité bloque ta bannière de consentement ?

La séquence commence par le script du CMP. La plupart des CMP (comme Cookiebot, OneTrust ou Quantcast) fournissent ce script à partir d'un CDN tiers. Chaque fournisseur utilise des domaines CDN qui sont connus du public, cohérents à travers des milliers d'implémentations et mis à jour selon des calendriers prévisibles.

C'est cette cohérence qui permet de les cibler. Les listes de filtres fonctionnent en faisant correspondre les destinations des requêtes à des domaines connus. Un domaine CDN qui apparaît sur des milliers de sites est exactement le type de modèle stable que les responsables des listes de filtres recherchent. EasyPrivacy, les filtres de confidentialité de uBlock Origin et plusieurs bloqueurs de navigateur incluent déjà des domaines CDN CMP courants.

Lorsqu'un visiteur dont l'un de ces bloqueurs est actif arrive sur une page, le navigateur demande le script CMP. Le bloqueur l'intercepte. Le script ne se charge jamais. La page est affichée sans bannière de consentement.

Le visiteur voit la page normalement. Rien ne semble cassé. Du côté du site, aucun état de consentement n'est enregistré pour cette session.

Ce qui se passe ensuite dépend de la façon dont la configuration du tag gère un signal de consentement absent :

• Les étiquettes configurées avec le mode Consent Mode V2 attendent un signal qui n'arrive jamais.
• Les balises avec des valeurs par défaut de repli fonctionnent selon les valeurs par défaut qui ont été définies.
• Les balises sans configuration de consentement explicite peuvent tirer sans base légale.

Dans les trois cas, l'utilisateur n'a jamais reçu de bannière. Il n'existe aucune trace de décision.

Ce que fait la V2 de Consent Mode lorsque le consentement n'est pas défini.

La V2 de Consent Mode de Google contrôle le comportement des balises par le biais d'états de signal par catégorie :

analytics_storage, ad_storage et ad_personalization. Chaque catégorie est définie comme accordée ou refusée. Les balises écoutent le signal correspondant avant d'agir.

Lorsque le CMP est bloqué, aucun signal n'est émis. La balise ne reçoit pas de refus et ne tient pas. Elle ne reçoit pas granted et ne se déclenche pas. Elle tombe dans son état par défaut, une configuration qui vit dans le conteneur GTM, généralement à l'intérieur d'un modèle de balise ou d'un bloc d'initialisation.

Certaines configurations ne tiennent pas compte des valeurs par défaut explicites. L'hypothèse est que le CMP se charge rapidement et émet un signal avant qu'une balise n'agisse. Cette hypothèse fonctionne lorsque le CMP se charge.

Le comportement de la plateforme dans le cas non défini n'est souvent pas celui auquel les équipes s'attendent :

• GA4: un état non défini peut laisser passer des signaux de modélisation.
• Balises publicitaires: les tirs partiels dans un état non défini peuvent enregistrer un événement qui alimente l'attribution.
• Certains modèles de balises: l'absence de refus explicite est considérée comme accordée.

Il en résulte des données de mesure qui ne peuvent pas être attribuées à un enregistrement de consentement vérifié.

Pourquoi il s'agit d'un problème de conformité au GDPR, et pas seulement d'un problème d'UX.

L'article 7 du GDPR fait peser la charge de la preuve sur le responsable du traitement. Le consentement doit être librement donné, spécifique, éclairé et sans ambiguïté. En cas de contestation, le responsable du traitement doit être en mesure de démontrer que le consentement a été donné, avec des enregistrements, pour cette session.

Un CMP bloqué ne laisse aucune preuve au contrôleur : aucune trace du rendu de la bannière, aucune trace de la réponse de l'utilisateur. Trois organismes européens chargés de l'application de la loi se sont penchés directement sur cette question :

1. L'autorité néerlandaise de protection des données (Autoriteit Persoonsgegevens) a déclaré que le suivi sans enregistrement de consentement valide enfreint le GDPR, quelle que soit la cause de l'échec du mécanisme de consentement. Les défaillances techniques dans le flux de consentement ne transfèrent pas la responsabilité hors du contrôleur. (Source : autoriteitpersoonsgegevens.nl)
2. La CNIL française a publié des directives selon lesquelles le consentement doit être recueilli avant tout traitement de données personnelles, et que les organisations sont tenues de s'assurer que leurs mécanismes de consentement fonctionnent réellement. Les balises qui tirent dans un état de repli non défini ne relèvent pas de cette norme. (Source : cnil.fr)
3. La DSK (Datenschutzkonferenz) allemande a renforcé le fait que le traitement dépendant du consentement doit être vérifiable et reproductible. Les sessions qui se déroulent sans enregistrement du consentement ne répondent pas à cette exigence. (Source : datenschutzkonferenz-online.de)

Les trois organismes ont cité la fiabilité du flux de consentement dans des cas d'application active.

La seule façon de garantir la conformité est de ne rien envoyer par défaut. C'est une voie royale sur le marché du suivi et de l'analyse, mais en conjonction avec les adblockers, cela peut causer un réel préjudice à tes données.

La perte de données et les personnes concernées

Le chemin conforme a un coût réel. Les sessions où le CMP a été bloqué ne génèrent aucune donnée d'attribution, aucun signal de conversion pour les plateformes publicitaires et aucun événement GA4.

L'ampleur dépend de l'audience. Environ 30 % des internautes dans le monde utilisent une forme ou une autre de bloqueur de publicité (GWI, 2025). Pour les publics techniques (développeurs, spécialistes du marketing, professionnels de l'analyse), la part est plus élevée.

La plupart de ces utilisateurs ne bloquent pas les mesures intentionnellement. Les recherches menées par GWI en 2025 montrent que seuls 26,6 % des utilisateurs de bloqueurs de publicité dans le monde citent "l'arrêt de la collecte de données" comme raison d'en utiliser un. La majorité d'entre eux (63,5 %) disent qu'il y a trop de publicités. Par ailleurs, 53,5 % disent que les publicités interfèrent avec la navigation, selon Backlinko, 2025.

Cette distinction est importante. La plupart des utilisateurs qui ont installé un bloqueur de publicité ne refusent pas les analyses. Ils veulent moins de publicités et un chargement plus rapide des pages. Si une bannière de consentement leur parvient, beaucoup l'accepteront et leurs données circuleront avec une base légale.

Les sessions qui restent sombres sont celles où la bannière n'est jamais apparue, non pas parce que l'utilisateur a refusé, mais parce que le mécanisme de consentement a échoué silencieusement.

La correction de la livraison CMP permet de récupérer ces sessions.

Comment le GTM côté serveur élimine la vulnérabilité de la bannière de consentement.

La racine du problème est l'endroit où le script CMP est hébergé. Un CDN tiers a un domaine fixe et connu. Ce domaine apparaît dans les listes de filtres. Tout CMP provenant d'un CDN bien connu est une cible stable.

L'hébergement du script CMP sur un sous-domaine de première partie change cela. Le sous-domaine appartient au site. Il n'apparaît pas dans les listes de filtres génériques ciblant les fournisseurs de CMP. Un bloqueur ne peut pas s'y opposer sans bloquer également les actifs de première partie du site, ce que la plupart des listes de filtrage évitent spécifiquement.

Lorsque le navigateur demande le script CMP à partir d'un domaine contrôlé par le site, le script se charge. La bannière s'affiche. L'utilisateur voit l'invite et un signal de consentement est émis avant que les balises ne soient activées.

Il s'agit du même principe d'infrastructure décrit dans l'article Pourquoi le suivi côté serveur peut encore perdre des données (et comment le script de suivi amélioré y remédie). Là, le fait de déplacer la demande de suivi vers un point de terminaison de première partie a empêché les bloqueurs de la faire correspondre à des modèles de CDN analytiques connus. Appliquée à la couche de consentement, la même configuration côté serveur protège un élément différent : le CMP atteint le navigateur au lieu d'être intercepté avant que la bannière ne puisse apparaître.

Le GTM côté serveur peut gérer la livraison de CMP dans le cadre d'une configuration first-party plus large. Lorsque le script CMP est servi à partir du même sous-domaine que le conteneur du serveur, le signal de consentement atteint le conteneur avant que les balises de mesure ou de publicité ne soient activées.

Le tableau de bord TAGGRS peut t'aider à vérifier que cela fonctionne. Dans les analyses côté serveur, vérifie si les balises de consentement se déclenchent dans les sessions sans demande CMP enregistrée. Ce schéma, des événements actifs mais aucun appel CMP visible, signifie que la bannière de consentement n'atteint pas une partie de l'audience.

Ce qu'exige une configuration de consentement résiliente

1. Héberge le script CMP sur un sous-domaine de première partie. Retire le domaine CDN fixe de l'équation. Les listes de filtres ne peuvent pas bloquer silencieusement un sous-domaine que le site contrôle.

2. Définis explicitement les valeurs par défaut de Consent Mode V2 pour toutes les régions. Chaque balise du conteneur doit avoir un comportement défini pour le cas où aucun signal de consentement ne s'est déclenché. Aucune balise ne doit fonctionner dans un état de repli non défini.

3. Lance les balises de consentement d'abord dans le conteneur GTM. Configure le bloc d'initialisation du consentement pour qu'il s'exécute avant toute mesure ou balise publicitaire. Le signal doit exister avant que quoi que ce soit n'agisse sur lui.

4. Vérifie par le biais du tableau de bord TAGGRS. Vérifie que les balises à consentement ne tirent pas dans les sessions où aucune demande de CMP n'est enregistrée. Rattrape les lacunes avant qu'elles n'apparaissent dans un audit.

5. Documente l'architecture du consentement. Enregistre le fournisseur de CMP, le chemin d'hébergement et les états par défaut explicites pour chaque région et catégorie de balises. Lorsqu'un régulateur demande des preuves, la documentation est la première chose qu'un contrôleur produit.

FAQ

Les bloqueurs de publicité peuvent-ils bloquer n'importe quel CMP, ou seulement des plateformes spécifiques ?

Tout CMP qui délivre son script à partir d'un CDN tiers est exposé. Les installations par défaut de Cookiebot, OneTrust et Quantcast chargent toutes le script à partir de l'infrastructure du fournisseur. Les CMP qui prennent en charge l'hébergement de première partie en tant qu'option de configuration ne sont pas affectés de manière inhérente, mais la fonctionnalité doit être activement activée.

Comment puis-je savoir si ma bannière de consentement est bloquée pour certains visiteurs ?

Le signal le plus clair est un décalage entre le volume de demandes côté serveur et les entrées du journal de consentement du CMP. Si le conteneur du serveur reçoit des demandes dans des sessions où aucun signal de consentement n'apparaît dans les enregistrements du CMP, la bannière ne s'est probablement pas chargée pour ces utilisateurs. Le tableau de bord TAGGRS permet de s'en rendre compte grâce aux catégories de demandes. Tu peux aussi tester directement en activant une liste de filtres commune dans un navigateur et en vérifiant si ta propre bannière de consentement se rend.

Le réglage du mode de consentement V2 par défaut sur " refusé " est-il suffisant pour rester conforme au GDPR lorsqu'un CMP est bloqué ?

Elle gère correctement le comportement des balises, mais ne résout pas le problème de fond. Le fait de définir les valeurs par défaut comme étant refusées signifie que les balises ne se déclencheront pas dans l'état indéfini, ce qui est la bonne configuration. Ce qu'il ne peut pas faire, c'est montrer aux utilisateurs une bannière qu'ils n'ont jamais reçue. Un organisme de réglementation qui demande à voir la preuve du consentement pour une session spécifique ne la trouvera pas. Les valeurs par défaut traitent de la conformité au niveau de la couche d'étiquetage. L'hébergement d'une CMP de première partie traite de la conformité au niveau de la collecte du consentement.

Quelle est la différence entre une bannière de consentement bloquée et ce contre quoi le script de suivi amélioré protège ?

Le script de suivi amélioré protège la demande de suivi après que le consentement a été recueilli. Il empêche les bloqueurs de publicité d'intercepter l'événement navigateur-serveur avant qu'il n'atteigne le conteneur du serveur. Une bannière de consentement bloquée est une étape plus précoce : l'utilisateur n'a jamais été invité à donner son consentement, aucun signal de consentement n'a jamais été enregistré et toutes les balises qui ont été activées l'ont été sans base légale. Les deux problèmes partagent la même solution d'infrastructure (livraison de première partie) mais se situent à des points différents du flux de données. Le script de suivi amélioré de TAGGRS est un outil parfait pour cacher le CMP aux adblockers et charger correctement une bannière de cookies via le conteneur GTM du serveur.