Umami auto-hébergé : une alternative RGPD à Google Analytics sur Cloudflare et Fly

Début juillet 2026, un fil publié sur r/programming relance l'intérêt pour l'auto-hébergement d'Umami, l'outil d'analytics web open source, en combinant Cloudflare et Fly.io comme socle d'hébergement. Le contenu détaillé de cette discussion n'a pas pu être récupéré au moment de la rédaction : nous nous appuyons donc ici sur la documentation officielle d'Umami, de Fly.io et de Cloudflare, en le signalant clairement.

Le sujet dépasse largement un simple retour d'expérience communautaire. Il touche à une question que beaucoup d'équipes techniques et de PME françaises se posent depuis plusieurs années : comment mesurer l'audience d'un site sans dépendre de Google Analytics, tout en restant à l'aise vis-à-vis du RGPD.

Umami en trois lignes, pour ceux qui découvrent

Umami est un outil d'analytics web open source, pensé comme alternative directe à Google Analytics. Sa promesse : mesurer le trafic (pages vues, référents, appareils, provenance géographique) sans cookies, sans identifiant publicitaire et sans transmettre les données de vos visiteurs à un tiers publicitaire. Le projet propose une version hébergée par l'éditeur (umami.is) ou un auto-hébergement complet, code source à l'appui.

Techniquement, Umami est une application web qui s'appuie sur une base de données relationnelle, PostgreSQL ou MySQL, pour stocker les événements de visite. L'éditeur distribue une image Docker officielle, ce qui rend le déploiement sur à peu près n'importe quelle infrastructure conteneurisée relativement direct, sans avoir à écrire soi-même un Dockerfile.

Pourquoi associer Cloudflare et Fly.io

L'intérêt d'une combinaison Cloudflare plus Fly.io, telle que décrite dans ce type de retour d'expérience, tient à la complémentarité des deux plateformes :

• Fly.io héberge l'application elle-même : le conteneur Umami et, souvent, une instance Postgres managée par Fly, déployée sur des régions proches de vos visiteurs pour limiter la latence.
• Cloudflare intervient en amont, au niveau réseau : proxy DNS, mise en cache des ressources statiques, et éventuellement un tunnel (Cloudflare Tunnel) pour exposer l'application sans ouvrir de port entrant, ou Cloudflare Access pour restreindre l'accès au tableau de bord d'administration aux seules personnes autorisées.

Cette architecture évite de confier l'intégralité de la chaîne à un seul fournisseur, tout en gardant chaque brique remplaçable indépendamment des autres. C'est cohérent avec la philosophie même d'Umami : reprendre la main brique par brique, plutôt que déléguer l'ensemble à un acteur unique.

Comment auto-héberger Umami concrètement

Le point de départ reste le fichier docker-compose.yml fourni par le projet, qui déclare le service Umami et sa base de données :

services:
  umami:
    image: docker.umami.is/umami-software/umami:postgresql-latest
    ports:
      - 3000:3000
    environment:
      DATABASE_URL: postgresql://umami:umami@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: remplacez-moi-par-une-chaine-aleatoire
    depends_on:
      - db
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: umami
    volumes:
      - umami-db-data:/var/lib/postgresql/data
volumes:
  umami-db-data:

Sur Fly.io, le passage d'un conteneur local à une application déployée se fait avec les commandes habituelles du CLI flyctl :

fly launch
fly postgres create
fly secrets set DATABASE_URL='postgresql://...' APP_SECRET='...'
fly deploy

Côté Cloudflare, l'usage le plus courant consiste à pointer votre domaine vers Fly.io en activant le proxy (le fameux nuage orange), à forcer le HTTPS de bout en bout, puis, pour les équipes qui veulent éviter d'exposer directement l'adresse Fly, à faire transiter le trafic par un Cloudflare Tunnel via le démon cloudflared. La protection de l'interface d'administration d'Umami par Cloudflare Access est une option supplémentaire pour les équipes qui veulent restreindre l'accès aux statistiques à une liste d'adresses e-mail précise.

Ce que ça change pour un développeur ou une PME française

Depuis 2022, la CNIL considère que les transferts de données réalisés via Google Analytics vers les États-Unis n'offrent pas de garanties suffisantes au regard du RGPD, une position reprise par plusieurs autres autorités de protection des données en Europe. De nombreux sites ont depuis cherché des alternatives capables de mesurer une audience sans reproduire ce problème de fond.

Umami s'inscrit dans cette recherche : pas de cookies, donc pas de bandeau de consentement nécessaire pour la seule mesure d'audience, et surtout un hébergement que vous choisissez vous-même, en Europe si vous le souhaitez, avec un contrat et une localisation de données que vous maîtrisez de bout en bout.

Pour un développeur indépendant ou une petite équipe, l'auto-hébergement a un coût réel : maintenance de l'instance, mises à jour de sécurité, sauvegarde de la base de données. C'est le compromis classique de tout outil auto-hébergé face à une offre SaaS. La version cloud d'Umami, ou d'autres solutions RGPD-friendly déjà hébergées en Europe, restent des options légitimes pour qui préfère déléguer cette charge opérationnelle.

Notre lecture chez CZSyn

Nous voyons régulièrement des clients nous demander de sortir Google Analytics de leur site, souvent après un audit RGPD ou une remarque de leur DPO. Umami revient systématiquement dans les solutions que nous évaluons, précisément parce que son modèle sans cookies simplifie la conformité au lieu de la complexifier avec des couches de consentement supplémentaires.

L'architecture Cloudflare plus Fly.io décrite dans ce type de retour d'expérience nous semble un bon compromis pour une équipe technique autonome : coût maîtrisé, données hébergées où vous le décidez, et aucune brique propriétaire fermée entre votre site et vos statistiques. Pour une PME sans équipe technique dédiée, en revanche, le temps de maintenance d'une instance auto-hébergée doit être mis en balance avec le confort d'une solution déjà administrée. Dans les deux cas, la bascule hors de Google Analytics est aujourd'hui une question d'arbitrage, plus une question de faisabilité technique.

Sources primaires

• Fil de discussion Reddit r/programming, « Self-hosting Umami analytics on Cloudflare, Fly and... ».
• Documentation officielle Umami, umami.is/docs.
• Documentation officielle Fly.io, fly.io/docs.
• Documentation officielle Cloudflare, developers.cloudflare.com.