Votre sGTM n'est plus vraiment server-side (Google l'a rebranché)

Vos conversions Google Ads en server-side ont augmenté cet été. Vous n’avez rien changé, pas de nouveau tag, pas de nouvelle balise, pas de retouche du conteneur. Et pourtant la courbe est montée, quelque part entre juin et juillet. Avant de mettre ça sur le compte d’un bon trimestre ou d’un uplift de votre setup, arrêtez-vous : ce n’est probablement pas votre travail. C’est Google qui a rebranché le navigateur dans votre pipeline sGTM, via un mécanisme qu’il appelle les parallel browser signals, sans l’annoncer ailleurs que dans ses release notes.

Tout le monde a vendu, et acheté, le server-side GTM sur une promesse d’architecture : le navigateur envoie un hit à votre serveur, et c’est votre serveur qui décide de ce qui part chez Google. Cette phrase, vous l’avez sans doute écrite quelque part, dans un cahier des charges ou dans une doc de conformité pour votre DPO. En 2026, elle est devenue fausse, et je vais vous montrer précisément où.

Cet article n’est pas une news de release notes de plus. C’est un article de diagnostic et de décision. Vous allez comprendre ce qui a bougé dans vos chiffres, apprendre à vérifier ce qui sort réellement de votre conteneur quand le consentement est refusé, recaler vos baselines avant Black Friday, et surtout corriger les formulations que vous avez déjà promises à un client ou à un DPO. Si vous découvrez le server-side, la promesse qu’on réexamine ici est posée dans mon guide GTM server-side. Cet article en est le pendant honnête, dans la même veine que celui sur le sous-domaine sGTM bloqué : là où le guide dit « migrez », celui-ci dit « voici où la promesse s’arrête ».

Le symptôme d’abord : un uplift que vous n’avez pas provoqué

Reprenons dans l’ordre. Le signal qui doit vous alerter n’est pas une alerte technique, c’est un écart de volume. Sur plusieurs comptes que j’ai regardés, les conversions Google Ads remontées via sGTM affichent une marche d’escalier, pas une pente : un saut net sur une poignée de jours, puis un nouveau plateau plus haut. Relevé au 15 septembre 2026 sur les comptes concernés, l’ordre de grandeur tourne autour de 6 à 12 % de conversions en plus sur les segments où Google Signals était actif, sans la moindre modification de configuration côté conteneur.

Une marche d’escalier, ce n’est jamais un effet de saisonnalité ni un uplift de tag. La saisonnalité ondule, un bon setup fait monter progressivement. Un saut sur trois jours suivi d’un plateau, ça veut dire qu’un interrupteur a été basculé quelque part, et pas par vous. C’est le premier réflexe de praticien : la forme de la courbe vous dit déjà que la cause est externe.

Le piège, c’est la tentation de s’attribuer le mérite. Ne déclarez pas cette hausse comme un uplift de votre travail, vous vous exposeriez à devoir la reproduire l’an prochain. Ne la déclarez pas non plus comme un bug, parce que côté Google, ce n’en est pas un : c’est un comportement voulu et documenté, juste pas annoncé.

Ce qui a changé, ligne par ligne

Trois entrées des release notes de Google Tag Manager racontent la même histoire, mais personne ne les a recollées. Prises séparément, ce sont trois notes techniques anodines. Ensemble, elles dessinent une thèse : Google recouple systématiquement le serveur au navigateur.

À ces trois lignes s’ajoute un mouvement de fond : l’unification du Google tag et de GTM annoncée le 20 août 2026, et le comportement piloté par l’ID de conteneur depuis juillet. Même série de release notes, même direction : la frontière client-side / server-side se dissout côté Google. Le changement le plus visible de cette série, c’est d’ailleurs gtag(‘config’) qui cesse de fonctionner dans GTM le 2 octobre 2026. Pendant ce temps, les équipes mesure continuent de raisonner avec deux mondes séparés. C’est là que se creuse l’écart entre ce que vous croyez faire tourner et ce qui tourne vraiment.

« Parallel browser signals », traduction honnête

Le terme vient directement des release notes, et il est précis dans ce qu’il cache. « Parallel » veut dire que ces signaux voyagent à côté de votre flux serveur, pas à travers lui. Votre conteneur reçoit son hit et l’envoie, comme prévu ; mais en parallèle, un canal navigateur alimente Google directement, et c’est Google qui recolle les deux à l’arrivée grâce au GCLID. Vous n’êtes plus le seul point de passage. Vous n’êtes plus l’arbitre unique de ce qui part.

