Contraintes de confidentialité pour les données analytics liées

Pour les équipes opérant dans l’UE — ou traitant des données de résidents de l’UE — les implications de confidentialité du rapprochement des données analytics avec les enregistrements CRM façonnent l’architecture. La conformité au RGPD affecte ce qui peut être construit, comment le modéliser, et quels signaux doivent être vérifiés avant le traitement.

Les identifiants cookies sont des données personnelles

Le RGPD est explicite à ce sujet. Le considérant 30 du règlement nomme spécifiquement les identifiants en ligne — y compris les cookies — comme données personnelles lorsqu’ils peuvent être utilisés pour identifier une personne physique. Un user_pseudo_id de GA4 est un identifiant basé sur les cookies. Un email haché est pseudonymisé, pas anonyme, et reste soumis aux exigences du RGPD.

Au moment où vous liez un user_pseudo_id à un enregistrement de contact CRM, vous avez créé une activité de traitement qui connecte le comportement de navigation à une personne identifiée. Vous êtes passé de « analytics anonymes » à « profilage comportemental de personnes identifiées ». Ce sont des catégories fondamentalement différentes sous le RGPD, avec des bases légales différentes, des exigences de documentation différentes et des profils de risque différents.

L’exemption de consentement CNIL disparaît

Pour les équipes soumises aux lignes directrices de la CNIL (l’autorité française de protection des données), les implications sont encore plus spécifiques.

La CNIL accorde une exemption au consentement préalable aux cookies d’analytics, mais uniquement si les données génèrent une sortie statistique anonyme et ne sont pas combinées avec d’autres traitements. De nombreux sites européens s’appuient sur cette exemption pour collecter des données GA4 sans bandeau de consentement bloquant l’analytics. L’exemption autorise les cookies uniquement analytics parce que les données restent anonymes — des statistiques de trafic agrégées qui ne peuvent pas identifier des individus.

Si vous liez des cookies analytics avec des données CRM, l’exemption de consentement ne s’applique pas. Le consentement préalable devient obligatoire. Les données analytics ne sont plus anonymes — elles sont associées à une personne connue. Chaque page vue, chaque session, chaque événement de scroll devient une partie du profil comportemental de cette personne.

Ce n’est pas un risque théorique. La CNIL a infligé des amendes combinées dépassant 139 millions d’euros entre décembre 2022 et décembre 2024 pour des violations liées aux cookies. L’application est active et les pénalités sont substantielles.

La chaîne de consentement dans votre architecture

La chaîne d’implémentation pratique connecte votre gestion du consentement à vos modèles de données :

CMP (Consent Management Platform)
  → Google Consent Mode
    → Comportement des cookies GA4
      → Export BigQuery : privacy_info.analytics_storage
        → Modèles de base dbt : filtre sur le statut de consentement
          → Résolution d'identité : seuls les événements consentis participent

Votre plateforme de gestion du consentement alimente les signaux de consentement vers le Google Consent Mode, qui indique à GA4 s’il doit poser des cookies. L’export BigQuery inclut privacy_info.analytics_storage, qui reflète le statut de consentement de l’utilisateur au moment de l’événement.

Vos modèles de base dbt doivent filtrer sur ce champ lors de la construction de modèles Customer 360 qui se lient aux données CRM :

-- Dans base__ga4__events ou un modèle d'identité en aval
WHERE privacy_info.analytics_storage = 'Yes'

Les événements où analytics_storage n’est pas accordé ne doivent pas participer à la résolution d’identité. L’utilisateur n’a pas consenti à ce que son comportement de navigation soit lié à son identité. Traiter ces événements via le pont d’identité viole le consentement que l’utilisateur a donné (ou refusé).

Avec le Consent Mode v2 en mode Avancé, GA4 envoie des pings sans cookies même quand le consentement est refusé. Ces pings apparaissent dans l’export BigQuery mais avec des identifiants limités — pas de valeur cookie user_pseudo_id, pas de ga_session_id. Ils sont conçus pour la modélisation comportementale de Google dans l’interface GA4, pas pour la résolution d’identité au niveau de l’entrepôt.

N’essayez pas de lier ces événements sans cookies aux données CRM. Ils manquent des identifiants nécessaires pour une correspondance déterministe, et utiliser des signaux comportementaux pour tenter une correspondance probabiliste sur des événements avec consentement refusé constituerait une violation de conformité.

Le droit à l’effacement change votre architecture

Quand un client exerce son droit à l’effacement en vertu du RGPD (Article 17), vous devez cascader cet effacement sur chaque table de votre graphe d’identité. Cela signifie :

Le mapping d’identité qui relie leur user_pseudo_id à leur contact CRM doit être supprimé
Tous les modèles en aval contenant leurs DCP — la ligne du Customer 360, les points de contact attribués, les historiques de sessions — doivent soit supprimer soit anonymiser les enregistrements
Les modèles incrémentaux contenant des données historiques avec leurs identifiants doivent être reconstruits

