Le § 25 TDDDG en Allemagne : la contrainte server-side uniquement

Il s’agit de recherche sur la vie privée, et non d’un conseil juridique. Voir l’avertissement complet en pied de page.

TL;DR

Le § 25 TDDDG est la contrainte contraignante pour tout déploiement paneuropéen. Configurez pour l’Allemagne ; le reste de l’UE compose vers le haut.
L’intérêt légitime ne se substitue pas au consentement § 25. L’Orientierungshilfe DSK Version 1.2 du 20 novembre 2024 est sans ambiguïté sur ce point — et reste l’orientation opérationnelle à la date de mai 2026.
La seule architecture sans consentement est un traitement purement server-side sans cookie, sans localStorage, sans sonde de fingerprinting, sans lecture d’identifiant côté client. Le « Zugriff auf Informationen » du § 25 va au-delà des cookies jusqu’à toute lecture de données côté client.
Une Analyse d’Intérêt Légitime documentée au titre de l’article 6(1)(f) doit néanmoins exister pour la couche de traitement RGPD qui suit l’ingest server-side — l’AILI ne déverrouille pas d’exemption § 25, mais elle fonde le traitement des données à caractère personnel.
L’application est active dans BayLDA, NRW LDI, BlnBDI et HmbBfDI en 2024-2026 — ciblant les déploiements GA4 / Meta Pixel / Hotjar sans consentement conforme au TDDDG. Sanction maximale : 300 000 € par § 28(1) No. 13 plus amendes RGPD au titre de l’article 83 en parallèle.

Pourquoi l’Allemagne est différente

La carte 2026 UE de l’analyse web sans consentement n’est pas uniforme. La CNIL française a construit une exemption détaillée de mesure d’audience — le Garante italien, l’AEPD espagnole et l’AP néerlandaise ont construit la leur. L’Allemagne n’en a pas. La Datenschutzkonferenz — l’instance coordonnée des 17 régulateurs allemands de protection des données — a confirmé dans son Orientierungshilfe für Anbieter:innen von digitalen Diensten (Version 1.2, 20 novembre 2024) que le § 25 TDDDG est lex specialis et que seuls le consentement ou la stricte nécessité permettent le stockage ou l’accès sur l’appareil terminal de l’utilisateur. L’intérêt légitime au titre de l’article 6(1)(f) RGPD n’est pas une base alternative valide pour l’opération de stockage/accès elle-même.

Cela fait de l’Allemagne la contrainte contraignante pour tout déploiement d’analyse web paneuropéen. Un opérateur qui configure pour l’Allemagne est configuré pour partout ailleurs dans l’UE. Un opérateur qui configure uniquement pour la Fiche 16 française doit toujours à l’opérateur allemand une réponse séparée et plus stricte.

L’article qui suit est la réponse allemande. La règle elle-même, le renommage de mai 2024, l’exemption étroite, pourquoi le « server-side uniquement » est la posture opérationnelle, l’Analyse d’Intérêt Légitime au titre de l’article 6(1)(f) RGPD qui doit néanmoins exister, où Statnive Live se positionne, le bloc de politique de confidentialité en langue allemande qu’un opérateur peut coller, et les 8 événements d’audit de confidentialité qui produisent la piste de redevabilité.

TDDDG, en bref

La Telekommunikation-Telemedien-Datenschutz-Gesetz allemande est entrée en vigueur le 1 décembre 2021 sous le nom de TTDSG (la transposition par le gouvernement fédéral de l’article 5(3) ePrivacy en droit national). En mai 2024, lorsque l’Allemagne a transposé le Digital Services Act de l’UE, le texte a été renommé en TDDDG — Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz. Le fond n’a pas été changé ; seul le nom a reflété la portée DSA plus large.

Le § 25 est la disposition opérationnelle relative aux cookies/stockage et la transposition directe de l’article 5(3) de la Directive ePrivacy 2002/58/CE (telle que modifiée par 2009/136/CE).

