May 19, 2026

Umami en mode God — analytics self-hosted configuré aux petits oignons

Aujourd’hui on parle analytics. Mais pas n’importe quel analytics — pas le truc de la firme de Mountain View qui aspire vos données comme un Dyson sous stéroïdes. Non. On parle d’Umami, l’outil open source auto-hébergé qui fait tout ce dont vous avez besoin sans vendre votre âme au diable publicitaire.

J’ai passé quelques heures à configurer tout ça sur mes deux sites — sevan.zone et nocarbono.sevan.zone — et le résultat est franchement satisfaisant. Je vous raconte.

C’est quoi Umami déjà ?

Umami, c’est un outil d’analytics web léger, open source, RGPD-friendly, qui se self-host sur votre propre serveur. Pas de cookie de tracking, pas de partage de données vers des tiers, pas de script de 300 ko. Juste un petit bout de JavaScript et une base de données PostgreSQL qui tourne chez vous.

La version 3.x a introduit des fonctionnalités qui commencent vraiment à titiller les ceintures noires de Google Analytics 4. Voyons ce que ça donne quand on pousse la bête dans ses retranchements.

Core Web Vitals — parce que la performance c’est aussi du SEO

Premier truc : activer le tracking des Core Web Vitals. Un seul attribut à ajouter sur la balise script :

<script defer src="https://votre-umami/script.js"
  data-website-id="VOTRE-ID"
  data-performance="true">
</script>

Et voilà — Umami remonte maintenant le LCP, le FCP, le CLS, l’INP et le TTFB pour chaque page. Si vous avez fait du SEO technique dans votre vie, vous savez à quel point ces métriques sont cruciales. Là, vous les avez dans votre propre dashboard, sans passer par la Search Console ou PageSpeed Insights.

Session Replay — voir ce que font vos visiteurs en vrai

Umami 3.x a un enregistreur de sessions. Un deuxième script à charger :

<script defer src="https://votre-umami/recorder.js"
  data-website-id="VOTRE-ID">
</script>

Ça enregistre les mouvements de souris, les clics, les scrolls. Utile pour comprendre pourquoi les gens n’arrivent pas à trouver votre bouton de contact ou pourquoi ils fuient votre page panier comme la peste.

Un détail piégeux : il faut activer l’enregistrement dans les paramètres du site dans Umami. Le script peut charger sans problème mais ne rien enregistrer si l’option n’est pas cochée côté serveur. Je le précise parce que j’ai failli passer à côté.

Goals — le bug qui masquait tout

Ah, les goals. J’avais configuré des objectifs de conversion et j’avais droit à un magnifique “Something went wrong” à chaque fois que j’essayais de les afficher.

Après avoir fouillé dans les entrailles du code compilé de l’app (les joies du Next.js minifié — merci Turbopack), j’ai trouvé le problème : le format de données était incorrect.

Umami attend un goal par rapport — avec un paramètre type qui vaut "path" ou "event" — et non pas un tableau de goals dans un seul rapport. Autrement dit, si vous avez 4 pages à tracker en tant qu’objectifs, vous créez 4 rapports distincts, pas 1 rapport avec un tableau de 4 éléments.

La distinction est subtile, elle n’est documentée nulle part de façon claire, et elle rend les vieux rapports mal formés totalement silencieux côté UI. Suppression, recréation avec le bon format, et là tout s’affiche nickel.

Pour sevan.zone : Projets, Blog, À propos, Jeux. Pour nocarbono : Calculateur Bilan Carbone, Blog, Admin Projets, Boutique.

Funnels — le même bug, bis

Même punition pour les funnels. Chaque étape d’un entonnoir doit avoir type: "path" (pour une URL) ou type: "event" (pour un événement custom). J’avais utilisé type: "url" — valeur logique mais invalide selon le schéma Zod interne.

Le code source des chunks compilés est formel :

steps: z.array(z.object({
  type: z.enum(["path", "event"]),  // pas "url" !
  value: z.string(),
  filters: z.array(...).optional()
})).min(2).max(8)

Les 5 funnels ont été recréés avec le bon type. Ce genre de bug muet est exactement ce qui rend le debugging de Next.js compilé… amusant.

WooCommerce + Revenue Tracking

