DSAR sans drame : droit d'accès et droit à l'effacement dans le traceur

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

Les articles 15 et 17 s’appliquent à l’analyse web — les identifiants pseudonymes comme les IP hachées, les identifiants de cookies et les signatures de visiteur BLAKE3-HMAC restent des données à caractère personnel selon la ligne Breyer, IAB Europe et l’arrêt de la Cour d’appel de Bruxelles du 14 mai 2025.
Trois points d’accès livrés — POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase — tous protégés par CSRF, à débit limité et journalisés dans le journal d’audit.
Les tables de rollup survivent à l’effacement car elles ont déjà été agrégées au-delà du point d’identifiabilité — les esquisses HyperLogLog uniqCombined64 sont des comptages, pas des enregistrements, et les contributions individuelles ne peuvent pas être inversées.
8 événements d’audit de confidentialité émettent une preuve de redevabilité structurée au sens de l’article 28(3)(h) — couvrant l’opt-out, l’accès, l’effacement, le consentement donné/retiré et la consultation des pages légales.
L’objectif d’application coordonné du CEPD 2025 était le droit à l’effacement dans le cadre coordonné ; l’objectif du CEPD 2026 se déplace vers les obligations de transparence. Les deux s’alignent sur l’architecture décrite dans cet article.

Pourquoi l’analyse web est la surface DSAR la plus oubliée

La plupart des flux de traitement des demandes d’accès au titre du RGPD sont construits autour des systèmes où les données à caractère personnel résident manifestement — le CRM, les tickets d’assistance, l’historique des commandes, les listes d’envoi de courriels. La pile d’analyse web est généralement une réflexion après-coup, et lorsqu’elle est évoquée, le premier réflexe de l’opérateur est souvent : « il n’y a pas de données à caractère personnel là-dedans, nous avons haché les IP ». Ce réflexe est faux en droit et de plus en plus faux d’un point de vue architectural.

Le projet de lignes directrices 01/2025 du CEPD sur la pseudonymisation — adopté en projet lors de la 101ᵉ plénière du 16 janvier 2025, ouvert à consultation publique jusqu’au 28 février 2025 et toujours en développement à la date de mai 2026 — précise que les données pseudonymisées, y compris les IP hachées, les identifiants de cookies, les signatures de visiteur BLAKE3/HMAC et les chaînes TC, restent des données à caractère personnel lorsqu’une ré-identification est raisonnablement probable par des moyens disponibles pour le responsable de traitement ou tout tiers. L’arrêt IAB Europe de la CJUE (C-604/22, 7 mars 2024), confirmé par l’arrêt de la Cour d’appel de Bruxelles du 14 mai 2025 (affaire 2022/AR/292), étend cette analyse au-delà des chaînes TC à tout identifiant associé à une IP. Breyer (C-582/14, 19 octobre 2016) avait réglé la question de l’IP côté opérateur bien plus tôt.

Concrètement, cela signifie que l’analyse web qui traite des IP, des cookies hachés, des signatures de visiteur BLAKE3-HMAC ou tout identifiant par visiteur traite des données à caractère personnel au sens du RGPD. Les articles 15 (droit d’accès) et 17 (droit à l’effacement) s’appliquent. L’article 28(3)(e) impose au sous-traitant — s’il y en a un — d’assister le responsable de traitement dans ces demandes. L’horloge de notification des violations au titre de l’article 33 inclut les violations affectant ces identifiants.

L’article qui suit est le mode d’emploi de l’opérateur. L’anatomie d’une DSAR d’analyse web, les trois points d’accès que Statnive Live livre, le journal d’audit requis, comment les rollups survivent à l’effacement, un runbook DSAR à l’usage des développeurs et un exemple de code fonctionnel.

Anatomie d’une DSAR d’analyse web

Une DSAR contre une pile d’analyse web ne ressemble pas à une DSAR contre un CRM. Il n’y a pas d’adresse e-mail, pas de nom de client, pas de clé primaire évidente. La personne concernée vous contacte et dit, en substance : « je visite parfois votre site. Qu’avez-vous sur moi, et veuillez supprimer ces données. »