§ 25(1) TDDDG (traduction française) : « Le stockage d’informations sur l’équipement terminal de l’utilisateur final ou l’accès à des informations déjà stockées dans l’équipement terminal n’est autorisé que si l’utilisateur final y a consenti sur la base d’informations claires et exhaustives. L’information à l’utilisateur final et le consentement sont fournis conformément au Règlement (UE) 2016/679 [RGPD]. »

§ 25(2) ne crée d’exemption que pour deux cas :

(i) la finalité unique est de transmettre un message via un réseau public de télécommunications, et
(ii) le stockage ou l’accès est absolument essentiel pour fournir un service numérique expressément demandé par l’utilisateur.

C’est toute l’exemption. Il n’y a pas d’exemption de mesure d’audience dans le texte allemand. Il n’y a pas d’équivalent de la Fiche 16 française, des lignes directrices cookies 2021 italiennes ou du guide espagnol de mesure d’audience. Le § 25(2) couvre les cas strictement nécessaires — un cookie de panier d’achat, une session d’authentification, un jeton CSRF — et c’est toute la liste.

Les sanctions au titre du § 28(1) No. 13 et § 28(2) TDDDG vont jusqu’à 300 000 € par violation. Les amendes RGPD au titre de l’article 83 (jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial) s’appliquent en parallèle pour la couche de traitement des données à caractère personnel.

La position DSK et pourquoi l’intérêt légitime ne vous sauve pas

La Datenschutzkonferenz (DSK) — l’instance coordonnée des APD fédérales et de Länder allemandes — a publié son Orientierungshilfe für Anbieter:innen von digitalen Diensten Version 1.2 le 20 novembre 2024. L’orientation est sans ambiguïté sur deux points.

Point un : le § 25 TDDDG est lex specialis. Pour tout stockage ou accès sur l’équipement terminal d’un utilisateur, l’exigence de consentement (ou de stricte nécessité) du § 25 régit. Les dispositions de base légale de l’article 6 RGPD ne fournissent pas de base alternative pour l’opération de stockage/accès elle-même.

Point deux : l’intérêt légitime ne peut pas se substituer au consentement § 25. Même si l’opérateur dispose d’une Analyse d’Intérêt Légitime au titre de l’article 6(1)(f) parfaitement documentée, cette AILI couvre le traitement des données à caractère personnel après leur collecte — pas l’acte de les collecter via un accès à l’équipement terminal. Les deux sont régis par des couches différentes et exigent des bases différentes.

L’effet pratique : un déploiement d’analyse web qui pose un cookie, écrit dans localStorage ou lit un identifiant côté client déclenche le § 25 TDDDG. Le déploiement a besoin de consentement. Point final. Aucun raisonnement « intérêt légitime » ne rattrape l’exigence de consentement à la couche § 25.

C’est pourquoi la position allemande est tellement plus stricte que celle de la France. L’exemption Fiche 16 de la CNIL interprète l’article 5(3) ePrivacy avec une exception définie de mesure d’audience intégrée à la transposition nationale. Le § 25(2) allemand interprète l’article 5(3) ePrivacy sans cette exception de mesure d’audience. Les deux interprétations sont cohérentes avec la Directive sous-jacente ; elles se positionnent simplement à des endroits différents dans la marge de discrétion par État membre que la Directive permet.

La seule architecture sans consentement : server-side uniquement

L’unique architecture qui survit au § 25 TDDDG sans consentement est une où le serveur de l’opérateur ne stocke pas sur ni n’accède aux informations de l’équipement terminal du visiteur. Le navigateur n’envoie que ce qu’il envoie par défaut dans le cadre d’une requête HTTP inévitable — IP, User-Agent, en-têtes Referer. Le serveur lit ces en-têtes, dérive ses analyses, et n’écrit rien en retour. Aucun cookie. Aucun localStorage. Aucune sonde de fingerprinting. Aucune construction d’identifiant côté client. Aucune instruction à l’appareil d’envoyer des informations supplémentaires.

