Mise en conformité des transferts vers Google Analytics aux USA

Suite à des plaintes de NOYB, le DSB autrichien puis la CNIL, en coopération avec ses homologues européens, ont tour à tour analysé les transferts de données collectées par Google Analytics vers les États-Unis.

En suivant un raisonnement similaire, ces Autorités de contrôle ont estimé, respectivement le 12 janvier 2022 et le 10 février 2022, que ces transferts sont illégaux.

Précisons pour commencer que seul l’éditeur qui utilise Google Analytics est visé par ces décisions : Google n’est pas mis en cause par ces Autorités dans le cadre spécifique de ce transfert.

En effet, dans le cas du transfert en dehors de l'Espace Économique Européen (“EEE”), seule la transmission de données à caractère personnel par l’exportateur est couverte par la notion de transfert au sens du RGPD, et non sa réception par l’importateur.

I- Les données transférées à Google Analytics sont des données personnelles

Pour arriver à cette conclusion, la CNIL commence par constater que Google Analytics permet notamment de réaliser un suivi de l’utilisateur via un identifiant unique associé aux données de cet utilisateur.

Plus précisément, l’opération de suivi consiste en la récupération et l’envoi de ces informations, entre autres, aux serveurs Google Analytics :

• l’identifiant de cookie visiteur (le “client ID” Google Analytics)
• l’adresse IP du visiteur
• des informations sur son navigateur et sur son système d’exploitation (“user-agent”, taille d’écran et langue)
• le nom de domaine ou l’url de la page visitée
• le référent de la page (“referer”) lorsqu'il existe
• optionnellement, un identifiant utilisateur attribué par l’éditeur (“user ID”)
• des informations d’événement (ex.: “page vue”) ou optionnellement de commande

La CNIL rappelle que l’article 4.1 du RGPD définit une donnée à caractère personnel comme “toute information se rapportant à une personne physique identifiée ou identifiable”, c’est-à-dire à une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant en ligne.

Puis elle renvoie au considérant 30 du RGPD pour souligner que les identifiants en ligne comme les adresses IP ou les données de cookies peuvent être utilisées pour identifier un utilisateur, en particulier lorsqu’elles sont combinées avec d’autres types d’informations similaires.

Les client IDs répondent selon elle à cette définition d’identifiant unique dont la finalité est de différencier les individus, et qui peuvent en outre être combinés avec d’autres informations, telles que l’adresse du site visité, le user-agent, l’heure de la visite du site web ainsi que l’adresse IP.

Cette combinaison permet de renforcer leur caractère discriminant puisque plusieurs éléments peuvent donc être recoupés pour permettre d’individualiser les visiteurs du site web sur lequel Google Analytics est mis en œuvre.

Il n’est en effet pas nécessaire de connaître le nom ou l’adresse postale du visiteur puisque, conformément au considérant 26 du RGPD, une telle individualisation peut être suffisante pour les rendre identifiables.

Raisonner différemment reviendrait, selon la CNIL, à permettre d’individualiser des individus et de leur associer des informations personnelles sans leur garantir de protection contre cette individualisation. Cela serait également contraire à la jurisprudence européenne, qui donne au RGPD un champ d’application très large.

La CNIL relève en outre que dans le cas des utilisateurs qui se sont enregistrés ou logués chez l’éditeur à travers un compte utilisateur, ou ceux qui ont passé une commande, les données sont directement reliables à des données identifiantes (car nominatives) via le user ID ou le numéro de commande.

Enfin, si l’utilisateur est connecté à son compte Google, la CNIL note que l’information de sa visite du site pourra être liée à son profil Google.

Ce qui ressort effectivement de la lecture des Règles de confidentialité de Google : “Lorsque vous êtes connecté à votre compte, nous stockons les informations collectées en les associant à votre compte Google et les considérons comme des informations personnelles”.

Notons que ce traitement, opéré manifestement par Google en sa qualité de responsable de traitement, diffère du transfert reproché à l’éditeur, et il n’est pas clairement établi qu’un transfert hors de l’EEE a lieu dans ce cas précis. La CNIL n’a pas non plus étudié les mesures de sécurité appliquées au stockage de cette donnée.

