Le guide 2026 de l'analyse web sans consentement dans l'UE

Ceci est une recherche en matière de protection des données, et non un conseil juridique. Voir la note de bas de page pour la clause de non-responsabilité complète.

TL;DR

L’analyse web sans bandeau est réalisable en 2026 — sous la fiche n°16 de la CNIL, les lignes directrices 2021 du Garante italien, le guide AEPD espagnol et la position de l’AP néerlandaise, ainsi que la référence la plus stricte (le § 25 TDDDG allemand).
Configurez pour l’Allemagne ; le reste de l’UE s’aligne automatiquement. L’architecture serveur sans cookie qui satisfait au § 25 TDDDG satisfait par construction à toutes les autres dérogations nationales de mesure d’audience.
GA4 échoue à la dérogation dans tous les États membres qui en possèdent une. Transfert transfrontalier + mutualisation entre clients + identifiant persistant + non-éditeur-unique le disqualifient.
L’article 88a, § 3, point c du Digital Omnibus harmoniserait la dérogation à l’échelle de l’UE — mais c’est une proposition de la Commission, pas une loi ; et l’avis conjoint 2/2026 du CEPD-EDPS du 11 février 2026 a soulevé des préoccupations sur le paquet plus large.
Architecturez pour les deux scénarios. Un déploiement en propre sans cookie satisfait la mosaïque actuelle et est positionné pour qualifier dès le premier jour si l’article 88a est adopté tel quel.

Pourquoi un guide, et pourquoi maintenant

Une part croissante d’opérateurs européens parvient simultanément à la même conclusion : le bandeau de cookies est une taxe sur la mesure, et la mesure qui passe est de plus en plus peu fiable. L’étude de Plausible sur les bandeaux cookies chiffre la taxe de perte de visibilité à environ 55,6 % — des visiteurs qui sont arrivés sur le site, ont refusé le bandeau et sont sortis de l’analyse web. Les deux sanctions de la CNIL — 325 M€ contre Google et 150 M€ contre Shein le 1er septembre 2025 — toutes deux sur l’expérience utilisateur du bandeau de cookies plutôt que sur l’ad-tech en aval — ont fait du bandeau lui-même la responsabilité réglementaire, et plus seulement des cookies derrière.

Il existe une voie légale pour exécuter l’analyse web sans bandeau sur la majeure partie de l’UE. Elle existe depuis l’amendement de la directive ePrivacy en 2009. La CNIL française a passé la dernière décennie à la peaufiner ; le Garante italien et l’AEPD espagnole ont construit leurs propres versions ; la proposition Digital Omnibus de la Commission du 19 novembre 2025, si adoptée, harmoniserait cette voie dans les 27 États membres. L’Allemagne reste l’exception stricte et façonne ce qui est atteignable.

C’est un guide pratique. Ce que « sans consentement » signifie réellement en 2026, où chaque régulateur se positionne, ce qui disqualifie presque toutes les configurations Google Analytics 4, ce qui maintient un opérateur exempté, pourquoi le tracking « anonyme » n’est pas ce qu’il semble être, et la configuration que nous avons bâtie dans Statnive Live pour que le travail soit en grande partie fait dans le binaire.

Ce que « sans consentement » signifie réellement

Deux couches de droit européen régissent l’analyse web, et les deux s’appliquent simultanément. Manquer à l’une suffit à exiger un consentement.

Couche 1 — Directive ePrivacy 2002/58/CE, article 5, paragraphe 3. Le consentement est exigé avant de stocker sur, ou d’accéder à des informations déjà stockées sur, l’équipement terminal d’un utilisateur — sauf lorsque cela est strictement nécessaire pour transmettre une communication, ou pour fournir un service expressément demandé par l’utilisateur. Les lignes directrices 2/2023 version 2.0 du CEPD, adoptées le 7 octobre 2024, ont étendu cette portée expressément au-delà des cookies — le tracking par pixel, le tracking par URL, le fingerprinting on-device, les données générées localement accessibles via API, les identifiants hachés côté client, le reporting IoT, et le tracking IP seul lorsque l’opérateur instruit l’appareil d’envoyer des informations sont tous dans le champ. Tout ce qui lit ou écrit sur l’appareil du visiteur déclenche l’article 5, paragraphe 3.

Couche 2 — RGPD. Tout traitement ultérieur de données personnelles nécessite une base légale au titre de l’article 6. Pour l’analyse web, cela signifie le consentement (article 6, paragraphe 1, point a), le contrat (point b) ou l’intérêt légitime (point f). (f) exige une évaluation des intérêts légitimes (LIA) documentée selon les lignes directrices 1/2024 du CEPD du 8 octobre 2024 — identification de l’intérêt → nécessité → mise en balance par rapport aux droits et attentes raisonnables de la personne concernée.

