Tracking server-side : quand s'y mettre vraiment

Passez au tracking server-side quand votre trafic Safari pèse lourd dans vos conversions, quand vous alimentez déjà Meta CAPI ou l’API Google Ads, et quand vous acceptez une facture cloud d’environ 90 dollars par mois plus du temps d’ops. Pas quand on vous parle de la fin des cookies tiers. Cet argument est mort depuis juillet 2024, et le second argument de vente habituel, celui d’iOS, repose sur une erreur de calcul.

Deux chiffres suffisent à cadrer la décision, et aucun des deux ne figure dans les argumentaires habituels. Le premier vient de Safari : depuis ITP 2.1 (WebKit, 2019), les cookies persistants créés en JavaScript sont plafonnés à 7 jours de durée de vie, ce qui est la seule raison technique solide de basculer. Le second vient de Google : sa propre documentation chiffre un serveur de tagging à environ 45 dollars par mois et par instance sur Cloud Run, avec un minimum de deux instances en production. Aucun scénario gratuit n’existe dans cette documentation.

Le tracking server-side, c’est le fait de déplacer la collecte et l’envoi des données de mesure du navigateur de l’internaute vers un serveur que vous contrôlez. La donnée transite alors par votre infrastructure avant d’atteindre Google Analytics, Meta ou une autre régie. C’est une bascule d’architecture réelle. Elle mérite mieux qu’un argumentaire qui n’a pas été mis à jour depuis quatre ans, car la mesure est le socle de tout media buying sérieux.

Que fait réellement le tracking server-side ?

Le tracking server-side change le chemin d’une donnée, il n’en crée aucune. Le navigateur envoie l’événement à votre serveur au lieu de l’envoyer directement à la régie. Votre serveur enrichit, filtre, puis transmet. C’est un relais, pas une source.

Cette distinction est la plus utile de tout le sujet. Si un utilisateur refuse le dépôt de traceurs, le server-side ne fabrique pas magiquement son parcours. Si votre site n’envoie pas l’identifiant de commande, aucun serveur ne l’inventera. Le gain se situe ailleurs : dans la durée de vie des identifiants, dans la maîtrise de ce que vous envoyez, et dans la qualité d’appariement des événements côté régie.

Trois choses que le server-side ne fait pas, et qu’il faut poser d’emblée :

• Il ne crée aucune donnée nouvelle. Il déplace une donnée déjà collectée.
• Il ne supprime pas le JavaScript côté client. Un script tourne toujours dans le navigateur pour capter l’événement de départ.
• Il n’exonère de rien au titre du RGPD. Le conteneur serveur ne gère même pas nativement le framework de consentement TCF.

Pourquoi l’argument de la fin des cookies tiers est périmé

Google a officiellement abandonné la suppression des cookies tiers dans Chrome le 22 juillet 2024. Anthony Chavez, vice-président Privacy Sandbox, l’écrit ce jour-là sans ambiguïté : « Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing » (plutôt que de déprécier les cookies tiers, nous introduirions dans Chrome une nouvelle expérience permettant aux personnes de faire un choix éclairé, valable sur l’ensemble de leur navigation). Le sujet est donc clos depuis deux ans, et pourtant il ouvre encore la majorité des argumentaires commerciaux sur le server-side. La suite du dossier est encore plus nette.

Le 22 avril 2025, Google abandonne même le prompt de choix qui devait remplacer la suppression. Puis, le 17 octobre 2025, Google annonce le retrait de six technologies Privacy Sandbox : Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage et IP Protection. Le motif officiel tient en trois mots : « low levels of adoption ». Seules CHIPS, FedCM et Private State Tokens survivent.

Ces API ont été dépréciées en Chrome 144, le 13 janvier 2026. Une nuance s’impose ici, car elle est régulièrement mal rapportée : les release notes de Chrome 150, publiées le 30 juin 2026, indiquent « no deprecations or removals in this release ». Ce n’est pas la preuve que le retrait a échoué. Les intents publiés sur blink-dev précisent que le retrait prévu en M150 passe par un field trial, c’est-à-dire un déploiement progressif piloté côté serveur, qui n’apparaît pas dans les notes de version. La suppression du code, elle, est annoncée pour M152 et n’est pas encore livrée.

Pourquoi l’argument iOS repose sur un contresens