Ce qui est documenté, c’est le principe : Google le décrit dans sa page sur Google Signals en sGTM et dans celle sur le consent mode en server-side. Ce qui n’est pas documenté, et c’est le point que je refuse de combler par une supposition, ce sont les champs exacts des payloads non consentis émis par le template Floodlight. La configuration Floodlight en sGTM décrit le setup, pas le contenu précis de la requête émise quand ad_storage est refusé.

C’est important, alors soyons nets : personne, hors de Google, ne peut affirmer aujourd’hui la liste exacte des paramètres qui partent en cas de refus de consentement. La force de cet article n’est pas de vous donner cette liste, c’est de vous donner la méthode pour l’établir vous-même, sur votre propre conteneur. Un praticien ne suppose pas le contenu d’un payload : il l’ouvre et le lit.

Le protocole en 4 étapes pour voir ce qui sort vraiment

Voici la manip. Comptez trente minutes, un conteneur de test, et un peu de rigueur.

1. Isolez un conteneur de test. Ne faites jamais ça sur la prod. Dupliquez votre conteneur serveur sur un environnement séparé (un service Cloud Run distinct, par exemple), avec les mêmes tags Floodlight et Ads que la prod, mais un flux de données que vous contrôlez.
2. Refusez ad_storage. Dans le conteneur web qui alimente le serveur, forcez un état de consentement ad_storage: denied (et analytics_storage: denied pour un test strict). C’est l’état qui doit, selon la promesse d’origine, empêcher toute donnée publicitaire de sortir. Si vous avez un doute sur ce que « refusé » signifie exactement côté signal, la mécanique est détaillée dans mon article sur le Consent Mode v2.
3. Déclenchez une conversion Floodlight et une conversion Ads. Simulez un achat ou un lead avec un GCLID présent dans l’URL. Vous voulez reproduire le cas exact de la jointure du 22 juin.
4. Inspectez le payload sortant, paramètre par paramètre. Activez le mode Preview du conteneur serveur et lisez la requête effectivement émise vers les endpoints Google. Ne vous fiez pas au nom du tag, lisez l’URL et le corps de la requête sortante.

Voici la check-list des identifiants à chercher dans ce payload. Copiez-la telle quelle dans votre doc de QA :

[ ] GCLID / GBRAID / WBRAID présents alors que ad_storage = denied ?
[ ] E-mail haché (sha256) dans un paramètre em, sha256_email ou équivalent ?
[ ] Téléphone haché dans un paramètre pn ou sha256_phone ?
[ ] Identifiant de session ou client (cid, sid) reconstitué côté serveur ?
[ ] Adresse IP transmise ou dérivée (géo, region) ?
[ ] Paramètres custom (u1..uN) contenant un identifiant planqué ?
[ ] Une requête S2S part-elle MEME quand aucun tag ne se déclenche visiblement ?
[ ] Date du relevé notée à côté de chaque résultat.

La dernière ligne n’est pas cosmétique. Ces comportements évoluent au fil des release notes : un relevé sans date n’est pas un relevé, c’est un souvenir.

Recaler la baseline avant Black Friday

Une fois que vous savez ce qui sort, il faut savoir ce que ça a fait à vos chiffres. Le risque, sinon, c’est de figer une baseline de QA fausse juste avant le pic e-commerce, et de passer novembre à comparer des pommes gonflées à des poires.

L’objectif de la mesure : isoler l’effet de la jointure GCLID x cookie, et distinguer les conversions retrouvées des vraies ventes en plus. C’est exactement le même piège que celui du Data Strength Uplift, la métrique Google Ads qui compte des conversions récupérées, pas des ventes supplémentaires. Une conversion que Google reconnecte par GCLID n’est pas un client de plus dans votre CRM.

Sur l’export GA4 vers BigQuery, une requête de comparaison avant / après vous donne le premier tri. Adaptez les dates à votre propre marche d’escalier relevée à l’étape précédente :

-- Compare le volume de conversions avant / après la bascule observee.
-- Ajustez les bornes de dates a VOTRE marche d'escalier.
WITH conv AS (
  SELECT
    event_date,
    CASE
      WHEN PARSE_DATE('%Y%m%d', event_date) < DATE '2026-06-22' THEN 'avant'
      ELSE 'apres'
    END AS periode,
    (SELECT value.string_value FROM UNNEST(event_params)
       WHERE key = 'gclid') AS gclid,
    ecommerce.purchase_revenue AS revenue
  FROM `projet.analytics_XXXXXX.events_*`
  WHERE event_name = 'purchase'
    AND _TABLE_SUFFIX BETWEEN '20260501' AND '20260731'
)
SELECT
  periode,
  COUNT(*) AS conversions,
  COUNTIF(gclid IS NOT NULL) AS conversions_avec_gclid,
  ROUND(COUNTIF(gclid IS NOT NULL) / COUNT(*) * 100, 1) AS pct_gclid,
  ROUND(SUM(revenue), 2) AS revenue_total
