Après Schrems II, plusieurs autorités européennes de protection des données ont conclu que Google Analytics a créé des problèmes illégaux de transfert de données entre l'UE et les États-Unis dans le cadre de l'ancien dispositif de transfert.
Le cadre EU-U.S. Data Privacy Framework a depuis lors modifié la base juridique pour les fournisseurs américains certifiés, mais de nombreux propriétaires de sites soucieux de la vie privée évitent toujours GA4 car il reste lié à l'écosystème publicitaire de Google, aux contraintes de consentement et aux questions de traitement transfrontalier.
Pour les sites qui souhaitent une configuration de confidentialité plus propre, la solution concrète est de migrer les analyses de GA4 vers une solution auto-hébergée, dans un centre de données en UE, avec un suivi en première partie et moins de questions liées au traitement transfrontalier.
Quatre options reviennent sans cesse dans les comparatifs : Umami, Matomo, Fathom Lite et Ackee. Deux sont actives et valent votre temps. L'une est figée en fonctionnalités et publie peu. L'autre est active mais de niche. Cet article compare les quatre, vous donne une règle de décision par archétype et associe chaque outil au plan VPS qui lui convient le mieux.
En bref
La version courte n'est pas compliquée. La plupart des sites devraient commencer avec Umami, passer à Matomo uniquement pour des besoins de rapports plus intensifs, ignorer Fathom Lite, et traiter Ackee comme un choix de préférence de niche.
- Utiliser Umami pour les blogs personnels, les SaaS indépendants et tout ce qui nécessite un tableau de bord d'analyse lisible par des non-ingénieurs. Fonctionne facilement sur un VPS avec 1 GB RAM. Sous licence MIT. Sans cookies par défaut.
- Utiliser Matomo lorsque vous avez réellement besoin d'entonnoirs, de suivi e-commerce, de cartes de chaleur ou d'enregistrements de sessions dans un seul outil. La surface fonctionnelle complète coûte davantage en RAM et en charge opérationnelle. Le minimum réaliste est de 2 GB RAM pour les petits sites ; 4 GB pour les sites à trafic modéré avec les fonctionnalités par défaut activées.
- N'utilisez pas Fathom Lite. L'image Docker open source n'a pas été mise à jour depuis cinq ans. Les mainteneurs sont passés entièrement à Fathom Analytics commercial. L'exploiter comme service exposé sur internet en 2026 représente un risque de sécurité et de compatibilité.
- Ackee est actif mais évolue moins vite qu'Umami. Choisissez-le uniquement si l'esthétique du tableau de bord compte spécifiquement pour vous. Sinon, optez par défaut pour Umami.
Les quatre candidats, en bref
La liste restreinte est plus courte qu'il n'y paraît. Umami et Matomo sont les choix sérieux pour la plupart des configurations d'analyse auto-hébergées. Fathom Lite apparaît encore dans d'anciennes listes, mais la version open source est trop en retard. Ackee fonctionne encore, mais il se rapproche davantage d'un choix de préférence que d'une recommandation par défaut.
Umami
Umami est une application Node.js s'appuyant sur PostgreSQL. Sous licence MIT. Développement actif avec des commits hebdomadaires et des versions taguées régulières tout au long de 2025 et jusqu'en 2026. La version stable actuelle est v3.1.0.
Le processus Node tourne en veille à environ 200 Mo de RAM. Postgres ajoute 150 à 250 Mo supplémentaires selon la configuration. La pile complète tourne confortablement avec 1 Go au total. Le script de suivi fait environ 2 Ko. Sans cookies par défaut ; aucun identifiant tiers ; aucune bannière de consentement requise selon la plupart des interprétations des régulateurs européens.
- Point fort principal : le tableau de bord le plus épuré de tous les outils de cette sélection, la friction de configuration la plus faible, la plus petite empreinte opérationnelle.
- Faiblesse principale : les fonctionnalités de funnel et de heatmap sont moins développées que celles de Matomo, et l'interface de gestion multi-sites fonctionne mais est moins aboutie à l'échelle d'une agence.
Matomo
Matomo est une application PHP vieille de 15 ans, s'appuyant sur MySQL ou MariaDB. Le projet s'appelait autrefois Piwik. GPL v3 pour le cœur ; certains plugins avancés (heatmaps, enregistrement de session, tests A/B) sont commerciaux. La version stable actuelle est v5.10.0.
Le minimum réaliste en RAM est de 1,5 à 2 Go au total : les workers PHP-FPM consomment chacun 50 à 80 Mo, MariaDB nécessite 512 Mo pour être à l'aise, nginx est modeste mais présent, et le cron d'archivage fait régulièrement pic sur le CPU et la mémoire.
- Point fort principal : la plus grande surface de fonctionnalités parmi tous les outils d'analytique open source. Entonnoirs, attribution multiple, e-commerce, objectifs, dimensions personnalisées, segments, attribution marketing, rapports style GA4.
- Faiblesse principale : le tableau de bord est dense (certains utilisateurs le trouvent semblable à Excel) et l'attention opérationnelle requise est réelle. Vous devrez savoir ce qu'est un cron d'archivage.