Cela tombe entièrement en dehors du § 25 TDDDG. Le déclencheur « stockage ou accès sur l’équipement terminal » de l’article 5(3) ePrivacy ne se déclenche pas car aucune interaction avec l’équipement terminal au-delà du comportement par défaut de requête du navigateur ne se produit. Les lignes directrices 2/2023 v2.0 du CEPD couvrent explicitement cette exemption : lorsque l’opérateur n’instruit pas l’appareil d’envoyer des informations et n’écrit ni ne lit le stockage de l’appareil, l’article 5(3) ne s’applique pas.

C’est aussi la seule architecture sans consentement qui satisfait les 27 États membres y compris les plus stricts. C’est surdimensionné pour la France ; c’est nécessaire pour l’Allemagne. Les opérateurs avec du trafic allemand — même une petite part — devraient concevoir vers la base server-side uniquement car le coût d’architecturer deux piles (une pour l’Allemagne, une pour partout ailleurs) dépasse presque toujours le coût de la base stricte unifiée.

L’AILI au titre de l’article 6(1)(f) RGPD — toujours requise

Contourner le § 25 TDDDG à la couche de l’équipement terminal n’élimine pas la question RGPD. Une fois que le serveur lit l’IP, le User-Agent et le Referer de la requête, il traite des données à caractère personnel. L’arrêt Breyer de la CJUE (C-582/14, 19 octobre 2016) a réglé qu’une IP dynamique est une donnée à caractère personnel entre les mains d’un opérateur de site web. Le User-Agent est un identifiant à empreinte digitale en soi.

La base légale au titre de l’article 6 RGPD pour ce traitement est réalistement l’article 6(1)(f) — intérêts légitimes — pour la mesure d’audience first-party. La DSK a accepté cette position dans son orientation 2024, mais uniquement à la condition explicite que l’exigence d’accès à l’équipement terminal du § 25 TDDDG soit satisfaite indépendamment (c’est-à-dire que l’exception strictement nécessaire s’applique, ou qu’aucun accès à l’équipement terminal ne se produise). L’architecture server-side uniquement remplit cette condition par construction.

L’Analyse d’Intérêt Légitime elle-même doit être documentée selon les lignes directrices 1/2024 du CEPD :

Identification de l’intérêt. Exploiter, améliorer et sécuriser le site web du responsable de traitement (la composante fonctionnelle reconnue dans Breyer §§ 60-64) ; mesurer l’audience et l’engagement de contenu (la composante commerciale reconnue dans CJUE C-621/22 KNLTB §§ 47-49, arrêt du 4 octobre 2024).
Nécessité. La mesure d’audience ne peut pas être raisonnablement atteinte par des moyens moins intrusifs tout en produisant les métriques nécessaires. Minimisation : pas d’identifiant persistant ; IP brute écartée avant stockage ; sel quotidien-rotatif et à portée de site ; troncature IPv4 /24 ; User-Agent réduit aux versions majeures ; référent réduit à l’hôte ; agrégation à la dizaine la plus proche.
Mise en balance. Intérêts de la personne concernée : article 7 de la Charte (vie privée) et article 8 (protection des données). Attentes raisonnables : un visiteur s’attend à ce que l’opérateur connaisse les comptages de visites agrégés et la popularité des pages, pas une surveillance individuelle cross-day ou cross-site — l’architecture correspond à cette attente. Impact : minimal — pas de publicité comportementale, pas de profilage, pas de partage avec des tiers, pas de décisions affectant la personne concernée. Mitigations : destruction du sel en fin de journée, troncature IP, plafond de conservation, opt-out au titre de l’article 21, DPA en place le cas échéant, hébergement UE uniquement, chemins de code open source pour les déploiements auto-hébergés.

