1 an après … de retour sur mon blog avec un article sur la nouvelle loi sur les données personnelles ! Beaucoups d'impacts en perspective pour les professionnels de l'informatique.
1 an après … de retour sur mon blog avec un article sur la nouvelle loi sur les données personnelles ! Beaucoups d'impacts en perspective pour les professionnels de l'informatique.
«Chaque utilisateur ayant un droit à l’oubli, il est nécessaire de prévoir une fonction qui supprime l’ensemble des données personnelles de cet utilisateur.» Alors NON: cela dépend très très fortement de l'intérêt du consommateur, et des autres obligations légales. Écrire ça comme ça décrédibilise totalement le reste de l'article.
J'ai pris le temps de faire un article orienté pour les DEVELOPPEURS, pour leur donner une idée des implications de cette réglementation. Comment un article de 1300 mots pourrait-ils prétendre résumer l'implémentation de la GDPR qui est composer d'une centaine de pages ? Il s'agit bien évidement de vulgarisation et par conséquent il y a des raccourcis dans l'article. Bien sûr que les données nécessaires aux obligations légales ne peuvent être supprimées (par exemple)…. Je l'explique d'ailleurs dans un des paragraphes plus bas. Je t'invite avec (grand) plaisir à faire un commentaire plus constructif, je l’intégrerai volontiers au sein de l'article.
Alors pourquoi avoir parlé de “droit à l'oubli” ? Il n'existe pas sinon cité entre guillemets. On te parle de “droit à l'effacement”, ce qui est un chouilla différent. Par contre, le particulier peut demander la restitution d'une partie des données, celles que tu as donné, tu peux demander l'effacement de ton identité pour les services non essentiels, et à la fin des traitements usuels (délais de garde, garantie, expiration de droits, etc), ces données nominatives doivent disparaitre.
(EDIT : j'oubliais de signaler qu'une empreinte digitale, une image de caméra de vidéosurveillance, l'IP d'un ADSL ou un SSID d'un smartphone est une donnée identifiante, donc personnelle. Et on a déjà une première précision dans le RGPD qui précise qu'une telle donnée ne peut être marchandée. Exeunt donc les filtres anti-anti-adware des journaux ou l'obligation de donner son numéro de plaque minéralogique pour se garer).
Or, il se trouve que ces dispositions existaient déjà dans la loi française et les normes du traitement documentaire. Je le sais d'autant mieux que j'ai bossé sur une GED avec une formation spécifique sur ces normes.
Sur la gestion d'un fichier avec données nominatives, il “suffit” pour un développeur de se calquer sur les procédures de gestion documentaire, qui stipulent qu'une donnée récoltée doit être décrite, avoir une finalité précise, une traçabilité, et des process, notamment les conditions d'accès aux données. Car oui, dans le RGPD, si tu le relis très attentivement, on te demande de documenter des procédures et les flux de données. Oui, je sais, écrire de la doc, c'est toujours bien moins sexy que faire du TDD ou jongler avec ses images dockers… Mais cela t'oblige à réfléchir à 2 fois sur par exemple ton presta de newsletter ou le service d'OCR en PaaS. C'est la raison pour laquelle tu es responsable du choix de ton sous-traitant, et que ce dernier doit t'informer de toute modification dans le process concernant tes données, notamment le recours à sa propre sous-traitance ou la localisation (grossière) de ses serveurs de backups.
(EDIT: j'avais oublié aussi de préciser qu'il y a un process qui est demandé en cas de découverte d'une faille de sécurité. Comme répondre à ces questions : Pourquoi a-t-elle eu lieue ? Comment a-t-elle lieue ? Qu'avez-vous fait pour la limiter dans l'immédiat ? Avez vous les logs d'accès ? Qui a profité de cette faille ? Qui est impacté par les données disséminées ? Que comptez-vous faire pour qu'elle ne se reproduise pas ?. Encore une fois, documenter et que des bonnes pratiques)
Après, il y a de très nombreuses subtilités qui existent déjà dans le droit, mais sont désormais normalisées au niveau Européen ; Comme, par exemple que les coordonnées d'une entreprise uni-personnelle doivent être vues comme celles d'un particulier. Eh oui, ben ça, ça date des premières jurisprudences de la loi de 1978. Et on ne limite pas uniquement aux données commerciales : les salariés sont eux-aussi concernés. D'ailleurs, plutôt que prôner l'effacement, ce qui cause de nombreux autres soucis comme la cohérence de ta base, il vaut mieux recourir à la pseudonymisation, donc utiliser des tables, voire des bases différenciées.
Je suis désolé de ma tartine, mais… La loi c'est comme le code : l'imprécision peut se payer cher
Très clairement, tu es plus calé que moi sur le sujet! L'objectif n'est absolument pas de toucher des personnes comme toi dans cet article, je te désinforme plus que autres choses. L'objectif est de faire découvrir à tous les développeurs et autres fonctionnels les implications (assez grossièrement) de cette nouvelle réglementation. Merci pour ton retour intéressant !
Oh purée… Lire le RGPD ne suffit pas, il aurait fallut faire aussi relire son article par un juriste.