Que possède réellement l’opérateur ?

Pour une pile d’analyse web first-party sans cookies comme Statnive Live en mode consent-free, la réponse est : une signature pseudonyme à portée quotidienne dérivée de l’IP du visiteur, du User-Agent, de la portée du site et d’un sel quotidien-rotatif détruit en fin de journée. L’architecture est décrite en détail dans le Manuel 2026 de l’analyse web sans consentement dans l’UE. La signature de la journée existe dans la table des événements bruts jusqu’à la rotation du sel à 00:00 UTC suivant ; après rotation, la signature devient effectivement irréversible car le sel qui l’a produite a disparu. Les rollups agrègent cette signature en comptages avant la rotation du sel, de sorte que l’identifiant par visiteur n’est pas présent dans les tables de rollup — uniquement des comptages de visiteurs uniques par jour, page ou source.

Pour un déploiement Statnive Live en mode consent-required ou hybrid avec consentement donné, un identifiant de cookie est en outre émis vers le navigateur (un UUID brut). Le serveur stocke SHA-256(master_secret || site_id || cookieID) avec un préfixe h: comme clé de persistance. La continuité du visiteur entre les jours est préservée par l’identifiant de cookie haché plutôt que par le sel quotidien-rotatif.

Trois choses en découlent :

Article 15 — droit d’accès. La personne concernée peut fournir à l’opérateur quelque chose à rechercher — typiquement l’identifiant de cookie depuis son navigateur (s’il existe dans sa session actuelle) ou une description de sa visite (date, page, heure approximative, IP depuis un réseau connu). L’opérateur peut retourner les événements correspondants.
Article 17 — droit à l’effacement. L’opérateur peut localiser les mêmes événements et les supprimer. Les enregistrements que l’opérateur peut identifier sont les enregistrements qu’il peut effacer.
Ce qui ne peut pas être identifié ne peut pas être effacé — et ne peut pas non plus être conservé. La destruction quotidienne du sel à 00:00 UTC est un effacement contemporain et automatique de la capacité de ré-identification d’un jour à l’autre. La signature de session-jour-1 d’un visiteur est définitivement dissociée de sa signature de session-jour-2 dès que le sel du Jour 1 est détruit ; une demande au titre de l’article 17 parvenant à l’opérateur le Jour 2 ne peut pas demander la suppression des enregistrements du Jour 1 parce qu’ils ne peuvent pas être localisés, mais cela ne pose pas de problème car ils ne sont plus ré-identifiables.

L’architecture est conçue de sorte que la conservation en régime permanent de données identifiables soit faible. La rotation du sel fait gratuitement la plus grande partie du travail de minimisation des données au titre de l’article 5(1)(c) RGPD. Les demandes DSAR contre une pile d’analyse web architecturée ainsi sont intrinsèquement moins volumineuses que celles contre un CRM — la plupart des visiteurs ne laissent aucun enregistrement par visiteur dès que le sel tourne.

Les trois points d’accès

Statnive Live livre trois points d’accès de confidentialité par défaut. Tous trois sont protégés par CSRF, à débit limité et émettent des événements d’audit structurés.

POST /api/privacy/opt-out

Le point d’accès du droit d’opposition au titre de l’article 21. Un visiteur l’appelle depuis un bouton dans la politique de confidentialité de l’opérateur. Le serveur enregistre l’opt-out sous la forme d’un cookie strictement nécessaire exprimant le choix de l’utilisateur (autorisé au titre de l’ePrivacy § 25(2)(ii) / TDDDG / transpositions nationales équivalentes parce qu’il met en œuvre la préférence de service expressément demandée par l’utilisateur). Les requêtes d’ingest ultérieures depuis le même navigateur sont rejetées au niveau de la couche d’ingest avant le calcul de la signature du visiteur.

