Programmation

Se passer de google analytics tout en respectant la vie privée

Publié le 9 min de lecture

Pour un petit site, comme un blogue ou un portfolio, Google Analytics est une solution disproportionnée. Il faut ajouter un script tiers, afficher un bandeau de consentement, accepter que les données des visiteurs partent chez un géant publicitaire, puis naviguer dans une interface conçue pour des équipes marketing. Pourtant, les questions qu'on se pose vraiment sont simples : combien de personnes lisent mes articles, lesquels, d'où viennent-elles, et sur quel appareil ?

Pour répondre à ces questions, un petit module d'analytics maison suffit. C'est ce que j'ai construit pour davidpaquette.com, et voici les choix qui le rendent léger et respectueux des visiteurs.

Pourquoi éviter les outils tiers

Les raisons de se passer d'un service externe tiennent en quatre points.

La vie privée

Un script d'analyse tiers dépose des témoins (cookies), identifie les visiteurs d'un site à l'autre et envoie des données hors de votre contrôle. Pour un site personnel, c'est un prix élevé pour un simple compteur de visites.

La performance

Chaque script externe ajoute des requêtes réseau, du JavaScript à exécuter et un point de défaillance supplémentaire. Un site rapide le reste plus facilement quand il ne charge rien d'extérieur.

La simplicité

Un bandeau de consentement est un irritant pour le visiteur, et sa gestion est une charge pour le propriétaire du site. Si l'on ne dépose aucun témoin de suivi et qu'on ne partage rien avec des tiers, la question se pose bien différemment.

La propriété des données

Avec un module maison, les statistiques vivent dans un fichier que l'on possède. On décide de ce qu'on garde, pendant combien de temps, et on peut tout effacer d'un clic.

Ce qu'on collecte, et ce qu'on laisse de côté

La règle de départ est de ne collecter que ce qui répond à une question réelle. Pour chaque page vue, mon module enregistre six informations :

  • l'horodatage de la visite;
  • le chemin de la page consultée;
  • la provenance externe, c'est-à-dire le site d'où vient le visiteur, sans les paramètres de l'adresse;
  • le type d'appareil : ordinateur, mobile ou tablette;
  • l'adresse IP, anonymisée avant même d'être écrite sur le disque;
  • une courte empreinte du navigateur.

Rien d'autre. Pas de témoin, pas de profil, pas de suivi d'une page à l'autre, pas d'identifiant persistant. Le module n'ajoute rien au code HTML des pages ni aux en-têtes envoyés au visiteur : la collecte se fait côté serveur, après l'envoi de la réponse, de sorte que le visiteur n'en perçoit aucun effet.

Le module est également sélectif sur ce qu'il compte. Il ignore tout ce qui n'est pas une vraie lecture de page : les requêtes autres que GET, les réponses qui ne sont pas des pages HTML réussies, l'interface d'administration, les préchargements de navigateur et les robots connus (moteurs de recherche, moniteurs de disponibilité, outils de ligne de commande). Mes propres visites sont aussi exclues grâce à une liste d'adresses à ignorer. Le résultat est un compteur plus proche de la réalité que bien des outils qui gonflent leurs chiffres avec du trafic automatisé.

Tronquer les adresses IP et limiter la conservation

L'adresse IP est la donnée la plus délicate. Elle est utile pour deux raisons : estimer le nombre de visiteurs distincts et deviner le pays. Mais une adresse complète peut, dans certains contextes, identifier une personne ou un foyer.

La solution est de ne jamais stocker l'adresse complète. Pour une adresse IPv4, le dernier octet est remplacé par zéro : 203.0.113.57 devient 203.0.113.0. Pour une adresse IPv6, on ne garde que les trois premiers groupes, ce qui correspond à un préfixe de type /48. Cette anonymisation est faite avant l'écriture, donc l'adresse complète n'existe jamais dans les fichiers de statistiques. On perd un peu de précision, mais la géolocalisation par pays reste fiable et le comptage des visiteurs reste utilisable.

L'autre levier est la durée de conservation. Mon module applique une purge automatique : les visites de plus de 24 mois sont supprimées. Ce délai est configurable. Conserver des données indéfiniment « au cas où » est une mauvaise habitude; deux ans suffisent amplement pour comparer une année à la précédente.

Une analyse sans témoin de suivi

Comment compter des visiteurs sans témoin ? En acceptant une approximation honnête. Mon module combine l'adresse IP anonymisée avec une courte empreinte calculée à partir de l'agent utilisateur du navigateur (seuls huit caractères du résultat sont conservés). Deux visites avec la même combinaison sont comptées comme venant du même visiteur.

Cette méthode a des limites assumées. Deux personnes derrière la même connexion, avec le même navigateur, apparaîtront comme une seule. Une personne qui passe du téléphone à l'ordinateur sera comptée deux fois. Quelqu'un dont l'adresse change pendant la journée sera, elle aussi, comptée plus d'une fois. Pour un site de taille modeste, ces écarts n'ont aucune importance : l'objectif est de suivre une tendance, pas de facturer des clients à la visite.

Avant de renoncer au bandeau de consentement, vérifiez toutefois les règles de votre juridiction (Loi 25 au Québec, RGPD en Europe). Les exigences varient, et l'absence de témoin ne règle pas, à elle seule, toutes les obligations d'information. Une politique de confidentialité claire, qui décrit ce qui est collecté et pourquoi, reste indispensable.

