Il y a un moment, dans à peu près toutes les discussions sur le tracking, où quelqu'un lâche « il faudrait passer en server-side ». Souvent sans très bien savoir ce que ça implique, et parfois pour un site qui reçoit trois cents visites par mois.
J'ai travaillé pendant plusieurs années sur du tracking où le server-to-server faisait partie du quotidien, sur des volumes qui le justifiaient largement. Et j'ai aussi vu des projets où c'était une complication pure, ajoutée parce que c'était le sujet du moment.
Alors voilà ce que ça résout réellement, ce que ça coûte, et comment décider.
Aujourd'hui, sur la majorité des sites, tout se joue dans le navigateur. Le visiteur charge la page, les scripts de mesure se chargent avec elle, ils lisent ou écrivent des cookies, et ils envoient directement leurs requêtes vers Google, Meta ou qui que ce soit d'autre.
Votre serveur n'est jamais au courant. Il a livré une page HTML, et c'est tout. Toute la chaîne de mesure se déroule chez le visiteur, entre son navigateur et des serveurs tiers.
Ce modèle a bien fonctionné pendant quinze ans. Il s'effrite pour trois raisons qui s'additionnent.
Les navigateurs limitent la durée de vie des cookies posés par du JavaScript, parfois à quelques jours seulement. Les bloqueurs de publicité empêchent une partie des scripts de se charger, avec des taux qui montent très haut sur certaines audiences techniques. Et les visiteurs refusent le suivi plus souvent qu'avant.
Résultat : une partie de vos données n'arrive jamais. Pas parce que votre configuration est mauvaise, mais parce que le chemin lui-même est devenu fragile.
Le principe est simple à énoncer. Au lieu que le navigateur parle directement aux plateformes, il parle à un serveur que vous contrôlez. Et c'est ce serveur qui relaie vers les plateformes.
Classique : navigateur → Google / Meta / autres
Server-side : navigateur → votre serveur → Google / Meta / autres
Ce déplacement change plusieurs choses d'un coup.
La requête part maintenant vers votre propre domaine, souvent un sous-domaine du site. Pour un bloqueur, c'est beaucoup moins évidemment identifiable qu'un appel vers un domaine publicitaire connu. Les cookies posés par votre serveur ne sont plus soumis aux mêmes limites de durée que ceux posés en JavaScript. Et surtout, vous reprenez la main sur ce qui est transmis : vous pouvez filtrer, enrichir ou anonymiser avant l'envoi, ce qui est impossible quand le navigateur parle directement à un tiers.
Ce dernier point est celui qu'on cite le moins et c'est pourtant le plus solide. Vous savez exactement quelle donnée sort de chez vous.
Il existe une situation où la question ne se pose même pas : quand la conversion n'a pas lieu dans le navigateur.
Prenez un site qui génère des demandes de devis. Le visiteur remplit un formulaire, vous recevez la demande, et deux jours plus tard le commercial qualifie le lead au téléphone. Certains sont sérieux, d'autres non.
En tracking classique, vous remontez la soumission du formulaire. Toutes les soumissions se valent, y compris les faux numéros et les curieux. Vos campagnes s'optimisent donc vers le volume de formulaires, pas vers la qualité des clients.
Avec une remontée côté serveur, vous pouvez envoyer la conversion au moment où le lead est qualifié, depuis votre CRM, avec sa vraie valeur. Les plateformes optimisent alors vers ce qui produit des clients réels.
C'est la différence la plus rentable que j'aie vue en tracking, et elle n'a rien à voir avec les cookies ou les bloqueurs. Elle vient du fait que la donnée intéressante n'existe tout simplement pas dans le navigateur.
Le même raisonnement vaut pour un e-commerce avec beaucoup de retours, un abonnement qui se confirme après une période d'essai, ou une prise de rendez-vous qui peut être annulée.
C'est la partie que les articles enthousiastes passent sous silence.
Il y a un serveur à faire tourner, en permanence, avec ce que ça implique de coût mensuel et de maintenance. Il y a un sous-domaine à configurer, avec son certificat. Il y a une configuration en double à maintenir, parce qu'en pratique on garde souvent une partie côté navigateur. Et il y a le débogage, qui devient franchement moins confortable : le mode prévisualisation de GTM montre ce qui se passe dans le navigateur, mais pour voir ce que fait votre serveur, il faut aller lire ses logs.
Ajoutez à ça que vous devenez responsable de la disponibilité de la chaîne. Si votre serveur de tracking tombe un samedi soir, vous perdez les conversions du week-end, et personne ne vous préviendra.
Ce n'est pas une raison de renoncer. C'est une raison de ne pas s'y lancer pour un site vitrine avec un formulaire de contact.
Je me pose trois questions, dans cet ordre.
Est-ce que la donnée qui m'intéresse existe dans le navigateur ? Si la vraie conversion se produit ailleurs, dans un CRM, après un appel, après un délai de rétractation, alors le server-side n'est pas une optimisation, c'est la seule manière de remonter l'information juste. C'est le critère le plus fort.
Est-ce que je dépense assez pour que l'écart compte ? Récupérer quelques pourcents de signal sur un budget publicitaire de deux cents francs par mois ne paiera jamais le serveur. Sur plusieurs milliers, le calcul change complètement.
Est-ce que mon tracking classique est déjà propre ? Et c'est la question qui tranche le plus souvent. Passer en server-side un tracking qui compte déjà les conversions en double ne fait pas disparaître les doublons, ça les déplace. J'ai vu plusieurs projets vouloir sauter cette étape, et à chaque fois il a fallu y revenir.
Si les trois réponses sont oui, la bascule se justifie. Si la troisième est non, il y a un travail plus simple et plus rentable à faire avant.
Entre le tout navigateur et une infrastructure serveur complète, il existe une option que je recommande souvent et dont on parle peu : envoyer les conversions importantes directement depuis votre back-end vers les API de conversion des plateformes, sans monter de serveur de tracking dédié.
Concrètement, quand votre application enregistre une commande ou qualifie un lead, elle appelle l'API de la plateforme avec les informations de la conversion. Une requête HTTP, dans le code que vous maîtrisez déjà.
Vous ne récupérez pas tous les bénéfices d'une vraie infrastructure server-side, notamment sur la durée de vie des cookies. Mais vous récupérez l'essentiel, c'est-à-dire des conversions fiables qui ne dépendent ni d'un bloqueur ni du navigateur, avec leur vraie valeur. Et vous n'avez pas de serveur supplémentaire à maintenir.
Pour la grande majorité des PME avec lesquelles je travaille, c'est le bon compromis. Le server-side complet garde son intérêt quand les volumes et les budgets le justifient.
Le tracking server-side est un vrai outil, pas une mode, mais il répond à un problème précis. Si votre conversion réelle se produit hors du navigateur, il devient rapidement indispensable. Si vous cherchez juste à récupérer un peu de signal perdu, commencez par vérifier que ce qui remonte aujourd'hui est correct.
Dans les deux cas, la question à se poser en premier n'est pas technique. C'est : quelle est la donnée que je devrais mesurer et que je ne mesure pas ? La réponse indique presque toujours quoi faire.
Besoin d'aide ?
Clics, scroll, temps de lecture, abandon de formulaire : comment j'ai mis en place un tracking précis sur ce site avec @vercel/analytics en quelques dizaines de lignes.
X-Frame-Options, CSP, HSTS, Permissions-Policy : comment configurer les headers de sécurité HTTP sur Next.js en 2026 et vérifier le résultat sur securityheaders.com.
