GTM intègre plusieurs mécanismes natifs pour gérer le consentement : le Consent Mode, les Consent Settings (Built-In et Additional Consent Checks), et la Consent Overview. Ces fonctionnalités peuvent être utiles si vous n'utilisez pas de CMP ou si vous gérez le consentement manuellement, mais elles suscitent souvent de la confusion lorsqu'on utilise une CMP comme Axeptio — on pourrait croire qu'il faut les configurer pour être conforme. Voici ce que chacune fait réellement, et comment elles s'articulent avec Axeptio.

Le Consent Mode est un mécanisme propriétaire de Google. Il permet aux balises Google (Google Ads, GA4, Floodlight…) de modifier leur comportement en fonction de signaux de consentement (ad_storage, analytics_storage, ad_user_data, ad_personalization, etc.) : par exemple, envoyer des données anonymisées plutôt que de ne pas s'exécuter du tout. Google l'a conçu avec une ambition universelle — les 7 types de signaux disponibles (ad_storage, analytics_storage, ad_user_data, ad_personalization pour les services Google, et functionality_storage, personalization_storage, security_storage pour les tags tiers) en sont la preuve. En pratique cependant, peu de services tiers ont rendu leurs templates consent-aware, et le Consent Mode ne permet pas de gérer le consentement service par service.

Dans chaque balise GTM, une section Consent Settings (Beta) est disponible. Elle affiche deux blocs distincts.

Les Built-In Consent Checks indiquent quels signaux Consent Mode la balise consulte nativement (par exemple ad_storage et analytics_storage pour une balise Google Analytics). Vous ne pouvez pas les modifier — GTM les détermine automatiquement selon le type de balise, et ils ne sont visibles que si le template de la balise accède activement à l'état du consentement dans son code.

Ces checks ne bloquent pas le déclenchement de la balise. En mode avancé du Consent Mode — c'est-à-dire si la balise se déclenche sans être conditionnée par un trigger Axeptio — ils modifient son comportement selon l'état des signaux : une balise Google Ads enverra par exemple des données anonymisées plutôt que des données personnelles si ad_storage est denied. Puisqu'Axeptio gère ces signaux, les Built-In Checks fonctionnent automatiquement sans aucune configuration de votre part.

Ce paramètre permet de conditionner le déclenchement d'une balise à l'état de signaux Consent Mode spécifiques. Il est particulièrement utile dans des configurations sans CMP, ou avec une CMP qui gère uniquement des catégories de finalité sans granularité au niveau du service.

Il propose trois options :

Avec Axeptio, laissez ce paramètre sur "Not set". "No additional consent required" est également acceptable, mais "Not set" est plus juste : vous ne déclarez pas que la balise ne nécessite pas de consentement, vous laissez simplement Axeptio s'en charger.

Ce choix a un effet d'affichage dans la Consent Overview : les balises en "Not set" apparaissent dans "Consent not configured", tandis que celles en "No additional consent required" apparaissent dans "Consent configured". Les deux sont corrects avec Axeptio — c'est uniquement une question d'affichage, pas de conformité. Si la Consent Overview génère de la confusion dans votre équipe, sachez qu'il est possible de la désactiver dans Admin > Paramètres du conteneur, en décochant "Activer l'aperçu du consentement".

Pourquoi ne pas utiliser "Require additional consent for tag to fire" avec Axeptio ?

Il y a deux raisons. D'abord, si vous avez déjà conditionné vos balises selon nos préconisations, cela crée une double condition : GTM vérifie le consentement de son côté, en parallèle de ce qu'Axeptio a déjà communiqué. Une balise peut alors ne jamais se déclencher, même si l'utilisateur a donné son consentement.

Ensuite, cette option vous demande de relier une balise à un signal Google Consent Mode, alors qu'Axeptio part d'une philosophie différente. Axeptio gère le consentement service par service : chaque service est accepté ou refusé individuellement. Si vous reliez un pixel Meta et un pixel Pinterest au même signal ad_storage, vous les conditionnez au même résultat — alors qu'un utilisateur peut très bien avoir accepté l'un et refusé l'autre. Vous perdez la précision qu'Axeptio vous donne, et le contrôle que vous offrez à vos visiteurs.

GTM propose un déclencheur natif appelé Consent Initialization - All Pages. Il se déclenche avant tout autre déclencheur dans le conteneur — c'est le tout premier à s'exécuter sur chaque page. Son rôle est d'établir les valeurs par défaut des signaux Consent Mode avant que les autres balises ne commencent à se déclencher.

C'est précisément ce que fait Axeptio : il s'appuie sur ce déclencheur pour définir les signaux par défaut dès le chargement de la page, avant tout le reste. Si vous chargez Axeptio via GTM, vous devez impérativement configurer votre balise Axeptio avec le déclencheur Consent Initialization - All Pages — et non "All Pages" ou "Page View". Sans cela, d'autres balises peuvent se déclencher avant qu'Axeptio ait eu le temps de définir les signaux Consent Mode par défaut.

La gestion du consentement avec Axeptio passe par les événements et variables qu'Axeptio envoie à GTM, pas par les Consent Settings. C'est cette approche qui vous permet de conditionner chaque balise au consentement du service correspondant, avec la granularité nécessaire pour être conforme.

Pour configurer vos balises, commencez par Conditionner au consentement vos balises GTM : introduction.