MISE À JOUR : Google force le passage à la version 4 de Google Analytics. La technique présentée dans cette article ne fonctionne pas avec cette version, et devient donc caduque. Plusieurs solutions alternatives sont présentées dans les commentaires. Pour ma part, j’ai choisi d’utiliser Plausible, qui est un produit open source, au tarif raisonnable, et géré par une équipe sympa et dont le support client est très réactif.
De quoi on parle ?
Google Analytics est sûrement l’outil de statistiques web le plus utilisé. Son premier avantage est d’être gratuit, mais il faut dire qu’il propose énormément de fonctionnalités, avec une ergonomie plutôt bonne une fois qu’on s’est repéré dans les options.
Pour fonctionner, Google Analytics a besoin de poser un cookie sur le navigateur des internautes, afin de pouvoir les suivre tout au long de leurs visites (sans cela, chaque page vue serait perçue comme étant la première d’une nouvelle visite). Au passage, Google récolte un certain nombre d’infos ; certaines sont accessibles (la taille de l’écran, la langue du navigateur…), d’autres comme l’adresse IP des internautes sont utilisées par Google en interne.
Le RGPD a été promulgué en 2016, et si la CNIL a fait preuve de tolérance dans l’application de certaines contraintes, il est temps désormais de se mettre en conformité sous peine de sanctions.
Ce dont je parle, ce n’est pas seulement l’obligation de prévenir les internautes qu’on pose des cookies sur leur navigateur. En effet, pendant très longtemps la majorité des sites se contentaient de mettre un bandeau alertant les internautes (avec un simple bouton « OK » pour cacher le panneau). Mais cela n’était déjà pas suffisant. Depuis 5 ans, en plus d’informer il faut aussi donner la possibilité de refuser l’ajout de cookies.
On peut regrouper les cookies en plusieurs groupes, permettant d’accepter ou de refuser tous les cookies de statistiques d’un côté, tous les cookies publicitaires de l’autre, etc.
Est-ce qu’on peut simplifier ?
Mais vous avez peut-être un site sur lequel vous ne diffusez pas de publicités, et pour lequel vous n’avez besoin que d’un minimum de statistiques (nombre de visiteurs, nombre de pages vues, etc.). Vous voulez utiliser Google Analytics, mais vous n’avez pas envie de mettre un bandeau de cookie.
Il faut voir aussi que si votre solution de statistiques est configurée pour déposer des cookies, et que vous laissez la possibilité à l’utilisateur de le refuser, une partie (potentiellement importante) de votre trafic ne sera plus comptabilisée. Donc ce serait doublement avantageux de trouver une solution qui n’impose pas de pollution visuelle (le bandeau d’information sur les cookies), et qui ne risque pas de fausser vos statistiques.
Il existe quelques alternatives qui mettent en avant le respect de la vie privée des internautes, comme Matomo ou Analytics Suite Delta d’AT Internet (si configuré comme le préconise la CNIL). Mais ce sont des solutions payantes (avec la possibilité de l’installer gratuitement sur ses propres serveurs dans le cas de Matomo, mais ça représente aussi des coûts).
Ça tombe bien, il est possible d’utiliser Google Analytics sans mettre de bandeau cookies, tout en étant en conformité avec le RGPD. Pour cela, il faut appliquer deux modifications dans l’appel à Google Analytics :
- demander à ce qu’aucun cookie ne soit déposé sur le navigateur ;
- anonymiser les requêtes pour que Google ne stocke pas les adresses IP.
Ensuite, on verra une astuce pour que les différentes pages vues par un même internaute soient comptabilisées correctement.
Modification de l’appel Javacript
Je vais partir du principe que vous utilisez la dernière version de Google Analytics, dont l’appel utilise Google Tag Manager.
Vous devez donc avoir dans votre code HTML quelque chose qui ressemble à ça :
<script async src="https://www.googletagmanager.com/gtag/js?id=VOTRE_IDENTIFIANT_GA"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', "VOTRE_IDENTIFIANT_GA");
</script>
On va donc modifier ce code. Tout se passe dans le dernier appel de fonction, à laquelle on va passer des paramètres supplémentaires :
<script async src="https://www.googletagmanager.com/gtag/js?id=VOTRE_IDENTIFIANT_GA"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'VOTRE_IDENTIFIANT_GA', {
client_storage: 'none',
anonymize_ip: true
});
</script>
La clé client_storage sert à indiquer de ne rien enregistrer sur le navigateur (grâce à la valeur « none« ), et donc de ne pas déposer de cookie. La clé anonymize_ip fait en sorte que Google ne stocke pas l’adresse IP exacte de l’internaute.
Et voilà, pas besoin de plus pour être en conformité avec le RGPD. Et si vous ne déposez pas de cookies par ailleurs (soit par vous-même, soit par de la publicité ou autre appels à des librairies externes), vous n’avez pas besoin de mettre de bandeau cookie. Merveilleux, non ?
Et le suivi des visites ?
Il reste un problème avec le code ci-dessus : si un internaute visite plusieurs pages, au gré de ses clics sur les liens internes du site, vous ne saurez pas qu’il s’agit de la même personne. Chaque page sera considérée comme faisant partie d’une nouvelle visite ; vous aurez un nombre de visiteurs, un nombre de visites et un nombre de pages vues qui seront tous égaux.
C’est logique ; sans cookie sur le navigateur, il n’est pas possible de savoir que deux accès sont effectués depuis le même navigateur.
Mais ne serait-il pas possible d’utiliser un autre moyen pour identifier un visiteur ?
L’idée va être de générer un identifiant côté serveur, qui sera le même pour toutes les pages consultées par un même visiteur. On fournira cet identifiant à Google Analytics, qui pourra ainsi rapprocher les différentes connexions pour les regrouper au sein de la même “visite”.
La question est maintenant de savoir comment générer cet identifiant, sans déposer de cookie ni enregistrer des données personnelles en base de données. Ce qu’on peut faire, c’est utiliser l’adresse IP du visiteur. C’est une solution imparfaite, car plusieurs personnes peuvent visiter le site avec la même adresse IP ; mais c’est une approximation dont on se satisfera faute de mieux.
On ne va évidemment pas utiliser l’adresse IP telle quelle, car encore une fois c’est une donnée personnelle qu’il ne faut surtout pas transmettre en clair à Google. Par contre, il est possible de l’utiliser dans un calcul, dont le résultat sera toujours le même pour une adresse IP donnée.
On va donc calculer un hash MD5 à partir de l’adresse IP, à laquelle on aura concaténé l’année courante et le numéro de semaine courante. L’identifiant généré changera donc toutes les semaines, ce qui est suffisant pour suivre les pages vues pendant une visite.
Si on pinaille, on pourra remarquer qu’une personne qui visite le site du dimanche soir 23h30 jusqu’au lundi matin 00h30 sera vue comme deux visiteurs séparés. Si c’est vraiment problématique, on peut remplacer le numéro de la semaine par le numéro du mois ; le phénomène existera toujours, mais 12 fois par an au lieu de 52.
Voici un exemple de code serveur en PHP pour faire ce calcul :
$gaClientId = md5($_SERVER['REMOTE_ADDR'] . date('YW'));
Il faut ensuite utiliser cette variable dans le code Javascript. Voici un exemple d’utilisation en pur PHP (a priori vous utilisez sûrement un système de templates, mais c’est facilement adaptable) :
<script async src="https://www.googletagmanager.com/gtag/js?id=VOTRE_IDENTIFIANT_GA"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'VOTRE_IDENTIFIANT_GA', {
client_storage: 'none',
anonymize_ip: true,
client_id: '<?=$gaClientId?>'
});
</script>
Concernant la publicité
Le cas de la publicité en ligne est un peu particulier, notamment parce que Google crée des passerelles entre ses différents outils. Dans la console de Google Analytics, il est possible d’activer les fonctionnalités de remarketing. Donc pour être certain de ne pas commettre d’impair, vous pouvez vouloir les désactiver dans le code Javascript.
Pour cela, on va faire un appel de fonction supplémentaire :
<script async src="https://www.googletagmanager.com/gtag/js?id=VOTRE_IDENTIFIANT_GA"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('set', 'allow_google_signals', false);
gtag('config', 'VOTRE_IDENTIFIANT_GA', {
client_storage: 'none',
anonymize_ip: true,
client_id: '<?=$gaClientId?>'
});
</script>
Avec cet appel supplémentaire, tous les appels publicitaires seront désactivés.
Événements Javascript
Google Analytics permet aussi de pister les clics qui sont faits. Cela peut être utile si vous chargez des pages en Javascript.
Dans ce cas, il faudra appeler la fonction gtag() en lui passant un paramètre supplémentaire.
Mais, pour commencer, on va reprendre le code précédent, en créant des variables globales qui faciliteront l’accès à l’identifiant Google Analytics et à l’identifiant client :
<script async src="https://www.googletagmanager.com/gtag/js?id=VOTRE_IDENTIFIANT_GA"></script>
<script>
window._googleAnalyticsId = "VOTRE_IDENTIFIANT_GA";
window._googleAnalyticsClientId = "<?=$gaClientId?>";
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('set', 'allow_google_signals', false);
gtag('config', window._googleAnalyticsId, {
client_storage: 'none',
anonymize_ip: true,
client_id: window._googleAnalyticsClientId
});
</script>
Ensuite, à chaque fois qu’une page va être chargée en Javascript, on appellera le code suivant :
gtag('config', window._googleAnalyticsId, {
page_path: "/URL/de/la/page",
client_storage: 'none',
anonymize_ip: true,
client_id: window._googleAnalyticsClientId
});
La clé page_path doit contenir l’URL que vous voulez voir apparaître dans Google Analytics.
Article intéressant 🙂
si on veut affiner encore un peu les utilisateurs avec une même IP, on peut ajouter un peu plus d’informations dans le hash (par exemple si disponible le user agent ou d’autres entête HTTP lié au navigateur).
@Damien : Non, c’est tentant mais c’est une fausse bonne idée. Tu tombes dans le « fingerprinting », qui est considéré comme un traceur au même titre que les cookies.
Voir cet article de la CNIL : Cookies et traceurs : que dit la loi ?
(il contient un lien vers cette explication du fingerprinting)
Déjà, le calcul d’un identifiant à partir de l’adresse IP semble ne pas entrer dans le cadre du fingerprinting (surtout en réduisant la fenêtre temporelle de suivi), mais ce n’est pas très clair.
ah j’avais raté cette « subtilité », bah j’ai appris un truc aujourd’hui
Et moi j’ai découvert ton blog 🙂
Personnelement, je ne fait pas confiance à Google pour ne pas enregistré l’ip des visiteurs simplement car je lui demande gentiment.
Si je ne me trompe pas, c’est la machine du client qui fait l’appel de tracking, avec son ip donc.
Il la stock donc forcément dans leur logs, pour des raisons technique variées (et légitime), et que rien de me permet de savoir si google ne s’en sert pas pour autant. Cet aspet (le client fait l’appel lui même au serveur de google) à lui seul rend ta démarche caduc selon moi. Mais je suis extremiste de ce coté là je te l’accorde.
Ensuite, Google peut tout a fait continuer de faire son fingerprinting avec les info qu’il a, ce qu’il fait très certainement. (UserAgent, ip, date, ordre des headers, …)
Bonjour à tous,
Je viens de tester cette solution, mais le paramètre « client_storage = none » n’empêche pas le script de déposer les cookies.
Je n’ai d’ailleurs pas trouvé le paramètre client_storage dans la doc de Google https://developers.google.com/s/results/analytics/devguides/collection/gtagjs?q=client_storage
Est-ce que je suis le seul chez qui cela ne fonctionne pas ?
Merci
@Zed : Si tu es en mode parano, tu as sûrement raison. Disons que je suis plus pragmatique et moins dogmatique.
@Charlie: Renseignement pris, cette technique ne fonctionne pas avec Google Analytics v4, qui est le nouveau nom de GA « App + Web » (et « GA 360 » en version premium pour les entreprises). GA v4 est sorti en fin d’année dernière.
Mais je confirme que ça fonctionne très bien avec un tag créé il y a un peu plus d’un an.
J’avais réussi à trouver une page de documentation bien enfouie ; clairement ce n’était pas mis en avant par Google, ça ne va pas dans leur intérêt.
C’est un peu dogmatique, je suis d’accord.
À la fin, si tu veut utilisé GoogleAnlaytics, rien à dire, cependant, le message de ton article disant qu’il est possible de le faire en respectant GDPR, sans avertir le visiteur ni lui demandé son consentement, me semble un peu exagéré. Et même si légalement tout vas bien, car les « Privacy policies » s’alignent, dans le font le soucis du tracking reste le même et ne change pas.
Utiliser Google analytics implique du tracking de ses visiteurs de la part de google quoi qu’il se passe. De plus, les commentaire précédent semble indiqué que google à changer la donne et rend les astuce que tu montre invalide (ce qui n’est guère étonnant de la part de google 😀 )
Qui dit tracking de la part d’un prestataire/partenaire (ce qu’est google dans ton example), la GDPR dit recueil du consentement libre, non équivoque et éclairé du visiteur.
Non, pas d’accord. Il y a un paramètre pour demander à ce que l’adresse IP soit anonymisée. Ce paramètre est très explicite. Toi tu pars du principe que Google fait sûrement l’inverse dans notre dos ; tu es libre de penser ça, mais c’est assez gratuit.
En partant du principe que Google fait ce qu’il dit faire, le postulat de l’article reste complètement valide.
Et si une nouvelle version de Google Analytics retire ce paramètre, mais que ça fonctionne toujours pour les trackings existants, ça ne rend pas cet article caduque. Le jour où Google forcera tout le monde à migrer vers la dernière version, ce sera différent − on est d’accord.
En l’occurrence, le paramètre que Google a supprimé concerne les cookies, pas l’anonymisation de l’IP.
Si tu es certain au fond de toi que Google enregistre systématiquement l’IP de l’internaute, je ne peux que t’inviter à installer Matomo. Je ne suis pas là pour prendre la défense de Google ou te faire changer d’avis. Mais mon blog n’est pas là non plus pour troller sur Google.
> Non, pas d’accord. Il y a un paramètre pour demander à ce que l’adresse IP soit anonymisée. Ce paramètre est très explicite. Toi tu pars du principe que Google fait sûrement l’inverse dans notre dos ; tu es libre de penser ça, mais c’est assez gratuit.
Non c’est pas gratuit 😀 C’est basé sur leur comportement, leurs intérêts, ect. Mes conviction sont pas très importantes et pas le sujet.
> Et si une nouvelle version de Google Analytics retire ce paramètre, mais que ça fonctionne toujours pour les trackings existants, ça ne rend pas cet article caduque. Le jour où Google forcera tout le monde à migrer vers la dernière version, ce sera différent − on est d’accord.
Le mot caduc est un peu fort, je te présente mes excuse. Je le remplacerais par « conditionné » .Je pense aussi que ton article sera lu par des gens de bonne fois souhaitant utiliser GA éthiquement (ou simplement sans bannière GDPR) lors de la mise en place de leur site/blog/service/… Ceux la pourront ils utiliser les ancien tag ? (partant du principe qu’ils commence tout juste ?)
> En l’occurrence, le paramètre que Google a supprimé concerne les cookies, pas l’anonymisation de l’IP.
Totalement d’accord pour le cookie, de plus c’est du code JS que tu peu inspecté (même s’il est minifié/ofusqué) . Je suis plus inquiet par les appels de tracking que ce que fait le tag. Tu pourrais même faire les appels de tracking GA toi même sans passer par leur tag. (et donc bien respecter cette logique de « non pose de cookie »). Je me demande si ça existe, un tag open-source d’ailleurs.
> Si tu es certain au fond de toi que Google enregistre systématiquement l’IP de l’internaute, je ne peux que t’inviter à installer Matomo. Je ne suis pas là pour prendre la défense de Google ou te faire changer d’avis. Mais mon blog n’est pas là non plus pour troller sur Google.
Désolé si mes mots donnent l’impression de troller google. C’est pas mon souhait. Et vraiment sans troll, c’est techniquement obligatoire de fournir l’ip des visiteurs a Google. (à moins que le client passe par un VPN/TOR, ce qui n’est pas le sujet). C’est pourquoi la confiance en Google est important et ne peu être mis de coté. Je ne dis pas qu’il ne faut pas avoir confiance, (même si je le pense), je dit que c’est important de le noté.
Pour finir, ton article je le trouve très bien. Et réalisé ce que tu décrit est très bien aussi, et vas dans le bon sens je trouve (pour la Privacy, et l’expérience visiteur) . Je ne remet absolument pas en cause son contenu ni les étapes décrites.
Merci pour l’article, pas mal d’entreprises aujourd’hui ne sont toujours pas conforme au RGPD, sans parler des cookies, traçages …
Bonne initiative pour résoudre un problème qui frustre tous les développeurs et directeurs artistiques : celui du bandeau de consentement aux cookies qui pourrit l’expérience utilisateur.
Hélas, tu aurais dû pousser ta recherche plus loin du côté de la CNIL, car cette page explique clairement que Google Analytics ne pourra jamais être exempt de l’obligation du consentement : https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience
Pour la simple et bonne raison que pour avoir dispense de consentement, il faut que ce soit limité à la seule mesure d’audience sur le site ou l’application pour le compte exclusif de l’éditeur.
Or, dans les conditions d’utilisation, Google dit clairement que les données d’analyse de ton site lui appartiennent, et qu’il peut les utiliser à ses propres fins.
Ce qui nous permet d’emblée d’exclure Google Analytics, le pixel Facebook et Quantcast !
Qui plus est, les traceurs doivent se limiter à ton site, et ne doivent pas recueillir d’informations sur les autres sites que l’utilisateur visite, même si ces sites t’appartiennent.
Enfin, il faut que les traceurs aient une durée de vie maximale de 13 mois, et que les informations collectées ne soient pas conservées plus de 25 mois.
L’anonymisation de l’IP n’est qu’un seul critère parmi tant d’autres. Et ces autres critères ne sont pas respectés par Google.
Matomo peut en effet être une alternative intéressante, mais il faut configurer tout un tas de machins pour pouvoir bénéficier de la dispence de consentement… et c’est chiant.
Après avoir fait un long benchmark des différentes solutions de tracking, celle qui m’a semblé la plus simple, la plus facile à installer, la plus respectueuse de la Privacy Policy et la plus éthique est Plausible : https://plausible.io/
Pour 6 euros par mois, tu peux tracker 50 sites sans avoir besoin du consentement car tous ces critères sont respectés de base.
Il faut bien sûr s’attendre à moins de fonctionnalités car il y a moins de données qui sont récoltées.
Je suis en train de convertir mon agence de com à cette solution, car le côté anti-GAFAM et le côté respect de la vie privée semblent séduire nos clients (surtout les associations).
Je précise : je ne suis pas sponsorisé par plausible 😛
C’est le résultat de mes recherches après m’être tapé des pages et des pages de la CNIL.
@Quentin Durand : Merci pour ton commentaire, mais ton interprétation n’est pas bonne.
Le passage que tu cites sur le site de la CNIL est sous le titre «Dans quels cas les cookies sont-ils exemptés de consentement ?». Donc tout ce que tu dis est vrai si − et seulement si − un cookie est déposé sur le navigateur.
Sauf qu’avec la technique que je présente dans l’article, aucun cookie n’est déposé sur le navigateur. Donc pas de souci.
Voilà, c’est simple 🙂
Après, pour les personnes qui veulent trouver une solution clé en main, merci d’avoir indiqué Plausible.
@Amaury : voici la page de la CNIL qui définit ce qu’est un cookie : https://www.cnil.fr/fr/cookies-et-traceurs-que-dit-la-loi
Je cite :
Les termes de « cookie » ou « traceur » recouvrent par exemple :
– les cookies HTTP,
– les cookies « flash »,
– le résultat du calcul d’une empreinte unique du terminal dans le cas du « fingerprinting » (calcul d’un identifiant unique du terminal basée sur des éléments de sa configuration à des fins de traçage),
– les pixels invisibles ou « web bugs »,
– tout autre identifiant généré par un logiciel ou un système d’exploitation (numéro de série, adresse MAC, identifiant unique de terminal (IDFV), ou tout ensemble de données qui servent à calculer une empreinte unique du terminal (par exemple via une méthode de « fingerprinting »).
En bref : dès lors qu’on trace un utilisateur, c’est un traceur, et il est soumis aux règles de la Privacy Policy. On utilise par abus le terme de « cookie », mais ce n’est pas la seule technique de traçage. Et ce qui est réglementé, ce n’est pas la présence d’un cookie (qui n’est qu’un simple fichier de 4ko max), mais bien la présence d’un traceur.
Si l’outil d’analyse d’audience compte juste les pageviews sans différencier ses utilisateurs, il n’y a pas de traçage. Mais pour différencier un utilisateur d’un autre, ou reconnaître les nouveaux visiteurs des visiteurs récurrents, il faut bien « identifier » les utilisateurs (leur assigner une identité dans l’outil de mesure d’audience), donc les tracer, et c’est là que se pose le problème de la vie privée.
Oui, je connais cette page de la CNIL (si tu relis tous les commentaires, tu peux voir que je la citais déjà).
Soyons pragmatiques : si tu n’es pas capable de faire la différence entre les « pages vues » et les « visiteurs uniques par page », tes stats ne servent pas à grand-chose.
D’ailleurs, Plausible fait aussi le distinguo des visiteurs uniques (cf. https://plausible.io/docs/metrics-definitions). Le seul truc, c’est qu’ils réduisent le suivi à une seule journée. Mais sur le fond, que ce soit sur 1 jour ou sur 7 jours, c’est pareil.
La technique que j’expose dans l’article, qui se base sur l’adresse IP + le numéro de semaine, le tout anonymisé, je pense qu’elle n’entre pas dans le cadre du fingerprinting (et Plausible est d’accord avec ça, sinon ils ne feraient pas pareil).
Là encore, si tu relis les commentaires, tu verras que je pense que si on ajoute d’autres critères (comme le User-Agent du navigateur par exemple), à ce moment-là ça devient du fingerprinting.
Et si tu regardes bien, Plausible utilise justement le User-Agent dans le calcul de l’identifiant unique (cf. https://plausible.io/data-policy). De mon interprétation, ça devient du fingerprinting !
Honnêtement, ma manière de faire me paraît être dans les clous.
Je ne génère pas d’identifiant permanent. Il n’est pas possible de remonter jusqu’à une donnée personnelle à partir de l’identifiant généré. Aucune information personnelle (adresse IP, adresse email, nom, identifiant client réel) n’est remontée à Google.
Et de toute façon, si ce n’est pas dans les clous, Plausible ne l’est pas non plus.
@Amaury : merci pour ton article qui est intéressant, et merci également aux autres commentateurs d’avoir apporté des précisions.
Malheureusement, sur le plan technique, l’adresse IP réelle de l’utilisateur est automatiquement enregistrée par Google dès lors que le poste client fait l’appel au Javascript stocké sur le serveur Google. Pour rappel, lorsque le navigateur du client passe sur la ligne script src machin, il télécharge le script contenu dans l’attribut src ; et c’est là que l’information de l’IP est nécessairement transmise à Google.
L’option anonymize_ip est en pratique une option qui ne sert à rien dans la mesure où Google anonymise déjà les adresses IP qu’il collecte (c’était déjà le cas en 2005 quand j’ai commencé à creuser le fonctionnement de Google Analytics). L’anonymisation est en réalité du fingerprinting car l’objectif de Google est de suivre la navigation de ses utilisateurs sur internet, afin de leur proposer des produits et services associés à leurs centres d’intérêts. Ceci a été, est, et sera pour toujours l’unique objectif de Google. Si Google Analytics est gratuit pour les webmestres, c’est parce qu’il permet à Google de collecter de l’information.
Le fonctionnement serait différent si c’était ton serveur qui envoyait des requêtes HTTP à Google à chaque fois que quelqu’un accédait à une page ; là tu aurais la maitrise de ce qui est transmis à Google ou pas. Tant qu’on est sur du javascript, tout est entre les mains de Google, et de fait, tu sous-traites à Google la gestion de tes statistiques.
Par conséquent, d’un point de vue RGPD, quand on utilise Google Analytics sur les pages, en plus du bandeau RGPD qu’il faut mettre obligatoirement, il faut aussi avoir un contrat de sous-traitance avec Google. Plus d’infos sur l’URL que j’ai mise en lien de mon nom (Google RGPD).
Source : je suis DPO (et en train de militer pour qu’on vire Google Analytics du site internet de ma boîte ^^)
@Lone Sloane : Je ne sais pas sur quoi tu te bases pour dire que « l’adresse IP réelle de l’utilisateur est automatiquement enregistrée par Google dès lors que le poste client fait l’appel au Javascript stocké sur le serveur Google ».
Certes, Google connait l’adresse IP du client (forcément, quand on se connecte à un serveur, celui-ci connaît notre adresse IP). Mais de là à dire que Google l’enregistre, alors même qu’on a activé l’option anonymize_ip, ça revient à dire qu’on n’a absolument aucune confiance en Google.
Je ne dis pas qu’il faut avoir une confiance aveugle, hein. Mais là, clairement, il y a une option qui permet d’éviter que l’adresse IP soit stockée telle quelle. Croire que Google s’en fout et va quand même stocker l’IP, c’est être en mode parano (cf. l’échange avec Zed). Pour un DPO, être paranoïaque est sûrement une qualité, et tu as le droit de penser ça si tu veux, mais pas de l’asséner sur un ton péremptoire comme si c’était une vérité absolue et vérifiée (à moins d’avoir des sources vérifiées).
‣ Pour le bandeau RGPD, je n’ai pas non plus la même lecture que toi. À partir du moment où l’IP est anonymisée, et qu’il n’y a aucun cookie déposé sur le navigateur, il n’y a pas d’obligation d’en mettre un. C’est aussi simple que ça.
‣ Pour le contrat de sous-traitance, c’est pareil. Tu as une lecture très biaisée de la page que tu as donnée en lien. Il y est écrit « Lorsque nous agissons en qualité de sous-traitant des données personnelles ». Sauf que − encore une fois − avec le paramétrage que je propose, aucune donnée personnelle n’est stockée par Google ; donc Google n’agit pas en sous-traitant des données personnelles.
Après, libre à toi de penser que Google nous ment de toute façon, que c’est le diable prêt à tout pour nous voler nos données et nous tracer. Mais dans ce cas, tu es libre d’utiliser plein d’autres solutions. Cet article a pour but de rendre service aux personnes qui utilisent Google Analytics ; pas d’offrir une tribune aux anti-Google.
Bonjour, à tous, je découvre l’article suite à une problématique entre GA et le RGPD que nous avons dans mon entreprise.
Tout d’abord merci à toi pour ton article et aux autres pour les commentaires qui permettent d’avoir une vision d’ensemble des « deux parties » (pour ou contre l’utilisation de GA sans consentement RGPD).
Sur le papier, ta méthode me semble correcte. Ma seule interrogation serait sur la méthode d’anonymisation utilisée par Google.
En effet pour qu’une donnée soit considérée comme anonyme elle ne doit pas s’apparenter avec de la pseudonymisation.
Or, dans ton processus seul, l’IP est rendu anonyme, mais quid des autres informations (langue, horaire, localisation, …) que Google peut récupérer ?
Le seul fait de rendre anonyme uniquement l’IP ne m’empêche pas via une corrélation des données de d’identifier un utilisateur ?
Ma problématique ne vient pas du fait que Google anonymise réellement ou pas l’IP, mais est ce que cette anonymisation de seulement l’IP permet de rendre anonyme l’ensemble des jeux de données d’un utilisateur lors de la navigation ?
Merci, Killian HOARAU Développeur web
Bonne question. Le tout est de savoir si les autres informations permettent de reconnaître et de suivre une personne de manière unique. Tu cites la langue, l’horaire et la localisation. On peut déjà enlever la localisation, car elle est basée sur l’IP ; donc on peut raisonnablement penser que si l’IP n’est pas enregistrée, la localisation précise non plus.
Quand bien même, une localisation imprécise (à l’échelle d’une ville), couplée à la langue et aux heures de connexion, est-ce suffisant pour suivre quelqu’un ? Je n’ai pas la réponse à cette question. J’aurais tendance à penser que c’est suffisamment grossier pour dire que ça respecte la liberté individuelle ; ça devient du calcul statistique et non plus du suivi personnel.
Mais il faudrait qu’un spécialiste réponde.
Un point avait été soulevé par la CNIL si j’ai bien compris même une localisation non précise peut poser problème car elle permet de regrouper un certain nombre d’utilisateur (ex les personnes habitant dans la ville X)
https://www.cnil.fr/fr/lanonymisation-de-donnees-personnelles
»
Puisque le processus d’anonymisation vise à éliminer toute possibilité de ré-identification, l’exploitation future des données est ainsi limitée à certains types d’utilisation. Ces contraintes sont à prendre en compte dès le début du projet.
Pour construire un processus d’anonymisation pertinent, il est ainsi conseillé :
[…]
.de supprimer les éléments d’identification directe ainsi que les valeurs rares qui pourraient permettre un ré-identification aisée des personnes (par exemple, la présence de l’âge des individus peut permettre de ré-identifier très facilement les personnes centenaires) ;
»
Si j’ai bien compris si une donnée permet de faire une liste de personnes (dans notre cas zone de géolocalisation) alors notre jeu de donnée n’est pas anonyme.
De plus l’un des critères pour rendre un jeu de donnée anonyme est d’empêcher la corrélation. Malheureusement nous n’avons pas la certitude que Google ne soit pas capable d’appliqué cette dite corrélation. Or on peut fortement pensé qu’au vue des données qu’il possède ils sont empellement capable de faire de la corrélation pour retrouver l’utilisateur avec le jeu de donnée que nous leur fournissons?
Quoi qu’il en soit, à mon sens, si votre seul problématique est la traçabilité de votre utilisateur sur votre site une solution en accord avec la RGPD serait de faire ca en interne et de conserver ce qui permet d’identifier un utilisateur seulement au court de sa session.
Une fois la session terminé le parcours peut s’enregistrer pour un traitement futur sans pour autant avoir d’information sur l’identité de l’utilisateur.
Autant pour l’âge je comprends et je suis d’accord, autant pour les autres données je suis moins convaincu. Évidemment, tout dépend de la granularité des informations enregistrées : si Google enregistre des données géographiques en sachant que vous habitez dans un hameau de 15 habitants, ça pourrait devenir problématique.
« Quoi qu’il en soit, à mon sens, si votre seul problématique est la traçabilité de votre utilisateur sur votre site une solution en accord avec la RGPD serait de faire ca en interne et de conserver ce qui permet d’identifier un utilisateur seulement au court de sa session. »
La technique que je présente, qui revient à faire une session qui dure une semaine, me paraît pertinente. D’ailleurs on peut voir que les outils qui se disent en conformité avec la RGPD (comme Plausible, voir les commentaires précédents) utilisent cette technique.
La vraie question est donc de savoir quelles sont les informations que Google enregistre. Malheureusement ce n’est pas possible de le savoir précisément − pour ce que j’en sais. De ce que j’ai lu sur le web, le fait de demander l’anonymisation de l’adresse IP devrait avoir un impact suffisant pour être dans les clous vis-à-vis de la RGPD, mais c’est impossible à garantir à 100%. Comme cela a été dit dans les précédents commentaires, Google pourrait décider d’enregistrer l’adresse IP malgré tout, on n’a pas d’autre choix que de leur faire un minimum confiance.
Allez, pour ajouter au débat, une petite news amusante parue sur Le Monde le 20/01 : https://www.lemonde.fr/pixels/article/2022/01/20/l-utilisation-de-google-analytics-jugee-contraire-au-droit-europeen-sur-les-donnees-personnelles_6110287_4408996.html
Bonne lecture (et pour moi je suis plutôt d’accord avec leur analyse à eux !)
Hello merci pour cet article, en revanche je ne suis pas vraiment d’accord avec ce qui est dit à propos de Matomo analytics.
Je l’utilise sur plusieurs de mes sites et son installation via leur extension wordpress est très simple. Il suffit ensuite de faire un clic pour activer le mesure d’audience et anonymiser les adresses IP. Il y a même une page explicative pour être conforme au RGPD et ne pas avoir à afficher de bandeau de demande de cookies (rappelons que Matomo est directement recommandé par la CNIL donc on est clairement sur une solution validée).
J’ai lu un commentaire disant que c’était payant et fastidieux, c’est faux, Matomo est totalement open source et gratuit dans sa version de base déjà très détaillée (qui inclut des stats ecommerce d’ailleurs).
Bref je recommande aux personnes en recherche d’une alternative éthique à google analytics de tester, j’en suis très satisfait, ça ne requiert pas de compétences techniques et ça ne ralentit pas le serveur 🙂
@Lone : Ce qui a changé, c’est que l’Europe est désormais claire sur le fait que les données des utilisateurs ne doivent pas sortir hors de l’Europe. Ça change tout ! Auparavant, il fallait faire en sorte de ne pas déposer de cookie sur les navigateurs, et anonymiser l’adresse IP, pour pouvoir dire que les données personnelles sont sécurisées. Maintenant, même anonymisées, les données ne peuvent pas être envoyées chez Google aux États-Unis.
Je me répète, ça change tout. Au passage, c’est aussi valable pour des services comme Google Fonts, ou encore les CDN qui sont souvent utilisés pour charger des librairies Javascript. Et ça, je ne connais personne qui l’avait anticipé !
@Louis : Oui, Matomo est l’une des 18 solutions recommandées par la CNIL. Mais pour que ça fonctionne, il faut suivre le guide de configuration. Si Matomo est mal configuré, il n’est pas plus utilisable sans bandeau de consentement qu’une autre solution non listée par la CNIL.
À ce niveau, je préfère largement Plausible, qui n’a besoin d’aucune configuration, vu qu’il est développé de telle sorte qu’il ne récupère jamais aucune donnée personnelle.
Et Matomo est effectivement payant si on veut l’utiliser de la même manière qu’on utilise Google Analytics, c’est-à-dire sans le déployer soi-même sur des serveurs qui nous appartiennent. Certes c’est de l’open-source, mais il faut soit payer pour l’utiliser en mode SaaS, soit avoir les compétences techniques nécessaires pour le faire tourner sur un serveur en propre.
Soyons honnête deux secondes : d’un côté il faut juste ajouter un tag Javascript dans les pages web ; de l’autre côté il faut faire la même chose, et en plus installer un logiciel sur un serveur. Les deux sont loin d’être identiques dans leurs complexités, le temps à y consacrer initialement, ni le temps de maintenance dans la durée.
Oui en effet il faut bien configurer matomo, mais ça n’est pas si complexe, en tout cas dans l’environnement wordpress. L’installation sur le server se fait via une extension disponible dans le catalogue, il faut ensuite cocher ou décocher certaines cases si on veut éviter d’avoir à mettre un bandeau d’acceptation cookies (bien sûr ça retire des fonctionnalités d’analyse).
Après plausible est une alternative intéressante je suis d’accord, mais je ne l’ai pas encore testée.
Google forçant le passage à la version 4 de Google Analytics, j’ai mis un message pour dire que cet article est caduque. Personnellement, je suis passé à Plausible : il est open source, son prix est raisonnable, son interface est simple, il n’offre pas pléthore de fonctionnalités mais il offre celles dont j’ai besoin, son équipe est sympa et son support client est réactif.