Pour nocarbono.sevan.zone qui tourne sur WordPress/WooCommerce, j’ai branché le tracking de revenus directement dans un must-use plugin PHP. Quand une commande est confirmée, on envoie l’événement à Umami :

umami.track('revenue', {
  revenue: 29.90,
  currency: 'EUR'
});

Ça alimente le rapport Revenue d’Umami avec les vrais chiffres. Le rapport affiche l’évolution du CA dans le temps, par devise, avec comparaison mois précédent ou année précédente.

Identifier les utilisateurs connectés

Toujours côté WordPress, pour les utilisateurs connectés, on appelle umami.identify() avec le login et le rôle :

umami.identify('nom_utilisateur', { role: 'editor' });

Pratique pour distinguer le trafic admin du trafic visiteur dans les rapports, sans stocker quoi que ce soit de personnel côté Umami.

Segments — les audiences personnalisées

Umami 3.x permet de créer des segments — des filtres réutilisables pour couper vos données selon vos audiences cibles. La syntaxe suit un schéma clair :

{
  "filters": [
    { "name": "device", "operator": "eq", "value": "mobile" }
  ],
  "match": "all"
}

Les champs disponibles : path, referrer, os, browser, device, country, region, city, language, event, utmSource, utmMedium, utmCampaign… et les opérateurs : eq, neq, c (contains), dnc (doesn’t contain), s (starts with), etc.

J’en ai créé 4 par site :

Mobiles — visiteurs sur smartphone
France — trafic français
Trafic organique — UTM medium = organic
Visiteurs page cible — personnes ayant visité la page principale du site (calculateur pour NoCarbono, projets pour Sevan)

UTM, Retention, Journey — les rapports de fond

UTM — pour voir d’où viennent vos visiteurs quand vous faites des campagnes. Les paramètres utm_source, utm_medium, utm_campaign dans vos liens sont agrégés automatiquement.

Retention — la métrique qui dit combien de visiteurs reviennent la semaine suivante, le mois suivant. Indispensable pour savoir si votre contenu crée de l’attachement ou si les gens ne reviennent jamais.

Journey — le chemin de navigation réel de vos visiteurs à travers le site. Différent du funnel : vous ne définissez pas les étapes, Umami les découvre lui-même. Pratique pour repérer des parcours inattendus.

Quelques fonctionnalités bonus qui méritent un paragraphe chacune.

Boards — des tableaux de bord personnalisés pour regrouper vos rapports favoris en un coup d’œil. J’en ai créé 3 : SEO et Acquisition, Conversions, Audience.

Share Links — une URL publique en lecture seule de votre dashboard, à partager avec un client ou un commanditaire sans lui donner accès à l’admin. Pratique pour la transparence.

Links trackés — Umami peut jouer le rôle de raccourcisseur d’URL avec tracking intégré. Vous créez un lien court (/q/mon-slug), vous le partagez sur les réseaux ou dans une newsletter, et Umami comptabilise chaque clic. Utile pour mesurer l’efficacité réelle de vos publications.

Pixels email — une image invisible (1×1 px) à glisser dans vos emails. Quand l’email est ouvert et que les images sont chargées, Umami enregistre l’ouverture. Vieille technique, toujours efficace pour les newsletters :

<img src="https://votre-umami/p/votre-pixel" width="1" height="1">

Conclusion

Au bout du compte, Umami 3.x est une stack analytics sérieuse pour qui veut garder la main sur ses données. Ce n’est pas GA4 — il n’y a pas de modélisation ML ou de cohortes en temps réel — mais pour 95% des besoins d’un créateur de contenu ou d’un indie maker, c’est largement suffisant.

Et surtout : vos données restent chez vous. Dans votre serveur. Dans votre base. Pas dans un datacenter irlandais appartenant à une régie publicitaire.

Le setup complet (Core Web Vitals, session replay, goals, funnels, UTM, retention, journey, segments, revenue, identify, boards, links, pixels) représente une bonne journée de travail si on part de zéro. Mais une fois en place, c’est du feu.

Si vous vous lancez, le seul conseil que je donnerai : lisez le schéma Zod dans les chunks compilés avant de taper vos données à la main via l’API. Vous vous épargnerez quelques “something went wrong” bien énervants.