TL;DR
Le server-side tagging déplace la collecte de données du navigateur de l'utilisateur vers un serveur que vous contrôlez. Cela permet de filtrer, anonymiser ou bloquer les données avant de les transmettre à des tiers (Google, Facebook, etc.), de contourner les bloqueurs de publicité et les restrictions des navigateurs (ITP Safari, fin des cookies tiers Chrome), et d'allonger la durée de vie des cookies first-party. Cependant, le server-side tagging ne supprime pas l'obligation de consentement : si vous collectez des données personnelles, le RGPD et la directive ePrivacy s'appliquent, que le tracking soit client-side ou server-side.
Qu'est-ce que le server-side tagging ?
Le server-side tagging est une méthode de collecte de données qui déplace l'exécution des tags (scripts de tracking) du navigateur de l'utilisateur vers un conteneur serveur géré par votre organisation. Au lieu que le navigateur de l'utilisateur envoie directement les données à Google Analytics, Facebook ou d'autres services tiers, les données transitent d'abord par votre serveur, qui décide ensuite quoi transmettre, à qui et sous quelle forme.
Dans le modèle client-side classique (le modèle dominant jusqu'à présent), chaque tag tiers est chargé dans le navigateur de l'utilisateur. Cela signifie que Google, Facebook et tous les autres services tiers reçoivent directement les données du navigateur, sans que vous puissiez contrôler précisément ce qui est transmis.
Avec le server-side tagging, le navigateur n'envoie les données qu'à votre serveur (généralement un sous-domaine de votre propre domaine, comme analytics.votresite.com). Votre serveur traite ensuite ces données et les redistribue aux services tiers via des connexions serveur-à-serveur. Cela vous donne un contrôle total sur les données qui quittent votre infrastructure.
Pourquoi le server-side tagging gagne du terrain en 2026 ?
Plusieurs facteurs convergent pour faire du server-side tagging le nouveau standard de collecte de données.
Les restrictions des navigateurs
Safari (ITP) limite les cookies posés par JavaScript à 7 jours et bloque les cookies tiers depuis 2020. Firefox Enhanced Tracking Protection bloque les scripts de tracking connus par défaut. Chrome a commencé à restreindre les cookies tiers en 2025. Ces restrictions réduisent la durée de vie et la fiabilité des cookies client-side, ce qui dégrade la qualité des données analytics et publicitaires.
Les bloqueurs de publicité
Plus de 40 % des audiences tech en Europe et en Amérique du Nord utilisent des bloqueurs de publicité. Ces outils bloquent les tags client-side (GTM, GA4, Meta Pixel) en se basant sur des listes de domaines connus. Le server-side tagging, déployé sur un sous-domaine first-party, est invisible pour ces bloqueurs car les requêtes semblent provenir de votre propre domaine.
Le contrôle des données
Le server-side tagging permet de filtrer, anonymiser ou supprimer des données avant de les envoyer à des tiers. Par exemple, vous pouvez supprimer l'adresse IP de l'utilisateur avant d'envoyer les données à Google Analytics, ou hasher les adresses e-mail avant de les transmettre à Facebook pour les conversions. Ce contrôle est un élément clé de la conformité RGPD (principe de minimisation des données).
Supprimer l'adresse IP ne règle pas pour autant toutes les questions posées par l'outil de Google, comme l'explique notre analyse sur la conformité de Google Analytics au RGPD.
La performance du site
Chaque tag client-side charge un script dans le navigateur, ce qui ralentit le chargement de la page. En déplaçant le traitement sur le serveur, le nombre de scripts dans le navigateur diminue, ce qui améliore la vitesse de chargement et, par extension, le SEO et l'expérience utilisateur.
Le server-side tagging supprime-t-il l'obligation de consentement ?
Non. C'est le mythe le plus répandu et le plus dangereux. Le server-side tagging ne supprime pas l'obligation de consentement au sens du RGPD et de la directive ePrivacy.
La directive ePrivacy (article 5(3), transposé par l'article 82 de la loi Informatique et Libertés en France) exige le consentement pour tout accès ou stockage d'information sur le terminal de l'utilisateur, sauf exception (cookies strictement nécessaires). Si votre implémentation server-side dépose des cookies first-party pour identifier les utilisateurs, le consentement est requis.
Le RGPD s'applique à tout traitement de données personnelles. Les adresses IP, les identifiants client, les user agents et d'autres informations transmises dans les requêtes HTTP sont des données personnelles au sens du RGPD. Même si vous supprimez les cookies, le simple fait de collecter et traiter ces données sur votre serveur constitue un traitement qui nécessite une base légale (consentement, intérêt légitime, etc.).
En résumé : le server-side tagging change le "où" et le "comment" de la collecte, pas le "si". Vous avez toujours besoin d'un bandeau cookies conforme et d'une CMP pour recueillir le consentement avant de collecter des données non essentielles.
Ce que le server-side tagging change réellement pour le consentement
Si le server-side tagging ne supprime pas l'obligation de consentement, il change significativement la manière dont le consentement est appliqué techniquement.
Application du consentement côté serveur
En mode client-side, le blocage des tags repose sur le navigateur : la CMP doit empêcher le chargement des scripts avant consentement. Si un script se charge malgré tout (erreur de configuration, timing, cache), le cookie est déposé. En mode server-side, le consentement peut être vérifié sur le serveur avant de transmettre les données aux tiers. Cela constitue une couche de vérification supplémentaire, plus fiable que le blocage client-side seul.
Filtrage et anonymisation des données
Le serveur peut supprimer ou anonymiser les données personnelles avant de les transmettre. Par exemple : supprimer l'adresse IP avant envoi à GA4, hasher les e-mails pour les API de conversion (Facebook CAPI, Google Enhanced Conversions), ou supprimer les paramètres d'URL contenant des identifiants personnels.
Côté Meta, notre guide sur le Meta Pixel, ses cookies et le RGPD explique comment bloquer le pixel jusqu'au consentement du visiteur.
Cookies first-party avec durée de vie allongée
Les cookies posés par le serveur (via des en-têtes HTTP Set-Cookie) ne sont pas soumis aux mêmes restrictions que les cookies posés par JavaScript. Safari ITP limite les cookies JavaScript à 7 jours, mais les cookies server-side (posés depuis un sous-domaine first-party) peuvent avoir une durée de vie plus longue. Cela améliore la qualité du suivi des visiteurs récurrents, mais ne change pas l'obligation de consentement pour ces cookies.
Comment intégrer le server-side tagging avec le Consent Mode ?
Le Consent Mode v2 fonctionne aussi bien en mode client-side qu'en mode server-side. Dans une architecture server-side, le flux est le suivant.
La CMP recueille le consentement côté client (dans le navigateur). L'état du consentement est transmis au conteneur serveur GTM avec chaque événement. Le conteneur serveur vérifie l'état du consentement avant de transmettre les données aux services tiers. Si le consentement est "denied", les données ne sont pas transmises (mode basic) ou sont transmises sous forme de pings anonymisés (mode advanced).
Pour la partie client, la documentation Consent Mode v2 de FlowConsent explique comment les valeurs par défaut sont fixées à « denied » avant le chargement de tout tag.
Cette architecture offre une double vérification : la CMP bloque les scripts côté client, et le serveur vérifie le consentement avant chaque transmission. C'est la configuration la plus robuste pour garantir que les données ne quittent pas votre infrastructure sans consentement.
Pour vérifier en pratique que les refus sont respectés, la vérification de conformité FlowConsent scanne vos pages en refusant le consentement et conserve la preuve.
Erreurs fréquentes (et comment les éviter)
Croire que le server-side tagging élimine le besoin de consentement. C'est faux. Le RGPD et la directive ePrivacy s'appliquent que le tracking soit client-side ou server-side. Correction : maintenez votre bannière de consentement et votre CMP, même avec une architecture server-side.
Utiliser le server-side tagging pour contourner les bloqueurs sans consentement. Déployer le tracking sur un sous-domaine first-party pour contourner les ad blockers est techniquement possible, mais si vous le faites sans consentement, vous collectez des données en violation du RGPD. Correction : le contournement des ad blockers n'est légal que pour les utilisateurs qui ont consenti.
Oublier que les cookies server-side nécessitent aussi un consentement. Un cookie déposé par un en-tête HTTP Set-Cookie depuis votre serveur est toujours un cookie au sens de la directive ePrivacy. S'il n'est pas strictement nécessaire, le consentement est requis. Correction : incluez les cookies server-side dans votre politique de cookies et dans la configuration de votre CMP.
Ne pas auditer les données transmises par le serveur. Le server-side tagging vous donne le contrôle, mais ce contrôle est inutile si vous ne vérifiez pas ce qui est réellement transmis. Correction : auditez régulièrement les flux de données sortants de votre conteneur serveur pour vérifier que les données personnelles sont bien filtrées ou anonymisées.
Côté navigateur, un audit complet des cookies de votre site reste le point de départ pour lister ce qui est réellement déposé chez vos visiteurs.
Sous-estimer la complexité technique. Le server-side tagging nécessite un serveur (généralement Google Cloud Run ou AWS), une configuration DNS (sous-domaine first-party), et une maintenance continue. Ce n'est pas un plugin qu'on installe en un clic. Correction : prévoyez les ressources techniques nécessaires ou faites appel à un prestataire spécialisé.
Penser que le server-side résout le problème des données manquantes. Le server-side tagging améliore la couverture (moins de blocage par les ad blockers, cookies plus durables), mais les utilisateurs qui refusent le consentement restent invisibles. Correction : combinez le server-side tagging avec le taux de consentement optimisé et le conversion modeling pour maximiser la couverture.
Checklist : server-side tagging et conformité cookies
- La bannière de consentement est maintenue même avec une architecture server-side.
- L'état du consentement est transmis du client au conteneur serveur avec chaque événement.
- Le conteneur serveur vérifie l'état du consentement avant toute transmission aux tiers.
- Les cookies server-side (first-party) sont déclarés dans la politique de cookies.
- Les données personnelles (IP, e-mail, identifiants) sont filtrées ou anonymisées sur le serveur avant envoi aux tiers.
- Le sous-domaine first-party est configuré (ex: analytics.votresite.com) avec les enregistrements DNS corrects.
- Le Consent Mode v2 est implémenté et ses signaux sont propagés au conteneur serveur.
- Un audit de cookies confirme que les cookies non essentiels ne sont pas déposés avant consentement, y compris les cookies server-side.
- Les flux de données sortants du serveur sont audités régulièrement.
- La documentation technique de l'architecture est à jour dans le registre des traitements.
Conclusion
Le server-side tagging est une évolution majeure de la collecte de données qui offre un meilleur contrôle, une meilleure résilience face aux restrictions des navigateurs et des ad blockers, et une meilleure capacité de filtrage des données personnelles. Mais il ne change pas les règles fondamentales du consentement : le RGPD et la directive ePrivacy s'appliquent que le tracking soit client-side ou server-side.
L'architecture idéale combine le server-side tagging avec une CMP conforme et le Consent Mode v2 pour garantir que le consentement est vérifié à la fois côté client et côté serveur. C'est la configuration la plus robuste pour concilier conformité et qualité des données.
Pour vérifier que votre site ne dépose pas de cookies avant consentement, y compris les cookies server-side, lancez un scan gratuit avec FlowConsent.