Le chiffre « 4 % des utilisateurs acceptent le tracking sur iOS » circule depuis mai 2021 et il est faux. Ce n’est pas une opinion, c’est un problème de dénominateur : le tracker Flurry qui l’a produit ne comptait pas la même population que les autres mesures. La même semaine, Kochava mesurait 48,8 %.

Les données récentes confirment l’ordre de grandeur. Selon AppsFlyer (2025), le taux d’opt-in au framework App Tracking Transparency atteint 50 % au niveau mondial et 53 % en France. Le tracker Flurry qui a produit le 4 % est d’ailleurs arrêté depuis mars 2024. Autrement dit, environ un utilisateur iOS sur deux accepte, et non un sur vingt-cinq.

Le marché a d’ailleurs voté avec son budget : la dépense publicitaire sur iOS a progressé de 26 % entre 2023 et 2024. Un écosystème réputé aveugle n’attire pas ce type de croissance.

Ce qu’on lit partout. iOS a rendu la mesure impossible, seuls 4 % des utilisateurs acceptent d’être suivis, et le server-side est la parade.

Ce que dit la donnée. Le 4 % vient d’un tracker arrêté depuis mars 2024, avec un dénominateur non comparable. Kochava mesurait 48,8 % la même semaine, et AppsFlyer mesure 50 % au niveau mondial et 53 % en France en 2025.

Quelle est la vraie raison technique de passer au server-side ?

La vraie raison s’appelle ITP et elle vient de Safari. Depuis ITP 2.1, sorti en 2019, Safari plafonne à 7 jours la durée de vie des cookies persistants créés en JavaScript via document.cookie. John Wilander l’annonce dans les termes suivants sur le blog WebKit : « All persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry » (tous les cookies persistants côté client, c’est-à-dire les cookies persistants créés via document.cookie, sont plafonnés à sept jours d’expiration). Or c’est exactement ainsi que la plupart des balises de mesure posent leur identifiant.

Le détail qui change tout : les cookies posés par un en-tête HTTP Set-Cookie, depuis un serveur situé sur votre propre domaine, ne sont pas soumis à ce plafond de 7 jours. Simo Ahava, référence de l’écosystème Google Tag Manager, le formule ainsi : « By using the Set-Cookie header you can extend cookie lifetime to whatever duration you select » (en utilisant l’en-tête Set-Cookie, vous pouvez étendre la durée de vie du cookie à la durée de votre choix). C’est ce mécanisme, et lui seul, qui justifie techniquement une bascule server-side. Il est très rarement expliqué, parce qu’il est moins vendeur qu’une prophétie sur la fin des cookies.

À cette raison s’ajoutent deux motifs légitimes, moins spectaculaires mais réels : la maîtrise de ce que vous transmettez aux régies, et la qualité d’appariement des événements. Sur Meta, cette qualité se lit dans l’Event Match Quality, un score de 0 à 10 calculé sur une fenêtre glissante de 48 heures, réservé au web. Meta classe l’email et le paramètre fbc en priorité High, le téléphone, fbp, external_id et la date de naissance en Medium, le prénom, le nom, la ville et le code postal en Low. Meta ne publie aucune pondération chiffrée par paramètre : toute grille du type « email égale 2 points » est une reconstitution d’agence, pas une donnée. Sur les autres seuils que Meta publie réellement dans sa documentation, et sur ceux qu’elle ne publie pas, voir notre analyse de la structure de compte Meta Ads.

Combien coûte vraiment un tracking server-side ?

Comptez environ 90 dollars par mois de serveur sur Cloud Run, et environ 120 dollars par mois sur App Engine, avant tout le reste. Ces chiffres ne viennent pas d’une estimation, ils viennent de la documentation de Google elle-même.

Le point important n’est pas le montant, il est modeste pour beaucoup de structures. Le point important est qu’aucun scénario gratuit n’existe dans la documentation Google. Quand un prestataire vous annonce un serveur de tagging sans coût récurrent, demandez sur quelle infrastructure il tourne et qui la paie.

Le vrai coût est ailleurs, dans les compétences. Une mise en place propre demande une configuration DNS en enregistrements A ou AAAA plutôt qu’en CNAME, l’administration de Google Cloud Platform, un load balancer, des certificats TLS, des templates Google Tag Manager personnalisés, et une gestion manuelle du consentement. Ce n’est pas du GTM avancé. C’est du GTM plus de l’ops cloud, et ces deux métiers cohabitent rarement dans la même personne.