Fathom Lite
Fathom Lite est l'implémentation Go open-source originale de Jack Ellis et Paul Jarvis. Sous licence MIT. Le dépôt existe toujours sur GitHub, et la dernière version GitHub est v1.3.1. L'image Docker fonctionne toujours avec pull.
L'image Docker sur Docker Hub n'a pas été mise à jour depuis plus de cinq ans. La branche master du dépôt n'a eu que des commits sporadiques sans nouvelle version dans cet intervalle. Le README indique que la version Lite ne recevra plus de nouvelles fonctionnalités, bien que les mainteneurs la décrivent toujours comme maintenue pour les correctifs à long terme. Le produit activement développé est Fathom Analytics en version commerciale.
Faire tourner en 2026 une application d'analyse figée fonctionnellement avec une image Docker publique obsolète est un risque. Le comportement des scripts de tracking dans les navigateurs a évolué. Les mises à jour de runtime et de dépendances que les projets actifs publient régulièrement ne sont pas intégrées dans la version publique Lite.
Si vous trouvez Fathom Lite recommandé dans un tour d'horizon 2026, vérifiez la date de l'image Docker et l'historique des versions avant de le considérer comme un choix de production.
Le SaaS commercial Fathom Analytics sur usefathom.com est un produit différent. C'est bien si vous acceptez qu'il s'agit d'un SaaS et non d'un auto-hébergement. Ce n'est pas l'objet de cet article.
- Point fort principal : binaire minuscule, tracker léger, idée de produit originale et simple.
- Faiblesse principale: codebase open source dont les fonctionnalités sont figées, image Docker obsolète, parcours de publication flou et aucune raison valable de le déployer comme service analytique exposé sur internet en 2026.
Ackee
Ackee est un outil d'analyse Node.js + MongoDB. Sous licence MIT. La version actuelle est v3.6.0. Le mainteneur publie des correctifs de bogues et des mises à jour de dépendances. Les développements majeurs ont ralenti. Le tableau de bord est minimaliste, le tracker est léger et l'empreinte ressource est comparable à celle d'Umami.
Ackee fonctionne. La raison pour laquelle il se retrouve dans la colonne niche est qu'Umami est au moins un cran au-dessus sur tous les axes pertinents : vitesse de développement, écosystème, documentation tierce, intégrations disponibles.
Si vous avez déjà une bonne raison de préférer Ackee (vous avez testé les deux et préféré son tableau de bord), choisissez-le. Sinon, optez pour Umami et passez à la suite.
- Point fort principal : tableau de bord épuré, tracker léger, faible empreinte en ressources, encore maintenu.
- Faiblesse principale : rythme de développement plus lent qu'Umami, écosystème plus restreint, moins d'intégrations et moins de documentation tierce pour ceux qui ont besoin d'aide après l'installation.
Cadre de décision : choisir par archétype
L'archétype compte plus que la grille de fonctionnalités. Un blog personnel n'a pas besoin du même stack d'analyse qu'un produit SaaS ou une agence gérant des comptes clients. Commencez par le propriétaire du tableau de bord, la profondeur des rapports et la quantité de travail serveur que vous êtes prêt à assumer. Le choix de l'outil devient bien plus simple ensuite.
Blog personnel ou propriétaire d'un seul site
Choisissez Umami. La configuration se résume à un seul fichier Docker Compose. Le tracker est un script d'une ligne dans votre <head>. Le tableau de bord est lisible sur un téléphone. La RAM et le stockage sont des préoccupations négligeables à cette échelle.
Aucun second outil n'est nécessaire. Si vous quittez GA4 pour des raisons de principe ou pour supprimer la bannière de cookies, Umami règle la question.
Fondateur d'un SaaS indépendant ou petite équipe produit
Optez par défaut pour Umami. N'ajoutez Matomo que si vous avez identifié une fonctionnalité précise qui manque.
La raison la plus courante d'ajouter Matomo ici est le reporting par entonnoir sur les flux d'inscription et de mise à niveau qu'Umami ne gère pas encore aussi bien. La question décisive est de savoir si quelqu'un dans l'équipe souhaite activement gérer la surface plus large de Matomo.
Si la réponse est non, Umami, combiné à quelques requêtes en base de données sur votre base produit, vous donnera 90 % des insights entonnoir pour 10 % du coût opérationnel. Si votre produit génère beaucoup d'événements et que vous souhaitez une interface entonnoir native, installez Matomo. Le coût opérationnel est plus élevé : Matomo, une base de données, une couche serveur web, Redis en option, plus de RAM et un job d'archivage à gérer.
Agence gérant 10+ propriétés clients
Choisissez Matomo. La gestion multi-sites est mature. Les permissions par utilisateur et les connexions par client sont des fonctionnalités de premier ordre. Les plugins payants de heatmap et d'enregistrement de session sont des différenciateurs que les agences facturent réellement.
L'interface multi-sites d'Umami fonctionne mais semble moins étoffée à l'échelle d'une agence : filtrage sur de nombreux sites, attribution d'accès au niveau client, export de rapports personnalisés. L'interface de Matomo est dense, mais cette densité vous offre les fonctionnalités que le travail exige.
Si l'agence dispose d'un portefeuille de sites à faible trafic et que la mission principale est de produire des rapports de trafic mensuels plutôt qu'une optimisation du taux de conversion, Umami reste un choix défendable et permettra d'économiser sur les coûts d'infrastructure. La décision porte sur le plafond fonctionnel, pas sur le mauvais outil.
Comparaison fonctionnalité par fonctionnalité
| Fonctionnalité | Umami | Matomo | Fathom Lite | Ackee |
|---|---|---|---|---|
| Licence | MIT | GPL v3 (plugins payants commerciaux) | MIT | MIT |
| Pile | Node + PostgreSQL | PHP + MySQL ou MariaDB | Go + MySQL ou SQLite | Node + MongoDB |
| Développement actif (2026) | Oui, commits hebdomadaires | Oui, équipe à temps plein | Non, ~5 ans sans mise à jour | Oui, faible activité |
| Sans cookies par défaut | Oui | Configurable (indicateur requis) | Oui | Oui |
| Gestion multi-sites | Oui, basique | Oui, mature | Oui, basique | Oui, basique |
| Entonnoirs et objectifs | Limité | Totale | Aucune | Aucune |
| Suivi e-commerce | Aucune | Totale | Aucune | Aucune |
| Heatmaps et enregistrement de session | Replay de session ; pas de heatmaps natives | Oui (plugin payant) | Aucune | Aucune |
| Taille du script de tracking | ~2 KB | ~22 KB | ~1 KB | ~2 KB |
| Plancher de RAM réaliste | 1 GB total | 2 GB total | n/a (ne pas déployer) | 1 GB total |
| Complexité opérationnelle | Faible | Moyen | n/a | Faible |
| Recommandation | Par défaut pour la plupart | Quand le plafond de fonctionnalités est important | À éviter | Niche |
Dimensionnement VPS en chiffres clairs
L'outil adapté dépend en partie de ce que vous êtes prêt à payer pour la machine qui le fait tourner.
| Installation | RAM réaliste | CPU | Le stockage | Bonne base VPS |
|---|---|---|---|---|
| Umami + Postgres, faible trafic | 512 MB-1 GB | 1 vCPU | 20-25 GB NVMe | Petit VPS |
| Umami + Postgres, marge de croissance | 1-2 GB | 1-2 vCPU | 40-60 GB NVMe | VPS petit à moyen |
| Ackee + MongoDB | 1 GB | 1 vCPU | 20-25 GB NVMe | Petit VPS |
| Matomo + MariaDB, petit site | 1.5-2 GB | 1-2 vCPU | 40-60 GB NVMe | VPS intermédiaire |
| Matomo + MariaDB, trafic modéré, fonctionnalités par défaut | 2-4 GB | 2 vCPU | 80-120 GB NVMe | VPS moyen à grand |
| Matomo + MariaDB + carte de chaleur ou enregistrement de session | 4 GB+ | 2-4 vCPU | 120 GB+ NVMe | VPS plus grand |
Pourquoi ces minimums sont importants :
Le faible encombrement d'Umami est délibéré. Umami stocke des événements d'analyse légers dans PostgreSQL plutôt que des journaux complets de requêtes web, ce qui maintient une croissance modeste de la base de données pour les sites de petite et moyenne taille.
Le processus Node reste sous 250 MB même lorsque plusieurs milliers de visiteurs consultent le site quotidiennement. La croissance de Postgres est modeste.
Un VPS avec 1 Go de RAM et 25 Go de NVMe stocke plusieurs années d'analyses pour un site de solopreneur typique. J'utilise Umami sur un VPS de 1 Go à Frankfurt pour un petit projet ; la latence depuis Lagos est d'environ 110 ms, le tableau de bord répond en moins de 400 ms et le serveur tourne en silence depuis des mois.
L'empreinte de Matomo est plus importante car son architecture est plus ancienne et plus générale. Chaque worker PHP-FPM consomme 50 à 80 Mo. MariaDB fonctionne mal avec moins de 512 Mo alloués.
Le cron d'archivage horaire recommandé par Matomo peut provoquer des pics CPU et mémoire, donc le VPS a besoin de marge au-delà de l'empreinte normale de PHP et de la base de données. Un VPS de 1 Go fait tourner Matomo techniquement pour de très petites installations, mais le tableau de bord est lent et le risque d'OOM lors de l'archivage est bien réel. Le plancher de 2 Go n'est pas une restriction arbitraire. C'est le seuil à partir duquel l'outil cesse de vous résister.
La croissance du stockage est rarement le goulot d'étranglement. Un disque NVMe de 60 Go contient de nombreuses années de données Matomo, même avec la conservation des journaux bruts activée par défaut. Si vous activez l'enregistrement de session, prévoyez environ dix fois plus d'espace disque par mois et réévaluez la taille du plan chaque année.
Pro Tip
If you are running Umami today on a 1 GB VPS and your traffic is growing, the upgrade path is straightforward. Snapshot the VPS, resize to 2 GB, restart. The extra RAM gives Postgres and the Node process more headroom.
Datacenters européens et l'angle RGPD