Néanmoins la CNIL souligne son existence, et indirectement qu’un lien peut être créé via le client ID entre les données collectées pour la mesure d’audience et l’identité de la personne (les données nominatives du compte Google).

Rappelons à ce titre qu’un traitement de données à caractère personnel, indépendamment de la question du transfert, doit s’appuyer sur une base légale valablement mise en œuvre pour être conforme au RGPD.

La question des cookies et de leur éventuelle exemption mise à part, ce traitement des données personnelles s’appuie en général sur l’intérêt légitime.

Il est donc primordial de correctement délivrer l’information nécessaire et d’implémenter la gestion du droit d’opposition dans la CMP ou sur la page de vie privée par exemple.

II- Les transferts vers Google Analytics ne sont pas conformes au RGPD

Puisque les données collectées via Google Analytics sont des données à caractère personnel au sens du RGPD, et puisqu’elle constate que ces données sont hébergées aux États-Unis, la CNIL conclut assez logiquement que ces données collectées via Google Analytics sont nécessairement transférées aux États-Unis.

Un "transfert" de données personnelles au sens du RGPD est défini comme :

• un transfert à une entité qui n'opère pas au sein de l’EEE
• un transfert à une entité dont un sous-traitant n'opère pas au sein de l'EEE
• la possibilité d’accès par une personne située hors de l'EEE à des données stockées dans l’EEE (par exemple un employé d’un sous-traitant situé aux États-Unis qui a la capacité technique de se connecter à distance)

L’envoi de données à Google LLC, l’importateur, entre bien dans le scope de cette définition du transfert.

La mise en demeure de l’éditeur par le DSB autrichien apporte un éclairage complémentaire, ce dernier soulignant que techniquement l’éditeur transfère des données à Google Ireland Limited, qui à son tour les transfère à Google LLC aux États-Unis.

Cela ne diminue pas la responsabilité de l’éditeur dans le transfert ultérieur vers les États-Unis, en ce sens que Google Ireland Limited agit comme sous-traitant et donc sur instruction de ce dernier.

En décidant de mettre en œuvre la fonctionnalité Google Analytics à des fins d’évaluation et d’optimisation, la CNIL considère en effet que l’éditeur détermine les moyens et les finalités de la collecte et du traitement et doit en être considérée comme le responsable du traitement.

La CNIL rappelle alors que le RGPD prévoit au chapitre V, et en particulier à l’article 44, que ce transfert ne peut être effectué que si des mesures appropriées sont mises en place pour garantir dans le pays tiers un niveau de protection des personnes physiques équivalent à celui appliqué au sein l’Union européenne.

Ledit chapitre V du Règlement prévoit différents instruments pour assurer ce niveau élevé de protection :

• les décisions d’adéquation (article 45)
• les garanties appropriées (article 46)
• étant précisé qu’en l’absence de protection équivalente, il peut exister des dérogations (article 49)

Concernant le premier point, les deux Autorités confirment que depuis son invalidation par la Cour de Justice de l'Union Européenne (“CJUE”) du 16 juillet 2020, le Privacy Shield qui encadrait les transferts vers les États-Unis est non conforme au RGPD.

La CJUE s’est en effet appuyée sur les conséquences de la section 702 du Foreign Intelligence Surveillance Act (“FISA”), modifiée par l'amendement de 2008 (FISA Amendments Act ou “FAA”), pour justifier son jugement, et en particulier sur l'article 50 USC § 1881a.

Concrètement, le problème pour la CJUE est que le FISA oblige les “hébergeurs Cloud” à communiquer aux services de renseignement américains les données concernant des personnes à surveiller qu'ils contrôlent, stockent ou gèrent, ainsi que les clés de chiffrement si nécessaire, hors de toute procédure européenne.

Les personnes à surveiller sont définies comme tous les individus physiques qui ne sont ni Américains ni résidents des États-Unis. Les Européens ne vivant pas aux États-Unis font donc partie de celles-là.

Le FISA étant par ailleurs applicable auprès d'entreprises opérant sur le sol états-unien, et aux données stockées localement mais aussi à distance (par exemple sur des serveurs hébergés dans l'EEE) si ces entreprises y ont accès, il s’agit bien dans les deux cas d’un transfert au sens du RGPD.

