Mise à jour de Google Consent Mode de juin 2026 : un contrôle unifié pour toutes les données Google Ads

Le 15 juin 2026, Google restructure la façon dont les données publicitaires circulent entre Analytics et Google Ads. Le changement central : ad_storage dans Consent Mode devient le paramètre unique qui détermine quelles données publicitaires sont collectées et transmises à votre compte Ads. Si vous gérez des campagnes de conversion, entretenez des audiences de remarketing ou vous appuyez sur GA4 pour alimenter Ads, cette transition affecte directement votre mesure.

Mise à jour de Google Consent Mode de juin 2026

Ce qui change le 15 juin 2026

L'annonce de Google indique : « à partir du 15 juin 2026, Google Analytics passera à l'utilisation de Consent Mode (au sein de Google Ads) comme contrôle unique des données ». Trois changements distincts sont regroupés dans cette transition.

1. Google Signals perd son autorité sur la collecte des données publicitaires

Jusqu'à présent, deux éléments déterminaient conjointement si Google Ads recevait les cookies publicitaires et les identifiants utilisateurs de votre site : le paramètre Google Signals au sein de Google Analytics, et le paramètre ad_storage dans Consent Mode. Les deux devaient autoriser le suivi pour que le signal complet soit transmis. Ce modèle de double contrôle donnait aux organisations un moyen de restreindre le partage de données publicitaires au niveau d'Analytics sans toucher à leur configuration de Consent Mode.

Après le 15 juin, ce modèle prend fin. ad_storage devient la seule autorité pour toutes les données publicitaires collectées pour les comptes Ads liés. Google Signals est réduit à des finalités exclusivement liées à Analytics, en particulier l'association des sessions aux utilisateurs connectés pour les rapports comportementaux au sein de GA4. Le paramètre gtag allow_google_signals continue de fonctionner pour cet usage de reporting, mais n'a plus aucun poids sur ce qui parvient à Google Ads.

Auparavant, désactiver Google Signals était un moyen relativement simple de limiter le flux de données publicitaires. Après la transition, le seul levier qui compte est ad_storage dans Consent Mode, ce qui place la configuration de la CMP au centre de votre gouvernance des données.

2. Une consolidation de la personnalisation des annonces arrive

Google a annoncé que les contrôles de personnalisation des annonces seront à terme consolidés au sein de Google Ads, ad_personalization dans Consent Mode v2 devenant le paramètre déterminant si les données Analytics peuvent être utilisées pour la publicité personnalisée. Aucune date précise n'a été fixée, et Google a indiqué que le calendrier serait communiqué séparément.

Actuellement, les paramètres de personnalisation sont répartis sur plusieurs niveaux au sein d'Analytics (compte, propriété, lien Ads et événement), ce qui offre aux équipes un contrôle granulaire. Lorsque cette stratification disparaîtra, le signal ad_personalization de votre CMP deviendra le point de décision unique. S'il est refusé, la constitution d'audiences à partir des données Analytics et le remarketing via Google Ads cesseront de fonctionner pour ces utilisateurs, indépendamment de tout réglage côté Analytics.

3. Chiffrement de l'adresse IP avant transmission à Google Ads

Les balises Analytics continueront de collecter les adresses IP, mais Google les chiffrera avant de les transmettre aux comptes Ads liés. Ce qu'il advient de ces données après chiffrement dépend des paramètres de votre compte Google Ads plutôt que de quoi que ce soit au sein d'Analytics. Google a indiqué qu'une documentation supplémentaire sur le traitement des adresses IP en dehors des marchés réglementés sera publiée prochainement.

Qui est le plus concerné

Les organisations ayant désactivé Google Signals comme mesure de confidentialité

Désactiver Google Signals a longtemps été une tactique courante pour limiter la connexion entre les données Analytics et Ads sans modifier Consent Mode. Certaines équipes juridiques et de confidentialité ont fait ce choix précisément pour empêcher que les données des visiteurs ne soient liées aux identités de comptes Google, et ont construit leur documentation de conformité autour de cela.

