Fin 2025, le paysage de la protection des données en Europe est plus exigeant que jamais. Après des années de jurisprudence post-Schrems II, et une vigilance accrue des autorités comme la CNIL, l'utilisation d'outils américains est devenue un exercice de haute précision.
C'est dans ce climat qu'un jugement du Tribunal administratif de Hanovre, daté du 19 mars 2025, est devenu le nouveau cas d'école pour l’ensemble du marché.
Sa conclusion est sans appel : charger le script Google Tag Manager (GTM) depuis l'infrastructure de Google requiert un consentement préalable.
Dissection du cas noz.de : l’exigence d’un consentement valide
Pour en comprendre toute la portée, revenons à son origine : le site web noz.de.
Comme de très nombreux sites, l'éditeur chargeait le script gtm.js depuis les serveurs de Google, via le domaine www.googletagmanager.com, et ce script GTM se chargeait ensuite d'appeler la CMP (bannière de consentement).
Conséquence directe : une communication était établie avec Google avant même que l'utilisateur n'ait pu exprimer son choix.
Le tribunal a également conclu que même après l’obtention du consentement, les traitements de données étaient privés de base légale valide, mais uniquement en raison de l’invalidité du consentement collecté par noz.de via sa CMP Sourcepoint.
Le tribunal n’a donc pas déclaré que l’utilisation de Google Tag Manager est illégale en soi, mais a jugé que son implementation sur noz.de était illicite, pour deux raisons cumulatives :
- Le consentement n'était pas recueilli préalablement au chargement de GTM.
- Quand un consentement était finalement recueilli via sa CMP Sourcepoint, de toute façon ce dernier était invalide, car il ne respectait pas certains critères du RGPD.
La conclusion du tribunal est donc d'une grande clarté : pour être licite, le chargement de GTM depuis l'infrastructure de Google doit être conditionné à un consentement préalable ET valide.
Nous ne nous éterniserons pas ici sur le critère de validité, qui est une évidence pour Sirdata, ses partenaires et ses clients. En revanche, nous allons creuser la question du consentement obligatoire...
Une surprise ? Non, pas vraiment
Cette exigence de consentement préalable semble refléter les conditions générales du service GTM :
De plus, les "Data Processing Terms" (DPA) de Google Ads confirment les traitements de données :
La conclusion est donc sans équivoque, et le jugement ne fait que rappeler à l'écosystème les obligations contractuelles fixées par Google lui-même. Le consentement n'est pas une simple formalité, mais bien la clé de voûte légitimant l'utilisation du script gtm.js chargé depuis l’infrastructure de Google.
Mais… pourquoi ?
Les Clés de Compréhension : Deux Verrous à Débloquer
Le tribunal fonde sa décision sur deux piliers distincts, qui agissent comme deux verrous. Le premier relève de la directive ePrivacy (la loi sur les "cookies et autres traceurs"), et le second du RGPD.
Nous ne sommes pas avocats et, par conséquent, nous ne pouvons pas vous fournir de conseils juridiques. En revanche, en tant qu’experts de l’articulation technique ↔ juridique, nous pouvons expliciter le sous-jacent technologique de cette décision et proposer des actions techniques concrètes pour optimiser vos implémentations au regard de cette nouvelle jurisprudence.
Verrou n°1 : Le Stockage sur le Terminal (Directive ePrivacy)
gtm.js depuis le domaine www.googletagmanager.com entraîne un "enregistrement local" dans le navigateur de l'utilisateur.Or, la loi ePrivacy est formelle : toute opération d'accès ou de stockage d'information sur le terminal d'un utilisateur requiert son consentement. Une exception est possible, si cette opération est "strictement nécessaire" à la fourniture du service demandé.
Mais le tribunal a jugé que GTM, servant les intérêts de l'éditeur du site et non une fonction demandée par le visiteur, ne remplit pas cette condition : un consentement est nécessaire.
L'explication technique : le header "Cache-Control", cousin du cookie. Comment cet "enregistrement" a-t-il lieu alors qu'aucun cookie ne soit déposé ? La réponse se trouve dans les en-têtes de la réponse serveur de Google, et plus précisément dans la directive HTTP "Cache-Control: private".
Lorsque l'infrastructure Google renvoie le script gtm.js vers le navigateur, il donne des directives à ce dernier via ce qu’on appelle les en-têtes HTTP. Même si vous n'êtes pas familier avec ces headers, vous en connaissez déjà un, peut-être sans en connaître le nom : "Set-Cookie". C’est celle qui donne l’ordre au navigateur de créer et stocker un cookie.
Il faut voir la directive "Cache-Control: private" comme une instruction de même nature. Elle ordonne au navigateur de conserver une copie du script gtm.js dans une mémoire qui lui est propre (son cache "privé"). Cette instruction matérialise donc un stockage sur le terminal.
Techniquement, il est possible d'utiliser ce mécanisme pour stocker un identifiant unique sur un terminal, et suivre spécifiquement un utilisateur, tout comme avec un cookie. C'est pourquoi il tombe dans la catégorie des "autres traceurs" visés par la loi.
En résumé : même sans cookie, selon le jugement, l'acte de stockage est avéré et requiert un consentement.
Verrou n°2 : La Transmission de l'Adresse IP (RGPD)
www.googletagmanager.com entraîne la transmission de l'adresse IP de l'utilisateur à Google, qui opère l'infrastructure recevant cette requête.L'adresse IP étant une donnée personnelle, sa collecte et son enregistrement (ne serait-ce que dans les logs serveur) constituent un traitement de données à caractère personnel soumis au RGPD.
Google étant un acteur majeur dont le modèle économique repose sur l'exploitation de données à des fins publicitaires, le tribunal estime que ce traitement doit s'appuyer sur le consentement.
L'analyse juridique : pour être licite, un traitement doit reposer sur une base légale, comme le consentement ou l'intérêt légitime de l'éditeur du site par exemple.
Lorsque l'adresse IP est transmise à Google, le tribunal estime que les risques pour la vie privée de l'utilisateur l'emportent sur l'intérêt de l'éditeur du site. La portée des traitements potentiels que Google pourrait effectuer avec cette donnée est jugée trop importante, et le consentement préalable est la base légale appropriée.
Le tribunal a donc écarté la piste de l'intérêt légitime, et son raisonnement est crucial : le problème n'est pas l'intérêt légitime en soi, mais l'identité et la nature du destinataire des données.
Il est essentiel de noter que l'intérêt légitime reste une base légale parfaitement valide dans d'autres contextes et pour ce même cas de figure, notamment lorsque les données ne sont pas transmises à un géant de la publicité.
Les Solutions : De la Contrainte à la Stratégie
Maintenant que nous avons disséqué le "pourquoi" de la décision du tribunal, explorons le "comment" optimiser son tag management, avec pour objectif prioritaire la conformité.
Face à cette obligation de consentement, plusieurs voies sont possibles.
Voie n°1 : La Simplicité et ses Compromis
Ce sont les solutions les plus simples, mais elles impliquent des sacrifices importants.
- Charger GTM uniquement après le consentement : c’est l’approche la plus simple et la plus sûre. On attend un "oui" explicite de l'utilisateur avant de déclencher le script GTM. C'est la voie que noz.de semble avoir choisie.
- Avantage : certitude juridique.
- Inconvénient majeur : une perte de données massive. Aucune balise, même légitime, ne peut être déclenchée sans consentement. Tous les utilisateurs qui ignorent la bannière ou refusent le consentement deviennent invisibles, faussant radicalement vos analyses de trafic et le pilotage de vos campagnes.
- Changer d'outil : L'autre option radicale est d'abandonner GTM au profit d'une autre solution, comme notre champion national Commanders Act, par exemple.
- Avantage : Peut résoudre le problème de conformité à la source et permettre de gérer les balises avec ou sans consentement, en fonction de leur nature.
- Inconvénient majeur : Une migration souvent lourde, coûteuse, et la perte de tout l'écosystème et des compétences acquises sur GTM.
Voie n°2 : La Stratégie de la Proxyfication
Si vous avez compris que le problème ne vient pas du script gtm.js lui-même, mais de la manière dont il est servi par l'infrastructure de Google, vous avez peut-être deviné la solution.
L'approche consiste à ne plus laisser les navigateurs de vos utilisateurs communiquer directement avec Google, en intercalant un serveur proxy qui agit comme un intermédiaire intelligent et un filtre de conformité. Cette méthode s'attaque directement aux deux verrous identifiés par le tribunal.
Comment la proxyfication déverrouille le Verrou n°1 (Stockage ePrivacy) ?
Le problème, nous l'avons vu, est la directive "Cache-Control: private" envoyée par Google. Juridiquement, cette directive est interprétée comme l'intention de l'opérateur de donner un ordre de stockage sur le terminal de l'utilisateur. C'est cet ordre qui constitue l'infraction à la loi ePrivacy.
La solution consiste donc à neutraliser cet ordre. Le serveur proxy intercepte la réponse de Google et modifie l'en-tête. En remplaçant la directive "Cache-Control: private" par "Cache-Control: no-store", le proxy supprime l'instruction de stockage.
À noter que la directive "Cache-Control: no-store" force le téléchargement du script depuis le serveur à chaque chargement de page. Si vous êtes engagé dans une démarche d’éco-conception, ou tenu réglementairement de mettre en place des mesures de préservation des ressources collectives, vous pouvez privilégier l’alternative "Cache-Control: public", qui permet l’usage de caches partagés (ceux des FAI, par exemple, ou encore de divers équipements de réseau publics).
La nuance est essentielle : même avec une directive public, un navigateur peut choisir de mettre le script en cache pour des raisons de performance. Mais l'intention a changé.
Ce n'est plus l'opérateur du site ou son partenaire qui ordonne un stockage privé, c'est le navigateur de l'utilisateur qui gère ses ressources en fonction des choix de ce dernier. Par ailleurs, avec un en-tête "Cache-Control: public", le suivi spécifique d'un utilisateur n'est pas réaliste.
L'acte qui nécessitait le consentement a donc tout simplement été supprimé.
Comment la proxyfication déverrouille le Verrou n°2 (Transmission d'IP) ?
Le navigateur de l'utilisateur envoie sa requête (et son adresse IP) au serveur proxy. C'est ensuite ce dernier qui contacte Google, en utilisant sa propre adresse IP : l'adresse IP personnelle de l'utilisateur est volontairement masquée et n'atteint jamais l'infrastructure de Google.
Cette approche, consistant à utiliser la proxyfication comme un outil de mise en conformité, n'est pas une simple astuce technique. C'est une méthode que Sirdata a théorisée et mise en œuvre dès mars 2022 pour répondre à la problématique des transferts de données vers Google Analytics aux États-Unis, et dont la robustesse a été reconnue officiellement par la CNIL en juin 2022. Nous appliquons ici cette même logique, déjà validée juridiquement.
En résumé, pour permettre le chargement du script gtm.js sans consentement préalable, le serveur proxy agit comme un filtre de conformité qui :
- Anonymise la connexion en masquant l'adresse IP de l'utilisateur lors de la requête.
- Neutralise l'ordre de stockage sur le terminal de la réponse en modifiant l'en-tête "Cache-Control".
La Solution Pratique : Google Tag Manager Server-Side
La méthode de la proxyfication que nous venons de décrire peut sembler complexe, mais un outil a justement été conçu pour cela : Google Tag Manager Server-Side (GTM Server).
Son rôle est exactement de servir d'intermédiaire entre le navigateur de l'utilisateur (côté client) et les différents services (comme l'infrastructure de Google, les plateformes publicitaires, etc.).
C'est donc l'outil naturel pour modifier les en-têtes de requête (supprimer l'IP) et il ne vous reste qu’à modifier l’en-tête de réponse ("Cache-Control") via une surcouche, comme celle que nous proposons, ou un CDN.
Attention ! On pourrait donc croire que GTM Server est la solution miracle, mais c'est ici que se trouve le piège le plus important.
Le Point de Vigilance Crucial : Où hébergez-vous votre serveur ?
GTM Server est un logiciel ; il doit être hébergé quelque part.
La solution par défaut, mise en avant par Google, est un déploiement en un clic sur sa propre infrastructure Cloud Run (Google Cloud Platform, GCP).
Et c'est là que le raisonnement s'effondre. En suivant la logique stricte du tribunal de Hanovre, l’objectif de conformité n’est en réalité pas atteint.
En effet, l’application GTM Server chargée de masquer l’adresse IP de l’utilisateur n’intervient qu’après que cette IP a déjà été transmise et traitée par les couches basses de l’infrastructure d’hébergement, comme les répartiteurs de charge, les pare-feux, les journaux d’accès de GCP, etc.
En d'autres termes : l'adresse IP de votre utilisateur a quand même été transmise à l'écosystème de Google. Le problème de fond, sanctionné par le tribunal, reste entier.
La conclusion est donc claire : pour que la proxyfication via GTM Server soit une solution de conformité pleine et entière permettant un chargement sans consentement, et sans perte d'efficacité, elle doit être opérée sur une infrastructure sans lien avec Google.
Et il en est de même lorsque vous travaillez avec un prestataire qui lui-même s'appuie sur l'infrastructure GCP.
Ainsi, il est possible d’opter pour un chargement via GCP une fois le consentement obtenu, mais seules des solutions souveraines par défaut, comme celle de Sirdata, assurent l’étanchéité technique et juridique indispensable pour empêcher effectivement tout accès de Google à l’adresse IP de l’utilisateur à l'occasion du chargement.
Il est envisageable de compléter GCP par un CDN (Content Delivery Network) assurant l’anonymisation des requêtes, mais dans ce cas, l’adresse IP est systématiquement supprimée, y compris après consentement. Une telle configuration technique risque donc d’empêcher le bon fonctionnement des balises CAPI.
Pour guider votre choix, nous vous proposons ce comparatif, fondé sur les informations tirées des documentations et communications officielles des différents fournisseurs de solutions :
| Solution | Infrastructure | Stockage local |
Masquage IP |
Chargement sans consentement |
Commentaires |
|---|---|---|---|---|---|
| GCP / Cloud Run | GCP | Non | Non | Non | CDN anonymisant possible, mais l’adresse IP n’est pas utilisable dans sGTM. |
| Addingwell Stape.io (Global) |
GCP | Non | Non | Non | CDN anonymisant possible, mais l’adresse IP n’est pas utilisable dans sGTM. |
| Taggrs Stape EU |
Fournisseurs Cloud EU (hors Google) | Non | Oui | Non | CDN non anonymisant possible. |
| sGTM by Sirdata | Infrastructure EU souveraine |
Oui | Oui | Oui | – |
Analyse du Tableau
- L'écosystème Google (GCP, Addingwell, Stape.io Global...) : Ces solutions reposent sur l'infrastructure cloud de Google. Par conséquent, l'adresse IP de l'utilisateur est inévitablement transmise à Google avant même tout traitement. Elles ne déverrouillent aucun des deux verrous et rendent le consentement préalable indispensable ou doivent être associées à un CDN anonymisant (ce qui peut empêcher le bon fonctionnement des balises CAPI).
- Les hébergeurs européens (Taggrs, Stape EU) : Ces acteurs apportent une réponse partielle mais significative. En utilisant des infrastructures européennes distinctes de Google, ils résolvent le problème de la transmission de l'adresse IP (le verrou n°2). C'est une avancée majeure. Cependant, ils ne gèrent pas nativement la réécriture de l'en-tête "Cache-Control". Le premier verrou reste donc bloqué, ce qui rend le consentement (ou un CDN) toujours nécessaire.
- La Solution Européenne Intégrée (sGTM by Sirdata) : Une solution souveraine par défaut qui va plus loin. Opérée sur une infrastructure européenne et indépendante, elle est conçue pour résoudre nativement les deux problématiques. Elle masque l'adresse IP ET elle réécrit l'en-tête "Cache-Control". C'est le seul service autonome qui déverrouille les deux verrous simultanément, rendant le chargement de GTM sans consentement techniquement et juridiquement possible.
Au fait, de quel "consentement" parle-t-on ?
Pour nos clients et les utilisateurs de CMP qui choisissent la voie du chargement post-consentement, une dernière question se pose : que signifie concrètement "recueillir le consentement pour GTM" ?
C'est un raccourci de langage, car on ne consent pas à un outil, mais bien à des traitements de données. Le consentement requis pour charger le script gtm.js depuis l'infrastructure de Google doit donc couvrir les activités publicitaires de Google lui-même.
Dans le standard du marché, le TCF (Transparency and Consent Framework) de l'IAB Europe, cela se traduit de manière très précise. Pour charger GTM en conformité, vous devez recueillir un consentement valide pour les éléments suivants :
- Le Vendeur n°755 (Google Advertising Products).
- Les Finalités n°1 (Stocker et/ou accéder à des informations sur un appareil) et n°2 (Utiliser des données limitées pour sélectionner la publicité).
Attention, ce consentement initial n'est que la première étape. Il ne sert qu'à déverrouiller le chargement du conteneur GTM. Une fois cette opération effectuée, chaque balise que vous souhaitez déclencher via GTM (Meta, Criteo, etc.) doit être elle-même conditionnée à l'obtention d'un consentement spécifique, en fonction des partenaires et des finalités qu'elle poursuit.
Pensez-y comme une clé qui ouvre la porte d'entrée de l'immeuble (le conteneur GTM), mais chaque appartement (chaque balise) à l'intérieur nécessite sa propre clé pour y entrer. La gestion du consentement n'est donc pas un simple interrupteur "on/off" pour GTM, mais une orchestration fine qui doit être parfaitement maîtrisée au sein de votre CMP.
Sirdata GTM Server-Side
Sirdata
sgtm.sirdata.io
Démarrez dès aujourd’hui avec Sirdata sGTM, la voie souveraine par défaut pour concilier conformité et performance.