Pré-version du Règlement Protection de la vie privée – partie 1

Suite à l’adoption lundi 23/10/13 de la version du Parlement Européen concernant la protection de la vie privée, je vais faire une série d’articles analysant point par point ce texte.

Aujourd’hui, les provisions générales du texte (articles 1 à 10).

Mais tout d’abord, un point de procédure :

Le texte voté lundi soir (et analysé ici) n’est pas la règlementation qui entrera en vigueur. Il s’agit simplement du texte voté par le Parlement Européen. Les gouvernements des 28 (oui, 28, la Croatie est devenue membre de l’UE depuis le début de l’année) doivent avaliser ce texte, ou faire leur propre proposition.

Ils feront certainement leur propre proposition, le texte sur lequel ils travaillent diffère pas mal de celui adopté par le Parlement. Cependant, cette proposition ne sera pas adoptée de suite (vous savez bien que l’administration est lente, alors imaginez quand 28 administrations de nationalités différentes travaillent ensemble…).

S’entamera ensuite une procédure de trilogue (Parlement Européen – Gouvernements des 28 – Commission Européenne) pour arriver à un texte acceptable par tous.

NB : vous noterez la très grande démocratie du processus… Déjà que le texte voté lundi 23/10/13 soir est le fruit de négociations feutrées, sans discussions officielles ; le texte issu du trilogue sera élaboré de façon encore plus obscure et feutrée (les lobbyistes américains doivent être aux anges).

En un mot comme en cent, bien malin sera celui qui arrivera à prédire le contour final du texte. Au pire on peut partir en conjectures, et au mieux analyser ce qu’on a sous la main.

Les différents textes :

La directive 95/46 CE (celle encore en vigueur) est trouvable là : http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:fr:HTML

Le texte voté lundi 23/10/13 ici : http://t.co/UN1D7mIzZh

 Allez, c’est parti !

Généralités

Au plan matériel (art. 2), ça ne bouge pas vraiment, le texte s’applique pour les traitements (papier ou informatique) à but professionnel. Les activités domestiques sont épargnées.

Sont concernées par ce texte (art.3) tous les professionnels exerçant dans l’UE, ou traitant des données de personnes situées dans l’UE (et paf Facebook).

Les définitions (art. 4) ont pas mal bougé.

La définition de donnée à caractère personnel ne change pas, c’est tout ce qui se rapporte à une personne identifiable. Une personne est identifiable si à partir des informations dont vous disposez vous pouvez l’identifier. Ça semble tomber sous le sens, mais c’est assez complexe en pratique. Si je parle d’un toxicomane mineur habitant à Triffoullis-les-Oies (20 habitants), est-il identifiable ? Pour la plupart des gens non, mais pour la pharmacie qui lui fournit son Subutex, oui. Le considérant 23 indique aussi qu’il faut prendre en considération les moyens à disposition et les efforts déployés pour déterminer si la personne est identifiable. Donc si ça fatigue trop Google de croiser ses bases pouir vous retrouver, vous êtes considéré comme non-identifiable et ne bénéficiez pas de la protection de ce texte. Mais rien ne garantit qu’il ne décidera pas un jour de faire l’effort de vous retrouver quand même…

On voit aussi apparaitre la notion de données pseudonymes. Est pseudonyme une donnée à caractère personnel qu’on ne peut raccrocher à son titulaire sans information complémentaire (sic!). On a donc une donnée à caractère personnel dont on doit s’assurer que l’attribut identifiant est séparé de la donnée elle-même. Du coup, imaginons une base de données qui enregistre plein de choses sur plein de personnes. Si mon outil de restitution ne prévoit pas de remontée des noms-prénoms (et autres éléments identifiants), je suis considéré comme maniant des données pseudonymes ? Quelles sont les autres protections à mettre autour ? (pour l’exemple que j’ai donnée, a minima, l’impossibilité de mettre en place d’autres requêtes que celles existantes et qui ne font pas remonter les éléments identifiants). Bref, ces pseudonymes posent de vraies questions, auxquelles les CNIL européennes vont devoir répondre (je me poile déjà en imaginant la CNIL tentant d’aller faire un contrôle de Google AdSense..).

