Le Consent Mode est la couche qui dit aux balises Google ce que votre visiteur a accepté. Sans lui, vous avez deux états possibles : les balises tournent, ou elles ne tournent pas. Avec lui, elles adaptent leur comportement au choix réel de la personne, finalité par finalité.

C'est un mécanisme de transmission de signal, pas un mécanisme de conformité. Il ne recueille pas le consentement : il transporte une décision prise ailleurs, par votre bandeau. C'est pour cette raison qu'il ne remplace pas une plateforme de gestion du consentement, il en dépend.

La distinction compte, parce que beaucoup d'équipes marketing installent le Consent Mode en pensant régler la question juridique. Ce que le Consent Mode règle, c'est la perte de données de mesure. Ce que la CNIL regarde, c'est ce qui est déposé dans le navigateur avant le choix, et cela se joue dans le bandeau, comme nous l'expliquons dans le guide du bandeau cookies conforme à la CNIL.

Les deux sujets se rejoignent sur un point précis, et c'est là que cet article devient utile : selon le mode que vous choisissez, les balises Google se chargent avant ou après le choix de l'utilisateur. Cette décision technique a des conséquences que la doctrine française rend impossibles à ignorer.

Avant d'entrer dans la technique, il faut séparer quatre choses que les réunions mélangent en permanence. La confusion coûte du temps et fait acheter la mauvaise solution.

La CMP, ou plateforme de gestion du consentement, est l'outil qui demande, qui recueille et qui enregistre le choix. C'est la couche qui parle à l'utilisateur et qui garde la trace.

Le gestionnaire de balises, Google Tag Manager par exemple, est l'outil qui décide quelles balises se déclenchent et quand. C'est un chef d'orchestre, pas un mécanisme de consentement. Il peut appliquer un consentement, il ne le recueille pas.

Le Consent Mode est le protocole qui communique l'état du consentement aux balises Google. C'est une couche de transmission, avec quatre paramètres.

Le TCF, Transparency and Consent Framework de l'IAB, est un cadre technique de standard ouvert qui permet aux sites, aux annonceurs et aux agences d'obtenir, d'enregistrer et de mettre à jour le consentement. C'est la définition que Google en donne dans sa documentation.

Ces quatre éléments ne se substituent pas les uns aux autres. Une entreprise peut avoir un gestionnaire de balises parfaitement configuré et aucun consentement valable. Elle peut avoir le Consent Mode en place et aucune preuve à produire. Elle peut avoir une CMP et ne transmettre aucun signal aux balises.

La question utile en réunion n'est donc pas « avons-nous le Consent Mode », c'est « qui recueille, qui bloque, qui transmet, et qui garde la trace ». Nous y revenons plus loin, parce que la réponse est presque toujours organisationnelle avant d'être technique.

Le Consent Mode v2 repose sur quatre paramètres. Deux existaient déjà dans la première version, deux sont apparus avec la v2. Voici les noms techniques exacts et ce que chacun contrôle, selon la référence du gtag.js publiée par Google.

• ad_storage : autorise le stockage lié à la publicité, cookies sur le web ou identifiants d'appareil dans les applications.
• analytics_storage : autorise le stockage lié à la mesure, par exemple la durée de visite.
• ad_user_data : autorise l'envoi de données utilisateur à Google à des fins publicitaires. Nouveau dans la v2.
• ad_personalization : autorise la publicité personnalisée, donc le remarketing. Nouveau dans la v2.

La logique de cette répartition mérite d'être comprise, parce qu'elle n'est pas intuitive. Les deux premiers paramètres portent sur le stockage dans le terminal. Les deux nouveaux portent sur l'usage des données côté Google. Ce sont deux questions différentes, et un utilisateur peut légitimement accepter l'une en refusant l'autre.

Un cinquième paramètre apparaît dans la même référence technique et concerne directement les plateformes de consentement : wait_for_update, qui définit un délai en millisecondes pendant lequel les balises attendent une mise à jour du consentement.

Ce réglage est celui qui provoque le plus d'incidents silencieux. Trop court, et les balises agissent sur l'état par défaut avant que le choix de l'utilisateur ne soit remonté, ce qui produit des mesures fausses. Trop long, et vous retardez le chargement pour tout le monde.

