GA4 et Google Ads : la consolidation du 15 juin 2026

Le 15 juin 2026, Google rebranche ad_storage en interrupteur binaire pour GA4 et Google Ads. Plus de levier intermédiaire, plus de paramètre planqué dans l'admin GA, plus de Google Signals qui décide silencieusement si vos audiences cross-device se peuplent. Une seule manette, un seul état, deux issues possibles : granted ou denied. Ce n'est pas un bug, c'est une feature. Et pour les équipes qui ont passé deux ans à câbler du Consent Mode v2 dans Tag Manager, ça change le diagnostic d'attribution mesurable du jour au lendemain.

La page support officielle de Google le formule en une phrase technique : à partir du 15 juin 2026, Google Analytics va basculer sur Consent Mode (au sein de Google Ads) comme contrôle unique pour les données. Source : support.google.com/analytics/answer/17016975. Avant cette date, Google Signals jouait deux rôles dans la même case à cocher : il pilotait la collecte des cookies et identifiants Google Ads ET il autorisait l'association des données GA4 avec les utilisateurs connectés pour le reporting comportemental.

Si vous avez déjà câblé un Tag Manager, vous voyez le problème. Une seule variable de configuration GA4 contrôlait deux pipelines de données distincts. Un junior tape sur le toggle pour activer le reporting démographique. Personne ne réalise qu'on vient aussi d'ouvrir les vannes côté Ads. Deux fonctionnalités, un seul levier : c'est exactement le genre de couplage qu'un game designer arracherait à la première itération.

Après le 15 juin, le paramètre Google Signals dans l'admin GA et l'API Google Signals ne contrôleront plus QUE l'association des données GA4 avec les utilisateurs connectés pour le reporting comportemental. Toute la partie collecte Ads passe sous gouvernance ad_storage, et ad_storage vit dans Consent Mode, dans Google Ads, hors GA4. Le pipeline est découpé proprement. C'est mieux. Mais ça implique de re-câbler.

Simo Ahava (co-fondateur Simmer, référence technique sur Consent Mode v2) le résume mieux que la doc Google : "soit vous accordez ad_storage et Google utilisera tous les signaux Ads disponibles, y compris l'association de l'utilisateur avec sa connexion Google, soit vous le mettez sur denied et Google n'accèdera à aucun identifiant en dehors de ce qui est disponible dans l'URL (par exemple gclid)." Citation publiée sur LinkedIn, reprise par ppc.land.

Lisez bien : binaire. granted ou denied. Aucun état intermédiaire. Aucune granularité par feature. Si vous voulez du remarketing GA4 sans transmission de l'utilisateur connecté, désolé, ce n'est plus possible. C'est l'inverse aussi : si vous voulez le reporting démographique GA4 sans alimenter les audiences Ads, perdu, c'était déjà compliqué, ça devient impossible côté collecte.

Pour les devs dans la salle, c'est une simplification brutale du modèle de données. Un seul flag, deux branches. La logique métier remonte d'un cran : c'est désormais à la CMP et à votre bannière de gérer le détail, plus à Google. Le seul vrai pouvoir granulaire qui vous reste, c'est le moment où vous demandez le consentement et la manière dont vous formulez l'option. Spoiler : la majorité des CMP actuelles ne distinguent même pas ad_storage de analytics_storage côté UX.

Petit recap pour ceux qui auraient sauté l'étape de mars 2024. Depuis le 6 mars 2024, le déploiement de Consent Mode v2 est obligatoire pour utiliser les produits publicitaires Google dans l'EEE ou au Royaume-Uni (obligation DMA). Source : cookiebot.com. Cette version a ajouté deux paramètres aux deux existants :

• ad_storage (cookies et IDs publicitaires)
• analytics_storage (cookies et IDs analytics)
• ad_user_data (envoi de données utilisateur à Google pour la pub)
• ad_personalization (consentement au remarketing)

Simo Ahava souligne un détail technique critique sur son blog : ad_storage et analytics_storage ont un impact fonctionnel direct sur les tags côté site (quels identifiants partent dans le payload). ad_user_data et ad_personalization, eux, sont des instructions downstream vers les services Google sur le traitement des données. Ils ne modifient pas le comportement du tag sur la page. Pour le résumer dans le langage d'un dev : ad_storage et analytics_storage sont des flags compile-time pour le tag, les deux autres sont des hints runtime pour Google.

