Google tag gateway a-t-il besoin du consentement aux cookies ?

Tous les articles

Oui. Google tag gateway change l'endroit d'où se charge votre balise Google, pas le consentement dont elle a besoin. La balise est servie depuis un chemin de votre propre domaine, mais elle lit toujours le Consent Mode : votre bannière, vos valeurs de consentement par défaut et les paramètres de consentement de chaque balise s'appliquent donc toujours. Le seul point à vérifier est l'ordre de chargement : vos valeurs par défaut doivent toujours être définies avant le déclenchement de toute balise Google.

C'est ce dernier point qui mérite votre temps. Le volet juridique de la question a une réponse courte, et le volet pratique tient en une courte liste de vérifications. Les deux suivent.

Que change réellement Google tag gateway ?

Google tag gateway for advertisers charge votre balise Google ou votre conteneur Tag Manager depuis un chemin de votre propre domaine, comme /metrics/, au lieu de googletagmanager.com. Les requêtes de mesure passent elles aussi par ce chemin, et votre CDN ou votre équilibreur de charge les transmet à Google. La page développeurs de Google décrit le dispositif comme l'exécution de votre balise sur votre propre infrastructure propriétaire (first party).

Il y a deux façons de l'activer. Si votre site est derrière Cloudflare, vous pouvez le faire depuis Tag Manager, sous Admin, Google tag gateway, puis autoriser Google dans Cloudflare et choisir les domaines. Sur tout autre CDN, vous routez le chemin de mesure vers l'adresse fps.goog de votre balise, transmettez les en-têtes de localisation du visiteur et remplacez le src de votre extrait de code par le nouveau chemin.

Dans les deux cas, trois choses changent : l'adresse d'où vient le script, l'adresse où partent les requêtes, et qui les transmet. Rien dans cette liste ne touche au consentement.

Servir les balises depuis votre propre domaine change-t-il vos obligations de consentement ?

Non. La règle européenne sur le consentement, à l'article 5(3) de la directive ePrivacy, porte sur le stockage d'informations sur l'appareil du visiteur ou la lecture de ces informations. Elle ne s'intéresse pas au domaine d'où vient le script. Un cookie Google Analytics déposé par une balise chargée depuis /metrics/ reste un cookie qui exige le consentement là où le consentement est requis.

Google dit la même chose dans sa propre page de configuration. Le guide de configuration Cloudflare pour tag gateway prévient que l'activation de la fonctionnalité modifie la façon dont les balises Google se déclenchent, et vous demande d'adopter le Consent Mode et de revoir vos paramètres de consentement si le consentement conditionne déjà vos balises.

Une passerelle n'est donc pas un moyen de contourner une bannière de cookies. Si votre bannière était nécessaire avant le changement, elle l'est aussi après.

Tag gateway peut-il casser votre configuration du consentement ?

Oui, à cause de l'ordre plutôt que de la loi. Le Consent Mode ne fonctionne que si l'état de consentement par défaut est défini avant le déclenchement de toute balise Google, comme le précise le guide de configuration du consentement de Google. Que la passerelle perturbe cet ordre ou non dépend de l'origine de vos valeurs par défaut.

• Votre plateforme de consentement s'exécute dans Tag Manager. Le modèle est placé sur le déclencheur Consent Initialization, qui s'exécute avant tous les autres déclencheurs du conteneur. Le conteneur se charge toujours d'un seul bloc, simplement depuis une autre adresse, donc les valeurs par défaut passent toujours en premier.
• Votre plateforme de consentement est un script distinct dans la page. Ici, l'ordre dépend de la page. Si le CDN sert ou injecte désormais la balise Google plus tôt qu'avant, elle peut s'exécuter avant votre script de consentement. Les outils de Google signalent alors que la valeur par défaut est définie trop tard.

Nous voyons le premier cas sur notre propre site. veloconsent.com charge son conteneur Tag Manager depuis un chemin de son propre domaine via un Cloudflare Worker. C'est notre propre proxy et non la passerelle de Google, mais le principe est le même, et le modèle Velo sur Consent Initialization définit toujours les valeurs refusées par défaut avant l'exécution de toute autre balise.

Si vous êtes dans le second cas, la correction se trouve dans votre page ou votre configuration, pas dans les règles de consentement. N'importe laquelle de ces solutions rétablit l'ordre :

