Vous voulez du web analytics simple, rapide, conforme RGPD. Plausible est excellent (voir notre guide dédié). Umami est l’autre choix qui s’est imposé chez les développeurs francophones d’Afrique de l’Ouest : interface dashboard ultra-moderne, performance similaire, hébergement sur n’importe quelle stack Node.js + Postgres ou MySQL. Umami v2.13 (2026) : open source MIT, dashboard dark-mode élégant, multi-sites illimités, custom events, sessions, géolocalisation, devices, sources de trafic. Auto-hébergé sur Hetzner CX22 à 4,51 €/mois pour usage illimité.

Sommaire

Pourquoi Umami en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer)
Concepts fondamentaux
Vue d’ensemble pratique
Tutoriels du cluster
Cas d’usage
Adaptation au contexte ouest-africain
Erreurs fréquentes
FAQ

Pourquoi Umami en 2026

Cinq raisons concrètes.

License MIT vs AGPL Plausible. Pour les développeurs et entreprises qui craignent les obligations virales d’AGPL, Umami sous license MIT permet usage illimité sans contrainte légale.

Stack simple. Node.js + Postgres ou MySQL. Pas de ClickHouse contrairement à Plausible. Plus simple à backup, restaurer, et debug.

UI design 2026. Dashboard moderne dark mode élégant, charts interactifs, tableau real-time fluide. Probablement le plus beau dashboard analytics open source.

Multi-sites illimité. Une instance Umami héberge des centaines de sites. Idéal pour agences digitales gérant clients multiples.

compatible RGPD (sans cookies ni tracking individuel — mention dans la politique de confidentialité recommandée). Aucun cookie, aucune donnée personnelle, aucun fingerprinting. Pas de bandeau cookies nécessaire si Umami est votre seul tracker.

Concepts fondamentaux

Sites et tracking codes

Chaque site reçoit un Website ID UUID. Snippet 1-ligne à coller dans head. Pas de configuration côté Umami nécessaire au-delà.

Sessions, events, pageviews

Umami compte trois métriques principales :

Pageviews : nombre total de pages chargées.
Visits/Sessions : sessions uniques (déduplication par jour).
Visitors : visiteurs uniques par jour.

Sans cookie, identification par hash user-agent + IP + jour. Hash change quotidiennement.

Custom events

Pour tracker actions spécifiques : signup, purchase, click button. Trigger via umami.track('event-name') JavaScript.

Properties events

Custom event peut avoir properties : umami.track('purchase', { amount: 12000, currency: 'XOF' }). Filtrable côté dashboard.

Teams et permissions

Umami Pro features (Cloud) : teams. Self-hosted : un seul user admin par défaut, multi-user via configuration custom.

API et webhooks

API REST publique. Webhook sortant pour notifier événements (Slack/Discord). Idéal pour alertes pic de trafic.

Vue d’ensemble pratique

Tutoriels du cluster Umami

Cas d’usage

Agence digitale multi-clients

Agence à Casablanca gérant 25 sites clients : une instance Umami, dashboard partagé chaque client (lecture seule), reporting mensuel automatisé.

SaaS B2B

SaaS à Abidjan : dashboard interne Umami + dashboard public temps réel sur landing.

Blog tech francophone

Média à Dakar : Umami sur articles, top performances, sources sociales (Facebook, Twitter, LinkedIn). compatible RGPD (sans cookies ni tracking individuel — mention dans la politique de confidentialité recommandée) sans bandeau cookies.

E-commerce mobile-first

Boutique à Cotonou : Umami léger ne ralentit pas mobile 4G. Track Wave checkout, Orange Money clicks, conversion rate par source.

Documentation technique

Doc API d’une fintech : Umami sur docs.app.com pour mesurer pages les plus consultées, identifier confusions UX.

Ajustements pratiques pour Dakar, Abidjan et Bamako

Quatre adaptations spécifiques.

Performance mobile. Script Umami 2 Ko gzippé. Comparé à Google Analytics 4 (45 Ko), gain 200-500 ms latence sur 3G partagée à Saint-Louis ou Bobo-Dioulasso. Conversion impactée directement.

