Huit logiciels libres de mesure d'audience s'installent sur son propre serveur, mais ils ne répondent pas au même besoin. GoAccess lit les logs du serveur web et ne pose aucun script. PostHog mesure l'usage d'une application plus que l'audience d'un site, et son éditeur recommande son cloud au-delà d'environ 100 000 événements par mois. Les six autres posent un script sur les pages : Umami se contente de Node.js et de PostgreSQL, Matomo sait aussi importer des logs, et Plausible, Rybbit et Swetrix reposent sur une base ClickHouse.
Script, logs ou analytics produit : trois façons de mesurer
Un outil de mesure par script charge un fichier JavaScript qui compte les pages vues, les sources de trafic et les événements choisis. Plausible, Umami, Matomo, Rybbit, Swetrix et Open Web Analytics fonctionnent ainsi. Leur limite commune est documentée par Umami : un visiteur dont le bloqueur filtre le script n'est pas compté.
L'analyse de logs part du serveur. GoAccess lit les journaux d'accès d'Apache, de Nginx ou d'un CDN comme CloudFront : il voit les requêtes que les bloqueurs cachent aux scripts, mais rien de ce qui se passe dans le navigateur sans requête vers le serveur. Son manuel définit un visiteur unique comme une adresse IP, une date et un user agent, robots compris par défaut. Matomo fait le pont : son script import_logs.py charge des logs Apache, Nginx, IIS, HAProxy ou CloudFront, sans résolution d'écran, titres de page ni événements.
L'analytics produit suit des utilisateurs à travers une application : entonnoirs, rejeu de sessions, feature flags, tests A/B. PostHog en est l'exemple. Son README fixe lui-même la limite d'une instance auto-hébergée vers 100 000 événements par mois.
Ce que chaque outil demande pour tourner
Relevé dans les dépôts et les documentations le 5 octobre 2026.
| Outil | Licence | À faire tourner | Collecte | Cookie par défaut | Dernière version |
|---|---|---|---|---|---|
| Matomo | GPL 3.0 ou ultérieure | PHP, MySQL ou MariaDB | script, import de logs | oui, désactivable | 5.14.1, 4 oct. 2026 |
| Umami | MIT | Node.js 22, PostgreSQL | script | non | 3.4.0, 17 sept. 2026 |
| Plausible, édition communautaire | AGPL 3.0 ou ultérieure | PostgreSQL, ClickHouse, 2 Go de RAM | script | non | 3.2.1, 15 mai 2026 |
| Rybbit | AGPL 3.0 | ClickHouse, PostgreSQL, Redis, 2 Go de RAM, domaine en HTTPS | script | non | 2.9.0, 12 sept. 2026 |
| Swetrix, édition communautaire | AGPL 3.0 | ClickHouse, Redis, 2 Go de RAM | script | non | 5.4.1, 4 août 2026 |
| Open Web Analytics | GPL 2.0 ou ultérieure | PHP 8.2, MySQL, une tâche cron par minute | script | oui, 364 jours | 1.14.0, 21 sept. 2026 |
| PostHog | MIT, hors dossier ee/ | 38 services Docker, 4 vCPU et 16 Go de RAM conseillés | script | oui, 365 jours | aucune : livraison continue depuis master |
| GoAccess | MIT | aucune base, la RAM borne le volume traité | logs du serveur | sans objet | 1.12, 16 sept. 2026 |
Les trois outils bâtis sur ClickHouse recommandent 2 Go de RAM. Matomo conseille 2 CPU et 2 Go de RAM jusqu'à 100 000 pages vues par mois, et Open Web Analytics demande une tâche cron chaque minute depuis sa version 1.11.
Côté versions, Open Web Analytics n'a rien publié entre janvier 2023 et juin 2025, puis dix versions entre juillet et septembre 2026, avec un schéma de base qui change à chacune des quatre dernières. PostHog ne publie aucune version et ne prend pas de tickets venus d'instances auto-hébergées. L'édition communautaire de Plausible sort deux fois par an.
Quatre éditeurs gardent une part du produit pour leur offre payante. Matomo vend entonnoirs, cartes de chaleur et enregistrements de session en extensions séparées, sous licence propriétaire. La documentation de PostHog réserve au cloud toutes les fonctions de ses formules payantes. L'édition communautaire de Swetrix enregistre les erreurs JavaScript mais n'envoie aucune alerte, et celle de Plausible n'a ni entonnoirs, ni objectifs de revenus, ni SSO.
Ce que « sans cookie » ne règle pas
La mention « sans cookie » ne dit rien des conditions que la CNIL pose pour mesurer l'audience sans demander le consentement. Sa page sur les outils de mesure d'audience les fait porter sur l'usage des données : une mesure faite pour le seul compte de l'éditeur du site, des statistiques anonymes, aucun recoupement avec d'autres traitements ni suivi d'un site à l'autre. Elle recommande aussi d'informer les visiteurs, de limiter la durée de vie des traceurs à treize mois et de conserver les données vingt-cinq mois au plus. Elle interdit enfin aux fournisseurs de présenter leur outil comme « certifié » ou « validé par la CNIL ».
Matomo dépose des cookies par défaut, mais son option « Enforce compliance », apparue en version 5.9, masque une partie de l'adresse IP, fixe la durée de conservation et coupe le journal des visites, les profils de visiteurs, les cartes de chaleur et les tests A/B. GoAccess ne pose ni script ni cookie, mais les logs qu'il lit contiennent l'adresse IP complète, et son option d'anonymisation ne la masque que dans le rapport.
Sans cookie, les visiteurs se comptent aussi autrement. Umami calcule son identifiant de visiteur avec un sel renouvelé chaque mois : un visiteur qui revient le mois suivant compte comme nouveau.
Intégrer un script de mesure sous une CSP stricte
Une politique de sécurité du contenu sans 'unsafe-inline' refuse les scripts écrits dans la page. Le snippet d'installation de Plausible en est un : il faut le sortir dans un fichier servi par le site, puis autoriser l'origine de l'instance de mesure en script-src pour le chargeur et en connect-src pour l'envoi des événements. Le rapport HTML de GoAccess pose le problème dans l'autre sens : sa FAQ indique qu'il exige 'unsafe-inline' et 'unsafe-eval' sur la page qui le sert.
Les prises de contact se perdent facilement. Le suivi des liens sortants de Plausible compare l'hôte du lien à celui de la page, et un lien mailto: n'a pas d'hôte : les clics sur une adresse e-mail ne remontent qu'avec un événement personnalisé. Chez Umami, aucun clic n'est compté sans un attribut data-umami-event sur l'élément.