# Tracking server-side : à partir de quand ce n’est plus un luxe

> Le server-side vaut son coût quand vos campagnes s'optimisent sur les conversions et qu'une autre situation s'y ajoute. Pas pour passer les bloqueurs : notre test du 14 octobre 2026 montre qu'une installation standard est bloquée comme Google.

- Page d'origine : https://dotsland.com/tracking-server-side-quand-passer/
- Langue : fr
- Publié le : 2026-11-11T09:00:00+01:00
- Mis à jour le : 2026-10-14T01:22:14+02:00
- Rubrique : Marketing Digital
- Éditeur : Dotsland, https://dotsland.com/

---

## En bref

- Le tracking server-side devient utile quand vous achetez de la publicité optimisée sur les conversions et qu’au moins une autre situation s’y ajoute : un cycle d’achat de plus d’une semaine, le besoin de transmettre la marge, la volonté de filtrer ce qui sort, des chiffres qui ne se recoupent plus.
- Il ne sert pas à passer les bloqueurs. Le 14 octobre 2026, nous avons testé douze adresses de mesure contre la liste EasyPrivacy du jour : un serveur de balisage installé sur votre propre sous-domaine mais qui garde les chemins de Google est bloqué comme Google lui-même, trois fois sur trois.
- La même liste contient 35 621 règles qui visent nommément des sous-domaines de mesure déguisés en domaine du site, sur plus de 21 000 noms de domaine.
- Ce qu’il apporte vraiment : des cookies qui durent plus de sept jours sur Safari, un signal de conversion plus complet pour Meta et Google, et la maîtrise de ce qui sort, champ par champ.
- Il ne dispense jamais du consentement, et il coûte au minimum un serveur à surveiller.

Le tracking server-side cesse d’être un luxe quand vos campagnes publicitaires s’optimisent sur des conversions que le navigateur ne voit plus en entier : un cycle d’achat de plus de sept jours sur Safari, des ventes à rattacher à une marge, des plateformes qui demandent un envoi serveur en complément du pixel. Il reste un luxe si votre seul argument est de passer les bloqueurs de publicité : notre test du 14 octobre 2026 montre qu’une installation standard est bloquée comme le pixel qu’elle remplace.

> **Comment nous avons vérifié**  
> Le 14 octobre 2026, nous avons passé douze adresses de mesure (scripts et envois de Google, Meta et TikTok, un serveur de balisage sur sous-domaine, un point de collecte propre au site) dans le moteur de filtrage open source de Brave, chargé avec EasyList, EasyPrivacy (version du 13 octobre 2026, 23 h 05 UTC) et les listes de uBlock Origin. Nous avons ensuite compté, dans EasyPrivacy, les règles des sections consacrées aux sous-domaines de mesure déguisés. Les règles de cookies de Safari, la recommandation de Meta et le coût indiqué par Google viennent de leur documentation officielle, lue le même jour. Les sources figurent en fin d’article.

## Qu’est-ce que le tracking server-side change, concrètement ?

Dans une installation classique, le navigateur du visiteur charge les scripts de Google, Meta ou TikTok et leur envoie lui-même chaque événement. Avec le server-side, le navigateur envoie les événements à **votre** serveur, qui les relaie ensuite à chaque plateforme. Deux trajets au lieu d’un : du navigateur à votre serveur, puis de votre serveur aux plateformes.

Le second trajet est hors de portée du navigateur : c’est là que vous ajoutez la marge, retirez un champ, rattachez un remboursement. Le premier trajet, lui, reste une requête de navigateur comme une autre, et c’est là que se joue la question des bloqueurs.

## Le server-side passe-t-il les bloqueurs de publicité ?

Pas dans sa configuration la plus répandue. Voici ce qu’a donné notre test, toutes listes réunies.

| Adresse testée | Résultat | Règle qui bloque |
| --- | --- | --- |
| Scripts et envois de Google Analytics, Google Tag Manager, pixel Meta, pixel TikTok (6 adresses) | **Bloquées, 6 sur 6** | Règles visant les domaines des plateformes |
| Serveur de balisage sur votre sous-domaine, chemins de Google conservés (`/gtm.js`, `/gtag/js`, `/g/collect`) | **Bloquées, 3 sur 3** | Règles génériques sur le chemin, quel que soit le domaine |
| Serveur de balisage aux chemins renommés, point de collecte propre au site (3 adresses) | Passent, 3 sur 3, ce jour-là | Aucune |