Après le 15 juin, cette protection disparaît. Si ad_storage est accordé dans votre configuration de CMP, Ads commencera à lier les données publicitaires aux utilisateurs connectés, indépendamment du réglage de Signals. Ce changement de traitement des données s'opère silencieusement du côté de Google ; aucune action de votre part ne le déclenche. Si la désactivation de Signals était inscrite dans votre DPA ou votre cadre de gouvernance des données, auditez dès maintenant vos valeurs par défaut de ad_storage pour confirmer qu'elles reflètent votre intention réelle en matière de confidentialité.

Les éditeurs et annonceurs dans l'EEE, au Royaume-Uni et en Suisse

La mise à jour transforme le résultat du consentement en un choix binaire. Comme l'a décrit l'analyste Simo Ahava : « Soit vous accordez ad_storage et Google utilisera tous les signaux publicitaires disponibles à sa disposition (y compris en liant l'utilisateur à sa connexion Google), soit vous le réglez sur refusé et Google n'accédera à aucun identifiant en dehors de ce qui est disponible dans l'URL (par exemple gclid). »

Avec ad_storage refusé, Ads ne peut travailler qu'avec des paramètres d'URL tels que gclid. La modélisation de conversion dans Consent Mode v2 compense partiellement grâce à une estimation agrégée, mais ce processus nécessite un volume minimal de sessions consenties pour produire des chiffres fiables. Dans des marchés comme l'Allemagne, la France et les Pays-Bas où les taux de refus sont élevés, les comptes de petite taille peuvent ne pas atteindre ce seuil, et les campagnes reposant sur des listes de remarketing ou des enchères au CPA cible en subiront un impact direct.

Pour les régions soumises au RGPD, la bonne configuration consiste à régler ad_storage et analytics_storage par défaut sur denied, mis à jour vers granted uniquement après acceptation active. Cela est également imposé par la politique de consentement des utilisateurs de l'UE, que Google a appliquée plus strictement en 2025 en désactivant la personnalisation pour les comptes non conformes.

Les annonceurs menant des campagnes de remarketing, de suivi des conversions ou d'attribution

Toute campagne dépendant d'une identité au niveau de l'utilisateur est exposée si ad_storage est mal configuré. La modélisation de conversion nécessite un volume suffisant de sessions ayant opté pour le consentement afin d'estimer les résultats des visiteurs non consentants ; en dessous d'un certain seuil, elle devient peu fiable. Les listes de remarketing cessent de croître dès qu'un état refusé est enregistré. Customer Match, Floodlight, l'attribution multi-appareils et les Enhanced Conversions dépendent tous d'identifiants contrôlés par ce paramètre. Une valeur par défaut réglée sur granted alors que denied est légalement requis gonfle artificiellement les données d'audience et crée une exposition en matière de conformité. Des lacunes sur des pages spécifiques telles que les écrans de confirmation et les sous-domaines produisent des baisses inexpliquées dans les conversions signalées.

Les organisations encore sur Consent Mode v1

Google a commencé à appliquer Consent Mode v2 pour le trafic de l'EEE en mars 2024. La version 2 a introduit ad_user_data et ad_personalization en plus des deux paramètres d'origine. Une CMP qui ne définit que ad_storage et analytics_storage fonctionne avec une intégration incomplète. Lorsque la consolidation d'ad_personalization entrera en vigueur, cette lacune deviendra particulièrement lourde de conséquences puisqu'elle régira exclusivement le comportement de personnalisation dans son ensemble.

Ce que contrôle réellement ad_storage

La portée de ce paramètre est plus large que ce que de nombreux annonceurs réalisent.

Lorsque ad_storage est refusé, les balises Google ne lisent ni n'écrivent de cookies publicitaires (y compris _gcl_au), ne collectent ni ne transmettent d'identifiants d'appareil, ne lient pas la session à une identité de compte Google, et ne transmettent pas de données au niveau du visiteur à Ads. La seule information qui parvient à Google Ads dans cet état provient des paramètres d'URL déjà présents sur la page d'atterrissage, comme un gclid ajouté par un clic payant. Rien d'autre ne passe.

Lorsqu'il est accordé, les balises définissent et lisent les cookies publicitaires, collectent les identifiants d'appareil, relient les sessions aux comptes Google connectés, et envoient des signaux de mesure complets à Ads pour l'attribution et la constitution d'audiences. La liaison à la connexion que Google Signals contrôlait auparavant est désormais entièrement gérée ici après le 15 juin.

Le paramètre est initialisé via gtag('consent', 'default', {...}) avant le chargement de toute balise, et mis à jour via gtag('consent', 'update', {...}) une fois que l'utilisateur fait son choix. Pour un guide complet sur la configuration de ces appels, consultez le guide d'intégration gtag. La valeur par défaut établit le comportement pour les visiteurs qui n'ont pas encore interagi avec la bannière ; la mise à jour communique la décision réelle. Les deux doivent s'exécuter sur chaque page, dans le bon ordre, avant l'exécution de toute balise Ads ou Analytics. Un appel manquant, un déclenchement tardif ou une valeur de paramètre erronée signifie que Google agit sur le mauvais signal.

Comment auditer votre configuration avant le 15 juin

Étape 1 : Vérifier l'état par défaut lors d'une visite à froid

Ouvrez votre site dans une fenêtre de navigation privée sans toucher à la bannière de consentement. Utilisez le mode Aperçu de GTM ou Google Tag Assistant pour confirmer quel état de confidentialité est défini avant le déclenchement de toute balise. Pour le trafic soumis au RGPD (EEE, Royaume-Uni, Suisse), ad_storage et analytics_storage doivent être par défaut sur denied. Une valeur par défaut granted avant toute interaction de l'utilisateur constitue un problème de conformité préexistant qui doit être corrigé immédiatement.

Pour les visiteurs américains, la bonne valeur par défaut dépend de la loi étatique applicable. La Californie, sous CCPA, fonctionne en opt-out, donc granted est acceptable tant que vous respectez le signal Global Privacy Control. Les États ayant des exigences d'opt-in nécessitent un point de départ denied. Une CMP configurée avec une valeur par défaut globale unique plutôt que des règles spécifiques par juridiction peut envoyer granted à des utilisateurs qui exigent légalement denied, une lacune qui pèse davantage après le 15 juin.

Étape 2 : Confirmer la présence des quatre paramètres

Vérifiez que les appels par défaut et de mise à jour incluent bien ad_storage, analytics_storage, ad_user_data et ad_personalization. Les intégrations plus anciennes ne transmettent souvent que les deux premiers. Le drapeau ad_user_data contrôle spécifiquement si des données first-party telles que des adresses e-mail peuvent être envoyées à Google pour une correspondance hachée ; sans lui, les Enhanced Conversions ne fonctionneront pas correctement même lorsque ad_storage est accordé.

Étape 3 : Confirmer la couverture sur tous les types de pages

Un signal de confidentialité n'a de sens que s'il se charge avant les balises sur chaque page, pas seulement sur la page d'accueil. Les pages de confirmation de commande ratent fréquemment ce point car elles chargent les balises de conversion Ads via un chemin de code ou un conteneur distinct. Les sous-domaines exécutant leur propre instance GTM ont chacun besoin d'une intégration indépendante. Les pages AMP nécessitent une implémentation dédiée utilisant le composant amp-consent, qui fonctionne différemment de l'approche gtag standard. Les applications monopages nécessitent une attention particulière pour garantir que la préférence enregistrée persiste à travers les changements de route côté client sans réexécuter inutilement la valeur par défaut.

Étape 4 : Tester l'appel de mise à jour lors des première et deuxième visites

L'appel de mise à jour doit se déclencher après que l'utilisateur a interagi avec la bannière, pas avant. L'échec le plus courant est une situation de compétition : GTM a déjà dispatché les balises Ads avant que le callback de la CMP n'arrive, si bien que ces balises s'exécutent selon la valeur par défaut plutôt que le choix réel de l'utilisateur. Cela compte le plus lorsque la valeur par défaut est denied et que l'utilisateur accepte, car ce premier déclenchement de vue de page a déjà manqué la fenêtre.

Tout aussi important : vérifiez que la mise à jour se déclenche également lors des visites de retour, lorsque la préférence enregistrée est relue depuis un cookie. Certaines CMP ne déclenchent le callback que sur la page où le choix initial est effectué et s'attendent à ce que le cookie transmette silencieusement l'état lors des visites suivantes. Si la confirmation est absente de ces pages ultérieures, GTM peut continuer à traiter les sessions comme non consenties. Testez les deux scénarios dans l'Aperçu GTM : une nouvelle visite avec une action d'acceptation, et une visite de retour où le choix précédent doit être respecté automatiquement.

Étape 5 : Confirmer la liaison entre GA4 et le compte Ads

Le nouveau modèle à autorité unique s'applique spécifiquement aux propriétés liées entre GA4 et Google Ads. Vérifiez que ce lien est en place et pointe vers le bon compte sous GA4 Administration > Liens Google Ads. Un lien rompu ou mal associé signifie que les changements du 15 juin pourraient ne pas produire l'effet attendu, et vos données ne refléteront pas correctement le nouveau comportement.

Confirmez également que le marquage automatique est actif dans Google Ads. Le paramètre gclid qu'il ajoute aux URL de destination est le seul signal disponible dans un état refusé, ce qui rend ce réglage plus critique que jamais.

Étape 6 : Examiner les diagnostics et les paramètres du compte Ads

Les diagnostics de balises dans le centre de consentement de GA4 mettent en évidence les lacunes de signal et signalent les balises mal configurées. Accédez à Administration, puis Consentement, puis Diagnostics des balises. L'UniConsent Consent Data Validator offre une vue indépendante en dehors de l'interface GA4. Les deux outils comportent un décalage de 48 à 72 heures, commencez donc l'examen au moins deux semaines à l'avance pour laisser le temps aux corrections d'apparaître dans les données avant la transition.

Du côté Ads, examinez les paramètres au niveau du compte concernant l'anonymisation des adresses IP, la configuration des données clients et la personnalisation. Après le 15 juin, ces paramètres de compte pèseront plus lourd que tout ce qui se trouve dans Analytics, ils doivent donc correspondre à la configuration que vous souhaitez pour chaque marché que vous desservez.

La tendance plus large

Cette transition s'inscrit dans une démarche délibérée de Google visant à réduire la fragmentation des contrôles de confidentialité. Mi-2025, les diagnostics de balises ont été ajoutés au centre de consentement d'Analytics. En juillet 2025, Google a renforcé l'application de la politique de consentement des utilisateurs de l'UE, coupant la personnalisation pour les comptes qui ne transmettaient pas les signaux EEE corrects. Vers décembre 2025, des contrôles cachés de transmission de données sont apparus dans les paramètres de Google Tag. En février 2026, les importations d'attributs de session et d'adresses IP ont été retirées de l'API Google Ads, poussant cette responsabilité vers l'approche de chiffrement qui arrive maintenant en juin.

Le schéma est clair : supprimer les dérogations au niveau des produits, faire transiter les décisions par un nombre réduit de canaux faisant autorité, et rapprocher le contrôle de la confidentialité du lieu où les données sont réellement utilisées. Pour les éditeurs et les annonceurs, cela fait de la CMP l'interface principale entre les choix des utilisateurs et ce que l'ensemble de la suite Google reçoit.

Comment UniConsent vous aide

UniConsent CMP est une plateforme de gestion du consentement certifiée par Google, prenant entièrement en charge les quatre paramètres de Consent Mode v2. Elle transmet automatiquement les choix des utilisateurs à Google Tag Manager, applique des valeurs par défaut spécifiques à chaque juridiction pour l'EEE, le Royaume-Uni, la Suisse et les États américains, et maintient des signaux cohérents sur le web, AMP et les environnements mobiles. Les taux d'acceptation, la santé des signaux et les pistes d'audit de conformité sont tous accessibles depuis un tableau de bord unique.

L'échéance du 15 juin approche. Si vous n'avez pas encore examiné votre configuration ad_storage et confirmé que votre intégration de Consent Mode v2 est complète, c'est le moment de le faire.

À propos d'UniConsent

UniConsent CMP est une plateforme de gestion du consentement reconnue mondialement et certifiée par Google, au service des principaux éditeurs et de dizaines de millions d'utilisateurs chaque jour. UniConsent aide les entreprises à rester conformes au RGPD, aux lois américaines de confidentialité des États et aux exigences de politique de Google.

Contactez-nous pour en savoir plus : hello@uniconsent.com