L’AILI n’est pas un exercice ponctuel. Le CEPD recommande un rafraîchissement annuel et en cas de changement matériel — par exemple sur un renvoi CJUE qui affecte l’analyse Breyer, sur l’adoption du Digital Omnibus, ou sur les mises à jour d’orientation nationale allemande.

Où Statnive Live se positionne

Statnive Live est construit pour satisfaire le § 25 TDDDG par construction. Les étapes de configuration de l’opérateur pour un site allemand :

Sélectionner la juridiction DE. Le panneau de politique du site de Statnive Live expose une énumération à 11 juridictions. Sélectionner DE déclenche le validateur de règle stricte.
Le validateur de règle stricte interdit permissive. Un opérateur allemand ne peut pas sélectionner le mode permissive — le validateur refuse la sauvegarde avec l’erreur : « Le mode de consentement permissive est incompatible avec le § 25 TDDDG (Allemagne). Sélectionnez consent-free ou consent-required. » Ceci est appliqué à la sauvegarde de la politique et à nouveau au chargement de la politique sur chaque requête d’ingest, de sorte que la configuration ne peut pas être modifiée hors bande.
Défaut à consent-free. Cela désactive les cookies, localStorage et le fingerprinting dans le traceur ; active la signature de visiteur BLAKE3-HMAC quotidienne-rotative côté serveur ; active la transformation du référent en hôte uniquement ; active la troncature IP ; active la minimisation User-Agent. L’architecture correspond à la base « pas de stockage ou d’accès à l’équipement terminal » du § 25 TDDDG.
Identifiant de cookie haché au repos, mais aucun cookie posé. Lorsque consent-free est actif, aucun cookie _statnive n’est posé sur le navigateur. Il n’y a aucun cookie à hacher au repos dans ce mode. (En mode consent-required ou hybrid avec consentement donné, un UUID est émis vers le navigateur ; le stockage 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.)
GPC et DNT honorés. Dans la juridiction DE, consent.respect_gpc = true est le défaut. Les visiteurs envoyant Sec-GPC: 1 sont court-circuités avant le calcul de l’identifiant de visiteur — aucun enregistrement pseudonyme n’est créé pour un visiteur qui refuse, il n’y a donc rien à supprimer puisque rien n’a été écrit. Le post GPC et mode hybride couvre le plan de test de bout en bout.
Points d’accès DSAR honorés. POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase sont exposés sur chaque déploiement Statnive Live quelle que soit la juridiction. L’opérateur allemand dispose du câblage même si, en mode consent-free, le volume de demandes d’accès et d’effacement sur un déploiement sans cookie est intrinsèquement faible — la plupart des visiteurs ne laissent aucun enregistrement par visiteur dès que le sel tourne.
Routes publiques de divulgation légale intégré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. La route /legal/privacy-policy/de sert la clause allemande verbatim décrite dans la section suivante.

L’énumération à onze juridictions (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU) et les quatre modes de consentement (permissive / consent-free / consent-required / hybrid) se composent en 44 cellules. La ligne DE n’a que deux cellules valides — consent-free et consent-required. Le travail du validateur est d’empêcher l’existence des 22 autres cellules.

Le bloc de politique de confidentialité allemand

Un opérateur exécutant le mode consent-free de Statnive Live pour un site allemand peut servir la clause suivante à /datenschutz (ou la page juridique équivalente). La formulation est le texte verbatim de research-53 §08 et reflète l’analyse § 25 TDDDG ci-dessus.

Reichweitenmessung. Diese Website verwendet [Statnive Live] zur rein server-seitigen Reichweitenmessung. Es werden keine Cookies, kein Local Storage und keine vergleichbaren Technologien auf Ihrem Endgerät gespeichert oder ausgelesen. Insbesondere findet kein Zugriff im Sinne des § 25 Abs. 1 TDDDG statt. Verarbeitet werden ausschließlich Daten, die Ihr Browser für die Auslieferung der Seite ohnehin überträgt (IP-Adresse, Browser-Kennung in stark reduzierter Form, aufgerufene URL, Referrer-Domain). Wir kürzen Ihre IP-Adresse vor jeder weiteren Verarbeitung um das letzte Oktett und ersetzen sie durch eine pseudonymisierte Signatur, deren Salt nach 24 Stunden vernichtet wird.