Alternativement, l’opt-out peut être persisté côté serveur via une liste de suppression indexée sur la signature hachée du visiteur avec un TTL adéquat — le choix est configurable par l’opérateur.

Le point d’accès émet l’événement d’audit privacy.opt_out_received avec l’horodatage, l’ID du site et un hachage de la signature du visiteur pour recoupement avec le journal d’audit.

GET /api/privacy/access

Le point d’accès du droit d’accès au titre de l’article 15. Le visiteur fournit :

L’identifiant de cookie actuellement stocké dans son navigateur (le cas échéant), ou
Un identifiant pré-partagé signé (pour les opérateurs intégrant leur propre portail DSAR), ou
Une description de sa visite suffisamment précise pour que l’opérateur puisse la localiser (date, page, heure approximative, réseau source).

Le point d’accès retourne les événements en fichier. La réponse est un objet JSON contenant les événements bruts correspondant à la recherche, plus les métadonnées dérivées du rollup qui touchent le visiteur (à quels seaux de rollup sa visite a contribué, sans divulguer les autres visiteurs dans le même seau). Événement d’audit : privacy.dsar_access_requested.

POST /api/privacy/erase

Le point d’accès du droit à l’effacement au titre de l’article 17. La recherche est la même que pour l’article 15. Le point d’accès énumère dynamiquement les tables du backend de stockage — via une introspection system.tables sur ClickHouse — et supprime les lignes correspondantes de toutes les tables possédant une colonne visitor_signature ou cookie_id_hash. L’énumération dynamique est intentionnelle : une future table ajoutée au schéma échoue en mode fermé si elle porte un identifiant de visiteur mais n’est pas ajoutée au chemin d’effacement, car le test d’intégration qui valide l’énumération dynamique couvre toutes les tables que le schéma connaît.

Les rollups agrégés ne sont pas supprimés. La raison — et c’est la raison correcte au titre du RGPD — est dans la section suivante. Événement d’audit : privacy.dsar_erase_requested.

Les trois points d’accès rejettent les requêtes cross-origin non signées, exigent un jeton CSRF dérivé de la session de l’opérateur et limitent le débit par IP et par tuple (IP, site_id) pour prévenir les abus. Le journal d’audit est séparé de la base de données d’analyse et conservé selon la politique de rétention du journal d’audit de l’opérateur — typiquement plus longtemps que la fenêtre de rollup analytique de 25 mois.

Pourquoi les rollups survivent à l’effacement — et pourquoi c’est correct

La partie la plus contre-intuitive de la conception d’une DSAR analytique est la survie des tables de rollup agrégées à une demande d’effacement au titre de l’article 17. La première réaction est généralement : si l’utilisateur veut être supprimé, certainement toutes les données le concernant doivent disparaître, y compris les comptages auxquels il a contribué ?

La réponse dépend de ce que la table de rollup contient réellement. Une ligne dans hourly_visitors enregistre, par exemple : site_id=X, hour=Y, unique_visitors=4271. La ligne ne contient pas la signature du visiteur, l’IP du visiteur ni aucun identifiant par visiteur. Elle contient une esquisse HyperLogLog uniqCombined64 — une structure de données probabiliste qui produit des estimations précises de cardinalité sans stocker les valeurs individuelles. L’esquisse uniqCombined64 est un comptage, pas un enregistrement de qui. La contribution du visiteur au comptage ne peut pas être inversée à partir de l’esquisse.

C’est la position standard du CEPD sur les données agrégées : une fois que des données ont été agrégées au-delà du point d’identifiabilité — au-delà du point où toute contribution individuelle peut être reconstruite — elles ne sont plus des données à caractère personnel. La recommandation de la Fiche 16 de la CNIL d’agréger à la dizaine la plus proche est fondée sur le même principe. L’analyse d’anonymisation du Garante italien dans sa décision Caffeina Media repose sur la question de savoir si la ré-identification est raisonnablement probable ; pour un comptage agrégé dérivé d’une esquisse HyperLogLog, elle ne l’est pas.