Le 15 juin 2026 cible le premier groupe. Pour le second groupe, Google a déjà annoncé qu'une consolidation similaire arriverait plus tard en 2026 : ad_personalization deviendra le seul paramètre contrôlant si les données sont utilisées pour la personnalisation côté compte Ads. Date non encore publiée. À surveiller.

Si vous pensiez que cette histoire était théorique, rappel utile. Le 21 juillet 2025, Google a commencé à désactiver le tracking de conversions et la création d'audiences pour les comptes non conformes à Consent Mode v2. Source : dinmo.com. Ce n'était pas une menace, c'était l'enforcement réel.

La bascule du 15 juin 2026 vient s'empiler par-dessus. Si vous êtes conforme Consent Mode v2 depuis l'été 2025, le travail est en grande partie déjà fait : ad_storage est correctement signalé par votre CMP, vos defaults sont posés avant l'évaluation des tags, votre dataLayer transmet bien les états via les paramètres URL gcs et gcd. Si vous êtes restés en Consent Mode v1, ou si vous avez bricolé sans CMP certifiée Google, le 15 juin va faire mal. Pas parce que Google sanctionne, mais parce que vos audiences vont fondre, et vos modèles smart bidding vont s'agiter dans le vide.

Le diagnostic technique est posé par dataslayer.ai : les audiences de remarketing construites dans GA4 continuent de fonctionner, mais leur composition se réduit aux seuls utilisateurs ayant explicitement accordé ad_storage. La fallback cross-device via Google Signals disparaît. Concrètement, si votre site convertit en majorité des utilisateurs anonymes (taux de consentement ad_storage faible), vos audiences GA4 vont rétrécir de manière brutale entre le 14 et le 16 juin.

Le conversion tracking Google Ads natif (le tag de conversion classique posé directement sur la page de remerciement) n'est PAS affecté. Le changement cible uniquement la collecte "via le tag GA4". C'est une nuance qui sauve : si vous avez les deux pipelines en parallèle (Ads conversion tag natif + import GA4), vos conversions natives continuent de remonter, vos imports GA4 se réduisent au consentement disponible.

J'ajouterais une nuance technique au passage : le tracking conversion natif tient si et seulement si votre tag de conversion est posé proprement, déclenché par un événement non discutable, et avec un dataLayer cohérent. Si vous avez câblé vos conversions Ads via GTM en pointant sur un événement GA4 rerouté en interne, vous êtes mécaniquement dans le pipeline GA4. C'est le piège classique du tracking "tout passe par GTM". Allez voir, vraiment. Pour les bases du câblage propre, la lecture du guide d'installation Google Tag Manager reste utile, même en 2026.

Krista Seiden, ancienne Product Manager Google Analytics entre 2016 et 2019 (et anciennement Analytics Evangelist chez Google), tire la sonnette d'alarme sur ppc.land. Sa phrase mérite d'être lue lentement :

"Cette manoeuvre ressemble moins à une simplification qu'à Google qui repositionne les leviers là où ils lui profitent le plus, c'est-à-dire son activité Ads."

Et plus loin, sur la dimension réglementaire :

"La responsabilité RGPD est portée par le data controller, pas par Google. Les annonceurs ont aujourd'hui moins de contrôle granulaire sur ce qui circule où, tout en conservant l'intégralité de la responsabilité légale."

Le point juridique est lourd. Côté annonceur, vous perdez un cran de finesse dans les paramètres techniques (Google Signals avait deux fonctions, vous en perdez une côté Ads), mais vous restez le data controller au sens du RGPD. C'est vous qui définissez les finalités, c'est vous qui devez démontrer la base légale, c'est vous qui répondez en cas de contrôle CNIL. La simplification opérationnelle de Google ne transfère aucun risque juridique.

Et pour ceux qui ont oublié l'historique français, rappelons les deux dates à ne pas confondre. La CNIL a mis en demeure un gestionnaire de site utilisant Google Analytics le 10 février 2022, pour transferts insuffisamment encadrés vers les États-Unis. Puis le 7 juin 2022, la CNIL a considéré que la modification des paramètres seuls ne constituait pas une mesure suffisante. Réhabilitation : juillet 2023, quand la Commission européenne a déclaré les États-Unis "pays adéquat" via le Data Privacy Framework. GA4 redevient légalement utilisable en France à cette date. Honnêtement, je ne sais pas si le Data Privacy Framework tiendra dans le temps face à un Schrems III. Mais aujourd'hui, juin 2026, GA4 est légal en France si vous êtes conforme Consent Mode v2.

Trois changements arrivent en cascade, signalés sur la même page support Google :

