Google Analytics est un outil proposé par le géant du web permettant de mesurer la fréquentation d’un site web. Dans le domaine, c’est le leader et il est utilisé par de très nombreux sites dont ce blog ;) En 2021, les différents outils Google (Google Analytics, Google Universal Analytics et Google Global Site Tag) représentent plus de 80% des parts de marché. Mais depuis quelques mois, un vent de changement commence à souffler et semble vouloir fragiliser l’hégémonie de Google sur ce marché…

Rappel des faits

Le 10 février 2022, la CNIL (“Commission Nationales de l’Informatique et des Libertés” en France) met en demeure un gestionnaire de site web pour l’utilisation de Google Analytics (https://www.cnil.fr/fr/utilisation-de-google-analytics-et-transferts-de-donnees-vers-les-etats-unis-la-cnil-met-en-demeure). Cette procédure fait suite à une série de plaintes, déposées par l’association autrichienne Noyb, ciblant 101 sites utilisant Google Analytics ou Facebook Connect (https://noyb.eu/en/eu-us-transfers-complaint-overview). 6 entreprises françaises font partie de cette liste : Le Huffington Post, Leroy Merlin, Decathlon, Free Mobile, Auchan et Sephora.

Dans le cas de Google Analytics, celui-ci attribue un identifiant unique à chaque visiteur. Cet identifiant (qui constitue une donnée personnelle) ainsi que les données qui lui sont associées sont transférés aux Etats-Unis. Selon la CNIL, ces transferts ne sont pas suffisamment encadrés, notamment au regard de la protection des données, et il existe une possibilité d’accès pour les services de renseignements américains. C’est l’une des conséquences de l’invalidation du “Privacy Shield” pendant l’été 2020 par la Cour de justice de l’UE (“Schrems II”).

La CNIL indique que les entreprises doivent cesser d’utiliser Google Analytics, dans les conditions actuelles. Elle conseille d’utiliser des outils produisant des données statistiques anonymes, permettant de sortir du champ d’application du RGPD et l’exemption du consentement.

A noter, la dernière version de Google Analytics (GA4), sortie en octobre 2020, permet d’anonymiser les adresses IP et de mieux gérer la durée de rétention des données. Cette version vient remplacer la solution actuelle (Universal Analytics) qui sera abandonnée à partir de juillet 2023. Mais à l’heure actuelle, malgré ces évolutions et un paramétrage “correct”, tout cela n’est pas suffisant vis-à-vis de la réglementation européenne.

Ai-je vraiment besoin d’avoir toutes ces informations ?

Tout cela m’a amené à remettre en question mon choix d’utiliser Google Analytics. Je m’étais déjà posé la question à l’époque de la migration du blog de Wordpress vers Hugo mais par manque de temps, je n’étais pas allé plus loin.

C’est donc le bon moment pour le faire, et ma première question a été : “ai-je vraiment besoin d’avoir des statistiques ?”. Finalement, la meilleure solution pour être respectueux et conforme par rapport à toutes les réglementations sur le droit des personnes c’est de ne plus collecter de statistiques ! C’est d’ailleurs une approche adoptée par certains blogs et je me suis sérieusement posé la question de l’adopter pour plusieurs raisons :

  • l’utilisation de plus en plus importante des bloqueurs de pub, dont certains bloquent aussi les outils de statistiques (UBlock Origin par exemple), et qui faussent donc les chiffres
  • de nombreux lecteurs lisent via les flux RSS via un agrégateur
  • l’impact important du partage sur les réseaux sociaux (le “bon” article au “bon” moment peut facilement faire exploser les compteurs)
  • la simplicité (aussi bien en termes de “charge mentale” que de complexité technique)

Finalement, je vais tout de même conserver une collecte de statistiques, mais beaucoup plus légère (en matière de quantité de données collectées et d’impact sur les performances du site). En réalité, les seules métriques qui m’intéressent réellement sont :

  • le nombre de visiteurs global, pour avoir une idée de la tendance par rapport à mon rythme de publication
  • les articles les plus vus/lus, pour me permettre de comprendre les sujets et thèmes qui intéressent et éventuellement d’orienter ma ligne éditoriale

Les alternatives SaaS

La CNIL propose une liste d’alternatives et donne des recommandations pour des solutions respectueuses des droits des personnes (https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience).

Lors d’une première analyse, j’ai identifié plusieurs solutions, principalement basée sur des offres SaaS (et donc majoritairement payante) :

  • Matomo Analytics, qui propose aussi une possibilité d’auto-hébergement, mais toutes les fonctionnalités ne sont pas disponibles (via des plugins payants)
  • Analytics Suite Delta (AT Internet), le “Google Analytics à la Française”, qui bosse notamment avec Le Monde, la FDJ, LeBonCoin et Axa. Chose intéressante à noter, l’outil est conçu pour limiter son empreinte carbone !
  • Fathom, un produit canadien, mais dont le stockage et le traitement des données est fait sur des serveurs allemands. Il respecte l’ensemble des normes sur l’exploitation des données (RGPD, ePrivacy, CCPA, PECR…). Selon leur site, “we sell software, not data” (on vend des logiciels, pas des données)
  • Simple Analytics

Ces 4 solutions sont séduisantes mais elles ne proposent pas de plan gratuit.

Les solutions “self-hosted”

J’ai décidé de partir sur une solution open-source ET self-hosted, premièrement car je ne souhaitais pas payer pour ce type de service, deuxièmement car j’ai un serveur à la maison et je voulais “m’amuser” et enfin pour avoir la maitrise du fonctionnement de l’outil et la pleine propriété des données.

Evidemment, il existe de nombreux services répondant au besoin… Mais j’ai tout de même réussi à faire une “short-list” :

Pour commencer, un petit coup de GitHub Compare histoire de prendre les tendances :D

GitHub Compare GitHub Compare

En ce qui concerne la popularité, on peut déjà noter que Plausible et Umami se dégagent nettement. Mais globalement, chaque projet est vivant et actif.

Concernant les langages utilisés, on a du Javascript, du Python et Elixir. Cela peut permettre de faire un 1er choix si jamais j’ai besoin de faire des contributions sur le projet dans l’avenir ;)

