Maîtrisez vos données analytiques : auto-hébergé vs SaaS privé UE en 2026

L’analyse web auto-hébergée en 2026 : un repositionnement, pas une niche

Pendant la majeure partie de la décennie écoulée, « analyse web auto-hébergée » était une position que l’on prenait pour des raisons idéologiques — un étendard Plausible-ou-Matomo planté face au défaut GA4. En 2026, c’est autre chose : le Data Act de la Commission européenne (applicable depuis le 12 septembre 2025) interdit explicitement le verrouillage par des formats de stockage propriétaires chez les éditeurs SaaS, et l’on observe un exode SaaS documenté et citable d’entreprises européennes qui rapatrient leurs charges de travail depuis des plateformes cloud sous contrôle américain — « des fabricants du Mittelstand allemand, des agences gouvernementales françaises, des prestataires de santé néerlandais », selon MassiveGRID. Les observateurs du secteur décrivent désormais la souveraineté des données comme « une réponse pragmatique à la pression réglementaire, à la réalité politique et à la reconnaissance croissante que la souveraineté des données n’est pas optionnelle. »

Statnive Live se décline en deux formes : un binaire Go auto-hébergé que vous faites tourner vous-même, et un SaaS privé UE à Nuremberg. Cet article est la version honnête de la question que tout opérateur soucieux de la vie privée doit maintenant trancher : laquelle me convient réellement ? Chaque affirmation réglementaire ou produit de cet article est accompagnée d’une source en note de bas de page — et lorsque le compromis est réel, il est nommé.

Ceci est l’article 3 d’une courte série de présentation de Statnive Live. L’article 1 a traité de la décision plugin WordPress vs Statnive Live ; l’article 2 a couvert le cadre réglementaire UE en 2026. Celui-ci porte sur la forme de déploiement — responsable du traitement vs sous-traitant, rayon de blast, et modèle de menace de chaque côté.

Ce que l’auto-hébergement protège réellement

L’auto-hébergement réduit cinq menaces SaaS courantes à un seul serveur que vous gérez déjà :

Le fournisseur qui fait faillite, pivote ou change arbitrairement ses tarifs. SmartSaaS et Sharp Hue le présentent comme le risque SaaS canonique : si votre stack d’analyse web vit sur les serveurs d’un tiers, vos données historiques vivent sur sa feuille de route.
Le rachat du fournisseur. Les nouveaux propriétaires peuvent modifier la posture de confidentialité, augmenter le prix ou forcer une migration. J. Chang Law suit le volet contractuel de ces litiges.
L’exposition aux failles du fournisseur. Quand les données des visiteurs résident dans un SaaS multi-locataire, toute faille chez le fournisseur est une faille de vos données (cadrage Kiteworks). L’auto-hébergement limite le rayon de blast à votre propre serveur.
Le risque de transfert transfrontalier. Un hébergement hors de l’EEE déclenche le chapitre V du RGPD (articles 44–49). La réponse la plus propre est de rester dans l’EEE — voir l’article 2 de cette série pour l’argumentation réglementaire.
La divulgation forcée par le régulateur. Le CLOUD Act américain + la FISA 702 couvrent toute donnée contrôlée par un fournisseur incorporé aux États-Unis, quelle que soit leur localisation physique. Comme Civo le souligne : « Stocker vos données à Francfort ou à Dublin ne les met pas hors de portée du droit américain. Si le fournisseur est une société américaine, les autorités américaines peuvent contraindre l’accès à toutes les données que cette société contrôle, où qu’elles soient stockées. » La FISA 702 devait expirer en avril 2026 avec une pression de renouvellement déjà en cours au moment où nous écrivons — le périmètre post-renouvellement dira si la situation évolue ; la réponse architecturale n’en dépend pas.

Un binaire auto-hébergé sur une infrastructure contrôlée par l’opérateur, exploitée par une entité juridique non américaine, réduit les cinq menaces à un seul problème que l’opérateur gère déjà — son propre serveur.

Ce que l’auto-hébergement ne protège pas

La liste complémentaire honnête. L’auto-hébergement déplace le risque ; il ne le supprime pas. Quatre problèmes restent les vôtres :