• Chargez le script de consentement au-dessus de l'extrait Google, pour que ses valeurs par défaut s'exécutent en premier.
• Déplacez les valeurs de consentement par défaut dans Tag Manager, sur le déclencheur Consent Initialization.
• Si c'est la configuration automatique de Cloudflare qui a déplacé la balise, utilisez plutôt la configuration manuelle. Vous modifiez vous-même l'extrait de code, vous décidez donc où il se place.

Confirmez-le ensuite dans Tag Assistant, comme dans les vérifications ci-dessous. Notre article sur la question de bloquer ou non les balises Google jusqu'au consentement explique comment le Consent Mode basique et le Consent Mode avancé traitent les balises qui se chargent avant un choix.

Qu'est-ce qui reste identique après le changement ?

Presque tout ce que vous avez configuré pour le consentement est conservé, et la passerelle ne fait rien de tout cela à votre place.

• Les balises Google Analytics, Google Ads et Floodlight lisent le Consent Mode d'elles-mêmes. Les balises Custom HTML et la plupart des modèles de la communauté ne le font pas, donc leurs paramètres de consentement dans Tag Manager comptent toujours.
• Les conversions améliorées dépendent toujours de ad_user_data. Si le visiteur refuse la publicité, ces données ne doivent pas être envoyées, quel que soit le chemin utilisé par la balise.
• Le script de votre plateforme de consentement continue de se charger depuis le même endroit. Avec Velo, c'est l'adresse de Velo, et c'est normal.
• Un conteneur serveur reçoit toujours l'état du consentement avec chaque requête. Les balises serveur de Google le respectent. Les balises serveur des autres fournisseurs ont besoin de leurs propres vérifications du consentement, comme l'explique notre guide sur la transmission du consentement à un conteneur côté serveur.

Notre guide d'aide détaille la configuration dans l'ordre, de la diffusion des balises Google via tag gateway à la transmission du consentement au marquage côté serveur.

Comment vérifier que le consentement fonctionne toujours après le changement ?

Refaites le même test de consentement qu'avant le changement, plus deux vérifications propres à la passerelle. Commencez chaque test dans une nouvelle session de navigateur, sur le site publié.

1. Vérifiez que la passerelle fonctionne correctement

   Ouvrez /metrics/healthy et /metrics/?validate_geo=healthy sur votre domaine, avec votre propre chemin. Les deux doivent renvoyer ok. Si seul le second échoue, les en-têtes de localisation ne sont pas transmis.

2. Confirmez que le nouveau chemin est utilisé

   Dans l'onglet réseau de votre navigateur, la balise Google et ses requêtes doivent passer par votre chemin de mesure. Si elles partent encore vers googletagmanager.com, une ancienne copie de l'extrait de code est toujours dans la page.

3. Vérifiez que les valeurs par défaut passent en premier

   Dans Tag Assistant, la valeur de consentement par défaut doit apparaître avant le déclenchement de toute balise Google. Une valeur par défaut signalée comme tardive signifie que votre script de consentement se charge désormais après la balise.

4. Testez l'acceptation, le refus et un choix partiel

   Vérifiez l'état du consentement sur chaque balise dans les trois cas. Les balises qui ont des paramètres de consentement supplémentaires doivent rester bloquées après un refus.

5. Changez d'avis sur une page suivante

   Rouvrez la bannière, modifiez le choix et vérifiez que la mise à jour atteint les balises sur la page suivante.

Tag gateway récupère-t-il les données que le consentement masque ?

Non. Un visiteur qui refuse est traité de la même façon, quel que soit le domaine depuis lequel la balise se charge. Google présente la passerelle comme un moyen de rendre la mesure plus durable, ce qui concerne le simple chargement du script, par exemple là où un bloqueur l'en empêcherait. C'est un problème distinct du consentement, et la passerelle n'y change rien. Pour comprendre ce qu'un refus fait à vos rapports, commencez par ce qui arrive aux données GA4 quand les utilisateurs refusent les cookies.

Le modèle Tag Manager de Velo est placé sur Consent Initialization : les valeurs par défaut passent donc en premier, quelle que soit l'adresse qui sert votre conteneur. Activer la passerelle devient alors un simple changement de routage, suivi d'une série de tests.