Web Bot Auth, Google Tag Gateway et sGTM : ce que chaque brique protège vraiment dans GA4

Web Bot Auth ne récupérera pas un seul événement bloqué dans votre GA4. Je préfère le dire d’emblée, parce que l’idée circule qu’il ferait partie d’une stack de contournement des bloqueurs. Ce n’est pas le cas.

Ce protocole n’est pas une invention de Google. Il s’appuie sur les HTTP Message Signatures (RFC 9421) pour permettre à un client automatisé de signer ses requêtes sortantes. C’est un document de groupe de travail à l’IETF depuis septembre. Google le teste sur son propre trafic : un sous-ensemble des requêtes de Google-Agent est authentifié sous l’identité agent.bot.goog. L’implémentation reste expérimentale. Il s’agit donc de savoir qui frappe à votre porte. Il ne s’agit pas de savoir si le navigateur de votre visiteur a laissé passer le tag.

Trois problèmes distincts, trois briques distinctes

Les requêtes bloquées : Google Tag Gateway

Le Tag Gateway est une fonction gratuite qui fait passer les requêtes GA4, GTM et Google Ads par votre domaine via un proxy CDN. Sur Cloudflare, quelques clics suffisent. C’est le meilleur rapport effort/résultat du marché, mais ses limites sont nettes. Il ne concerne que GA4 et Google Ads, Meta, LinkedIn et TikTok restent tiers. Surtout, il ne change pas la façon dont les cookies sont écrits : le navigateur les pose en JavaScript, donc le plafond de 7 jours d’ITP sur Safari s’applique toujours.

La maîtrise de la donnée : sGTM

Le server-side GTM offre le contrôle complet sur la transformation des données, le routage vers les fournisseurs et la persistance des cookies. Il n’est pourtant pas étanche. Si le script navigateur qui envoie l’événement initial est bloqué, le conteneur serveur ne reçoit rien. Et le server-side change la destination, pas le motif de la requête, que les filtres reconnaissent encore. Google recommande d’ailleurs de combiner Tag Gateway, CDN et sGTM.

Simo Ahava, lui, prend ses distances avec l’usage anti-bloqueur. Il écrit qu’il ne cautionne pas l’utilisation de ces techniques pour échapper aux bloqueurs. Je partage sa position. Mesurez le phénomène plutôt que de le combattre.

La pollution par les agents : là, Web Bot Auth sert

Les agents IA qui naviguent et déclenchent des tags gonflent vos sessions et déforment vos taux de conversion. Une chaîne user-agent se falsifie en une ligne. Une signature cryptographique, non. Cloudflare et AWS WAF vérifient déjà ces signatures en bordure de réseau pour leurs clients. Les acteurs bougent : OpenAI publie un répertoire de clés pour ChatGPT agent.

Deux précautions. Google recommande de continuer à s’appuyer sur les adresses IP, le reverse DNS et les user-agents pendant le déploiement progressif. Et l’absence de signature ne prouve pas qu’un bot est malveillant. Votre règle d’exclusion doit donc raisonner en trois états : vérifié, non signé, inconnu.

Le flux de données que je déploierais

À ma connaissance, vérifier une signature Ed25519 dans le bac à sable JavaScript d’un conteneur sGTM n’est pas réaliste. C’est mon analyse, pas une documentation officielle. Je ferais donc la vérification au niveau du CDN et je transmettrais le verdict à sGTM par un en-tête.

Navigateur ou agent
  → domaine first-party (CDN : Tag Gateway + vérification des signatures)
  → en-tête ajouté : x-bot-verdict = verified | unsigned | none
  → conteneur sGTM : client GA4, lecture de l'en-tête
  → paramètre d'événement bot_class
  → GA4 flux principal (trafic humain, consentement respecté)
  → GA4 flux secondaire (agents et trafic suspect)
  → BigQuery pour l'audit

Le flux secondaire est volontaire. Simo Ahava recommande un flux de données dédié pour ses mesures de blocage, afin de ne pas polluer l’analytics marketing. Même logique ici : vous excluez de vos rapports sans détruire l’information.

Le consentement ne se contourne pas

Cette stack améliore le transport et l’hygiène de la donnée. Elle ne change pas votre base légale. La CNIL n’a jamais inscrit GA4 sur sa liste des solutions exemptées, il reste soumis au consentement. Une configuration server-side ne permet pas de passer outre le choix de l’internaute. Quant à la proxyfication, la CNIL décrit des conditions exigeantes : traitement des identifiants, des URL, de l’IP et des possibilités de recoupement. Un sGTM mal réglé ne vous protège pas, il documente simplement votre problème.

Où l’IA accélère vraiment

Pas dans la collecte. Dans l’audit. Exportez une semaine de logs sGTM vers BigQuery, puis demandez à un LLM de regrouper les user-agents, les ASN et les comportements de navigation non étiquetés. Il propose des familles, vous validez à la main, vous codez la règle. Ce travail me prenait une demi-journée de requêtes SQL. Il tient maintenant en une heure, à condition de ne jamais déléguer la décision d’exclusion au modèle.

À faire cette semaine

Ajoutez un paramètre bot_class à vos événements dans un flux GA4 de test, sans rien exclure. Laissez tourner sept jours. Comparez ensuite vos conversions avec et sans le trafic non vérifié.

Quel pourcentage de votre « croissance » organique résiste à ce test ?