L’effet pratique : une demande d’effacement au titre de l’article 17 supprime les lignes d’événements bruts (qui portent la signature par visiteur, la géolocalisation dérivée de l’IP, le référent réduit à l’hôte, la page) mais laisse les tables de rollup intactes. Les tableaux de bord de l’opérateur continuent d’afficher le trafic historique vers la page, mais aucune ligne du tableau de bord ne peut être tracée jusqu’à la personne concernée qui a demandé l’effacement.

C’est décrit dans la politique de confidentialité de l’opérateur sous la forme : « agrégées au-delà du point d’identifiabilité ». C’est le bon libellé — ni surclamation « anonyme » ni sous-claim « toujours des données à caractère personnel ». Les rollups sont l’état stable correct au titre du RGPD pour la conservation analytique.

Le plafond de 25 mois sur le TTL du rollup (750 jours, via la migration 011_rollup_ttl.sql) s’applique quoi qu’il en soit. Même les comptages agrégés expirent automatiquement selon le calendrier de la Fiche 16 de la CNIL.

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. Ces événements sont la preuve de redevabilité de l’article 28(3)(h) pour un audit par le DPO de l’opérateur, l’auditeur du responsable de traitement, ou une autorité de protection des données :

Événement	Déclencheur	Objectif
`privacy.opt_out_received`	`POST /api/privacy/opt-out`	Opposition au titre de l’article 21 enregistrée
`privacy.dsar_access_requested`	`GET /api/privacy/access`	Demande au titre de l’article 15 initiée
`privacy.dsar_erase_requested`	`POST /api/privacy/erase`	Demande au titre de l’article 17 initiée
`privacy.consent_given`	`statnive.acceptConsent()`	Consentement accordé en mode `consent-required` / `hybrid`
`privacy.consent_withdrawn`	`statnive.withdrawConsent()`	Consentement révoqué
`legal.lia_viewed`	`GET /legal/lia`	Page LIA de l’opérateur servie
`legal.dpa_viewed`	`GET /legal/dpa`	Page DPA de l’article 28 servie
`legal.privacy_policy_viewed`	`GET /legal/privacy-policy/{lang}`	Page de politique de confidentialité servie

Chaque événement est du JSON structuré avec horodatage, ID du site, ID de requête et l’empreinte pertinente. Le journal d’audit est séparé de la base de données d’analyse — il ne fait pas l’objet d’un rollup, n’expire pas au TTL analytique de 25 mois et est conservé selon la politique du journal d’audit de l’opérateur (typiquement plus longtemps, souvent indéfiniment comme preuve de conformité).

Le journal d’audit est ce que l’opérateur remet à un régulateur lors d’une inspection. La politique de confidentialité est la position publique ; les événements d’audit sont la preuve contemporaine que la position a été réellement mise en œuvre. Le pack de réponse à une inspection de la CNIL comprend typiquement (a) la LIA, (b) la politique de confidentialité, (c) le journal d’audit pour la fenêtre d’inspection, et (d) la sortie du point d’accès d’audit d’événements (le contrôle du plafond de 3 événements pour les déploiements français). Statnive Live produit les quatre prêts à l’emploi.

Runbook DSAR pour les opérateurs

Un runbook fonctionnel pour traiter une DSAR contre un déploiement Statnive Live :

Étape 1 : identifier la demande. La personne concernée vous contacte, typiquement par e-mail à l’adresse DSAR publiée par le responsable de traitement. La demande doit être suffisamment précise pour que l’opérateur puisse localiser les données — cela signifie typiquement l’identifiant de cookie actuellement dans le navigateur du visiteur (que le visiteur peut inspecter via DevTools) ou une description de la visite suffisamment précise pour identifier la fenêtre d’événements.

