Pourquoi les bloqueurs de publicité peuvent empêcher l’affichage de votre bannière de consentement, et comment y remédier

Les statistiques de consentement sont calculées sur les visiteurs dont le navigateur a effectivement affiché la bannière. Certains n’atteignent jamais cette étape, parce qu’un bloqueur de publicité (ad blocker) a empêché le chargement des scripts de la plateforme de gestion du consentement (CMP). Pour eux, la bannière ne s’affiche pas. Ils naviguent pourtant sur le site, consultent des pages et achètent parfois, mais leurs visites n’apparaissent pas dans le reporting de consentement, et les balises qui dépendent de leur choix, de la mesure d’audience aux outils de support client, ne se déclenchent pas.

Ni le design ni la visibilité de la bannière ne sont en cause, et la CMP n’est pas mal configurée pour autant. Le phénomène tient à la façon dont les bloqueurs de publicité décident de ce qu’ils bloquent, et il peut toucher n’importe quel script chargé par une requête qui figure dans une liste de filtres.

Dans cet article, nous verrons comment un bloqueur de publicité en vient à bloquer une CMP déployée via Google Tag Manager, pourquoi une plateforme de consentement peut légitimement vouloir que sa bannière atteigne ces visiteurs sans aller à l’encontre de leurs préférences en matière de vie privée, et comment des solutions comme l’Enhanced Tracking Script de TAGGRS rétablissent le chargement du conteneur GTM, et avec lui celui de la bannière de consentement.

Pourquoi une CMP chargée via GTM peut ne pas s’afficher

Les bloqueurs de publicité n’analysent pas ce que fait un script. Ils comparent chaque requête que le navigateur s’apprête à envoyer à des listes de filtres, pour la plupart maintenues par des communautés de bénévoles, et annulent celles qui correspondent à un domaine, un chemin ou un motif connu. EasyPrivacy, l’une des listes les plus utilisées, est par exemple activée par défaut dans uBlock Origin et intégrée à AdBlock Plus et AdBlock.

Google Tag Manager est une cible naturelle pour ces listes, puisqu’il sert de point d’entrée à une large part des balises analytics et publicitaires du web. Lorsque la requête du conteneur est annulée, le navigateur ne reçoit jamais les instructions qu’il contient : aucune des balises qu’il embarque ne s’exécute, quelle que soit leur finalité.

Une CMP déployée via GTM peut faire partie de ces balises. L’intégration d’Axeptio via son template Google Tag Manager reste la configuration standard, et pour de bonnes raisons : la bannière, Google Consent Mode et les balises soumises au consentement sont gérés au même endroit, et les signaux de consentement parviennent à chaque balise dans le bon ordre. C’est aussi l’option la plus accessible pour les équipes qui ne disposent pas de compétences techniques avancées.

Certains délégués à la protection des données (DPO) privilégient une approche plus stricte, qui consiste à rendre la CMP indépendante de Google Tag Manager. Le SDK Axeptio peut alors être chargé directement dans le code de la page, avant le snippet GTM. C’est l’une des configurations recommandées par Axeptio lorsque la priorité est de garantir le chargement de la bannière sans dépendre du conteneur GTM, avec un consentement recueilli avant le déclenchement de la moindre balise. Les balises analytics et publicitaires continuent en revanche de passer par GTM et restent exposées au même filtrage. C’est là qu’une configuration server-side conserve tout son intérêt, comme nous le verrons plus loin.

Lorsque la CMP est chargée via GTM, le bloqueur n’intervient pas sur son paramétrage. Il agit une étape plus tôt, au moment où le conteneur lui-même est servi au navigateur. Du point de vue de la protection de la vie privée, rien de préjudiciable ne se produit : le conteneur ne se chargeant pas, aucune balise de tracking ne devrait se déclencher non plus. C’est l’étape du consentement qui disparaît. Aucune décision n’est enregistrée, l’événement axeptio_update n’atteint jamais le dataLayer, et des services fonctionnels déployés via le conteneur, comme un widget de chat ou un formulaire de réservation, peuvent ne pas se charger.

Une CMP doit-elle chercher à atteindre les visiteurs qui bloquent pourtant la publicité ?

Un visiteur qui installe un bloqueur de publicité exprime une attente sur la manière dont il souhaite être traité en ligne, et une CMP n’a pas à aider qui que ce soit à passer outre. Reste à savoir si afficher la bannière revient à ignorer ce choix. Trois arguments laissent penser que c’est l’inverse.

Le premier est juridique. Un bloqueur de publicité applique des listes de noms d’hôte et de motifs d’URL maintenues par des tiers. Il ignore quelles finalités poursuit le site et ne peut exprimer aucun choix entre elles. Au sens du RGPD, le consentement doit être spécifique et éclairé, et refuser doit être aussi simple qu’accepter. Un visiteur qui ne voit jamais la bannière n’a pas été sollicité, et le site ne dispose d’aucune trace prouvant qu’un choix lui a été proposé.

Le deuxième porte sur ce que transporte réellement un conteneur. Les gestionnaires de balises déploient couramment des services sans rapport avec la publicité : le gestionnaire de consentement lui-même, des outils de prévention de la fraude, un chat en direct, des widgets de paiement ou de réservation. Bloquer le conteneur les supprime en même temps que les traceurs, et un visiteur qui accepterait volontiers un chatbot de support tout en refusant la personnalisation publicitaire n’a aucun moyen de le faire savoir.

