PII et données personnelles quelle différence ?

La PII est une notion surtout américaine, la donnée personnelle est une notion juridique du RGPD. Les deux parlent d’identification directe ou indirecte, mais pas avec les mêmes conséquences. Le vrai sujet, c’est de savoir quoi classer, quoi protéger, et quoi arrêter de traiter comme anonyme.

Que couvre vraiment la PII ?

La PII couvre toute information qui permet d’identifier une personne, seule ou combinée avec d’autres données. C’est le point important à garder en tête, surtout quand on travaille avec des bases clients, des logs produit, des exports analytics ou des données marketing.

Le terme PII, pour Personally Identifiable Information, est surtout utilisé aux États-Unis. Il n’existe pas une définition fédérale unique qui s’applique partout de la même manière. Selon le secteur, l’État, le régulateur ou le référentiel utilisé, le périmètre peut varier.

La définition du NIST, l’institut américain qui publie beaucoup de standards de cybersécurité, est souvent utilisée comme référence. Elle dit, en gros, qu’une PII est une information qui peut distinguer ou retracer l’identité d’une personne, seule ou combinée avec d’autres informations liées, ou raisonnablement “linkables”, à cette personne.

Dans la vraie vie des équipes data, marketing, produit et analytics, le piège est simple. On croit qu’une donnée technique n’est pas personnelle parce qu’elle ne ressemble pas à un nom, un email ou un numéro de téléphone. Mais un identifiant utilisateur, un cookie persistant, une adresse IP, un device ID, un ID CRM pseudonymisé ou une suite d’événements produit peuvent suffire à reconnaître quelqu’un dans un contexte donné.

Découvrez égalementComment optimiser une page de confirmation de commande ?

Chez certains clients, j’ai déjà vu des exports analytics considérés comme inoffensifs alors qu’ils contenaient des identifiants persistants très faciles à recroiser. Personne n’avait mis de nom dans le fichier, donc tout le monde pensait que c’était “safe”. Sauf qu’avec deux tables internes et un peu d’historique, on pouvait revenir à des utilisateurs précis.

L’évaluation se fait donc au cas par cas. Il faut regarder le contexte, les données disponibles autour, les accès internes, les croisements possibles et la probabilité raisonnable de réidentifier quelqu’un. Une donnée isolée peut sembler neutre. La même donnée dans un écosystème riche peut devenir très identifiante.

Quels identifiants sont directs ?

Les identifiants directs sont les données qui peuvent identifier une personne à eux seuls. Dans la grille du NIST, l’organisme américain qui publie des standards de cybersécurité, ça correspond à ce qu’on appelle la linked information : une information déjà liée à une personne précise, sans avoir besoin de recouper avec autre chose.

On parle ici des données les plus évidentes. Un nom complet, un numéro de sécurité sociale, un numéro de passeport, un numéro de permis de conduire, des données biométriques comme une empreinte digitale ou un scan du visage, des numéros de comptes financiers, ou encore des numéros de dossiers médicaux. Si je vois cette donnée, je peux pointer vers quelqu’un directement. Pas besoin d’être détective.

Le problème, c’est que ces données se baladent souvent partout. Dans des fichiers Excel, des CRM, des outils support, des exports envoyés “juste pour analyse”, des logs applicatifs, des tickets internes. J’ai déjà vu chez un client des numéros de sécurité sociale dans des commentaires de tickets support. Personne n’avait prévu ça. Mais une fois que c’est là, il faut gérer l’accès, la conservation, la suppression, l’audit. Et ça devient vite pénible.

Découvrez égalementGuide Firebase A/B Testing Web

Le risque n’est pas seulement juridique. Il y a le risque de fuite de données, d’usurpation d’identité, de fraude, de perte de confiance, d’audit impossible à tenir proprement, et de suppression compliquée quand une personne exerce ses droits. Plus la donnée identifie directement, plus l’impact potentiel est fort.

Il faut aussi distinguer donnée sensible et donnée non sensible, sans faire semblant que c’est toujours noir ou blanc côté PII. La sensibilité dépend du contexte, de la loi applicable et du dommage possible pour la personne. Un nom complet peut sembler banal. Associé à un dossier médical, une plainte RH ou une transaction bancaire, il change complètement de niveau de risque.

Le RGPD, lui, prévoit des catégories particulières de données avec une protection renforcée, comme certaines données de santé, des données biométriques utilisées pour identifier une personne, ou des données liées aux convictions religieuses, politiques ou syndicales.

Mes réflexes opérationnels sont simples :

• Minimiser ce qu’on collecte vraiment.
• Limiter les accès aux seules personnes qui en ont besoin.
• Éviter les exports inutiles, surtout en CSV ou Excel.
• Chiffrer les fichiers, bases et sauvegardes sensibles.
• Tracer les accès pour savoir qui a consulté quoi, et quand.