Dans son rapport de transparence, Google confirme être destinataire de telles demandes d’accès par les services de renseignement des États-Unis, et y répondre le plus souvent favorablement (environ 3 fois sur 4 d’après les statistiques à disposition).

Google fournit aussi des explications plus détaillées sur le cadre administratif de ces demandes d’accès, et nous avons également pu prendre connaissance du rapport très complet du Congressional Research Service (“CRS”) sur l’arrêt Schrems II et son impact sur le Privacy Shield.

Ces éléments nous permettent de déduire en quoi des transferts de données mis en œuvre dans Google Analytics sont problématiques au regard de l’action possible des services de renseignement américains.

Concrètement, deux mécanismes semblent cohabiter :

• les services de renseignement américains peuvent exiger de Google la communication de données relatives à un utilisateur identifié si ce dernier n’est ni Américain ni résident des États-Unis
• les services de renseignement américains semblent pouvoir intercepter des communications électroniques directement dans les infrastructures ou les câbles de télécommunication, et alimenter des bases de profils

Dans le premier cas, la demande implique que l'utilisateur soit identifié par son nom ou son email par exemple. On peut aisément imaginer que le problème est alors pour la CNIL, l’utilisation potentielle du client ID comme clé d’accès aux données collectées par Google Analytics à partir des informations du compte Google.

Ce risque semble n’être que théorique pour l’instant, car nous n’avons cependant pas pu constater de tels traitements dans les demandes mentionnées par Google sur son site dédié à la transparence.

Dans le second cas, à défaut de pouvoir intercepter une adresse email dans les données collectées par Google Analytics, l’adresse IP semble être la clé d’accès la plus évidente pour les services de renseignement, en ce sens qu’elle peut raisonnablement être attribuée à un utilisateur non Américain si résident des États-Unis.

Elle peut également éventuellement être couplée à d’autres informations comme le client ID, qui à leur tour pourraient permettre de faire une demande relative à un utilisateur identifié à Google.

Les autres cas de figure impliquant des recoupements d’informations avec d’autres informations détenues par ailleurs pour identifier un individu semblent peu probables, car :

• d’une part, les services de renseignement doivent au préalable s’assurer de manière suffisamment certaine que l’utilisateur n’est pas un citoyen américain vivant éventuellement à l’étranger, ni un résident des États-Unis. Cela impliquerait donc de recouper les données pour identifier l’utilisateur pour vérifier précisément la légalité de ce recoupement au regard du législateur américain…
• d’autre part, pour effectuer un tel recoupement il serait nécessaire qu’il existe d’autres données relatives à cet utilisateur accessibles aux services de renseignement américains. Cela serait rendu possible par un autre transfert aux États-Unis, illégal par définition et que les Autorités de régulation des données européennes auraient failli à sanctionner.

Ni le user ID, ni le numéro de commande ne sont par ailleurs utilisables par les services de renseignement pour accéder aux données nominatives relatives au compte de l’utilisateur, dans la mesure où ces données sont stockées chez l’éditeur et ne sont pas transférées à Google Analytics.

On pourra néanmoins noter que le CLOUD Act de 2018, adopté depuis, oblige les fournisseurs de Cloud américains, où qu’ils soient dans le monde (et pas uniquement aux Etats-Unis), à fournir les données d'un individu sans aucune demande d’autorisation à la justice du pays de l'individu concerné et peut représenter un risque. Mais il s’agit d’un tout autre sujet, et des hébergeurs américains ont déjà su démontrer une résistance efficace au programme de surveillance, dans le cadre de l’hébergement de données de santé en Europe par exemple.

Toujours est-il que l’invalidation du Privacy Shield prive l’éditeur d’une décision d’adéquation pertinente sur laquelle il peut s’appuyer pour transférer des données vers Google Analytics aux États-Unis (et il semble donc peu probable qu’il en soit adopté une à court terme).

Dans son Arrêt, la CJUE a néanmoins confirmé que l'utilisation de Clauses Types ou Standard Contractual Clauses (“SCC”) adoptées entre l'exportateur et l'importateur demeurent valides.

