Le tracking client-side montre ses limites

Google Ads ou Meta Ads rapportent moins de conversions que votre outil de gestion de commandes n'en enregistre réellement. Ce n'est presque jamais un bug de configuration.

Si vous pilotez un site e-commerce, vous avez probablement déjà constaté l'écart. C'est une conséquence structurelle de la manière dont le tracking web fonctionne depuis vingt ans : des scripts de mesure exécutés directement dans le navigateur du visiteur.

Ce mode de collecte, dit « client-side », est aujourd'hui bousculé par trois phénomènes qui n'ont rien à voir avec la disparition des cookies tiers. D'ailleurs, clarifions un point d'actualité souvent mal relayé : en avril 2025, Google a annoncé qu'il maintenait les cookies tiers dans Chrome, renonçant à leur suppression généralisée ; en octobre 2025, le Privacy Sandbox — l'alternative que Google construisait depuis 2020 — a lui-même été retiré.

Détaillons ces trois causes concrètes de perte de données, indépendantes du sort des cookies :

• Les bloqueurs de publicité et extensions de confidentialité (uBlock Origin, Ghostery, AdBlock…) interceptent nommément les domaines de collecte connus (google-analytics.com, facebook.com/tr, etc.) avant même que la requête ne parte. Une partie significative des internautes, variable selon les audiences B2B/B2C, ne remonte tout simplement jamais dans vos rapports.
• L'ITP (Intelligent Tracking Prevention) de Safari/iOS réduit agressivement la durée de vie des cookies déposés en JavaScript côté client, parfois à 24 h ou 7 jours selon le contexte. Sur un site e-commerce où le cycle d'achat dépasse quelques jours, l'attribution devient trouée.
• Le consentement RGPD conditionne le déclenchement des balises marketing : sans consentement, pas de mesure de conversion attribuée à ce visiteur — et c'est normal, c'est la loi. Le tracking server-side n'y change rien : il respecte le même cadre de consentement que le client-side. C'est l'idée reçue la plus fréquente sur ce sujet.

Qu'est-ce que le tracking server-side, concrètement ?

En tracking client-side classique, le navigateur du visiteur envoie les données de mesure directement aux serveurs des plateformes tierces : Google Analytics, Meta, LinkedIn Ads, etc. Le conteneur Google Tag Manager (GTM) tourne dans la page, exécute des scripts tiers, et chaque plateforme reçoit sa propre requête, depuis le navigateur.

En tracking server-side (ou « server-side tagging »), un maillon intermédiaire s'intercale. Le navigateur n'envoie plus ses événements directement aux plateformes : il les envoie à un premier point de collecte que vous hébergez et contrôlez, généralement exposé sur un sous-domaine de votre propre nom de domaine (un domaine « first-party », par exemple mesure.monsite.fr). C'est ce conteneur serveur qui reçoit l'événement, peut l'enrichir ou le filtrer, puis le redistribue vers les plateformes marketing via des appels serveur-à-serveur.

Ce déplacement change la donne sur plusieurs points :

• Le point de collecte étant sur votre propre domaine, il échappe aux listes de blocage génériques qui ciblent les domaines tiers connus (adblockers).
• Les cookies posés depuis un domaine first-party bénéficient d'une durée de vie plus favorable sous ITP que des cookies posés par un tiers.
• Vous devenez le point de passage de toute la donnée : vous pouvez la nettoyer, l'enrichir avec des informations internes (statut de fidélité, segment client), la dédupliquer ou la router différemment selon la plateforme, avant qu'elle ne quitte votre infrastructure.

Ce que le tracking server-side résout — et ce qu'il ne résout pas

Une architecture server-side améliore réellement trois choses : le taux de capture des événements, la persistance de l'identifiant visiteur, et le contrôle qualité de la donnée avant son envoi aux plateformes.

En revanche, il ne règle pas — et il faut le dire sans ambiguïté, car c'est une source fréquente de confusion commerciale dans ce marché :

• Il ne réintroduit pas magiquement la donnée perdue par refus de consentement. Un visiteur qui refuse les cookies marketing reste non mesurable pour ces finalités, server-side ou pas.
• Il ne remplace pas un plan de marquage propre. Une architecture serveur alimentée par un dataLayer mal structuré produira une donnée tout aussi peu fiable qu'en client-side — juste acheminée différemment.
• Il ne dispense pas de configurer correctement l'outil de base. Si votre conteneur GTM côté navigateur est mal structuré, migrer côté serveur n'arrangera rien : consultez d'abord notre guide pour configurer Google Tag Manager.

Architecture type d'un dispositif de tagging serveur

Sans entrer dans un tutoriel d'installation, voici les briques qui composent une architecture server-side standard, dans l'écosystème Google.