Si ad_personalization et l'ancien paramètre allow_ad_personalization_signals se contredisent, Google désactive la personnalisation. C'est le réglage le plus restrictif qui gagne.

C'est une bonne nouvelle sur le plan du risque, et un piège sur le plan du diagnostic. Une équipe qui ne comprend pas pourquoi le remarketing ne fonctionne plus après une migration cherche souvent du côté du bandeau, alors que la réponse est dans une ligne de configuration héritée.

Trois paramètres circulent dans les requêtes et servent au diagnostic. gcs transmet les états de ad_storage et analytics_storage. gcd encode l'information détaillée des types de consentement, et Google précise qu'il est toujours envoyé, que le Consent Mode soit activé ou non. dma_cps encode le consentement pour les services Google.

Savoir que ces paramètres existent change la manière de vérifier une installation. Vous n'avez pas besoin d'un outil payant pour savoir si le signal part correctement : il est lisible dans l'onglet réseau du navigateur.

Les noms et les descriptions de tous ces paramètres figurent dans la référence du gtag.js publiée par Google, et le détail du comportement des deux modes dans sa documentation sur le Consent Mode. Ce sont les deux seules pages à garder ouvertes pendant une mise en place, parce que le vocabulaire y est fixé et que les guides de marché le déforment.

Google propose deux implémentations du Consent Mode, et le choix entre les deux n'est pas un réglage technique mineur. C'est la décision structurante de tout le sujet, parce qu'elle détermine si des données quittent le navigateur avant que l'utilisateur ait choisi.

Dans le mode basic, les balises Google ne se chargent pas tant que l'utilisateur n'a pas interagi avec le bandeau. La formulation de Google est explicite : cette configuration ne transmet aucune donnée à Google avant l'interaction de l'utilisateur.

Si l'utilisateur accepte, les balises se chargent, transmettent les états de consentement et la mesure reprend normalement. S'il refuse, rien n'est envoyé. Zéro signal.

Dans le mode advanced, les balises se chargent immédiatement à l'ouverture du site, avec un état par défaut fixé à denied. Tant que le consentement est refusé, elles envoient de la mesure sans cookies, ce que Google appelle des cookieless pings.

La documentation de Google est claire sur ce comportement : quand les visiteurs refusent le consentement, les balises ne stockent pas de cookies, mais elles communiquent l'état du consentement et l'activité de l'utilisateur par ces requêtes sans cookies.

Si l'utilisateur accepte ensuite, la mesure complète avec cookies reprend.

Le basic est plus protecteur, parce que rien ne sort du navigateur avant le choix, et il paie ce choix par une modélisation de moindre qualité. L'advanced envoie des signaux sans cookies même en cas de refus, et alimente pour cette raison un modèle plus précis.

Voici l'analyse que nous devons vous livrer honnêtement, en distinguant ce qui est un fait de ce qui est une lecture.

Le fait : en mode advanced, la balise se charge et communique avec les serveurs de Google avant tout consentement. Google affirme qu'en cas de refus, aucun cookie n'est stocké.

La lecture : en France, l'article 82 de la loi Informatique et Libertés régit l'accès ou l'inscription d'informations dans le terminal de l'utilisateur. Un chargement de script qui n'écrit rien n'est pas automatiquement une opération soumise à consentement, mais l'affirmation vient de Google, pas de la CNIL.

Nous n'avons trouvé aucune prise de position publique de la CNIL sur le mode advanced. En l'absence de doctrine explicite, la position prudente consiste à traiter cette affirmation comme une affirmation de l'éditeur, et non comme une validation de l'autorité. Une entreprise qui veut minimiser le risque juridique choisit le basic. Une entreprise qui privilégie la qualité de la mesure choisit l'advanced en connaissant ce point ouvert.

C'est une décision d'arbitrage, et elle mérite d'être documentée comme telle, avec la personne qui l'a prise et la date. C'est exactement le genre de décision qu'un contrôle demande à voir motivée.

C'est l'argument commercial principal du mode advanced, et il faut le décrire précisément, sans les chiffres que le marché invente.

