Le sous-domaine de tracking de Simo Ahava est sur une liste de blocage. Quand un visiteur arrive sur son blog avec uBlock Origin actif, la requête vers sgtm.simoahava.com ne part pas. Si la référence mondiale du server-side voit son propre conteneur coupé, l’argument « ça ne concerne que les setups mal faits » ne tient plus. Voici ce qui a changé, et pourquoi votre sous-domaine sGTM bloqué n’est plus une hypothèse d’école.
Pendant des années, on a vendu le server-side GTM (moi compris, sur ce blog) comme le moyen de récupérer les données que le client-side perd. L’argument reposait sur une hypothèse simple : un sous-domaine first-party comme sgtm.votresite.com passe sous le radar des bloqueurs, qui ne connaissent que googletagmanager.com. Cette hypothèse est fausse depuis mai 2026. Les mainteneurs de filtres ont changé de méthode : ils ne visent plus seulement les origines tierces connues, ils listent désormais les sous-domaines de tracking un par un, nommément.
Cet article n’est pas un guide de contournement. C’est un article de diagnostic et de décision. Vous allez vérifier votre propre domaine, chiffrer la perte sur vos données plutôt que sur une fourchette de vendeur, et repartir avec une grille pour décider quoi faire, y compris ce que je vous déconseille de faire.
Ce qui a changé dans les listes de filtrage
Jusqu’ici, une liste de blocage fonctionnait par motifs génériques : elle connaissait googletagmanager.com, google-analytics.com, et coupait tout ce qui en venait. Un sous-domaine à vous, sur votre propre nom de domaine, restait invisible parce qu’il n’était dans aucune liste.
Le basculement, c’est que les mainteneurs ont commencé à cataloguer ces sous-domaines first-party à la main. Le fichier AdGuard tracking_servers_firstparty.txt en est l’exemple le plus net. Au 17 septembre 2026, je l’ai ouvert et recompté : il contient 2 527 règles de blocage de sous-domaines entiers, dont 41 entrées commençant par gtm. et 43 commençant par sgtm.. Chaque entrée est un domaine nommé, pas un motif. On y trouve sgtm.simoahava.com, mais aussi sgtm.yubico.com, sgtm.ookla.com, sgtm.kaspersky.de, gtm.temu.com, et côté hébergeur gw.stape.fr et stape.brascast.com. Ces chiffres bougent chaque semaine, à la hausse : datez toujours votre propre relevé.
Le second point, celui qui fait mal, c’est la distribution. Le fichier EasyPrivacy easyprivacy_specific.txt fait le même travail, et EasyPrivacy est activé par défaut dans uBlock Origin. Autrement dit, il ne s’agit pas d’une liste optionnelle que seuls les paranoïaques cochent : c’est le réglage d’usine de l’un des bloqueurs les plus installés au monde. Une entrée là-dessus touche une part réelle de votre trafic, sans que l’utilisateur ait rien fait de spécial.
Si vous voulez le contexte de ce qu’est le server-side et de la promesse qu’on est en train de réexaminer, il est posé dans mon guide GTM server-side. Cet article-ci en est le pendant honnête : là où le guide dit « migrez », celui-ci dit « voici où l’argument s’arrête ».
Vérifiez si votre sous-domaine sGTM est bloqué (2 minutes)
C’est la partie la plus utile, alors elle vient tôt. Vous avez deux moyens de savoir si votre endpoint est listé.
Le rapide : isblocked.fyi. L’outil, apparu en juin 2026, agrège 22 listes de filtrage (uBlock Origin, Brave, AdGuard, AdBlock Plus). Vous tapez votre sous-domaine, c’est gratuit et sans compte, et il vous dit sur quelles listes vous figurez. Il conserve aussi l’historique, ce qui va nous servir juste après pour le chiffrage.
Le sûr : allez lire les fichiers sources directement sur GitHub. tracking_servers_firstparty.txt chez AdGuard et easyprivacy_specific.txt chez EasyList sont publics. Un Ctrl+F sur votre domaine règle la question sans intermédiaire.
Reste à lire le résultat correctement, parce que toutes les entrées ne se valent pas.
| Ce que vous voyez | Poids réel |
|---|---|
| Entrée sur EasyPrivacy (défaut uBlock Origin) | Fort : touche une large part du trafic sans action de l’utilisateur |
| Entrée sur une liste optionnelle | Modéré : ne touche que ceux qui l’ont cochée |
| Blocage « tout le trafic » | Total : la requête ne part jamais |
| Blocage « third-party only » | Total en pratique pour du tracking embarqué |
| Blocage scripts / XHR | Coupe le chargement du conteneur ou l’envoi des hits |
Le piège classique est la mention « third-party only », qu’on lit comme rassurante. Pour du tracking, elle ne l’est pas : votre requête de mesure est, par nature, une requête tierce du point de vue du bloqueur, même quand elle part vers votre propre sous-domaine. Un blocage « third-party only » équivaut donc, pour vous, à un blocage total.
Chiffrez la perte sur VOS données, pas sur une fourchette de vendeur
Vous allez lire partout que les ad blockers coupent « 5 à 40 % » du trafic selon l’audience. Cette fourchette vient de Mariusz Brucki, chez TAGGRS, un hébergeur sGTM. Ce n’est pas une étude indépendante, c’est le chiffre d’un acteur qui vend la contre-mesure au problème qu’il décrit. Je le cite en nommant sa source et son intérêt, je ne le reprends pas comme un fait. Vous avez mieux sous la main : vos propres données.
La méthode maison tient en trois gestes. Comparez le volume d’événements côté serveur (export sGTM ou table BigQuery) au volume côté client sur la même fenêtre. Segmentez par navigateur et par device, parce qu’un moyennage général ne veut rien dire. Puis regardez l’écart : c’est votre perte réelle, sur votre audience, pas sur celle d’un article.
Le repère sectoriel compte autant que le chiffre. Les verticales à fort taux de bloqueurs (tech, gaming, développeurs) n’ont rien à voir avec le retail grand public. Si vous vendez des outils à des développeurs, votre exposition peut être plusieurs fois celle d’un e-commerce mode. Un chiffre moyen appliqué à votre cas est au mieux inutile, au pire trompeur.
Attention au piège de datation, parce que c’est là qu’on se trompe le plus. Si votre courbe a chuté d’un coup, ne concluez pas trop vite au blocage. Croisez la date de la baisse avec la date de premier référencement de votre domaine sur la liste, qu’isblocked.fyi conserve dans son historique. Si les deux coïncident, l’imputation est propre. Sinon, cherchez ailleurs : une balise cassée, un changement de consentement, une saisonnalité. La démarche générale pour trancher entre bug, tracking cassé et vraie baisse, je la détaille dans mon article sur les données manquantes dans GA4, et la source serveur pour comparer les volumes se met en place comme dans mon guide export sGTM vers BigQuery.
Une nuance utile au passage, parce qu’elle circule mal : le server-side reste immunisé pour l’écriture serveur vers BigQuery. Un bloqueur qui aurait tué la requête client ne peut rien contre une insertion serveur. Mais cette immunité tombe si la requête initiale du navigateur vers votre sous-domaine est elle-même bloquée : dans ce cas, il n’y a jamais de hit à insérer côté serveur. C’est exactement la faille que les listes viennent d’ouvrir.
Ce qui ne marche pas, ou plus
Le premier réflexe de tout le monde : renommer son sous-domaine sgtm. en quelque chose de moins évident. data., m., t., au choix. Soyons clairs, ça vous fait gagner quelques mois, pas plus. Les listes se mettent à jour, et le renommage est précisément ce que les mainteneurs anticipent : ils cataloguent les nouveaux noms au fur et à mesure. Vous entrez dans une course à l’armement où l’autre camp a le temps pour lui et vous fait payer chaque manche en dette technique.
La logique de contournement est perdante par construction, et c’est le point que je veux poser sans détour. Chaque tour de renommage vous coûte une reconfiguration, un risque de casse, et un peu plus d’opacité vis-à-vis d’un utilisateur qui, en installant uBlock Origin, a exprimé un choix. Ce n’est pas une position morale abstraite, c’est aussi une question d’efficacité : vous dépensez de l’énergie sur un vecteur que vous ne contrôlez pas.
Ce qui change vraiment quelque chose, et à quel prix
Il existe de vraies options, à condition de regarder leur coût en face et pas seulement leur bénéfice.
| Option | Bénéfice réel | Coût (technique, éthique, juridique) |
|---|---|---|
| Chemins de service randomisés (Google tag gateway, depuis mai 2026) | Masque les IDs de conteneur, complique le motif de détection | Reste un contournement, gain temporaire, dépendance à Google |
| Sous-répertoire + proxy CDN plutôt que sous-domaine | Même origine que le site, plus difficile à isoler | Configuration lourde, risque de flaguer le site entier |
| Ne rien contourner, mesurer proprement | Cohérence, crédibilité, conformité | Accepter une part de trafic non mesurable |
L’arbitrage entre le tag gateway et le sGTM, je l’ai traité en détail dans mon comparatif Google tag gateway ou GTM server-side, et je dois y ajouter la nuance de cet article : le tag gateway masque, il ne rend pas invisible.
Sur le choix du sous-répertoire, il faut citer Simo Ahava tel quel, parce que sa position est contre-intuitive. Il déconseille le same-origin et défend le sous-domaine, pour une raison de separation of concerns : un bloqueur trop zélé pourrait flaguer le site entier s’il confond le site et l’endpoint de mesure. Autrement dit, la solution « plus discrète » du sous-répertoire vous expose à un risque plus grave, celui de voir tout votre domaine pris pour une régie. Ce n’est pas tranché, mais ça mérite d’être su avant de rearchitecturer.
La partie que personne n’écrit : et si on arrêtait de courir ?
Posons deux faits calmement.
Les chiffres d’uplift qu’on vous montre pour justifier le tag gateway (11 % avec Cloudflare, 14 % avec Fastly) sont des chiffres Google, pas des études indépendantes. Comme la fourchette « 5 à 40 % » venait d’un hébergeur, ces uplifts viennent du fournisseur de la solution. Ça ne les rend pas faux, ça les rend intéressés. Traitez-les comme tels.
Ensuite, le routage first-party ne change rien à la base légale. Le jugement allemand de mars 2025, qui dit que GTM ne peut pas s’exécuter avant consentement explicite, s’applique que le script vienne de Google ou de votre propre serveur. Changer d’origine technique ne fait pas disparaître une obligation RGPD. Le cadre du Consent Mode et de ce qu’il faut réellement respecter est dans mon article Consent Mode v2 dans GA4.
Et voici la ligne que j’assume. Un utilisateur qui a installé uBlock Origin a fait un choix. Le rôle du consultant est de mesurer proprement ce qui est mesurable, pas de forcer la porte. Le server-side reste justifié, pour de vraies raisons : cookies first-party plus durables, contrôle des données, CAPI, maîtrise des coûts. Mais il n’est plus justifié par « ça contourne les bloqueurs », et c’est cette raison-là qu’il faut arrêter de vendre.
Récap actionnable
Cette semaine : vérifiez votre sous-domaine sur isblocked.fyi et dans les deux fichiers GitHub, puis mettez le domaine sous monitoring pour être alerté s’il est ajouté. Ce mois-ci, avant le pic de fin d’année : chiffrez votre perte réelle en comparant volumes serveur et client, segmentés par navigateur, et documentez votre exposition. L’audit de tracking avant le pic, je le déroule dans mon guide Black Friday, et le blocage par IP de Safari 27, l’autre front du même combat, est traité ici.
Dans un reporting client, la formulation juste n’est pas « on a tout récupéré ». C’est : une part identifiée du trafic est structurellement non mesurable côté navigateur, voici son ordre de grandeur sur votre audience, voici ce qu’on capte quand même côté serveur, et voici pourquoi courir après le reste coûterait plus que ça ne rapporterait. Cette phrase-là vaut mieux qu’un sous-domaine renommé tous les trois mois.