- Data
Table des matières
- Qu’est-ce que le Tracking Server-Side ?
- Quels sont les avantages du Tracking Server-Side ?
- Revivez notre retour d'expérience du déploiement de Matomo en full Server-Side
- Quelles obligations en matière de RGPD ?
- Quelles solutions et infrastructures techniques sont compatibles avec le Server-Side ?
- Comment déployer concrètement une architecture Tracking Server-Side ?
- En conclusion, quelle démarche adopter avec le Server-Side ?
Table des matières
- Qu’est-ce que le Tracking Server-Side ?
- Quels sont les avantages du Tracking Server-Side ?
- Revivez notre retour d'expérience du déploiement de Matomo en full Server-Side
- Quelles obligations en matière de RGPD ?
- Quelles solutions et infrastructures techniques sont compatibles avec le Server-Side ?
- Comment déployer concrètement une architecture Tracking Server-Side ?
- En conclusion, quelle démarche adopter avec le Server-Side ?
Face aux restrictions croissantes des navigateurs, à la fin annoncée des cookies tiers et aux exigences du RGPD, le tracking server-side s’impose comme la solution incontournable pour une collecte de données plus fiable. En offrant un contrôle total sur les flux de données, cette approche permet d’optimiser la mesure des performances digitales.
Nous faisons le point sur les applications et bonnes pratiques du tracking en server-side en 2025.
Qu’est-ce que le Tracking Server-Side ?
Le Tracking Server-Side (suivi côté serveur) désigne le fait de collecter les données de navigation d’un utilisateur en faisant transiter ces informations directement par un serveur propriétaire avant de les envoyer aux plateformes de destination (outil analytics, régie publicitaire, CRM, etc.). Autrement dit, au lieu que le navigateur de l’internaute envoie les données de navigation directement aux serveurs des outils tiers (mode client-side classique), c’est votre serveur qui joue le rôle d’intermédiaire et transmet les données aux bons outils. Cela élimine les échanges directs entre le navigateur de l’utilisateur et les serveurs des solutions de tracking.
Tracking Server-Side vs Client-Side
Le tracking client-side (côté client) est le modèle historiquement dominant depuis les débuts de la pratique analytics. Il consiste à exécuter des scripts de suivi directement dans le navigateur de l’utilisateur (via des balises JavaScript insérées dans les pages web). Ces scripts envoient les données de navigation du navigateur vers les serveurs des outils analytics ou publicitaires. Ce modèle est facilement observable (les requêtes de tracking sont visibles dans la console du navigateur) et donc contrôlable par l’utilisateur ou des extensions de blocage. À l’inverse, le tracking server-side opère de manière invisible pour le navigateur (les échanges ont lieu entre serveurs), ce qui complique la détection externe de ces flux de données.
Différences entre le Tracking Client-Side et le Tracking Server-Side
Tagging Server-Side
Il existe des implémentations hybrides appelées tagging server-side. Par exemple, Google Tag Manager Server-Side propose un conteneur de tags côté serveur : lors du chargement d’une page, le navigateur de l’utilisateur envoie une requête vers un serveur intermédiaire (votre conteneur GTM côté serveur), qui va ensuite traiter et dispatcher les données vers les différentes plateformes (analytics, publicité, etc.)
On reste donc dans un modèle serveur-à-serveur pour la transmission finale des données, tout en utilisant un Tag Management System (TMS) pour simplifier la gestion des tags. Si vous souhaitez explorer cette approche plus en détail, notre agence GTM vous accompagne dans la mise en place et l’optimisation de ces solutions hybrides.
Pourquoi ce changement de paradigme ?
En mode client-side classique, chaque tag tiers (Google Analytics, Facebook Pixel, etc.) exécute du code sur le navigateur et dépose des cookies souvent tiers. Ces requêtes et cookies sont de plus en plus bloqués : par les navigateurs (Safari avec ITP depuis 2017, Firefox ETP, et bientôt Chrome), par des extensions anti-tracking.
Résultat : les données recueillies en client-side deviennent partielles et moins fiables.
Quels sont les avantages du Tracking Server-Side ?
Améliorer la qualité des données collectées
Les adblockers (près de 44% des internautes français en seraient équipés !), les fonctionnalités ITP (l’Intelligent Tracking Prevention est une fonctionnalité par Apple sur son navigateur Safari pour limiter le suivi des utilisateurs à l’aide de cookies. ) et autres méthodes de barrage du tracking bloquent généralement les requêtes depuis un navigateur vers un serveur externe. Ainsi, les données des internautes qui en sont équipés sont retenues dans le navigateur et ne sont jamais transmises au serveur de tracking, d’où des données analytiques incomplètes à l’échelle globale.
Dans un modèle Server-Side, comme le navigateur est incapable de repérer une connexion entre deux serveurs distants (votre serveur web et le serveur de tracking) ces systèmes de protection ne peuvent opérer.
Concrètement, les données de l’utilisateur sont transmises de votre serveur web au serveur de tracking visé, sans déclencher les filtres du navigateur. Moins de données sont perdues : on estime que le server-side peut permettre de collecter en moyenne +10 % à +30 % de données en plus par rapport au tout client-side
Par exemple, l’implémentation d’une solution analytics full server-side (sans aucune balise côté client) que nous avons réalisée pour le site Clubic a permis de récupérer un volume inestimable de données auparavant bloquées par les navigateurs, améliorant fortement la fiabilité des analyses.
De même, en conservant les données de suivi dans un cookie first-party déposé par votre domaine (au lieu d’un cookie tiers), le server-side permet de prolonger la durée de vie des identifiants utilisateur. On peut ainsi suivre un même visiteur sur une plus longue période malgré les restrictions ITP ou la fin des cookies tiers
Cette continuité des données réduit les écarts entre vos chiffres analytics et vos données back-office (ventes, chiffre d’affaires…), à condition bien sûr de rester conforme au RGPD (consentement utilisateur préalable) ou d’utiliser uniquement des données agrégées anonymes lorsque c’est possible.
Revivez notre retour d'expérience du déploiement de Matomo en full Server-Side
Enrichir les données collectées
Le serveur intermédiaire peut jouer le rôle de chef d’orchestre en combinant plusieurs sources de données avant envoi.
Par exemple, lors d’une conversion, il est possible d’associer des informations issues de votre CRM (ex. segment client, score, identifiant offline) aux événements transmis aux plateformes publicitaires. Grâce à ce matching server-side, Facebook ou Google pourront faire le lien entre les conversions et vos clients existants via des identifiants hashés (email, téléphone) envoyés par le serveur.
Ce type d’enrichissement améliore le taux de correspondance entre vos visiteurs et les bases des régies, ce qui peut affiner le retargeting ou la création d’audiences similaires, tout en restant dans un cadre sécurisé (les données sensibles ne sont pas exposées dans le navigateur).
L’enrichissement des données collectées avec les informations de marge permet d’orienter les algorithmes publicitaires vers les emplacements générant le meilleur ROI.
Augmenter la performance des campagnes publicitaires
Les grandes plateformes publicitaires poussent aujourd’hui à l’adoption du tracking server-to-server pour fiabiliser la mesure des conversions. Des solutions Conversion API (CAPI) ont été déployées par Facebook/Meta, Google Ads (via Google Tag Manager Server-Side ou l’API de mesure de conversions), Pinterest, Snapchat, TikTok, LinkedIn, etc., afin de doubler le tracking client par un envoi côté serveur des événements de conversion.
L’objectif est d’améliorer la remontée des données de conversion même lorsque le parcours utilisateur est partiellement masqué (par exemple si l’utilisateur a un adblocker ou refuse les cookies publicitaires).
En capturant davantage de conversions et de signaux via le serveur, on alimente mieux les algorithmes publicitaires. Ces derniers disposent de plus d’informations pour optimiser la diffusion des annonces. On observe ainsi des campagnes plus performantes grâce au server-side : meilleur ciblage des audiences (enrichi par plus de données comportementales), dispositifs de remarketing plus fournis, et rapports de performance plus complets sur le nombre de conversions réellement attribuées aux publicités.
Par exemple, le déploiement de la Meta Conversion API chez un annonceur a pu augmenter de 15 % le nombre de conversions tracées sur Facebook Ads par rapport au seul tracking pixel, permettant d’ajuster les investissements avec davantage de confiance. Dans l’ensemble, qui dit données publicitaires plus fiables dit coûts d’acquisition mieux maîtrisés.
Etude de cas
Résultats du déploiement de Meta CAPI
Enfin, la disparition progressive des cookies tiers renforce l’importance de ces approches first-party. Les conversions envoyées via un serveur s’appuient sur des cookies propriétaires et des identifiants hashés (emails, téléphones) fournis avec consentement, ce qui restera possible même quand les cookies tiers auront disparu. C’est d’ailleurs le principal argument derrière ces évolutions poussées par les régies : préparer un écosystème où la mesure des campagnes repose sur des données first-party bien maîtrisées.
WEBINAR
5 cas d’usages des données 1st party pour ses campagnes Paid
- Juliette Giovansili, Team Leader SEA
- Sylvain Rouxel, Expert Analytics
Améliorer les performances d’un site web
Plus on ajoute de tags tiers (services analytics, régies publicitaires, réseaux sociaux, etc) dans le code de source d’une page, plus on affecte potentiellement leur temps de chargement. Avec le Server-Side, le tracking passe uniquement par des serveurs, ce qui permet de réduire la charge côté client et garantit donc un temps de chargement plus rapide.
Exemple : si vous intégrez sur votre site 7 tags de solutions tierces, alors en mode Client-Side, vous générez 7 requêtes du navigateur de l’utilisateur vers les serveurs des acteurs tiers. En mode Server-Side, vous n’avez plus qu’une seule requête mutualisée car la répartition des données se fait depuis le serveur web.
De plus, si vous réduisez le nombre de balises, vous diminuez les risques de bugs d’affichage et autres dysfonctionnements techniques qui peuvent impacter à terme l’expérience utilisateur.
Renforcer le contrôle et la sécurité des données
En mode server-side, toutes les données de tracking transitent par un serveur qui vous appartient (ou que vous contrôlez étroitement). Cela présente un grand avantage en termes de sécurité et gouvernance de la donnée. Vous maîtrisez de A à Z quelles données sont collectées et ce qu’elles deviennent.
Il est possible de filtrer, anonymiser ou transformer les informations avant de les envoyer aux plateformes tierces. Cela permet d’éviter des fuites de données personnelles involontaires vers des acteurs tiers, et de bloquer tout script tiers potentiellement malveillant qui tenterait de collecter des informations à votre insu.
En somme, vous interposez un bouclier technique entre le navigateur de l’utilisateur et les multiples récepteurs de données.
Ce passage par votre serveur vous permet aussi de standardiser les données envoyées aux différentes plateformes. Vous pouvez par exemple uniformiser les identifiants, nettoyer les paramètres d’URL, enrichir les events avec des données serveur, etc., avant envoi. Ceci facilite grandement les rapprochements et comparaisons entre les données de sources différentes, puisque chaque outil reçoit des données cohérentes et harmonisées depuis votre serveur.
Enfin, ce contrôle accru vous aide à mieux respecter la conformité : par exemple, vous pouvez vous assurer qu’aucune donnée personnelle non autorisée (email en clair, IP complète, etc.) n’est transmise à un outil donné. En cas d’audit, il est plus simple de démontrer ce qui est collecté ou non, car tout transit passe par votre infrastructure.
Besoin d'un accompagnement Server-Side ?
Contactez nos experts !
Quelles obligations en matière de RGPD ?
Passer vos tags côté serveur ne vous dispense pas de respecter les lois sur la protection de la vie privée. Il est crucial d’intégrer le cadre réglementaire (RGPD, directives ePrivacy, recommandations de la CNIL) dès la conception de votre tracking server-side.
Le RGPD et la réglementation ePrivacy exigent d’obtenir le consentement préalable de l’utilisateur pour tout dépôt ou lecture de traceur non strictement nécessaire au service (ce qui inclut la majorité des cookies analytics et ads). Un tracking server-side implique généralement de déposer des cookies first-party ou d’exploiter des identifiants de l’utilisateur, il est donc soumis aux mêmes règles qu’un tracking classique. La CNIL a rappelé en 2020 dans ses lignes directrices cookies que le fait de router différemment les données ne change rien à l’obligation de consentement dès lors qu’il y a accès au terminal de l’utilisateur.
Autrement dit, serveur ou pas, vous devez informer l’utilisateur et recueillir son accord avant de tracer ses actions dès qu’on sort du périmètre des cookies purement techniques.
Notons que le caractère « invisible » du server-side (boîte noire côté navigateur) ne doit pas être un prétexte pour contourner la loi. Certes, il est plus difficile pour un régulateur ou un utilisateur lambda de détecter un suivi clandestin opérant sur un serveur distant.
Mais en cas de manquement, les sanctions seront tout aussi applicables. Un site qui collecterait des données personnelles via son serveur sans consentement s’expose aux mêmes risques juridiques que s’il le faisait en client-side.
En résumé, en 2025, le tracking server-side doit absolument s’inscrire dans une démarche Privacy by Design :
- Prévenez clairement l’utilisateur (via votre politique de confidentialité et votre CMP) que vous collectez des données côté serveur.
- Obtenez son consentement avant d’activer tout recueil de données non exempté.
- Conservez des preuves de consentement et de conformité (logs, paramètres de configuration) en cas de contrôle.
Utilisé correctement, le server-side peut même vous aider à mieux respecter la vie privée (en contrôlant ce qui est transmis aux tiers, en hébergeant les données en UE, etc.), mais il doit être manié avec éthique et transparence.
Quelles solutions et infrastructures techniques sont compatibles avec le Server-Side ?
Le tracking server-side s’est fortement démocratisé ces deux dernières années, avec de nouvelles solutions techniques et une adoption grandissante par l’industrie :
GTM Server-Side et consorts deviennent la norme
Google Tag Manager a lancé son conteneur server-side (en beta dès 2020, stable depuis 2021) pour faciliter l’adoption de ce modèle.
Désormais, la plupart des grands gestionnaires de tags proposent des offres similaires. Par exemple, Commanders Act (ex-TagCommander) permet un déploiement server-side depuis de nombreuses années, en mode « full serveur » pour les plus techniques ou en mode hybride proche de GTM pour simplifier.
Tealium, Adobe et d’autres acteurs du TMS offrent également des solutions équivalentes. En pratique, les équipes marketing disposent aujourd’hui d’outils intégrés pour passer leurs tags en server-side sans tout réinventer.
Solutions “clé en main”
Pour les organisations ne disposant pas d’une expertise DevOps avancée, des solutions SaaS ont émergé afin de déployer une infrastructure server-side en quelques clics.
On peut citer Addingwell ou Stape (Managed Server-Side GTM) parmi les offres courantes, qui permettent de créer automatiquement l’environnement cloud (serveur de collecte, conteneur de tags) avec un minimum d’efforts techniques.
En quelques minutes, vous pouvez obtenir une plateforme prête à l’emploi que vos web analysts peuvent utiliser pour configurer les tags via l’interface GTM. Ce type de service gère l’hébergement, la maintenance et le monitoring des flux de tracking, offrant un gain de temps considérable.
À noter : Addingwell est souvent recommandé pour les sites à fort trafic (migration partielle ou complète), tandis que Stape est jugé suffisant pour des sites à trafic modéré ou une migration ciblée sur quelques tags (notamment médias).
Fin annoncée des cookies tiers et Privacy Sandbox
L’initiative Privacy Sandbox de Google (APIs Topics, FLEDGE, Attribution Reporting, etc.) vise à proposer des alternatives aux cookies tiers pour le ciblage publicitaire et la mesure des conversions.
Cependant, ces technologies sont encore en test et Google a plusieurs fois repoussé l’échéance de suppression totale des cookies tiers (désormais planifiée pour mi-2025 au lieu de 2024).
En attendant, les acteurs du marketing digital n’ont pas d’autre choix que de se tourner vers des solutions first-party. Le server-side s’inscrit comme une réponse immédiate pour traverser cette période de transition : il permet de continuer à collecter des données de manière fiable malgré la disparition progressive des cookies tiers, et de se préparer aux nouveaux mécanismes de la Privacy Sandbox. D’ailleurs, la CNIL elle-même souligne que les sites ont tout intérêt à tester et anticiper ces nouvelles solutions pendant la transition actuelle
eur devient un pilier de la stratégie “cookieless” en complément des APIs du navigateur.
Adaptation des outils analytics (GA4 et autres)
Juillet 2023 a marqué la fin de Google Analytics Universal (GA3) au profit de Google Analytics 4, une version repensée dans un contexte de privacy renforcée. GA4 propose nativement des mécanismes de collecte côté serveur via l’API Measurement Protocol, et s’intègre très bien avec GTM Server-Side. De plus, GA4 encourage l’utilisation de sources de données server-to-server (importations, BigQuery…) pour compléter les analyses.
De leur côté, des solutions alternatives à Google Analytics comme Matomo ou Piano Analytics offrent depuis longtemps la possibilité d’une implémentation full server-side, notamment pour les organisations souhaitant héberger elles-mêmes leurs données analytics. La transition vers GA4 a été pour beaucoup d’entreprises le moment opportun pour repenser leur architecture de tracking et envisager la collecte server-side dès la refonte du plan de marquage.
Inscription à la newsletter
Recevez nos dernières actualités
Comment déployer concrètement une architecture Tracking Server-Side ?
Sur le plan pratique, la mise en place d’un tracking côté serveur requiert une planification méthodique. Les approches peuvent varier (déployer un Tag Manager server-side ou développer un tracking full serveur fait maison), mais les grandes étapes du projet restent similaires. Voici un plan de migration type :
Audit de l’existant : Dressez l’inventaire de toutes les balises et solutions de tracking actuellement déployées sur votre site (analytics, conversion, pixels médias, etc.). Identifiez celles qu’il faudra migrer en priorité en server-side. Profitez-en pour éliminer les tags obsolètes ou redondants.
- Choix de l’infrastructure et des outils : Deux options s’offrent à vous :
– Solution Cloud “maison” : déployer par exemple un conteneur GTM Server-Side sur votre propre instance cloud (Google Cloud, AWS, Azure…). Cela nécessite de créer un ou plusieurs serveurs, d’y installer le conteneur et de le maintenir à jour.
– Solution clé en main : faire appel à un prestataire qui fournit l’infrastructure gérée (par ex. Addingwell, Stape ou l’offre server-side d’un TMS comme Commanders Act). En quelques clics, vous obtenez un serveur de tagging fonctionnel sans avoir à vous soucier de la configuration système. - Déploiement du TMS côté serveur : Si vous optez pour un Tag Manager (recommandé pour simplifier), installez et configurez votre conteneur server-side. Par exemple, avec GTM : créer le conteneur de type Server, spécifier le domaine de collecte (souvent un sous-domaine dédié de votre site, ex: analytics.votresite.com), puis lier ce conteneur à votre infrastructure (URL du serveur, clés d’API, etc.).
Assurez-vous que le conteneur est accessible et fonctionnel (endpoint de collecte prêt à recevoir des requêtes). - Adaptation du tracking côté client : Même en server-side, un minimum d’implémentation côté client est nécessaire pour initier la collecte. Vous devez modifier vos balises front (ou votre code source) afin qu’ils envoient les données vers votre serveur au lieu des serveurs tiers. Par exemple, remplacer l’appel direct à Google Analytics par un appel HTTP vers votre domaine server-side, qui jouera le rôle de proxy. Concrètement, cela peut passer par le déploiement d’un script fourni par le TMS server-side (ex: Google Tag Manager client spécifique qui envoie toutes les hits au serveur GTM). Dans le cas d’une migration full serveur (sans aucun JS client tiers), cela implique de développer en back-end l’émission des événements (via des requêtes serveur lors des actions utilisateur).
- Paramétrage des tags côté serveur : Dans l’interface de votre TMS server-side, reproduisez le plan de marquage en configurant des tags server équivalents. Par exemple, créez une balise “Google Analytics 4” côté serveur qui recevra les données entrantes et les enverra au endpoint GA4, une balise “Facebook CAPI” qui enverra les conversions à Facebook, etc. La plupart des TMS offrent des modèles prédéfinis pour les principaux outils (GA4, Google Ads, Meta, etc.) afin de faciliter cette étape.
Si vous aviez des déclencheurs/variables spécifiques, ajustez-les dans ce nouveau conteneur. En mode full serveur sans TMS, cette étape correspond à coder les appels API vers chaque plateforme (ce qui est plus long et complexe). - Tests et validation : Une fois le setup fait, il est crucial de tester en parallèle l’ancien tracking et le nouveau. Vérifiez que les données remontent correctement dans chaque outil (analytics et conversions) via le serveur. Comparez les résultats avec le tracking client-side initial pour vous assurer qu’aucune donnée importante n’a été perdue ou mal transmise. Une bonne pratique consiste à doubler temporairement le tracking (client + serveur) sur une portion du trafic, puis à comparer les rapports. Vous pourrez ainsi mesurer l’apport du server-side et ajuster les derniers paramètres. L’objectif est d’atteindre au moins l’équivalence des données, voire une amélioration (comme attendue en avantage).
- Basculer et optimiser : Lorsque les résultats sont concluants, vous pouvez progressivement désactiver les anciens tags client-side devenus redondants et passer en mode “server-side only” pour la collecte voulue. Surveillez les performances du serveur (charge, coûts) et la qualité des données dans le temps. Mettez en place un suivi des éventuelles erreurs de transmission (le monitoring inclus dans certaines solutions aidera). Pensez également à former votre équipe webanalyse aux nouveaux outils et processus, et documentez la configuration pour la maintenir à jour.
En suivant ces étapes, la migration peut se faire de façon structurée et maîtrisée. Bien sûr, chaque projet a ses spécificités : un passage complet en full serveur demandera plus de développements, là où une approche hybride via GTM est plus rapide. Il est conseillé de se faire accompagner par des experts (web analytics, cloud) pour éviter les écueils techniques et garantir la fiabilité du nouveau dispositif.
En conclusion, quelle démarche adopter avec le Server-Side ?
Nous vous recommandons de considérer le Tracking Server-Side comme une option solide pour fiabiliser, sécuriser vos flux de données et optimiser la performance de votre site web.
Néanmoins, n’oubliez pas de prendre en compte le coût associé à cette migration qui dépend énormément du volume de trafic du site.
Aussi, veillez à pouvoir mobiliser une équipe technique ultra-compétente pour installer l’infrastructure idoine et la monitorer.
Enfin, n’utilisez surtout pas le Server-Side comme prétexte de contournement du RGPD. Vous risqueriez de vous faire rattraper tôt ou tard par la patrouille !
Empirik peut vous accompagner dans vos réflexions sur votre stratégie Analytics et dans la migration de votre tracking vers une architecture Server-Side.
Besoin d'aide et de conseils en Tracking Server-Side ?
Contactez nos experts !