Elles ne sont cependant pas suffisantes pour permettre la conformité du transfert vers les États-Unis, car elles ne s’appliquent qu’aux parties contractantes (l’éditeur et Google dans le cas présent) : la CJUE a en effet considéré que la nature contractuelle de ces clauses impliquent qu’elles ne peuvent lier les autorités des pays tiers.

En clair, les services de renseignement américains ne sont pas tenus de les respecter!

Pour s’appuyer sur l’article 46 du RGPD et utiliser des SCC comme outil juridique de transfert, il est donc nécessaire de préserver un niveau de garanties sur les données équivalent à une sous-traitance intra-EEE via l’adoption de mesures supplémentaires d’ordre juridique, organisationnel et technique, visant clairement à empêcher l’ingérence des services de renseignement.

Les transferts vers Google Analytics sont précisément encadrés contractuellement par l’annexe intitulée “Conditions Google Ads relatives au traitement des données”, qui contient des clauses contractuelles types destinées à encadrer les transferts vers les États-Unis et des mesures supplémentaires.

Ainsi que prescrit par la CJUE et le Comité européen de la protection des données (“CEPD”), la CNIL explique qu’il est donc nécessaire de vérifier si ces mesures complémentaires sont efficaces, c’est-à-dire qu’elles répondent à la problématique particulière de la possibilité d’accès des services de renseignements américains aux données.

Or, la CNIL explique que les principales “mesures juridiques et organisationnelles” adoptées, à savoir la possible notification des utilisateurs de l’accès illicite aux données et la publication d’un rapport de transparence ou d’une politique de gestion des demandes d’accès gouvernementales ne permettent pas concrètement d’empêcher ou de réduire l’accès des services de renseignement américains, ni d’en diminuer les effets.

L’examen attentif du caractère licite de chaque demande d’accès ne serait pas non plus être une mesure supplémentaire suffisamment efficace, car pour la CJUE même si ces demandes des services de renseignement sont “licites” d’un point de vue américain, elles ne sont pas conformes au RGPD.

Les principales “mesures techniques” telles que la protection des communications entre les services de Google, la protection des données en transit entre des centres de données, la protection des communications entre les utilisateurs et les sites web ou la sécurité sur site ne permettent pas non plus, selon la CNIL, de prévenir ou de réduire les possibilités d’accès des services de renseignement américains sur la base du cadre légal américain.

En ce qui concerne les techniques de chiffrement, telles que celles employées pour les données entreposées dans des centres de données, la CNIL relève qu’elles sont inefficaces car Google a dans tous les cas l’obligation de communiquer les clés de chiffrement nécessaires pour rendre les données intelligibles.

Dit autrement, pour la CNIL, tant que Google a la possibilité d’accéder aux données des personnes physiques en texte clair, de telles mesures techniques ne peuvent être considérées comme efficaces.

En ce qui concerne l’argument selon lequel les données de Google Analytics qui sont transférées sont pseudonymisées, la CNIL relève que les identifiants uniques universels (“UUIDs”) ne correspondent pas à la définition d’une information pseudonyme du RGPD.

En effet les identifiants uniques ont pour finalité spécifique d’individualiser les utilisateurs, et non de servir de garantie, d’autant que la combinaison d’identifiants uniques avec d’autres éléments tels que le user-agent ou l’adresse IP ou encore à un compte Google ou à un compte chez l'éditeur permettent dans tous les cas de pouvoir identifier un individu.

La pseudonymisation est définie par l’article 4.5 du RGPD comme un traitement de données à caractère personnel empêchant leur attribution à une personne concernée précise sans avoir recours à des informations supplémentaires. Si de telles informations supplémentaires existent quelque part, elles doivent être conservées séparément et soumises à des mesures techniques et organisationnelles afin de garantir qu’elle ne pourront pas être utilisées pour permettre leur recoupement avec les données pseudonymisées;

Le problème ici n’est donc pas l’utilisation du client ID ou de l’adresse IP à des fins d’individualisation pour la production de statistiques, mais le fait que ces identifiants puissent être utilisés pour opérer des recoupements avec des informations externes à Google Analytics, issues d’un compte Google par exemple, pour identifier la personne concernée.

En clair, c’est le caractère universel des identifiants qui pose problème, et le fait qu’aucune mesure ne permette efficacement de les isoler d’autres données que celles qu’ils permettent de traiter pour la mesure d’audience.