Quand une donnée devient identifiable ?

Une donnée devient identifiable quand elle peut être reliée à une personne par recoupement. C’est souvent là que les équipes se trompent, parce qu’elles cherchent un nom, un email, un numéro de téléphone. Mais l’identification ne marche pas toujours comme ça.

Découvrez égalementMinimisation des données protège-t-elle la privacy by design ?

Le NIST, l’institut américain qui publie beaucoup de référentiels sur la sécurité et la donnée, parle de linkable information. En clair, ce sont des informations qui ne permettent pas forcément d’identifier quelqu’un toutes seules, mais qui deviennent identifiantes quand on les met ensemble.

Quelques exemples très classiques :

• Profession.
• Tranche d’âge.
• Lieu de travail.
• Zone géographique générale.
• Affiliation religieuse.
• Origine ethnique.

Pris séparément, ça peut sembler assez banal. “Femme, 35-44 ans, travaille dans une banque à Lyon”, on se dit que ce n’est pas une identité. Mais dans une petite équipe, une filiale locale, ou une base client très segmentée, ça peut suffire à retrouver la personne.

C’est le problème des quasi-identifiants. Ce sont des données qui ont l’air peu sensibles chacune de leur côté, mais dont la combinaison peut isoler une personne dans une population. L’exemple classique, souvent cité, c’est le recoupement entre le sexe, le code postal et la date de naissance. Peu de variables, mais parfois assez pour réidentifier une grande partie des individus, surtout si on croise ça avec une autre base.

Le RGPD va dans le même sens. Une donnée personnelle, ce n’est pas seulement un nom ou un email. C’est aussi une donnée qui permet une identification indirecte. Et dans la vraie vie, c’est souvent l’indirect qui pose problème. J’ai déjà vu des exports “anonymisés” où il suffisait de croiser le service, l’ancienneté et le manager pour deviner la personne en 30 secondes.

La règle simple que je garde : si une équipe interne peut rattacher la donnée à un individu avec les outils dont elle dispose, il faut la traiter comme une donnée personnelle ou une PII.

Les cookies et IP sont ils concernés ?

Oui, les cookies, les adresses IP et les device IDs peuvent être concernés dès qu’ils permettent d’identifier ou de suivre une personne.

Le piège, c’est de croire qu’un identifiant technique n’est pas une donnée personnelle parce qu’il ne contient pas un nom ou un email. C’est rarement aussi simple. Le NIST, l’organisme américain qui publie des standards de cybersécurité et de gestion des données, inclut dans la PII, donc les informations permettant d’identifier une personne, des identifiants persistants d’actifs selon le contexte. Ça peut inclure une adresse IP, une adresse MAC, ou un autre identifiant attaché à un appareil.

Le RGPD suit une logique proche, mais avec ses mots à lui. Une donnée personnelle, c’est une donnée qui permet d’identifier quelqu’un directement ou indirectement. Directement, c’est simple : nom, email, numéro client. Indirectement, ça devient plus subtil : cookie, identifiant publicitaire, identifiant d’appareil, adresse IP, client ID, user ID. Si on peut rattacher ça à une personne, même avec d’autres données croisées, on est dans le périmètre.

Dans le tracking web et app, on manipule tous les jours des identifiants qui ont l’air purement techniques. User IDs, client IDs, device IDs, click IDs, cookies de session, cookies persistants. Certains servent juste à maintenir une session. D’autres servent clairement à reconnaître un navigateur, un appareil ou un utilisateur dans le temps. Et c’est là que le sujet devient sensible.

Mon point de vue terrain, surtout en tracking server-side, est assez simple. Le vrai sujet n’est pas de cacher les données dans un serveur en se disant que ça devient propre par magie. Le vrai sujet, c’est de documenter ce qui transite, pourquoi ça transite, combien de temps c’est gardé, et vers qui c’est envoyé. J’ai déjà vu des setups server-side très propres techniquement, mais flous juridiquement, parce que personne ne savait exactement quels identifiants partaient chez quels outils.

Avant d’envoyer un identifiant à un outil tiers, je me pose toujours ces questions :

• Est-ce que cet identifiant permet de reconnaître un utilisateur, un navigateur ou un appareil ?
• Est-ce qu’il est persistant dans le temps ou limité à une session courte ?
• Est-ce qu’il peut être recoupé avec un email, un compte client, une commande ou une adresse IP ?
• Pourquoi cet identifiant est-il envoyé à cet outil précis ?
• Quelle base légale ou quel consentement couvre cet envoi ?
• Combien de temps l’identifiant est-il conservé côté outil tiers ?
• Est-ce qu’un contrat, un DPA ou une documentation précise encadre ce transfert ?
• Est-ce qu’on peut réduire, hacher, tronquer ou supprimer cet identifiant sans casser le besoin métier ?