Ces deux couches s’ajoutent, elles ne se substituent pas. Selon l’avis 5/2019 du CEPD et réaffirmé par les Storage and Access Technologies Guidance d’avril 2026 de l’ICO britannique, l’article 5, paragraphe 3 de l’ePrivacy est lex specialis sur le RGPD pour tout stockage/accès sur équipement terminal. L’intérêt légitime au titre de l’article 6, paragraphe 1, point f du RGPD ne peut pas se substituer au consentement au titre de l’article 5, paragraphe 3 de l’ePrivacy. Le Garante italien va plus loin et interdit expressément l’intérêt légitime comme base pour les cookies et les mécanismes de tracking.

Il existe exactement deux voies vers une analyse web sans consentement satisfaisant les deux couches :

Voie 1 : ne pas déclencher l’article 5, paragraphe 3 du tout. Pas de cookies, pas de localStorage, pas de sondes de fingerprinting, pas de lectures d’identifiant côté client. Le navigateur envoie uniquement ce qu’il envoie par défaut (IP, User-Agent, Referer) ; le serveur les lit à l’ingestion, calcule son analyse web et n’écrit rien en retour sur l’appareil. C’est la seule voie sans consentement disponible en Allemagne au titre du § 25 TDDDG, et c’est la référence stricte que ce guide suppose.
Voie 2 : entrer dans une dérogation nationale de mesure d’audience. La fiche n°16 de la CNIL française, les lignes directrices cookies du 10 juin 2021 du Garante italien, le guide AEPD espagnol sur les cookies de mesure d’audience et la position cookies analytiques de l’AP néerlandaise permettent tous des cookies de mesure d’audience en propre strictement configurés sans consentement, selon leurs transpositions ePrivacy respectives. Chaque dérogation a ses propres conditions. Aucune n’est reconnue en Allemagne.

La conception robuste est la Voie 1 par défaut et la Voie 2 uniquement lorsqu’un opérateur a documenté qu’il satisfait à une dérogation nationale spécifique. Statnive Live livre la Voie 1 dans son mode consent-free et expose un énum de juridictions pour que les opérateurs des pays sous fiche n°16 puissent superposer la Voie 2.

La carte 2026, en un coup d’œil

Où chaque grand régulateur UE/EEE se positionne sur l’analyse web sans consentement, en mai 2026.

Juridiction	Dérogation mesure d’audience	Notes
France (CNIL)	Oui — Fiche n°16 + auto-évaluation du 4 juillet 2025	La plus permissive de l’UE. Date limite de conformité 1er janvier 2026. Conditions strictes : site unique, ≤3 types d’événements, troncature du dernier octet de l’IP, durée du traceur de 13 mois, conservation des données de 25 mois. Voir le décryptage CNIL.
Allemagne (DSK)	Non	Le § 25 TDDDG exclut l’intérêt légitime comme base pour le stockage/accès. L’architecture sans consentement doit être un traitement purement côté serveur. Voir le décryptage TDDDG.
Italie (Garante)	Oui — Lignes directrices cookies du 10 juin 2021 (en vigueur depuis le 10 janvier 2022)	Conditions : pas d’identification directe, cookies à IP masquée, statistiques mono-site, pas de transmission à des tiers. Intérêt légitime expressément interdit pour les cookies.
Espagne (AEPD)	Oui — Guide sur la mesure d’audience (2024)	Conditions alignées sur la CNIL. LSSI article 22.2 + LOPD-GDD.
Pays-Bas (AP)	Oui — « Les cookies analytiques … n’exigent pas de consentement s’ils sont utilisés uniquement pour compter les visiteurs »	Article 11.7a Telecommunicatiewet. L’AP surveille 500 sites par an pour la conformité.
Belgique (APD)	Non	« Les cookies de mesure d’audience ne sont pas exemptés de l’exigence de consentement dans le cadre juridique actuel. »
Irlande (DPC)	Aucune dérogation publiée	S’aligne sur les lignes directrices 5/2020 du CEPD.
Royaume-Uni (ICO)	Non — mais priorité d’application basse	Storage and Access Technologies Guidance de l’ICO d’avril 2026 : « Les cookies analytiques ne tombent pas sous la dérogation ‘strictement nécessaire’. » Priorité basse reconnue mais non codifiée pour l’analyse en propre à faible intrusion.
Autriche (DSB)	Pas de dérogation autonome	Décision NetDoktor du 22 décembre 2021 a constaté que le transfert GA UE→US était illégal pour des motifs Schrems II.