RGPD/CDP/ARTCI/NESA conformes. Aucun cookie, aucune donnée personnelle. Pas de bandeau cookies. Privacy policy mention courte suffit.

Multilingue dashboard. Umami UI traduit en français, arabe, anglais. Configuration locale par utilisateur.

Coût. 25 sites clients sur Plausible Cloud = 475 USD/mois. Umami self-hosted = 4,51 €/mois illimité. Économie 5 700 USD/an pour agence.

Erreurs fréquentes

Erreur	Cause	Solution
Stats ne remontent pas	Adblockers	Proxify script via votre domaine
Trafic gonflé	Bots non filtrés	Configurer bot detection ou Cloudflare devant
Custom events absents	Snippet sans plugin events	Activer track-events dans embed
Real-time delay	Cache Postgres	Tuner work_mem Postgres
Multi-sites lent	Postgres pas indexé	Vérifier indexes website_id, created_at
Backup oublié	Postgres pas dump	Cron pg_dump quotidien

FAQ

Umami vs Plausible vs Matomo ? Umami plus simple/léger. Plausible avec ClickHouse plus performant à scale. Matomo plus complet mais lourd.

Capacité Hetzner CX22 ? 50 sites + 500 000 pageviews/mois confortable. Au-delà CX42.

Migration depuis Plausible ? Pas direct. Recommencer avec snippet Umami, pas d’import historique.

API REST documentée ? Oui. Endpoints publics + auth Bearer pour admin.

Cloud Umami ? Oui (umami.is) à partir de 9 USD/mois. Self-hosted gratuit illimité.

Compatible WordPress ? Oui via plugin Umami WordPress sur repo WP.

Real-time visitors ? Oui, mise à jour 60s par défaut, configurable.

Étape 1 — Choisir son architecture d’hébergement Umami

Umami v2 (la branche stable depuis 2024) tourne en Node.js avec Postgres ou MySQL. Pour une équipe basée à Dakar, Abidjan ou Cotonou qui veut éviter les 9 EUR par mois (5 905 FCFA au taux fixe 1 EUR = 655,957 FCFA) du plan Plausible Cloud, l’auto-hébergement sur un VPS à 5 EUR par mois (3 280 FCFA) est immédiatement rentable dès le premier site.

Trois architectures possibles : VPS unique avec Docker Compose (le plus simple), Kubernetes avec Postgres managé (pour scaler), ou Vercel/Railway avec Postgres externe (zéro ops). Pour un trafic jusqu’à 10 millions d’événements par mois, un VPS à 2 vCPU et 2 Go de RAM suffit largement. Au-delà, basculez sur ClickHouse côté analytics.

Étape 2 — Installer Umami avec Docker Compose

L’installation officielle se fait avec un fichier docker-compose.yml qui orchestre Umami et Postgres. Créez un dossier dédié et un fichier .env pour les secrets.

mkdir umami && cd umami
cat > docker-compose.yml <<'EOF'
services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:${DB_PASS}@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: ${APP_SECRET}
    depends_on:
      db:
        condition: service_healthy
    restart: always
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: ${DB_PASS}
    volumes:
      - umami-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: always
volumes:
  umami-db:
EOF

openssl rand -base64 32 > .secret_app
openssl rand -base64 24 > .secret_db
cat > .env <<EOF
APP_SECRET=$(cat .secret_app)
DB_PASS=$(cat .secret_db)
EOF

docker compose up -d

Au bout de 30 à 60 secondes, docker compose ps doit afficher les deux services en état « running » et « healthy » pour Postgres. La première connexion sur http://127.0.0.1:3000 demande un login avec admin / umami — changez immédiatement le mot de passe dans Settings.

Étape 3 — Exposer Umami derrière Caddy avec HTTPS automatique

Exposer le port 3000 directement sur Internet est une mauvaise idée. On met Caddy devant pour HTTPS Let’s Encrypt automatique et un sous-domaine propre type analytics.votre-domaine.com.