Rechtsgrundlage. Soweit personenbezogene Daten im Sinne der DSGVO verarbeitet werden, stützt sich die Verarbeitung auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Eine Interessenabwägung gemäß EDSA-Leitlinien 1/2024 wurde dokumentiert.

Widerspruchsrecht gemäß Art. 21 DSGVO : [OPT-OUT-BUTTON].

La clause fait trois choses à la fois. Elle dit au visiteur ce qui se passe (reine server-seitige Reichweitenmessung) ; elle dit au régulateur pourquoi le § 25 TDDDG ne s’applique pas (pas de stockage ou d’accès à l’équipement terminal) ; et elle dit à la personne concernée quelle est la base RGPD (article 6(1)(f) plus une AILI documentée) et comment s’opposer (le lien d’opt-out de l’article 21).

Ce n’est pas un substitut à la propre politique de confidentialité de l’opérateur. L’opérateur doit toujours une notice complète couvrant l’identité du responsable de traitement, les finalités, les catégories de données, la période de conservation, les destinataires et les droits énumérés par les articles 13-22 du RGPD. La clause ci-dessus s’insère dans la section Reichweitenmessung de cette notice plus large.

L’opt-out de l’article 21 est implémenté dans Statnive Live sous la forme d’un cookie strictement nécessaire exprimant le choix de l’utilisateur — ce qui est autorisé au titre du § 25(2)(ii) TDDDG car il met en œuvre la préférence de service expressément demandée par l’utilisateur (le droit d’opposition). Alternativement, l’opt-out peut être persisté côté serveur via une liste de suppression indexée sur la signature h: du visiteur avec un TTL adéquat.

Le journal d’audit — 8 événements de confidentialité

Statnive Live émet 8 événements d’audit structurés couvrant la surface confidentialité-et-juridique. Ce sont les preuves de redevabilité de l’article 28(3)(h) prêtes pour un DPO ou un auditeur :

privacy.opt_out_received — une opposition au titre de l’article 21 a été enregistrée.
privacy.dsar_access_requested — une demande de droit d’accès au titre de l’article 15 a été initiée.
privacy.dsar_erase_requested — une demande de droit à l’effacement au titre de l’article 17 a été initiée.
privacy.consent_given — statnive.acceptConsent() a été appelée (pertinent en modes consent-required et hybrid, pas en consent-free).
privacy.consent_withdrawn — statnive.withdrawConsent() a été appelée.
legal.lia_viewed — la page /legal/lia a été servie.
legal.dpa_viewed — la page /legal/dpa a été servie.
legal.privacy_policy_viewed — la page /legal/privacy-policy/{lang} a été servie.

Pour un déploiement allemand consent-free, le mélange d’événements typique est opt_out_received (faible volume — la plupart des visiteurs ne s’opposent jamais car l’architecture est inobjectable), dsar_*_requested occasionnel (les droits des personnes concernées sont des fonctionnalités de disponibilité technique quel que soit le mode), et un flux constant de legal.*_viewed (suivi de transparence montrant que les visiteurs lisent réellement les pages de politique).

Les événements émettent vers le puits de logs supporté par l’environnement de l’opérateur — stdout/stderr dans les déploiements conteneurisés, syslog sur les hôtes traditionnels, ou une table d’audit dédiée dans les configurations auto-hébergées. Les événements d’audit sont du JSON structuré qui s’analyse proprement dans Loki, Elasticsearch ou tout pipeline de logs structurés.