La carte de référence pays par pays couvre les juridictions UE/EEE restantes ainsi que les questions des opérateurs sur les seaux « OTHER-EU » et « OTHER-NON-EU ».

L’effet pratique de cette carte : un opérateur qui configure pour l’Allemagne — la cellule la plus stricte — est configuré pour partout ailleurs dans l’UE. Un opérateur qui configure pour la fiche n°16 française couvre proprement la France, l’Italie, l’Espagne et les Pays-Bas, mais a toujours besoin de l’architecture niveau Allemagne si du trafic est allemand. Configurez pour l’Allemagne ; cela se compose vers le haut.

Les sept à-ne-pas-faire qui disqualifient presque toutes les configurations GA4

Voici la checklist négative de l’opérateur. Chacun de ces points, dans toute juridiction de la carte ci-dessus, écarte un déploiement analytique du territoire sans consentement et le ramène à « il faut un bandeau avec un bouton Refuser aussi facile que Accepter ».

1. Ne posez pas de cookie de tracking et n’écrivez pas dans localStorage sans consentement. Les cookies pour la mesure d’audience sont permis sous la fiche n°16 française, le guide AEPD espagnol et les lignes directrices 2021 du Garante — mais uniquement sous les conditions strictes des dérogations nationales, pas par défaut. localStorage et sessionStorage déclenchent le même article 5, paragraphe 3 que les cookies et n’ont nulle part de dérogation pour la mesure d’audience.

2. N’utilisez pas un sel statique ou unique. Un hachage avec sel statique d’un IPv4 est une pseudonymisation, pas une anonymisation — le Garante italien l’a précisément retenu dans sa décision Caffeina Media du 9 juin 2022 contre la fonctionnalité d’anonymisation IP de Google. L’espace IPv4 compte environ 4,3 milliards d’adresses ; une rainbow table de SHA-256(static_salt + IPv4) est triviale sur un seul GPU. Un sel qui ne tourne pas est un sel qui ne protège pas.

3. Ne stockez pas d’IP brutes ni de chaînes User-Agent brutes. Toutes deux sont des données personnelles en pratique — l’arrêt Breyer de la CJUE (C-582/14, 19 octobre 2016) l’a tranché pour les IP dynamiques. Selon l’auto-évaluation de la CNIL de juillet 2025, IPv4 est tronquée à /24 (et IPv6 à /48 ou /64) et les User-Agents sont réduits à leurs versions majeures uniquement (« Chrome 126 », pas « Chrome/126.0.6478.127 Mobile Safari/537.36 ») avant tout stockage.

4. N’utilisez pas de bibliothèques de fingerprinting tierces. Canvas, contexte audio, paramètres WebGL, énumération des polices, hardware concurrency — tout cela entre dans le champ de l’article 5, paragraphe 3 selon les lignes directrices 2/2023 du CEPD. FingerprintJS, ClientJS et les divers SDK commerciaux de fingerprinting déclenchent un consentement dans toutes les juridictions de l’UE. Le skill de revue de code RGPD de Statnive les interdit dans le tracker.

5. Ne croisez pas avec les CRM clients ou d’autres données du site. La condition de la fiche n°16 de la CNIL est explicite : « aucune mise en commun par le prestataire de données brutes de mesure d’audience provenant de plusieurs de ses clients n’est mise en œuvre. » Pas de mutualisation entre les clients du prestataire ; pas de jointures avec d’autres ensembles internes qui construiraient des profils inter-contextes.

6. Ne réutilisez pas d’identifiants entre sites clients. Le même visiteur sur deux sites différents doit produire deux signatures non liées. Fiche n°16 CNIL : « Aucun identifiant permettant un suivi à travers plusieurs domaines n’est utilisé. » C’est pourquoi Fathom et Statnive utilisent tous deux une composante de sel propre au site — la même personne visitant deux sites différents génère par construction deux hachages non corrélables.

7. Ne transférez pas de données personnelles aux États-Unis ou à d’autres pays tiers sans couverture vérifiée du chapitre V. Les décisions de 2022 — DSB autrichien NetDoktor, CNIL française, Garante italien et DPA danoise — interdisant Google Analytics pour des motifs Schrems II n’ont été renversées par aucune décision de 2024-2026. Le Data Privacy Framework UE-US actuel (en vigueur depuis juillet 2023) fournit une couverture intérimaire mais fait l’objet d’attaques pendantes (Latombe et noyb en parallèle). La réponse architecturalement durable est UE uniquement.

