Suivi côté serveur et Consent Mode v2 : mesurer les conversions en conformité avec le RGPD

Le suivi côté serveur déplace le traitement des données du navigateur de l'utilisateur vers un serveur que vous contrôlez vous-même. Google Consent Mode v2 détermine, au moyen de quatre signaux de consentement, si et comment les balises Google peuvent collecter des données. Ensemble, ils permettent de continuer à mesurer les conversions alors que le blocage des cookies et le RGPD érodent le suivi classique par navigateur.

Qu'est-ce que le suivi côté serveur et quel rapport avec Consent Mode v2 ?

Le suivi côté serveur signifie que les données de suivi ne sont plus envoyées directement depuis le navigateur à Google, Meta et consorts, mais d'abord à un conteneur serveur placé sous votre contrôle. Consent Mode v2 est la couche distincte qui détermine si une collecte est seulement autorisée : Google Consent Mode permet d'adapter le comportement des balises Google et des SDK d'applications aux choix de consentement des utilisateurs (Google for Developers, état 2026). L'un est l'architecture technique, l'autre l'interrupteur juridique et fonctionnel. Pour mesurer ses conversions en conformité avec le RGPD, il faut en règle générale les deux.

Pourquoi le suivi classique par navigateur ne suffit-il plus ?

Le suivi classique par cookies tiers ne fonctionne plus de façon fiable dans les navigateurs modernes, car ces cookies y sont bloqués et rendus éphémères. Avec l'Intelligent Tracking Prevention (ITP), Safari bloque entièrement les cookies tiers par défaut et supprime l'espace de stockage inscriptible par script d'un site (y compris LocalStorage, IndexedDB et caches de Service Worker) après sept jours d'utilisation de Safari sans interaction avec le site (WebKit Blog, 2020).

Les cookies déposés côté client avaient eux aussi déjà été plafonnés à sept jours de durée de vie auparavant (WebKit Blog, 2020). Pour les annonceurs, cela signifie concrètement : un clic aujourd'hui et une conversion deux semaines plus tard ne peuvent souvent plus être attribués à la même personne en se limitant au côté client. Les conséquences sont des lacunes dans la mesure des conversions, des campagnes sous-estimées et un pilotage des enchères moins bon. Le suivi côté serveur et Consent Mode v2 répondent précisément à cette lacune.

Comment fonctionne Google Consent Mode v2 avec ses quatre signaux ?

Consent Mode v2 traduit le choix fait dans la bannière de cookies en quatre signaux lisibles par machine, que les balises Google évaluent avant toute collecte de données. Selon Google for Developers (état 2026), ce sont les quatre suivants :

• ad_storage contrôle le stockage lié à la publicité, par exemple le dépôt de cookies publicitaires.
• analytics_storage contrôle le stockage lié à l'analyse.
• ad_user_data régit le consentement à l'envoi de données utilisateur à Google à des fins publicitaires.
• ad_personalization régit le consentement à la publicité personnalisée.

Les deux signaux commençant par ad_, ad_user_data et ad_personalization, sont la nouveauté de la version 2 par rapport à la première version. Le principe : recueillir le consentement, communiquer le statut à Google et laisser les balises respecter ce choix (Google for Developers, état 2026).

Basic ou Advanced Consent Mode : quelle différence ?

La différence tient à ce que les balises Google sont soit entièrement bloquées avant le consentement, soit déjà autorisées à modéliser des données sans cookies. Les deux variantes mettent en œuvre le même système de signaux, mais se comportent de façon fondamentalement différente en l'absence de consentement (Google for Developers, état 2026).

La modélisation des conversions signifie que Google extrapole statistiquement, à partir des pings anonymes et sans cookies des utilisateurs qui n'ont pas donné leur consentement, le nombre de conversions qui ont probablement eu lieu. Advanced Consent Mode permet ainsi une modélisation améliorée et spécifique à la publicité des conversions et du comportement (Google for Developers, état 2026). La variante qui vous convient dépend de votre niveau d'exigence en matière de protection des données, de la configuration de votre bannière et de vos objectifs de mesure ; une mise en œuvre propre doit être confiée à des spécialistes Google Ads expérimentés.