Le journal d’audit est ce que l’opérateur pointe si l’APD de Berlin ou le BayLDA bavarois ouvre une inspection. La clause dans la politique de confidentialité est la position publique ; les événements d’audit sont la preuve contemporaine que la position est réellement mise en œuvre.

Ce que cela apporte à un opérateur allemand

Le résultat pratique :

Aucun bandeau cookies requis pour le flux de mesure d’audience, sur la base qu’aucun stockage ou accès à l’équipement terminal ne se produit — la position européenne la plus stricte actuelle satisfaite par construction, pas par interprétation d’exemption ePrivacy.
Une AILI documentée au titre de l’article 6(1)(f) comme base RGPD pour le traitement des données à caractère personnel que le serveur effectue après lecture de l’IP, du User-Agent et du Referer à l’ingest. Le modèle d’AILI est à /legal/lia ; à personnaliser au contexte de traitement de l’opérateur avec un conseil.
Un bloc de politique de confidentialité qui nomme le § 25 Abs. 1 TDDDG et explique pourquoi il ne s’applique pas. Le bloc vit à /legal/privacy-policy/de et est prêt à coller dans la page /datenschutz de l’opérateur.
Une configuration qui satisfait les 27 États membres en déployant la cellule la plus stricte. Ajouter du trafic français, italien ou néerlandais ne nécessite pas de ré-architecturer ; la configuration existante qualifie également pour la Fiche 16 CNIL, les Lignes directrices cookies 2021 du Garante, le guide AEPD de mesure d’audience et la position cookies-analytiques de l’AP néerlandaise. La carte pays par pays parcourt les deltas.
Compatibilité ascendante avec l’article 88a(3)(c) du Digital Omnibus proposé. Si le texte de la Commission est adopté intact, un déploiement Statnive Live consent-free qualifie dès le premier jour.

Ce que cela n’apporte pas : la possibilité de poser un bandeau de consentement allemand gratuit, ou d’exécuter GA4 en Allemagne sur une base d’intérêt légitime. Ni l’un ni l’autre n’est réalisable ; l’orientation 2024 de la DSK ferme les deux chemins.

FAQ

Un opérateur allemand a-t-il encore besoin d’un bandeau dans un quelconque but ?

Possiblement — mais pas pour la mesure d’audience. Un bandeau de consentement n’est requis que pour le traitement qui déclenche le § 25(1) TDDDG (stockage ou accès sur l’appareil) et tombe en dehors du § 25(2)(i)-(ii). Cela inclut tout cookie publicitaire tiers, pixel de reciblage, widget de partage social qui pose des cookies, vidéos YouTube/Vimeo intégrées qui posent des cookies au chargement de la page, cookies de variante de test A/B, et ainsi de suite. Pour ces finalités, l’opérateur doit un bandeau avec une UX « Refuser aussi simple qu’Accepter » et la reconnaissance par l’Ordonnance allemande de gestion du consentement le cas échéant.

La couche de mesure d’audience — les comptages de visiteurs, la popularité des pages, l’analyse des référents — n’a pas besoin de bandeau dans les conditions de ce post. L’opérateur choisit s’il consolide l’analyse web sur la couche de mesure d’audience uniquement ou s’il ajoute une couche séparée avec consentement pour l’attribution e-commerce, les tests A/B ou l’attribution de campagne marketing.

Qu’en est-il de l’Ordonnance sur la gestion du consentement (EinwV) ?

L’Ordonnance allemande sur la gestion du consentement — Einwilligungsverwaltungsverordnung — a été approuvée par le Bundesrat le 20 décembre 2024 et est entrée en vigueur le 1 avril 2025 au titre du § 26(2) TDDDG. Elle reconnaît les Personal Information Management Services (PIMS) ; les sites web doivent honorer les signaux des services de gestion de consentement reconnus. L’EinwV ne change pas la règle substantive du § 25 — elle ajoute un chemin PIMS-reconnu pour le consentement que la règle exige lorsque le consentement est requis.