GA4 échoue au minimum aux points 1 (identifiant persistant), 5 (écosystème inter-clients de Google), 6 (identifiant inter-sites) et 7 (transfert de données aux États-Unis). La conclusion verbatim de la CNIL dans la fiche n°16 : « La plupart des grandes offres de mesure d’audience ne relèvent pas du champ de la dérogation, quelle que soit leur configuration. »

Les cinq à-faire qui vous maintiennent exempté

Ce sont les conditions qui — appliquées ensemble — permettent à une pile analytique en propre de qualifier simultanément pour le régime le plus strict actuel (§ 25 TDDDG) et la dérogation nationale la plus permissive (fiche n°16 CNIL). C’est aussi l’architecture que la proposition Digital Omnibus article 88a, § 3, point c standardiserait à l’échelle de l’UE si elle était adoptée telle quelle.

1. Sel à rotation quotidienne, propre au site, avec destruction. Les signatures de visiteurs sont dérivées comme BLAKE3-HMAC(master_secret, site_id || YYYY-MM-DD). Le sel est calculé en mémoire, jamais stocké, et le sel du jour précédent est détruit à la rotation. Même visiteur lundi et mardi → deux signatures différentes ; la ré-identification inter-jours est impossible par construction. Même visiteur sur deux sites différents → deux signatures non corrélables ; la ré-identification inter-sites est impossible par construction. C’est la construction Plausible (hash(daily_salt + website_domain + ip_address + user_agent)) plus une garantie de suppression du sel.

2. Troncature IP avant tout stockage. Retirez au moins le dernier octet d’IPv4 (203.0.113.42 → 203.0.113.0/24). Pour IPv6, conservez uniquement le préfixe réseau — typiquement /48 ou /64. L’IP brute peut exister brièvement dans le chemin de la requête pour le lookup GeoIP ; elle doit être écartée avant que l’écrivain par lots ne voie la ligne. La géolocalisation se dégrade à ville/région — le plafond CNIL.

3. Minimisation User-Agent et référent host-only. Les UA réduits à appareil + version majeure du navigateur + version majeure de l’OS, parsés côté serveur, chaîne brute écartée. Référent réduit au seul host (example.com, pas example.com/search?q=secret) avant stockage — élimine les PII accidentelles dans les chaînes de requête. Les deux sont des conditions de la fiche n°16 CNIL et les deux se produisent à l’ingestion dans le serveur de Statnive Live.

4. Pas de cookies, pas de localStorage, pas de fingerprinting. L’article 5, paragraphe 3 ePrivacy ne se déclenche pas car aucun stockage ni accès sur équipement terminal ne se produit. Vérifiez dans vos DevTools de navigateur → Application → Storage ; les quotas restent à zéro. Pas de sondes Canvas, WebGL, énumération de polices, contexte audio ni navigator.plugins non plus — ce sont toutes des lectures côté client que les lignes directrices 2/2023 du CEPD placent dans le champ de l’article 5, paragraphe 3.

5. Conservation bornée avec une LIA documentée. Les plafonds CNIL — durée de traceur de 13 mois et conservation des données de 25 mois — sont les barres européennes les plus strictes actuellement. Agrégez les sorties du tableau de bord à la dizaine la plus proche (ou documentez une analyse d’anonymisation citant l’avis WP29/CEPD sur l’anonymisation). Maintenez une LIA selon les lignes directrices 1/2024 du CEPD — implication du DPO, test en trois étapes, mise à jour annuelle ou lors de changements substantiels. Une AIPD au titre de l’article 35 du RGPD pour les déploiements à fort volume, à vertical sensible ou riches en fonctionnalités.

Ces cinq points constituent l’architecture. Ils ne dépendent pas de l’adoption du Digital Omnibus. Ils survivent au régime le plus strict actuel des États membres. Et ils se composent en une configuration unique que l’opérateur n’a pas à échanger lorsque la jurisprudence évolue.

Pourquoi « anonyme » ne suffit pas — la distinction de pseudonymisation

Les opérateurs ayant lu un peu les pages marketing de leurs fournisseurs d’analyse web ont vu le mot « anonyme » appliqué aux IP hachées et au tracking sans cookie. Ce mot accomplit un travail juridique que le RGPD ne permet pas.