Que faut-il penser des gains annoncés ?

Les chiffres de gains publiés par les éditeurs de solutions server-side sont invérifiables. « 15 à 30 % de conversions récupérées », « +30,7 % », « 15 à 40 % de données perdues » : ces valeurs sont auto-déclarées, sans méthodologie publiée ni groupe de contrôle. Elles constituent un argumentaire, pas une preuve, et il faut les lire comme telles.

Deux exemples de chiffres qui circulent et que nous vous conseillons de manier avec précaution :

• Le « +65 % de conversions récupérées par le Consent Mode » n’a aucune source Google. Le chiffre officiel est « more than 70 % », il date d’avril 2021, donc d’avant Consent Mode v2, et il porte sur les parcours clic-conversion, pas sur les conversions elles-mêmes.
• Le « −13 % de coût par action » avec l’API Conversions de Meta est réellement sourçable, dans la newsroom Meta du 17 avril 2023. Mais il est publié sans méthodologie ni échantillon, ciblé PME, et il a depuis été retiré de la documentation d’aide courante. Quant au « +19 % de ROAS avec CAPI », il est attribuable à des éditeurs tiers, pas à Meta.

Un seul objectif chiffré est officiellement publié par Meta dans ses bonnes pratiques de l’API Conversions, et il tient en une ligne : « aim for a 75% event coverage ratio of conversions api to meta pixel events » (visez un taux de couverture de 75 % des événements de l’API Conversions rapportés aux événements du Pixel Meta). C’est un repère utilisable, parce qu’il vient de la plateforme et qu’il est mesurable chez vous.

Un détail technique qui provoque beaucoup d’erreurs de lecture : la déduplication entre Pixel et API Conversions exige le même event_name et le même event_id, sur une fenêtre de 48 heures, et l’événement reçu en premier est celui qui est conservé. Beaucoup d’implémentations tablent sur 7 jours. C’est faux, et cela produit des doublons ou des pertes que l’on impute ensuite à tort au server-side.

Le server-side simplifie-t-il la conformité RGPD ?

Non. Il la complique, et c’est l’inverse exact de ce qui est souvent présenté. Une architecture server-side qui alimente Google Ads ou l’API Conversions de Meta sort du périmètre d’exemption de consentement pour la mesure d’audience défini par la CNIL. Vous quittez la mesure statistique pour entrer dans la publicité ciblée, avec toutes les obligations correspondantes.

Le sujet n’est pas théorique. La CNIL a prononcé contre Google une sanction de 325 millions d’euros le 1er septembre 2025 (délibération SAN-2025-004), la plus lourde jamais rendue en matière de cookies. Sur ce terrain, une architecture qui transmet plus de données, depuis vos propres serveurs, avec votre responsabilité de traitement, augmente votre exposition. Elle ne la réduit pas.

Il faut aussi trancher une question qui revient systématiquement en rendez-vous : peut-on utiliser le server-side pour contourner les bloqueurs de publicité ? Techniquement, oui. Simo Ahava, référence de l’écosystème Google Tag Manager, répond à cette question par « Absolutely. Should you? Definitely not. » Nous reprenons sa position sans réserve. Contourner un choix explicite exprimé par l’utilisateur crée un risque juridique et réputationnel sans commune mesure avec le gain de données.

Que valent vraiment les taux de consentement en France ?

Le taux de consentement mesuré en France est de 78,06 %, mais ce chiffre ne dit pas ce que la plupart des gens croient. Il vient du Baromètre Privacy 2025 de Commanders Act, sur un périmètre France et plus de 1 300 bandeaux. Il est solide. Il est aussi souvent mal interprété.

La distinction est simple et elle est tout le sujet :

• Le consent rate se calcule sur les choix exprimés. Sur 100 personnes qui cliquent, 78 acceptent.
• L’opt-in rate se calcule sur les bandeaux affichés. Il inclut donc tous ceux qui ne cliquent nulle part.

Or, toujours selon Commanders Act (2025), environ 40 % des visiteurs desktop et 32 % sur mobile ne font aucun choix explicite. En combinant les deux chiffres, l’opt-in rate réel se situe plutôt autour de 50 à 55 %. Nous présentons cette fourchette comme une reconstitution, pas comme une donnée publiée : Commanders Act ne publie pas ce ratio tel quel.