Étape 2 : vérifier l’identité du demandeur. L’article 12(6) du RGPD permet au responsable de traitement de demander une identification supplémentaire lorsque cela est raisonnablement nécessaire pour vérifier l’identité de la personne concernée. Pour les demandes analytiques, la preuve tend à être : le contrôle de l’identifiant de cookie (le visiteur envoie une capture d’écran de DevTools montrant le cookie), ou le contrôle de l’IP depuis laquelle le visiteur a visité (une connexion authentifiée depuis la même IP, ou un défi de rappel). L’opérateur ne devrait pas exiger plus d’identification que nécessaire pour vérifier la demande.

Étape 3 : exécuter la requête d’accès. L’opérateur appelle GET /api/privacy/access avec l’identifiant de recherche. La réponse contient les événements correspondants. Si la demande est une demande d’accès au titre de l’article 15, c’est la réponse à envoyer à la personne concernée — formatée en CSV, JSON ou PDF, selon la préférence du portail DSAR de l’opérateur.

Étape 4 : exécuter l’effacement (si demandé). L’opérateur appelle POST /api/privacy/erase avec le même identifiant de recherche. Le point d’accès supprime les lignes correspondantes de toutes les tables ayant un identifiant de visiteur ; les tables de rollup restent intactes (selon la section précédente). Le point d’accès retourne un comptage des lignes supprimées par table.

Étape 5 : confirmer à la personne concernée. L’article 12(3) du RGPD accorde jusqu’à un mois pour répondre, prolongeable de deux mois supplémentaires pour les demandes complexes. La réponse de l’opérateur devrait :

Confirmer que les données ont été localisées et (si l’effacement a été demandé) supprimées.
Décrire ce qui a été conservé — les agrégats de rollup — et pourquoi ce ne sont pas des données à caractère personnel.
Mentionner la conservation du journal d’audit de l’opérateur (le fait que la demande DSAR elle-même a été journalisée).

Étape 6 : journaliser la réponse. Les événements d’audit Statnive Live ont été émis automatiquement lorsque l’opérateur a appelé les points d’accès de l’API. L’opérateur devrait également journaliser la réponse envoyée à la personne concernée dans son système plus large de traitement DSAR (typiquement le help-desk ou DPMS).

L’ensemble du runbook tient sur une liste de contrôle d’une demi-page. La plupart des opérateurs qui le mettent en œuvre pour la première fois s’inquiètent que la DSAR analytique sera difficile ; en pratique, l’architecture est conçue de sorte que les données existent dans une fenêtre étroite et bien définie ou n’existent pas du tout. Le volume est faible, les requêtes sont bornées et la forme de la réponse est standardisée.

Un exemple d’intégration fonctionnel

Pour les opérateurs intégrant leur propre portail DSAR avec Statnive Live, le motif suivant fonctionne de bout en bout :