Les lignes directrices 01/2025 du CEPD sur la pseudonymisation à l’état de projet — adoptées comme projet lors de la 101e plénière le 16 janvier 2025, en consultation publique jusqu’au 28 février 2025 et encore en cours d’élaboration en mai 2026 — clarifient que les données pseudonymisées, y compris les IP hachées, les ID de cookies, les signatures de visiteur BLAKE3/HMAC et les chaînes TC, restent des données personnelles lorsque la ré-identification est raisonnablement probable via les moyens à disposition du responsable ou de tout tiers. L’arrêt IAB Europe de la CJUE (C-604/22, 7 mars 2024) a étendu cela au-delà des chaînes TC à tout identifiant associé à une IP.

En pratique :

Un système de tracking sans cookie avec un sel à rotation quotidienne est pseudonyme à l’intérieur du jour et devient anonyme uniquement à travers les jours — et uniquement parce que le sel du jour précédent est détruit.
Un hash IP à sel statique est pseudonyme indéfiniment et est réversible par quiconque dispose d’un GPU et d’une liste d’IP candidates.
Une géolocalisation « à l’échelle de la ville » dérivée d’une troncature IP /24 est pseudonyme selon Breyer — mais la troncature retire l’identifiant le plus réversible de la couche de stockage, ce qu’exigent à la fois le principe de minimisation des données de l’article 5, paragraphe 1, point c du RGPD et la condition de la fiche n°16 CNIL.

La posture robuste : traitez les identifiants visiteurs hachés comme des données personnelles à faible risque. Appliquez la base d’intérêt légitime de l’article 6, paragraphe 1, point f à leur traitement. Documentez la LIA. Honorez les demandes d’accès (article 15) et d’effacement (article 17) à leur sujet via un endpoint DSAR. Ne les commercialisez pas comme « anonymes ». Ce mot est pour des données dont la ré-identification n’est raisonnablement pas possible par quiconque, jamais — et une IP hachée révélée par les pouvoirs d’accès légal d’un État ne franchit pas cette barre.

C’est aussi pourquoi le Garante italien a jugé insuffisante la fonctionnalité d’anonymisation IP de Google dans sa décision Caffeina Media : « la fonctionnalité constitue une pseudonymisation de l’adresse IP, et non une anonymisation. … la fonctionnalité n’empêche pas Google LLC de ré-identifier l’utilisateur, compte tenu de la capacité de Google à enrichir ces données par des informations supplémentaires qu’elle détient. » La fonctionnalité faisait exactement ce que son marketing disait. Elle n’était simplement pas une anonymisation au sens du RGPD.

Comment Statnive Live est bâti pour cela

Statnive Live a été conçu selon les à-faire et à-éviter ci-dessus. L’architecture est ce que le serveur hébergé chez Hetzner à Nuremberg exécute par défaut ; le même binaire est aussi auto-hébergeable sur l’infrastructure du client, auquel cas rien n’est traité par Statnive.

Sans cookie par construction. Pas de cookies, pas de localStorage, pas de sessionStorage. L’article 5, paragraphe 3 ePrivacy ne se déclenche pas car aucun stockage ni accès sur équipement terminal ne se produit. Le tracker est un script en propre d’environ 2,0 Ko minifié / 0,9 Ko gzippé servi depuis le même domaine que le site de l’opérateur — pas de CDN tiers, pas de tag manager tiers.

Signatures visiteur BLAKE3-HMAC à rotation quotidienne. Les hachages sont dérivés comme HMAC(master_secret, site_id || YYYY-MM-DD). Le sel est en mémoire ; le sel du jour précédent est détruit à la rotation. La construction correspond à l’approche Plausible/Fathom et ajoute une composante par site, de sorte qu’un visiteur sur deux sites trackés par Statnive génère deux signatures non corrélables.

ID de cookie haché au repos. Lorsqu’un opérateur exécute Statnive Live en mode consent-required ou hybrid avec consentement donné, l’ID de cookie émis vers le navigateur est un UUID brut ; la valeur stockée côté serveur est SHA-256(master_secret || site_id || cookieID) avec un préfixe h:. Le navigateur voit l’UUID brut ; la base de données ne le voit jamais. La continuité visiteur inter-jours est préservée sans stocker l’identifiant brut.

Référent host-only côté serveur. Le tracker stocke le document.referrer complet ; à l’ingestion, le serveur le réduit à la portion host avant écriture. Les chaînes de requête (qui peuvent porter des termes de recherche ou des PII) n’entrent jamais en stockage persistant.

IP brute écartée avant stockage. L’IP existe dans le chemin de la requête pour le lookup GeoIP et la dérivation du hash ; elle est écartée avant que l’écrivain par lots ne voie la ligne. Vérifié par un test d’intégration dans internal/enrich/geoip.go du dépôt Statnive Live.

