+30 % de hits collectés : ce que change une infrastructure first-party client-side

Adblockers, restrictions ITP et blocage des CMP dégradent la qualité de votre collecte de données client-side. Mais ce n’est pas une fatalité : une infrastructure first-party client-side permet de restaurer l’exécution des scripts en client-side, la durée de vie des cookies et la cohérence de l’identité visiteur. Et cela tout en respectant vos utilisateurs et le cadre légal. Explications

Adblockers, ITP, ETP… Ces mécanismes qui altèrent la collecte client-side

Vous consultez vos tableaux de bord. GA4 semble stable. Meta Ads remonte des conversions. Les ROAS sont acceptables. Tout va bien. Du moins en apparence.

Car une partie de vos événements n’arrive jamais dans vos outils. Vos algorithmes publicitaires tournent donc sur des données tronquées. Et certains cookies de mesure, notamment ceux qui permettent à Google ou Meta d’optimiser vos enchères, disparaissent au bout de 24 heures pour une partie de votre trafic. Le pire ? Aucune erreur ne remonte : vous êtes partiellement aveugles sans même le savoir.

Ce n’est pas la fin des cookies tiers qui a créé ce problème. Rappelons d’ailleurs qu’en juillet 2024, Google a finalement renoncé à les supprimer dans Chrome, décision confirmée en avril 2025. Ces pertes de données ont d’autres sources :

• Les adblockers qui bloquent une partie du trafic depuis des années et dont les utilisateurs vieillissent peu à peu pour représenter des tranches d’âge avec un pouvoir d’achat et une LTV qui se développent.
• Safari qui limite les cookies depuis 2017, tout comme Firefox.
• Le RGPD qui a introduit une troisième source de perte : le non-consentement quand l’utilisateur limite les cookies mais, aussi, quand la bannière de consentement elle-même ne s’affiche pas du fait de l’adblocker.

Trois problèmes (voir le tableau) qui, cumulés, altèrent votre collecte client-side. Et une question : comment architecturer la collecte pour réduire ces pertes ?

Server Side et Client Side : 2 méthodes pour un enjeu commun

Ce constat et cette question ont conduit depuis 2020 à valoriser le server-side comme un nouveau standard de qualité pour la collecte. De fait, y recourir est justifié et nous avons ici même pris le temps de documenter les bénéfices du server-side. Mais le server-side présente aussi deux limites structurelles qu’on oublie souvent de mentionner quand on le présente comme la solution.

La première est économique. La migration vers une infrastructure server-side et son exploitation représentent un coût, qui rend son déploiement souvent progressif. Logique puisque le travail qui était couvert par le navigateur est maintenant assumé par un serveur centralisé – celui de votre plateforme server-side.

En outre, le tracking client-side est un standard maîtrisé par les équipes digitales depuis 1996, qui ne nécessite aucune refonte technique majeure et qui est compatible avec l’intégralité du stack martech. 

La seconde limite est plus fondamentale : le server-side ne remplace pas le client-side. Il le complète. Le cookie reste encore central dans l’écosystème digital. De nombreuses solutions marketing (A/B testing, ad-servers, outils de personnalisation, analytics) en dépendent.

Dans la pratique, en 2026, client-side et server-side cohabitent à l’échelle du web. Les grandes marques se sont bien emparées du potentiel du server-side, qui se développe à grande vitesse mais les plus petites structures restent attachées aux “tags”. Dans ce contexte, l’enjeu consiste à rapprocher la qualité de collecte du client-side de celle du server-side. Ce qui suppose de protéger au mieux la collecte client-side. Ceci d’autant plus que le server-side pratiqué par le marché repose souvent encore sur une collecte Client-Side. C’est l’échange de données qui se fait via API.

Google s’est donc attelé à la tâche en mai 2025 en lançant Google Tag Gateway. Une solution de tracking first-party pour GA4 et Google Ads. Un signal fort : même pour Google la collecte client-side doit être protégée. Et cette protection repose sur 2 piliers.

Les deux piliers d’une collecte client-side performante

Le First-Party Hosting : rendre vos scripts invisibles aux bloqueurs

Tout commence par un problème simple à formuler. Les librairies JavaScript de vos partenaires (Meta Pixel, TikTok, Bing UET, etc.) sont chargées depuis les domaines d’origine de ces partenaires. Comme ces domaines sont connus, les listes noires des adblockers les identifient immédiatement et bloquent leur chargement.

Le First-Party Hosting résout ce problème en déplaçant le point de chargement. Au lieu d’être servis depuis les domaines des partenaires, ces scripts sont hébergés depuis votre propre domaine, sous des noms de fichiers aléatoires et rafraîchis toutes les dix minutes pour rester à jour. Avec un bénéfice bien concret : les scripts partenaires s’exécutent sur l’ensemble du trafic, y compris pour les utilisateurs équipés d’un adblocker. 

Mieux encore : la Consent Management Platform (CMP) elle-même peut être hébergée de la même façon. En effet, si la librairie de votre CMP est bloquée avant de se charger, la bannière de consentement n’apparaît pas, aucun consentement n’est collecté et le dispositif en aval s’effondre. Le First-Party Hosting protège aussi ce “maillon zéro” de la chaîne : celui à partir duquel tout le reste est légalement possible.