Viennent ensuite les données chiffrées (« encrypted data »). Ce sont des données à caractère personnel que les moyens technologiques rendent illisibles pour toutes personnes non autorisées à les lire. Cependant, tout chiffrage se casse, c’est une simple question de temps. Donc cette catégorie est obsolète dès son origine ?

Vient ensuite une bonne nouvelle. Le consentement. Plus question maintenant de le présumer (en utilisant nos services vous acceptez que l’on revende vos données à qui en veut), le consentement doit résulter d’une action explicite (case à cocher, à condition qu’elle ne soit pas pré-cochée, etc.), et porte sur une finalité spécifique.

Les fuites de données font leur entrée dans les définitions, de même que les données génétiques et biométriques. Pas grand chose à dire à leur sujet, c’est explicite.

Principes dirigeant le traitement

L’article 5 précise les principes qui dirigent les traitements de données. On retrouve les mêmes que dans la Directive 95/46/CE, simplement présentés différemment. Si on veut ergoter, on peut signaler que les données n’ont plus besoin d’être nécessaires au traitement, mais doivent plutôt être le minimum nécessaire pour accomplir la finalité. Différence sémantique, sans grosse conséquence pour la pratique pour le moment (on verra d’ici quelques années si la CNIL sanctionne une société pour avoir enregistré un numéro de fax afin d’envoyer de la pub).

Pour mémoire, les données doivent être collectées et traitées de façon loyale, licite et transparente, dans une finalité déterminée, limitées au strict nécessaire, à jour et pertinentes, conservées pour la durée minimale nécessaire sous une forme qui permet à la personne concernée d’exercer ses droits, sans subir d’altération, sous la direction du responsable de traitement (ouf, vous pouvez reprendre votre souffle).

Les bases légales pour procéder à un traitement ne bougent pas (art. 6), sauf sur deux points. L’intérêt historique, statistique ou scientifique peut justifier un traitement (on y reviendra plus loin), et l’intérêt légitime d’un tiers aussi.

Cette notion d’intérêt légitime était déjà fumeuse dans la Directive, là on rajoute la possibilité de traiter des données en vertu de l’intérêt légitime d’un tiers. Gros problèmes en vue. Ok, quelques gardes-fous sont mis en place (et encore…), mais leur effectivité laisse place au doute. Et quand bien même, j’attends le jour où la CNIL fera une descente sur Palo Alto, Californie, pour contrôler les entreprises de la Sillicon Valley (oui, c’est une pique gratuite).

Vient ensuite une des grosses innovations du texte, tout un article sur la notion de consentement (art. 7). Fini le consentement « version violeur » (elle n’a pas dit « non », m’sieur le juge), maintenant le responsable de traitement doit prouver que la personne a consentie au traitement de ses données pour une finalité spécifique. Être d’accord pour que ses données soient traitées dans le cadre d’un webmail ne signifie pas accord pour que ces mêmes données soient revendues à un tiers. Et si on tente de noyer le poisson (comme Facebook et ses CGU de 14 pages), le contrat est entièrement nul (vous vous en moquez, mais pour un juriste ça signifie des annulations en cascade derrière).

Un article apparait aussi sur les enfants (art. 8) (au passage on notera que les définitions parlent d’un enfant de moins de 18 ans, et dans l’article 8 on parle de moins de 13 ans). Un enfant ne peut consentir à un traitement de données sns l’accord de ses parents, à charge du responsable de traitement de vérifier que c’est bien le parent qui donne l’accord. Il est ironique de noter que créer un profil en ligne (Facebook, Google, forum quelconque, etc. ) est dorénavant considéré comme aussi grave que vendre une maison du point de vue de l’enfant (accord parental exigé).