1. ad_storage devient le seul paramètre de gouvernance pour la collecte des cookies publicitaires et des identifiants (15 juin 2026, confirmé)
2. ad_personalization deviendra le seul paramètre contrôlant si les données sont utilisées pour la personnalisation côté Ads (date non annoncée, plus tard en 2026)
3. Les adresses IP collectées automatiquement seront chiffrées et transmises au compte Google Ads lié, sous gouvernance des paramètres Google Ads (date non annoncée, plus tard en 2026)

Le troisième point mérite un encart. L'IP, jusqu'ici masquée par défaut côté GA4, va circuler chiffrée vers Google Ads. C'est une bonne nouvelle pour l'attribution cross-device si vous êtes conforme. C'est une vigilance supplémentaire dans votre registre RGPD : vous transmettez désormais (même chiffrée) une donnée personnelle vers un compte Ads tiers à votre property GA4. La cohérence des bases légales doit être revue.

Pour les flux offline, deux changements parallèles tombent le 15 juin. L'enhanced conversions for web et l'enhanced conversions for leads fusionnent en un toggle unique on/off, avec déclenchement multi-sources simultané. Source : support.google.com/google-ads/answer/16884284. Et l'API Google Ads n'accepte plus les nouveaux intégrateurs d'offline conversion imports (y compris enhanced conversions for leads) à partir de cette même date : migration obligatoire vers Data Manager API, avec erreur CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE renvoyée aux nouveaux entrants. Source : ppc.land.

ALM Corp documente un gain médian observé de 5 à 15 % de conversions reportées après implémentation des enhanced conversions, et un gain médian de 10 % en plus pour les annonceurs combinant first-party data et click identifiers en mesure offline. Si vous traînez à brancher proprement votre first-party data, c'est le moment.

Pour les utilisateurs qui refusent ad_storage, Google modélise partiellement les conversions à partir des utilisateurs consentants. C'est une feature utile mais elle a des seuils stricts que peu d'annonceurs vérifient avant de constater des trous dans leur reporting :

• Minimum 700 clics publicitaires sur 7 jours par pays et par domaine
• Minimum 7 jours pleins de collecte de données
• Taux de consentement raisonnable (typiquement supérieur à 20 %)

Source : groas.ai et ppcmastery.com. Sous ces seuils, pas de modeled conversions. Vos conversions reportées chutent du delta exact de la part non-consentante de votre trafic. Et ce delta peut être brutal : selon le profil de votre site et la qualité de votre bannière, le taux de consentement ad_storage peut être très différent, et le seuil de 20 % mentionné par Google n'est pas garanti pour tout le monde.

Si vous êtes sur un domaine de niche avec moins de 700 clics Ads sur 7 jours par pays, vous voyez le problème : vous ne déclenchez jamais la modélisation, et chaque utilisateur en denied est une conversion potentielle invisible. La taille du compte devient un facteur de qualité de mesure. C'est une inégalité structurelle dans le système que peu d'annonceurs réalisent. Sur ce point, j'hésite encore sur la meilleure stratégie pour les petits comptes : optimiser la CMP au maximum pour pousser le taux de consentement, ou accepter le delta et ajuster les bids manuellement. Les deux ont leurs partisans, aucun n'est élégant.

ALM Corp et dataslayer.ai documentent les écueils classiques d'implémentation, et ils sont nombreux : defaults Consent Mode chargés trop tard (après évaluation des tags), confusion storage consent versus usage consent, CMP chargée de façon fragmentée avec race conditions sur le gtag('consent', ...), confiance aveugle dans le dashboard sans tester en vrai. Consent Mode est un système distribué entre votre CMP, vos tags, et les serveurs Google. Chaque maillon peut casser.

La checklist qui marche :