En particulier pour ce qui concerne la mesure technique optionnelle d’anonymisation de l’adresse IP par raccourcissement (suppression des derniers octets), la CNIL estime qu’elle n’est pas efficace pour deux raisons car :

• d’une part, elle n’est pas systématiquement mise en oeuvre puisqu’elle est optionnelle
• d’autre par, cette anonymisation n’a lieu qu’après le transfert, ce qui n'empêche ni l’accès de Google à l’adresse IP en clair, ni celui des services de renseignement

Dans cette position claire et tranchée, nous notons que la CNIL ne remet cependant pas en cause le fait que tronquer l’adresse IP permet de la rendre anonyme. Elle précise simplement qu’il est nécessaire de le faire avant le transfert pour que cela soit efficace.

En conclusion, la CNIL estime que ces mesures supplémentaires telles qu’elles sont mises en œuvre ne sont pas efficaces, dans la mesure où aucune d’entre elles n’empêche les services de renseignement américains d’accéder aux données en cause ou ne rendent cet accès ineffectif.

Ce faisant, la CNIL clarifie que l’efficacité des mesures additionnelles peut s’apprécier au regard de l’ineffectivité de l’accès aux données, ou autrement dit que ces données soient non signifiantes pour les services de renseignement même s’ils y accèdent.

Elle s’intéresse alors à la question de savoir si le transfert peut s’appuyer sur une dérogation prévue à l’article 49.1. a) et b) du RGPD, à savoir le consentement explicite de la personne concernée, ou la nécessité contractuelle.

Plus précisément, la question est de savoir si le consentement donné pour les traceurs ayant pour finalité la mesure d’audience peut également être valable pour les transferts de données collectées via ces traceurs, ce que la CNIL exclut d’office.

Elle explique en effet que le consentement à ces transferts ne peut être donné valablement que si la personne concernée a été préalablement et spécifiquement informée des risques que ce transfert pouvait comporter pour elle, justement en raison de l'absence de décision d'adéquation et de garanties appropriées.

L’information préalable nécessaire est donc radicalement différente de l’information relative aux cookies, et la CNIL conclut donc que le consentement donné par un utilisateur au dépôt de traceurs lors de sa visite sur un site web ne saurait être considéré comme équivalent au “consentement explicite au transfert envisagé”.

A noter que le DSB autrichien va encore plus loin, en précisant que ces dérogations prévues à l’article 49 du RGPD revêtent dans tous les cas un caractère exceptionnel potentiellement incompatible avec le transfert systématique qu’implique l’utilisation de Google Analytics.

Pour finir, les décisions clarifient indirectement qu’il n’existe pas de contrat implicite entre un site et l’ensemble de ses utilisateurs qui peut justifier un tel transfert, et qu’il est nécessaire d’étayer un tel rapport contractuel ou précontractuel pour s’appuyer sur la dérogation prévue au 49.1 b).

En conclusion, la CNIL estime que :

• Google Analytics ne peut pas être implémenté tel quel par un éditeur sans déclencher le transfert des données à caractère personnel des visiteurs de son site web vers Google LLC aux États-Unis
• de par la nature identifiante des données (en particulier des identifiants universels uniques, adresses IP, données du navigateur et métadonnées) ce transfert de données n’est pas conforme à l’article 44 du RGPD

Elle donne un mois à l’éditeur pour mettre en conformité le traitement relatif à la fonctionnalité Google Analytics avec le chapitre V du RGPD, c’est-à-dire concrètement pour empêcher les services de renseignement américains de pouvoir lier ces données à des Européens, ou pour renoncer à utiliser ce service.

Paradoxalement, ce délai d’un mois est inhabituellement court, et permet d’espérer que la résolution est non seulement possible mais peut également être rapidement déployée.

III- Comment rendre les transferts vers Google Analytics aux États-Unis conformes au RGPD ?

Comme nous l’avons expliqué ci-dessus, la CNIL considère manifestement que le client ID et l’adresse IP sont des clés de correspondance universelles, en particulier entre les données transférées à Google Analytics et l’identité de la personne et/ou d’autres données stockées ou gérées par Google ou par les services de renseignement américains.

