Paul Le server-side consiste à faire transiter vos événements par un serveur que vous contrôlez, au lieu de les envoyer directement du navigateur vers Google, Meta ou TikTok. Le navigateur parle à votre serveur, votre serveur parle aux plateformes.
C'est une bonne idée dans plusieurs situations, et une dépense inutile dans d'autres. La différence tient à votre volume et à la nature de votre activité, pas à la mode du moment.
Ce que c'est, concrètement
Un conteneur Tag Manager tourne sur un serveur, généralement chez Stape ou sur votre propre infrastructure Google Cloud, accessible via un sous-domaine de votre site. Les balises que vous aviez côté navigateur sont déplacées vers ce conteneur, qui reçoit les événements et les redistribue.
Point important : le server-side ne dispense pas du consentement. Envoyer des données depuis un serveur ne rend pas légal ce qui ne l'était pas depuis le navigateur. Le mécanisme de consentement doit être respecté de la même façon.
Ce que ça apporte réellement
- Des cookies plus durables. Un cookie déposé par votre propre sous-domaine résiste mieux aux limitations imposées aux cookies tiers, notamment sur Safari. C'est le bénéfice le plus tangible, surtout sur les cycles d'achat longs
- Une résistance aux bloqueurs. Les requêtes partent vers votre domaine, non vers un domaine publicitaire connu. On récupère typiquement 5 à 15 % d'événements supplémentaires
- Un enrichissement centralisé. Vous pouvez compléter les événements avec des données issues de votre back-office, par exemple la marge réelle ou le statut d'un client, avant envoi aux plateformes
- Une page plus légère. Moins de scripts tiers exécutés dans le navigateur, donc un gain sur les temps de chargement
- Un point de contrôle unique. Vous décidez quelles données partent vers quelle plateforme, ce qui simplifie la mise en conformité
Ce que ça ne règle pas
Le server-side ne répare pas un tracking mal conçu, il le déplace. Si vos événements navigateur sont incomplets, si vos valeurs sont fausses ou si votre dataLayer est approximatif, vous obtiendrez exactement les mêmes problèmes, avec une couche d'infrastructure en plus et un débogage plus difficile.
Il ne dispense pas non plus du consentement, ne remplace pas la connexion au CRM et ne récupère pas les données des visiteurs qui ont explicitement refusé.
Le coût réel
Trois postes, dont un seul est visible :
- L'hébergement : de quelques dizaines à quelques centaines d'euros par mois selon le volume de requêtes
- La mise en place : c'est le poste principal, entre la migration des balises, les tests et la période de validation en parallèle
- La maintenance : une configuration server-side est moins lisible qu'un conteneur navigateur, et demande quelqu'un capable d'intervenir quand un événement cesse de remonter
La règle de décision
Ce que je conseille en pratique :
- Cela vaut le coup si vous dépensez plusieurs milliers d'euros par mois en publicité, si votre part de trafic Safari et mobile est élevée, si votre cycle d'achat dépasse quelques jours, ou si vous avez besoin d'enrichir vos conversions avec des données internes
- C'est prématuré si votre tracking navigateur n'est pas encore fiable, si votre budget publicitaire est inférieur à quelques milliers d'euros mensuels, ou si personne ne pourra maintenir l'installation
Dans le doute, commencez par fiabiliser la couche navigateur et par connecter votre CRM. Ces deux chantiers produisent presque toujours plus de valeur qu'une migration server-side, et ils sont de toute façon un prérequis.