Un pattern deletion_requests

Une approche consiste en une table deletion_requests que vos modèles dbt vérifient à chaque exécution :

-- seed ou source : deletion_requests
-- Colonnes : contact_id, requested_at, processed_at

-- Dans votre modèle Customer 360 :
SELECT
    c.*,
    CASE
        WHEN dr.contact_id IS NOT NULL THEN NULL
        ELSE c.customer__email
    END AS customer__email,
    CASE
        WHEN dr.contact_id IS NOT NULL THEN NULL
        ELSE c.customer__name
    END AS customer__name,
    -- ... mettre en NULL tous les champs de DCP
    dr.contact_id IS NOT NULL AS customer__is_deleted
FROM {{ ref('int__customer__enriched') }} c
LEFT JOIN {{ ref('deletion_requests') }} dr
    ON c.customer_id = dr.contact_id
    AND dr.processed_at IS NULL

Cela met à NULL les champs de DCP dans les modèles en aval quand une demande d’effacement correspondante existe. Les données agrégées non-DCP (nombres de deals, chiffres de revenus) sont préservées pour le reporting métier tout en supprimant les informations identifiantes.

Pour les modèles incrémentaux, la suppression est plus complexe. Un enregistrement mis à NULL dans l’exécution d’aujourd’hui peut encore exister avec des DCP dans la partition d’hier. Options :

Full refresh des modèles affectés après traitement des suppressions (le plus simple, le plus coûteux)
Merge avec suppression utilisant la unique_key — l’exécution incrémentale écrase l’ancien enregistrement avec la version anonymisée
Reconstruction au niveau partition ciblant uniquement les plages de dates où l’utilisateur affecté a des données

Limites de rétention de données CNIL

La CNIL spécifie une durée de vie maximale des cookies de 13 mois et une rétention des données de 25 mois pour les données analytics. Votre mapping d’identité doit respecter ces limites :

-- Filtrer les mappings d'identité sur la fenêtre de rétention
WHERE identified_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 25 MONTH)

Les identités de plus de 25 mois doivent expirer de votre pont d’identité, et les données de navigation associées doivent être anonymisées ou supprimées. Cela empêche votre Customer 360 d’accumuler des profils de navigation historiques dépassant la période de rétention.

Recommandations architecturales

Séparer les chemins consentis et non consentis

Ne filtrez pas le consentement au niveau de la couche mart. Intégrez le filtre de consentement dans la couche de résolution d’identité pour que les événements non consentis n’entrent jamais dans le graphe d’identité :

base__ga4__events (tous les événements, statut de consentement comme colonne)
  ├── int__ga4__analytics_only (non consenti, agrégats anonymes uniquement)
  └── int__ga4__consented_events (événements consentis uniquement)
        → int__identity_resolved (liens vers le CRM)
          → mrt__core__customer_360

Cela rend la frontière de consentement visible dans le DAG. Quiconque examine le projet peut voir exactement où commence la liaison de données personnelles et quels modèles y participent.

Documenter l’activité de traitement

Le RGPD exige de maintenir un Registre des Activités de Traitement (RAT). Votre modèle Customer 360 est une activité de traitement. Documentez :

Finalité : Attribution marketing, analytics clients, analyse des revenus
Base légale : Consentement (pour la liaison cookie-CRM dans l’EEE)
Catégories de données : Comportement de navigation, coordonnées, historique des transactions
Durée de conservation : Conformément aux lignes directrices CNIL ou votre propre politique de rétention des données
Destinataires : Quelles équipes et systèmes accèdent aux données Customer 360

Cette documentation vit en dehors de votre projet dbt (dans les registres de votre DPO), mais référencez-la dans les descriptions de vos modèles pour que les développeurs comprennent le contexte de conformité.

Le compromis métier

Les exigences de consentement signifient que certains visiteurs n’apparaîtront jamais dans votre Customer 360. Dans les marchés à application stricte (France, Allemagne, Italie), les taux de consentement pour les cookies analytics varient typiquement entre 40 % et 70 %. Cela signifie que 30 à 60 % de votre trafic web est invisible pour la résolution d’identité.

Le Customer 360 ne couvre que les clients qui ont consenti au traitement de données qui le rend possible. Un Customer 360 partiel et conforme est préférable à un Customer 360 complet et non conforme.

Pour la portion non consentie, vous pouvez encore construire des analytics agrégées anonymes — patterns de trafic, performance des pages, entonnoirs de conversion — du moment que la sortie reste statistique et ne peut pas identifier des individus. Ces insights agrégés complètent le Customer 360 identifié sans franchir les frontières de consentement.