Les services qui fonctionnent sur mon serveur sont essentiellement basés sur Docker (sauf quand je n’ai pas d’autre choix…) donc je privilégie autant que possible ce mode de déploiement. L’ensemble des outils proposent un déploiement via Docker et la procédure est clairement documentée pour chacun. En bonus, ils fournissent tous un fichier docker-compose.yml !

Je souhaitais aussi un outil qui fonctionne en mode “cookie-less” (pour éviter l’affichage d’une horrible bannière de consentement…) et qui prenne en compte le header HTTP DNT (“Do Not Track”). Ce header permet d’indiquer les préférences de l’utilisateur concernant le suivi publicitaire (0 si l’on autorise, 1 si l’on préfère ne pas être suivi).

Au niveau de l’UI, je n’avais pas de grosses attentes en dehors du fait d’avoir une interface simple, moderne, lisible et dans laquelle je ne suis pas noyé par d’innombrables graphiques et tableaux… Au passage, si l’affichage en mode mobile est convenable, c’est du bonus !

Avec l’ensemble de ces critères sous le coude, j’ai finalement choisi Umami !

Mise en place d’Umami

Côté installation, c’est ultra-simple ! Un fichier docker-compose.yml est disponible sur le dépôt GitHub et il est prêt à l’emploi (modulo l’ajustement des variables d’environnements par rapport à son setup, variables que j’extrais d’ailleurs dans un fichier .env dédié).

Attention à ne pas oublier de passer le script de provisionning de la base de données PostgreSQL (qui se trouve sur le dépôt dans le dossier sql) : docker exec -i umami-db psql -U umami -d umami < ./sql/schema.postgresql.sql

Il ne reste plus qu’à lancer la stack Docker : docker-compose up -d

Lors de la 1ère connexion, n’oubliez pas de modifier le mot de passe par défaut… !

Concernant l’accès à partir de l’extérieur, l’ensemble de mes applications se trouvent derrière un reverse proxy, Traefik. C’est donc lui qui est en charge de la gestion du nom de domaine ainsi que du mapping des ports. J’aborderais ce sujet lors d’un prochain article ;)

Concernant l’intégration dans mon blog, qui pour rappel est basé sur Hugo, j’ai simplement ajouté un template qui vient embarquer dans le site le code nécessaire pour le tracking (directement au niveau du thème Tranquilpeak) :

{{ with .Site.Params.umami }}
    {{ if isset . "id" }}        
        <script async defer 
            src="{{ .url }}"    
            data-website-id="{{ .id }}" 
            data-do-not-track="true">
        </script>
    {{ end }}
{{ end }}

Ce template est appelé à partir d’un autre template head.html via la ligne suivante : {{ partial "umami.html" . }}

Les paramètres (identifiant, activation du DNT…) sont situés directement dans le fichier de configuration global d’Hugo (config.toml). Cela me permet d’éviter d’avoir à toucher au thème en cas de changement.

[params.umami]
  id = "00000000-0000-0000-0000-000000000000"
  url = "https://my-home-server.xyz/umami.js"

L’outil est d’ores et déjà en place depuis quelques jours et je suis plutôt satisfait du fonctionnement. A voir dans la durée donc… ! Je ne manquerais pas de vous faire des retours d’ici quelques mois quand j’aurai plus de recul ;)