La compromission de votre propre serveur. OS hôte, ClickHouse, le binaire Go, le réseau — tout cela se retrouve dans votre rayon de blast. Si votre posture d’administration système est fragile, l’auto-hébergement peut aggraver les choses, pas les améliorer. Le cadrage Slimstat / TeamUpdraft de l’auto-hébergé comme charge serveur est le même compromis vu sous l’angle de la performance.

La perte de clés de chiffrement. Les disques chiffrés LUKS et les sauvegardes chiffrées avec age fonctionnent tant que les clés existent. Perdez-les et les données sont perdues — comme une clé SSH ou un portefeuille Bitcoin. Nous documentons la procédure de récupération LUKS dans docs/luks.md ; le reste relève de votre gestionnaire de mots de passe.

Le risque interne au sein de votre propre équipe. Un administrateur malveillant ou négligent peut lire les événements bruts avant le hachage, supprimer des tables ou exfiltrer des journaux d’audit. Le RBAC (admin / viewer / API-only) aide à compartimenter ; le risque résiduel vous appartient.

L’erreur opérationnelle. Supprimer des données, mal configurer les sauvegardes, laisser le tableau de bord grand ouvert. Le même exercice de restauration qui protège d’une faille protège aussi d’une erreur opérationnelle — mais seulement si vous l’avez réellement exécuté.

Si ces quatre points vous conviennent mieux que la liste des risques SaaS ci-dessus, auto-hébergez. Sinon, le chemin SaaS privé UE en couvre la plupart tout en préservant l’histoire de résidence des données en UE uniquement.

L’architecture en binaire unique

Les deux chemins exécutent le binaire Go identique contre le schéma ClickHouse identique. Il n’y a pas de fork, pas de second code. Tous les assets — JS du traceur, SPA du tableau de bord, migrations ClickHouse, dépendances Go vendorisées — sont embarqués via go:embed. Pas de CDN externe, pas d’npm install à l’exécution, pas de go mod download au runtime.

Le fonctionnement en air-gap est un objectif non négociable du projet, pas une aspiration. Le binaire est requis pour fonctionner entièrement en air-gap sous iptables -P OUTPUT DROP avec zéro connexion sortante requise. La porte de validation de la version exécute le test air-gap à chaque version : ingestion d’événements, matérialisation des rollups, rendu du tableau de bord — tout cela sous le drop iptables. Le trafic sortant des fonctionnalités optionnelles (par ex. une mise à jour optionnelle de la base GeoIP) passe par internal/httpclient/guarded.go — liste d’autorisation FQDN, rejet des adresses RFC-1918/loopback/CGNAT après résolution DNS, HTTPS forcé. La liste d’autorisation par défaut est vide.

En CI, la règle air-gap-validator rejette les constructions *http.Client brutes, le DNS/HTTP au runtime, les imports CDN dans le tableau de bord ou le traceur, les pings de télémétrie, et les URL de polices/scripts externes. Le contrat est appliqué par la revue de code et par Semgrep, pas par une liste de contrôle.

Défense en profondeur — les affirmations concrètes

Les primitives cryptographiques et opérationnelles, avec les chemins de fichiers pour les vérifier :