sudo apt install -y caddy
sudo tee /etc/caddy/Caddyfile <<'EOF'
analytics.votre-domaine.com {
    reverse_proxy 127.0.0.1:3000
    encode gzip zstd
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}
EOF
sudo systemctl reload caddy
sudo journalctl -u caddy -n 30

Vérifiez d’abord que le DNS A record pointe sur l’IP du VPS (chez OVH, Hetzner, Contabo ou un hébergeur local comme InTouch). Le journal Caddy doit afficher « certificate obtained successfully » en moins de 60 secondes. Si vous voyez « no such host », le DNS n’a pas propagé — attendez 5 minutes et relancez systemctl reload caddy.

Étape 4 — Créer un site et installer le tracker

Dans l’interface Umami, allez dans Settings → Websites → Add website. Renseignez le nom commercial et le domaine (sans https://). Umami génère un identifiant data-website-id et un snippet à coller juste avant </head> sur toutes les pages à mesurer.

<script
  defer
  src="https://analytics.votre-domaine.com/script.js"
  data-website-id="abcd1234-ef56-7890-abcd-ef1234567890">
</script>

Pour un site WordPress, collez ce snippet dans Apparence → Personnaliser → CSS additionnel n’est pas la bonne place — utilisez plutôt un plugin comme « Insert Headers and Footers » ou ajoutez-le dans header.php du thème enfant. Visitez ensuite votre site dans un navigateur en navigation privée. Dans Umami, la page Realtime doit afficher 1 visiteur actif sous 10 secondes. Aucun visiteur ? Vérifiez que script.js charge bien (onglet Network du devtools, statut 200).

Étape 5 — Mettre en place les événements personnalisés

Suivre les pages vues ne suffit pas pour mesurer un funnel SaaS ou e-commerce. Umami permet de tracker des événements custom via umami.track(). Typiquement on mesure clic sur « S’abonner », soumission de formulaire de contact, ajout panier WooCommerce.

// Bouton CTA principal
document.querySelector('#cta-pricing').addEventListener('click', () => {
  umami.track('click-pricing-monthly', { plan: 'pro', currency: 'XOF' });
});

// Soumission formulaire contact
document.querySelector('form#contact').addEventListener('submit', () => {
  umami.track('contact-submit', { source: 'homepage' });
});

Après 24 à 48 heures de trafic réel, l’onglet Events affichera vos custom events avec leur compteur. Si rien n’apparaît, ouvrez la console : typeof umami doit retourner "object". Sinon le tracker n’a pas chargé sur cette page.

Étape 6 — Configurer la rétention et les sauvegardes Postgres

Umami stocke chaque événement individuellement. Sur un site à 100 000 visites par mois, la base grossit d’environ 200 Mo par an. Sauvegardez quotidiennement, sinon une corruption disque efface 12 mois de données analytiques.

mkdir -p /opt/umami-backup
cat > /opt/umami-backup/backup.sh <<'EOF'
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
docker compose -f /home/ubuntu/umami/docker-compose.yml exec -T db \
  pg_dump -U umami umami | gzip > /opt/umami-backup/umami-$DATE.sql.gz
find /opt/umami-backup -name "umami-*.sql.gz" -mtime +30 -delete
EOF
chmod +x /opt/umami-backup/backup.sh
echo "0 3 * * * /opt/umami-backup/backup.sh" | sudo crontab -

Le lendemain matin, vérifiez la taille du fichier généré : il doit faire au minimum 500 Ko (un dump vide tourne autour de 50 Ko et signale un problème de connexion). Pour restaurer : gunzip -c umami-XXXX.sql.gz | docker compose exec -T db psql -U umami umami.

Étape 7 — Bloquer les bots et le trafic interne

Umami filtre déjà la majorité des bots connus, mais pas vos propres tests depuis le bureau. Pour exclure votre IP fixe ou celle de l’agence web :

// Dans le snippet, juste avant le tag <script> Umami :
<script>
const skipIps = ['41.214.XX.XX', '154.124.XX.XX']; // IPs fixes Dakar/Abidjan
fetch('https://api.ipify.org?format=json')
  .then(r => r.json())
  .then(d => {
    if (skipIps.includes(d.ip)) {
      window.umami = { track: () => {}, identify: () => {} };
    }
  });
</script>

Variante côté serveur : utilisez la variable d’environnement TRACKER_SCRIPT_NAME pour renommer script.js en quelque chose comme stats.js, ce qui contourne les bloqueurs publicitaires qui filtrent les noms classiques. Redémarrez ensuite avec docker compose up -d et adaptez votre snippet.

Étape 8 — Mettre à jour Umami sans casser les données

Umami publie en moyenne une release mineure par mois. Mettre à jour, c’est docker compose pull puis docker compose up -d. Mais avant chaque update majeure (v2.x → v3 par exemple), faites toujours un dump.

cd ~/umami
/opt/umami-backup/backup.sh
docker compose pull
docker compose up -d
docker compose logs -f umami | head -50

Les logs doivent afficher « Database connection established » et « ready – started server on 0.0.0.0:3000 ». Si vous voyez « migration failed », restaurez le dump et ouvrez une issue sur le repo umami-software/umami avec le log complet. Le rollback prend 5 minutes maximum si la sauvegarde est fraîche.

Pour comparer avec d’autres solutions analytics respectueuses, consultez notre comparatif Plausible vs Umami vs Matomo 2026. Et pour brancher ces données dans un dashboard Grafana, voyez le tutoriel Grafana + Postgres.

Umami Analytics 2026 : guide complet (alternative Plausible et Google Analytics)

Sommaire

Pourquoi Umami en 2026

Concepts fondamentaux

Sites et tracking codes

Sessions, events, pageviews

Custom events

Properties events

Teams et permissions

API et webhooks

Vue d’ensemble pratique

1. Déploiement Coolify ou Docker

2. Premier site et premier tracking

3. Custom events et goals

4. Comparaison Umami vs Plausible

Tutoriels du cluster Umami

Cas d’usage

Agence digitale multi-clients

SaaS B2B

Blog tech francophone

E-commerce mobile-first

Documentation technique

Ajustements pratiques pour Dakar, Abidjan et Bamako

Erreurs fréquentes

FAQ

Sur le même thème

Étape 1 — Choisir son architecture d’hébergement Umami

Étape 2 — Installer Umami avec Docker Compose

Étape 3 — Exposer Umami derrière Caddy avec HTTPS automatique

Étape 4 — Créer un site et installer le tracker

Étape 5 — Mettre en place les événements personnalisés

Étape 6 — Configurer la rétention et les sauvegardes Postgres

Étape 7 — Bloquer les bots et le trafic interne

Étape 8 — Mettre à jour Umami sans casser les données

Sommaire

Pourquoi Umami en 2026

Concepts fondamentaux

Sites et tracking codes

Sessions, events, pageviews

Custom events

Properties events

Teams et permissions

API et webhooks

Vue d’ensemble pratique

1. Déploiement Coolify ou Docker

2. Premier site et premier tracking

3. Custom events et goals

4. Comparaison Umami vs Plausible

Tutoriels du cluster Umami

Cas d’usage

Agence digitale multi-clients

SaaS B2B

Blog tech francophone

E-commerce mobile-first

Documentation technique

Ajustements pratiques pour Dakar, Abidjan et Bamako

Erreurs fréquentes

FAQ

Sur le même thème

Étape 1 — Choisir son architecture d’hébergement Umami

Étape 2 — Installer Umami avec Docker Compose

Étape 3 — Exposer Umami derrière Caddy avec HTTPS automatique

Étape 4 — Créer un site et installer le tracker

Étape 5 — Mettre en place les événements personnalisés

Étape 6 — Configurer la rétention et les sauvegardes Postgres

Étape 7 — Bloquer les bots et le trafic interne

Étape 8 — Mettre à jour Umami sans casser les données

Articles Similaires

Déployer Plausible Analytics sur Hetzner avec Coolify : tutoriel complet 2026

Plausible Analytics 2026 : guide complet (alternative Google Analytics légère et conforme RGPD)

Comprendre pourquoi le storytelling vend mieux que les argum