En deux mots : le tracking server-side, c’est envoyer les données depuis votre serveur, et plus seulement depuis le navigateur du visiteur. On y gagne une mesure plus fiable, moins à la merci des bloqueurs et des navigateurs, à condition de bien le poser. Je vous explique ce que ça change vraiment pour une TPE ou une PME, et surtout quand ça vaut le coup.
Le tracking, à quoi ça sert vraiment ?
Pour optimiser vos campagnes, l’algorithme de Google a besoin de savoir quelles pubs génèrent des ventes ou des demandes. Chaque conversion (un achat, un formulaire rempli, un appel) lui sert à aller chercher d’autres personnes qui ressemblent à vos clients. Si cette info est incomplète ou fausse, Google optimise à l’aveugle et votre budget file au mauvais endroit. En clair : la qualité de votre tracking pèse directement sur la rentabilité de vos campagnes. C’est pour ça que je commence presque toujours une mission par là.
Le tracking classique (client-side) montre ses limites
Historiquement, la mesure passe par un script posé dans le navigateur du visiteur. Ce fonctionnement, le client-side, prend l’eau depuis quelques années : bloqueurs de pub, restrictions de Safari et d’iOS qui raccourcissent la durée de vie des cookies, extensions de confidentialité, refus de consentement (RGPD). Résultat, une part parfois importante de vos conversions ne remonte plus jusqu’à Google, ou alors vous perdez l’attribution. Vous faites peut-être plus de ventes que ce que votre compte affiche, mais Google l’ignore, donc il optimise moins bien.
Attention, je ne dis pas que le client-side est mort. Passer au server-side doit répondre à un constat business, pas à un effet de mode. Deux questions que je me pose systématiquement : est-ce que mes conversions se jouent surtout pendant la session de découverte (ce qui peut arriver en génération de leads par exemple) ? Et est-ce que la part de trafic Safari est négligeable, disons en dessous de 40 % dans GA4 ? Si c’est oui aux deux, on peut souvent attendre.
À noter : avec la bascule de la recherche vers l’IA et le zero-click, une partie des conversions remonte encore moins bien qu’avant. Raison de plus pour fiabiliser la mesure. J’en parle dans IA Mode et Google Ads.
Le server-side : la donnée passe par votre serveur
Avec le server-side, les événements de conversion transitent par un serveur intermédiaire (le plus souvent un conteneur Google Tag Manager côté serveur) avant d’arriver chez Google. L’info part de serveur à serveur, sans dépendre entièrement du navigateur. Les cookies déposés sont plus durables (first-party), la mesure est plus stable, et votre site charge souvent plus vite parce qu’il embarque moins de scripts.
| Critère | Client-side | Server-side |
|---|---|---|
| Sensibilité aux bloqueurs | Élevée | Faible |
| Impact Safari / iOS | Fort (cookies raccourcis) | Limité (cookies first-party) |
| Qualité des données envoyées | Partielle | Plus complète |
| Contrôle et RGPD | Limité | Fort (filtrage possible) |
| Mise en place | Simple | Plus technique |
Ce que ça change sur vos résultats
Une meilleure donnée, ce sont de meilleures décisions côté algorithme. En pratique : une attribution plus juste, des conversions qu’on croyait perdues qui réapparaissent, et souvent un coût par acquisition qui baisse à budget égal. Soyons clairs, le server-side ne fabrique pas de ventes. Il permet à Google de compter correctement celles que vous réalisez déjà, et donc d’optimiser sur du solide. C’est déjà énorme.
Et le RGPD dans tout ça ?
Le server-side n’est pas une combine pour contourner le consentement, et je préfère le dire franchement. Vous devez toujours recueillir le consentement du visiteur via un bandeau (CMP) et ne mesurer que ce qui est autorisé. En revanche, il vous donne plus de contrôle sur ce que vous transmettez : vous pouvez filtrer, limiter ou anonymiser les données envoyées, ce qui va plutôt dans le sens de la conformité.
Faut-il passer au server-side ?
C’est surtout pertinent si vous dépendez beaucoup de Google Ads, si votre audience est très mobile (donc beaucoup de Safari et d’iOS), ou si vous avez un vrai volume de conversions, en e-commerce comme en génération de leads. Si vous démarrez avec un tout petit budget, ce n’est franchement pas la priorité : commencez par un client-side propre. Mais dès que les montants deviennent sérieux, le server-side devient un vrai levier de rentabilité.
Une autre raison serait un besoin d’optimisation plus poussé et surtout opaque. Je pense notamment à l’optimisation à la marge (envoyer votre marge directement dans Google Ads à la place du chiffre d’affaires) qui est une information sensible. Avec le server-side, vous pouvez enrichir la donnée sans donner la possibilité de la lire à un visiteur un peu technique ou à votre concurrent.
Questions fréquentes
Le tracking server-side est-il conforme au RGPD ?
Oui, à condition de respecter le consentement, comme pour le tracking classique. Il offre même plus de contrôle sur les données envoyées.
Est-ce que ça récupère 100 % des conversions ?
Non. Il améliore nettement la mesure et récupère des conversions perdues, mais aucune méthode ne capte tout, surtout sans consentement. Méfiez-vous de quiconque vous promet le contraire.
Combien de temps pour le mettre en place ?
Pour un site standard, comptez quelques jours de travail pour poser un conteneur server-side et les conversions principales, selon la complexité.
Quel coût pour la mise en place ?
Pour un site e-commerce standard sous Shopify, avec une installation partant de zéro, les offres du marché démarrent plutôt autour de 2 000 à 3 000 € HT. À cela il faut ajouter le stockage des requêtes sur un serveur et la maintenance de l’infrastructure, avec des tarifs qui démarrent autour de 90 € (par exemple chez Addingwell).
Vous vous demandez si votre tracking actuel est fiable ?
Demander un audit gratuit de votre setup