Identité du visiteur : HMAC(master_secret, site_id || YYYY-MM-DD), BLAKE3-keyé, dérivé en cours de processus, jamais persisté, renouvelé quotidiennement. Même visiteur → hash différent chaque jour. Stocké en FixedString(16) (BLAKE3-128 tronqué à 16 octets) dans ClickHouse. SHA-256 / BLAKE3 sont les seules familles de hachage dans le binaire ; aucun MD5, aucun SHA-1.
Auth du tableau de bord : hachage de mot de passe bcrypt coût 12, tokens de session crypto/rand de 32 octets (256 bits, encodés hex), TTL de 14 jours, cookies SameSite=Lax HttpOnly Secure. Un bcrypt coût 12 prend ~50 ms+ sur toute machine qui le fait tourner — c’est le but.
Journal d’audit : JSONL via slog de Go, append-only, sink fichier uniquement en v1, discipline chattr +a, logrotate copytruncate=off. Syslog et sinks distants différés à la v1.1 — cela préserve la valeur par défaut air-gap.
Chiffrement au repos : LUKS2 avec aes-xts-plain64, taille de clé 512, PBKDF argon2id, iter-time 2000. Requis sur VPS cloud mutualisé (y compris Netcup VPS 2000 G12 NUE D1) ; optionnel sur matériel cage dédié. L’impact E/S mesuré est de 40–50 % sur ext4-over-LUKS1 ; AES-NI + AVX2 le divise par deux.
Sauvegardes chiffrées : clickhouse-backup + age + zstd, planifiées par cron. Test de restauration à chaque version. Les sauvegardes sont envoyées dans un second emplacement UE-uniquement pour le SaaS ; pour l’auto-hébergé, l’emplacement est au choix de l’opérateur.
Durcissement systemd : NoNewPrivileges, ProtectSystem=strict, PrivateTmp, CapabilityBoundingSet=CAP_NET_BIND_SERVICE. L’unité de service est livrée avec les règles iptables air-gap via make airgap-bundle.
Court-circuit Sec-GPC : quand Sec-GPC : 1 ou DNT : 1 est défini, la requête est abandonnée avant que l’identifiant du visiteur ne soit calculé. Aucun identifiant pseudonyme n’est généré pour un visiteur qui refuse — il n’y a rien à supprimer parce que rien n’a été créé.

Quand auto-héberger, quand opter pour le SaaS privé UE

Cinq facteurs tranchent réellement la question. La plupart des lecteurs se retrouveront rapidement dans une colonne.

1. Effectif ops. L’auto-hébergement a un coût en temps ops. L’opérateur prend en charge la rotation TLS, les mises à jour de la base GeoIP, les montées de version ClickHouse, les patches noyau, la passphrase LUKS. Si vous n’avez personne dont c’est déjà le travail de gérer un serveur Linux, choisissez le SaaS.

2. Volume de trafic. Le plafond de conception de Statnive Live est de 200 M d’événements/jour par nœud sur une machine 8 cœurs / 32 Go. En dessous de ~10 M d’événements/jour, les deux chemins fonctionnent de façon équivalente ; au-dessus de ~50 M d’événements/jour, la maturité opérationnelle pour l’auto-hébergement commence à se justifier par elle-même.

3. Posture d’audit et de conformité. Les secteurs réglementés ont souvent besoin à la fois d’un DPA signé conforme à l’art. 28(3) et d’une infrastructure qu’ils pilotent. Le SaaS privé couvre la moitié DPA ; l’auto-hébergement couvre les deux mais transfère la charge opérationnelle sur votre équipe.

4. Géographie. Le SaaS est traité à Nuremberg, Allemagne (Netcup VPS 2000 G12 NUE) — UE/EEE uniquement, pas de transfert relevant du chapitre V. L’auto-hébergement place les données là où se trouve votre serveur. Les règles de résidence des données propres à certains pays (FADP suisse, marchés publics du secteur public allemand) nécessitent parfois une ville précise — seul l’auto-hébergement offre ce niveau de contrôle.

5. Coût à l’échelle. Le SaaS est facturé au trafic (Starter / Growth / Business de $9 à $339/mois sur les paliers publiés ; Enterprise au-dessus). L’auto-hébergement échange la facture SaaS contre un Hetzner CX43 (~14 €/mois) ou un Netcup VPS 2000 G12 (25,48 €/mois mensuel) plus le temps de l’opérateur. À faible trafic, le SaaS gagne sur le TCO ; à très fort trafic, l’auto-hébergement l’emporte.

Si trois de ces facteurs ou plus penchent dans le même sens, c’est votre réponse. S’ils sont partagés, optez par défaut pour le SaaS les 6 premiers mois — vous pouvez migrer vers l’auto-hébergement plus tard sans perdre de données, car le binaire et le schéma sont les mêmes.

Le « SaaS privé » comme voie intermédiaire

