Table des matières
Le back-office de votre client ne colle plus à Google Ads ni à Meta, et il vous demande quel chiffre croire. Souvent, la cause est la mesure : un tracking qui repose uniquement sur le navigateur (client-side) laisse filer une partie des conversions. Le tracking server-side reprend la main sur ce flux, sans jamais passer outre le choix du visiteur.
En bref
En client-side, le navigateur envoie les données directement à chaque plateforme : il subit les bloqueurs, l'ITP de Safari et le poids des scripts tiers.
En server-side, un serveur que vous contrôlez, sur le sous-domaine du site, filtre puis redistribue les données.
Selon GWI (T2 2025), 30,9 % des internautes suisses utilisent un bloqueur de publicité.
Le server-side ne remplace pas le consentement : un refus reste un refus.
Client-side ou server-side : quelle différence ?
Les deux méthodes collectent les mêmes événements. Seul le chemin des données change.
Client-side (méthode « pixel ») : le navigateur charge un script par outil (GA4, pixel Meta, balise LinkedIn) et envoie les données directement à chaque plateforme. Chaque script dépend de ce que le navigateur accepte d'exécuter.
Server-side : le navigateur envoie les événements à un serveur intermédiaire sur un sous-domaine du client (par exemple data.votreclient.ch). Ce conteneur Google Tag Manager server-side applique vos règles puis transmet aux plateformes via leurs API. Vous décidez de ce qui sort, et vers qui.
Pourquoi le client-side perd des conversions
Quatre causes expliquent la plupart des écarts entre le back-office (Shopify, WooCommerce) et les rapports publicitaires.
Les restrictions des navigateurs. L'ITP de Safari limite à 7 jours les cookies posés en JavaScript (24 h dans certains cas de liens de tracking). Un achat dix jours après le clic n'est plus relié à l'annonce. Or Safari pèse près de la moitié de la navigation mobile en Suisse (StatCounter, août 2026).
Les bloqueurs de publicité. Selon GWI (T2 2025), 30,9 % des internautes suisses en utilisent un. Les scripts de Google, Meta ou TikTok ne se chargent alors jamais.
Le consentement mal branché. Sans Consent Mode v2 correctement configuré, Google exploite moins bien les données des visiteurs suisses depuis le 31 juillet 2024.
Le poids des scripts tiers, au détriment des Core Web Vitals.
La solution technique : GTM server-side hébergé par Stape
L'architecture la plus courante combine Google Tag Manager server-side (le conteneur qui reçoit les événements et orchestre les envois) et Stape, l'hébergeur que nous utilisons, plus simple à maintenir qu'une instance Google Cloud gérée à la main. Ce qu'elle apporte :
Une mesure first-party. Les cookies de mesure sont posés par le serveur du site, donc plus résilients aux restrictions des navigateurs, si l'hébergement est bien configuré : Safari limite aussi à 7 jours les cookies posés par un serveur tiers masqué derrière un sous-domaine (WebKit, 2020).
Un chargement de GTM plus robuste. Avec le Custom Loader de Stape, le script GTM est servi depuis le domaine du site plutôt que depuis googletagmanager.com. La CMP continue de décider de ce qui se déclenche.
Les API de conversion (CAPI Meta, Google Ads, LinkedIn) branchées depuis le même serveur.
Un hébergement choisi. Un serveur dans l'UE ou en Suisse facilite la maîtrise des flux (LPD, RGPD), mais les envois vers Google ou Meta aux États-Unis restent un transfert à documenter (comparatif des hébergeurs).
Comment justifier l'investissement auprès de vos clients
Le server-side a un coût (mise en place, puis abonnement mensuel au serveur). Deux arguments lèvent l'objection.
1. L'argument performance
Le Smart Bidding et l'algorithme de Meta optimisent sur les conversions reçues. Plus le signal est complet et fiable, mieux ils enchérissent. Le gain dépend du site et du consentement : mesurez-le avant et après, sans promettre de pourcentage.
2. L'argument gouvernance
Avec le server-side, vous choisissez les champs transmis : tronquer une adresse IP, hacher un e-mail, retirer un paramètre d'URL sensible avant l'envoi. C'est une application concrète de la protection des données dès la conception (art. 7 LPD), un argument qui parle aux DPO.
Conseil A-Track
Avant de chiffrer le projet, comparez sur un mois les ventes du back-office et celles remontées dans Google Ads et Meta. L'écart mesuré sur le site de votre client convainc bien mieux qu'une moyenne de marché.
Questions fréquentes sur le server-side
Le server-side remplace-t-il le pixel ?
Non. La configuration recommandée est hybride : le pixel reste dans le navigateur, l'API de conversion envoie les mêmes événements depuis le serveur, et la plateforme les déduplique grâce à un identifiant commun (event_id). Voir la documentation Meta.
Est-ce compatible avec tous les CMS ?
Oui : via le dataLayer et GTM, sur Shopify, WooCommerce, PrestaShop ou un site sur mesure.
Le site devient-il plus rapide ?
Seulement si vous retirez des scripts du navigateur. Ajouter le server-side sans rien enlever côté client ne fait rien gagner.
Conclusion : par où commencer
Mesurez l'écart entre back-office et plateformes publicitaires sur un mois (méthode dans notre guide de la mesure de performance).
Vérifiez la CMP et le Consent Mode v2 avant toute migration : le serveur applique les choix du visiteur, il ne les remplace pas (voir notre guide de conformité LPD et RGPD).
Déployez un conteneur server-side sur un sous-domaine du client, puis surveillez-le dans la durée : un tracking server-side peut casser après la mise en ligne.
Quel écart entre back-office et plateformes chez vos clients ?
A-Track mesure l'écart entre ventes réelles et conversions remontées, puis déploie GTM server-side sur le sous-domaine du client, dans le respect du consentement.
Parlons-en lors d'un appel de 30 minutes avec un expert.