Conservation rollup 25 mois. Un TTL de 750 jours est appliqué sur les rollups AggregatingMergeTree v1 (hourly_visitors, daily_pages, daily_sources) — 24,6 mois, correspondant au plafond CNIL avec marge. Au-delà, les rollups expirent automatiquement sans intervention de l’opérateur.

Quatre modes de consentement, onze juridictions, validation par règle stricte. La politique de site porte un énum de mode de consentement (permissive / consent-free / consent-required / hybrid) et un énum de juridiction (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU). Un validateur de règle stricte empêche les opérateurs allemands de choisir permissive (le § 25 TDDDG l’interdit) et de choisir consent-required sans intégration de consentement active. Le validateur fonctionne à la sauvegarde dans l’admin et de nouveau à chaque chargement de politique sur chaque requête d’ingestion. Le décryptage TDDDG couvre la cellule Allemagne en détail.

GPC et DNT court-circuitent avant le hash. Lorsque Sec-GPC: 1 ou DNT: 1 est défini et que la politique de site honore ces signaux, la requête est abandonnée avant que l’identifiant visiteur ne soit calculé. Aucun identifiant pseudonyme n’est généré pour un visiteur qui refuse — il n’y a rien à supprimer car rien n’a été créé. Le billet GPC et mode hybride passe par le plan de test bout-en-bout.

Endpoints DSAR de série. POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase — protégés CSRF, limités en débit, journalisés à des fins d’audit. Huit événements d’audit privacy (privacy.opt_out_received, privacy.dsar_access_requested, privacy.dsar_erase_requested, privacy.consent_given, privacy.consent_withdrawn, legal.lia_viewed, legal.dpa_viewed, legal.privacy_policy_viewed) émettent des journaux structurés prêts pour un audit d’accountability au titre de l’article 28, paragraphe 3, point h. Le billet DSAR couvre la surface d’intégration.

Routes de divulgation légale publiques embarquées dans le binaire. /privacy, /legal/privacy-policy/en, /legal/privacy-policy/de, /legal/lia et /legal/dpa sont servies par le même binaire Go que le tracker — pas de dépendance CDN, sûr en air-gap, accessible aux opérateurs exécutant Statnive Live dans des environnements à sortie restreinte.

Le résultat est une configuration qui satisfait à la barre stricte allemande aujourd’hui, qualifie sous la fiche n°16 française avec une auto-évaluation documentée, et est positionnée pour qualifier sous l’article 88a, § 3, point c proposé dès le premier jour si le Digital Omnibus est adopté tel quel. Les opérateurs n’ont pas à choisir ; la même politique de site les emmène tous.

Ce qui s’annonce — article 88a, § 3, point c

La proposition Digital Omnibus de la Commission européenne du 19 novembre 2025 — COM(2025) 837 final — introduirait un nouvel article 88a du RGPD comportant une liste limitative d’objectifs sans consentement. Le sous-paragraphe pertinent pour l’analyse web est 88a § 3 point c : « creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use. »

Statut à mi-mai 2026 : le dossier compte la rapporteure ITRE Aura Salla (EPP/FI — nomination contestée par sept organisations de la société civile sur fond de conflit lié au lobbying chez Meta) et la rapporteure LIBE Marina Kaljurand (S&D/EE) ; le CESE a adopté son avis le 18 mars 2026 ; le groupe de travail du Conseil est en discussion active (fichier WK 3736/2026 INIT). Il n’y a pas encore de vote en plénière du Parlement européen sur COM(2025) 837 — un vote en plénière du 26 mars 2026 sur le dossier distinct Digital Omnibus sur l’IA est une proposition différente. L’avis conjoint 2/2026 du CEPD-EDPS du 11 février 2026 a soulevé des préoccupations sérieuses sur l’effet du paquet plus large sur la protection individuelle et la sécurité juridique. Adoption réaliste fin 2026 à 2027 ; entrée en vigueur probable 2027 à 2028 ; article 88a applicable six mois après l’entrée en vigueur.

Trois implications pour les opérateurs :

