L'analyse d'audience est la dernière balise tierce que la plupart des gens conservent, et c'est celle qui voit tout : chaque page, chaque lecteur, chaque heure, sur un système que vous ne possédez pas et ne pouvez pas auditer. Six étapes pour la remplacer par un compteur qui vous appartient — Umami, Plausible Community Edition, Matomo ou rien d'autre que le journal du serveur — tournant sur une machine nordique louée sans pièce d'identité. Sans cookies par défaut, aucun bandeau à négocier, aucun transfert de votre lectorat vers un pays tiers. À partir de $3.90 par mois. Testé sur Debian 12.
Choisir
Quatre outils, une table honnête
Provisionner
Un sous-domaine, trois ports
Déployer
Compose, Caddy, première connexion
Instrumenter
Une balise, et le chemin interne
Se conformer
Deux lois, pas une
Conserver
Conservation, sauvegardes, le journal oublié
Compter les visiteurs est réellement utile, et il n'y a rien de sinistre à vouloir le faire. Vous avez besoin de savoir si la réécriture a aidé, quel article les gens terminent réellement, quel référent envoie des lecteurs plutôt que des rebonds, et si le déploiement de la nuit dernière a discrètement cassé le paiement sur un navigateur. Chacune de ces questions trouve sa réponse dans une table de pages vues, et chacune d'elles est une raison légitime de mesurer.
Ce qui vaut la peine d'être regardé en face, c'est l'arrangement que presque tout le monde a accepté pour obtenir ces réponses. La balise d'analyse standard est un morceau de code, écrit par une entreprise publicitaire, que vous placez sur chaque page de votre site et que vous chargez de faire tourner dans le navigateur de votre lecteur. Elle lit l'adresse de la page, le référent, l'écran, la langue, l'appareil ; elle pose ou lit un identifiant sur l'appareil ; elle envoie tout cela à un système que vous ne pouvez pas inspecter, dans un pays dont vous n'avez pas choisi les règles ; et elle remet le fichier qui en résulte à une entreprise dont les revenus proviennent du fait de savoir ce que font les gens. Le propriétaire du site obtient un tableau de bord. Le tableau de bord est la moitié la plus petite de la transaction.
La facture arrive en quatre versements, et un seul d'entre eux est évident. Il y a le bandeau de consentement, qui existe presque entièrement à cause de cette seule balise, qui vous coûte une part mesurable de visiteurs dès la porte d'entrée, et que vous payez ensuite un second prestataire pour gérer. Il y a la question du transfert, parce que les données de vos lecteurs partent vers un pays tiers et que quelqu'un doit finir par écrire pourquoi cela est licite. Il y a les données elles-mêmes, qui constituent votre lectorat, dans une base de données que vous ne pouvez interroger qu'à travers les rapports qui vous sont proposés. Et il y a la dépendance : le produit est retiré, renommé ou restructuré selon le calendrier de quelqu'un d'autre, et la dernière fois que c'est arrivé, les anciennes mesures ont disparu avec lui.
L'auto-hébergement supprime les quatre à la fois, et ce n'est pas un gros chantier. Le logiciel est mature, gratuit et sans surprise ; la machine coûte quelques dollars par mois ; le travail représente une soirée. Ce que vous récupérez en échange, c'est une table qui vous appartient, sur du matériel dans une juridiction que vous avez choisie, sans tiers à déclarer et — pour la plupart des configurations — sans bandeau à négocier. Quatre façons de savoir combien de personnes lisent votre site, et ce que chacune coûte :
| Propriété | La grande balise d'analyse gratuite | Un SaaS d'analyse axé sur la confidentialité | Le même logiciel, votre VPS |
|---|---|---|---|
| Qui détient la table du lectorat | Une entreprise publicitaire | Un prestataire, sous contrat | Vous, sur disque |
| Bandeau de consentement nécessaire | Oui, en pratique toujours | Généralement non | Généralement non — voir l'étape 05 |
| Les données quittent l'EEE | Oui, par conception | Cela dépend du prestataire | Seulement si vous choisissez une machine hors de l'EEE |
| Tiers à déclarer | Au moins un, plus ses sous-traitants ultérieurs | Un seul sous-traitant | Aucun |
| Bloqué par les listes de filtrage | Fortement | Par nom d'hôte, souvent | Rarement, une fois qu'elle est interne |
| Données brutes à votre disposition | Non — rapports uniquement | Via une API, tant que vous payez | C'est votre base de données |
| Coût mensuel à 100k vues | Rien financièrement | Des dizaines de dollars, croissant avec le trafic | $3.90–$7.90, fixe |
| À choisir quand | Vous avez besoin de l'intégration avec la plateforme publicitaire et acceptez le reste | Vous voulez l'éthique sans rien faire tourner | Le lectorat vous appartient, et la table aussi |
La troisième colonne est une réponse réelle, pas un homme de paille : un prestataire hébergé axé sur la confidentialité élimine la plupart des mêmes problèmes pour les personnes qui ne devraient pas faire tourner de serveurs, et payer un tel prestataire est un meilleur résultat que de garder la balise publicitaire. Ce guide s'adresse au cas où vous louez déjà une machine, ou étiez sur le point de le faire.
Ces quatre outils ne sont pas quatre variantes de la même chose. Ils diffèrent par ce dans quoi ils stockent les données, et ce seul choix détermine l'empreinte mémoire, la croissance du disque, le risque lié aux mises à jour et la profondeur des rapports. Lisez d'abord la colonne du stockage, puis celle des fonctionnalités ; c'est dans cet ordre que la décision se prend réellement.
| Outil | Pile et stockage | Palier raisonnable | À choisir pour |
|---|---|---|---|
| Umami | Application Node + PostgreSQL ou MySQL. Deux conteneurs. | Sentinel · $3.90 | La réponse par défaut. Léger, lisible, sans cookies, multi-site, sous licence MIT. |
| Plausible Community Edition | Application Elixir + PostgreSQL + ClickHouse. Quatre conteneurs. | Garrison · $7.90 | Objectifs, tunnels de conversion et tableaux de bord publics ; requêtes rapides à fort volume. |
| Matomo | Application PHP + MariaDB, plus une tâche d'archivage planifiée. | Garrison · $7.90 | Parité fonctionnelle avec l'outil en place — segments, cohortes, e-commerce, import de journaux. |
| GoAccess | Un seul binaire qui lit le journal d'accès du serveur web. Aucune base de données. | Celui que vous faites déjà tourner | Aucun JavaScript — sites statiques, documentation, API. |
Umami est celui vers lequel se tourner sauf raison contraire. C'est une application Node adossée à une seule base de données relationnelle, elle se contente d'un gigaoctet de mémoire, le schéma se résume à une poignée de tables que vous pouvez interroger vous-même, et les rapports couvrent ce que la plupart des gens ouvrent un tableau de bord pour voir : pages, référents, pays, appareils, plus des événements personnalisés si vous le souhaitez. L'outil est sans cookies par défaut, et il ne vous demande pas de le configurer pour cela.
Plausible Community Edition est la version auto-hébergeable du produit hébergé, et la pièce supplémentaire est ClickHouse — une base orientée colonnes qui rend instantanées les requêtes agrégées sur des dizaines de millions de lignes, et qui consommera autant de mémoire que vous le lui permettrez. C'est un compromis raisonnable au-delà de quelques millions de vues mensuelles, et un choix curieux en dessous. Lisez les termes de la licence du projet avant de déployer : l'édition communautaire est prévue pour faire fonctionner votre propre outil d'analyse, pas pour être revendue sous forme de service.
Matomo est le seul des quatre à remplacer réellement l'outil en place, fonctionnalité par fonctionnalité, et cette franchise joue dans les deux sens : vous obtenez des segments, des tunnels de conversion, des cohortes, une attribution e-commerce, des cartes de chaleur via des extensions et la possibilité d'importer vos propres journaux serveur ; vous obtenez aussi une grosse application PHP dont les tables brutes croissent vite et dont les rapports sont précalculés par une tâche d'archivage que vous devez planifier vous-même. Deux points méritent malgré tout qu'on s'y arrête : l'outil peut être configuré pour ne déposer aucun cookie, et des configurations de mesure d'audience de Matomo ont figuré sur des listes publiées par des régulateurs comme exemptées de consentement — vérifiez la liste en vigueur plutôt qu'un article de blog, mais c'est un avantage réel sur le papier.
GoAccess est l'option que personne ne suggère et que plusieurs devraient pourtant retenir. Il lit le journal d'accès que votre serveur web écrit déjà et le restitue sous forme de rapport terminal ou de page HTML autonome unique. Rien ne s'exécute dans le navigateur, rien n'est stocké sur l'appareil, et il n'y a aucune question de consentement à régler puisqu'il n'y a aucune collecte au-delà de la requête elle-même. Ce que vous perdez, c'est tout ce qui se passe à l'intérieur de la page, ainsi que tout espoir de compter des personnes plutôt que des requêtes. Pour un site de documentation ou un blog statique, c'est souvent un compromis raisonnable — et l'outil se combine bien avec l'un des autres plutôt que de le remplacer.
Si vous ne parvenez pas à nommer la fonctionnalité dont vous avez besoin chez Plausible ou Matomo, c'est Umami qu'il vous faut. Déployez-le en vingt minutes, faites-le tourner un mois, et laissez la question à laquelle vous ne parvenez pas à répondre vous dire s'il faut changer. Migrer plus tard vous coûte l'historique et rien d'autre, et l'historique que vous perdriez ne représente qu'un mois.
Commandez le VPS et choisissez le bastion en fonction de l'endroit où se trouvent vos lecteurs et de l'endroit où vous voulez que les données résident — Stockholm, Helsinki, Oslo et Reykjavík se trouvent tous à l'intérieur de l'EEE, ce qui est précisément le but. Puis lancez la passe de durcissement de la première heure avant que quoi que ce soit d'autre ne touche la machine : SSH par clé uniquement, un port déplacé, un pare-feu en refus par défaut, des mises à jour automatiques. Ce sont les mêmes quarante minutes pour chaque guide de cette série, et ce n'est pas optionnel sur une machine qui va détenir une année du lectorat de quelqu'un.
Réglez ensuite le nom d'hôte, car il est intégré en dur dans l'extrait de suivi sur chaque page de chaque site que vous mesurez, et le changer plus tard signifie éditer tous ces extraits pendant que l'ancien nom continue de recevoir des requêtes. Deux configurations fonctionnent. Un sous-domaine dédié du site que vous mesurez — le proxy inverse sur la machine d'analyse répond pour lui, et c'est la solution la plus simple qui fonctionne. Ou un nom neutre sur un domaine à part, si une seule instance doit servir plusieurs sites sans rapport entre eux et que vous préférez que la source de chaque site ne révèle pas les autres. Créez l'enregistrement et laissez-le se résoudre avant d'aller plus loin : le proxy demande un certificat à une autorité de certification au premier démarrage, et cette autorité vérifie le nom depuis l'extérieur.
dig +short stats.example.com # must return the VPS address before you deploy
ufw default deny incoming
ufw allow 47222/tcp # administrative SSH, moved off 22
ufw allow 80/tcp # ACME challenge and the redirect to 443
ufw allow 443/tcp # the dashboard and the collection endpoint
ufw enable && ufw status numbered
Trois ports, rien de plus. La base de données ne doit pas être publiée : elle vit sur le réseau Docker interne, accessible par le conteneur de l'application et par personne d'autre sur internet. C'est la façon la plus courante dont une machine d'analyse auto-hébergée finit dans un résultat de scan — un port PostgreSQL ou MySQL lié à l'adresse publique parce qu'un fichier Compose tiré d'un tutoriel contenait un mapping de ports qui était là pour le développement local.
Côté dimensionnement, résistez à l'envie de surdimensionner. Un Sentinel — 2 vCPU, 4 GB, 120 GB NVMe, $3.90 par mois — fait tourner Umami plus Postgres avec de la marge, et tiendra des années d'événements pour un site atteignant six chiffres de vues mensuelles. Montez vers un Garrison — 4 vCPU, 8 GB, 240 GB — si vous avez choisi Plausible, parce que ClickHouse y est plus à l'aise, ou Matomo, parce que la tâche d'archivage réclame les cœurs. La bande passante est illimitée sur tous les paliers, et le trafic d'analyse n'y pèse presque rien : chaque requête fait quelques centaines d'octets.
Le déploiement de référence ci-dessous est celui d'Umami, car c'est celui que la plupart des lecteurs devraient faire tourner et parce que la forme se généralise : un conteneur d'application, un conteneur de base de données qu'il peut atteindre et que personne d'autre ne peut atteindre, et un proxy inverse détenant le certificat. Plausible et Matomo diffèrent par le nombre de conteneurs et les noms des variables, pas par la structure — prenez leurs fichiers Compose officiels et appliquez les trois mêmes règles.
Les trois règles, classées par ce qu'elles vous coûteront si vous les ignorez. Épinglez chaque image sur un tag exact, jamais sur un tag flottant : une pile d'analyse qui tire silencieusement une nouvelle version majeure pendant un redémarrage sans rapport est une migration de schéma que vous n'avez pas planifiée. Générez le secret applicatif à partir d'une véritable source aléatoire et conservez-le — il chiffre le matériel de session, et le changer plus tard déconnecte tout le monde dans le meilleur des cas. Ne publiez aucun port de base de données : les deux conteneurs partagent un réseau, et c'est tout le contrôle d'accès dont ils ont besoin.
mkdir -p /srv/analytics && cd /srv/analytics
openssl rand -base64 32 > .app_secret # keep this file; back it up with the database
openssl rand -base64 24 > .db_password
chmod 600 .app_secret .db_password
Le fichier Compose. Deux services, un réseau privé, un volume nommé pour la base de données, et pas un seul port publié — le proxy est la seule chose qui communique avec le monde extérieur :
services:
umami:
image: ghcr.io/umami-software/umami:postgresql-v2.x.y # an exact tag, never :latest
environment:
DATABASE_URL: postgresql://umami:CHANGE_ME@db:5432/umami
APP_SECRET: CHANGE_ME # the openssl output above
depends_on: [db]
restart: unless-stopped
db:
image: postgres:16-alpine
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: CHANGE_ME
volumes:
- umami-db:/var/lib/postgresql/data
restart: unless-stopped
volumes:
umami-db:
Caddy est ici le chemin le plus court vers une configuration TLS correcte : deux lignes de configuration, un certificat obtenu et renouvelé sans tâche cron, et des réglages par défaut modernes que vous n'avez pas à chercher vous-même. Si vous faites déjà tourner nginx sur la machine, gardez nginx — l'exigence est d'avoir un proxy devant, pas ce proxy en particulier. Dans tous les cas, l'application d'analyse ne doit jamais être ce qui écoute directement sur le port 443.
# Caddyfile — Caddy runs as a third service in the same Compose project, so
# "umami" resolves on the internal network. It is the only service that
# publishes ports (80 and 443).
stats.example.com {
encode zstd gzip
reverse_proxy umami:3000
}
Démarrez la pile, puis faites la seule chose qui soit véritablement urgente. docker compose up -d, attendez les migrations, et ouvrez le tableau de bord. Chacun de ces outils embarque soit un compte administrateur par défaut documenté, soit un écran de première inscription ouvert à tous, et le nom d'hôte est devenu de notoriété publique dès l'instant où le certificat a été émis, car les journaux de transparence des certificats sont publics et sont parcourus en continu. Changez le mot de passe par défaut et fermez l'inscription dans les minutes qui suivent le premier chargement réussi, pas demain.
docker compose up -d
docker compose logs -f umami # wait for the schema migration to finish
docker compose ps # both services healthy, no published ports listed
ss -tlnp | grep -E ':(5432|3306)' # must print nothing at all
Umami est livré avec un compte administrateur documenté dont le mot de passe est identique sur chaque installation de la planète. Chez Plausible, le premier visiteur devient propriétaire à moins que l'inscription ne soit désactivée dans l'environnement. Matomo guide le premier visiteur à travers un installateur qui crée le super-utilisateur. Dans les trois cas, la fenêtre entre « le certificat existe » et « vous vous êtes connecté » est une fenêtre pendant laquelle quelqu'un d'autre peut se connecter à votre place — et il n'a pas besoin de deviner le nom d'hôte, car celui-ci est publié pour lui. Connectez-vous en premier, changez l'identifiant, puis basculez l'inscription sur fermé et rechargez la page pour confirmer que cela a été pris en compte.
Enregistrez le site dans le tableau de bord, copiez l'identifiant qu'il vous donne, et placez une balise de script différée dans le modèle — dans le head ou à la fin du body, cela importe peu, mais différée dans tous les cas afin qu'elle ne puisse jamais retarder la page. C'est toute l'intégration. Il n'y a ni gestionnaire de balises, ni conteneur, ni couche de données, ni câblage de mode de consentement, et cette absence est l'essentiel de ce que vous étiez venu chercher.
<script defer src="https://stats.example.com/script.js"
data-website-id="00000000-0000-0000-0000-000000000000"></script>
Chargez une page du site, puis regardez le tableau de bord : la requête devrait y apparaître en quelques secondes. Si ce n'est pas le cas, la console du navigateur et l'onglet réseau répondent à la question en moins d'une minute — les deux modes de défaillance sont un identifiant mal saisi, qui produit une requête acceptée puis rejetée, et une requête qui ne part jamais du tout, ce qui signifie qu'une extension l'a bloquée. Excluez votre propre trafic avant de commencer à lire les chiffres, sans quoi vos propres rechargements de page seront votre premier référent pendant une semaine.
Vient maintenant la décision qui mérite réflexion. L'extrait ci-dessus effectue une requête vers un nom d'hôte qui n'est pas celui du site, et une partie de vos visiteurs font tourner des logiciels qui bloquent ce type de requête par motif. Les listes repèrent les noms de fichiers bien connus — tout ce qui se termine par le nom de script propre à l'éditeur — ainsi que les domaines hébergés bien connus, quel que soit le serveur vers lequel ils pointent. La correction comporte deux volets : renommer le fichier de script et le point de terminaison de collecte avec un nom qui ne ressemble pas à celui d'un traceur, ce que chacun de ces outils permet, et les servir depuis l'origine propre du site via un chemin que votre proxy existant relaie. Il ne reste alors plus aucune requête tierce à bloquer.
# On the site's own web server — the two paths the tracker needs, first-party:
example.com {
handle /p/s.js { reverse_proxy https://stats.example.com { header_up Host stats.example.com } }
handle /p/collect { reverse_proxy https://stats.example.com { header_up Host stats.example.com } }
# ... the rest of the site
}
Deux détails font que cela fonctionne pleinement plutôt qu'à moitié. Le proxy doit transmettre l'adresse du visiteur dans un en-tête que l'application d'analyse est configurée pour reconnaître comme fiable, sans quoi chaque requête sera attribuée à votre propre serveur web et le rapport par pays ne sera plus qu'une seule barre. Et il faut indiquer au traceur où envoyer ses données, ce qui se fait via un attribut de données sur la balise de script dans les trois outils — renommer le fichier sans repointer le point de terminaison vous donne un script qui se charge et ne rapporte nulle part.
C'est aussi la fin honnête de l'histoire de la mesure. Un visiteur qui a désactivé JavaScript, ou qui fait tourner une liste stricte assortie d'une règle cosmétique visant le suivi interne, ne sera pas compté, et aucune quantité d'ingénierie ne devrait être dépensée à le pourchasser — un filtre au niveau du réseau est une préférence exprimée, et la réponse polie est le journal serveur, qui les compte sans rien collecter de plus. Les événements et les applications monopages constituent l'autre moitié de l'instrumentation : chaque outil expose une petite fonction pour les événements personnalisés, et chacun d'entre eux a besoin d'un appel explicite au changement de route, car un framework qui remplace la vue sans navigation ne produit aucun chargement de page que le script puisse remarquer.
La raison pour laquelle les gens ne parviennent pas à s'accorder sur la nécessité d'un bandeau pour l'analyse d'audience, c'est qu'ils débattent en réalité de deux règles différentes comme s'il s'agissait d'une seule. Séparez-les, et la réponse devient gérable. L'article 5(3) de la directive ePrivacy — transposé en droit national dans chaque État membre, et véritable source du bandeau de cookies — dispose que le stockage d'informations sur l'équipement terminal d'un abonné, ou l'accès à des informations déjà stockées sur celui-ci, requiert son consentement, sauf si cela est strictement nécessaire à la fourniture d'un service qu'il a explicitement demandé. Notez ce qu'il ne dit pas : il ne dit pas cookie, et il ne dit pas donnée personnelle. Il vise localStorage, il vise le fingerprinting d'appareil, et il s'applique même à une valeur qui n'identifie personne.
Le RGPD est la seconde règle et régit une question différente : ce que vous pouvez faire des données personnelles une fois que vous les détenez. Il s'applique à votre outil d'analyse que vous stockiez ou non quoi que ce soit sur l'appareil, car une requête web livre une adresse IP, et la Cour de justice a tranché dans l'arrêt Breyer (C-582/14) qu'une adresse IP peut constituer une donnée personnelle entre les mains d'un opérateur de site web. Les deux règles s'empilent donc : le 5(3) demande avez-vous écrit sur l'appareil, le RGPD demande qu'avez-vous fait de ce qui est arrivé.
Un serveur d'analyse sans cookies est construit pour répondre aux deux, mais étroitement. Il ne stocke rien sur l'appareil — aucun cookie, aucune entrée localStorage, aucun identifiant d'aucune sorte — ce qui écarte le 5(3), puisqu'il n'y a ni stockage ni accès à un stockage. Et il prend l'adresse IP qu'il reçoit forcément, la combine avec l'user agent, le site et un sel secret renouvelé chaque jour, hache le résultat, conserve le hachage et jette l'adresse. Ce hachage permet à l'outil de distinguer deux visiteurs au sein d'une même journée, et cesse d'être utile dès que le sel change, ce qui explique précisément pourquoi la même personne compte comme un nouveau visiteur le lendemain. Le traitement est réel, et il est à peu près aussi minimal qu'un traitement puisse l'être.
Ce qui reste, c'est une base légale pour cette opération étroite, et en pratique les opérateurs s'appuient sur l'intérêt légitime au titre de l'article 6(1)(f), documenté par une analyse de mise en balance qui reste courte parce que les faits sont simples : aucun profilage, aucun partage, aucun suivi inter-sites, un pseudonyme qui meurt chaque jour, une durée de conservation définie. Plusieurs autorités de contrôle sont allées plus loin et ont publié des critères selon lesquels une mesure d'audience strictement limitée est totalement exemptée de consentement — les critères varient selon le pays, ils sont mis à jour, et celui qui compte pour vous est le vôtre. Ceci n'est pas un conseil juridique. C'est la carte des instruments qui s'appliquent, afin que le conseil que vous suivez puisse porter sur votre situation plutôt que sur la forme générale du problème.
| La question | Balise d'analyse ad-tech | Sans cookies, auto-hébergé dans l'EEE |
|---|---|---|
| Écrit sur l'appareil du visiteur ? | Oui — le consentement de l'article 5(3) s'applique donc | Non — le 5(3) n'est pas déclenché |
| Identifiant persistant conservé ? | Des mois à des années, tous sites confondus | Un hachage salé qui expire chaque jour |
| Transfert vers un pays tiers à documenter ? | Oui, avec un mécanisme de transfert à maintenir | Aucun — la machine se trouve dans l'EEE |
| Sous-traitants à nommer et sous contrat | Le prestataire et ses sous-traitants ultérieurs | Votre hébergeur, pour le matériel, et personne d'autre |
| Qui peut répondre à une demande d'accès | Vous, via l'export disponible | Vous, avec SQL — et souvent il n'y a rien à renvoyer |
Une ligne supplémentaire mérite de figurer dans le dossier, car c'est l'argument discret en faveur de toute cette démarche. La légalité de l'envoi des données des visiteurs européens vers un service d'analyse américain fait l'objet de contentieux depuis une décennie : la Cour de justice a invalidé le cadre de transfert précédent dans l'arrêt Schrems II (C-311/18) en 2020, plusieurs autorités de contrôle nationales ont statué contre la balise d'analyse standard sur cette base en 2022 — l'Autriche en janvier, la France en février, l'Italie en juin, d'autres suivant ensuite — et une nouvelle décision d'adéquation, le Data Privacy Framework UE-États-Unis, a rétabli une voie de transfert en juillet 2023 et fait elle-même l'objet d'un recours. Vous n'avez pas besoin d'avoir un avis sur la façon dont cela se terminera. Une machine à Helsinki retire définitivement la question de votre dossier, et cela vaut plus que d'avoir raison sur l'état actuel de la situation.
Définissez la durée de conservation dès le premier jour, tant qu'elle reste un chiffre abstrait plutôt qu'une année de données à laquelle vous vous êtes attaché. Chacun de ces outils peut supprimer les événements bruts selon un calendrier tout en conservant les synthèses agrégées ; douze mois de détail est généreux pour presque tout usage, et cela signifie que la réponse honnête à « combien de temps conservez-vous cela » est un chiffre plutôt que « indéfiniment ». Cela résout aussi le problème de disque avant qu'il ne commence, ce qui compte surtout pour Matomo, dont les tables brutes sont celles qui grossissent.
Sauvegardez la base de données ailleurs que sur cette machine et chiffrez-la à la sortie — le guide des sauvegardes traite le sujet en détail, et la version courte consiste en un export nocturne redirigé vers un dépôt en ajout seul sur une seconde machine, idéalement dans une seconde juridiction. Sauvegardez le secret applicatif à côté : une base de données que vous pouvez restaurer et un secret que vous ne pouvez pas restaurer forment un tableau de bord sur lequel personne ne peut se connecter. Puis restaurez-la une fois, sur un VPS de test, délibérément, avant d'en avoir besoin.
docker compose exec -T db pg_dump -U umami umami | zstd -q -o /srv/backup/umami-$(date -u +%F).sql.zst
restic -r sftp:backup@bastion-2:/srv/repo backup /srv/backup /srv/analytics/.app_secret
restic -r sftp:backup@bastion-2:/srv/repo forget --keep-daily 7 --keep-weekly 8 --prune
Les mises à jour méritent un peu plus de soin qu'une simple montée de version de conteneur ordinaire, car ces applications possèdent un schéma. Lisez les notes de version des versions majeures que vous franchissez, prenez la sauvegarde avant plutôt qu'après, puis changez le tag épinglé et redémarrez la pile en surveillant les journaux — une migration qui échoue à mi-chemin reste réparable grâce à l'export de la nuit précédente, et devient très désagréable sans lui. Il n'y a aucune raison d'être sur la toute dernière version la semaine où elle paraît, et une bonne raison de ne pas l'être.
Vous venez de déployer une pile qui, délibérément, ne stocke jamais d'adresse IP. À deux mètres de là, votre proxy inverse écrit l'adresse IP complète de chaque visiteur dans un journal d'accès, en clair, et la conserve aussi longtemps que le dit la rotation par défaut — à la fois sur la machine d'analyse et sur le serveur web placé devant votre site réel. Ce journal est un ensemble de données plus vaste et plus sensible que la base de données d'analyse, c'est un traitement dont vous devez rendre compte, et presque personne ne s'en souvient. Décidez à quoi il sert : si c'est uniquement pour le débogage, tronquez ou masquez le dernier octet dans le format du journal et appliquez une rotation agressive ; si vous le voulez pour une mesure fondée sur les journaux, dites-le dans la politique et donnez-lui une durée de conservation réelle. Ce que vous ne devez pas faire, c'est le laisser à sa configuration par défaut tout en décrivant votre site comme ne collectant pas d'adresses IP.
Enfin, les limites qu'il vaut mieux reconnaître honnêtement, car un compteur auto-hébergé n'est pas une version strictement meilleure de ce que vous avez retiré. Vous perdez l'identité inter-appareils et inter-jours, si bien que visiteur qui revient signifie quelque chose de plus restreint qu'avant. Vous perdez l'intégration avec les plateformes publicitaires, ce qui compte si vous achetez du trafic et n'a aucune importance sinon — les données de la Search Console sont un produit séparé et ne sont pas affectées. Vous héritez d'une mise à jour et d'une sauvegarde à gérer, ce qui représente un coût récurrent réel mesuré en soirées passées. Et la machine elle-même devient quelque chose qui mérite d'être protégé : elle détient votre lectorat, elle se trouve sur l'internet public, et la liste de durcissement ainsi qu'une route privée vers le tableau de bord sont les deux choses qui la maintiennent sans histoires.
L'un de ces outils livre le même identifiant administrateur sur chaque installation de la planète ; les autres accordent la propriété du compte à quiconque s'inscrit le premier. Le nom d'hôte est publié dans les journaux de transparence des certificats dès que TLS fonctionne. Connectez-vous, changez-le, fermez l'inscription — dans les cinq premières minutes, pas demain.
Les fichiers Compose écrits pour un ordinateur portable publient le port 5432 ou 3306 pour que leur auteur puisse s'y connecter depuis une interface graphique. Copiez-en un sur une machine publique et la table du lectorat n'est plus qu'à un mot de passe deviné. Le conteneur de l'application atteint la base de données via le réseau interne ; rien n'a besoin d'être publié à part le proxy.
Déplacer le logiciel sur votre propre machine répond à la question du transfert et à celle du sous-traitant. Cela ne répond pas à l'article 5(3) si vous activez ensuite une fonctionnalité qui écrit sur l'appareil, et cela n'écrit pas votre politique de confidentialité à votre place. L'exemption est une propriété de la configuration, pas de l'hébergement.
Un proxy inverse qui ne transmet pas l'adresse du client fait ressembler chaque requête à une requête venant du proxy lui-même. Le tableau de bord se remplit, les totaux semblent corrects, et les colonnes de géographie et d'unicité sont discrètement fictives. Vérifiez la répartition par pays dès le premier jour, pas lors du bilan trimestriel.
La pile a été choisie parce qu'elle ne stocke jamais d'adresse IP. Le proxy placé devant elle les stocke en clair par défaut, tout comme le serveur web placé devant votre site. Masquez-les ou mettez-les en rotation délibérément, et décrivez-les dans la politique — ou arrêtez de prétendre que vous ne les collectez pas.
Les nouveaux totaux ne correspondront pas aux anciens, et aucune configuration ne les fera correspondre. Des règles de comptage différentes, une part bloquée différente, et aucun bandeau ne filtrant l'échantillon. Consacrez la quinzaine à apprendre votre propre ratio, puis traitez le nouveau chiffre comme la référence et arrêtez de vouloir faire coïncider deux définitions.
Onze questions qui reviennent en le faisant — à commencer par celle que tout le monde comprend mal, dans les deux sens.
Souvent oui, et la raison est plus précise que « l'auto-hébergement suffit ». Deux règles distinctes entrent en jeu. L'article 5(3) de la directive ePrivacy — celle que tout le monde appelle la loi cookies — exige un consentement pour stocker des informations sur l'appareil d'un visiteur, ou pour en lire, à moins que cela soit strictement nécessaire à un service que ce visiteur a demandé. Elle s'applique aux cookies, mais aussi à localStorage, à sessionStorage et à tout ce que vous laissez derrière vous, et elle s'applique que la donnée soit personnelle ou non. Un outil qui n'écrit rien sur l'appareil ne la déclenche simplement pas. Le RGPD est la seconde règle et il ne disparaît pas pour autant : vous recevez tout de même une adresse IP et une chaîne user agent à chaque requête, et une adresse IP est une donnée personnelle entre les mains d'un opérateur de site web (Cour de justice, Breyer, C-582/14). Ce que fait un serveur d'analyse sans cookies, c'est hacher cette IP avec un sel renouvelé chaque jour puis la jeter, si bien que ce qui atterrit dans la base de données est un pseudonyme par jour et par site plutôt qu'une personne. C'est un traitement étroit et bien documenté, sur lequel la plupart des opérateurs s'appuient au titre de l'intérêt légitime, et plusieurs autorités de contrôle ont publié des critères selon lesquels la mesure d'audience pure est exemptée de consentement. C'est une position défendable, pas une formule magique : notez ce que vous collectez, pourquoi, et pendant combien de temps, et lisez les recommandations de votre propre régulateur plutôt que la page d'accueil d'un fournisseur. Rien sur cette page ne constitue un conseil juridique.
Umami. C'est une application Node unique et une base de données PostgreSQL, elle est à l'aise sous 1 GB de mémoire, le tableau de bord est lisible dès la première visite, elle est sans cookies dès l'installation, et une seule instance sert avec bonheur tous les sites que vous possédez. Pour l'immense majorité des personnes qui remplacent Google Analytics sur un blog, un site de documentation, une boutique ou un site d'entreprise, c'est la bonne réponse, et les trois autres sont un débat que vous n'aviez pas besoin d'avoir. Choisissez plutôt Plausible Community Edition si vous voulez des tunnels de conversion, des objectifs de revenus et une meilleure histoire de tableau de bord public, et que vous êtes prêt à faire tourner ClickHouse pour cela. Choisissez Matomo si vous avez véritablement besoin de l'ensemble de fonctionnalités de Google Analytics — segments, cohortes, rapports personnalisés, attribution e-commerce, import de journaux bruts — et que vous acceptez de faire tourner une grosse application PHP avec une tâche d'archivage planifiée. Choisissez GoAccess si vous ne voulez aucun JavaScript sur la page.
Parce qu'ils comptent des choses différentes, et l'écart joue dans les deux sens à la fois. Vers le haut : Google Analytics derrière un bandeau de consentement ne voit jamais que les visiteurs ayant cliqué sur accepter, ce qui en Europe représente régulièrement la moitié d'entre eux, tandis qu'un compteur sans cookies et sans bandeau les voit tous. Vers le haut encore : votre nouveau point de terminaison se trouve sur votre propre domaine et ne figure pas sur les listes de filtrage qui rejettent les requêtes vers les traceurs bien connus. Vers le bas : un hachage qui change chaque jour ne peut pas reconnaître la même personne le lendemain, si bien qu'un lecteur qui visite le site lundi puis jeudi compte comme deux visiteurs, pas comme un visiteur qui revient — les sessions sont recomposées au sein d'une même journée, jamais entre plusieurs jours ou plusieurs appareils. Vers le bas encore : la plupart des outils auto-hébergés embarquent un filtre anti-robots prudent et aucune inflation façon Discover. Le conseil pratique est d'arrêter de vouloir faire coïncider les deux. Faites tourner les deux pendant deux semaines pour apprendre votre propre ratio, notez-le sur un post-it, puis supprimez la balise Google et utilisez les nouveaux chiffres comme la référence qu'ils sont devenus. Ce qui compte pour les décisions, c'est la forme de la tendance et le classement relatif des pages et des sources, et les deux survivent intacts au changement.
Partiellement, et cela vaut la peine de savoir exactement comment, car le mécanisme est plus simpliste qu'on ne le croit. Les grandes listes de filtrage fonctionnent par motifs : les noms d'hôte des services hébergés, et un ensemble de noms de fichiers et de chemins bien connus — une requête vers quelque chose se terminant par plausible.js, umami.js ou matomo.php est reconnaissable quel que soit le serveur vers lequel elle va. Déplacez le logiciel vers stats.example.com en gardant les noms de fichiers d'origine, et vous perdrez quand même une tranche du public technophile. Il existe deux corrections honnêtes, et elles se combinent. Renommez le script et le point de terminaison de collecte avec un nom qui ne ressemble pas à celui d'un traceur — chacun de ces outils vous le permet, et cela ne coûte qu'une ligne de configuration. Servez-les depuis la même origine que le site lui-même, via un chemin sur votre domaine principal que le proxy inverse relaie, si bien qu'il ne reste aucune requête tierce à bloquer. Ensemble, ces deux mesures récupèrent la majeure partie de la perte. Vous ne récupérerez pas tout, et vous ne devriez pas le vouloir : un visiteur qui fait tourner une liste stricte et qui a désactivé JavaScript a fait un choix, et la réponse appropriée à cela est le journal serveur, pas une course aux armements.
La question est légitime, et la réponse dépend de ce que le bloqueur protégeait. Une liste de filtrage dispose d'un seul outil, grossier, pour deux cibles très différentes : le réseau publicitaire qui suit une personne à travers dix mille sites et construit un profil, et le compteur qui indique à un seul propriétaire de site que sa page de documentation a été lue quatre cents fois hier. Bloquer le premier, c'est une personne qui se défend contre la surveillance. Bloquer le second est un dommage collatéral d'une règle incapable de faire la différence. Servir votre propre compteur depuis votre propre domaine ne consiste pas à faire passer un traceur en contrebande devant une défense ; cela consiste à supprimer une requête tierce qui n'aurait jamais dû exister, et la même visite génère de toute façon une ligne dans votre journal d'accès. Là où cela cesse d'être défendable, c'est au moment où ce que vous faites transiter par proxy n'est plus ce qui est décrit ici — si vous ajoutez des identifiants inter-sites, du fingerprinting, ou un acheminement vers une plateforme publicitaire, le bloqueur avait raison et le proxy est un mensonge. Le test est simple et vaut la peine d'être appliqué à vous-même une fois : pourriez-vous publier une page décrivant exactement ce que ce point de terminaison collecte, et un lecteur hausserait-il les épaules ? Si oui, faites-le transiter par proxy. Si non, le problème n'est pas le proxy.
Plus petit que ce que vous craignez, à une exception près. Umami est un processus Node et une base de données Postgres : il se stabilise sous 1 GB de mémoire pour un site normal, et la base de données croît d'à peu près la taille d'une ligne de texte par page vue, si bien qu'un Sentinel — 2 vCPU, 4 GB, 120 GB NVMe, $3.90 par mois — dispose d'années de marge. GoAccess ne pèse presque rien. Matomo se situe entre les deux : PHP et MariaDB sont peu exigeants tant que la tâche d'archivage ne tourne pas, ce qui constitue le pic de CPU à prévoir, et ses tables brutes croissent plus vite que les autres car il conserve davantage par requête. L'exception est Plausible Community Edition, et la raison en est ClickHouse plutôt que Plausible lui-même : une base orientée colonnes est conçue pour échanger de la mémoire contre de la vitesse de requête, et elle se servira de tout ce que vous laisserez à sa portée. Elle fonctionne avec 4 GB si vous plafonnez ses caches dans la configuration fournie, et elle est à l'aise à 8 GB — ce qui explique pourquoi le palier Garrison à $7.90 en constitue le plancher raisonnable. Dans tous les cas, le chiffre qui finit par imposer une mise à niveau est le disque, pas la mémoire, et l'étape 06 explique comment l'éviter.
Oui, et c'est la façon normale de les faire tourner. Les trois outils JavaScript sont tous multi-sites par conception : vous enregistrez chaque domaine dans le tableau de bord, chacun reçoit son propre identifiant, et le même point de terminaison de script accepte les requêtes de tous tout en conservant des rapports séparés. Une machine, un certificat, une sauvegarde, une mise à jour — vingt sites. Deux points à garder en tête à mesure que la liste s'allonge. Les rapports sont séparés par site, donc si vous administrez des sites pour des clients, utilisez les permissions d'utilisateurs et d'équipes propres à l'outil plutôt que de distribuer le compte administrateur à tout le monde, et vérifiez ce qu'implique une instance partagée avant de l'accepter dans un contrat : vous devenez la partie qui détient les données des visiteurs de vos clients. Et le point de terminaison de suivi porte un nom partagé, ce qui signifie que le domaine qui le sert apparaît dans le code source de chaque site de la liste — un fait qui vaut la peine d'être mentionné à un client dont les concurrents lisent le code source des pages, et un argument en faveur du chemin interne de l'étape 04.
Pour une large catégorie de sites, le journal suffit, et c'est la mesure la plus honnête qui existe : elle ne collecte rien de plus, car les lignes existent déjà. GoAccess lit un journal d'accès de serveur web et produit un rapport terminal ou un tableau de bord HTML autonome — pages les plus vues, référents, codes de statut, bande passante, temps de réponse, user agents — pour un site statique, un ensemble de documentation ou une API, c'est l'essentiel de ce qu'une balise de script allait vous apprendre. Deux limites décident si cela vous suffit. Un journal ne peut pas voir ce qui se passe à l'intérieur de la page : pas de profondeur de défilement, pas de clics sur des liens sortants, pas d'événements de bouton, pas de changements de route dans une application monopage, car rien de tout cela ne touche le serveur. Et un journal compte des requêtes plutôt que des personnes, si bien que vous êtes à la merci de la mise en cache et d'une population de robots qui constitue désormais la majorité du trafic brut — le filtrage est une tâche de maintenance permanente plutôt qu'une étape de configuration. Il existe aussi un piège de confidentialité dans le sens opposé à celui que vous attendez, et l'étape 06 le traite : le journal que vous analysez contient des adresses IP complètes, ce qui représente plus de données personnelles que ce que conservait l'outil JavaScript que vous avez rejeté.
En réalité, non, et il vaut mieux organiser les choses autour de ce fait plutôt que de le combattre. Matomo est le seul des quatre à offrir une véritable histoire d'import, et même là, les voies pratiques consistent à importer vos propres journaux de serveur web et à utiliser l'outillage de migration prévu pour les anciennes instances Matomo, plutôt qu'un transfert propre des rapports déjà traités par Google. Umami et Plausible Community Edition peuvent accepter un chargement en masse via leurs API si vous êtes prêt à écrire le mappage, mais vous inventeriez alors des sessions et des visiteurs à partir d'exports agrégés, et le résultat est un graphique qui paraît continu sans être comparable de part et d'autre de la jointure. Ce qui fonctionne réellement : exportez depuis Google, avant que la propriété ne disparaisse, les rapports qui vous importent — les totaux mensuels, les pages les plus vues, les sources principales, les nombres de conversions — au format CSV, conservez-les au même endroit que vos autres archives, et démarrez le nouvel outil avec une base de référence toute neuve à une date que vous notez. Vous consulterez l'ancien export deux fois dans la première année et plus jamais ensuite, et chaque chiffre qu'il contient a de toute façon été mesuré sous une définition différente.
Moins que vous ne le pensez, et cette brièveté est précisément le but — un paragraphe que vous pouvez défendre vaut mieux qu'une page que vous avez copiée. Dites ce qu'est l'outil et que vous le faites tourner vous-même ; nommez l'emplacement du serveur et son opérateur légal, car pouvoir dire « sur une machine que nous louons en Finlande » est tout l'intérêt de la démarche. Dites ce qui est enregistré à chaque visite : la page, le référent, le pays, l'appareil et la famille de navigateur, et un identifiant pseudonyme dérivé de l'adresse IP et de l'user agent avec un sel qui change chaque jour, à partir duquel l'IP d'origine ne peut pas être retrouvée. Dites ce qui n'est pas enregistré : aucun cookie, aucun identifiant inter-sites, aucun profil, aucune donnée vendue ou partagée. Indiquez la base légale sur laquelle vous vous appuyez et la durée de conservation, et assurez-vous que le chiffre que vous écrivez est bien celui avec lequel l'outil est configuré. Si votre proxy inverse conserve des journaux d'accès, il s'agit d'un traitement distinct avec sa propre durée de conservation — mentionnez-le, car c'est celui que l'on oublie. Puis maintenez le paragraphe synchronisé avec la configuration : une politique qui décrit l'installation que vous aviez il y a deux ans est pire qu'une politique vague.
Parce que « seulement des pages vues » sous-estime ce qu'est une base de données d'analyse. Agrégée sur une année, c'est le lectorat de votre site : quelles pages, dans quel ordre, depuis quels pays, à quelles heures, en provenance de quels liens — et pour un petit éditeur ou une boutique de niche, c'est un plan d'affaires et une liste de sources réunis dans une seule table. C'est aussi, sur le plan juridictionnel, exactement le genre de donnée qu'un adversaire demande à un prestataire plutôt qu'à vous directement. Deux propriétés en découlent. L'emplacement de la machine décide quelle procédure légale peut l'atteindre : une machine à Stockholm, Helsinki, Oslo ou Reykjavík se trouve à l'intérieur de l'EEE, ce qui retire entièrement la question du transfert international de votre dossier de conformité, et à l'intérieur de quatre régimes constitutionnels aux fortes traditions de liberté de la presse. Et le nom associé au compte décide ce que le compte lui-même révèle : chez NordBastion, il n'y a ni pièce d'identité, ni nom légal, ni carte bancaire, la facture se règle en Monero ou en Bitcoin, et la machine qui héberge votre lectorat n'est pas une ligne dans une base de données clients quelque part avec votre passeport accroché à elle. Le guide des juridictions détaille le plancher légal de chacune des quatre.
Sentinel — 2 vCPU, 4 GB et 120 GB de NVMe pour $3.90 par mois, à Helsinki, Stockholm, Oslo ou Reykjavík — fait tourner Umami et sa base de données avec de la marge pour des années d'événements. Montez vers Garrison à $7.90 si vous avez choisi Plausible ou Matomo. Aucun e-mail à l'inscription, aucune pièce d'identité, aucune carte, et aucun tiers ne détenant la liste de tous ceux qui ont un jour lu votre site.
Dernière révision · 2026-10-12 · Références · Documentation d'Umami, de Plausible Community Edition, de Matomo et de GoAccess ; directive ePrivacy 2002/58/EC, article 5(3) ; règlement (UE) 2016/679 ; arrêts de la Cour de justice Breyer (C-582/14) et Schrems II (C-311/18) ; décision d'adéquation Data Privacy Framework UE-États-Unis de juillet 2023 · Fréquence · annuellement
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Bitwarden-compatible password vault under your own control.
Files, calendar, contacts, photos — owned, not rented.
Postfix, Dovecot, SPF/DKIM/DMARC — deliverability included.
A meta search engine that does not log you — because you own it.
Hébergement privé, conçu dans le Nord.