Les statistiques par pays, grâce à une base GeoIP gratuite

Savoir de quels pays viennent les lecteurs est instructif, surtout pour un site en français : on voit l'importance relative du Québec, de la France, de la Belgique ou de l'Afrique francophone. Pas besoin d'un service payant pour cela. Il existe des bases de géolocalisation gratuites, comme DB-IP Lite, qui associent une plage d'adresses IP à un pays.

Dans mon module, la résolution du pays se fait en local, au moment de l'importation des données, et non sur le serveur de production. Cela présente plusieurs avantages : aucune requête vers un service externe, aucun ralentissement pour le visiteur et la possibilité de mettre à jour la base de géolocalisation quand on le souhaite. Les visites dont le pays n'a pas pu être déterminé sont marquées comme inconnues, et on peut relancer la résolution plus tard avec une base plus récente.

Comme l'adresse est tronquée, la précision se limite au pays, ce qui est exactement le niveau d'information dont on a besoin ici.

Rapatrier les données en local par FTP, puis purger la production

C'est la partie la plus originale de l'architecture. En production, le module se contente d'ajouter une ligne par visite dans un simple fichier texte (au format JSON, une ligne par page vue). Aucune base de données, aucune requête lourde, aucun traitement : écrire une ligne à la fin d'un fichier est l'une des opérations les plus rapides qui soient. Un plafond de taille protège le serveur : si le fichier dépasse 20 Mo, on cesse d'enregistrer jusqu'au prochain rapatriement.

Les statistiques ne sont ni analysées ni affichées sur le serveur public. Depuis mon poste local, un bouton d'administration télécharge les fichiers de visites par FTP, les importe dans une base SQLite locale, puis les efface de la production. Le serveur public ne garde donc que les visites récentes, qui n'ont pas encore été rapatriées.

Ce découpage a de nombreux avantages :

  • la production reste légère et sans interface d'administration d'analytics, donc sans surface d'attaque supplémentaire;
  • les données sensibles, même anonymisées, ne s'accumulent pas sur un serveur exposé;
  • l'importation se fait par lots, ligne par ligne, sans charger de gros fichiers en mémoire;
  • elle est idempotente : un fichier déjà importé n'est jamais inséré deux fois, ce qui évite les doublons si l'on relance l'opération;
  • toute l'analyse se fait en local, dans un environnement privé, avec des filtres par date, par mois, par année ou par plage de dates.

Visiteurs uniques contre visites : ce que chaque chiffre dit vraiment

Un tableau de bord d'analytics affiche en général deux chiffres qu'on confond souvent.

Les visites

Les visites (ou pages vues) comptent chaque chargement de page. Un lecteur qui consulte cinq articles génère cinq visites. C'est une mesure de l'activité du site.

Les visiteurs uniques

Les visiteurs uniques comptent des personnes distinctes sur la période choisie. Le même lecteur qui consulte cinq articles dans la journée ne compte que pour un seul visiteur. C'est une mesure de la portée, c'est-à-dire du nombre de personnes atteintes.

Le rapport entre les deux est révélateur. Si un site affiche 1 000 visites pour 900 visiteurs uniques, la plupart des lecteurs lisent une seule page puis repartent : ils sont probablement arrivés par un moteur de recherche, ont trouvé leur réponse et sont partis. Si le même site affiche 1 000 visites pour 300 visiteurs, les lecteurs explorent plusieurs pages, ce qui indique un contenu qui donne envie d'en lire davantage.

Il faut aussi retenir que le nombre de visiteurs uniques dépend de la période. Un visiteur qui revient chaque jour pendant une semaine compte pour un seul visiteur unique sur la semaine, mais pour sept sur sept jours consécutifs additionnés. On ne peut donc pas additionner les visiteurs uniques de chaque jour pour obtenir ceux du mois. Mon module calcule chaque total directement sur la période demandée, ce qui évite cette erreur classique.

Ce que ce modèle ne fait pas

Il serait malhonnête de présenter cette approche comme un remplacement complet de Google Analytics. Elle ne suit pas les parcours d'un utilisateur à travers le site, ne mesure pas le temps passé sur une page, ne gère pas les objectifs de conversion et ne propose pas de segmentation d'audience. Pour une boutique en ligne ou un site dont le revenu dépend de la publicité, ces fonctions comptent.

Mais pour un blogue, un site de portfolio ou un site de petite entreprise, les questions de base sont presque toujours les mêmes : quelles pages sont lues, par qui, d'où, sur quel appareil et avec quelle évolution dans le temps. Un module de quelques centaines de lignes y répond sans compromis sur la vie privée.

Conclusion

Mesurer son audience ne devrait pas exiger de céder les données de ses lecteurs. Collecter peu, anonymiser tôt, conserver brièvement, calculer en local : ces quatre principes suffisent à bâtir des statistiques utiles et respectueuses. Le résultat est un site plus rapide, sans bandeau envahissant, dont les données restent entre vos mains.

Et si vos besoins grandissent un jour, rien ne vous empêche d'adopter un outil plus complet. Mais commencez par vous demander quelles questions vous posez réellement : vous constaterez peut-être qu'un simple fichier texte et une base SQLite y répondent déjà très bien.

À lire aussi