Une note précise sur ce que « privé » signifie dans ce contexte. Le SaaS Statnive Live est logiquement isolé par locataire — chaque ligne d’événement porte un site_id, chaque requête du tableau de bord passe par whereTimeAndTenant() avec WHERE site_id = ? comme premier prédicat, et une règle CI de point d’étranglement de locataire rejette toute nouvelle requête qui la contourne. Il ne s’agit pas d’une mono-location physique : un seul cluster ClickHouse sert tous les clients. Les clients voulant une mono-location physique choisissent l’auto-hébergement.

Ce que le SaaS livre dès le départ :

DPA conforme à l’art. 28(3) RGPD sur tous les plans (y compris Free), signé et daté du 24/04/2026. Le DPA couvre les huit sous-paragraphes de l’art. 28(3) — instructions uniquement, confidentialité, sécurité art. 32, autorisation de sous-traitants ultérieurs, assistance aux droits des personnes concernées, assistance aux obligations du responsable pour les arts. 32–36, suppression ou restitution à la résiliation, et droits d’audit.
Liste des sous-traitants mise à jour dans les 7 jours de tout changement en amont, avec 14 jours de préavis aux clients via la page de confidentialité ; le client peut s’y opposer par écrit dans ce délai.
Fenêtre d’export client de 30 jours à la résiliation — CSV/JSON complets via l’endpoint d’export standard. Après 30 jours, tables brutes, tables de rollup, sauvegardes (prochain cycle de sauvegarde ≤ 24 h) et journaux d’audit sont supprimés, sauf si le droit de l’Union ou d’un État membre exige une conservation.
SLA de notification de faille de 48 heures à partir de la prise de connaissance, conformément à l’art. 33 du RGPD.
Traitement UE/EEE uniquement. Aucun transfert relevant du chapitre V de données personnelles stockées hors de l’EEE. Les deux sous-traitants résidant aux États-Unis présents dans la chaîne — Cloudflare DNS-only, Let’s Encrypt pour les certificats DV — sont divulgués dans le § 6 du DPA sous l’adéquation DPF. Ils reçoivent uniquement des métadonnées DNS et des métadonnées de certificat, jamais de charge utile applicative.

Ce dernier point est la réponse centrale à la question CLOUD Act / FISA 702. « Aucune partie incorporée aux États-Unis dans la chaîne de traitement » est la version stricte, et c’est ce que Civo et SoftwareSeni défendent dans les sources citées. « Dire Francfort ou Dublin ne rend pas un fournisseur américain souverain » est ce à quoi l’architecture doit réellement répondre ; « exploité par un client résidant en Allemagne d’une entité juridique allemande sur une infrastructure à Nuremberg » est la réponse.

Le chemin de migration entre les deux

Cette partie est courte, car elle est délibérément sans surprise.

Même binaire, même schéma. Les migrations vivent dans clickhouse/migrations/ et utilisent des templates Go {{if .Cluster}} dès le premier jour — la transition nœud unique → Distributed est un changement de configuration, pas une migration de plateforme.

Pas de verrouillage des données. ClickHouse utilise des formats binaires standard (Parquet / Native / RowBinary) plus le format d’archive clickhouse-backup. Migrer hors de Statnive Live vers ClickHouse Cloud ou un cluster autogéré est une restauration clickhouse-backup, pas une réimportation.

Export et effacement scoped au visiteur. GET /api/privacy/access retourne les lignes liées au cookie sur le site résolu (art. 15) ; POST /api/privacy/erase est l’endpoint d’effacement correspondant (art. 17). Le chemin d’effacement énumère system.columns dynamiquement, de sorte que toute nouvelle table qui porte un cookie_id est automatiquement incluse dans son périmètre — et la clause WHERE est cookie_id = ? AND site_id = ? afin qu’une demande d’effacement sur un site ne puisse jamais atteindre les lignes d’un autre locataire. DSAR dès le premier jour, pas en rattrapage.

Si vous commencez sur le SaaS privé et souhaitez ensuite auto-héberger, demandez le binaire plus une archive clickhouse-backup de vos données. Le pipeline de version produit un statnive-live-<VERSION>-linux-amd64-airgap.tar.gz reproductible plus des SHA256SUMS (et une signature Ed25519 optionnelle) — vous copiez l’archive, restaurez vos données avec clickhouse-backup restore, et vous faites tourner le même tableau de bord contre le même schéma, simplement sur votre matériel.