La configuration de ce guide est rétro-compatible. La mesure d’audience en propre, agrégée, à usage exclusif du responsable du traitement est exactement le cas d’usage décrit par l’article 88a, § 3, point c. Les opérateurs déployant les à-faire ci-dessus qualifient aujourd’hui sous les dérogations nationales lorsqu’elles existent, et qualifieront demain sous l’article 88a à l’échelle de l’UE si adopté tel quel.
La proposition est un glissement de couche, pas un ajout parallèle. Pour l’accès aux données personnelles sur équipement terminal, l’article 88a du RGPD régirait et l’article 5, paragraphe 3 ePrivacy cesserait de s’appliquer à ces opérations. Pour l’accès aux données non personnelles sur équipement terminal (un résidu plus étroit), l’article 5, paragraphe 3 ePrivacy continue de régir. Les deux cadres fonctionneraient séquentiellement, non en parallèle. La position la plus propre reste « aucun stockage ni accès sur équipement terminal en premier lieu » — cela évite les deux couches.
Le texte est une feuille de route, pas une base juridique actuelle. Les opérateurs qui conçoivent uniquement pour le Digital Omnibus et non pour le droit actuel des États membres passeront les 12-18 prochains mois dans un vide réglementaire.

Comment déployer ce guide

Une séquence de déploiement pratique pour un opérateur prenant en main Statnive Live (ou répliquant l’architecture sur une pile auto-hébergée) :

Choisissez votre juridiction la plus stricte. Si du trafic est allemand, configurez pour DE / consent-free. Le validateur de règle stricte le fait pour vous et refuse les configurations permissives.
Publiez une évaluation des intérêts légitimes. Le modèle des lignes directrices 1/2024 du CEPD est la structure canonique : identification de l’intérêt → nécessité → mise en balance. Téléchargez le modèle LIA pour la formulation recommandée par Statnive Live ; adaptez-la à votre contexte de traitement avec un conseil.
Publiez une notice de confidentialité. Des clauses EN et DE sont embarquées dans Statnive Live aux endpoints /legal/privacy-policy/en et /legal/privacy-policy/de. La clause allemande comporte la formulation verbatim § 25 Abs. 1 TDDDG sur l’absence de stockage ou d’accès sur équipement terminal ; la clause anglaise couvre la base de l’article 6, paragraphe 1, point f et le schéma d’attestation de la fiche n°16 de la CNIL.
Câblez les endpoints DSAR. Trois routes (/api/privacy/opt-out, /api/privacy/access, /api/privacy/erase) sont exposées par le binaire. Le billet DSAR couvre l’intégration ; la surface de journalisation d’audit est câblée par défaut.
Honorez GPC par défaut en mode UE. Définissez consent.respect_gpc = true sur chaque site allemand, français, italien et néerlandais. Le billet GPC explique les couches de court-circuit côté client + application côté serveur.
Exécutez l’endpoint d’audit d’événements mensuellement. GET /api/admin/event-audit?site_id=N retourne le nombre de noms d’événements uniques par site face au plafond CNIL de trois événements. Visez le statut ok ; investiguez tout over immédiatement.
Révisez la LIA chaque année. Le CEPD recommande une mise à jour annuelle et lors de changements substantiels — par exemple, à l’adoption du Digital Omnibus, à un renvoi CJUE affectant le statut DPF, ou à une publication de nouvelles lignes directrices d’un régulateur national.

La carte de référence pays par pays est la table de consultation pour les détails par juridiction. Les trois billets privacy existants — Pourquoi l’analyse web datenschutzfreundliche compte en 2026, Analyse web conforme au RGPD en 2026 et Possédez vos données analytiques : auto-hébergé vs SaaS UE privée en 2026 — couvrent le paysage plus large et l’aspect responsable-vs-sous-traitant.

À faire et à éviter — la carte condensée

Les sections du corps ci-dessus contiennent les listes complètes « Sept à-ne-pas-faire » et « Cinq à-faire ». La version condensée, pour les opérateurs qui scannent d’abord :

À faire	À éviter
Configurer pour le régime le plus strict des États membres (le § 25 TDDDG allemand) — le reste de l’UE se compose vers le haut.	Configurer séparément pour chaque État membre où vous avez du trafic — c’est la voie vers 27 LIA différentes que vous ne mettrez jamais à jour.
Utiliser un sel à rotation quotidienne, propre au site ; détruire le sel d’hier en fin de journée.	Utiliser un sel statique — un seul GPU et une rainbow table IPv4 l’inversent ; le Garante l’a dit dans Caffeina Media.
Tronquer IPv4 à /24 et IPv6 à /48 avant tout stockage ; réduire User-Agent aux versions majeures ; réduire Referer à host.	Stocker IP brutes, User-Agents bruts ou URL de référent complètes — toutes sont des données personnelles ; les chaînes de requête brutes fuitent des PII.
Publier une évaluation des intérêts légitimes documentée selon les lignes directrices 1/2024 du CEPD et l’auto-évaluation spécifique au pays.	Revendiquer « CNIL-certifié » ou utiliser le logo CNIL. La CNIL a retiré son programme d’évaluation le 1er janvier 2026 — les opérateurs s’auto-évaluent.
Honorer GPC et DNT par défaut en mode UE ; honorer le droit d’opposition de l’article 21 avec un lien d’opt-out persistant.	Traiter les ID de visiteurs hachés comme des données « anonymes » — ils sont pseudonymes selon le projet de lignes directrices 01/2025 du CEPD, données personnelles à part entière selon Breyer.