La documentation de Google distingue deux niveaux. En mode basic, la modélisation repose sur un modèle général, décrit comme moins détaillé. En mode advanced, elle repose sur un modèle spécifique à l'annonceur, décrit comme plus détaillé.

La raison de cet écart découle directement de la section précédente. En advanced, Google reçoit des requêtes sans cookies même des utilisateurs qui ont refusé, et ce volume de signal permet d'entraîner un modèle propre au compte. En basic, aucun signal n'arrive des utilisateurs qui refusent ni de ceux qui n'ont pas encore choisi, donc seul un modèle générique est possible.

Un avertissement utile, parce que ce point circule beaucoup : nous n'avons trouvé aucun seuil quantitatif d'éligibilité à la modélisation dans la documentation de Google. Les volumes minimaux que citent certains guides, du type nombre de clics par pays sur une fenêtre de sept jours, ne sont pas confirmés par la source. Ne construisez pas un business case sur ces chiffres.

Ici, la précision compte plus qu'ailleurs, parce que la version qui circule dans les guides de marché est plus catégorique que ce que les sources officielles permettent d'affirmer.

Depuis mars 2024, les utilisateurs résidant dans l'Espace économique européen disposent de nouveaux choix sur la manière dont leurs données peuvent être partagées entre certains services Google. C'est ce que Google déclare sur sa page consacrée à la confidentialité de ses services, en rattachant ce changement au Digital Markets Act.

Une précision de calendrier, parce qu'elle circule de travers. Le DMA est entré en vigueur le 1er novembre 2022 et est applicable depuis le 2 mai 2023. Ce qui s'est joué en mars 2024, c'est l'échéance de conformité des contrôleurs d'accès désignés, que la Commission a datée du 7 mars 2024. Mars 2024 n'est donc pas la date d'entrée en application du règlement.

L'obligation qui pèse sur les annonceurs, elle, découle de la EU user consent policy de Google. Cette politique exige d'obtenir un consentement juridiquement valable pour l'utilisation de cookies ou d'autres formes de stockage local là où la loi l'exige, et pour la collecte, le partage et l'utilisation de données personnelles aux fins de personnalisation des annonces.

Son champ géographique est plus large que l'Union européenne : elle s'applique aux utilisateurs situés dans l'Espace économique européen, au Royaume-Uni et en Suisse. Elle exige aussi de conserver les enregistrements des consentements donnés et de fournir aux utilisateurs des instructions claires pour révoquer leur consentement. Le texte est court et vaut la lecture directe, sur la page de la politique de consentement de Google.

Enfin, Google avertit que sans les nouveaux paramètres, la personnalisation publicitaire et certaines fonctions de mesure cessent d'être disponibles là où sa politique de consentement l'exige.

Nous avons vérifié quatre pages officielles de Google et aucune n'indique aujourd'hui une date limite du type « obligatoire depuis le tel mars 2024 ». Il est plausible que Google ait retiré la date parce qu'elle est passée, mais nous ne l'avons pas lue, donc nous ne la certifions pas.

La formulation exacte que nous retenons est donc celle-ci : depuis mars 2024, dans le contexte du Digital Markets Act, Google exige des signaux de consentement explicites pour le trafic de l'Espace économique européen, et l'obligation pour les annonceurs découle de sa EU user consent policy. Sans ad_user_data et ad_personalization, les fonctions de personnalisation et de mesure ne sont plus disponibles.

Si vous voyez un guide qui cite une date au jour près comme échéance réglementaire, demandez la source. Cette précision n'est pas une coquetterie : elle évite de justifier un projet interne sur un fait qui ne tient pas.

Ce point surprend beaucoup d'équipes techniques, et il figure noir sur blanc dans la documentation de Google.

Google recommande d'implémenter un seul des deux mécanismes, le TCF ou le Consent Mode, et pas les deux ensemble. La raison invoquée est de garder le marquage aussi léger que possible et d'éviter les interactions non voulues.

Une précision de version, parce qu'elle a une échéance. La version en vigueur du framework de l'IAB est le TCF v2.3, et l'IAB Europe a fixé au 28 février 2026 la date limite d'adoption : les TC strings créées sans le segment des vendeurs divulgués sont considérées comme invalides à partir du 1er mars 2026. Un guide qui parle encore de v2.0 décrit un état du framework qui n'existe plus.

