Plausible vs Umami : quel analytics self-hosted choisir ?

Pourquoi self-héberger son analytics web

Les bénéfices d'un analytics auto-hébergé

Conformité RGPD native : aucun transfert vers des tiers, pas de consentement requis si le cookie n'est pas utilisé
Données 100 % sous votre contrôle : export CSV/SQL à tout moment, conservation indéfinie
Coût fixe : un VPS à 6 €/mois suffit pour des millions de pages vues
Script léger (< 2 Ko) : impact quasi nul sur le score Core Web Vitals
Pas de sampling : toutes les pages vues sont comptées, même sur les gros volumes
Open source : audit du code possible, pas de dépendance à un éditeur

Plausible vs Umami : comparaison des critères clés

Faites défiler le tableau

Critère	Plausible 3.2	Umami 3.4
Langage / stack	Elixir + ClickHouse	Node.js + PostgreSQL
Base de données	ClickHouse (colonnar)	PostgreSQL uniquement (MySQL supprimé en v3)
Interface	Très épurée, une seule page	Multi-sites, tableaux de bord configurables
Funnels	Oui, multi-étapes avec revenus	Oui, via rapports personnalisés
Événements personnalisés	Oui, avec API props	Oui, avec API props + TypeScript SDK
Heatmaps / Session replay	Non	Oui (v3.4, 2026)
Segmentation avancée	Filtres combinés	Segments de session, filtres sur propriétés
RAM minimale recommandée	2 Go (ClickHouse)	512 Mo
Licence	AGPL-3.0	MIT

Prérequis selon l'outil

Plausible requiert ClickHouse, une base de données colonnaire conçue pour les séries temporelles. ClickHouse est puissant mais gourmand en RAM : prévoyez au minimum 2 Go, idéalement 4 Go pour une instance confortable. Umami tourne sur PostgreSQL, bien plus léger : 512 Mo suffisent pour un site à trafic modéré. Si votre VPS héberge déjà PostgreSQL pour une autre application, Umami s'y greffe sans ressource supplémentaire. À partir d'Umami v3, MySQL n'est plus supporté ; si vous migrez depuis une ancienne installation MySQL, prévoyez une exportation et une réimportation en PostgreSQL.

Déployer Plausible (ou Umami) sur VPS

Cloner le dépôt officiel (plausible/community-edition ou umami-software/umami) et copier le fichier .env.example en .env
Renseigner les variables obligatoires : SECRET_KEY_BASE (Plausible) ou APP_SECRET (Umami), l'URL publique, les credentials de base de données
Lancer docker compose up -d — l'image télécharge ClickHouse/PostgreSQL et migre le schéma automatiquement
Configurer un reverse proxy nginx avec HTTPS (Let's Encrypt) sur le domaine choisi, puis vérifier que l'en-tête X-Forwarded-For est bien transmis
Ajouter le script de tracking sur votre site (<script defer src="https://analytics.votredomaine.com/js/script.js"></script> pour Plausible, équivalent pour Umami) et vérifier la première page vue dans le tableau de bord

Activez le blocage des bots au niveau nginx (if ($http_user_agent ~* "(bot|crawler|spider)")) pour garder vos statistiques propres sans configuration supplémentaire côté analytics.

Arbre de décision : Plausible ou Umami ?

Choisissez Plausible si…

Vous voulez une interface que n'importe quel collaborateur comprend en 5 minutes sans formation
Votre équipe n'a pas besoin de session replay ni de heatmaps
Vous disposez d'au moins 4 Go de RAM sur le VPS (ClickHouse le mérite)
Vous gérez plusieurs sites et souhaitez les piloter depuis un seul tableau de bord minimaliste
Vous avez besoin de funnels avec suivi de revenus intégré (Plausible 3.2)

Choisissez Umami si…

Vous avez un VPS limité (512 Mo–1 Go de RAM) ou PostgreSQL est déjà installé
Vous avez besoin de heatmaps et de session replay (Umami 3.4, 2026)
Votre équipe développe des intégrations sur mesure via l'API TypeScript officielle (@umami/api-client)
Vous gérez de nombreux sites pour des clients différents (multi-tenant natif)
Vous souhaitez connecter un assistant IA via MCP pour interroger vos données en langage naturel (Umami 3.4)

Conformité RGPD, CNIL et ePrivacy : ce que couvre vraiment chaque outil

Les deux outils sont conçus pour fonctionner sans cookie de tracking et sans collecte d'adresse IP complète. Plausible hache l'adresse IP avec un sel quotidien rotatif ; Umami adopte une approche similaire. Résultat : aucun identifiant persistant n'est stocké côté serveur, ce qui permet de s'affranchir du bandeau de consentement pour le seul analytics — à condition que le script ne soit pas combiné avec d'autres traceurs. La CNIL française, dans ses recommandations de 2024 sur les alternatives à GA4, cite explicitement les solutions d'analytics auto-hébergées sans cookie comme exemptées de consentement lorsque les données restent sur des serveurs sous juridiction européenne. La directive ePrivacy va dans le même sens. Attention : si vous hébergez sur un VPS en dehors de l'UE ou si vous agrégez les données avec une solution publicitaire tiers, la dispense tombe. Documenter l'hébergement (localisation du VPS, politique de rétention) dans votre registre de traitement reste obligatoire.

Migrer depuis Google Analytics 4

Étapes pour passer de GA4 à Plausible ou Umami

Exporter l'historique GA4 au format CSV via Google Analytics > Rapports > Exporter, ou via l'API Data GA4 pour les volumes importants — ni Plausible ni Umami n'importent nativement cet historique, mais vous pouvez le conserver en archive
Installer le script Plausible/Umami en parallèle du tag GA4 pendant 2 à 4 semaines pour comparer les métriques (les chiffres seront différents : GA4 échantillonne, Plausible/Umami comptent tout)
Vérifier que les événements personnalisés critiques (formulaires, clics, achats) sont bien répliqués via l'API plausible('goal') ou umami.track()
Supprimer le tag GA4 et son cookie _ga une fois satisfait — pensez à mettre à jour votre politique de confidentialité
Documenter les nouvelles métriques dans votre registre RGPD : base légale (intérêt légitime), durée de rétention, localisation du serveur

Les chiffres de trafic seront systématiquement plus élevés avec Plausible ou Umami qu'avec GA4 sur le même site : GA4 filtre une partie du trafic bot et n'échantillonne pas les sessions courtes de la même façon. Attendez-vous à +10 % à +25 % de pages vues — ce n'est pas un bug, c'est la précision sans sampling.

Fonctions avancées : funnels, segments, événements et API

Plausible 3.2 (janvier 2026) a introduit les funnels multi-étapes éditables avec suivi de revenus : vous définissez une séquence d'URLs ou d'événements, et le tableau de bord affiche le taux de conversion à chaque étape. La segmentation s'appuie sur des filtres combinés (source, pays, device, propriétés d'événements) avec le nouveau filtre « ne contient pas » ajouté en 2026. L'API Plausible est RESTful, documentée, et permet d'extraire n'importe quelle dimension via /api/v1/stats/breakdown. Umami 3.4 (août 2026) va plus loin avec les segments de session — vous pouvez grouper les visiteurs par propriétés de session et rejouer leur parcours. Les heatmaps et le session replay, ajoutés en juin 2026, permettent d'analyser visuellement le comportement sur une page. Le SDK TypeScript @umami/api-client (généré depuis OpenAPI) facilite l'intégration dans des pipelines de données. Umami supporte aussi le « stitching » de session : si un visiteur revient sur un autre appareil et s'identifie, les sessions sont fusionnées dans un seul profil.