Le troisième tient au rôle de la bannière : c’est elle qui permet de faire respecter un refus. Lorsqu’un visiteur clique sur « Refuser », la CMP enregistre sa décision, passe les signaux Consent Mode à « denied » et permet à chaque balise en aval, dans le navigateur comme sur le serveur, d’en tenir compte. Sans bannière, il n’y a aucune décision à propager, et l’internaute ne peut compter que sur son bloqueur de publicité pour garder la maîtrise de ses données.

Ce raisonnement ne tient qu’à une condition : rétablir le conteneur ne doit jamais rétablir le tracking par défaut. Chaque balise qu’il contient doit rester conditionnée au choix du visiteur. TAGGRS, partenaire server-side d’Axeptio, pose le même principe dans la documentation de l’outil présenté plus bas, qu’il décrit comme un moyen d’améliorer la mesure des données collectées avec consentement, et non de suivre les internautes à l’encontre de leurs choix.

Rétablir le chargement du conteneur avec l’Enhanced Tracking Script de TAGGRS

Puisque les listes de filtres fonctionnent par reconnaissance, la parade la plus efficace consiste à rendre la requête du conteneur moins reconnaissable. C’est le principe de l’Enhanced Tracking Script développé par TAGGRS, la plateforme néerlandaise de tracking server-side avec laquelle Axeptio a annoncé un partenariat pour aider les marques à mettre en place un dispositif de collecte de données fiable et conforme.

Le script remplace le snippet GTM standard sur le site. Il masque le script de chargement de GTM et chiffre les chemins des requêtes d’événements envoyées au conteneur server-side, si bien que les règles qui recherchent googletagmanager.com, un ID de conteneur ou un chemin de tracking caractéristique ont beaucoup moins de chances de trouver une correspondance. Le conteneur est servi par le conteneur serveur TAGGRS du site, sur un sous-domaine propre au site, au lieu d’être appelé directement depuis le domaine de Google.

Pour les utilisateurs d’Axeptio, le premier effet concerne l’étape du consentement elle-même. Une fois le conteneur chargé, la balise Axeptio qu’il contient se déclenche et la bannière s’affiche avec la configuration déjà en place. Le choix du visiteur est enregistré, transmis à Google Consent Mode et, grâce à la configuration TAGGRS–Axeptio, envoyé au conteneur serveur, où il détermine quelles balises server-side peuvent se déclencher. Un visiteur qui aurait autrement échappé à toute demande de consentement est désormais sollicité, et sa réponse s’applique à l’ensemble de la stack.

Partant de là, TAGGRS met en avant deux autres bénéfices. Le script augmente le volume d’événements captés par GA4 et les plateformes publicitaires, y compris auprès des visiteurs qui utilisent un bloqueur de publicité ou des réglages de navigateur orientés confidentialité. Associé à une configuration server-side adaptée, il contribue en outre à prolonger la durée de vie des cookies dans les navigateurs qui les restreignent, comme Safari avec son Intelligent Tracking Prevention (ITP). L’étape du consentement intervenant désormais en premier, les événements supplémentaires récupérés sont des événements que le visiteur a acceptés.

TAGGRS précise que le script ne remplace pas le tracking server-side et que les requêtes envoyées directement par le navigateur vers des endpoints tiers peuvent toujours être bloquées. Son rôle est de sécuriser le chargement du conteneur, premier maillon de la chaîne.

La mise en place se fait en quelques étapes : activer le script dans le tableau de bord TAGGRS avec l’ID de votre conteneur web GTM, remplacer les snippets GTM standard sur le site (les deux ne doivent jamais cohabiter) et ajouter un client dédié dans le conteneur serveur. La procédure détaillée et les comportements attendus sont décrits sur la page consacrée à l’Enhanced Tracking Script. Pour transmettre le consentement Axeptio au conteneur serveur, suivez le guide Configure TAGGRS with Axeptio using GTM et, côté CMP, le guide Server Side Tracking Setup d’Axeptio.

La prochaine étape : sécuriser les ressources propres de la CMP

Une fois le conteneur sécurisé, les ressources propres de la CMP constituent l’étape suivante. La balise Axeptio charge le SDK, sa configuration et l’API de consentement depuis des domaines Axeptio, et ces requêtes peuvent être exposées au même type de filtrage.

Bonne nouvelle : Axeptio proposera prochainement de nouvelles options de proxy, qui permettront de charger la CMP et l’ensemble de ses composants, appels API compris, depuis votre propre domaine first-party.

En attendant, une configuration server-side avec TAGGRS apporte déjà plusieurs bénéfices. Déposer les cookies Axeptio côté serveur les met à l’abri des restrictions imposées par les navigateurs, ce qui contribue à réduire ce que l’on appelle la fatigue du consentement : le choix du visiteur est conservé pendant toute la durée configurée dans la CMP au lieu d’être écourté par ces restrictions, si bien que les visiteurs récurrents voient la bannière moins souvent et rencontrent moins de friction.

Ces briques se complètent. Un chemin de chargement que les listes de filtres peinent à reconnaître permet à la bannière d’atteindre des visiteurs qui lui échappent aujourd’hui. Les cookies déposés côté serveur, depuis une infrastructure alignée sur le domaine et l’adresse IP du site, peuvent persister assez longtemps dans Safari pour préserver l’attribution de conversions qui s’étalent sur plusieurs jours ou semaines, comme l’explique TAGGRS dans son article consacré au tracking server-side et au consentement. Ensemble, elles donnent à davantage de visiteurs la possibilité de faire un choix éclairé, et aux marques des données qui reflètent fidèlement ces choix.