Stockage du consentement dans GTM : mise en œuvre du stockage local ou des cookies first-party

Introduction : Pourquoi le choix du stockage est plus important qu'il n'y paraît

La plupart des équipes ont désormais mis en place une bannière de consentement et un CMP. Les cases légales sont cochées, la bannière s'affiche et les utilisateurs peuvent accepter ou refuser les cookies. Mission accomplie... n'est-ce pas ? Pas tout à fait.

En coulisses, la manière dont vous stockez l'état du consentement et dont vous le transmettez à Google Tag Manager et au mode de consentement a un impact direct sur :

• la qualité des données dans GA4 et d'autres outils ;

• l'efficacité du modèle de conversion ;

• la facilité du balisage côté serveur et des intégrations back-end ;

• la fréquence à laquelle vous finissez par redemander le consentement des utilisateurs.

Dans la pratique, il existe deux façons principales pour les CMP de conserver le choix de l'utilisateur :

2. Cookie first-party

3. localStorage

Du point de vue du CMP, les deux fonctionnent. D’un point de vue measurement, ils se comportent différemment, et ces différences sont importantes.

Cet article analyse :

• comment les cookies et le localStorage se comportent dans une configuration de consentement

• comment connecter à la fois GTM et Google Consent Mode avec un minimum de code personnalisé

• quand choisir l'un ou l'autre, avec des scénarios concrets

1. Cookies first-party vs localStorage : même objectif, comportement différent

Ces deux mécanismes sont utilisés pour « mémoriser » le fait qu'un utilisateur a accepté, refusé ou personnalisé son consentement. Mais en réalité, leur fonctionnement est très différent.

1.1 Cookie first-party – propriétés clés

• Stocké par le navigateur et envoyé avec chaque requête HTTP vers votre domaine.

• A une date d'expiration (par exemple 6 mois).

• Disponible très tôt dans le cycle de vie de la page (dès la toute première requête).

• Peut être lu par :

  • le script de votre CMP sur la page,

  • GTM (via une variable de cookie first-party),

  • GTM côté serveur / backends (à partir des en-têtes HTTP).

Implications pour le consentement :

• L'état du consentement est disponible dès que quelque chose s'exécute, ce qui est parfait pour les paramètres par défaut du mode consentement et la logique côté serveur.

• Lorsque les utilisateurs suppriment les cookies, ils suppriment également leur consentement → la bannière réapparaîtra lors de leur prochaine visite.

1.2 localStorage – propriétés clés

• Stocké uniquement dans le navigateur ; il ne voyage jamais avec les requêtes HTTP.

• Pas d'expiration intégrée ; stocké jusqu'à ce qu'il soit explicitement effacé (ou que les données du site soient effacées).

• Disponible uniquement une fois que JavaScript s'exécute sur la page.

• Non visible pour le GTM côté serveur ou votre backend, sauf si vous le transmettez vous-même.

Implications pour le consentement :

• Il y a toujours un petit décalage temporel : la page doit exécuter JS pour lire localStorage et exposer le consentement.

• L'état du consentement survit à la suppression des cookies, sauf si l'utilisateur efface toutes les données du site.

• Les systèmes côté serveur/backend ne peuvent pas le voir directement ; ils doivent obtenir le consentement via des balises (par exemple GA4 → sGTM) ou des paramètres personnalisés.

1.3 Comportement lorsque les utilisateurs « nettoient » leur navigateur

C'est l'une des grandes différences pratiques :

Si le consentement se trouve dans un cookie :

• Effacer les cookies = effacer le consentement.

• Les utilisateurs verront la bannière plus souvent.

Si le consentement se trouve dans localStorage :

• L'effacement des cookies n'efface pas le consentement.

• Les utilisateurs voient la bannière moins souvent → vous obtenez moins de « fatigue du consentement » et des taux de consentement plus stables.

Il n'y a pas d'option universellement « meilleure » ; c'est un compromis entre la stabilité de l'expérience utilisateur et le lien strict entre la présence des cookies et le consentement.

2. Mise en œuvre du consentement avec les cookies propriétaires (exemple GTM)