Et quand les deux sont présents avec des signaux contradictoires, Google applique « l'union la plus conservatrice des signaux en faveur de la confidentialité ». Autrement dit, si le TCF refuse une finalité que le Consent Mode autorise, c'est la restriction qui gagne.

Cette règle explique un symptôme courant : une installation où la mesure semble sous-évaluée sans raison, parce que deux couches de consentement se superposent et que la plus restrictive s'impose silencieusement.

Il existe bien une exigence de CMP certifiée par Google, mais elle concerne les éditeurs qui diffusent de la publicité via AdSense ou Ad Manager, pas les annonceurs qui implémentent le Consent Mode. Ce sont deux politiques distinctes, avec deux périmètres distincts.

Confondre les deux conduit à des cahiers des charges impossibles à satisfaire, ou à des achats de solution surdimensionnés. Si votre sujet est le Consent Mode côté annonceur, la certification pour éditeurs n'est pas votre critère de choix.

Sur le TCF lui-même, Google le définit comme un cadre technique de standard ouvert qui permet aux sites, aux annonceurs et aux agences d'obtenir, d'enregistrer et de mettre à jour le consentement des utilisateurs. Sa documentation associe les finalités TCF aux paramètres du Consent Mode, ce qui confirme que le TCF fonctionne comme véhicule de communication du consentement.

L'ordre des opérations évite la majorité des incidents. Voici la séquence que nous recommandons.

1. Décidez du mode avant de toucher au code. Basic ou advanced est un arbitrage entre risque juridique et qualité de mesure. Écrivez la décision, avec la date et la personne qui l'a prise.
2. Cartographiez les balises existantes. Vous ne pouvez pas piloter un consentement sur des balises que vous ne connaissez pas. Cette étape révèle presque toujours des balises ajoutées par une agence et oubliées.
3. Fixez l'état par défaut à denied pour les quatre paramètres, avant tout chargement de balise. C'est le point de départ, quel que soit le mode retenu.
4. Reliez le bandeau à la mise à jour du consentement. Le choix de l'utilisateur doit déclencher une mise à jour des quatre paramètres, pas seulement des deux anciens.
5. Réglez wait_for_update en connaissance de cause. Trop court, les balises agissent sur l'état par défaut. Trop long, vous ralentissez tout le monde.
6. Vérifiez dans l'onglet réseau. Cherchez gcs et gcd dans les requêtes, avant et après le choix. C'est le contrôle le plus fiable et il ne coûte rien.
7. Vérifiez le retrait. Retirez le consentement, rechargez, et confirmez que l'état transmis a bien changé.
8. Documentez la configuration. Le mode retenu, les valeurs par défaut, le délai d'attente, et la date. C'est ce qui permet à la personne suivante de comprendre l'installation.

L'étape 2 est celle que tout le monde saute et celle qui coûte le plus cher, parce qu'une balise inconnue échappe par construction au consentement.

Il y a dans la EU user consent policy de Google une exigence que presque personne ne relève, et qui pèse pourtant autant que les paramètres techniques : conserver les enregistrements des consentements donnés par les utilisateurs finaux.

Cette exigence rejoint une obligation du RGPD, celle de pouvoir démontrer le consentement. Les deux disent la même chose sous deux angles différents. Google vous demande de garder la trace parce que sa politique l'impose. Le règlement vous la demande parce que sans elle vous ne pouvez pas prouver que le traitement était licite.

Or le Consent Mode ne conserve rien. Il transporte un état, il ne l'archive pas. Une installation qui repose uniquement sur le Consent Mode transmet correctement le signal et se retrouve incapable de répondre à la question la plus simple d'un contrôle : que ce visiteur a-t-il accepté, quand, et sur quelle version du bandeau.

La même politique exige aussi de fournir aux utilisateurs des instructions claires pour révoquer leur consentement. C'est un point d'interface, pas un point de balise, et il tombe donc lui aussi du côté du bandeau.

Ce que cela implique concrètement pour votre architecture : la couche qui recueille doit journaliser, avec un horodatage, la version affichée et les finalités concernées. La couche qui transmet, elle, se contente de refléter l'état courant. Confondre les deux rôles produit une installation techniquement propre et juridiquement nue.