Le mot de la fin

L’analyse web sans consentement dans l’UE est réalisable en 2026. Elle n’est pas réalisable par accident, et elle n’est pas réalisable en configurant un outil d’analyse basé aux États-Unis pour « anonymiser » les IP. Elle est réalisable en concevant le déclencheur de stockage/accès hors du système, en dérivant des signatures qui se détruisent elles-mêmes, en tronquant les données identifiantes à l’ingestion, et en documentant la base d’intérêt légitime selon le test en trois étapes du CEPD. L’architecture est la conformité ; le contrat est la piste d’audit.

Configurez pour l’Allemagne ; vous êtes configuré pour partout ailleurs. Faites tourner une LIA ; vous avez une base à montrer. Honorez GPC ; vous avez une présomption de conformité sous l’article 88b proposé. Bornez votre conservation à 25 mois ; vous êtes dans le plafond CNIL sans effort. Sautez les cookies complètement ; vous sautez la responsabilité UX du bandeau de cookies qui a produit 475 M€ de sanctions CNIL en septembre 2025.

Voilà ce que Statnive Live propose. Sans cookie. UE uniquement. Sels à rotation quotidienne. ID de cookie haché au repos. Référent host-only. Conservation 25 mois. Quatre modes de consentement, onze juridictions, validation par règle stricte. Endpoints DSAR, modèle LIA, modèles de notice de confidentialité et DPA dans le binaire, téléchargeables sans appel commercial.

Si ce guide vous aide à resserrer un pan de votre pile analytique actuelle, c’est ce pour quoi il existe. S’il vous convainc de basculer — c’est ce pour quoi statnive.com/live existe. Dans les deux cas, les à-faire et à-éviter ci-dessus sont l’architecture durable ; la jurisprudence et les propositions continueront de bouger autour, et le guide est conçu pour que l’opérateur n’ait pas à ré-architecturer à chaque fois.

Ceci est une recherche en matière de protection des données, et non un conseil juridique. Les configurations décrites qualifient au titre des lignes directrices des régulateurs lorsqu’elles sont déployées conformément à une évaluation des intérêts légitimes documentée et à l’auto-évaluation nationale pertinente. Chaque client de Statnive demeure responsable du traitement et est responsable de sa propre configuration et AIPD. Consultez un conseil juridique qualifié dans votre juridiction avant publication.

État des références réglementaires au 13 mai 2026 : fiche n°16 CNIL + mise à jour du 4 juillet 2025 (la date limite de conformité du 1er janvier 2026 est désormais passée ; programme d’évaluation retiré ; régime d’auto-évaluation en vigueur) ; § 25 TDDDG (en vigueur depuis le 1er décembre 2021, renommé en mai 2024) ; lignes directrices cookies du Garante italien du 10 juin 2021 (en vigueur depuis le 10 janvier 2022) ; guide AEPD sur les cookies (juillet 2023, appliqué le 11 janvier 2024) ; position cookies analytiques de l’AP néerlandaise (article 11.7a Telecommunicatiewet) ; Storage and Access Technologies Guidance de l’ICO britannique (29 avril 2026) ; lignes directrices 2/2023 v2.0 du CEPD (7 octobre 2024) ; lignes directrices 1/2024 du CEPD (8 octobre 2024) ; projet de lignes directrices 01/2025 du CEPD sur la pseudonymisation (adoptées comme projet le 16 janvier 2025 ; consultation publique jusqu’au 28 février 2025 ; version finale non encore publiée en mai 2026) ; avis conjoint 2/2026 du CEPD-EDPS du 11 février 2026 sur le Digital Omnibus ; Digital Omnibus COM(2025) 837 final (proposition de la Commission du 19 novembre 2025, pas de vote en plénière du Parlement européen sur COM(2025) 837 au 13 mai 2026) ; CJUE C-582/14 Breyer (ECLI:EU:C:2016:779) ; CJUE C-604/22 IAB Europe (7 mars 2024) ; CJUE C-621/22 KNLTB (ECLI:EU:C:2024:857) ; CJUE C-446/21 Schrems v Meta (4 octobre 2024).