1. Un conteneur GTM serveur, distinct du conteneur GTM web. Il tourne non plus dans le navigateur mais sur une infrastructure serveur (le plus souvent Node.js dans l'implémentation officielle de Google). Il reçoit les événements, applique une logique de traitement (clients de tags, variables, déclencheurs), et les redistribue.
2. Un endpoint de collecte first-party. L'URL vers laquelle le navigateur envoie désormais ses événements, hébergée sur un sous-domaine de votre propre nom de domaine. Ce point est celui qui échappe le mieux aux listes de blocage.
3. Des clients et des tags côté serveur, qui traduisent l'événement reçu en appel vers chaque plateforme cible : l'API de mesure GA4, la Conversion API (CAPI) de Meta, l'API de conversions LinkedIn, etc.
4. Une couche de gouvernance de la donnée, souvent négligée : règles de filtrage (ne pas transmettre certains champs sensibles), de transformation (hashage d'identifiants avant envoi), et de journalisation pour audit.

Options d'hébergement : trois familles, un arbitrage différent

C'est ici que le choix d'infrastructure devient structurant, et qu'il dépasse largement la seule configuration de tags.

Ces trois familles n'ont ni le même coût réel, ni les mêmes contraintes d'exploitation, ni le même niveau de maîtrise sur la localisation des données. Nous les avons comparées en détail, chiffres à l'appui, dans notre article Server-side GTM : faut-il l'héberger sur Google Cloud, Stape ou vos propres serveurs ?

L'auto-hébergement est l'option la moins répandue chez les agences purement marketing, parce qu'elle demande une réelle compétence d'infrastructure et de développement backend — pas seulement de paramétrage d'outils. C'est un terrain qui recoupe directement notre pratique : notre équipe travaille au quotidien sur des architectures Symfony/PHP et sur l'hébergement d'infrastructures Sylius pour de l'e-commerce, et nous publions plusieurs plugins open-source pour l'écosystème Sylius sur GitHub. Auto-héberger un conteneur de tagging serveur, l'intégrer à une infrastructure e-commerce existante, ou construire des ponts avec un backend PHP maison sont des sujets que nous traitons avec les mêmes réflexes qu'un projet applicatif classique : versionnement, supervision, plan de reprise.

Le bon choix dépend surtout de votre capacité interne : équipe technique existante et volumes importants → cloud ou auto-hébergement ; besoin de rapidité et absence d'équipe infra → service managé, quitte à migrer plus tard.

Étapes de mise en place

1. Cartographier l'existant. Recenser les balises et plateformes actuellement en client-side (GA4, Ads, Meta, LinkedIn, CRM) et les événements du plan de marquage e-commerce concernés (vue produit, ajout panier, achat…). Voir notre article dédié au tracking e-commerce pour la structuration de ces événements.
2. Choisir l'infrastructure d'hébergement du conteneur serveur, selon les trois familles décrites plus haut.
3. Configurer le domaine first-party dédié à la collecte, avec le certificat et le DNS associés.
4. Déployer le conteneur serveur et le connecter au conteneur GTM web existant via le client GA4 côté serveur.
5. Migrer les intégrations une par une (GA4 d'abord, puis Meta CAPI, puis les autres), plutôt qu'un basculement global : cela permet de comparer les volumes client-side et server-side pendant une phase de recouvrement, et de détecter les écarts avant coupure définitive.
6. Vérifier la persistance du consentement dans la nouvelle architecture : le conteneur serveur doit continuer de recevoir et respecter le statut de consentement transmis par le navigateur.
7. Mettre en place le monitoring : un conteneur serveur qui tombe en silence prive tout le tracking de données, sans qu'aucune alerte visuelle n'apparaisse sur le site — l'un des risques spécifiques à cette architecture.

Erreurs fréquentes

• Oublier la déduplication entre l'événement client-side (souvent maintenu en parallèle pour GA4) et celui envoyé en server-side : sans identifiant d'événement partagé, les plateformes comptent parfois deux fois la même conversion.
• Négliger le monitoring applicatif du conteneur serveur, qui devient un composant d'infrastructure à part entière, avec ses propres pannes possibles.
• Croire que le server-side dispense du consentement, ce qui expose à un risque de conformité RGPD plus grand qu'en client-side, puisque l'architecture est aussi plus opaque à auditer.
• Sous-estimer la charge de maintenance : un conteneur serveur nécessite des mises à jour régulières et une vigilance sur les évolutions d'API des plateformes tierces (Google, Meta modifient périodiquement leurs API de conversion serveur).

Quand la mise en place vaut le coût

Le tracking server-side n'est pas systématiquement le bon investissement pour tous les sites. Trois signaux indiquent qu'il devient pertinent.

En ordre de grandeur d'effort — sans donner de tarif précis, qui dépend fortement du nombre de plateformes à migrer et du niveau de personnalisation souhaité — la mise en place d'une architecture server-side de base (un conteneur, deux à trois plateformes migrées) est un projet de plusieurs semaines, mobilisant à la fois une compétence marketing (plan de marquage, paramétrage GTM) et une compétence technique (infrastructure, monitoring, intégration backend si auto-hébergement). Ce n'est pas un projet d'après-midi, mais ce n'est pas non plus une refonte de site : c'est un chantier d'infrastructure de mesure.

Si votre organisation dispose déjà d'une équipe capable de suivre ce chantier dans la durée, le tracking server-side est un investissement solide. Si ce n'est pas le cas, un accompagnement externe qui couvre à la fois la partie marketing et la partie infrastructure a du sens — c'est le type de configuration que couvre notre accompagnement en tracking web, du plan de marquage jusqu'à l'hébergement des briques techniques.

FAQ sur le tracking server-side