Introduction
Il y a une phrase qui revient dans presque tous les rendez-vous de pilotage depuis deux ans : « on a l'impression que le trafic est stable, mais les conversions ne remontent plus dans l'outil ». Ce n'est pas une impression. C'est une mesure qui s'effrite, doucement, sans prévenir.
Le plus surprenant, c'est que la fin des cookies tiers n'a pas eu lieu. Pas au sens où on l'annonçait. Et pourtant la donnée s'est déjà dégradée, largement, silencieusement. Un site français moyen tourne autour de 60 à 75 % de consentement selon son secteur et la qualité de son bandeau. Autrement dit, entre un quart et 40 % du trafic n'existe tout simplement pas dans Google Analytics. Ajoutez à cela l'ITP de Safari, qui tronque les cookies first-party posés en JavaScript à sept jours, et l'ETP de Firefox qui fait le ménage de son côté. Un visiteur qui revient au bout de dix jours redevient un inconnu. Un parcours de trois semaines entre première visite et achat ? Invisible.
Le sujet n'est donc pas « par quoi remplacer le cookie ». C'est une mauvaise question, formulée à l'envers. La vraie question, celle qui structure les projets sérieux : qui contrôle la collecte, où sont stockées les données, et combien de temps survivent-elles ?
Un prestataire digital qui traite le tracking sans cookies comme un simple paramétrage d'outil passe à côté du chantier. Il y a trois couches à empiler, dans cet ordre précis : la conformité et le consentement, l'infrastructure de collecte, puis seulement l'outillage analytics. Inverser cet ordre, c'est ce qui produit ces projets à 15 000 € de server-side qui ne mesurent finalement rien de plus qu'avant. Voyons pourquoi, et surtout comment s'y prendre.
Où en est-on vraiment : l'état des lieux à connaître avant d'investir
Le calendrier réel de Google et pourquoi il ne change rien à l'urgence
Reprenons depuis le début. En juillet 2024, Google annonce qu'il ne supprimera finalement pas les cookies tiers dans Chrome. À la place : un choix laissé à l'utilisateur. Puis, en avril 2025, la firme enfonce le clou en abandonnant même l'idée d'une invite dédiée. Beaucoup ont conclu, avec un soulagement compréhensible, que le sujet était refermé.
Mauvaise lecture. Chrome n'a jamais été le sujet.
La pression vient d'ailleurs, et de trois directions simultanées qui n'ont rien à voir avec le calendrier de Mountain View. D'abord les navigateurs concurrents : Safari bloque les cookies tiers depuis 2020, Firefox depuis 2019. Sur un site B2C français, ça représente déjà 30 à 40 % de l'audience, davantage sur mobile. Ensuite la doctrine réglementaire : la CNIL et l'EDPB ne se sont jamais alignés sur les décisions produit de Google, et leurs positions sur le consentement se sont durcies, pas assouplies. Enfin, la fatigue au consentement, ce phénomène très concret où les utilisateurs refusent par réflexe, de plus en plus vite, avec un taux d'acceptation qui baisse d'année en année.
Autrement dit : même si Chrome garde ses cookies tiers indéfiniment, la donnée continue de se dégrader. Le sursis technique ne suspend rien.
Cookie tiers, cookie first-party, identifiant serveur : lever la confusion
La confusion est fréquente, y compris chez des équipes marketing expérimentées. Clarifions.
Le cookie tiers, c'est celui déposé par un domaine différent de celui que l'utilisateur visite. Le pixel Meta sur votre site e-commerce, par exemple. Sa fonction : reconnaître le même individu d'un site à l'autre. C'est précisément ce que les navigateurs tuent, et ce qui ne reviendra pas.
Le cookie first-party, lui, est posé par votre propre domaine. Il survit. Mais avec une nuance qui change tout : s'il est posé en JavaScript côté navigateur, Safari le limite à sept jours. Posé en HTTP par votre serveur, depuis un sous-domaine que vous contrôlez, il peut vivre bien plus longtemps. Même finalité, même nom de cookie, durée de vie radicalement différente. Tout le pari du server-side tient dans cette nuance.
L'identifiant serveur, enfin, ne repose sur aucun cookie. C'est votre propre identifiant client, généré et stocké chez vous, rattaché à un compte ou à un e-mail. Il ne dépend d'aucun navigateur. Il ne s'efface pas.
Voici la correspondance à garder en tête :
- Retargeting cross-site → cookie tiers → mort, à remplacer par les APIs de conversion et les audiences de première main.
- Mesure d'audience simple → cookie first-party → survit, mais avec fenêtre de rétention réduite côté Safari.
- Attribution multi-touch sur cycle long → cookie first-party JS → très dégradé, sauf passage en server-side.
- Reconnaissance client fidèle → identifiant serveur ou login → intact, et c'est le seul mécanisme qui gagne en valeur avec le temps.
- Mesure des campagnes payantes → mixte → dépend entièrement du Consent Mode et des APIs serveur.
Les pertes chiffrées que subit un site non préparé
Comment reconnaître un site qui subit la perte de signal sans le savoir ? Les symptômes sont assez caractéristiques, et ils se lisent directement dans le compte Analytics.
Le premier, le plus parlant : la part de trafic « direct » qui gonfle sans raison. Quand un site passe de 15 à 30 % de direct en dix-huit mois sans avoir gagné en notoriété, ce n'est pas une hausse de notoriété. C'est de l'attribution perdue, du trafic dont la source a été effacée en cours de route.
Le deuxième : l'écart entre les commandes du back-office et celles remontées dans l'outil. Sur les audits menés ces derniers mois, cet écart oscille entre 20 et 45 % selon le mix d'audience. Un e-commerce avec beaucoup de trafic iOS et un taux de consentement à 65 % ne verra jamais plus de deux tiers de ses conversions réelles.
Le troisième, souvent le plus douloureux financièrement : les audiences de remarketing qui fondent. Vous aviez 40 000 visiteurs en liste il y a un an, vous en avez 12 000 aujourd'hui, à trafic constant. La fenêtre de rétention s'est raccourcie, les cookies s'effacent plus vite, la liste ne se remplit plus assez vite pour compenser.
Et il y a un quatrième symptôme, plus insidieux : les campagnes payantes qui semblent moins performantes qu'avant, alors qu'elles performent identiquement. On coupe des campagnes rentables sur des chiffres faux. C'est probablement le coût caché le plus élevé de toute cette histoire.
Couche 1 : le consentement, faire de la CMP un actif et pas une case à cocher
Ce que la CNIL exige réellement, et ce qu'elle tolère
Commençons par le socle réglementaire, parce que tout le reste en découle.
Les exigences sont connues et assez stables : le refus doit être aussi simple que l'acceptation (donc un bouton « Tout refuser » au même niveau visuel que « Tout accepter »), pas de bandeau qui bloque la navigation de façon abusive, une granularité par finalité, et une preuve de consentement conservée et horodatée.
Mais il existe un levier largement sous-exploité, et c'est probablement l'information la plus rentable de cet article : l'exemption pour la mesure d'audience. La CNIL admet qu'un traceur de mesure d'audience puisse être dispensé de consentement, sous conditions strictes. À savoir : finalité limitée à la mesure d'audience du site, pas de recoupement avec d'autres traitements, pas de transmission à des tiers, données pseudonymisées, durée de conservation limitée (13 mois pour les traceurs, 25 mois pour les données), et périmètre restreint à un seul site.
Concrètement, cela signifie qu'un site correctement configuré peut mesurer 100 % de son audience, y compris les visiteurs qui refusent les cookies publicitaires. Matomo en configuration exemptée, Piano Analytics, ou d'autres solutions certifiées permettent d'y accéder. Google Analytics 4, non — et c'est une différence structurante, pas un détail de configuration.
Réfléchissez-y une seconde. Un site à 65 % de consentement qui bascule sa mesure d'audience en solution exemptée passe à 100 % de données réelles. Pas modélisées. Réelles. Aucune technologie de modélisation ne fera jamais mieux que ça.
Optimiser le taux de consentement sans tricher
L'autre levier, complémentaire, c'est le taux de consentement lui-même. Et là, le terrain de jeu est plus large qu'on ne le croit.
Ce qui fonctionne, testé et retesté : une formulation courte, qui explique ce qu'on fait de la donnée en une phrase compréhensible, pas un pavé juridique. Un bandeau en bas plutôt qu'une modale plein écran (moins agressif, donc moins de refus réflexe). Un délai d'affichage de quelques centaines de millisecondes après le chargement, le temps que l'utilisateur voie qu'il est arrivé quelque part de crédible. Et une mention de la valeur rendue, du type « pour améliorer votre expérience et nos contenus », plutôt qu'une formulation défensive.
Ce qui ne fonctionne pas, ou plus : le dark pattern. Le bouton refus grisé, le lien minuscule en bas, la double couche pour refuser. Au-delà du risque de sanction, ça produit un consentement de mauvaise qualité, cliqué par exaspération, souvent suivi d'un retrait ultérieur.
Un chiffre pour fixer les idées : passer de 62 à 78 % de consentement sur un site à 300 000 sessions mensuelles, c'est près de 50 000 sessions supplémentaires réellement mesurées chaque mois. Aucune modélisation Google ne restitue une donnée de cette qualité. Un point de consentement gagné vaut plus que trois mois de tuning de Consent Mode.
TCF, Google Consent Mode v2 et les signaux obligatoires
Depuis mars 2024, tout annonceur diffusant via Google Ads dans l'Espace Économique Européen doit transmettre les signaux du Consent Mode v2. Ce n'est pas une recommandation, c'est une condition d'accès aux fonctionnalités.
La v2 ajoute deux paramètres aux quatre existants : ad_user_data, qui indique si les données utilisateur peuvent être envoyées à Google à des fins publicitaires, et ad_personalization, qui autorise ou non la personnalisation publicitaire et le remarketing.
Un paramétrage bâclé ici a des conséquences immédiates et brutales. Si ad_personalization reste sur denied par erreur pour tout le monde, les audiences de remarketing cessent purement et simplement de se remplir. On l'a constaté chez un annonceur qui cherchait pendant six semaines pourquoi ses listes stagnaient : une valeur par défaut jamais mise à jour par la CMP. Six semaines de remarketing perdues sur une ligne de configuration.
Couche 2 : le Consent Mode, ses promesses et ses limites
Mode basique contre mode avancé, l'arbitrage structurant
C'est probablement la décision la plus discutée du chantier, et celle sur laquelle beaucoup de prestataires restent prudemment neutres. Prenons position.
En mode basique, les balises Google ne se déclenchent pas du tout avant le consentement. Rien n'est envoyé. Si l'utilisateur refuse, Google ne reçoit strictement aucun signal, pas même anonyme. La modélisation ne s'appuie alors que sur les données consenties, et sa qualité s'en ressent nettement.
En mode avancé, les balises se chargent immédiatement et envoient des pings sans cookie, sans identifiant, contenant des informations agrégées (page vue, horodatage, données techniques). Google dispose alors d'un volume bien supérieur pour modéliser les conversions manquantes.
La question juridique est réelle : ces pings sont-ils un traitement soumis à consentement ? La position dominante des juristes spécialisés est qu'en l'absence d'identifiant et de lecture d'informations stockées sur le terminal, l'article 82 de la loi Informatique et Libertés ne s'applique pas. La CNIL n'a pas explicitement tranché, ce qui laisse une zone grise.
Notre recommandation, en fonction du profil :
- E-commerce ou site à forte dépendance Google Ads : mode avancé, avec une documentation claire du raisonnement juridique dans le registre des traitements. Le gain de mesure est trop important pour s'en priver.
- Secteur sensible (santé, données personnelles, secteur public, banque-assurance) : mode basique. La zone grise n'est pas un endroit où se placer quand on traite des données sensibles.
- Site B2B ou vitrine à faible volume publicitaire : mode basique, et concentrer l'effort sur une solution analytics exemptée. La modélisation ne s'activera de toute façon pas.
Comment fonctionne la modélisation comportementale de Google
Le principe est plus simple qu'il n'y paraît. Google observe le comportement des utilisateurs consentants, en tire des modèles statistiques, et applique ces modèles aux pings anonymes des non-consentants pour estimer les conversions manquantes.
Deux conditions techniques doivent être remplies pour que ça s'active : au moins 1 000 événements par jour avec analytics_storage="denied" pendant sept jours, et au moins 1 000 utilisateurs quotidiens sur au moins sept des derniers vingt-huit jours. En dessous, rien ne se passe. Beaucoup de sites paramètrent minutieusement leur Consent Mode avancé sans jamais atteindre ces seuils, et attendent une modélisation qui ne viendra jamais.
Et voici la limite que les présentations commerciales oublient volontiers : la modélisation ne remplit que les rapports agrégés. Vos totaux de conversion, votre trafic global. Pas les segments. Pas les audiences exportables vers Google Ads. Pas l'exploration au niveau utilisateur. Pas BigQuery. Vous obtenez un chiffre de synthèse plus juste, ce qui est déjà appréciable, mais rien d'actionnable finement.
Les pièges d'implémentation les plus fréquents
Sur la dizaine d'implémentations auditées cette année, les mêmes erreurs reviennent avec une régularité presque comique.
Le classique numéro un : les balises se déclenchent avant l'initialisation du Consent Mode. La CMP se charge de façon asynchrone, GTM part plus vite, et les premières balises envoient des données sans signal de consentement. Il faut impérativement que le script d'initialisation soit placé avant le conteneur GTM, en dur dans le <head>.
Le classique numéro deux : les états par défaut oubliés. Sans default explicite, Google considère le consentement comme accordé. Ce qui est exactement l'inverse de ce que demande le RGPD.
Le troisième : la région EEE mal déclarée, ou pas déclarée du tout, qui applique les règles européennes au monde entier (ou l'inverse, plus problématique).
Le quatrième, plus subtil : l'absence de wait_for_update. Sans ce délai, généralement fixé entre 500 et 2 000 millisecondes, les balises partent avant que la CMP ait eu le temps de communiquer le choix réel de l'utilisateur.
Pour vérifier, la méthode est simple et prend dix minutes. Ouvrez l'onglet réseau de votre navigateur, filtrez sur les requêtes vers Google, et regardez les paramètres gcs et gcd. Le paramètre gcs vous donne l'état du consentement au moment de l'envoi : G100 signifie tout refusé, G111 tout accordé. Si vous voyez G111 alors que vous venez de tout refuser, vous avez trouvé votre bug. Tag Assistant et le mode debug de GTM complètent utilement le diagnostic.
Couche 3 : le tracking server-side, reprendre la main sur la donnée
Ce que le server-side résout, et ce qu'il ne résout pas
Mettons d'emblée les choses au clair, parce que c'est une confusion qui circule et qui expose juridiquement ceux qui y croient : le server-side n'est pas un contournement du consentement. Si un utilisateur refuse, vous ne devez pas envoyer ses données à Meta ou à Google, que ce soit depuis son navigateur ou depuis votre serveur. Changer de canal technique ne change rien à l'obligation légale.
Ce que le server-side apporte réellement, en revanche, mérite l'investissement.
D'abord, la durée de vie des cookies. Un cookie posé en HTTP depuis votre propre sous-domaine échappe à la limitation à sept jours de l'ITP. On passe de sept jours à treize mois. Sur un cycle d'achat B2B de six semaines, ça fait toute la différence entre mesurer et deviner.
Ensuite, la résistance aux bloqueurs. Entre 15 et 25 % des utilisateurs français utilisent un bloqueur de publicité qui neutralise les requêtes vers google-analytics.com. Une requête vers metrics.votresite.fr passe sans encombre.
Troisième bénéfice, souvent négligé : la performance. Déporter les balises côté serveur allège le navigateur, réduit le JavaScript exécuté et améliore les Core Web Vitals. Sur des sites chargés en balises, on observe des gains de 200 à 600 ms sur le LCP. Ce qui, accessoirement, est aussi un signal SEO.
Enfin, et c'est peut-être le plus important stratégiquement : la maîtrise de ce qui sort. Avec un conteneur serveur, vous décidez précisément quelles données partent vers quelle plateforme. Vous pouvez filtrer, anonymiser, tronquer. En client-side, le pixel Meta collecte ce qu'il veut et vous n'avez aucune visibilité dessus.
Les architectures possibles et leur coût réel
Trois grandes familles, avec des profils de coût très différents.
Server-side GTM auto-hébergé sur Google Cloud. Contrôle total, mais il faut gérer soi-même le scaling, les certificats, la supervision. Compter 80 à 150 € par mois d'infrastructure pour un site à 100 000 sessions, davantage au-delà. Nécessite une compétence DevOps réelle en interne ou chez le prestataire. Le piège classique : une configuration minimale à deux instances qui s'effondre le jour d'un pic de trafic, typiquement pendant le Black Friday.
Solutions managées (Stape, Addingwell, JENTIS). Le rapport effort/résultat est nettement meilleur pour la grande majorité des sites. Entre 20 et 200 € par mois selon le volume, avec l'infrastructure, le scaling et le sous-domaine gérés. Addingwell a l'avantage d'un hébergement européen, ce qui simplifie sensiblement le discours RGPD. Le contre-argument, réel : une dépendance de plus.
Briques open source (Snowplow, RudderStack en version communautaire). Puissantes, très flexibles, mais elles supposent une équipe data en interne. À réserver aux structures qui ont déjà un data engineer, sinon le coût de maintenance dépasse largement l'économie de licence.
Pour donner des repères budgétaires globaux, mise en place comprise : un site jusqu'à 50 000 sessions mensuelles s'en sort autour de 3 000 à 6 000 € de setup et 30 à 60 € par mois. Entre 50 000 et 500 000 sessions, comptez 6 000 à 15 000 € de setup et 80 à 250 € par mois. Au-delà, on entre dans du sur-mesure et les fourchettes n'ont plus grand sens.
Le sous-domaine first-party, le détail technique qui fait tout
Ce point mérite qu'on s'y arrête, parce qu'il conditionne la totalité du bénéfice.
Votre conteneur serveur doit être servi depuis un sous-domaine de votre site : gtm.votresite.fr, metrics.votresite.fr, peu importe le nom. Si vous utilisez l'URL par défaut fournie par votre hébergeur de conteneur, vous êtes en contexte tiers, et les cookies posés retombent sous les restrictions des navigateurs. Vous avez payé un server-side pour obtenir exactement le comportement d'un client-side. Ça arrive plus souvent qu'on ne l'imagine.
Techniquement, il faut un enregistrement DNS (A ou CNAME selon la solution) pointant vers l'infrastructure du conteneur, et un certificat SSL valide sur ce sous-domaine. La plupart des solutions managées provisionnent le certificat automatiquement via Let's Encrypt.
Deux erreurs classiques à éviter. Un CNAME pointant vers un domaine tiers : Safari détecte le cloaking CNAME et applique quand même une limitation à sept jours. Et le mélange de domaines, quand le site tourne sur votresite.com mais que le conteneur est sur tracking.votresite.fr : ce sont deux domaines distincts, donc contexte tiers, donc bénéfice nul.
APIs de conversion : Meta CAPI, Enhanced Conversions, TikTok Events API
C'est le prolongement naturel du server-side, et c'est là que les gains sur les campagnes payantes se matérialisent vraiment.
Le principe : au lieu d'envoyer les conversions depuis le navigateur (bloquable, tronqué, dégradé), vous les envoyez depuis votre serveur, avec des données utilisateur hachées permettant à la plateforme de faire la correspondance avec son propre référentiel.
Trois points de vigilance.
Le hachage, d'abord. Les données doivent être normalisées avant d'être hachées : minuscules, espaces supprimés, format international pour les numéros de téléphone. Un e-mail haché sans normalisation préalable ne matchera jamais. C'est une source d'échec silencieux extrêmement fréquente, parce que rien ne remonte d'erreur : le taux de correspondance est simplement mauvais et personne ne sait pourquoi.
La déduplication, ensuite. Si vous envoyez la même conversion en client-side et en server-side, elle sera comptée deux fois, sauf si vous transmettez un identifiant d'événement commun aux deux envois. Meta utilise event_id, Google son transaction_id. Sans ça, vos ROAS deviennent fantaisistes et vos décisions d'arbitrage budgétaire avec.
La base légale, enfin. Envoyer une adresse e-mail hachée à Meta reste un transfert de donnée personnelle vers un tiers publicitaire. Le hachage est une pseudonymisation, pas une anonymisation. Il faut le consentement, il faut que ce soit mentionné dans la politique de confidentialité, et le transfert hors UE doit être encadré. Un prestataire qui vous propose de « contourner le consentement grâce à CAPI » vous expose. Passez votre chemin.
Les analytics alternatives : quand quitter Google Analytics devient rationnel
Le critère de décision, avant le comparatif d'outils
La plupart des comparatifs commencent par les outils. C'est l'erreur. Ils devraient commencer par les besoins, parce que le même outil peut être un excellent choix pour un site et une erreur coûteuse pour un autre.
Cinq critères, à trancher dans cet ordre :
- Avez-vous besoin de mesurer 100 % de votre audience ? Si oui, il vous faut une solution éligible à l'exemption CNIL. Ce seul critère élimine déjà GA4.
- Avez-vous besoin de données au niveau utilisateur individuel ? Parcours détaillés, cohortes, entonnoirs personnalisés. Si non, une solution légère suffit largement.
- Quelle est votre dépendance à Google Ads ? Si le payant Google représente 60 % de votre acquisition, quitter GA4 complique l'import de conversions et la modélisation d'enchères.
- Avez-vous des contraintes d'hébergement ? Secteur public, santé, marché réglementé : l'hébergement européen ou l'auto-hébergement peuvent être non négociables.
- Quel budget récurrent ? Certaines solutions passent de gratuites à quatre chiffres mensuels selon le volume.
Panorama comparé des solutions crédibles
Matomo. La référence de l'exemption CNIL. En version auto-hébergée, la donnée reste chez vous, la personnalisation est totale, et le coût se limite à l'hébergement. En version cloud, comptez de 26 à plusieurs centaines d'euros par mois. Ce qu'on gagne : la mesure de 100 % du trafic, la propriété des données, une interface proche de l'ancien Universal Analytics (que beaucoup regrettent encore). Ce qu'on perd : l'intégration native à Google Ads, et un peu de confort d'analyse par rapport à GA4 sur les gros volumes. Pour qui : à peu près tout le monde, franchement, et en priorité les sites à fort trafic organique.
Piano Analytics (ex-AT Internet). Solution française, exemption CNIL disponible, très solide sur les gros volumes et les organisations complexes. Ce qu'on gagne : la robustesse, le support en français, la conformité par construction. Ce qu'on perd : le prix, qui démarre haut, et une courbe d'apprentissage réelle. Pour qui : les grands comptes, les médias, les acteurs institutionnels.
Plausible et Fathom. Le segment léger, sans cookie du tout. Un script de moins de 1 Ko, un tableau de bord d'une seule page, aucune donnée personnelle collectée. Ce qu'on gagne : la simplicité absolue, l'exemption de bandeau, une performance imbattable. Ce qu'on perd : tout ce qui relève de l'analyse fine, des entonnoirs complexes, du suivi individuel. Pour qui : les sites vitrines, les blogs, les SaaS en amorçage, et tous ceux qui regardent en réalité cinq indicateurs par mois. Beaucoup de sites tirent 90 % de la valeur de leur analytics de Plausible et pourraient s'épargner GA4.
Simple Analytics. Positionnement voisin, hébergement néerlandais, une orientation encore plus marquée sur la confidentialité. Même profil d'usage.
L'entrepôt propriétaire (collecte maison vers BigQuery ou équivalent). C'est l'option des structures matures. Vous collectez vos événements, vous les stockez chez vous, vous construisez vos propres modèles d'attribution. Contrôle total, coût marginal faible au volume, mais il faut une équipe data. Ce n'est pas un projet analytics, c'est un projet data. Ne pas le lancer sans en avoir conscience.
La question de la migration : coexistence plutôt que bascule
Une recommandation ferme, issue de trop de migrations douloureuses : ne coupez jamais l'ancien outil du jour au lendemain. Faites tourner les deux en parallèle pendant au moins trois mois, idéalement six.
Pourquoi ? Parce que les chiffres ne coïncideront jamais. Jamais. Et ce n'est pas un bug.
Les définitions de session diffèrent d'un outil à l'autre. GA4 rouvre une session à minuit ou au changement de source, Matomo utilise une inactivité de 30 minutes par défaut. Les filtrages de robots ne reposent pas sur les mêmes listes. Et surtout, le traitement du consentement change tout : Matomo en mode exempté mesure tout le monde, GA4 mesure les consentants plus une modélisation. Sur un site à 70 % de consentement, l'écart peut dépasser 35 % sur les sessions.
Plutôt que de chercher une impossible égalité, établissez un coefficient de réconciliation. Sur trois mois de données parallèles, vous obtiendrez un ratio stable, par exemple 1,38 entre Matomo et GA4 sur les sessions. Ce coefficient vous permet de raccorder l'historique et de continuer à lire vos séries longues sans rupture. C'est pragmatique, c'est suffisant, et ça évite des semaines de débat stérile en comité de pilotage.
Les techniques d'identification qui prennent le relais
Le first-party data comme socle
Si vous ne deviez retenir qu'une seule chose de tout cet article, ce serait celle-ci : la seule stratégie de mesure qui prend de la valeur avec le temps, c'est la donnée que vous collectez vous-même, avec l'accord explicite de vos utilisateurs, en échange de quelque chose qui a de la valeur pour eux.
Toutes les autres approches sont défensives. Elles limitent la perte. Celle-ci construit un actif.
Comment ? Par la valeur rendue, pas par le formulaire imposé. Un compte client qui donne accès à l'historique de commandes et à un suivi de livraison. Une newsletter qui apporte réellement quelque chose. Une wishlist qui se retrouve d'un appareil à l'autre. Un devis en ligne, un configurateur qu'on sauvegarde, un contenu premium. Chacun de ces mécanismes vous donne un e-mail et, surtout, un identifiant persistant.
Cet identifiant, une fois posé, vous permet de reconnaître le visiteur sur mobile puis sur desktop, de reconstituer un parcours complet même à trois semaines d'intervalle, et d'alimenter vos APIs de conversion avec un taux de correspondance élevé. Aucun navigateur ne peut l'effacer. Aucune décision de Google ne peut le remettre en cause.
Un e-commerce qui passe de 12 à 35 % de commandes réalisées en compte identifié ne gagne pas seulement en fidélisation. Il gagne une base de mesure stable pendant que tout le reste s'érode.
Ce qu'il faut savoir sur le fingerprinting
Le sujet revient régulièrement, souvent porté par des prestataires enthousiastes. Autant être direct.
Le fingerprinting consiste à identifier un navigateur par la combinaison de ses caractéristiques techniques : résolution, polices installées, version, fuseau horaire, rendu du canvas. Aucun cookie, aucun stockage, et un taux d'unicité qui peut dépasser 90 %.
Techniquement, ça fonctionne. Juridiquement, c'est un terrain très exposé. Le RGPD ne parle pas de cookies, il parle de traitement de données personnelles. Un identifiant unique reconstitué à partir de caractéristiques techniques reste un identifiant unique, et l'article 82 vise l'accès à des informations stockées sur le terminal, ce qui couvre largement les techniques de fingerprinting. L'EDPB l'a confirmé, la CNIL également.
En février 2025, Google a levé son interdiction du fingerprinting côté annonceurs, ce qui a été interprété par certains comme un feu vert. Ce n'en est pas un. La politique commerciale d'une régie publicitaire ne modifie pas le droit européen. L'ICO britannique a d'ailleurs réagi publiquement pour rappeler que cette pratique restait soumise aux mêmes exigences de transparence et de consentement.
Un prestataire qui vous propose le fingerprinting comme solution au tracking sans cookies vous propose un risque, pas une solution. La différence entre les deux tient rarement plus de deux ans.
Privacy Sandbox, Topics API et data clean rooms
Faisons le point sans survendre, parce que ce sujet a produit beaucoup de littérature et peu d'adoption.
La Topics API attribue à chaque navigateur quelques centres d'intérêt calculés localement à partir de l'historique, et les partage avec les annonceurs sans révéler les sites visités. C'est disponible dans Chrome. L'adoption côté acheteurs média reste marginale, parce que le ciblage obtenu est bien plus grossier que ce que permettaient les cookies tiers. La Protected Audience API, pour le remarketing, souffre du même décalage entre disponibilité technique et usage réel.
Le verdict est assez simple : ne construisez pas votre stratégie 2026 sur Privacy Sandbox. Suivez le sujet, ne l'attendez pas.
Les data clean rooms, en revanche, ont un cas d'usage bien réel, mais restreint. Il s'agit d'environnements sécurisés où deux acteurs croisent leurs données sans jamais y accéder mutuellement : un annonceur et un retailer, par exemple, pour mesurer l'impact réel d'une campagne sur les ventes en magasin. Google Ads Data Hub, Amazon Marketing Cloud, LiveRamp. C'est puissant, c'est coûteux, et ça suppose déjà d'avoir une base de données propriétaire conséquente. Réservé aux gros annonceurs, et sans intérêt pour un site à 200 000 sessions annuelles.
Feuille de route opérationnelle : par où commencer selon votre site
Phase 1 : audit et mesure de la perte actuelle
Impossible de piloter ce qu'on ne mesure pas. Avant tout investissement, il faut chiffrer la perte.
Quatre relevés à faire. Le taux de consentement réel, remonté par votre CMP (et non estimé au doigt mouillé). L'écart entre les conversions trackées et les conversions du back-office, sur trois mois glissants. L'inventaire complet des balises actives avec leur finalité déclarée, exercice pendant lequel on découvre systématiquement deux ou trois pixels dont plus personne ne se souvient. Et la durée de vie effective de vos cookies dans Safari, vérifiable en trois minutes dans l'inspecteur.
Durée : une à deux semaines. Compétences : analytics et un peu de technique. Indicateur de réussite : vous pouvez énoncer, en une phrase, le pourcentage de vos conversions que vous ne voyez pas.
Phase 2 : sécuriser la conformité et le Consent Mode
C'est le socle, et l'ordre n'est pas négociable.
Au programme : audit de conformité de la CMP, refonte du bandeau pour optimiser le taux d'acceptation, implémentation ou correction du Consent Mode v2, choix argumenté entre basique et avancé, et documentation du paramétrage dans le registre des traitements.
Durée : deux à quatre semaines. Compétences : juridique, UX, technique GTM. Indicateur de réussite : le taux de consentement progresse d'au moins cinq points, et les paramètres gcs reflètent fidèlement les choix utilisateurs.
Phase 3 : basculer la collecte en server-side
Choix de l'architecture, configuration du sous-domaine first-party, migration progressive des balises, mise en place des APIs de conversion avec déduplication, période de double collecte pour valider les écarts.
Durée : quatre à huit semaines selon la complexité. Compétences : GTM avancé, un peu de DevOps, connaissance des plateformes publicitaires. Indicateur de réussite : les cookies dépassent sept jours dans Safari, et les conversions remontées dans Meta ou Google Ads progressent de 15 à 30 %.
Phase 4 : construire la donnée propriétaire
C'est la phase la plus longue, la moins technique, et de loin la plus rentable à horizon trois ans. Stratégie de collecte d'e-mails par la valeur, mise en place d'un identifiant utilisateur persistant, réconciliation cross-device, alimentation des APIs de conversion avec des données identifiées.
Durée : continue. Compétences : marketing, produit, CRM, technique. Indicateur de réussite : la part de sessions identifiées augmente trimestre après trimestre.
Un mot sur l'ordre, parce que c'est là que se jouent les échecs. Ne passez jamais au server-side avant d'avoir réglé le consentement. Vous obtiendriez une infrastructure impeccable qui collecte les mêmes 65 % de données qu'avant, avec une facture mensuelle en plus. On a vu des projets à 20 000 € produire un gain de mesure de quatre points, uniquement parce que la CMP n'avait jamais été touchée. Et ne choisissez pas votre outil analytics avant d'avoir tranché la question de l'exemption : c'est ce critère qui commande le choix, pas l'inverse.
Ce que ça change pour le pilotage SEO et acquisition
Attribution : accepter l'incertitude et changer d'indicateurs
Voilà le point qui fait grincer en comité de direction. L'attribution déterministe multi-touch, celle qui reconstituait proprement le parcours complet de chaque visiteur, appartient au passé. Elle ne reviendra pas.
Ce qui la remplace est moins élégant, mais plus honnête : un pilotage à trois étages. Les données consentues, fiables, sur lesquelles on peut analyser finement. La modélisation, imprécise mais utile pour les tendances agrégées. Et la mesure incrémentale, qui devient la référence pour les décisions importantes.
La mesure incrémentale, concrètement, c'est simple : vous coupez une campagne sur une région pendant trois semaines, vous comparez avec les régions témoins, et vous observez l'écart réel de chiffre d'affaires. Pas d'attribution, pas de cookie, pas de modèle. Juste une observation de l'effet réel. C'est plus lent, ça demande de la discipline, et c'est infiniment plus fiable que n'importe quel modèle d'attribution.
Les indicateurs à privilégier suivent la même logique : le coût d'acquisition global rapporté au chiffre d'affaires total plutôt que par canal, l'évolution du taux de nouveaux clients, la valeur vie client par cohorte d'acquisition, les tests d'incrémentalité sur les gros postes budgétaires. Moins granulaire, moins satisfaisant intellectuellement, mais résistant à la perte de signal.
Le SEO devient un canal comparativement mieux mesuré
Il y a une conséquence de tout ceci que peu de monde a formulée, et qui mérite qu'on s'y attarde.
La Search Console ne dépend pas du consentement. Pas du tout. Les impressions, les clics, les positions, les requêtes : Google collecte ces données côté serveur, dans son index. Aucun bandeau, aucune CMP, aucun ITP ne les affecte. Un site à 60 % de consentement dispose de 100 % de sa donnée organique.
Faites le calcul. Sur les campagnes payantes, vous mesurez peut-être 65 % des conversions, avec une modélisation qui comble partiellement le reste et une attribution incertaine. Sur l'organique, vous disposez de la totalité du signal de visibilité, mesuré à la source.
Dans un environnement où le signal se dégrade partout ailleurs, la fiabilité relative de la donnée SEO augmente mécaniquement. Ce qui devrait, logiquement, peser dans les arbitrages budgétaires. Un canal qu'on mesure bien est un canal qu'on optimise bien.
Ce n'est pas un argument pour tout basculer sur le SEO du jour au lendemain, évidemment. Mais quand la mesure du payant devient floue et coûteuse à fiabiliser, la question du rééquilibrage se pose sérieusement. Beaucoup d'annonceurs ne l'ont pas encore posée.
Choisir son prestataire digital sur ce sujet : la grille de questions
Le marché du server-side attire beaucoup de monde depuis deux ans, avec des niveaux de maîtrise très inégaux. Voici les questions à poser avant de signer, et surtout ce que chaque réponse révèle.
« Réalisez-vous le paramétrage server-side en interne ou le sous-traitez-vous ? » Une sous-traitance n'est pas disqualifiante en soi, mais elle doit être assumée. Un prestataire qui élude cette question aura du mal à intervenir en urgence le jour où le conteneur tombe pendant les soldes.
« Pouvez-vous me montrer la documentation d'une implémentation précédente ? » La réponse révèle immédiatement le niveau de rigueur. Un paramétrage non documenté est un paramétrage que personne ne pourra reprendre, y compris chez eux dans six mois.
« À qui appartient le conteneur serveur, et qui détient les accès administrateur ? » Question essentielle. Certains prestataires hébergent tout sur leur propre compte, ce qui transforme la fin de contrat en négociation. Le conteneur, le compte cloud et le sous-domaine doivent être à votre nom.
« Comment gérez-vous l'articulation entre consentement et envois server-side ? » Si la réponse évoque un contournement du consentement, arrêtez l'entretien. Ce n'est pas une position agressive, c'est une protection : c'est vous qui serez responsable de traitement en cas de contrôle, pas eux.
« Prévoyez-vous une période de double collecte, et sur quelle durée ? » Un prestataire qui propose une bascule sèche n'a probablement jamais géré de migration réelle. Les écarts se découvrent uniquement en parallèle.
« Comment mesurez-vous le succès de la mission ? » Les bonnes réponses sont chiffrées : progression du taux de correspondance CAPI, hausse des conversions remontées, durée de vie effective des cookies. Les mauvaises réponses parlent de « mise en place ». Une mise en place n'est pas un résultat.
Chez FDSEO, ces sujets sont traités dans l'ordre décrit plus haut : conformité d'abord, infrastructure ensuite, outillage en dernier. Non par principe méthodologique, mais parce que l'inverse produit des factures sans effet mesurable, et qu'on préfère éviter cette conversation-là au troisième comité de pilotage.
FAQ
Le tracking sans cookies est-il vraiment sans cookies ?
Rarement, en fait. L'expression désigne surtout l'abandon des cookies tiers. La plupart des solutions dites « sans cookies » utilisent toujours des cookies first-party, simplement mieux maîtrisés et plus durables. Seules quelques solutions comme Plausible ou Fathom fonctionnent réellement sans aucun cookie, en renonçant au suivi individuel.
Le Consent Mode avancé est-il conforme au RGPD ?
La question n'a pas été tranchée explicitement par la CNIL. La position dominante considère que les pings anonymes, sans identifiant ni lecture du terminal, ne relèvent pas de l'article 82. Le risque reste faible mais non nul : documentez votre raisonnement dans le registre des traitements, et privilégiez le mode basique sur les secteurs sensibles.
Combien coûte une migration en server-side ?
Entre 3 000 et 6 000 € de mise en place pour un site jusqu'à 50 000 sessions mensuelles, avec 30 à 60 € par mois d'infrastructure. Comptez 6 000 à 15 000 € et 80 à 250 € mensuels au-delà. Le retour sur investissement vient principalement des conversions récupérées sur les campagnes payantes.
Faut-il quitter Google Analytics 4 ?
Pas nécessairement, mais il faut arbitrer. Si vous avez besoin de mesurer 100 % de votre audience, GA4 ne le permettra jamais et une solution exemptée s'impose. Si votre acquisition dépend fortement de Google Ads, gardez GA4 et complétez-le. La coexistence est souvent le meilleur choix.
Que se passe-t-il si je ne fais rien ?
La dégradation continue, lentement. Le trafic direct gonfle, les audiences de remarketing s'assèchent, l'écart entre conversions réelles et mesurées se creuse. Le vrai risque n'est pas de perdre de la donnée : c'est de prendre de mauvaises décisions budgétaires sur des chiffres faux, sans le savoir.
Conclusion
La fin des cookies tiers n'est pas une échéance technique à absorber. C'est un déplacement du terrain de jeu, et il favorise ceux qui possèdent leur donnée plutôt que ceux qui la louent aux plateformes.
Trois principes à retenir. La priorité absolue va au consentement, parce qu'un point gagné vaut plus que n'importe quelle modélisation. L'infrastructure vient ensuite, une fois le socle propre. L'outil arrive en dernier, et ce n'est pas une question de préférence mais de logique : le choix de l'outil découle des besoins de conformité, jamais l'inverse.
Et en toile de fond, ce chantier qui ne s'arrête jamais : la construction d'une base de données propriétaire, alimentée par de la valeur réelle rendue aux utilisateurs. C'est le seul actif de mesure qui s'apprécie avec le temps pendant que tout le reste se dégrade.
Reste à savoir où vous en êtes exactement. Un audit de perte de signal se réalise en quelques jours et donne un chiffre précis : le pourcentage de vos conversions que vous ne voyez pas. C'est généralement à ce moment-là que les arbitrages deviennent évidents.