La CNIL précise par ailleurs dans sa mise en demeure que si un responsable de traitement fait valoir de ne pas avoir la capacité d’identifier l’utilisateur grâce à l’usage de ce type d’identifiants (seuls ou combinés avec d’autres données), il doit démontrer les moyens mis en œuvre pour s’assurer du caractère anonyme des identifiants collectés.

Elle conclut qu’en l’absence d’une telle démonstration, ces identifiants ne sauraient être qualifiés d’anonymes, mais reconnaît donc que c’est une voie possible.

Tenter de démontrer qu’il ne s’agit pas de données à caractère personnel alors que la finalité reste d’individualiser pour opérer des statistiques d’audience va être difficile et l’issue incertaine.

Concernant l'adresse IP, la méthode semble assez simple à la lecture de la mise en demeure : il suffit de l’anonymiser par raccourcissement avant l’envoi à Google.

Pour les utilisateurs de la version Universal Analytics de Google Analytics (“analytics.js” et “gtag.js”), il suffit d’utiliser le paramètre IP override.

En cas de doute, si votre identifiant Analytics est de la forme UA-XXXXXXX-X, il s’agit d’un identifiant Universal Analytics.

Mais il n’existe à notre connaissance aucun mécanisme équivalent pour GA4.

En cas de doute, si votre identifiant Analytics est de la forme G-XXXXXXX-X, il s’agit d’un identifiant GA4.

S’il semble donc possible de mettre les transferts vers Google Universal Analytics en conformité avec l’article 44 du RGPD, tant que Google n’active pas l’option IP override pour GA4 on ne peut qu’espérer une rapide décision d’adéquation entre l’Europe et les États-Unis.

Édit du 26/04/2022 : suite à des modifications récentes opérées par Google, il nous semble désormais possible d’opérer cette opération également pour GA4. L’offre Sirdata Analytics Helper couvre donc désormais également GA4, en phase bêta.

Deux problèmes se posent néanmoins pour Universal Analytics :

• l’IP ne sert pas que d’identifiant, elle est également analysée pour estimer la localisation du visiteur
• si la requête est initiée depuis le terminal de l’utilisateur, l’adresse IP sera accessible dans tous les cas à Google et aux services de renseignement dans les données de connexion

Il est donc nécessaire d’effectuer le traitement de la localisation en amont de l’envoi à Google Analytics, ce qui sera possible grâce au paramètre Geographical override.

Enfin, afin de masquer l’adresse IP réelle du visiteur, il sera nécessaire de faire transiter l’appel via un proxy en utilisant les options de transport de Google Analytics, et d’envoyer les informations vers Google Analytics via un appel server-to-server (S2S).

Concernant le client ID, le principe va être équivalent : il s’agira de substituer un identifiant propre au site et indépendant de Google, via le paramètre client ID.

Toutefois ce client ID, même attribué par site et indépendamment de Google, pourrait être relié à d’autres données comme le compte Google sur la page où le script Google Analytics est exécuté.

Afin de rendre non effectif un tel lien pour les services de renseignement après le transfert vers les États-Unis, il est nécessaire de procéder à une pseudonymisation de ce client ID au niveau du proxy, c’est-à-dire là où l’IP sera anonymisée également.

Ainsi le client ID transféré à Google Analytics aux États-Unis et auquel les services de renseignement peuvent avoir accès ou intercepter est, quoi qu’il arrive, lié à une adresse IP anonymisée et diffère du client ID stocké dans le terminal de l’utilisateur et qui peut être lié au compte Google.

IV- SIRDATA ANALYTICS HELPER

Pour la plus grande sécurité de nos clients utilisant Universal Analytics et celle de leurs visiteurs, nous avons ajouté ces mesures et cette option de proxification dans notre offre Analytics Helper déjà existante.

De cette manière, ni l’éditeur, ni Google, ni les services de renseignement, ni ces deux derniers conjointement ne peuvent identifier directement ou indirectement l’utilisateur concerné grâce aux données transmises à Google Analytics aux États-Unis.

Il s’agit toujours de données pouvant servir à individualiser pour produire des statistiques, donc de données personnelles, mais les mesures additionnelles cumulées qu’apportent l’éditeur, Google et Sirdata permettent donc de garantir un niveau de protection de la personne concernée équivalent à celui dont elle bénéficie en Europe.