Questions fréquentes

Que se passe-t-il si Statnive Live ferme ?

Même binaire, vous continuez à le faire tourner. Les clients auto-hébergés l’ont déjà. Les clients SaaS peuvent demander le binaire plus une archive clickhouse-backup de leurs données à la sortie. Le pipeline de version produit un bundle air-gap reproductible avec des sommes SHA256 ; rien de cela ne dépend du fait que Statnive soit en activité.

Puis-je déplacer mes données vers ClickHouse Cloud ?

Oui. Les données sont au format ClickHouse standard ; la restauration clickhouse-backup vers une cible ClickHouse Cloud est le chemin supporté. Si vous voulez utiliser les données avec un autre outil, l’endpoint d’export produit du CSV/JSON.

Mon CI peut-il tourner contre une instance Statnive ?

Oui. make ci-local lance ClickHouse, lance le binaire Go, exécute les tests d’intégration et les arrête. Le CI de chaque PR le fait déjà — c’est le même exercice que vous utiliseriez en local.

Où conserver les sauvegardes chiffrées ?

Au choix de l’opérateur pour l’auto-hébergement : tout store compatible S3, tout disque distant, tout support. Pour le SaaS, un second emplacement UE-uniquement est la réponse contractuelle. La restauration est testée à chaque version, quelle que soit la localisation des sauvegardes.

CLOUD Act / FISA 702 — Nuremberg aide-t-il ?

Oui, quand le fournisseur est également non contrôlé par des États-Unis. Le SaaS Statnive Live est exploité par un client résidant en Allemagne de Netcup (entité juridique allemande) sur l’infrastructure Netcup à Nuremberg. Aucune partie incorporée aux États-Unis dans la chaîne de traitement → aucune portée CLOUD Act / FISA 702 sur la charge utile applicative. Deux sous-traitants résidant aux États-Unis apparaissent sous l’adéquation DPF — Cloudflare DNS-only et Let’s Encrypt — recevant des métadonnées DNS et des métadonnées de certificat uniquement. C’est une surface différente de « la base de données vit sur AWS-Francfort ».

Qu’en est-il de la reprise après sinistre ?

Le même test de restauration s’exécute à chaque version, contre le même format de sauvegarde chiffrée — chiffré age, compressé zstd, archive clickhouse-backup. Nous avons également documenté le chemin de récupération LUKS dans docs/luks.md pour la couche de chiffrement au repos. Il n’y a pas de magie ; il y a un exercice qui a réellement été exécuté.

L’essentiel

L’auto-hébergement n’est pas un étendard idéologique en 2026 — c’est la réponse la plus propre à une tendance mesurable dans la pression réglementaire et de marchés publics de l’UE. Statnive Live livre le même binaire Go plus le même schéma ClickHouse en deux formes : auto-hébergé, où vous prenez toute la responsabilité opérationnelle et perdez les risques liés au fournisseur SaaS ; et SaaS privé UE à Nuremberg, où vous bénéficiez d’un DPA art. 28(3), d’une résidence des données UE-uniquement et d’un SLA de sous-traitants à 7 jours — mais aussi du rayon de blast multi-locataire que l’architecture a été conçue pour borner.

Choisissez le chemin qui correspond à votre effectif ops, votre trafic et votre posture d’audit. Si vous hésitez, commencez par le SaaS — la migration vers l’auto-hébergement est à une restauration clickhouse-backup de distance.

Statnive Live arrive bientôt sur fr.statnive.com/live. En attendant, le plugin WordPress est sur WordPress.org, l’article de comparaison présente l’arbre de décision WP-vs-Live, le guide RGPD couvre le volet réglementaire, et la page de tarifs présente les deux produits ensemble. Si vous comparez spécifiquement les alternatives à GA, notre classement détaillé couvre sept solutions de remplacement axées sur la confidentialité, avec des notes d’intégration WordPress. Si un fait dans cet article s’avère erroné, écrivez-moi — chaque affirmation a une note de bas de page, et nous préférons en corriger une plutôt que de livrer une demi-vérité bien tournée.