Voici la partie où nous sortons du fait vérifié pour vous livrer une analyse, et nous le signalons explicitement parce que c'est notre lecture, pas une règle.

La plupart des entreprises mesurent le trafic, les conversions et le coût d'acquisition. Très peu mesurent la seule chose qui relie la conformité à la performance : la proportion du consentement recueilli qui arrive intacte jusqu'à la couche d'activation.

Cette proportion se dégrade sans bruit. Un consentement peut être parfaitement recueilli et ne jamais atteindre Google, parce que le délai d'attente est trop court, parce qu'une balise a été ajoutée hors du gestionnaire, parce qu'une migration a oublié deux paramètres, ou parce que deux couches de consentement se superposent et que la plus restrictive s'impose.

Dans tous ces cas, les rapports montrent une baisse de performance et l'équipe marketing conclut à un problème d'audience ou de créations. Le problème est en amont, dans la transmission du signal.

Le test qui révèle l'écart tient en trois chiffres. Combien de visiteurs ont accepté la mesure selon votre bandeau. Combien de sessions consenties votre outil de mesure enregistre. Et l'écart entre les deux, exprimé en pourcentage. Si personne dans l'entreprise ne peut produire ces trois chiffres, l'écart existe et n'est pas piloté.

C'est aussi l'argument le plus solide en interne pour financer une installation propre. Un projet de conformité se défend mal quand il est présenté comme une contrainte. Il se défend bien quand il montre combien de consentements déjà obtenus sont perdus en route.

Le Consent Mode ne concerne pas que le web. Les descriptions officielles des paramètres le disent explicitement : ad_storage porte sur le stockage lié à la publicité, cookies sur le web ou identifiants d'appareil dans les applications, et analytics_storage sur le stockage lié à la mesure, cookies sur le web ou identifiants d'application.

La conséquence pratique est souvent ignorée dans les organisations où le site et l'application sont gérés par deux équipes différentes. Le bandeau du site peut être irréprochable pendant que l'application collecte sans mécanisme équivalent, ou avec un mécanisme qui ne remonte pas les mêmes finalités.

Deux vérifications suffisent à situer le risque. La première : l'application demande-t-elle un consentement pour les finalités publicitaires, avec la même granularité que le site. La seconde : ce choix est-il transmis aux quatre paramètres, ou seulement aux deux anciens.

Un point de vigilance supplémentaire, sur lequel nous renvoyons à la source plutôt qu'à notre résumé : la CNIL a modifié sa recommandation cookies en décembre 2025 pour traiter du consentement multi-terminaux. Si votre utilisateur consent sur le téléphone et retrouve le service sur l'ordinateur, la question de savoir dans quelles conditions ce choix se propage a une réponse récente, et c'est le texte qu'il faut lire.

Trois attentes reviennent régulièrement dans les briefs et méritent d'être corrigées avant qu'un projet ne s'appuie dessus.

Il ne compense pas un bandeau non conforme. Si des traceurs sont déposés avant le choix, le Consent Mode ne change rien à ce constat. Le dépôt a eu lieu, et c'est ce que le contrôle observe.

Il ne compense pas l'absence de blocage technique. Un état de consentement transmis à des balises Google ne dit rien des balises qui ne sont pas de Google. Un pixel publicitaire tiers installé en dehors du gestionnaire de balises continue de fonctionner, indifférent au signal.

Il ne compense pas un refus. La modélisation estime des conversions à partir de signaux disponibles, elle ne reconstitue pas des données que l'utilisateur a refusé de fournir. Présenter la modélisation comme un moyen de retrouver les données perdues est une promesse que la documentation ne soutient pas.

La bonne manière de situer l'outil est celle-ci : le Consent Mode réduit la perte de mesure causée par un refus légitime, et il donne à vos rapports une lecture honnête de ce que vos visiteurs ont accepté. C'est utile, et c'est déjà beaucoup. Ce n'est pas une couche de conformité.

Les défauts que nous rencontrons le plus souvent en audit d'installations françaises.

Ne mettre à jour que les deux anciens paramètres. Une migration de la v1 vers la v2 qui oublie ad_user_data et ad_personalization produit une installation qui a l'air de fonctionner et qui perd les fonctions de personnalisation.