Sirdata Analytics Helper est en test depuis près de 18 mois chez nos partenaires, et cumule donc désormais plusieurs avantages en permettant :

• de bloquer les cookies Google Analytics lorsque le Google Consent Mode ne les bloque pas en l’absence de consentement (analytics.js)
• d’utiliser des cookies privés à la place de ceux gérés par Google Analytics en cas de consentement, et de générer le client ID à la place de Google Analytics
• de visualiser des statistiques en temps réel ou générer des rapports qui tiennent compte des visiteurs n’ayant pas consenti et que la modélisation du Google Consent Mode ne permet pas encore de faire apparaître
• de rendre conformes les transferts vers Google Analytics aux États-Unis via la pseudonymisation du client ID et en masquant l’adresse IP réelle de l’utilisateur dans tous les cas (consentement ou non)

Déployer notre Analytics Helper suppose un simple copier-coller d’un script sur les pages de l’éditeur, et ne nécessite pas de changement dans le taggage de Google Analytics.

Les obligations de transparence et la licéité des traitements au regard du RGPD sont mises en œuvre via Sirdata CMP et seront bientôt déployables en un clic dans la console de gestion.

Le service fonctionne également derrière les CMP certifiées Transparency & Consent Framework (“TCF”), tout comme il est possible de déployer une version sur-mesure du service sur un site équipé d’une CMP non compatible avec le TCF, après un audit de conformité.

Voici les tableaux récapitulatifs et comparatifs des fonctionnalités de notre Analytics Helper en fonction de la version de Google Analytics utilisée :

Sirdata Analytics Helper pourrait contribuer à diminuer les effets sur les personnes concernées dans le cadre de GA4, mais ne permet pas d’atteindre les objectifs de la solution de mise en conformité proposée.

Édit du 26/04/2022 : suite à des modifications récentes opérées par Google, il nous semble désormais possible d’opérer cette opération également pour GA4. L’offre Sirdata Analytics Helper couvre donc désormais également GA4, en phase bêta.

Par ailleurs, ainsi qu’expliqué ci-dessus, les programmes de surveillance américains peuvent potentiellement rendre inefficaces les mécaniques d’anonymisation appliquées par Google directement, dans le tag manager pour GA4 par exemple.

Il nous semble en effet important que l’éditeur ou un tiers indépendant de Google, basé en Europe et non américain procède à ce traitement.

Tout en reconnaissant l’intérêt évident et la merveille de technologie qu’est GA4, nous en déconseillons donc l’utilisation et limitons l’utilisation du Sirdata Analytics Helper à Universal Analytics pour l’instant.

Édit du 26/04/2022 : suite à des modifications récentes opérées par Google, il nous semble désormais possible d’opérer cette opération également pour GA4. L’offre Sirdata Analytics Helper couvre donc désormais également GA4, en phase bêta.

Par ailleurs, la mise en conformité d’Universal Analytics grâce au Helper implique des coûts importants pour Sirdata, car à l’évidence on ne lutte pas contre l’espionnage de masse sans devoir déployer des moyens importants ! Elle ne peut donc pas être gratuite.

C’est pourquoi nous recommandons aux éditeurs utilisant Google Analytics de prendre le temps de la réflexion et de considérer :

• d’investir pour faire une utilisation conforme d’Universal Analytics
• ou d’utiliser des offres alternatives comme Plausible ou encore celles d’Eulerian, Matomo, et SmartProfile, qui proposent des variantes exemptées de consentement

Ceci étant dit, nous intégrerons avec plaisir ces fonctionnalités pour GA4 dans notre Analytics Helper le jour ou Google fournira les briques nécessaires, en particulier la fonctionnalité de surcharge de l’adresse IP.

Édit du 26/04/2022 : suite à des modifications récentes opérées par Google, il nous semble désormais possible d’opérer cette opération également pour GA4. L’offre Sirdata Analytics Helper couvre donc désormais également GA4.

Les éditeurs clients de Google Analytics et agissant en responsables de traitement devraient d’ailleurs pouvoir en demander la mise à disposition à Google, qui agit dans ce cadre comme leur sous-traitant…