Dépannage courant

Problèmes fréquents et solutions

ClickHouse ne démarre pas (Plausible) : vérifiez la RAM disponible (free -h) — ClickHouse nécessite au moins 1,5 Go libres au démarrage. Si le VPS est serré, ajoutez un fichier swap de 2 Go (fallocate -l 2G /swapfile). Consultez les logs avec docker compose logs clickhouse.
Migrations Umami bloquées : après une mise à jour, si l'application refuse de démarrer avec une erreur relation does not exist, forcez les migrations manuellement : docker compose exec umami node node_modules/.bin/db-migrate up --config src/db/umami/database.json.
Pages vues non comptées : vérifiez que l'en-tête CSP de votre site autorise le domaine analytics (script-src 'self' https://analytics.votredomaine.com). Les bloqueurs de publicité peuvent aussi bloquer le script — envisagez de le servir depuis votre propre domaine (proxy de script).
ClickHouse en erreur après redémarrage brutal : si ClickHouse signale une table corrompue, lancez docker compose exec clickhouse clickhouse-client --query "SYSTEM RELOAD DICTIONARY" puis redémarrez le conteneur.
Umami v3 : erreur après migration depuis MySQL : Umami v3 a supprimé le support MySQL. Si vous upgradez depuis une v2 avec MySQL, exportez d'abord toutes les données (CSV ou dump SQL), provisionnez PostgreSQL, puis réimportez via les scripts de migration officiels fournis dans le dépôt.

Sauvegarder et restaurer vos données analytics

Stratégie de backup pour Plausible et Umami

Plausible / ClickHouse : utilisez docker compose exec clickhouse clickhouse-backup create (avec l'image altinity/clickhouse-backup) ou exportez les tables critiques en Parquet via clickhouse-client --query "SELECT * FROM plausible_events_db.events FORMAT Parquet" > events_$(date +%Y%m%d).parquet
Umami / PostgreSQL : un pg_dump classique suffit — docker compose exec db pg_dump -U umami umami > umami_$(date +%Y%m%d).sql. Planifiez-le en cron quotidien et envoyez le fichier vers un stockage objet (S3, Backblaze B2)
Testez la restauration au moins une fois par trimestre sur un VPS de staging : docker compose exec db psql -U umami umami < umami_backup.sql
Pour Plausible, vérifiez aussi le backup du volume Docker qui contient les données PostgreSQL de la base applicative (distinct de ClickHouse)
Documentez la procédure de restauration dans votre runbook — une sauvegarde non testée n'en est pas une