Les données sensibles (celles que l’on n’a pas le droit de traiter, sauf exception) voient un ajout, la notion de « gender identity ». Amha, ça correspond plutôt à « se sentir homme (ou femme) » plutôt que « sexe (h/f) », mais tant que ce point ne sera pas expliciter noi sur blanc, on court au-devant de GROS soucis. S’il est interdit de traiter le sexe d’une personne, il devient aussi interdit de traiter son prénom (en général révélateur du sexe). Il sera aussi interdit de procéder aux bilans sociaux d’entreprise (lutte contre les discriminations au travail), de même que prendre un congé maternité (car réservé aux femmes). Une panoplie infinie d’ennuis en perspective 🙂 .

Autrement, on y retrouve aussi les notions d’intérêt historique, scientifique ou statistique comme base légale pour traiter ce type de données, mais comme dit plus tôt, j’y reviendrais plus loin. Les archives sont aussi une base légale au traitement de ce type de données.

Pour le reste, ça ne bouge que dans la formulation.

Enfin, pudiquement intitulé « traitements ne permettant pas l’identification », l’article 10 instaure le premier cheval de Troie de ce texte.

Si le traitement ne concerne que des données anonymes ou pseudonymes, la personne concernée n’a plus aucun droit.

Aucun.

Droit d’opposition, d’accès, ou être informé si la base se fait piraté et que vos données sont dans la nature, du moment que c’était des données pseudonymes, vous n’avez aucun droit à être informé (rappel : les données pseudonymes sont des données dont l’élément identifiant est gardé séparément. En cas de piratage, rien n’empêche le pirate de piquer les données et les éléments identifiants).

Partie 2 – Les droits des personnes

Publicités