Pour un déploiement consent-free, l’EinwV est largement non pertinente car aucun consentement n’est sollicité. Pour un déploiement consent-required ou hybrid, le chemin de reconnaissance EinwV est le mécanisme à long terme pour honorer les signaux de consentement au niveau du navigateur — voir le post GPC et mode hybride pour comment Statnive Live met en œuvre la gestion des signaux au niveau du navigateur aujourd’hui.

L’arrêt BGH Planet49 change-t-il quelque chose ?

L’arrêt de la Cour fédérale de justice allemande BGH I ZR 7/16 Planet49 (rendu le 28 mai 2020, suite à CJUE C-673/17 du 1 octobre 2019) a confirmé en droit allemand que les cases pré-cochées ne produisent pas de consentement valide et que les approches d’opt-out au titre de l’ancien § 15(3) TMG étaient insuffisantes post-RGPD. L’arrêt renforce la direction du consentement au § 25 — il ne l’affaiblit pas. Les opérateurs qui interprètent BGH Planet49 comme un assouplissement du régime allemand de consentement ont mal lu l’arrêt.

Puis-je utiliser l’intérêt légitime pour les cookies en Allemagne si mon AILI est très approfondie ?

Non. L’orientation 2024 de la DSK est explicite : l’intérêt légitime ne se substitue pas au consentement § 25 TDDDG à la couche d’accès à l’équipement terminal. Une AILI documentée de manière exhaustive est requise pour la base de l’article 6 RGPD pour le traitement ultérieur des données à caractère personnel, mais elle ne déverrouille pas une exemption de stockage de cookies à la couche § 25. C’est la position cohérente de l’avis 5/2019 du CEPD et est réaffirmée par l’orientation Storage and Access Technologies de l’ICO britannique d’avril 2026.

La façon de satisfaire le droit allemand sans consentement est de ne pas écrire sur l’appareil en premier lieu. Architectez le cookie hors du système ; la question d’intérêt légitime devient la question RGPD-article-6-uniquement, pas la question § 25.

Quoi faire, et quoi éviter

À faire	À éviter
Sélectionner la juridiction `DE` dans Statnive Live ; défaut au mode `consent-free` (le validateur de règle stricte l’applique).	Mettre un site allemand en mode `permissive` — le § 25 TDDDG l’interdit ; le validateur refuse la sauvegarde.
Honorer GPC et DNT par défaut en mode UE ; court-circuiter l’ingest avant de calculer la signature du visiteur.	Traiter l’analyse web sans cookies comme automatiquement conforme au § 25 — la DSK a confirmé que l’accès aux informations de l’appareil final déclenche aussi le § 25, même sans cookies.
Publier la clause Reichweitenmessung verbatim à `/datenschutz` nommant le § 25 Abs. 1 TDDDG et le droit d’opposition de l’article 21.	Revendiquer « aucun bandeau de consentement nécessaire en DE » sans l’AILI documentée + la divulgation dans la politique de confidentialité. La position DSK exige les deux.
Documenter une Analyse d’Intérêt Légitime au titre de l’article 6(1)(f) selon les lignes directrices 1/2024 du CEPD pour le traitement des données à caractère personnel que le serveur effectue à l’ingest.	S’appuyer sur l’intérêt légitime comme substitut au consentement § 25 à la couche d’accès à l’équipement terminal. L’Orientierungshilfe DSK Version 1.2 est sans ambiguïté : ce n’est pas possible.
Recouper avec un conseil allemand qualifié — typiquement un Fachanwalt für IT-Recht — avant publication.	Exécuter GA4 / Meta Pixel / Hotjar pré-consentement en Allemagne. BayLDA, NRW LDI, BlnBDI et HmbBfDI ont tous sanctionné des opérateurs pour cela.

La conclusion

