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 : le prix du VPS ne dépend pas du nombre 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 | Non en Community Edition (réservés au cloud Plausible) | Oui, via rapports personnalisés |
| Événements personnalisés | Oui, avec API props | Oui, avec API props + TypeScript SDK |
| Heatmaps / Session replay | Non | Oui (replay depuis v3.1, heatmaps depuis v3.2, 2026) |
| Segmentation avancée | Filtres combinés | Segments de session, filtres sur propriétés |
| RAM minimale recommandée | 2 Go (ClickHouse) | Aucun minimum publié (PostgreSQL, plus léger) |
| Licence | AGPL-3.0 | MIT |
Prérequis selon l'outil
Plausible requiert ClickHouse, une base de données colonnaire conçue pour l'analytique. 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 : un petit VPS suffit 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-editionen version v3.2.1 au minimum, qui corrige la faille critique CVE-2026-8467, ouumami-software/umami) puis créer un fichier.env: aucun des deux dépôts ne fournit de.env.exampleRenseigner les variables obligatoires :
BASE_URLetSECRET_KEY_BASE(Plausible) ouDATABASE_URLetAPP_SECRET(Umami), en générant chaque secret avecopenssl rand -base64 48. Ledocker-compose.ymld'Umami contient unAPP_SECRETet un mot de passe PostgreSQL d'exemple : remplacez-les par des variables du.env(${APP_SECRET}), et publiez son port en127.0.0.1:3000:3000pour que seul nginx l'atteigneLancer
docker compose up -d— l'image télécharge ClickHouse/PostgreSQL et migre le schéma automatiquementConfigurer un reverse proxy nginx avec HTTPS (Let's Encrypt) sur le domaine choisi, puis vérifier que l'en-tête
X-Forwarded-Forest bien transmisAjouter 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. Sur Umami, changez d'abord le mot de passe du compteadmincréé par défaut
Activez le blocage des bots dans le seul vhost nginx de l'analytics, jamais dans celui de votre site où la règle bloquerait aussi Googlebot (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 n'avez pas besoin de funnels ni de suivi de revenus en auto-hébergé (absents de la Community Edition, réservés au cloud Plausible)
Choisissez Umami si…
- Vous avez un VPS limité (moins des 2 Go de RAM recommandés pour Plausible) ou PostgreSQL est déjà installé
- Vous avez besoin de heatmaps et de session replay (depuis Umami 3.2, 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, à activer avec
MCP_ENABLED=1en auto-hébergé)
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 dispense de consentement les traceurs de mesure d'audience qui servent exclusivement l'éditeur du site, ne produisent que des statistiques anonymes et ne permettent ni recoupement avec d'autres traitements, ni transmission à des tiers, ni suivi de la personne d'un site à l'autre. La directive ePrivacy va dans le même sens. Attention : si vous recoupez les données avec une solution publicitaire tierce, la dispense tombe ; et un VPS hors de l'UE soulève en plus la question des transferts de données encadrés par le RGPD. 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 — Plausible sait importer l'historique GA4 (en Community Edition, après configuration de l'intégration Google :
GOOGLE_CLIENT_IDetGOOGLE_CLIENT_SECRET) ; côté Umami, conservez cet export en archiveInstaller 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 peut échantillonner au-delà de ses quotas, 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')ouumami.track()Supprimer le tag GA4 et son cookie
_gaune 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 souvent plus élevés avec Plausible ou Umami qu'avec GA4 sur le même site : sans cookie, ils n'attendent pas le consentement du visiteur, alors que GA4 ne mesure pleinement que ceux qui ont accepté ses cookies. L'écart varie d'un site à l'autre selon votre taux de consentement — ce n'est pas un bug, c'est la mesure sans bandeau.
Fonctions avancées : funnels, segments, événements et API
Chez Plausible, les funnels multi-étapes (une séquence d'URLs ou d'événements, avec le taux de conversion à chaque étape) et le suivi de revenus sont réservés à l'offre cloud : la Community Edition auto-hébergée ne les inclut pas. Plausible 3.2 (janvier 2026) permet en revanche de limiter un lien de partage à un segment, et la version 3.2.1 (mai 2026) corrige la faille critique CVE-2026-8467 : c'est le minimum à installer. La segmentation s'appuie sur des filtres combinés (source, pays, device, propriétés d'événements) que l'on peut enregistrer en segments. L'API de statistiques v2 (POST /api/v2/query) permet d'extraire n'importe quelle dimension ; l'ancien point d'accès /api/v1/stats/breakdown est désormais marqué « legacy ». Umami 3.4 (septembre 2026) va plus loin avec les segments de session — vous pouvez grouper les visiteurs par propriétés de session et rejouer leur parcours. Le session replay (Umami 3.1, avril 2026) et les heatmaps (Umami 3.2, 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) — l'éditeur recommande au moins 2 Go de RAM pour ClickHouse et Plausible, et le processeur doit gérer SSE 4.2 (ou NEON sur ARM). Si le VPS est serré, ajoutez un fichier swap de 2 Go (fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile). Consultez les logs avecdocker compose logs plausible_events_db. - Migrations Umami bloquées : après une mise à jour, si l'application refuse de démarrer avec une erreur
relation does not exist, redémarrez le conteneur (docker compose restart umami) : au démarrage, Umami applique lui-même les migrations Prisma en attente (prisma migrate deploy) ; lisezdocker compose logs umamipour repérer celle qui échoue. - 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, identifiez la table en cause dans
docker compose logs plausible_events_db, puis consultezsystem.detached_parts(docker compose exec plausible_events_db clickhouse-client --query "SELECT table, name, reason FROM system.detached_parts"), qui liste les parties détachées et la raison de leur détachement ; si des données manquent, restaurez votre dernière sauvegarde. - 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 en suivant le guide officiel de migration MySQL vers PostgreSQL de la documentation Umami.
Sauvegarder et restaurer vos données analytics
Stratégie de backup pour Plausible et Umami
Plausible / ClickHouse : utilisez l'outil
clickhouse-backup create(imagealtinity/clickhouse-backup, lancée dans un conteneur voisin qui accède au volume de données de ClickHouse) ou exportez les tables critiques en Parquet viadocker compose exec -T plausible_events_db clickhouse-client --query "SELECT * FROM plausible_events_db.events_v2 FORMAT Parquet" > events_$(date +%Y%m%d).parquetUmami / PostgreSQL : un
pg_dumpclassique 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 -T db psql -U umami umami < umami_backup.sqlPour 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