FROM conv
GROUP BY periode
ORDER BY periode DESC;

Ce que vous cherchez : une hausse de conversions_avec_gclid et de pct_gclid sans hausse proportionnelle de revenue_total. Si le compte de conversions monte mais que le chiffre d’affaires réel suit à peine, vous tenez la preuve que l’uplift est une reconnexion de signal, pas une vente. Avant de conclure, excluez aussi les autres sources de gonflement connues : les Enhanced Conversions en server-side et, pour les setups multi-plateformes, la déduplication décrite dans mon article sur Meta CAPI. Une fois ces effets isolés, ce qui reste est votre vraie performance.

Ce que vous devez réécrire dans votre doc client ou DPO

C’est le morceau à forte valeur, et le plus inconfortable. Si vous avez documenté un setup server-side comme un contrôle de conformité, certaines de vos phrases sont maintenant fausses. Voici deux ou trois reformulations, prêtes à copier.

Avant : « Rien ne sort du conteneur server-side sans consentement de l’utilisateur. » Après : « Le conteneur server-side contrôle les tags que nous configurons. Certains templates fournis par Google (Floodlight, conversions Ads) peuvent émettre des requêtes serveur à serveur à des fins de modélisation, y compris en l’absence de consentement publicitaire. Un audit du payload sortant est nécessaire pour établir la liste exacte des données concernées. »

Avant : « Le server-side garantit que l’adresse IP et les identifiants ne sont pas transmis à Google sans base légale. » Après : « Le server-side nous permet de contrôler le payload des tags que nous maîtrisons. La transmission d’identifiants via les templates Google et via les parallel browser signals doit faire l’objet d’une vérification datée, et non d’une garantie a priori. »

Avant : « Notre architecture server-side est notre mesure de minimisation des données. » Après : « Le server-side est un des leviers de minimisation, pour les tags que nous configurons. Il ne couvre pas les canaux navigateur parallèles activés côté Google. »

Le cadre réglementaire européen rend cette réécriture urgente, pas facultative. La règle des 6 mois du Digital Omnibus et l’élargissement de ce que Google exploite, documenté dans mon article sur l’adresse IP en Google Ads, vont dans le même sens : un flux de données non consenties qui sort d’un conteneur serveur n’est plus un détail d’implémentation. C’est le point exact où l’architecture rencontre la conformité, et où le sGTM aggrave l’exposition au lieu de la réduire.

Ce que le server-side protège encore

Ne basculez pas dans l’excès inverse. « Le sGTM ne sert plus à rien » est aussi faux que « rien ne sort sans consentement ». Voici la grille honnête.

Ce qui tient toujours : le contrôle du payload des tags que vous configurez vous-même (hors templates Google fermés), le contexte first-party, l’enrichissement de données maîtrisé, une politique CSP resserrée, et la réduction de la surface client-side. Tout ça reste réel et reste un bénéfice.

Ce qui ne tient plus : la phrase absolue « rien ne part sans consentement ». Elle est morte. Les templates Google et les parallel browser signals ouvrent des canaux que votre conteneur ne médie pas.

Et si le bénéfice conformité s’érode, alors le calcul coût / bénéfice bouge, ce qui mérite de relire ce que le server-side coûte vraiment au regard de ce qu’il protège encore. Autre chose à ne pas oublier : la pression du navigateur ne s’inverse pas. Entre Safari 27 et le durcissement des bloqueurs, le server-side garde une utilité défensive réelle, même dépouillé de son argument de conformité absolu. Le mouvement d’unification côté Google, que je détaille dans Google Tag Gateway vs server-side GTM, va dans le même sens.

La vraie posture, en septembre 2026, c’est celle-ci : ouvrez votre conteneur, lisez ce qui en sort, datez votre relevé, et réécrivez ce que vous avez promis. Le server-side reste un bon outil. Il n’est simplement plus l’argument de conformité que vous vendiez. Faites la manip cette semaine, avant que le pic e-commerce ne fige une baseline que vous n’aurez pas vérifiée.