Le § 25 TDDDG d’Allemagne est la position européenne actuelle la plus stricte sur le consentement à l’équipement terminal. Il n’y a pas d’exemption de mesure d’audience en droit allemand, la DSK a confirmé que l’intérêt légitime ne se substitue pas à l’exigence § 25, et les sanctions vont jusqu’à 300 000 € par violation au titre du § 28(1) No. 13 plus les amendes RGPD au titre de l’article 83.

La seule architecture sans consentement qui survit en Allemagne est celle où aucun stockage ou accès sur l’équipement terminal ne se produit. Le mode consent-free de Statnive Live plus la juridiction DE est exactement cette architecture, appliquée par un validateur de règle stricte qui refuse de sauvegarder une configuration allemande permissive. Le bloc de politique de confidentialité à /legal/privacy-policy/de nomme le § 25 Abs. 1 TDDDG et le droit d’opposition de l’article 21. Les 8 événements d’audit de confidentialité émettent la piste contemporaine de redevabilité.

Un opérateur qui configure pour l’Allemagne est, par construction, configuré pour le reste de l’UE. La base stricte compose vers le haut. Le Manuel 2026 de l’analyse web sans consentement dans l’UE est le cadre plus large ; le post Fiche 16 CNIL est l’alternative française ; la carte pays par pays parcourt les États membres restants. Le chemin de l’opérateur allemand est celui décrit dans ce post.

Il s’agit de recherche sur la vie privée, et non d’un conseil juridique. Statnive Live, configuré en mode consent-free pour la juridiction DE avec consent.respect_gpc = true et une Analyse d’Intérêt Légitime documentée, est architecturé pour qualifier comme déploiement sans stockage-ni-accès-à-l’équipement-terminal au titre du § 25 TDDDG. L’architecture supprime le déclencheur du § 25(1) ; l’AILI couvre la base de l’article 6(1)(f) RGPD pour le traitement ultérieur. Chaque client de Statnive demeure le responsable de traitement et porte la responsabilité de sa propre configuration et AIPD. À recouper avec un conseil allemand qualifié — le DPO de référence ou un Fachanwalt für IT-Recht — avant publication.

Statut des références réglementaires au 13 mai 2026 : TDDDG (renommé depuis TTDSG le 14 mai 2024 ; aucun amendement textuel au § 25 entre cette date et mai 2026) ; § 25 TDDDG ; § 28(1) No. 13 TDDDG ; DSK Orientierungshilfe für Anbieter:innen von digitalen Diensten Version 1.2 du 20 novembre 2024 (toujours opérationnelle ; pas de version successeur à la date de mai 2026 ; confirme que le suivi sans cookies déclenche également le § 25 lorsqu’il accède aux informations de l’appareil final) ; Einwilligungsverwaltungsverordnung (EinwV) approuvée par le Bundesrat le 20 décembre 2024, effective le 1 avril 2025 ; BGH I ZR 7/16 Planet49 du 28 mai 2020 ; CJUE C-673/17 Planet49 du 1 octobre 2019 (ECLI:EU:C:2019:801) ; CJUE C-582/14 Breyer du 19 octobre 2016 (ECLI:EU:C:2016:779) ; CJUE C-621/22 KNLTB du 4 octobre 2024 (ECLI:EU:C:2024:857) ; lignes directrices 2/2023 v2.0 du CEPD du 7 octobre 2024 ; lignes directrices 1/2024 du CEPD du 8 octobre 2024 ; projet de lignes directrices 01/2025 du CEPD sur la pseudonymisation (adopté en projet le 16 janvier 2025 ; version finale non encore publiée à la date de mai 2026) ; Avis conjoint CEPD-CEPD 2/2026 du 11 février 2026 sur le Digital Omnibus ; avis 5/2019 du CEPD. Application continue 2024-2026 du § 25 TDDDG par BayLDA / NRW LDI / BlnBDI / HmbBfDI contre les déploiements GA4 / Meta Pixel / Hotjar sans consentement.