Comment réduire le risque conformité ?

On réduit le risque en classant les données, en limitant leur collecte et en sécurisant leur usage dès le départ. Je le vois souvent chez les clients : le problème ne vient pas d’un manque de bonne volonté, il vient du flou. Personne ne sait vraiment quelles données circulent, dans quels outils, ni pourquoi elles sont encore là.

Les exigences légales se renforcent partout. Le RGPD en Europe, les lois américaines État par État, les textes au Brésil, au Canada, en Inde… La tendance est claire. Protéger les données personnelles, ce n’est pas juste cocher une case conformité. C’est aussi éviter une fuite, réduire l’impact d’un incident, et garder la confiance des clients.

Je commence toujours par cartographier les données. C’est simple à dire, mais très puissant. On liste les données collectées, les outils où elles vivent, les usages réels, les personnes ou systèmes qui y accèdent, et les destinataires externes. CRM, outil emailing, analytics, support client, tableur partagé, automatisation Make ou Zapier… Tout compte.

Ensuite, je réduis. Pas par principe, mais parce que chaque donnée inutile devient un risque inutile. On collecte ce qui sert vraiment. On supprime ce qui n’a plus de raison d’être. On évite de stocker un email ou un numéro de téléphone si un identifiant pseudonyme suffit pour faire le même travail.

Il faut aussi être clair sur deux notions souvent mélangées. L’anonymisation veut dire qu’on ne peut raisonnablement plus réidentifier une personne, même en recoupant avec d’autres sources. La pseudonymisation remplace un identifiant direct par un autre identifiant, par exemple un ID client. Ça réduit le risque, oui, mais ça reste une donnée personnelle si quelqu’un peut retrouver le lien.

Le reste, c’est de l’hygiène solide. Contrôle d’accès pour limiter qui voit quoi. Chiffrement pour rendre les données illisibles sans clé. Durées de conservation pour ne pas garder indéfiniment. Logs, c’est-à-dire traces d’accès et d’actions, pour comprendre ce qui s’est passé. Documentation pour prouver les choix. Et revue régulière des tags marketing, pixels, scripts, connecteurs d’automatisation, parce que c’est souvent là que les données partent sans bruit.

Alors on classe quoi avant de collecter ?

La différence entre PII et donnée personnelle n’est pas juste une histoire de vocabulaire. La PII vient surtout du cadre américain, avec le NIST comme référence pratique. La donnée personnelle, elle, est définie par le RGPD et couvre aussi l’identification indirecte. Dans les deux cas, les noms, numéros officiels, données biométriques, IP, cookies ou device IDs peuvent vite devenir sensibles selon le contexte. Mon conseil est simple : partez du risque de réidentification, pas de l’étiquette dans l’outil. Vous collectez moins, vous documentez mieux, vous sécurisez plus proprement, et vous gardez la confiance de vos clients.

FAQ

• Quelle est la différence entre PII et donnée personnelle ?
  La PII est un terme surtout utilisé aux États-Unis pour parler des informations qui identifient une personne directement ou indirectement. La donnée personnelle est une notion juridique du RGPD. Elle couvre toute information liée à une personne identifiée ou identifiable.
• Une adresse IP est-elle une PII ?
  Elle peut l’être. Le NIST inclut les identifiants persistants comme les adresses IP ou MAC dans le périmètre de la PII selon le contexte. Côté RGPD, une adresse IP peut aussi être une donnée personnelle si elle permet d’identifier indirectement une personne.
• Les cookies sont-ils des données personnelles ?
  Souvent oui, surtout quand ils servent à reconnaître un navigateur, suivre un parcours ou rattacher une activité à un utilisateur. Un cookie isolé peut sembler technique, mais s’il permet l’identification ou le suivi, il doit être traité avec prudence.
• Qu’est-ce qu’une donnée linkable ?
  C’est une donnée qui ne suffit pas toujours à identifier quelqu’un seule, mais qui peut le faire une fois combinée à d’autres informations. Par exemple une tranche d’âge, une zone géographique, une profession ou un lieu de travail peuvent devenir identifiants par recoupement.
• Comment savoir si une donnée est vraiment anonyme ?
  Une donnée est vraiment anonyme si la réidentification n’est pas raisonnablement possible. Si vous pouvez retrouver la personne avec une clé, un autre fichier, un ID ou un outil interne, ce n’est pas de l’anonymisation. C’est plutôt de la pseudonymisation, et ça reste à protéger.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA et les sujets SEO/GEO. 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. Si vous voulez remettre à plat vos données, vos tags, vos flux IA ou vos automatisations sans bricolage risqué, contactez-moi.

Franck Scandolera

⭐ 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.