Il existe plusieurs façons valables de connecter ensemble un CMP, GTM et le mode Consentement.

La configuration ci-dessous est un exemple concret, utilisant :

• un CMP qui stocke le consentement dans un cookie first-party

• la variable de cookie first-party du GTM pour lire cet état

• un mappage simple vers le mode Consentement de Google

2.1 Hypothèses

Pour cet exemple, supposons que :

• Votre CMP écrit un cookie appelé cmp_consent une fois que l'utilisateur a fait son choix.

  La valeur du cookie se présente comme suit :

           cmp_consent=ad_storage=granted|analytics_storage=denied|ad_user_data=denied|ad_personalization=denied

• « ad_storage » correspond à : « Si cette option est définie sur refusé, les balises et pixels publicitaires de Google et Microsoft ne pourront pas lire ou écrire de cookies first-party. »

• « analytics_storage » correspond à : « Si cette option est définie sur refusé, les balises Google Analytics ne liront ni n'écriront de cookies analytiques, et les données collectées par Google Analytics n'utiliseront pas d'identifiants de cookies persistants (les identifiants sont réinitialisés à chaque chargement de page). »

• « ad_user_data » correspond à : « Si cette option est désactivée, les données utilisateur ne peuvent pas être utilisées avec les solutions publicitaires de Google pour la constitution d'audiences. »

• « ad_personalization » correspond à : « Si cette option est désactivée, les données collectées sur ce site web ne seront pas utilisées à des fins de remarketing dans les solutions publicitaires de Google.

Vous pouvez adapter les noms et les formats à votre propre CMP.

À titre d'exemple, nous utiliserons le modèle Simo Ahava Consent mode pour configurer le consentement.

2.2 Étape 1 – Laissez le CMP écrire le cookie de consentement

Cette partie est généralement gérée dans l'interface utilisateur du CMP ou dans la configuration du script, et non dans GTM.

Configuration type dans votre CMP :

• Méthode de stockage : Cookie / Cookie first-party

• Nom du cookie : cmp_consent

• Lorsque l'utilisateur enregistre ses préférences :

• S'il accepte tout → ad_storage=granted|analytics_storage=granted|ad_user_data=granted|ad_personalization=granted

• S'il refuse tout → ad_storage=denied|analytics_storage=denied|ad_user_data=denied|ad_personalization=denied

• S'il personnalise → mélange d'acceptations/refus

Vous n'avez pas besoin de coder cela vous-même ; assurez-vous simplement de connaître :

• le nom du cookie

• le format de la valeur

2.3 Étape 2 – Exposer le cookie à GTM via une variable de cookie first-party

Nous allons maintenant informer GTM de l'existence de ce cookie.

1. Allez dans Variables → Nouveau

2. Type de variable : Cookie first-party

3. Nommez-le : Cookie – cmp_consent

4. Nom du cookie : cmp_consent

Cette variable renverra désormais une chaîne telle que :

ad_storage=granted|analytics_storage=granted|ad_user_data=granted|ad_personalization=granted

chaque fois que le cookie existe.

2.4 Étape 3 – Extraire chaque valeur de consentement avec des variables Regex

À l'heure actuelle, {{Cookie – cmp_consent}} renvoie une chaîne complète, par exemple :

ad_storage=granted|analytics_storage=denied|ad_user_data=denied|ad_personalization=denied

Le modèle Consent Mode de Simo attend quatre variables, une par signal de consentement, chacune renvoyant exactement granted ou denied.
Un moyen simple d'y parvenir consiste à utiliser des variables de table Regex.

2.4.1 Créer Regex – ad_storage

1. Allez dans Variables → Nouveau

2. Type : Table Regex

3. Nom : Regex – ad_storage

4. Variable d'entrée : {{Cookie – cmp_consent}}

5. Pour le modèle, remplissez « (^|\|)ad_storage=granted(\||$) ».

6. Comme sortie, remplissez le tableau avec « granted ».

7. Comme valeur par défaut, mettez « denied ».

Ainsi, si le cookie contient ad_storage=granted, cette variable renvoie granted.
Si le champ est manquant ou mal formé, il revient à denied.

