Table des matières
Vos rapports Google Ads et Meta ne collent plus aux ventes réelles, Safari efface vos cookies en quelques jours et votre bannière réduit encore le volume de données. Le tracking server-side est souvent présenté comme la réponse à tout. Il apporte beaucoup, à condition de savoir précisément ce qu'il change, et ce qu'il ne change pas, au regard de la LPD et du RGPD.
Ce guide reprend les questions que nous posent le plus souvent les agences et les PME suisses : fonctionnement, conformité, plateformes publicitaires, applications, CMS, CRM, hébergement et coûts.
En bref
Le server-side fait transiter vos données par votre propre serveur, sur un sous-domaine de votre site, avant de les envoyer à Google, Meta ou TikTok.
Il rend la mesure plus résiliente (ITP de Safari, bloqueurs, pages plus légères) mais ne remplace ni la bannière ni le consentement : un refus reste un refus.
Côté conformité, son atout est le contrôle : vous décidez quelles données (IP, identifiants) partent vers quels outils.
Les API de conversion (Meta, TikTok, conversions hors ligne Google Ads) s'appuient sur ce serveur, avec une déduplication par identifiant d'événement.
Client-side ou server-side : ce qui change vraiment
Comment fonctionne le tracking server-side avec sGTM ?
En tracking classique (client-side), le navigateur du visiteur charge un script par outil (Pixel Meta, gtag.js, Pixel TikTok) et envoie lui-même les données à chaque plateforme. En server-side, le navigateur envoie un flux unique à votre conteneur Google Tag Manager Server-Side (sGTM), hébergé sur un serveur que vous contrôlez. Ce serveur agit comme un centre de tri : il reçoit l'événement, le nettoie, retire ce qui ne doit pas sortir, puis le transmet aux seuls outils autorisés.
Pourquoi le tracking client-side est-il devenu fragile ?
Trois évolutions ont réduit la fiabilité des scripts exécutés dans le navigateur :
Les navigateurs : l'Intelligent Tracking Prevention (ITP) de Safari limite à 7 jours les cookies posés en JavaScript, et même à 24 heures dans certains cas de liens de tracking. Sur iOS, l'App Tracking Transparency (iOS 14.5, avril 2021) exige l'accord de l'utilisateur pour le suivi entre applications.
Les bloqueurs : selon GWI (T2 2025), 30,9 % des internautes suisses utilisent un bloqueur de publicité, qui vise en priorité les scripts des régies.
Le consentement : les visiteurs qui refusent les cookies ne doivent pas être suivis, ce qui réduit mécaniquement le volume observé.
À noter : Google a annoncé en avril 2025 renoncer à supprimer les cookies tiers de Chrome. Le problème ne vient donc pas d'une « fin des cookies tiers », mais de ces restrictions cumulées.
Que change le sous-domaine first-party ?
Le serveur sGTM est installé sur un sous-domaine de votre site, par exemple mesure.votre-marque.ch. Les requêtes restent dans votre propre domaine (first-party) et les cookies peuvent être posés par votre serveur plutôt qu'en JavaScript, ce qui les expose moins aux limites de durée de l'ITP. Deux nuances importantes :
Depuis 2023, WebKit limite aussi à 7 jours les cookies posés par un serveur dont l'adresse IP diffère nettement de celle du site. L'architecture d'hébergement compte donc.
Il ne s'agit pas de contourner le choix du visiteur : la mesure first-party reste soumise à votre bannière. Elle est résiliente aux restrictions techniques, pas aux refus.
Combien de données peut-on récupérer ?
Aucun chiffre universel n'est honnête : le gain dépend de la part de trafic Safari et iOS, du taux de refus de votre bannière, de votre public (plus ou moins équipé en bloqueurs) et de l'état de départ du tracking. Le bon réflexe est de mesurer avant et après : comparez sur quelques semaines les conversions remontées dans Google Ads et Meta aux ventes réelles de votre back-office.
Le server-side ralentit-il le site ?
Plutôt l'inverse. En déplaçant une partie des scripts des régies vers le serveur, vous laissez moins de JavaScript à télécharger et à exécuter au navigateur. Le gain réel dépend du nombre de balises retirées côté client : il se vérifie dans vos rapports Core Web Vitals, pas sur promesse.
Conformité LPD et RGPD : ce que le serveur permet, et ce qu'il ne permet pas
Le server-side est-il obligatoire pour être conforme ?
Non. Ni la LPD ni le RGPD n'imposent une technologie. Ils imposent des principes : transparence, proportionnalité, sécurité, respect des choix des personnes. Le server-side est un outil de contrôle qui aide à les appliquer. En client-side, le navigateur du visiteur se connecte directement aux serveurs de chaque régie, qui reçoivent au passage son adresse IP et des métadonnées techniques. Avec un serveur intermédiaire, c'est vous qui décidez de ce qui sort.
Comment le serveur protège-t-il les adresses IP et les données personnelles ?
Sur sGTM, chaque événement peut être filtré avant envoi : suppression ou troncature de l'IP, retrait du User-Agent, exclusion des paramètres d'URL qui contiennent un e-mail. Pour les correspondances avancées (Advanced Matching chez Meta, conversions améliorées chez Google), e-mails et téléphones sont hachés en SHA-256 avant transmission.
Attention : un hachage est une pseudonymisation, pas une anonymisation. La régie peut rapprocher ces valeurs de ses propres comptes utilisateurs : ce sont toujours des données personnelles, qui exigent une base légale, une mention dans votre politique de confidentialité et, côté UE, le consentement.
Faut-il encore une bannière de cookies avec le server-side ?
Oui. Le lieu de traitement change, pas l'obligation. En Suisse, l'art. 45c LTC impose d'informer et de permettre le refus (opt-out) ; dans l'UE, ePrivacy et le RGPD exigent un consentement préalable pour les traceurs non essentiels. Et depuis le 31 juillet 2024, Google applique sa politique de consentement de l'UE au trafic suisse : sans Consent Mode v2 correctement alimenté, pas de remarketing ni de mesure publicitaire complète.
Comment le Consent Mode v2 fonctionne-t-il avec sGTM ?
Votre CMP transmet le choix du visiteur aux balises Google via quatre paramètres (ad_storage, analytics_storage, ad_user_data, ad_personalization). En mode advanced, un refus déclenche des pings sans cookie, que le serveur relaie sans identifiant ; Google s'en sert pour modéliser les conversions manquantes. Selon Google (2021), cette modélisation retrouve en moyenne plus de 70 % des parcours clic publicitaire vers conversion perdus à cause des refus de cookies. Côté UE, faites valider ce mode par votre DPO : ces pings restent un flux technique. Le serveur doit aussi appliquer le consentement aux balises non Google (Meta, TikTok, LinkedIn), qui ignorent le Consent Mode.
Et les transferts de données vers les États-Unis ?
Le server-side ne supprime pas les transferts : si vous envoyez des données à Meta ou Google, elles partent vers ces sociétés. Il permet en revanche de les réduire au strict nécessaire. Côté cadre juridique, le Swiss-U.S. Data Privacy Framework est en vigueur depuis le 15 septembre 2024 (le cadre UE-États-Unis depuis le 10 juillet 2023) : vérifiez que vos destinataires y sont certifiés et mentionnez-les dans votre politique. Sanctions et obligations détaillées : voir notre guide de conformité LPD et RGPD.
Conseil A-Track
Documentez vos règles de filtrage sGTM (quelles données partent vers quel outil, sous quelle condition de consentement) dans un tableau simple. C'est la pièce la plus utile face à un DPO, à un client ou au PFPDT, et elle sert de référence à chaque mise à jour.
Meta, Google Ads, GA4 et TikTok : API de conversion et déduplication
La Conversions API de Meta remplace-t-elle le Pixel ?
Non, elle le complète. La Conversions API (CAPI) permet à votre serveur d'envoyer les événements directement à Meta. Meta recommande une configuration redondante : le Pixel côté navigateur et la CAPI côté serveur, pour les mêmes événements. Mise en place détaillée dans notre guide Facebook CAPI.
Comment éviter de compter deux fois la même vente ?
Chaque événement reçoit un identifiant unique (event_id), identique côté Pixel et côté serveur. Quand Meta reçoit deux événements avec le même nom et le même event_id, il n'en garde qu'un. Selon la documentation Meta, il retient en général le premier reçu, si le second arrive dans les 48 heures. Sans event_id cohérent, vos conversions sont gonflées et l'algorithme optimise sur de fausses données.
Qu'apporte la TikTok Events API ?
Une large part du trafic TikTok passe par le navigateur intégré de l'application, où scripts et cookies sont moins fiables. La TikTok Events API envoie les conversions depuis votre serveur ou votre boutique (Shopify, WooCommerce) : l'attribution devient plus stable et l'algorithme reçoit plus de signaux pour sortir de sa phase d'apprentissage.
Que change GA4 en server-side ?
GA4 reçoit les données via votre serveur, qui peut poser le cookie _ga depuis votre domaine. Google fixe sa durée par défaut à 2 ans ; posé côté serveur, il résiste mieux à l'ITP, dans la limite des règles de Safari décrites plus haut. Résultat, si le visiteur a consenti : moins de visiteurs comptés deux fois et des parcours longs mieux attribués.
Applications mobiles, web apps et Server-to-Server
Comment suivre une application iOS ou Android en server-side ?
Au lieu d'embarquer un SDK par régie, l'application envoie ses événements à un seul outil de collecte (Firebase, ou le SDK d'une plateforme de données clients), relayé vers votre sGTM. Le serveur traduit ensuite ces événements pour chaque API publicitaire. Sur iOS, l'App Tracking Transparency s'applique toujours : le server-side ne dispense pas de demander l'autorisation pour le suivi entre applications.
Faut-il encore intégrer les SDK de Meta ou TikTok ?
Moins il y en a, mieux c'est : chaque SDK alourdit l'application, impose des mises à jour et envoie des données que vous maîtrisez mal. Réduire les SDK tiers au profit d'un flux serveur simplifie la maintenance et la documentation LPD. Certaines fonctions (attribution des installations, SKAdNetwork d'Apple) peuvent toutefois exiger un SDK ou un partenaire de mesure mobile : à arbitrer au cas par cas.
Et les web apps (React, Vue.js, Angular) ?
Dans une Single Page Application, la page ne se recharge pas à chaque clic. Il faut donc pousser dans le dataLayer des événements de page virtuelle et d'action, que le conteneur GTM web transmet au sGTM. Bien conçu, ce plan de marquage ne dégrade pas la fluidité de l'application.
Peut-on relier web et application (cross-device) ?
Oui, si l'utilisateur se connecte. Un identifiant utilisateur interne (User ID), transmis sous forme pseudonymisée depuis le site et depuis l'application, permet à GA4 et aux API de conversion de rapprocher les sessions. C'est un traitement de données personnelles : il doit figurer dans votre politique de confidentialité et respecter le consentement.
Qu'est-ce que le Server-to-Server (S2S) pur ?
En S2S, c'est votre back-end (PHP, Node.js, Python) qui envoie l'événement, sans passer par le navigateur. Nous combinons souvent les deux approches : le back-end confirme la vente et envoie un webhook au sGTM, qui gère la distribution vers les régies. Un webhook part quand un statut change dans votre base (commande payée, livrée) : il ne dépend pas d'un onglet resté ouvert. Pour les architectures headless ou sur mesure, c'est souvent la méthode la plus fiable, car l'événement est capté à la source.
Le S2S doit lui aussi respecter le consentement : enregistrez le choix du visiteur avec la commande pour savoir quels outils peuvent recevoir l'événement.
Shopify, WordPress, CRM : brancher vos outils
Le server-side fonctionne-t-il sur Shopify ?
Oui. Shopify limite les scripts personnalisés sur son checkout, ce qui fragilise le suivi des achats en client-side. Les solutions passent par les Customer Events (Web Pixels) de Shopify, par une application de connexion au sGTM ou par les webhooks de commande. La vente est alors transmise dès sa validation par Shopify.
Et sur WordPress et WooCommerce ?
La base est un dataLayer e-commerce propre (souvent via le plugin GTM4WP) avec les événements standard de GA4 : view_item, add_to_cart, purchase. Le conteneur web envoie ensuite ce flux vers votre sGTM, qui le distribue à GA4, Google Ads, Meta ou Pinterest.
PrestaShop, Magento, Webflow ou Wix ?
PrestaShop et Magento donnent un accès complet au back-end : idéal pour standardiser la couche de données et ajouter du S2S sur les étapes clés, avec une bonne qualité de correspondance des événements.
Webflow et Wix sont plus fermés mais acceptent GTM : le server-side y reste possible pour les formulaires et les événements clés, avec moins de profondeur.
Comment remonter les ventes conclues hors ligne (CRM) ?
C'est souvent là que le server-side rapporte le plus en B2B. Un prospect remplit un formulaire, l'identifiant de clic (gclid, fbclid) est enregistré dans le CRM, puis la vente est signée des semaines plus tard. Quand l'affaire passe à « gagnée » dans HubSpot ou Salesforce, un webhook envoie au sGTM l'identifiant et le montant (par exemple CHF 5'000), qui les transmet à Google Ads ou à Meta. L'algorithme apprend alors à chercher des clients, pas seulement des formulaires remplis. Méthode complète dans notre guide des conversions hors ligne CRM.
Et les abonnements ou l'e-mailing ?
Les paiements récurrents (Stripe, Chargebee) ont lieu sans visite du site : seul un webhook serveur peut les remonter pour suivre la valeur client dans la durée. Côté e-mailing (Klaviyo, ActiveCampaign), l'envoi serveur des événements (panier, achat) rend les scénarios automatisés plus fiables, sous réserve du consentement marketing.
Hébergement, coûts et maintenance
Stape ou Google Cloud Platform ?
sGTM peut être hébergé sur Google Cloud (GCP), mais la configuration, la montée en charge et la supervision demandent des compétences DevOps, et les coûts varient avec le trafic. Nous utilisons le plus souvent Stape, un hébergeur spécialisé : choix de serveurs en Europe, tarif lisible et outils pratiques comme le Custom Loader (chargement des scripts GTM depuis votre domaine). D'autres options existent, dont l'hébergement en Suisse : voir notre comparatif Infomaniak, Google Cloud ou Stape.
Combien coûte une mise en place chez A-Track ?
Nos forfaits de configuration initiale (hors TVA, hors licence CMP et hébergement sGTM) :
Landing pages et petits sites : dès CHF 1'200.
Site CMS standard (leads et e-commerce) : dès CHF 2'400.
Sites sur mesure (plan de taggage, S2S, CRM) : dès CHF 4'800.
Détail des forfaits et des options (CAPI, CRM, API) sur la page Tracking et conformité.
Pourquoi une maintenance annuelle ?
Un tracking juste au lancement peut casser sans bruit : mise à jour d'API chez Meta ou TikTok, nouvelle règle de Safari, changement de CMP, nouveau plugin, évolution légale ou du standard IAB TCF. Nos forfaits de maintenance démarrent à CHF 900 par an (petits sites), CHF 1'800 (CMS standard) et CHF 3'600 (sur mesure), hors TVA : surveillance, correctifs et veille réglementaire.
Quel retour sur investissement attendre ?
Le ROI dépend de votre budget média et du volume de conversions aujourd'hui manquantes. Le mécanisme, lui, est simple : plus les plateformes reçoivent de conversions fiables et consenties, mieux leurs algorithmes d'enchères apprennent. Mesurez l'écart entre conversions déclarées et ventes réelles avant le projet : c'est votre référence pour juger du résultat. Pour la méthode, voir notre guide de la mesure de performance marketing.
Comment A-Track se situe-t-il ?
Nous ne sommes pas une agence média : nous réparons et maintenons la « tuyauterie » (CMP, Consent Mode, GTM, sGTM, API de conversion) pour que les campagnes des agences et des annonceurs reposent sur des données fiables et conformes. Basés à Genève, nous partons de la LPD suisse et du RGPD, et nos audits confrontent votre site à ces deux cadres, ainsi qu'au standard IAB TCF 2.3 lorsque vous l'utilisez.
Conclusion : par où commencer
Mesurez l'écart entre les conversions déclarées par vos plateformes et vos ventes réelles sur un mois.
Vérifiez votre socle de consentement : CMP, Consent Mode v2, déclenchement des balises non Google.
Priorisez les flux qui comptent : achat ou lead en server-side, puis API de conversion Meta et Google, puis CRM.
Documentez et surveillez : règles de filtrage, tests après chaque mise à jour du site ou de la CMP.
Par où commencer votre passage au server-side ?
A-Track cartographie vos plateformes (Meta, Google Ads, GA4, TikTok), votre CMS et votre CRM, puis vous propose un plan de migration server-side conforme à la LPD et au RGPD.
Première étape : un appel de 30 minutes avec un expert.