Tracking server-side vs client-side : quelle approche ?
Server-side vs client-side tracking : ad blockers, qualité des données, coût et privacy. Guide pour choisir la bonne architecture de collecte.
Deux architectures de collecte fondamentalement différentes
Le tracking client-side est le modèle historique du web analytics : un script JavaScript s’exécute dans le navigateur de l’utilisateur, collecte les données d’interaction et les envoie directement aux plateformes analytics et marketing (Google Analytics, Facebook, etc.). C’est simple, éprouvé, et c’est ainsi que fonctionne la grande majorité des sites aujourd’hui.
Le tracking server-side déporte cette logique côté serveur. Le navigateur envoie les données à un endpoint que vous contrôlez (votre propre serveur ou un service cloud), et c’est ce serveur qui redistribue les données vers les destinations finales. Le navigateur ne communique jamais directement avec les serveurs tiers.
Cette différence architecturale a des implications profondes sur la qualité des données, la conformité, les performances et le coût.
Impact sur la qualité des données
Le tracking client-side est aujourd’hui sérieusement dégradé. Les ad blockers (utilisés par 30 à 40 % des internautes selon les secteurs) bloquent les scripts de collecte. Les navigateurs imposent des restrictions croissantes : Intelligent Tracking Prevention (Safari) limite les cookies first-party à 7 jours, Firefox Enhanced Tracking Protection bloque les trackers connus, et Chrome prévoit des restrictions similaires.
Le résultat concret : un site qui s’appuie uniquement sur du client-side perd une part significative de ses données. Les parcours utilisateurs sont fragmentés, l’attribution est faussée, et les volumes reportés sous-estiment la réalité.
Le server-side contourne la majorité de ces obstacles. Les requêtes partent vers votre propre domaine (first-party), ce qui les rend invisibles aux ad blockers. Les cookies sont posés par le serveur (server-set cookies), échappant aux limitations ITP. Le taux de collecte peut augmenter de 15 à 30 % selon les audiences.
| Critère | Client-side | Server-side |
|---|---|---|
| Blocage ad blockers | Vulnérable (30-40 % de perte) | Contourné (domaine first-party) |
| Restrictions ITP/ETP | Cookies limités à 7 jours | Cookies server-set (pas de limite ITP) |
| Temps de chargement | Scripts tiers = poids page | Allégé (un seul endpoint) |
| Contrôle des données | Données envoyées directement aux tiers | Filtrage et enrichissement côté serveur |
| Coût d’infrastructure | Nul | Serveur(s) à provisionner |
| Complexité technique | Faible (copier-coller de tags) | Élevée (infra, mapping, monitoring) |
| Debugging | DevTools navigateur | Logs serveur, plus complexe |
| Latence données | Temps réel | Quasi temps réel (ajout d’un hop) |
Privacy et conformité
Le server-side offre un avantage structurel en matière de protection des données. Puisque toutes les requêtes transitent par votre serveur, vous pouvez filtrer, anonymiser ou supprimer des données avant qu’elles n’atteignent les plateformes tierces. Vous pouvez retirer les adresses IP, tronquer les identifiants, ou conditionner l’envoi de données au statut de consentement de l’utilisateur.
En client-side, une fois le script chargé, vous n’avez qu’un contrôle limité sur ce que le tag collecte réellement. Les pixels Facebook ou TikTok, par exemple, captent des signaux (URL, user agent, adresse IP) que vous ne maîtrisez pas entièrement.
Ce contrôle accru du server-side ne signifie pas qu’il dispense du consentement. La CNIL considère que le dépôt de cookies et la collecte de données personnelles nécessitent un consentement, quelle que soit l’architecture technique. Mais le server-side facilite la mise en conformité en offrant un point de contrôle centralisé.
Coût et complexité réels
Le principal frein au server-side est son coût. Un conteneur GTM Server-Side sur Google Cloud coûte entre 50 et 500 euros par mois selon le trafic, sans compter le temps de configuration et de maintenance. Des solutions managées comme Addingwell ou Stape simplifient le déploiement mais ajoutent un abonnement mensuel (à partir de 30 à 100 euros par mois).
Au-delà de l’infrastructure, il faut compter le temps de configuration : mapper chaque tag client-side vers son équivalent server-side, configurer les clients et les tags du conteneur serveur, tester les flux de données, et monitorer en continu. Un projet de migration server-side complet représente généralement entre 5 et 15 jours de prestation pour un consultant.
Quelle approche choisir ?
Le client-side reste pertinent pour les sites à faible enjeu data, les projets avec un budget limité, ou les cas où les ad blockers ne sont pas un problème significatif (audiences professionnelles sur desktop, par exemple).
Le server-side se justifie quand la qualité des données est critique : sites e-commerce avec des budgets média importants, entreprises dont l’attribution marketing pilote des investissements significatifs, ou organisations avec des exigences de conformité avancées.
L’approche la plus courante aujourd’hui est hybride : un conteneur client-side pour la collecte initiale et un conteneur server-side pour le traitement et la redistribution. C’est le modèle promu par Google avec GTM Server-Side, et c’est celui qui offre le meilleur compromis entre qualité de données, conformité et coût maîtrisé.