La définition juridique : article 4, point 1, du RGPD
Le RGPD ratisse délibérément large. L'article 4, point 1, définit une donnée personnelle comme suit :
« Toute information se rapportant à une personne physique identifiée ou identifiable (« personne concernée ») ; est réputée être une personne physique identifiable une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale. »
Article 4, point 1, règlement (UE) 2016/679
Quatre éléments donnent toute sa portée à cette définition , et chacun compte pour la façon dont vous classez les données dans votre organisation :
- « Toute information » , aucune limite de format. Textes, chiffres, photos, enregistrements audio, gabarits biométriques, métadonnées et schémas comportementaux entrent tous en ligne de compte.
- « Se rapportant à » , l'information doit concerner la personne, que ce soit par son contenu (elle la décrit), par sa finalité (elle sert à l'évaluer) ou par son résultat (son traitement a un impact sur elle).
- « Identifiée ou identifiable » , la personne n'a pas besoin d'être nommée. S'il est possible de l'isoler en combinant des points de données, cela suffit.
- « Personne physique » . Le RGPD protège les personnes physiques vivantes, et non les entreprises. Mais les données concernant un entrepreneur individuel ou un employé nommément désigné sont des données personnelles.
La conséquence pratique : s'il existe une possibilité raisonnable que quiconque , pas seulement vous, mais toute partie disposant d'un accès , puisse rattacher des données à une personne, il s'agit de données personnelles au sens du RGPD. C'est pourquoi les erreurs de classification se répercutent en cascade sur l'ensemble de votre programme de conformité.
Exemples concrets : ce qui compte et ce qui ne compte pas
La frontière entre données personnelles et données non personnelles est moins évidente que la plupart des organisations ne le supposent. Voici comment les types de données courants se classent au sens du RGPD, à la lumière des orientations réglementaires et de la jurisprudence de la CJUE :
| Type de donnée | Donnée personnelle ? | Pourquoi |
|---|---|---|
| Nom complet | Oui | Identifie directement une personne |
| E-mail : [email protected] | Oui | Identifie une personne physique par son nom |
| E-mail : [email protected] | Non | Adresse générique, aucune personne identifiable |
| Adresse IP dynamique | Oui | Arrêt Breyer de la CJUE (C-582/14) : identifiable avec les registres du FAI |
| Identifiant de cookie / empreinte d'appareil | Oui | Identifiant en ligne au sens du considérant 30 ; isole un utilisateur |
| Numéro d'identification de l'employé | Oui | Numéro d'identification rattaché à une personne précise |
| Données de localisation GPS | Oui | Suit les déplacements d'une personne ; identifiant de localisation |
| Données salariales liées au poste | Oui | Combinées au service/au poste, elles identifient la personne |
| Résultats de sondage anonymisés | Cela dépend | Non personnelles uniquement si la réidentification n'est pas raisonnablement possible |
| Dossiers clients pseudonymisés | Oui | Réidentification possible à l'aide de la clé conservée séparément |
| Images de vidéosurveillance | Oui | Images de personnes identifiables |
| Statistiques agrégées (grand ensemble de données) | Non | Uniquement si les individus ne peuvent pas être isolés de l'agrégat |
| Résultats de tests génétiques | Oui (catégorie particulière) | Catégorie particulière de l'article 9 , données génétiques |
| Appartenance syndicale | Oui (catégorie particulière) | Catégorie particulière de l'article 9 , explicitement énumérée |
Le piège de l'« effet mosaïque »
De nombreuses organisations classent les points de données individuellement et isolément , un numéro d'employé par-ci, un code de service par-là , et concluent qu'il ne s'agit pas de données personnelles. Or le RGPD apprécie l'identifiabilité par recoupement. Lorsque votre système RH, votre plateforme de paie et vos journaux de contrôle d'accès peuvent être recoupés, des données qui semblaient anonymes dans un système deviennent des données personnelles une fois agrégées. C'est précisément la faille que la cartographie des données inter-entités est conçue pour combler.
Catégories particulières : les données de l'article 9 exigent une protection renforcée
Le RGPD considère certains types de données personnelles comme intrinsèquement à haut risque. L'article 9 interdit le traitement de ces catégories, sauf si une dérogation juridique spécifique s'applique , et les sanctions en cas d'erreur sont proportionnellement plus lourdes.
Les catégories particulières sont les suivantes :
- Origine raciale ou ethnique , inclut les champs de nationalité dans les systèmes RH s'ils révèlent l'appartenance ethnique
- Opinions politiques , dons à des partis politiques, données d'inscription sur les listes électorales
- Convictions religieuses ou philosophiques , champs de préférences alimentaires révélant la religion (par ex. « halal » ou « casher » dans les systèmes de restauration)
- Appartenance syndicale , retenues sur la paie au titre des cotisations syndicales
- Données génétiques . Résultats de tests ADN, informations héréditaires
- Données biométriques (lorsqu'elles sont utilisées à des fins d'identification) , scans d'empreintes digitales, gabarits de reconnaissance faciale. À noter : les données biométriques utilisées pour l'authentification (déverrouillage d'un téléphone) peuvent ne pas relever de l'article 9 selon certaines interprétations, mais les journaux d'accès par empreinte digitale en relèvent assurément
- Données de santé , dossiers d'arrêt maladie, aménagements liés au handicap, examens de médecine du travail, demandes d'indemnisation d'assurance. C'est la catégorie la plus fréquemment mal classée en environnement d'entreprise
- Vie sexuelle ou orientation sexuelle . Champs de suivi de la diversité dans les RH, désignations de bénéficiaires révélant le genre du partenaire
Là où les organisations multi-entités se font piéger
Le manquement le plus courant que nous observons dans les organisations gérant la protection des données à travers plusieurs filiales : l'incohérence de la classification des données de santé. Un dossier d'arrêt maladie est classé comme « donnée RH standard » dans une filiale et comme « donnée de santé relevant de l'article 9 » dans une autre. Lorsqu'une autorité de contrôle audite le groupe, l'incohérence devient elle-même la preuve d'une gouvernance inadéquate. C'est pourquoi une taxonomie de données unifiée à travers toutes les entités n'est pas facultative . c'est le fondement d'une conformité défendable.
Bases légales pour le traitement des catégories particulières
Le traitement de données relevant d'une catégorie particulière exige à la fois une base légale au titre de l'article 6 et une dérogation distincte au titre de l'article 9, paragraphe 2. Les dérogations les plus fréquemment invoquées sont notamment :
- Consentement explicite (article 9, paragraphe 2, point a)) , il doit être donné librement, de manière spécifique, éclairée et univoque. Un consentement implicite n'est jamais suffisant.
- Obligations en matière de droit du travail (article 9, paragraphe 2, point b)) , traitement nécessaire à l'exécution d'obligations en matière de droit du travail et de la sécurité sociale
- Intérêts vitaux (article 9, paragraphe 2, point c)) , situations médicales d'urgence où la personne concernée ne peut consentir
- Intérêt public important (article 9, paragraphe 2, point g)) , il doit être proportionné et assorti de garanties
Données pseudonymisées ou anonymisées : la distinction décisive
C'est là que plus de programmes de conformité échouent que presque partout ailleurs. Cette distinction détermine si le RGPD s'applique ou non , et la ligne de partage est bien moins nette que la plupart des organisations ne le supposent.
Données pseudonymisées = toujours des données personnelles
La pseudonymisation remplace les identifiants directs par des identifiants artificiels (jetons, codes, hachages) tout en conservant la clé de réidentification séparément. Le RGPD définit explicitement la pseudonymisation à l'article 4, point 5, et traite les données pseudonymisées comme des données personnelles d'un bout à l'autre.
Pourquoi ? Parce que la réidentification est possible. La clé existe quelque part. Tant qu'une partie quelconque , vous, un sous-traitant, un destinataire de données ou un attaquant déployant un effort raisonnable , pourrait reconnecter le pseudonyme à la personne, il reste une donnée personnelle soumise à l'ensemble des obligations du RGPD.
La pseudonymisation est une mesure de sécurité, et non une dérogation. Elle peut réduire le risque (et le RGPD la reconnaît comme une garantie aux articles 25 et 32), mais elle ne soustrait pas les données au champ d'application du RGPD.
Données anonymisées = hors du champ du RGPD
Les données véritablement anonymisées , lorsque la réidentification est irréversible et raisonnablement impossible pour quelque partie que ce soit, par tout moyen raisonnablement susceptible d'être utilisé , sont entièrement exclues du RGPD (considérant 26).
Le critère est exigeant : vous devez tenir compte de l'ensemble des moyens « raisonnablement susceptibles d'être utilisés » pour la réidentification, y compris les évolutions technologiques futures, le coût de la réidentification et la disponibilité d'ensembles de données complémentaires. Le Comité européen de la protection des données (CEPD) a fixé un seuil élevé, et les autorités de contrôle ont régulièrement constaté que des ensembles de données que les organisations croyaient anonymes étaient, en réalité, pseudonymisés.
Conséquence pratique pour votre registre des traitements
Si votre registre des activités de traitement exclut certains ensembles de données en partant du principe qu'ils sont « anonymisés », vérifiez cette hypothèse au moyen d'une analyse documentée du risque de réidentification. Si vous vous trompez, ces ensembles de données auraient dû figurer dans votre registre des traitements depuis le début , et chaque activité de traitement les impliquant est restée non documentée. La gestion du registre des traitements de Priverion intègre des flux de classification des données qui signalent exactement ce type de faille dans toutes les entités du groupe.
Données relatives aux condamnations pénales : article 10
Les données relatives aux condamnations pénales et aux infractions font l'objet d'une règle propre à l'article 10. Il ne s'agit pas d'une catégorie particulière au titre de l'article 9, mais le traitement est limité au contrôle de l'autorité publique ou aux cas où il est autorisé par le droit de l'Union ou d'un État membre assorti de garanties appropriées.
Pour les employeurs : les vérifications d'antécédents, la communication du casier judiciaire et même le fait de noter qu'un employé a un casier vierge relèvent tous de l'article 10. Si vos filiales situées dans des juridictions différentes traitent les vérifications préalables à l'embauche de manière distincte, un traitement incohérent des données de l'article 10 est un constat d'audit fréquent.
Données des enfants : protections renforcées au titre de l'article 8
Lorsque le traitement de données personnelles d'enfants repose sur le consentement dans le cadre de services de la société de l'information, le RGPD exige le consentement parental pour les enfants de moins de 16 ans (les États membres pouvant abaisser cet âge à 13 ans). Le responsable du traitement doit s'efforcer raisonnablement de vérifier que le consentement est donné par le titulaire de la responsabilité parentale.
Si votre organisation traite des données de mineurs , plateformes éducatives, programmes d'allocations familiales, services pour la jeunesse , cela ajoute une strate de classification que votre cartographie des données doit refléter.
Cartographier les données personnelles dans une organisation multi-entités
Comprendre la définition n'est que le point de départ. Le véritable défi pour les organisations comptant plusieurs filiales est d'appliquer cette définition de manière cohérente à chaque entité, chaque système et chaque juridiction.
Voici la démarche qui fonctionne , et ce que nous avons vu échouer :
Ce qui fonctionne : taxonomie centralisée, exécution décentralisée
- Établissez une taxonomie de classification des données à l'échelle du groupe , définissez les catégories de données personnelles de manière identique dans toutes les entités. « Données de santé » signifie la même chose dans votre filiale suisse et dans votre filiale allemande.
- Cartographiez les activités de traitement au niveau de l'entité , chaque filiale documente ses propres activités de traitement à l'aide de la taxonomie partagée. Cela garantit l'exactitude locale tout en assurant une cohérence à l'échelle du groupe.
- Identifiez les flux de données inter-entités , là où des données personnelles circulent entre filiales ou vers des tiers, cartographiez ces flux explicitement. Les transferts intragroupe nécessitent toujours une base légale.
- Automatisez la recertification , lorsqu'une classification change (par ex. l'ajout d'un nouveau type de donnée aux systèmes RH), ce changement doit se propager au registre des traitements de chaque entité. Les chaînes d'e-mails manuelles ne passent pas à l'échelle.
- Révisez et auditez régulièrement , la classification des données n'est pas un exercice ponctuel. Les nouveaux systèmes, les nouveaux prestataires et les orientations réglementaires modifient tous ce qui compte comme donnée personnelle.
Ce qui échoue : une classification décentralisée sans supervision
Lorsque chaque filiale définit les données personnelles de façon indépendante , ou lorsque le DPD de groupe n'a aucune visibilité sur les classifications au niveau des filiales , les incohérences s'accumulent en silence. La filiale allemande classe les préférences alimentaires comme des données de santé (ce qui est correct selon de nombreuses interprétations des contrats de sous-traitance). La filiale britannique classe le même champ comme « donnée employé standard ». Le registre des traitements semble complet dans les deux entités, mais la posture de conformité du groupe présente une faille que tout audit transfrontalier mettra au jour.
C'est précisément le problème qui a conduit à la création de Priverion : une entreprise de 12 filiales gérant sa conformité au RGPD à travers 47 tableurs, sans aucun moyen cohérent de garantir que la même donnée soit classée de la même manière partout.