4 réflexions sur “Pré-version du Règlement Protection de la vie privée – partie 1

  1. Si les éléments identifiants font l’objet d’un piratage ensemble avec les données, alors le responsable du traitement ne peut plus soutenir que ces données sont pseudonymes! La notion de données pseudonymes me semble actuellement appeler des réactions excessives. Il s’agit uniquement d’une catégorie intermédiaire de données à caractère personnel — parce qu’à présent toutes les données sont personnelles (impossible en pratique de soutenir réellement le caractère anonyme de données), et le régime est en pratique intenable dans nombre des situations où il n’existe pas de risque d’atteinte à la vie privée des individus. Que des responsables de traitements invoquent le régime des données pseudonymes à tort — et il leur en coûtera cher. Il ne s’agit pas du cheval de Troie que l’on dit, à mon sens. Mais je suis très curieux de toute démonstration contraire argumentée.

    • Je ne suis pas d’accord avec vous, sur deux points :

      * Il est parfaitement possible d’anonymiser un jeu de données. Pour cela, il faut bien se poser la question du contenu de ce jeu de données, tant en volume (nombre de personnes y figurant) que de la granularité des infos. Par exemple, au lieu d’utiliser la date de naissance, on va utiliser une tranche d’âge. Au lieu de mettre l’adresse exacte, on utilise la ville ou l’arrondissement. C’est parfaitement possible d’avoir un traitement utilisant des données anonymes, mais il faut bien y réfléchir en amont (dans la pratique, il sera plus rapide de déclarer son traitement à la CNIL que de tenter de l’anonymiser pour échapper à cette formalité ^^ ).

      * En cas de piratage de la base, on se retrouve ne présence de 2 traitements. Celui du piraté, toujours pseudonyme de son point de vue, et celui du pirate, pas du tout pseudonyme.

      Personnellement, j’appréhende énormément le moment où les directions métiers à mon boulot vont découvrir la notion de donnée pseudonyme. Déjà que certaines me soutiennent que leur traitement est anonyme alors qu’elles enregistrent des numéros de téléphone… (en toute bonne foi, c’est ça le pire). Avec les pseudonymes, ça va être encore plus compliqué de leur expliquer les nuances : »pseudonyme, c’est comme anonyme, mais on garde le nom et prénom dans un coin de la table MySQL et vous ne pouvez pas le regarder ». Mouai…

      Et il y a une jolie blague à faire avec les pseudonymes, c’est utiliser le numéro de Sécu de façon généralisée ^^’

      • Merci. Pour ne pas flooder, je tente de rester bref:

        Anonymisation complète: impossible dès qu’un traitement longitudinal est nécessaire.

        En cas de piratage tant des éléments identifiants que des données, le responsable du traitement n’a par définition pas maintenu l’étanchéité technique/organisationnelle lui permettant d’invoquer le caractère pseudonyme des données. En clair, des données ne restent pseudonymes que si la clé permettant de les réattribuer à des individus n’est pas compromise. Pseudonyme n’est qu’une autre façon de dire « codé ».

        Enfin, les données pseudonymes restent des données à caractère personnel! En cas de fuite de données, le responsable doit en informer son autorité de contrôle qui lui demandera de justifier que les données pseudonymes dont il a perdu le contrôle ne peuvent pas facilement être réattribuées (ce qu’il ne pourra pas faire si la « clé » est un simple numéro de téléphone ou même de sécu).

        Prétendre que le régime des données pseudonymes est une zone de « non-droit » est tout simplement inexact.

      • Il ne s’agit pas de flood, mais de l’exposition de votre point de vue (qui est aussi valable que le mien) 😉
        Donc s’il vous faut de l’espace pour l’exposer, ne vous gênez pas.

        La question du piratage d’une base pseudonyme n’a pas de réponse définitive selon moi. Du point de vue strictement juridique, le piraté a bel et bien toujours en sa possession une base pseudonyme, car les moyens organisationnels et techniques existent toujours pour s’assurer qu’il ne puisse pas faire la réatribution. Il est « simplement » responsable d’une fuite de données, enclenchant les articles 30 et 31 (notification de violation).

        Sauf que l’article 10 nous dit que le responsable de traitement piraté n’est pas obligé de réatribuer les éléments identifiants aux données pseudonymes pour satisfaire à une obligation issue du Règlement.

        Donc il peut juridiquement soutenir qu’il n’a pas l’obligation d’informer les personnes concernées que leurs données ont été piratées.
        (je précise bien que c’est une interprétation possible du texte. La CNIL aura certainement un avis différent, du moins je l’espère).

        Concernant la façon d’appréhender intellectuellement la notion de donnée pseudonyme, je ne partage pas votre avis. Amha, ce ne sont pas des données codées.
        Il s’agit de données dont on s’assure, par un biais technique et/ou organisationnel, que les éléments identifiants ne puissent pas être réattribués.

        Prenons la base d’un réseau social diffusant de la publicité.

        Quand ce réseau diffuse des annonces publicitaires, il utilise des données pseudonymes. Du point de vue technique, les critères de ciblage sont non-identifants (tranche d’âge, zone géographique, etc.), même si on les combine tous. Et du point de vue organisationnel, on s’assure que le service « régie pub » n’a que les habilitations nécessaires pour faire les requêtes à base de ces critères, sans pouvoir voir les nom-prénoms ou courriel.

        Il n’empêche que la base contient bel et bien de quoi identifier les utilisateurs, et que la politique de non-attribution permettant de se prévaloir du régime des données pseudonymes n’est que purement déclarative (quel adminsys ne s’est jamais gardé un accès caché au système ?).

        Je ne prétend donc pas que les données pseudonymes sont une zone de non-droit, mais simplement qu’elles affaiblissent énormément la protection des personnes. C’est un choix politique qui a été fait, celui de laisser les entreprises s’autoréguler. Seulement, vu l’importance économique des données, c’est tout aussi pertinent que de de mander à des mineurs d’or de ne pas creuser trop vite.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s