2.4.2 Créer Regex – analytics_storage

Même principe :

1. Variables → Nouveau → Table Regex

2. Nom : Regex – analytics_storage

3. Variable d'entrée : {{Cookie – cmp_consent}}

4. Pour le modèle, remplissez « (^|\|)analytics_storage=granted(\||$) ».

5. Comme sortie, remplissez le tableau avec « granted ».

6. Comme valeur par défaut, indiquez « refusé ».

2.4.3 Créer une expression régulière – ad_user_data et expression régulière – ad_personalization

Répétez l'opération pour les deux signaux spécifiques à la version 2.

ad_user_data:

• Nom : Regex – ad_user_data

• Modèle : (^|\|)ad_user_data=granted(\||$) → Sortie « granted »

• Valeur par défaut : denied

ad_personalization

• Nom : Regex – ad_personalization

• Modèle : (^|\|)ad_personalization=granted(\||$) → Sortie « granted »

• Valeur par défaut : denied

À ce stade, vous disposez de quatre variables :

• {{Regex – ad_storage}}

• {{Regex – analytics_storage}}

• {{Regex – ad_user_data}}

• {{Regex – ad_personalization}}

Chacune renvoie « granted » ou « denied », exactement comme l'exige le modèle de Simo.

2.5 Étape 4 – Configurer la balise Simo Ahava Consent Mode

Nous intégrons maintenant ces variables dans le modèle de balise Consent Mode (balises Google).

2.5.1 Ajouter le modèle à votre conteneur

1. Dans GTM, allez dans Modèles → Rechercher dans la galerie

2. Recherchez « Consent Mode (Google tags) »

3. Ajoutez le modèle de Simo Ahava

Vous disposez désormais d'un nouveau type de balise.

2.5.2 Créer la balise « par défaut » Consent Mode

1. Allez dans Balises → Nouvelle

2. Type de balise : Consent Mode (Google tags)

3. Nom : Consent Mode – par défaut (à partir du cookie)

       Configurez :

• Type de commande : default

• Région : all

• ad_storage : {{Regex – ad_storage}}

• analytics_storage : {{Regex – analytics_storage}}

• ad_user_data : {{Regex – ad_user_data}}

• ad_personalization : {{Regex – ad_personalization}}

       Laissez wait_for_update comme bon vous semble (par exemple 500-1000 ms) en fonction du comportement de votre CMP.

       4. Déclencheur : Initialisation du consentement – Toutes les pages

       Lorsque cette balise se déclenche :

• Elle lit le cookie via vos variables Regex

• Envoie une commande par défaut avec les quatre états de consentement

• S'assure que GA4 / Google Ads / autres balises Google connaissent le statut du consentement avant leur exécution

2.5.3 Facultatif : balise « update » du mode consentement

La plupart des CMP envoient également un événement dataLayer une fois que l'utilisateur a enregistré ses préférences, par exemple :

dataLayer.push({
event: “cmp_consent_updated”
});

Si votre CMP n'appelle pas le mode consentement lui-même, vous pouvez :

1. Créer une deuxième balise avec le même modèle : Mode consentement – update (à partir du cookie)

2. Type de commande : update