Choisir le mode advanced sans le documenter. Le mode advanced est défendable, mais il implique un chargement avant le choix. Sans décision écrite, personne ne saura expliquer l'arbitrage en cas de question.

Superposer TCF et Consent Mode. Google recommande explicitement de n'en garder qu'un, et applique la lecture la plus restrictive en cas de conflit.

Régler l'état par défaut sur granted. C'est l'inverse de ce qui est attendu, et cela transforme le Consent Mode en décoration.

Traiter le Consent Mode comme une réponse à la CNIL. Le Consent Mode transporte un signal. Ce que la CNIL contrôle, c'est ce qui est déposé avant le choix, et c'est le bandeau qui en répond, pas le signal.

Enfin, ne jamais vérifier après une mise en production. Un déploiement de site, une nouvelle balise, un changement de gestionnaire de balises suffisent à casser la chaîne sans qu'aucune alerte ne se déclenche.

La confusion la plus tenace sur ce sujet vient d'un problème d'organisation, pas de technique. Trois couches différentes sont en jeu, et dans beaucoup d'entreprises françaises elles n'ont pas de propriétaire clairement désigné.

La première couche est le recueil. C'est le bandeau : ce qu'il affiche, dans quel ordre, avec quelle parité entre accepter et refuser, et ce qu'il journalise. Cette couche répond de l'article 82 de la loi Informatique et Libertés et de la doctrine de la CNIL. Son propriétaire naturel est celui qui répond de la conformité, souvent le délégué à la protection des données ou le juridique.

La deuxième couche est le blocage. C'est ce qui empêche techniquement une balise de s'exécuter avant le choix. Elle ne se voit pas dans l'interface, elle se voit dans l'onglet réseau du navigateur. Son propriétaire naturel est la technique, et c'est la couche la plus souvent laissée sans propriétaire, parce qu'elle tombe entre le juridique qui ne la lit pas et le marketing qui ne la configure pas.

La troisième couche est la transmission. C'est le Consent Mode : refléter l'état du consentement vers les balises Google. Son propriétaire naturel est celui qui pilote la mesure et l'acquisition.

Quand ces trois couches ont trois propriétaires nommés, les incidents se détectent en quelques jours. Quand elles n'en ont aucun, elles se découvrent lors d'un contrôle ou d'une chute de performance inexpliquée.

Le test le plus simple pour savoir où vous en êtes : demandez à trois personnes différentes qui est responsable du blocage technique. Si vous obtenez trois réponses différentes, ou trois hésitations, la couche est orpheline.

Si vous évaluez une solution, ces questions séparent rapidement les outils qui pilotent des outils qui affichent. Elles portent toutes sur des points vérifiables, pas sur des promesses.

1. Le blocage se fait avant ou après le chargement des balises ? Une solution qui charge puis demande aux balises de ne rien faire n'offre pas le même niveau de protection qu'une solution qui empêche le chargement.
2. Les quatre paramètres du Consent Mode v2 sont-ils gérés, ou seulement les deux anciens ? Demandez à voir la configuration, pas une fiche produit.
3. Comment wait_for_update est-il réglé, et pourquoi cette valeur ? Un prestataire qui ne sait pas répondre n'a pas réglé ce paramètre en connaissance de cause.
4. Que contient l'enregistrement d'un consentement ? La date, la version du bandeau affichée, les finalités concernées. Si la réponse est « on stocke le choix », c'est insuffisant pour démontrer quoi que ce soit.
5. Comment sort-on la preuve d'un consentement donné ? Demandez une démonstration sur un cas réel. C'est la question qui départage le plus.
6. Les balises tierces qui ne sont pas de Google sont-elles couvertes ? Le Consent Mode ne concerne que Google. Le reste dépend du blocage.
7. Que se passe-t-il quand un visiteur retire son consentement ? L'effet doit être immédiat sur les traceurs, pas seulement sur l'affichage.
8. Comment la solution suit-elle l'évolution de la doctrine ? La recommandation de la CNIL a été modifiée en décembre 2025. Une solution figée en 2020 a pris du retard.