Qu'est-ce que le Server-Side Tagging et comment fonctionne le conteneur serveur ?

Le Server-Side Tagging déplace le traitement des balises du navigateur vers un serveur contrôlé par l'exploitant. Contrairement au Client-Side Tagging, ce conteneur serveur ne s'exécute pas dans le navigateur ni sur l'appareil de l'utilisateur, mais sur un serveur que vous contrôlez (Google for Developers, état 2026).

Le déroulement : le conteneur serveur reçoit des requêtes, les convertit en événements et les traite avec des balises, des déclencheurs et des variables (Google for Developers, état 2026). Les données sont adressées via l'URL du conteneur, renseignée dans gtag.js sous le paramètre server_container_url. Point décisif pour la maîtrise des données : avec le Server-Side Tagging, seul l'exploitant a accès aux données présentes sur le serveur, jusqu'à ce qu'il les envoie ailleurs (Google for Developers, état 2026). Vous avez un contrôle total sur la manière dont les données sont mises en forme et sur leur destination.

Comment le suivi côté serveur améliore-t-il la mesure des conversions ?

Le suivi côté serveur améliore la mesure grâce à trois leviers : le contrôle des données, la protection des données et la performance. Dans le conteneur serveur, les données peuvent être vérifiées, validées et modifiées avant d'être transmises à des points de terminaison d'analyse et de publicité ou à des partenaires marketing (Google for Developers, état 2026).

Les données personnelles (PII) peuvent ainsi être supprimées avant d'être transmises à des tiers, ce qui rend la transmission des données plus facile à piloter. En outre, le Server-Side Tagging réduit la charge de traitement côté client et améliore la performance du site web (Google for Developers, état 2026). Comme les requêtes de suivi transitent par votre propre domaine first-party plutôt que par des points de terminaison de tiers, les mécanismes de protection des navigateurs les reconnaissent moins souvent que le suivi tiers — la qualité des données augmente.

Depuis quand Consent Mode v2 est-il obligatoire dans l'EEE et que se passe-t-il sans lui ?

Consent Mode v2 est obligatoire depuis le 6 mars 2024 pour les annonceurs qui s'adressent à des utilisateurs de l'Espace économique européen (EEE), Royaume-Uni compris. Pour le trafic de l'EEE, Google exige que les annonceurs recueillent le consentement des utilisateurs finaux et transmettent à Google les signaux de consentement ad_user_data et ad_personalization afin de pouvoir continuer à utiliser la mesure, la personnalisation et le remarketing (Google Ads Help, 2024).

Sans mise en œuvre, les nouveaux utilisateurs de l'EEE ne peuvent plus être intégrés aux listes d'audience et de remarketing, par exemple dans Google Ads, les audiences GA4 ou Floodlight (Google Ads Help, 2024). En pratique, cela signifie des audiences qui se réduisent et une moins bonne optimisation — une perte de performance directe, pas seulement un sujet de conformité.

Que signifie cela sur le plan du RGPD pour le consentement ?

Sur le plan du RGPD, la règle est la suivante : un consentement préalable et actif est requis pour les cookies et le suivi qui ne sont pas techniquement nécessaires. Dans l'arrêt Planet49 (aff. C-673/17, arrêt du 1.10.2019), la CJUE a jugé que le consentement au dépôt de cookies non techniquement nécessaires doit être donné par un comportement actif ; une case précochée ne constitue pas un consentement valable (CJUE / LfDI Baden-Württemberg, l'autorité de protection des données du Land de Bade-Wurtemberg).