// Triggered from a DSAR portal after identity verification
async function handleAccessRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
    {
      method: 'GET',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
      },
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR access failed: ${response.status}`);
  }
  const { events, rollup_metadata } = await response.json();
  return { events, rollup_metadata };
}

async function handleErasureRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/erase`,
    {
      method: 'POST',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        site_id: SITE_ID,
        cookie_id: verifiedRequest.cookieId,
      }),
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR erasure failed: ${response.status}`);
  }
  const { rows_deleted_by_table } = await response.json();
  return { rows_deleted_by_table };
}

La clé opérateur est rotée selon la politique de rotation des secrets de l’opérateur. Le jeton CSRF est dérivé de la session de l’opérateur dans le cadre du flux d’authentification administrateur standard de Statnive Live.

Ce que change un déploiement auto-hébergé

Pour les opérateurs exécutant Statnive Live en tant que déploiement auto-hébergé — le binaire s’exécutant sur l’infrastructure propre de l’opérateur — l’analyse responsable de traitement/sous-traitant change. Statnive n’est plus du tout sous-traitant des données analytiques de l’opérateur ; l’opérateur est le seul responsable de traitement. Il n’y a pas de DPA Statnive ↔ opérateur à signer car il n’y a rien dont Statnive serait sous-traitant.

Les points d’accès DSAR fonctionnent à l’identique sur un binaire auto-hébergé et sur un déploiement Statnive Live SaaS hébergé. Les événements d’audit s’émettent vers le puits de logs choisi par 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). L’exemple d’intégration ci-dessus fonctionne de la même manière contre le propre point d’accès de l’opérateur.

Ce qui diffère : la réponse du responsable de traitement à une demande au titre de l’article 15 émanant d’une personne concernée tierce est uniquement la réponse du responsable de traitement. Il n’y a pas de sous-traitant Statnive pour assister ; l’équipe IT de l’opérateur est le répondeur DSAR de l’opérateur.

C’est l’un des compromis couverts dans le post auto-hébergement vs SaaS européen privé. Pour les opérateurs ayant des postures strictes de non-implication de tiers avec les données (secteurs réglementés, environnements air-gapped), la forme auto-hébergée est la réponse propre ; pour les opérateurs ayant des postures strictes d’accord signé de sous-traitant (questionnaires fournisseur ISO 27001, gros achats), la forme SaaS avec un DPA au titre de l’article 28 est la réponse propre. L’architecture DSAR fonctionne de la même façon dans les deux cas.

Ce que cela apporte à l’opérateur

Le résultat pratique :

Un pack de réponse DSAR propre prêt pour toute demande au titre de l’article 15 / 17 contre la couche analytique. Trois points d’accès, huit événements d’audit, un runbook et un exemple d’intégration.
Une réponse défendable sur la survie des rollups. Le langage « agrégées au-delà du point d’identifiabilité » est la position alignée sur le CEPD ; le TTL de rollup de 25 mois s’applique de toute façon.
Une piste de redevabilité qui s’aligne sur l’assistance d’audit de l’article 28(3)(h) pour les relations de sous-traitance et le principe plus large de redevabilité de l’article 5(2) pour les propres registres du responsable de traitement.
Une compatibilité ascendante avec les attentes de droits des personnes concernées de l’article 88a du Digital Omnibus. Le texte actuel ne change pas les obligations substantielles des articles 15 et 17 ; les points d’accès DSAR fonctionnent sans changement.

Ce que cela n’apporte pas : un moyen de conserver des données brutes par visiteur au-delà de la fenêtre de rollup de 25 mois, car la destruction du sel rend cela impossible. Un moyen d’« annuler » une demande de suppression, car les suppressions sont irréversibles. Un moyen de contourner le journal d’audit pour les demandes « internes », car il n’y a pas de demandes internes — chaque appel aux trois points d’accès émet un événement.

Quoi faire, et quoi éviter

À faire	À éviter
Traiter les identifiants de visiteur hachés comme des données à caractère personnel à faible risque ; honorer les articles 15, 17 et 21 à leur égard.	Présenter les identifiants hachés comme « anonymes » — pseudonyme est le mot juridiquement correct ; la Cour de Bruxelles l’a confirmé le 14 mai 2025.
Câbler les trois points d’accès de confidentialité (`/api/privacy/opt-out`, `/api/privacy/access`, `/api/privacy/erase`) avec protection CSRF, limitation de débit et journal d’audit.	Construire un gestionnaire DSAR ponctuel qui contourne les journaux d’audit — la redevabilité de l’article 28(3)(h) est le pack de preuves dont vous avez besoin lors d’une inspection.
Décrire la survie des tables de rollup au titre de l’article 17 comme « agrégées au-delà du point d’identifiabilité » — ni surclamation « anonyme » ni sous-claim « données à caractère personnel ».	Supprimer les lignes des tables de rollup en réponse à une demande au titre de l’article 17 — ce sont des comptages agrégés, pas des enregistrements par visiteur, et vous perdriez la visibilité historique du trafic sans bénéfice RGPD.
Vérifier l’identité du demandeur selon l’article 12(6) RGPD — typiquement par contrôle de l’identifiant de cookie ou un défi de rappel — avant d’exécuter la requête d’accès / d’effacement.	Exiger plus d’identification que nécessaire ; les lignes directrices 01/2022 du CEPD sur le droit d’accès sont explicites sur le fait que les abus de demande mettent en échec le droit.
Documenter le runbook + journaliser chaque événement d’audit de confidentialité — l’objectif CEF du CEPD 2025 était le droit à l’effacement, l’objectif CEF du CEPD 2026 est la transparence.	Traiter la gestion DSAR comme du travail opérationnel ponctuel — l’application coordonnée des APD est active, et un journal d’audit contemporain est la bonne réponse.

La conclusion

Le droit d’accès et le droit à l’effacement au titre des articles 15 et 17 du RGPD s’appliquent à l’analyse web. Les lignes directrices 01/2025 du CEPD, les arrêts CJUE Breyer et IAB Europe et la position cohérente des régulateurs nationaux le confirment tous. La décision d’architecture est de savoir quoi en faire — et la réponse est de rendre la fenêtre de données par visiteur petite (rotation quotidienne du sel), de borner la fenêtre de rollup (TTL de 25 mois), d’exposer trois points d’accès (opt-out, accès, effacement), d’émettre huit événements d’audit et de documenter la position dans la politique de confidentialité.

Statnive Live livre cette surface par défaut. Les opérateurs intègrent contre elle ; le journal d’audit capture la preuve contemporaine ; les tables de rollup survivent à l’effacement car elles ont déjà été agrégées au-delà de l’identifiabilité. Le drame DSAR, lorsqu’il arrive, est procédural — une horloge d’un mois, une étape de vérification, un appel d’API, un e-mail de confirmation — pas architectural.

Pour le cadre plus large de la confidentialité, voir le Manuel 2026 de l’analyse web sans consentement dans l’UE. Pour expliquer pourquoi le sel quotidien-rotatif rend l’architecture intrinsèquement minimale, voir la carte pays par pays. Pour comprendre comment les mêmes événements d’audit alimentent l’intégration GPC et mode hybride, voir le post associé. La surface DSAR est le tissu conjonctif entre les quatre.

Il s’agit de recherche sur la vie privée, et non d’un conseil juridique. Les points d’accès DSAR décrits sont des fonctionnalités de disponibilité technique. La correction juridique de toute réponse à une demande au titre des articles 15 / 17 / 21 relève de la responsabilité du responsable de traitement au titre de l’article 12 du RGPD et de la législation nationale applicable. Chaque client de Statnive demeure le responsable de traitement et porte la responsabilité de sa propre configuration et AIPD. À recouper avec un conseil qualifié dans votre juridiction avant publication.

Statut des références réglementaires au 13 mai 2026 : articles 12, 15, 17, 21, 28(3)(e), 28(3)(h) et 33 du RGPD ; lignes directrices 01/2022 du CEPD sur le droit d’accès (version finale adoptée en mars 2023) ; CJUE C-582/14 Breyer du 19 octobre 2016 (ECLI:EU:C:2016:779) ; CJUE C-604/22 IAB Europe du 7 mars 2024 ; arrêt de la Cour d’appel de Bruxelles du 14 mai 2025 dans l’affaire 2022/AR/292 (confirme la ligne IAB Europe / chaîne TC) ; projet de lignes directrices 01/2025 du CEPD sur la pseudonymisation (adopté en projet lors de la 101ᵉ plénière du 16 janvier 2025 ; consultation publique jusqu’au 28 février 2025 ; version finale non encore publiée à la date de mai 2026 ; l’équipe sprint du CEPD vise l’achèvement à l’été 2026) ; lignes directrices 1/2024 du CEPD sur l’intérêt légitime du 8 octobre 2024 ; objectif du cadre d’application coordonné CEPD 2025 : droit à l’effacement (article 17) ; objectif du cadre d’application coordonné CEPD 2026 : obligations de transparence et d’information (articles 13/14) ; directive ePrivacy 2002/58/CE (en vigueur) et ses transpositions nationales, dont le § 25 TDDDG (Allemagne) et l’article 82 Loi 78-17 (France).