La question 5 est celle que nous conseillons de poser en premier. Elle ne se répond pas avec un argumentaire, elle se répond avec un écran.

Une installation conforme le jour de sa mise en production ne le reste pas d'elle-même. Les sites évoluent, les agences ajoutent des balises, les gestionnaires de balises changent de main. Voici le rythme minimal que nous recommandons.

Chaque trimestre, quatre vérifications suffisent, et elles prennent une demi-heure.

• La liste des balises. Comparez les balises actives avec la liste de la dernière vérification. Toute nouveauté doit avoir un propriétaire et une ligne au registre des traitements.
• Le comportement avant le choix. Navigation privée, outils de développement, page d'accueil, aucune interaction. Rien de soumis à consentement ne doit apparaître.
• Le signal transmis. Les valeurs de gcs et gcd avant et après le choix, puis après un retrait. Trois états, trois valeurs différentes.
• La production de preuve. Prenez un consentement récent et demandez sa trace complète. Si la manipulation prend plus de dix minutes, elle ne sera pas faisable sous la pression d'un contrôle.

À cela s'ajoute une vérification annuelle, de nature différente : relire la doctrine. Les textes de la CNIL sur les cookies ont bougé en 2020, puis en 2022 sur les cookie walls, puis en décembre 2025 sur le consentement multi-terminaux. Une configuration jamais relue vieillit même quand elle était juste.

Notez les résultats quelque part de stable, avec la date. Cela paraît bureaucratique et cela vous sauve deux fois : le jour où quelqu'un demande depuis quand une balise est là, et le jour où il faut démontrer une démarche de conformité continue plutôt qu'un effort ponctuel.

Non. Le Consent Mode transporte une décision de consentement vers les balises Google, mais il ne recueille pas cette décision et n'en conserve pas la preuve. Le recueil, l'affichage des finalités, le blocage technique avant le choix et l'enregistrement horodaté relèvent de la plateforme de gestion du consentement. Le Consent Mode dépend d'elle, il ne la remplace pas.

ad_storage pour le stockage lié à la publicité, analytics_storage pour le stockage lié à la mesure, ad_user_data pour l'envoi de données utilisateur à Google à des fins publicitaires, et ad_personalization pour la publicité personnalisée. Les deux premiers existaient dans la v1, les deux derniers sont apparus avec la v2 et sont ceux qu'une migration incomplète oublie.

Cela dépend de l'arbitrage que vous assumez. Le basic ne transmet rien à Google avant l'interaction de l'utilisateur, ce qui est la position la plus prudente au regard de l'article 82 de la loi Informatique et Libertés, et il donne une modélisation moins détaillée. L'advanced charge les balises immédiatement et envoie des requêtes sans cookies même en cas de refus, ce qui améliore la modélisation. Nous n'avons trouvé aucune prise de position de la CNIL sur le mode advanced.

L'obligation qui pèse sur les annonceurs découle de la EU user consent policy de Google, qui s'applique aux utilisateurs de l'Espace économique européen, du Royaume-Uni et de la Suisse. Sans les paramètres ad_user_data et ad_personalization, les fonctions de personnalisation publicitaire et certaines fonctions de mesure ne sont plus disponibles. Aucune des pages officielles que nous avons consultées n'indique aujourd'hui une date limite précise.

Ouvrez les outils de développement du navigateur sur l'onglet réseau, avant de charger la page, et cherchez les paramètres gcs et gcd dans les requêtes vers les domaines Google. Comparez leur valeur avant et après votre choix dans le bandeau, puis refaites le test en retirant le consentement. Si la valeur ne change pas, la mise à jour du consentement n'est pas reliée au bandeau.

• Bandeau cookies conforme : ce que la CNIL exige vraiment
• Qu'est-ce qu'une CMP et pourquoi en avoir une
• Portail des droits RGPD : répondre aux demandes DSAR

---

Le Consent Mode bien réglé fait une chose précieuse : il rend visible, dans vos rapports, la différence entre ce que vos visiteurs acceptent et ce que vous mesurez. C'est un indicateur de conformité autant qu'un indicateur marketing.

Vous voulez vérifier que le signal qui part de votre site correspond au choix de vos visiteurs ?

Réservez un échange avec notre équipe