Deux enseignements. D’abord, déplacer Google sur votre sous-domaine sans changer ses chemins ne change rien pour un bloqueur : la règle porte sur `/gtm.js` ou `/collect?v=`, pas sur l’adresse du serveur. Ensuite, ce qui passe aujourd’hui peut ne plus passer demain. EasyPrivacy se met à jour tous les quelques jours, et sa version du 13 octobre contient **35 621 règles**, réparties en vingt sections, qui visent nommément des sous-domaines de mesure installés sous le nom du site, sur plus de 21 000 noms de domaine. Les listes ajoutent les sites un par un.

Il y a surtout une raison de principe de ne pas bâtir un projet là-dessus : un visiteur qui installe un bloqueur exprime un choix. Le server-side sert à mesurer correctement les visiteurs qui ont accepté la mesure, pas à mesurer ceux qui ont fait savoir qu’ils n’en voulaient pas.

## Alors, à partir de quand le server-side vaut-il son coût ?

Notre règle : la première des cinq situations suivantes, plus au moins une autre.

**1. Vos campagnes s’optimisent sur les conversions.** Les algorithmes d’enchères de Meta et Google apprennent sur les conversions qu’ils reçoivent. Meta recommande lui-même d’implémenter son API Conversions « parallèlement » au pixel, dans une configuration qu’il appelle redondante, avec un identifiant d’événement commun pour dédupliquer. Si vous ne faites que de la notoriété ou du référencement naturel, cet argument tombe.

**2. Votre cycle d’achat dépasse sept jours, et une part de vos visiteurs est sur Safari.** Depuis 2019, Safari limite à sept jours la durée de vie des cookies créés par un script dans la page, ceux qu’utilisent les outils de mesure classiques. Un client qui revient acheter au bout de dix jours devient un nouveau visiteur, et la campagne qui l’avait amené perd la vente. Un cookie posé par votre propre serveur, dans la réponse HTTP, n’est pas visé par cette règle. Attention au montage : depuis 2020, Safari applique la même limite de sept jours aux cookies posés par un serveur tiers simplement caché derrière un sous-domaine du site. Le serveur doit être réellement le vôtre.

