Retour au blog

Consent Mode v2 et la Fin de Google Signals en Juin 2026

Le 15 juin 2026, ad_storage devient le seul contrôle des données publicitaires dans l'écosystème Google. Voici ce que change la fin de Google Signals pour les développeurs — et pourquoi toute cette mécanique est quelque chose qu'une analytique sans cookies n'a jamais eu à construire.

Le 15 juin 2026, Google supprime Google Signals comme contrôle indépendant des données publicitaires. Après cette date, le signal de consentement ad_storage envoyé par votre plateforme de gestion du consentement (CMP) devient l'unique porte qui décide si des données au niveau du visiteur parviennent à Google Ads. Si votre CMP est mal configurée, il n'existe plus de réglage côté serveur dans Analytics pour rattraper l'erreur.

C'est un changement discret mais important. Il fait reposer toute la charge de la justesse du consentement sur une couche JavaScript qui s'exécute dans le navigateur du visiteur, avant toute collecte de données. Il vaut la peine de comprendre exactement ce que fait cette couche, car c'est précisément la complexité qu'une conception sans cookies n'engage jamais.

Ce qu'est réellement Consent Mode v2

Consent Mode v2 est le framework de Google pour indiquer à ses balises si elles ont le droit d'utiliser le stockage. Ce n'est pas une bannière de consentement — c'est le câblage entre votre bannière et les balises de Google. Votre CMP définit quatre signaux :

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
});
  • ad_storage contrôle les cookies publicitaires, les identifiants d'appareil et les données au niveau du visiteur envoyées à Google Ads.
  • analytics_storage régit le cookie Analytics qui attribue un client ID.
  • ad_user_data autorise le hachage de données first-party comme l'e-mail pour Enhanced Conversions.
  • ad_personalization décide si les données Analytics alimentent le ciblage publicitaire personnalisé.

Lorsque le visiteur accepte, votre CMP déclenche un second appel qui met à jour les signaux concernés en granted. Tout ce qui suit dépend de l'arrivée correcte de cette mise à jour.

Basic vs. advanced, et pourquoi advanced existe

Il existe deux modes d'implémentation, et la différence compte juridiquement.

En mode basic, les balises de Google ne se chargent pas du tout tant que le consentement n'est pas accordé. En cas de refus, rien n'est envoyé.

En mode advanced, les balises se chargent immédiatement avec tous les signaux par défaut sur denied, et envoient malgré tout des cookieless pings à Google — une requête sans identifiants, sans client ID et sans état stocké. Google utilise le volume de ces pings, plus le comportement de la minorité qui consent, pour modéliser les conversions qu'il ne peut pas observer directement.

Le mode advanced existe parce que les taux de consentement sont faibles et que les annonceurs veulent retrouver leurs chiffres. Mais un cookieless ping envoyé avant le consentement reste une transmission de données à un tiers, et la lecture technologiquement neutre de l'article 5(3) de la directive ePrivacy par le CEPD n'exonère pas les requêtes simplement parce qu'elles omettent un cookie. Les conversions modélisées exigent aussi un volume minimal de sessions consenties pour produire quoi que ce soit de fiable — les petits sites n'obtiennent donc que du bruit.

Ce que supprime la fin du 15 juin

Jusqu'à présent, Google Signals faisait office de seconde porte. Vous pouviez le laisser désactivé dans Analytics pour restreindre le partage des données publicitaires, quel que soit le rapport du Consent Mode. Ce filet de sécurité a disparu.

Après l'arrêt :

  • Google Ads cesse de lire les réglages côté Analytics et s'appuie exclusivement sur les signaux Consent Mode envoyés par votre CMP.
  • Google Signals est restreint à un usage Analytics uniquement — associer les sessions aux utilisateurs connectés au sein de GA4.
  • Les adresses IP continuent d'être collectées et sont chiffrées avant d'être transmises aux comptes Ads liés, où les réglages du compte de destination prennent le relais.

L'effet pratique : un seul appel gtag('consent', 'update', ...) défaillant — une condition de course, une CMP qui se charge après la première balise, un déploiement qui supprime l'état par défaut — envoie désormais en silence des données que vous comptiez bloquer. Sous le RGPD, c'est un traitement sans base légale, et la suppression du filet de sécurité côté serveur rend plus difficile l'argument selon lequel l'exposition était contenue.

C'est aussi, selon les orientations récentes, une modification substantielle de la façon dont les données publicitaires sont partagées. Pour les sites ayant des visiteurs de l'UE, cela peut déclencher une obligation d'information des utilisateurs — une revue à mener avant l'échéance, et non après.

La complexité qui n'avait jamais besoin d'exister

Prenez du recul et regardez ce qu'exige une configuration conforme de Consent Mode v2 : une CMP, quatre signaux de consentement, des états par défaut, des appels de mise à jour correctement ordonnés par rapport au chargement des balises, une décision entre advanced et basic aux conséquences juridiques, des conversions modélisées qui ne fonctionnent qu'au-dessus d'un seuil de trafic, et désormais un point de défaillance unique sans filet de sécurité.

Toute cette mécanique existe pour continuer à utiliser des identifiants — le client ID, le cookie publicitaire, l'e-mail haché — tout en restant du bon côté du droit du consentement. Retirez les identifiants et tout l'appareil s'effondre en rien.

Un tracker sans cookies n'a pas d'ad_storage à bloquer parce qu'il ne définit aucun stockage publicitaire. Il n'a pas de client ID à refuser parce que l'identité est un hachage à sens unique SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) calculé en mémoire à l'edge et jamais inversé. L'IP brute et le User-Agent ne servent qu'à calculer ce hachage ; D1 stocke le hachage, pas les entrées. Il n'y a aucun signal de consentement susceptible de défaillir parce qu'il n'y a rien à consentir au titre de l'article 5(3) — l'accès à l'appareil du visiteur est strictement nécessaire pour délivrer la page, et le script de moins de 2 Ko envoyé à /collect ne lit aucun stockage.

L'arrêt du 15 juin est un bon moment pour poser une question plus tranchante que « mon Consent Mode est-il correctement configuré ». Demandez-vous pourquoi vous faites tourner une machine à états de consentement pour mesurer des pages vues en premier lieu. Les conversions que Google modélise à partir de cookieless pings sont une estimation de données que vous n'avez jamais eu le droit de collecter. Compter ce qui s'est réellement passé, sans identifiant, a toujours été le système le plus simple.

Sources

Comments

Loading comments…