3. Utiliser les quatre mêmes variables Regex (elles lisent désormais la nouvelle valeur du cookie après le choix de l'utilisateur)

4. Déclencheur : Événement personnalisé → nom de l'événement : cmp_consent_updated

Cela permet de conserver l'ensemble de votre configuration du mode consentement dans GTM et de la piloter à l'aide du cookie CMP.

2.6 Exemple pratique : de la sélection CMP au mode consentement opérationnel

Pour concrétiser cela, imaginez le flux suivant :

• L'utilisateur arrive sur votre site pour la première fois.

  • Pas de cookie cmp_consent.

  • Toutes vos variables Regex reviennent à « denied ».

  • La balise par défaut de Simo se déclenche lors de l'initialisation du consentement avec :

    • ad_storage : denied

    • analytics_storage : denied

    • ad_user_data : denied

    • ad_personalization : denied

• GA4 et Google Ads sont effectivement « gelés » dans un état respectueux de la vie privée.

• L'utilisateur n'accepte que les analyses, il refuse la publicité.

  • Le CMP écrit :

    • cmp_consent=ad_storage=denied|analytics_storage=granted|ad_user_data=denied|ad_personalisation=denied

  • Le CMP envoie cmp_consent_updated.

  • Votre balise de mise à jour du mode de consentement s'exécute et envoie :

    • analytics_storage : granted

    • ad_storage : denied

    • ad_user_data : denied

    • ad_personalization : denied

• GA4 est désormais autorisé à collecter des données, mais Ads reste restreint.

• Lors de la prochaine consultation de la page, le cookie est toujours présent.

  • La balise par défaut lit le cookie via les variables Regex et définit immédiatement les mêmes états.

  • Aucun code d'analyse personnalisé n'est nécessaire et la logique reste lisible dans l'interface utilisateur GTM.

Il ne s'agit là que d'un exemple parmi d'autres, mais il illustre bien comment les cookies propriétaires + les variables Regex + le modèle de Simo s'articulent entre eux.

3. Mise en œuvre du consentement avec localStorage (exemple GTM)

La même philosophie s'applique lorsque votre CMP stocke le consentement dans localStorage plutôt que dans un cookie.
Encore une fois, il ne s'agit là que d'une façon parmi d'autres de procéder ; l'idée est de montrer comment vous pouvez :

• lire localStorage via une simple variable JavaScript

• normaliser les valeurs via des variables Regex / Lookup

• les intégrer dans le même modèle de mode de consentement

3.1 Hypothèses

Pour cet exemple, supposons que :

• Votre CMP stocke le consentement dans localStorage sous la clé cmpConsent.

• La valeur est une chaîne unique, au même format que le cookie :

      ad_storage=granted|analytics_storage=denied|ad_user_data=denied|ad_personalisation=denied

(Si votre CMP utilise JSON, la logique est similaire : il vous suffit d'ajuster l'extraction.)

3.2 Étape 1 – S'assurer que le CMP écrit dans localStorage

Dans l'interface utilisateur / la configuration du CMP :

• Méthode de stockage : localStorage

• Clé : cmpConsent

• Au choix de l'utilisateur :

  • Écrit la chaîne ci-dessus (ou équivalente) dans localStorage.

  • Pousse éventuellement un événement cmp_consent_updated dans le dataLayer (même événement que celui utilisé pour l'exemple du cookie).

3.3 Étape 2 – Lire localStorage dans GTM avec une variable JavaScript

1. Accédez à Variables → Nouveau

2. Type : JavaScript personnalisé

3. Nom : JS – cmpConsent (localStorage)

4. Code :

   function () {
   try {
   var raw = window.localStorage.getItem(“cmpConsent”);
   return raw || “”;
   } catch (e) {
   return “”;
   }
   }

Cette variable renvoie la chaîne complète, par exemple :

ad_storage=granted|analytics_storage=denied|ad_user_data=denied|ad_personalisation=denied

lorsque l'utilisateur a déjà fait un choix.

3.4 Étape 3 – Extraire chaque valeur de consentement via des variables Regex

Vous pouvez maintenant répéter la même approche de modèle Regex, mais en utilisant la variable localStorage comme entrée.

3.4.1 Regex – ad_storage (LS)

1. Variables → Nouveau → Tableau Regex

2. Nom : Regex – ad_storage (LS)

3. Variable d'entrée : {{JS – cmpConsent (localStorage)}}

4. Pour le modèle, remplissez « (^|\|)ad_storage=granted(\||$) »

5. Comme sortie, remplissez le tableau avec « granted »

6. Comme valeur par défaut, mettez « denied »

3.4.2 Regex – analytics_storage (LS)

Même modèle :

1. Nom : Regex – analytics_storage

2. Modèle : (^|\|)analytics_storage=granted(\||$) → Sortie « granted »

3. Valeur par défaut : denied

3.4.3 Regex – ad_user_data (LS) et Regex – ad_personalization (LS)

•  Regex – ad_user_data (LS)

  • Modèle : (^|\|)ad_user_data=granted(\||$) → Sortie « granted »

  • Par défaut : denied

• Regex – ad_personalization (LS)

  • Modèle : (^|\|)ad_personalization=granted(\||$) → Sortie « granted »

  • Par défaut : denied

Une fois encore, chaque variable renvoie désormais exactement « granted » ou « denied ».

3.5 Étape 4 – Configurer la balise Consent Mode pour localStorage

Vous pouvez soit :

• réutiliser le même modèle Simo avec une balise différente, soit

• réutiliser la balise existante et échanger les entrées (si vous testez une méthode à la fois).

Configuration type :

1. Balises → Nouvelle

2. Type : Mode consentement (balises Google)

3. Nom : Mode consentement – default (à partir de localStorage)

Champs :

• Type de commande : default

• Région : all

• ad_storage : {{Regex – ad_storage (LS)}}

• analytics_storage : {{Regex – analytics_storage (LS)}}

• ad_user_data : {{Regex – ad_user_data (LS)}}

• ad_personalization : {{Regex – ad_personalization (LS)}}

Déclencheur : Initialisation du consentement – Toutes les pages

Si le CMP déclenche également cmp_consent_updated lorsque l'utilisateur change d'avis et écrit de nouvelles valeurs localStorage, vous pouvez :

• Créer une balise de mise à jour à l'aide des quatre mêmes variables Regex basées sur LS,

• Déclenchée sur le même événement cmp_consent_updated.

3.6 Exemple pratique : LocalStorage maintient le consentement stable

Exemple de parcours utilisateur :

• Jour 1 – première visite :

  • Pas de cmpConsent dans localStorage.

  • Toutes les variables LS Regex reviennent à « refusé ».

  • La balise par défaut de Simo définit tous les indicateurs du mode de consentement sur « refusé ».

  • GA4 et Ads se comportent en mode « sans consentement ».

• L'utilisateur accepte tout dans le CMP :

  • Le CMP écrit :

  • localStorage.cmpConsent = « ad_storage=granted|analytics_storage=granted|ad_user_data=granted|ad_personalisation=granted »

  • Le CMP envoie cmp_consent_updated.

  • Votre balise de mise à jour envoie une mise à jour du mode de consentement avec les quatre signaux définis sur « accordé ».

• Jour 10 – l'utilisateur efface les cookies, mais pas les données du site :

  • Le cookie CMP (si vous en aviez un) a disparu, mais localStorage.cmpConsent existe toujours.

  • Lors de la prochaine consultation de la page :

    • {{JS – cmpConsent (localStorage)}} renvoie la chaîne stockée.

    • Les variables Regex renvoient « accordé » pour les quatre types de consentement.

    • La balise par défaut du mode consentement définit immédiatement tout sur « accordé ».

L'utilisateur ne voit plus la bannière (si votre CMP considère que le consentement est toujours valide) et votre mesure reste cohérente malgré la suppression des cookies.

Conclusion

Que votre CMP stocke le consentement dans un cookie first-party ou dans localStorage, l'essentiel est de savoir comment ce signal est traduit dans Google Tag Manager et Consent Mode. Les cookies first-party vous fournissent un consentement précoce, visible par le serveur, facile à réutiliser dans GTM et les systèmes back-end, tandis que localStorage privilégie la stabilité de l'expérience utilisateur en survivant à la plupart des nettoyages de cookies.

Les implémentations présentées dans cet article (utilisation des variables de cookies GTM, des variables JavaScript/localStorage, de l'extraction Regex et du modèle Simo Ahava Consent Mode) ne sont qu'une des façons de tout assembler. Elles illustrent l'idée principale : choisir une source unique de vérité pour le consentement, la normaliser dans GTM et laisser Consent Mode l'appliquer de manière cohérente à tous vos tags. Une fois cette base en place, vous pouvez adapter les détails à votre CMP, à vos exigences légales et à l’ensemble de vos outils de mesure.

AUTEUR

Sven Bosschem

| LinkedinCette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Tags:

• Google Consent Mode
• GTM Consent Implementation
• First party Cookie vs Local Storage