**3. Vous voulez transmettre la marge, pas seulement le chiffre d’affaires.** Le navigateur ne connaît pas votre coût d’achat, et ne doit pas le connaître. Le serveur, si. C’est la condition pour piloter vos campagnes sur la marge, comme dans notre méthode pour [construire la colonne POAS dans Google Ads](https://dotsland.com/colonne-poas-google-ads/), et pour retirer d’une campagne les ventes remboursées.

**4. Vous voulez savoir, et décider, ce qui sort de chez vous.** Avec un pixel, c’est le script de la plateforme qui choisit ce qu’il collecte dans la page. Avec un serveur, vous filtrez champ par champ et vous gardez la trace de ce qui est parti. C’est un argument de conformité autant que de qualité.

**5. Vos chiffres ne se recoupent plus.** Si les ventes comptées par GA4, par Google Ads et par votre back-office divergent sans explication, un passage par le serveur permet de rattacher chaque conversion à une commande réelle, à condition de surveiller ensuite ce rapprochement. Nous avons raconté dans [votre tracking vous ment peut-être en silence](https://dotsland.com/tracking-server-side-mensonge-silencieux/) ce qui arrive quand personne ne le fait.

## Quand ce n’est pas le bon investissement

- **Vous n’achetez pas de publicité à la conversion.** Une mesure d’audience exemptée de consentement, bien réglée, suffit le plus souvent, pour bien moins cher.
- **Votre problème est le consentement.** Si la majorité de vos visiteurs refuse la mesure, le server-side ne change rien : sans accord, rien ne doit partir, par le navigateur comme par le serveur. Notre article sur [la mesure d’audience sans consentement](https://dotsland.com/les-solutions-validees-par-la-cnil-pour-la-conformite-des-entreprises/) détaille pourquoi.
- **Personne ne pourra le surveiller.** Un serveur de mesure qui tombe ne fait pas tomber le site : les conversions disparaissent sans bruit. Sans alerte et sans rapprochement avec les commandes, vous avez ajouté un point de panne invisible.

## Combien ça coûte ?

Pour un serveur de balisage hébergé chez Google, sa documentation indique environ 45 dollars par mois et par serveur dans la configuration par défaut, et recommande d’en faire tourner au moins deux pour limiter le risque de perte de données en cas de panne, soit environ 90 dollars par mois d’hébergement. Des offres gérées existent, facturées au volume d’événements. Dans les deux cas, le poste qui coûte le plus est ailleurs : le paramétrage initial, la déduplication avec ce que le navigateur envoie encore, et la surveillance dans la durée.

## Comment décider en une heure

1. **Listez vos plateformes publicitaires** et vérifiez lesquelles optimisent sur des conversions.
2. **Mesurez votre délai d’achat** : la part des commandes passées plus de sept jours après la première visite.
3. **Regardez la part de Safari** dans vos visites, sur ordinateur et sur mobile.
4. **Comparez sur un mois** les ventes de votre back-office, de GA4 et de vos plateformes publicitaires.
5. **Décidez qui surveillera** le dispositif une fois en place, avant de l’installer.

> **Ce que notre test ne dit pas**  
> Il porte sur les listes de filtrage, pas sur chaque bloqueur ni chaque navigateur, qui n’activent pas tous les mêmes listes. Il donne l’état du 14 octobre 2026 : les listes changent tous les quelques jours. Il ne mesure pas non plus la part de vos propres visiteurs équipés d’un bloqueur.

## Ce que ça dit de plus grand

Le server-side est souvent vendu comme une parade : aux bloqueurs, aux navigateurs, parfois même au consentement. C’est la mauvaise raison, et notre test montre qu’elle ne tient pas longtemps. La bonne raison est plus banale et plus durable : reprendre la main sur la donnée que vous envoyez à vos plateformes, l’enrichir de ce que vous seul savez, et la vérifier contre vos commandes réelles.

Ce rapprochement entre ce que disent les outils et ce qui s’est vendu, c’est le cœur de notre expertise [data, analytics et performance](https://dotsland.com/expertise/data-analytics-performance/).

## Sources

Pages ouvertes le 14 octobre 2026.

1. EasyPrivacy, version 202610132305 (13 octobre 2026, 23 h 05 UTC), sections `easyprivacy_specific_cname_*` et règles génériques `/gtm.js`, `/gtag/js?`, `/collect?v=`. [Consulter](https://easylist.to/easylist/easyprivacy.txt)
2. Moteur de filtrage de Brave (adblock-rust), utilisé par sa liaison Python `adblock` 0.6.0. [Consulter](https://github.com/brave/adblock-rust)
3. WebKit, « Intelligent Tracking Prevention 2.1 », février 2019 : cookies créés par `document.cookie` limités à sept jours. [Consulter](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/)
4. WebKit, « CNAME Cloaking and Bounce Tracking Defense », 12 novembre 2020 : cookies posés par un serveur tiers caché derrière un sous-domaine limités à sept jours. [Consulter](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/)
5. Meta for Developers, « Gestion des évènements dupliqués de pixel et de l’API Conversions ». [Consulter](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events)
6. Google for Developers, « Configurer le taggage côté serveur avec Cloud Run », mise à jour du 12 mai 2026 : environ 45 $ par serveur et par mois, au moins deux instances recommandées. [Consulter](https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide?hl=fr)

## FAQ

### Le tracking server-side permet-il de passer les bloqueurs de publicité ?

Pas dans sa configuration la plus répandue. Le 14 octobre 2026, un serveur de balisage installé sur le sous-domaine du site mais gardant les chemins de Google (`/gtm.js`, `/gtag/js`, `/g/collect`) était bloqué trois fois sur trois par la liste EasyPrivacy, qui contient aussi 35 621 règles visant nommément des sous-domaines de mesure. Et un visiteur qui installe un bloqueur exprime un choix qu’il faut respecter.

### À partir de quand faut-il passer au server-side ?

Quand vos campagnes s’optimisent sur les conversions et qu’au moins une autre situation s’y ajoute : un cycle d’achat de plus de sept jours avec une part de visiteurs sur Safari, le besoin de transmettre la marge, la volonté de filtrer ce qui sort, ou des chiffres qui ne se recoupent plus entre GA4, vos plateformes et votre back-office.

### Le server-side dispense-t-il du consentement ?

Non. Il change le chemin de la donnée, pas la nature du traitement. Sans consentement, rien ne doit partir vers une plateforme publicitaire, que l’envoi passe par le navigateur ou par votre serveur.

### Combien coûte un serveur de balisage ?

Hébergé chez Google, environ 45 dollars par mois et par serveur selon sa documentation, avec au moins deux serveurs recommandés, soit environ 90 dollars par mois. Le paramétrage, la déduplication et la surveillance coûtent davantage que l’hébergement.

### Dotsland peut-il m’accompagner ?

Oui. Nous faisons avec vous le diagnostic en une heure décrit plus haut, puis, si le server-side se justifie, le plan de marquage, la déduplication et le rapprochement avec vos commandes. Commencez par la liste ci-dessus, puis [écrivez-nous](https://dotsland.com/contact/).