Le Consent Mode n’est ni un bandeau ni une attestation de conformité. Dans le dispositif de mesure Google Ads, il communique aux balises les choix recueillis par une CMP ou une solution interne. Avant de comparer les modes, séparez donc trois sujets : la politique Google et le droit applicable, puis le comportement technique.
ad_storage, analytics_storage, ad_user_data et ad_personalization. Chacun prend notamment l’état granted ou denied. D’autres types existent, dont functionality_storage, personalization_storage et security_storage.Ce que Google attend des signaux de consentement
La politique Google sur le consentement des utilisateurs de l’Union européenne couvre l’Espace économique européen, le Royaume-Uni et la Suisse. Pour les annonceurs, Google demande en plus des signaux vérifiables pour le trafic de l’EEE, transmis par Consent Mode ou par le Transparency and Consent Framework. Ce sont des conditions d’usage de produits Google. Elles ne créent pas, à elles seules, une obligation légale autonome.
Le droit suit une autre logique. En France, la CNIL rappelle que les traceurs non strictement nécessaires exigent en principe un consentement libre, spécifique, éclairé et univoque. Le refus doit être aussi simple que l’acceptation, et le retrait rester accessible. Le choix entre mise en œuvre de base et avancée doit donc être évalué selon les finalités, les données envoyées et les textes applicables. Une documentation produit ne remplace pas cet examen juridique.
Sur le plan technique, le bandeau recueille un choix, puis l’implémentation le communique aux balises et leur fait respecter cet état. Si une baisse de conversions mesurées suit un changement de CMP, de balises ou de ciblage géographique, le consentement devient un contrôle prioritaire. Sans changement de ce type, il reste une hypothèse parmi d’autres, pas un diagnostic automatique.
Mode de base ou avancé : ce qui change vraiment
La différence ne se limite pas au refus final. Elle commence au chargement de la page : quelles balises sont chargées, quel état par défaut est posé, quand la mise à jour intervient et ce que la balise fait ensuite. Les libellés anglais basic et advanced désignent ici les mises en œuvre de base et avancée documentées par Google.
| Point de contrôle | Mise en œuvre de base | Mise en œuvre avancée |
|---|---|---|
| Ouverture de la page | Les balises Google restent bloquées jusqu’à l’interaction avec le bandeau. | Les balises Google se chargent après définition des états par défaut adaptés à la région et à la politique de l’entreprise. |
| Après un accord | Les balises peuvent se charger et adapter leur mesure aux types de consentement accordés. | Une mise à jour communique les états accordés ; les balises ajustent leur comportement. |
| Après un refus | Les balises Google restent bloquées et aucune donnée n’est envoyée par elles. | Les balises compatibles peuvent envoyer des mesures sans cookie avec les états refusés. |
| Modélisation Ads | Google décrit un modèle général lorsque les mesures sans cookie sont bloquées. | Les mesures sans cookie peuvent permettre une calibration propre à l’annonceur si les contrôles de qualité sont remplis. |
| Conclusion juridique | Aucun mode n’est déclaré conforme par nature. Le choix dépend des finalités, des données transmises, du message présenté et du droit applicable. | |
En mode de base, aucune donnée n’est envoyée par les balises Google avant l’interaction. Après un refus, elles restent bloquées, y compris pour transmettre le statut de consentement. Après un accord, elles se chargent selon la configuration et les paramètres accordés. Cela ne garantit ni le dépôt de chaque cookie ni l’enregistrement de chaque conversion : d’autres réglages peuvent encore intervenir.
En mode avancé, les balises se chargent avec des états par défaut définis avant les commandes de mesure. Lorsqu’un type de consentement est refusé, les balises compatibles n’écrivent pas le stockage correspondant. Elles peuvent néanmoins envoyer des mesures sans cookie. Google indique que ces requêtes peuvent contenir l’état de consentement, l’activité concernée et des informations contextuelles ou fonctionnelles.
Ces mesures ne servent pas à suivre individuellement une personne entre des sites ou des applications. Google précise aussi qu’elles ne construisent ni profil utilisateur ni liste de remarketing. Leur rôle est de fournir une matière de modélisation. En mode avancé, cette matière peut alimenter une calibration propre à l’annonceur. Elle ne garantit ni l’éligibilité du modèle ni une hausse chiffrée des conversions rapportées.
Le mode de base peut conserver une modélisation générale dans Google Ads. Le mode avancé ouvre la possibilité d’un modèle plus détaillé, sous réserve d’une implémentation correcte, d’un volume suffisant et du niveau de confiance exigé par Google. « Avancé » ne signifie donc ni « mesure complète » ni « résultat plus juste dans tous les comptes ».
Le choix porte d’abord sur les données que votre organisation accepte d’envoyer après un refus. Il peut combiner une CMP, du code gtag.js, un modèle Google Tag Manager ou une solution interne. Ce flux doit ensuite correspondre à la politique de l’entreprise et à l’avis juridique obtenu. Une option cochée par défaut dans un outil ne constitue pas cet arbitrage.
Mesure, export et remarketing : quatre paramètres distincts
Les quatre paramètres ne forment pas un interrupteur unique. Chacun gouverne un usage précis, et plusieurs états peuvent se combiner sur la même visite. C’est la raison pour laquelle un diagnostic limité à « cookies acceptés » ou « cookies refusés » manque le mécanisme réel.
ad_storagecontrôle le stockage lié à la publicité, notamment les cookies et identifiants publicitaires pris en charge par les balises Google.analytics_storagecontrôle le stockage lié à l’analyse. Avec un état refusé en mode avancé, GA4 peut recevoir des événements sans identifiant persistant et les utiliser selon ses règles de mesure et de modélisation.ad_user_datadéfinit le consentement à l’envoi de données utilisateur à Google à des fins publicitaires. Un refus désactive les usages concernés et limite notamment les exports de conversions fondés sur un identifiant de clic.ad_personalizationdéfinit le consentement à la publicité personnalisée. Google exige quead_user_dataetad_personalizationsoient accordés pour activer la personnalisation dans ses plates-formes publicitaires.
Le remarketing dépend donc des paramètres publicitaires et du stockage, tandis que la modélisation s’appuie sur des mesures qui ne créent pas de listes. Une conversion peut être modélisée sans qu’une personne refusante entre dans une audience. À l’inverse, une liaison de comptes ne corrige pas un état absent ou transmis trop tard.
Quels critères pour voir de la modélisation ?
Il n’existe pas un seuil unique qui « active le mode avancé ». Il faut distinguer la modélisation des conversions Google Ads, la modélisation comportementale GA4 et l’affichage d’un impact dans les diagnostics. Ces systèmes n’estiment pas les mêmes objets et n’appliquent pas les mêmes conditions.
Autre difficulté : deux pages d’aide Google Ads consultées le 17 juillet 2026 publient des formulations différentes sur le volume. La page dédiée à la modélisation mentionne 700 clics sur sept jours. Une autre page indique 100 clics par jour pour le mode de base, sans ce minimum pour le mode avancé. Tant que Google maintient les deux formulations, aucun de ces chiffres ne doit devenir une règle universelle de conception.
Conversions modélisées dans Google Ads
La page « À propos de la modélisation » demande une implémentation correcte de Consent Mode ou du TCF, puis affiche un seuil de 700 clics publicitaires sur sept jours pour chaque combinaison pays-domaine. Après les contrôles de qualité, Google entraîne le modèle et intègre progressivement les conversions modélisées dans la colonne « Conversions » et les rapports qui l’utilisent.
La page « Améliorer la modélisation » affiche, elle, 100 clics par jour et précise que cette condition concerne la mise en œuvre de base, pas l’avancée. Le bon contrôle n’est donc pas un calcul isolé dans un tableur. Vérifiez les diagnostics Google Ads, la date de début de modélisation et la présence effective des conversions modélisées. Même lorsque les critères externes sont remplis, Google conserve un seuil de confiance interne.
Modélisation comportementale dans GA4
GA4 impose une mise en œuvre avancée sur toutes les pages ou tous les écrans, avec chargement des balises dans tous les cas. La propriété doit collecter au moins 1 000 événements par jour avec analytics_storage=denied pendant sept jours. Elle doit aussi recevoir au moins 1 000 utilisateurs quotidiens avec analytics_storage=granted pendant sept des vingt-huit jours précédents.
Ces critères sont nécessaires, mais pas suffisants. Google tient aussi compte du rapport entre nouveaux et anciens utilisateurs, ainsi que du rapport utilisateurs-sessions. L’identité de reporting « Combinée » doit être sélectionnée pour afficher les données modélisées. Celles-ci ne s’appliquent pas partout : audiences, rétention, certaines explorations, métriques prédictives et export BigQuery restent notamment hors périmètre.
| Système | Conditions visibles | Ce que vous contrôlez |
|---|---|---|
| Conversions Google Ads | Consent Mode ou TCF, volume documenté de façon divergente, puis seuil de confiance du modèle. | Diagnostics de conversion, date de début de modélisation et présence dans les colonnes de conversion. |
| Comportement GA4 | Mode avancé partout, 1 000 événements refusés par jour et 1 000 utilisateurs accordés par jour selon les fenêtres documentées. | Éligibilité de la propriété, identité « Combinée », icône de qualité des données et rapports compatibles. |
| Impact affiché | Au moins sept jours complets d’implémentation, volume suffisant et impact supérieur au seuil d’affichage. | Rapport d’impact par combinaison pays-domaine, lorsqu’il est disponible. |
Une absence de chiffre modélisé ne prouve donc ni une panne ni l’inutilité du mode avancé. Elle peut venir du volume, de la qualité d’implémentation, du rapport consulté ou du seuil de confiance. À l’inverse, un chiffre modélisé reste une estimation intégrée au rapport. Pour comparer des périodes, identifiez d’abord la date d’éligibilité et séparez autant que possible données observées et données modélisées.
Ce qui a changé dans les contrôles de données en 2026
ad_storage ne gouverne pas tout l’usage publicitaire. Il contrôle le stockage publicitaire. ad_user_data encadre l’envoi de données utilisateur pour la publicité, tandis que ad_personalization encadre la publicité personnalisée. Un état accordé sur l’un ne remplace pas un refus sur l’autre.
Google a annoncé qu’à partir du 15 juin 2026, Consent Mode dans Google Ads devient le contrôle de référence pour la collecte et l’usage des données publicitaires issues de Google Analytics. Le réglage Google Signals dans Analytics doit alors se concentrer sur l’association avec les informations des utilisateurs connectés pour le reporting comportemental. Google prévoit aussi d’autres changements de personnalisation publicitaire plus tard en 2026, sans avoir publié toutes les dates exactes au jour de cette vérification.
La liaison GA4-Google Ads reste une étape séparée. Elle permet le flux de données entre les produits, puis la création de conversions Google Ads à partir d’événements clés et l’utilisation d’audiences. Elle ne transmet pas elle-même les états de consentement. Si ad_user_data est refusé, Google limite notamment l’export de conversions indexé sur les identifiants de clic, même lorsque les comptes sont correctement liés.
Bandeau visible, états incohérents : l’anomalie silencieuse
Une anomalie fréquente en audit consiste à trouver un bandeau fonctionnel en apparence, mais un état par défaut absent, défini trop tard ou jamais actualisé. Ce n’est pas un troisième mode. C’est une implémentation incomplète dont les effets dépendent de la balise et du moment où elle a lu l’état.
Les causes ne sont pas équivalentes. Une valeur par défaut tardive peut laisser une balise agir avant le refus. Une mise à jour absente conserve le défaut après un accord. Un paramètre v2 manquant limite certains usages publicitaires. Une liaison GA4-Ads absente bloque les échanges concernés, sans arrêter la collecte GA4 ni annuler tous les calculs d’attribution.
Les symptômes varient aussi : balise bloquée, état non défini, conversion non exportée, audience qui ne s’alimente plus, modélisation indisponible ou rapport privé d’une partie de ses données observées. Une baisse globale n’est jamais garantie. Le diagnostic doit relier chaque anomalie à la donnée ou à la fonctionnalité réellement affectée.
La bonne question n’est donc pas « le bandeau est-il présent ? » mais « que lit chaque balise avant et après le choix ? ». Selon l’architecture, la réponse se trouve dans la CMP, le code gtag.js, un modèle Google Tag Manager ou une solution interne. Dans GTM, le déclencheur « Initialisation du consentement » sert aux balises qui définissent ou actualisent ces états.
Une CMP du programme partenaire Google facilite l’intégration, sans garantir la conformité à la politique Google ni au droit applicable. Google précise que le résultat dépend du message présenté à l’utilisateur et de la configuration réelle. Il faut encore vérifier les finalités, le mappage, l’ordre d’exécution, les régions, la persistance du choix et les contrôles propres à chaque balise.
Les règles produit évoluent. Cette page s’appuie sur les documents officiels vérifiés le 17 juillet 2026, notamment la mise à jour Analytics du 15 juin et les deux seuils Ads encore divergents. Pour une mise en ligne, conservez cette date dans l’audit et faites valider séparément le volet juridique. Un réglage Google n’est jamais une consultation de conformité.
- Quatre paramètres sont centraux pour Google Ads et GA4 en v2, mais ils n’épuisent pas tous les types de consentement disponibles.
- Le mode de base bloque les balises après un refus. Le mode avancé peut envoyer des mesures sans cookie et permettre une calibration propre à l’annonceur.
- Les mesures sans cookie ne créent ni profil individuel ni liste de remarketing. Modélisation, export de conversions et personnalisation restent des mécanismes distincts.
- La conformité juridique ne se déduit pas du mode choisi. Elle dépend des finalités, du message, des données envoyées et du droit applicable.
Comment vérifier l’implémentation en conditions réelles ?
Les diagnostics Google Ads, GA4 et CMP donnent du contexte, mais ne suffisent pas. Tag Assistant est l’outil officiel de débogage des balises Google, qu’elles soient installées avec gtag.js ou Google Tag Manager. Le panneau Réseau du navigateur complète le contrôle en montrant les requêtes réellement émises.
Ce que le réseau du navigateur permet de voir
Le panneau Réseau affiche les URL, paramètres, en-têtes et charges utiles accessibles au navigateur. Les domaines et chemins varient selon les produits ; recherchez les requêtes des balises Google concernées, notamment les chemins de collecte, plutôt qu’un filtre générique supposé universel. Les bloqueurs, la prévention du suivi et le routage côté serveur peuvent modifier ce que vous observez.
Testez l’état initial puis la mise à jour dans des sessions propres : une pour l’accord, une pour le refus. Réinitialisez les préférences et simulez les régions configurées. Le paramètre gcs transmet ad_storage et analytics_storage. gcd encode des informations plus détaillées et peut être envoyé même sans Consent Mode actif. Cet encodage évolue ; son décodage manuel reste un indice, pas le contrôle principal.
La procédure officielle dans Tag Assistant
Tag Assistant présente les appels de consentement, les états obtenus et le comportement des balises dans une interface prise en charge par Google. Il évite de transformer un paramètre réseau encodé en verdict définitif. La procédure doit couvrir le défaut, l’actualisation et les balises, pas seulement l’existence d’une requête.
- Démarrez une session neuve. Ouvrez Tag Assistant, saisissez l’URL et utilisez une géolocalisation simulée si des valeurs régionales sont définies.
- Contrôlez le premier événement « Consent ». Dans « API Call » ou « Output / Consent », vérifiez les quatre paramètres et la colonne « On-page Default » avant toute commande de mesure.
- Effectuez un seul choix. Acceptez ou refusez, puis contrôlez le dernier événement « Consent » et la colonne « On-page Update ». La mise à jour doit intervenir sur la page avant toute transition.
- Ouvrez l’onglet des balises. Vérifiez celles qui ont été déclenchées ou bloquées et les contrôles de consentement qu’elles appliquent.
- Recommencez séparément. Utilisez une nouvelle session pour l’autre choix, testez la persistance sur la page suivante et répétez pour chaque région utile.
L’état par défaut doit être défini avant tout code qui utilise ou actualise le consentement. Avec gtag.js, il précède les commandes config et event. Avec un modèle GTM, les API de consentement du modèle sont préférables à un appel gtag dans une balise HTML personnalisée. La balise Google peut ensuite se charger avec un état refusé dans la mise en œuvre avancée.
Une mise à jour s’applique aux événements futurs. Elle ne transforme pas une requête déjà envoyée et doit être déclenchée avant le changement de page. La comparaison Tag Assistant, configuration CMP et diagnostics produit constitue un contrôle reproductible. Elle permet de qualifier l’implémentation sans prétendre démontrer, à elle seule, la conformité juridique.
La décision à documenter
Documentez trois décisions séparées. Premièrement, quelles finalités et quels états votre politique autorise-t-elle selon la région ? Deuxièmement, le site transmet-il le défaut puis la mise à jour au bon moment ? Troisièmement, quels résultats sont observés, modélisés ou exclus dans Google Ads et GA4 ? Une réponse floue sur l’un de ces points ne rend pas toute la mesure inconnue, mais empêche d’en quantifier proprement la couverture.
Le verdict utile n’est pas « avancé est meilleur ». C’est un dossier vérifiable : choix juridique validé, architecture identifiée, parcours accord et refus testés, états régionaux contrôlés, date de début de modélisation relevée et limites de rapport connues. Lors d’un audit, je diagnostique ces écarts et leur effet probable. La décision de conformité reste, elle, du ressort de votre conseil.
Questions fréquentes
Consent Mode v2 est-il une obligation légale ?
Quelle différence la version v2 ajoute-t-elle aux paramètres existants ?
ad_user_data et ad_personalization aux paramètres ad_storage et analytics_storage déjà mis en avant. Le premier encadre l’envoi de données utilisateur à Google pour la publicité ; le second encadre la publicité personnalisée. Un état refusé peut donc limiter la mesure publicitaire, certains exports ou le remarketing selon le paramètre concerné.Une CMP certifiée Google garantit-elle la conformité ?
gtag.js ou GTM.Peut-on passer du mode de base au mode avancé après coup ?
gtag.js ou de votre modèle GTM. Fixez une date, testez les états par défaut et les mises à jour, puis surveillez les diagnostics. GA4 indique que les données modélisées ne sont disponibles qu’à partir de la date d’éligibilité ; un changement futur ne recrée donc pas automatiquement les périodes antérieures.Quand faut-il définir puis actualiser les états de consentement ?
Consent Mode v2 agit-il sur les conversions créées depuis GA4 ?
ad_user_data est refusé, Google limite notamment l’export de conversions fondé sur les identifiants de clic. L’effet diffère donc d’une balise Ads directe.Sources officielles et primaires vérifiées le 17 juillet 2026 : Google documente les mises en œuvre de base et avancée, les défauts, mises à jour et régions, la référence des paramètres, la mise à jour pour le trafic EEE et la vérification des signaux EEE. Ses références couvrent aussi la modélisation Ads et seuil de 700 clics, la modélisation et seuil de 100 clics, la modélisation comportementale GA4, les paramètres HTTP de consentement, le contrôle avec Tag Assistant et la liaison GA4 et Google Ads. Elles incluent enfin le programme CMP et limites et les contrôles Analytics au 15 juin 2026 ; la CNIL documente les règles françaises sur les traceurs.
