L’EDPB change surtout le niveau de preuve attendu. Une donnée analytics n’est anonyme que si la ré-identification devient réalistement insignifiante, selon le contexte. Je vous explique ce que ça change pour vos IP, cookies, exports, segments et dashboards.
Qu’est-ce qui change vraiment ?
Le vrai changement, pour moi, c’est que l’anonymisation n’est plus traitée comme une recette technique, mais comme un test de résultat contextualisé. On ne dit plus “j’ai supprimé le nom, l’email et l’ID client, donc c’est anonyme”. On doit se demander si, dans ce contexte précis, quelqu’un peut raisonnablement retrouver une personne derrière les données.
Les Guidelines 02/2026 de l’EDPB, adoptées le 7 juillet 2026 et mises en consultation publique, vont dans ce sens. Elles remettent l’anonymisation dans la logique du RGPD, surtout celle du considérant 26. Ce considérant dit, en gros, qu’il faut regarder les moyens “raisonnablement susceptibles” d’être utilisés pour identifier une personne. Pas les moyens de la NSA dans un film. Pas non plus une vision naïve où personne ne croise jamais rien.
Une donnée est donc anonyme seulement si la probabilité réaliste de ré-identifier quelqu’un est insignifiante. Insignifiante ne veut pas dire mathématiquement nulle. Ça veut dire tellement faible, dans les conditions réelles d’usage, qu’on ne considère plus la donnée comme personnelle.
🚀 Maîtrisez les outils Web Analytics et optimisez votre croissance dès aujourd’hui
Transformez vos données en leviers de performance ! Nos formations en Web Analytics vous permettent de mesurer, analyser et perfectionner l’expérience utilisateur de votre site avec précision. De Google Tag Manager à Piwik Pro, en passant par Matomo Analytics et Google Analytics 4, nous vous guidons à chaque niveau pour une maîtrise complète des outils essentiels. Apprenez à structurer vos données, affinez votre stratégie digitale et prenez des décisions basées sur des insights fiables. Ne laissez plus vos performances au hasard : formez-vous et passez à l’action dès maintenant !
Et c’est là que ça devient très concret en analytics. Le niveau d’anonymat dépend du destinataire, de ses données annexes, de ses capacités techniques, de son accès à d’autres sources et de l’usage prévu. Le même export agrégé peut être anonyme pour une équipe marketing qui reçoit juste des statistiques globales, sans CRM, sans logs, sans historique utilisateur. Mais ce même export peut rester risqué pour une équipe data qui peut le croiser avec un CRM, des logs serveur, des parcours utilisateurs détaillés ou des événements très fins.
J’ai vu ça plusieurs fois chez des clients. Le sujet bloque rarement sur le nom ou l’email. Tout le monde sait les enlever. Le vrai sujet, c’est plutôt ce qu’on peut reconstruire en croisant trois sources qui, séparément, semblaient propres.
La tolérance au risque devient donc très basse. Pas théorique. Très opérationnelle. Et ça nous amène directement aux identifiants techniques, ceux qu’on sous-estime souvent en analytics : l’adresse IP, les cookies, les identifiants publicitaires et les empreintes navigateur.
Pourquoi supprimer l’IP ne suffit pas ?
Supprimer l’IP, les cookies ou les noms enlève les identifiants directs, oui. Mais ça ne supprime pas forcément la capacité d’isoler une personne, de relier sa visite à une autre source, ou de déduire quelque chose de significatif sur elle.
Un identifiant évident, c’est simple à repérer. Une adresse email, un nom, un numéro client, une IP complète, un cookie unique. On sait tout de suite que ça pointe vers quelqu’un.
Les signaux indirects sont plus discrets. Le navigateur, le système d’exploitation, la résolution d’écran, le fuseau horaire, les signaux issus de l’appareil, la structure du parcours, les événements rares, ou même des combinaisons d’attributs très ordinaires. Pris seuls, ils ont l’air banals. Mis ensemble, ils peuvent créer une empreinte assez distinctive.
Un exemple simple. Un rapport analytics contient la ville, l’heure de visite, le type d’appareil, la page consultée et un événement de conversion. Rien ne ressemble à un nom. Pourtant, si une seule personne d’une petite ville visite une page très spécifique à 23h42 depuis un iPhone récent et déclenche une demande de devis, on commence à isoler quelqu’un dans le dataset.
| Isoler | Retrouver un visiteur unique ou quasi unique dans les données, même sans connaître son nom. |
| Relier | Rapprocher ce visiteur d’une autre source, par exemple un CRM, un email de campagne, un log serveur ou un outil support. |
| Inférer | Déduire une information personnelle, comme un intérêt santé, une difficulté financière, une intention d’achat ou un contexte professionnel sensible. |
Le risque ne vient pas seulement de chaque colonne. Il vient de la forme globale du jeu de données. C’est l’assemblage qui compte. Une ville assez précise, une heure exacte, une page rare, un appareil reconnaissable, un événement très spécifique, et le niveau d’anonymisation devient beaucoup moins solide.
Dans les audits analytics, je vois souvent des setups où l’IP est bien masquée. Mais les événements, les paramètres d’URL, les user agents ou les IDs internes racontent encore trop de choses. Le user agent, c’est la chaîne technique envoyée par le navigateur avec des infos sur l’appareil et le logiciel utilisé. C’est rarement “personnel” en apparence, mais combiné au reste, ça peut devenir très parlant.
C’est exactement pour ça que l’EDPB remet au centre trois critères simples à tester sérieusement : est-ce qu’on peut isoler, relier ou inférer ?
Quels sont les trois tests EDPB ?
Les trois tests sont No Record Isolation, No Linkage et No Inference, et les trois doivent être satisfaits pour considérer les données comme anonymes. C’est le point qui change vraiment la lecture côté analytics. On ne peut pas dire “c’est bon, j’ai supprimé l’email” et passer à autre chose.
No Record Isolation, ou absence d’isolement, veut dire qu’on ne doit pas pouvoir isoler un enregistrement lié à une personne. En analytics, le cas classique, c’est le parcours unique dans une période donnée. Une personne visite une page très rare, revient trois fois depuis la même ville, clique sur un bouton précis, puis convertit à 23h47. Même sans nom, ce parcours peut devenir reconnaissable. J’ai déjà vu ça chez un client B2B avec peu de trafic sur certaines pages produit. Les identifiants avaient été retirés, mais certains chemins utilisateurs restaient quasiment uniques.
No Linkage, ou absence de rattachement, veut dire qu’on ne doit pas pouvoir relier ces données à d’autres sources identifiantes. Là, on pense au CRM, aux logs serveur, à l’outil emailing ou au support client. Si un export analytics contient un horodatage précis, une campagne email, une page visitée et une conversion, il peut parfois être recroisé avec une ouverture email ou un ticket support. Le problème n’est pas seulement le fichier analytics. Le problème, c’est l’écosystème autour.
No Inference, ou absence de déduction, veut dire qu’on ne doit pas pouvoir déduire des informations personnelles significatives. Un segment ou un événement peut révéler une intention, une situation ou un comportement sensible selon le contexte. Une visite sur une page “résiliation”, “problème de paiement”, “recrutement handicap” ou “traitement médical” n’a pas la même portée qu’une visite sur une page catalogue.
Il faut vraiment voir ces critères comme cumulatifs. Réussir un seul test ne suffit pas. Même deux tests validés ne rendent pas automatiquement le dataset anonyme.
| Critère | Question à se poser | Risque analytics typique |
| No Record Isolation | Est-ce qu’un parcours ou un événement permet d’isoler une personne ? | Parcours unique sur une période donnée |
| No Linkage | Est-ce que ces données peuvent être croisées avec une autre source ? | Rapprochement avec CRM, logs, emailing ou support |
| No Inference | Est-ce qu’on peut déduire une information personnelle significative ? | Segment ou événement révélant une intention ou une situation sensible |
Ces tests obligent à regarder le dataset complet, pas juste une colonne. Il faut aussi regarder la durée de conservation, les accès, les exports, les destinataires et les croisements possibles. C’est moins confortable, mais c’est beaucoup plus réaliste.
Comment adapter votre setup analytics ?
Il faut traiter l’anonymisation comme une preuve à construire, pas comme une case à cocher dans l’outil analytics.
Je commencerais par mettre à plat ce qui entre, ce qui sort, et qui peut voir quoi. C’est moins sexy qu’un nouveau tag, mais c’est là que tout se joue. Je cartographie les données collectées, les identifiants directs comme un email ou un user ID, les signaux indirects comme l’IP, le device, la géolocalisation, le navigateur, les pages vues très spécifiques, puis les destinations. Outil analytics, CRM, data warehouse, exports CSV, dashboard BI, agence média, équipe produit. Tout compte.
Je regarde aussi les durées de conservation et les personnes ou systèmes qui accèdent aux exports. Un dataset peut sembler anonyme dans Google Analytics, mais redevenir très parlant une fois croisé avec un export CRM ou des logs serveur. C’est exactement là que les trois tests EDPB deviennent utiles : est-ce qu’on peut isoler une personne, relier plusieurs traces entre elles, ou déduire une information sur quelqu’un. Et je le fais par destinataire, pas seulement en théorie dans mon coin.
Dans un setup analytics, les leviers pratiques sont assez concrets :
- Réduire les paramètres collectés, surtout ceux qui ne servent jamais aux décisions.
- Éviter les IDs persistants quand une mesure de session ou de campagne suffit.
- Limiter les dimensions trop fines, comme une URL avec email, numéro client ou recherche interne sensible.
- Agréger certains rapports quand le détail utilisateur n’apporte rien.
- Raccourcir la conservation des données brutes.
- Contrôler les exports, surtout les fichiers partagés hors outil.
- Documenter les choix, les hypothèses et les tests de ré-identification.
- Séparer les usages quand certains jeux de données restent personnels.
L’anonymisation peut très bien cohabiter avec le consentement, la minimisation, la pseudonymisation ou des règles d’accès. Mais elle ne remplace pas une gouvernance propre. Chez les clients, les meilleurs setups que je vois ne cherchent pas à tout garder “au cas où”. Ils gardent ce qui sert vraiment aux décisions business. Et bizarrement, les dashboards deviennent souvent meilleurs.
| Type de donnée | Usage typique | Niveau de vigilance |
| Donnée brute | Debug, attribution fine, analyse ponctuelle | Très élevé, accès limité et conservation courte |
| Donnée pseudonymisée | Analyse parcours, cohortes, activation contrôlée | Élevé, risque de recoupement à tester |
| Donnée anonymisée | Reporting agrégé, tendances, pilotage business | Modéré, preuve d’anonymisation à maintenir |
Alors, vos données analytics sont vraiment anonymes ?
La logique EDPB 2026 remet les choses à plat : une donnée analytics n’est pas anonyme parce qu’on a supprimé l’IP ou le cookie. Elle l’est si, dans son contexte réel, personne ne peut raisonnablement isoler, relier ou déduire une information personnelle significative. C’est plus exigeant, mais aussi plus sain. Ça oblige à regarder les datasets comme ils vivent vraiment : exports, croisements, conservation, accès internes, usages business. Mon conseil simple : partez des risques de ré-identification, pas des réglages d’outil. Le bénéfice pour vous, c’est un analytics plus robuste, plus propre, et plus défendable.
FAQ
- Une donnée anonymisée reste-t-elle soumise au RGPD ?
Si l’anonymisation est réelle, la donnée ne permet plus d’identifier une personne par des moyens raisonnablement susceptibles d’être utilisés. Elle sort alors de la logique des données personnelles. Le point dur, c’est justement de prouver que le risque réaliste de ré-identification est insignifiant. - Quelle différence entre anonymisation et pseudonymisation ?
La pseudonymisation remplace ou masque certains identifiants, mais une ré-identification reste possible avec une clé, une table de correspondance ou des données complémentaires. L’anonymisation va plus loin : il ne doit plus être réaliste d’isoler, relier ou inférer une personne dans le contexte d’usage. - Masquer les adresses IP suffit-il pour anonymiser Analytics ?
Non. Masquer l’IP réduit le risque, mais d’autres signaux peuvent rester identifiants en combinaison : navigateur, système, résolution d’écran, fuseau horaire, événements rares, parcours détaillé ou paramètres d’URL. L’EDPB demande de regarder la structure complète des données. - Quels sont les trois critères à vérifier ?
Les trois critères sont No Record Isolation, No Linkage et No Inference. En clair : on ne doit pas pouvoir isoler une personne, relier les données à une autre source identifiante, ni déduire une information personnelle significative. Les trois doivent tenir ensemble. - Par où commencer pour auditer ses données analytics ?
Je commencerais par lister les données collectées, les identifiants directs, les signaux indirects, les exports, les durées de conservation et les destinataires. Ensuite, je testerais chaque jeu de données avec les trois critères EDPB. C’est souvent là qu’on voit ce qu’il faut réduire, agréger ou mieux contrôler.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA en entreprise et SEO/GEO. J’accompagne des équipes data, marketing et produit sur des sujets où la mesure, la conformité et l’efficacité business doivent tenir ensemble. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez remettre à plat votre setup analytics ou automatiser vos contrôles data, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.