La problématique Schrems-II et le transfert GA4 évoqués en introduction constituent le contexte juridique ici. L'auto-hébergement ne rend pas automatiquement l'analytique conforme, mais il supprime le schéma par défaut de GA4 : les données visiteurs quittent votre site, entrent dans la pile analytique de Google et soulèvent des questions de traitement transfrontalier.
Auto-héberger votre analytique au sein de l'UE simplifie la pile au niveau de la juridiction. Ce n'est pas un raccourci de conformité. Les données sont collectées par votre tracker, envoyées directement à votre serveur, traitées et stockées dans la région que vous avez choisie.
Votre fournisseur de VPS peut toujours être considéré comme un sous-traitant, donc les conditions de traitement, les contrôles de sécurité, les règles de conservation et les mentions de confidentialité restent importants. Le point est plus précis : il n'y a pas de prestataire SaaS d'analytique au milieu, et pas de transfert d'analytique transatlantique par défaut à la façon de GA4.
Le choix du datacenter doit suivre votre audience et votre posture de conformité. Frankfurt est le choix habituel pour les publics allemands, autrichiens et plus largement européens. Amsterdam convient naturellement au trafic Benelux.
London convient aux cas UK GDPR, mais étant hors de l'UE, ce n'est pas la même réponse pour les exigences de résidence des données strictement européennes. Zurich convient aux audiences suisses et aux besoins de confidentialité propres à la Suisse, mais se trouve également hors de l'UE.
Pro Tip
Putting a US-headquartered CDN or proxy in front of your analytics endpoint can reintroduce transfer analysis and processor-review work. If the whole point is EU-only analytics handling, terminate TLS directly on the VPS or document the CDN setup carefully.
Aperçu des mécanismes d'installation
Il s'agit de la configuration de déploiement, pas d'un tutoriel. Les guides complets étape par étape sont des articles séparés.
Umami : Un seul fichier Docker Compose. Deux conteneurs : Umami (Node) et PostgreSQL. Une seule variable d'environnement : DATABASE_URL. Port par défaut 3000. Proxy inverse en frontal pour le TLS (Caddy est l'option la moins contraignante ; nginx-proxy-manager et Traefik fonctionnent aussi). Ajoutez le script de tracking (une ligne) dans le <head> de chaque page à suivre. Les mises à jour sont docker compose pull && docker compose up -d.
Matomo : Docker Compose avec trois à quatre conteneurs : Matomo (matomo:fpm-alpine), nginx (ou Apache) devant PHP-FPM, MariaDB, et Redis en option pour le cache. L'assistant de configuration basé sur navigateur prend en charge la première connexion à la base de données, l'utilisateur administrateur et la configuration du premier site. Le script de tracking est un snippet JS généré par Matomo et collé dans le <head>. Requis : un job cron pour l'archivage. L'option par défaut de déclencher l'archivage via URL (?force_archiving=1) fonctionne pour les petits sites mais ralentit visiblement les tableaux de bord. Les mises à jour impliquent un docker compose pull suivi d'un appel à console core:update.
Les deux : TLS via un reverse proxy est le schéma standard. Les deux projets publient des guides de mise à niveau officiels. Les deux disposent de recettes de sauvegarde fonctionnelles (pg_dump pour Umami, mariadb-dump pour Matomo).
C'est là que La marketplace de Cloudzy vraiment important. Vous pouvez déployer Umami or Matomo sur un VPS sans partir d'un serveur vierge, écrire vous-même le fichier Compose, ou passer la première heure à assembler la base de la pile.
Le VPS doit toujours être le bon serveur. L'analytique aime les disques rapides, une RAM prévisible et une région proche des personnes qui chargent votre script de suivi. Cloudzy vous offre Stockage NVMe, DDR5 RAM, jusqu'à 40 Gbps réseau, accès root complet accès, dédié IPv4 et IPv6, 12+ régions mondiales, 99.95% de disponibilité, et une garantie de remboursement de Remboursement sous 14 jours garantie.
Pour Umami, l'avantage est la rapidité : lancez, attachez votre domaine, mettez TLS devant et collez le script de suivi.
Pour Matomo, l'avantage est d'éviter le travail sur un serveur vierge avant même d'arriver à l'archivage, la rétention, les sauvegardes et les paramètres de suivi.
Quand l'auto-hébergement est le mauvais choix
Vous êtes un fondateur solo non technique, sans expérience Linux et sans temps pour l'apprendre. La bonne réponse est Plausible Cloud à 9-19 $ par mois. C'est conforme au RGPD, le tableau de bord est excellent et vous n'avez pas à gérer de serveur.
Le calcul du self-hosting ne tient que si votre temps vaut moins que l'abonnement SaaS ou si vous souhaitez réellement acquérir une expérience opérationnelle. Pour un fondateur solo non technique, ce calcul ne fonctionne pas.
Vous avez besoin de journaux d'audit en temps réel de niveau SOC2 ou HIPAA sur votre processeur d'analyse. Ni Umami open source ni Matomo open source ne fournissent cela par défaut. Vous pouvez construire vous-même la posture d'audit, mais le travail est réel et le processus de certification est un projet en soi. Achetez la conformité en tant que service pour ce cas.
Votre stack marketing nécessite GA4 ou une attribution Google Ads qui dépend des cohortes et des pixels de remarketing de Google. Les analytiques auto-hébergées ne sont pas la bonne catégorie d'outils pour l'optimisation AdWords ou Meta-Ads.
Les données de conversion doivent retourner vers Google ou Meta pour réentraîner les algorithmes d'enchères. L'analytique auto-hébergée remplace le cas d'utilisation de l'analytique descriptive (ce qui s'est passé sur mon site), pas le cas d'utilisation de l'attribution publicitaire (quelles publicités devrais-je diffuser).
Conclusion
La règle de décision est courte. Optez pour Umami par défaut pour les blogs personnels, les SaaS indépendants et les petites équipes produit. Passez à Matomo lorsque les entonnoirs, le commerce électronique ou les cartes thermiques sont incontournables et que vous disposez d'une attention opérationnelle suffisante.
Passez Fathom Lite. Choisissez Ackee uniquement si vous l'avez déjà testé et que vous préférez son tableau de bord. Faites tourner le serveur à Frankfurt ou Amsterdam si la juridiction européenne est importante ; sinon, là où se trouve votre trafic.
Le coût d'infrastructure pour un déploiement d'analyse auto-hébergé fonctionnel est entre 7 et 30 dollars par mois pour le VPS. Le coût en main-d'œuvre se résume à un fichier Docker Compose et un reverse proxy. La plupart des difficultés résident dans la décision, pas dans l'exécution.
Foire aux questions
Quel est le meilleur outil d'analyse auto-hébergé en 2026 ?
Umami est la recommandation par défaut pour les blogs personnels, les SaaS indépendants et les petites équipes produit. Il est sous licence MIT, activement développé, sans cookies par défaut, et fonctionne confortablement sur 1 Go de RAM. Choisissez Matomo pour les entonnoirs, le commerce en ligne ou les cartes de chaleur. Évitez Fathom Lite.
Fathom Lite est-il toujours maintenu ?
Non. L'image Docker open-source n'a pas été mise à jour depuis plus de cinq ans, et l'activité GitHub est sporadique et sans nouvelles versions. Les mainteneurs se concentrent désormais sur Fathom Analytics commercial. La version Lite ne devrait pas être utilisée comme un service exposé sur Internet en 2026.
L'analytique auto-hébergée peut-elle remplacer Google Analytics pour la conformité RGPD ?
Oui, sous conditions. Umami ou Matomo auto-hébergé sur un VPS en UE conserve les données d'analyse dans votre région choisie et supprime le schéma de transfert par défaut de GA4. Ne placez pas un CDN basé aux États-Unis comme Cloudflare devant le point de terminaison d'analyse si la conformité RGPD est la raison.
De combien de VPS ai-je besoin pour faire tourner Matomo ?
Le plancher réaliste est de 2 Go de RAM pour un petit site Matomo. Pour un trafic modéré avec les fonctionnalités par défaut, prévoyez 4 Go. Les cartes de chaleur et l'enregistrement de session poussent cette valeur plus haut. Ce plancher existe car PHP-FPM, MariaDB, nginx et l'archivage partagent le même serveur.
Umami a-t-il besoin d'une bannière de cookies dans l'UE ?
Selon la plupart des interprétations des régulateurs européens, non. Umami n'écrit pas de cookie de suivi par défaut. Il utilise des données de requête de première partie et les agrège côté serveur. Certaines juridictions peuvent néanmoins exiger une notice, vérifiez donc les recommandations de la DPA locale si la conformité est la raison principale.
Comment Umami se compare-t-il à Plausible auto-hébergé ?
L'histoire d'auto-hébergement d'Umami est plus fluide. Plausible Community Edition existe, mais le focus commercial de Plausible est sur le Cloud. Umami traite l'auto-hébergement comme la voie principale de distribution. Pour un déploiement prioritairement auto-hébergé, Umami est le choix le plus sûr. Pour le SaaS, Plausible Cloud et Umami Cloud fonctionnent tous les deux.
Quel emplacement de datacenter est le meilleur pour l'analytique auto-hébergée dans l'UE ?
Frankfurt est la valeur par défaut pour les audiences allemandes, autrichiennes et plus largement européennes. Amsterdam convient au trafic Benelux. London fonctionne pour le RGPD britannique, mais pas pour les exigences de résidence des données propres à l'UE. Choisissez la région la plus proche de vos visiteurs, sauf si les besoins de conformité orientent vers un endroit plus spécifique.