Le First-Party Tracking : redonner de la durée de vie à vos cookies

Une fois les scripts exécutés, reste un deuxième problème à résoudre : celui des requêtes de collecte. Même si le pixel Meta se charge correctement, ses hits partent vers connect.facebook.net, un domaine externe, ce que Safari détecte. Les restrictions ITP sont donc appliquées et un cookie ne vivra que 24 heures.

Avec le First-Party Tracking, ces requêtes passent là encore par votre propre domaine (/monsite/metrics)  avant d’être redistribuées aux partenaires. Du point de vue du navigateur, ce trafic reste de type first-party et le cookie est traité comme tel. Avec une durée de vie jusqu’à 13 mois.

Et cette longévité change tout. Les parcours visiteurs qui s’étalent sur plusieurs jours (les plus fréquents dans le retail) redeviennent traçables. Les visiteurs récurrents sont reconnus comme tels, et non recomptés à chaque session. Le retargeting fonctionne à nouveau sur les audiences Safari. Et les algorithmes publicitaires reçoivent des données plus complètes pour calibrer leurs enchères, avec des effets mesurables sur le CPA et le ROAS.

Commanders Act Gateway : les deux piliers en une seule infrastructure

Mettre en place ces deux piliers séparément est techniquement possible, mais au prix de configurations multiples : partenaire par partenaire, avec des sous-domaines dédiés, des stacks hétérogènes et une maintenance dispersée. 

Et c’est justement pour simplifier la mise en place comme l’exploitation que Commanders Act propose sa propre solution : Commanders Act Tag Gateway (CAG). Cette infrastructure rassemble les trois piliers sous un seul chemin sur le domaine client (/monsite/metrics) quelle que soit la solution CDN (Content Delivery Network) ou WAF (Web Application Firewall) en place.

Concrètement, un seul déploiement couvre l’ensemble de l’écosystème des partenaires (Google, Meta, TikTok, Bing, Awin, Piano…) et tous transitent par la même infrastructure. Point clé : CAG intègre nativement le Google Tag Gateway, ce qui garantit la compatibilité complète avec GA4 et Google Ads.

Avec cette solution, Commanders Act propose une collecte client-side robuste, protégée, et agnostique. 

Ce que ça change pour votre mesure et votre performance

Combinés au sein de CAG, le first-party hosting et le first-party tracking corrigent les grandes déformations qui pèsent sur la mesure digitale. Sur la performance publicitaire, l’effet est direct. Les plateformes comme Google Ads et Meta Ads fonctionnent sur du machine learning : la qualité de leurs optimisations dépend de la qualité des signaux de conversion qu’elles reçoivent. Une collecte lacunaire conduit à acheter des audiences déjà converties, ou à sous-investir des segments à fort potentiel. En revanche, une collecte plus complète donne au moteur le carburant dont il a besoin.

Sur les mises en place de CAG, les gains observés oscillent entre +20 % et +30 % de hits supplémentaires collectés selon le niveau initial de blocage, avec des effets correspondants sur le CPA et les ROAS.

Les gains concernent aussi l’attribution. Il s’agit cette fois de fiabiliser les décisions budgétaires. Quand les cookies de mesure expirent en 24 heures, les conversions réalisées trois jours après un premier clic ne sont plus rattachées à la bonne campagne. Le paid semble sous-performer tandis que le SEO semble sur-performer. Restaurer la durée de vie des cookies revient, aussi, à restaurer la lisibilité du tunnel.

Aller plus loin…

L’infrastructure first-party au service de la CMP

Sans infrastructure first-party, le cookie de consentement posé par la CMP suit exactement les mêmes contraintes ITP que les autres cookies de mesure. Sur Safari, il expire en 24 heures à 7 jours selon la configuration. À chaque nouvelle session, le même utilisateur revoit donc le bandeau de consentement – même s’il a déjà consenti la veille. Sollicité en boucle, il finit par refuser par automaticité, ou par fermer la bannière sans interagir. La marque perd des consentements qu’elle avait déjà obtenus. Avec le First-Party Hosting, le consentement est mémorisé durablement. L’utilisateur ne voit le bandeau qu’une seule fois. Il prend sa décision sans pression répétée.

De l’importance d’impliquer la RSSI

Le déploiement d’une solution telle que Commanders Act Tag Gateway (CAG) nécessite d’impliquer les équipes de la RSSI. De fait, dans une telle architecture first-party, tous les cookies du domaine transitent avec les requêtes, y compris les cookies d’authentification. On peut comprendre l’inquiétude des équipes sécurité.
CAG y répond par un double mécanisme de filtrage : une liste noire qui supprime les cookies sensibles avant même qu’ils n’atteignent le Gateway (côté CDN), et une liste blanche par partenaire qui ne transmet que les cookies strictement nécessaires à chaque destination – ga et _gcl* pour Google, par exemple. Ainsi, les cookies d’authentification n’arrivent jamais ni chez Commanders Act, ni chez les partenaires.