Une précision au passage : le « 71 % Didomi » qui circule abondamment est introuvable sur une page Didomi, leur benchmark public affichant « Data coming soon ». Si vous le voyez cité, demandez la page source.

Ce taux d’opt-in réel a une conséquence directe sur le Consent Mode de Google, dont la modélisation est soumise à des seuils officiels précis. Google Ads exige 700 clics publicitaires sur 7 jours, par pays et par groupement de domaines. GA4 exige 1 000 événements par jour en analytics_storage='denied' sur 7 jours, et 1 000 utilisateurs quotidiens consentis sur 7 des 28 jours précédents. Point rarement expliqué et pourtant décisif : le mode basique disqualifie la modélisation GA4, qui exige l’implémentation avancée. Si vous avez déployé le Consent Mode en mode basique, vous ne récupérez rien de ce que vous croyez récupérer.

Faut-il y aller ? L’arbre de décision

Passez au server-side si vous cochez au moins deux des quatre cases suivantes. Sinon, gardez votre budget pour un sujet qui bougera davantage votre coût par acquisition.

1. Votre trafic Safari et iOS pèse significativement dans vos conversions. C’est le seul cas où le plafond de 7 jours d’ITP vous coûte réellement de la donnée.
2. Vous alimentez déjà Meta CAPI ou l’API Google Ads, et vous constatez un taux de couverture inférieur au repère de 75 % publié par Meta.
3. Vous avez accès à une compétence ops cloud, en interne ou chez un prestataire identifié, pas seulement à un intégrateur GTM.
4. Votre volume rend l’écart de mesure décisionnel. Si un écart de 10 % sur vos conversions ne change aucun arbitrage de budget, l’investissement ne se justifie pas. Pour objectiver ce point, partez de votre coût d’acquisition client et de sa méthode de calcul : un écart de mesure ne compte que s’il déplace ce chiffre.

Si vous n’en cochez aucune, le levier le plus rentable est presque toujours ailleurs : dans la façon dont vous lisez vos données plutôt que dans la façon dont vous les collectez. C’est d’ailleurs le sujet de notre article sur les divergences entre GA4, Meta et votre CRM, qui explique pourquoi trois sources ne diront jamais la même chose, quelle que soit la qualité de votre tracking.

Pour situer ce point dans l’ensemble du dispositif, publicité payante et acquisition organique pose le cadre et ce que les études permettent réellement d’en dire.

Une précision qui évite une déception fréquente. L’envoi serveur n’affranchit pas du navigateur : les paramètres d’appariement recommandés proviennent de cookies posés côté navigateur ou d’un paramètre d’URL qu’il faut capter. Le fonctionnement de l’objet et les conditions de déduplication sont détaillés dans pixel publicitaire, du navigateur à l’API de conversions.

Une précision de méthode, avant toute décision technique : ce qui est mesuré, sous quel nom et pour quelle décision se décide dans un document à part, et les limites de la plateforme y sont plus contraignantes qu’on ne le croit. Voir plan de taggage : ce qu’il faut refuser de mesurer.

En bref

• Ignorez les deux arguments de vente habituels. La fin des cookies tiers est abandonnée depuis le 22 juillet 2024, et le « 4 % d’opt-in iOS » est un artefact de dénominateur, contre 50 % au niveau mondial et 53 % en France selon AppsFlyer en 2025.
• Vérifiez d’abord votre part de trafic Safari. Le plafond de 7 jours d’ITP sur les cookies créés en JavaScript est la seule raison technique solide, et elle ne concerne pas tous les sites au même degré.
• Budgétez le vrai coût avant de décider. Environ 90 dollars par mois sur Cloud Run selon la documentation Google, plus le trafic sortant, le load balancer, le certificat, et surtout du temps d’ops cloud. Et ne comptez sur aucune simplification RGPD : le server-side complique votre conformité, il ne l’allège pas.

Si vous hésitez entre investir dans votre infrastructure de mesure et investir dans vos campagnes, la bonne réponse dépend de votre volume et de votre mix d’audience, pas d’une tendance. Discutons de votre projet : nous regardons vos chiffres, votre part de trafic Safari et vos taux de couverture avant de recommander quoi que ce soit. Vous pouvez aussi découvrir notre approche de l’acquisition payante.