En Allemagne, l'exigence de consentement pour les accès non nécessaires aux terminaux est inscrite à l'article 25 de la TDDDG (anciennement TTDSG, loi allemande sur la protection des données et de la vie privée dans les télémédias et les télécommunications). Selon l'autorité de contrôle, un consentement aux cookies de suivi doit être éclairé, libre, préalable, actif, distinct et révocable (LfDI Baden-Württemberg, état 2024). Pour les cookies purement fonctionnels et techniquement nécessaires, comme le panier d'achat, aucun consentement n'est requis. Cette présentation est une information générale et ne remplace pas un conseil juridique.

FAQ : suivi côté serveur et Consent Mode v2

Le suivi côté serveur remplace-t-il le consentement ?

Non. Le suivi côté serveur est une architecture technique, pas un fondement juridique. L'obligation de recueillir un consentement préalable et actif pour les cookies et le suivi non nécessaires demeure indépendamment de cela (CJUE Planet49, 2019 ; art. 25 TDDDG). L'endroit où vous traitez les données ne change rien à la question de savoir si vous avez le droit de les collecter.

Ai-je besoin de Consent Mode v2 et du suivi côté serveur ensemble ?

Pas obligatoirement, mais ils se complètent. Consent Mode v2 est obligatoire pour les annonceurs de l'EEE depuis le 6 mars 2024 (Google Ads Help, 2024). Le suivi côté serveur est facultatif, mais améliore le contrôle des données, la protection des données et la qualité de la mesure (Google for Developers, état 2026). Pour une mesure des conversions robuste et conforme au RGPD, la combinaison est courante.

Quelle est la différence entre ad_user_data et ad_personalization ?

ad_user_data régit le consentement à l'envoi de données utilisateur à Google à des fins publicitaires, ad_personalization le consentement à la publicité personnalisée (Google for Developers, état 2026). Les deux ont été ajoutés avec la version 2 et sont, pour le trafic de l'EEE, les nouveaux signaux décisifs.

Le suivi fonctionne-t-il encore sans aucun cookie ?

De façon limitée. En cas de refus du consentement, Advanced Consent Mode envoie des mesures sans cookies via des pings et permet ainsi une modélisation améliorée des conversions et du comportement (Google for Developers, état 2026). Cela ne remplace pas une mesure complète, mais comble statistiquement une partie de la lacune.

De quels outils ai-je besoin pour le Server-Side Tagging ?

Dans l'écosystème Google, le Server-Side Tagging passe par un conteneur serveur Google Tag Manager, qui est la solution standard. Il s'exécute sur un serveur que vous contrôlez, idéalement sous votre propre domaine first-party (Google for Developers, état 2026). La mise en place exige un hébergement, une server_container_url correctement configurée et une bannière de consentement adaptée.

Le suivi côté serveur réduit-il aussi le risque lié à l'ITP de Safari ?

En partie. Comme les requêtes transitent par votre domaine first-party et non par des points de terminaison tiers, certains mécanismes de protection des navigateurs s'appliquent moins souvent. La règle de l'ITP consistant à supprimer le stockage inscriptible par script après sept jours sans interaction (WebKit Blog, 2020) reste toutefois pertinente ; le suivi côté serveur est une réduction du risque, pas un passe-droit.

Conclusion

Le suivi côté serveur et Consent Mode v2 résolvent deux problèmes différents : le problème technique de la disparition des cookies et le problème juridique du consentement. Consent Mode v2 est obligatoire dans l'EEE depuis mars 2024, tandis que le Server-Side Tagging vous rend la maîtrise de vos données. Qui combine proprement les deux garde ses conversions mesurables — sans ignorer le RGPD. État : 2026. Information générale, pas un conseil juridique.

Sources

• Google for Developers — Consent mode overview (état 2026)
• Google for Developers — An introduction to server-side tagging (état 2026)
• Google for Developers — Server-side tagging overview (état 2026)
• WebKit Blog — Full Third-Party Cookie Blocking and More (ITP) (2020)
• Google Ads Help — Updates to consent mode for traffic in the EEA (2024)
• CJUE C-673/17 Planet49 / LfDI Baden-Württemberg — Cookies et bannières de cookies (2019 / état 2024)