1. Vérifier que vos defaults Consent Mode v2 sont posés AVANT l'évaluation des tags (script CMP en <head>, pas en <body>)
2. Tester que la mise à jour du consentement persiste correctement sur les pages suivantes (problème classique : la CMP ne stocke pas l'état entre les routes côté Next.js)
3. Configurer des regions spécifiques pour EEE, UK, Suisse dans votre CMP
4. Établir une baseline métrique le 10 juin (audiences GA4, conversions reportées, taille des listes de remarketing) pour pouvoir mesurer l'impact du 15 juin
5. Documenter dans votre registre RGPD le changement de gouvernance Google Signals → ad_storage au 15 juin 2026

Le point 4 est sous-estimé. Sans baseline, vous allez vous demander en juillet si la chute des audiences vient du changement Google, d'un changement de votre CMP, ou d'un mouvement saisonnier. Avec baseline, vous le savez. Les équipes data parlent souvent de cette feedback loop comme du polish nécessaire avant un patch majeur.

Pour situer l'enjeu : selon W3Techs au 18 mai 2026, Google Analytics représente 78,2 % du marché des outils d'analytics (et 43,1 % de tous les sites web). Matomo : 2,7 %. Plausible : 0,4 %. Le 15 juin 2026 n'est pas un changement de niche, c'est un mouvement qui touche mécaniquement 4 sites sur 10 dans le monde. Si vous opérez du SEO + Ads en France, vous êtes statistiquement dedans.

C'est aussi pour ça que comparer GA4 et Matomo reste une question pertinente en 2026 : pour 2,7 % de part de marché, Matomo a l'argument de la souveraineté et une histoire de privacy plus claire. Pour 78,2 %, GA4 a l'écosystème Ads collé. La consolidation du 15 juin renforce cet écosystème Ads. C'est un trade-off à faire en connaissance de cause, pas un choix par défaut.

Pour comprendre le contexte, un retour rapide sur le calendrier Privacy Sandbox. Le 22 avril 2025, Chrome a maintenu le support des cookies tiers. Pas de suppression, pas de nouvelle invite de consentement standalone. Source : Privacy Sandbox Blog. Le 17 octobre 2025, Google a annoncé l'arrêt de 10 technologies Privacy Sandbox, dont Topics API, Attribution Reporting, Protected Audience. Source : la même page Privacy Sandbox. FLoC, déjà abandonné depuis 2022, était remplacé par Topics API, elle-même retirée en octobre 2025.

Ce que ça veut dire pour le 15 juin 2026 : Google a abandonné le plan B (Privacy Sandbox), a maintenu le plan A (cookies tiers + Consent Mode), et a simplifié le tableau de bord. La bascule du 15 juin est cohérente avec ce repli. Plus de levier intermédiaire entre l'annonceur et la collecte Ads, plus de complexité opaque côté admin GA. La direction est claire : moins de finesse, plus de volume, et la responsabilité légale reste là où elle est, c'est-à-dire chez vous.

Si la dépendance aux cookies tiers vous gêne, le travail à mener reste connu : structurer une stratégie first-party data et server-side tracking, poser un audit RGPD analytics propre, et reprendre les bases du reporting GA4 pour le SEO pour ne pas perdre le fil métier dans le bruit technique.

Trois actions concrètes, sans fioritures.

D'abord, ouvrez votre admin GA4 et notez explicitement, par écrit, l'état actuel du toggle Google Signals. Vous saurez exactement ce que vous perdez côté reporting comportemental (pas Ads) le 15 juin. Beaucoup d'équipes vont confondre les deux disparitions et se chercher des fantômes.

Ensuite, exigez de votre CMP un test en preview mode (GTM ou équivalent) qui vérifie : (a) defaults posés avant tags, (b) update du consentement persistant entre pages, (c) ad_storage correctement transmis dans les paramètres URL gcs et gcd. Si la CMP n'a pas un mode debug propre, c'est probablement le moment d'en changer.

Enfin, baseline le 10 juin sur trois métriques : taille des audiences GA4 actives, conversions reportées sur 7 jours par campagne, et taux de consentement ad_storage. Le 22 juin, vous saurez précisément ce que la bascule a coûté ou non. Sans cette mesure, le débat sera bloqué entre votre direction marketing et votre data team pendant des semaines.

À vous de jouer.

• Updates to Google Analytics Data Controls (support officiel Google)
• Google Signals : définition (support Google)
• Consent Mode v2 : référence technique (Simo Ahava)
• Google strips Analytics of ad data authority (ppc.land + quote Simo Ahava)
• Ex-Google analyst Krista Seiden on Signals change (ppc.land)
• GA4 Google Ads data controls June 15 2026 (dataslayer.ai)
• GA4 / Google Ads consent controls split June 2026 (ALM Corp)
• Google blocks new offline conversion imports via Ads API (ppc.land)
• Enhanced conversions settings update (support Google Ads)
• Consent Mode deadline : ads & privacy compliance (Cookiebot)
• Consent Mode v2 enforcement July 2025 (dinmo.com)
• Update on Privacy Sandbox technologies (Google)
• Google Ads conversion tracking setup 2026 (groas.ai)
• Analytics market share May 2026 (W3Techs)