Certes, nous vous avons déjà parlé en long en large et en travers du RGPD et compté moultes actualités découlant de son application, vous savez désormais que c’est un règlement qui vous veut du bien. Marc Rees vous en a fourni l’explication article par article, mais nous allons prendre aujourd’hui la posture d’un développeur (professionnel) qui peut encore se demander ce qu’il est tenu de faire pour respecter la règlementation.
Oui, cela parait évident à tous, mais tout le monde est tenu de respecter la loi : le RGPD est un règlement européen, ce qui implique qu’il est devenu applicable dans toute l’Union Européenne dès sa parution, sans avoir besoin d’être transposé dans les droits nationaux (à l’inverse d’une directive).
Point numéro un : on n’a pas le choix
Le fantôme de Marc Rees, qui hante encore la rédaction, me souffle que, pour être précis, un règlement s’applique dès sa parution sauf si, comme c’est le cas ici, il y a une date de début d’application différée, afin généralement de permettre à tout le monde de s’y adapter.
Publié en avril 2016, il était prévu par son article 99 une entrée en vigueur le 25 mai 2018, ce qui fut le cas. Et force est de constater que quasiment aucune entreprise n’était conforme à la règlementation à cette date, pour une raison simple : cette règlementation est à la fois conséquente avec 90 pages (en français) et 99 articles, mais surtout, elle est structurante, complexe et très contraignante pour les responsables de systèmes de traitements automatisés de données, puisque de très nombreuses données traitées par les entreprises (commerciales ou pas) sont à caractère personnel.
Petite vengeance sur nos amis Américains : à l’instar de bon nombre de leurs lois liées à la sécurité, le RGPD est également une loi extraterritoriale, qui s’applique partout en Europe (d’office) mais aussi partout où l’on traite de données personnelles d’une personne européenne : les MAGMA (Meta, Apple, Google, Microsoft, Amazon) y sont également tenus (et même TikTok). NDLA : si on utilise le nom de la maison mère de Google, Alphabet, je n’ai pas trouvé mieux que MAAMA ou AMAMA. Avis aux lecteurs imaginatifs…
Pour enfoncer le clou, l’article 32 indique que « […] le responsable du traitement et le sous-traitant mettent en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque […] ». Donc le responsable d’un traitement doit mettre en œuvre les mesures nécessaires.
Déjà, c’est quoi une donnée personnelle ?
Ce point est déjà un casse-tête en soi, dans le long chemin de la conformité au RGPD. Car si certaines données sont facilement identifiables en tant que données personnelles, on tombe très vite dans le besoin de réfléchir au sujet. La CNIL nous aide :
« Une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable. Mais, parce qu’elles concernent des personnes, celles-ci doivent en conserver la maîtrise. »
OK pour nom, prénom, date de naissance, en gros pour les données servant directement à identifier une personne, mais ça se complique pour celles qui sont indirectes. Ainsi, une adresse IP peut être une donnée personnelle si elle est rattachée à un contrat personnel d'un fournisseur d'accès internet. Elle ne l'est pas si elle est rattachée à un serveur d'entreprise (sauf si ensuite elle sert à exécuter un contrat pour un particulier, comme la location d'un serveur dédié).
Plus subtil encore, en poussant le raisonnement à l'extrême, toute donnée que vous produisez en tant que particulier peut éventuellement devenir personnelle. Certains banquiers se vantent de pouvoir identifier un client en regardant simplement trois ou quatre de ses transactions financières !
Autre exemple : dans un sondage, on vous demande votre code postal, votre secteur d'activité et votre âge. Dans certaines petites communes, vous serez le seul à répondre à ces critères, alors que ces informations ne semblent pas de prime abord très discriminantes. Et pour couronner le tout, l'inférence, la corrélation, le rapprochement de données très hétérogènes peuvent aboutir à une personnalisation de fait des données. Magie de l'informatique...
Au-delà de ce problème, il existe aussi une catégorie bien spécifique de données personnelles : les données sensibles, qui relèvent des droits fondamentaux concernant la protection de la vie privée. Cela comprend les données de santé (physique ou mentale) ou biométriques, les opinions religieuses, politiques ou syndicales, l'origine ethnique, la génétique, l'orientation et la vie sexuelle.
Sensibles au sens RGPD, leur traitement est en principe interdit ! Pour les utiliser, vous devez avoir un consentement explicite de la personne ou être dans des cas légaux bien délimités. De plus, leur traitement doit faire l’objet de mesures de sécurité renforcées ! Pas question de les stocker en clair, sans protection, sans gérer les droits d'accès, etc.
Rappel des principes
Le RGPD a voulu graver dans le marbre quelques principes indispensables :
- Transparence : l'utilisateur doit être informé de l’usage fait de ses données, de façon claire, et pas dans un océan de lignes en termes juridiques d’un contrat ;
- Légitimité : la finalité doit être légitime et surtout l’usage des données doit être en rapport avec cette finalité. De même, on ne peut pas ajouter un usage sans prévenir la personne concernée : ça n’est pas parce qu’elle a donné son accord pour un usage (et donc que vous traitez ses données) qu’elle sera d’accord pour un autre usage.
- Minimisation : il ne faut pas collecter plus que ce qui est nécessaire : ne pensez même pas à demander le numéro de sécurité sociale pour s'inscrire sur un forum de discussion !
- Exactitude : l'utilisateur doit pouvoir user de son droit de rectification facilement, mais il incombe aussi à l'entreprise utilisant les données de les mettre à jour dès qu'elle a connaissance d'une modification !
- Sécurité : les données doivent rester en sécurité, cf. article 32, et les données sensibles doivent faire l'objet d'une étude attentive avec des mesures supplémentaires ;
- Conservation limitée : les données ne seront conservées que durant le traitement et pas au-delà, sauf si la loi l’impose.
Cadres légaux d'utilisation : information et consentement
Pour être clair, l'information de l'utilisateur est obligatoire, et le recueil de son consentement est obligatoire sauf dans certains cas bien spécifiques.
Comme nous le dit encore la CNIL :
« Le consentement est une des bases légales prévues par le RGPD sur laquelle peut se fonder un traitement de données personnelles. Le RGPD impose que ce consentement soit libre, spécifique, éclairé et univoque ».
Il faut donc prévoir un petit lien qui va bien pour informer pour permettre à l'utilisateur qui vous confie ses données personnelles de :
- connaître la raison de la collecte des différentes données le concernant ;
- comprendre le traitement qui sera fait de ses données ;
- lui assurer la maîtrise de ses données, en facilitant l’exercice de ses droits.
La CNIL nous dit quoi mettre et quand informer ici, et pousse la mansuétude jusqu'à nous donner des exemples là. Elle rappelle aussi que le RGPD demande que cela soit fait « de façon concise, transparente, compréhensible et aisément accessible, en des termes clairs et simples ».
Pour ce qui est des exemptions de consentement, on ne peut pas faire n'importe quoi et les cas possibles sont listés de façon exhaustive :
- l'exécution d'un contrat ou d'un précontrat (par exemple un devis) : où envoyer votre facture si vous ne mentionnez aucune adresse (postale ou mail) ?
- certaines obligations légales (l'INSEE n'a pas besoin de vous demander si vous êtes d'accord pour être recensé) ;
- pour certaines missions d'intérêt public (je ne pousserai par exemple pas la taquinerie jusqu'à demander aux pompiers quand je les appelle quel usage ils comptent faire de mon nom et de mon adresse) ;
- pour sauvegarder les intérêts vitaux d'une personne ;
- pour l'intérêt légitime (comme la lutte contre la fraude, voir plus bas le cas des CAPTCHA).
En dehors de cela, le consentement est obligatoire. Et même sans obligation de consentement, l'information reste obligatoire.
Pour la personne et pour les traitements
La personne se voit sacraliser différents droits. Donc si vous êtes responsable d'une application ou d'un site web, vous devez en tenir compte et prévoir les différents cas.
- Droit à l’oubli : l'utilisateur peut demander l’effacement de toutes ses données sans qu’on puisse s’y opposer, sauf bien sûr si ça empêche l’exécution d’un contrat (vous ne pouvez pas demander la suppression de votre nom et prénom sur votre compte en banque, par exemple). Il faut donc pouvoir isoler les données d'un utilisateur, et les supprimer sans perturber vos traitements ;
- Droit d’accès : de la même façon, les données doivent pouvoir être consultables. Là aussi il faut les isoler, pour ne pas donner le contenu entier de votre base à l'utilisateur lambda, mais il faut aussi penser à une procédure (pas forcément informatique) pour identifier correctement le demandeur ! C’est simple quand l’utilisateur s’authentifie sur un site, c’est plus difficile sur un site de prospection commerciale, sur Google Ads, etc.
- Droit à l’information : on doit savoir facilement ce qui est utilisé et pourquoi.
- Droit d’opposition : l'utilisateur peut s’opposer à certains usages, donc il faut également être capable de différencier ceux-ci et de conserver ces demandes.
- Droit de rectification : la modification unitaire doit être possible, il faut donc un écran spécifique, un accès à la base de données, un script, etc.
- Droit à la portabilité : Là ça devient rigolo, car en théorie, vous pouvez demander (par exemple) à Twitter de vous fournir toutes vos données pour que Mastodon les intègre.
- Droit à… réparation : il est clairement prévu qu’une personne puisse demander une réparation financière si ses données personnelles sont maltraitées. En conséquence, il faut prévoir ce risque juridique et se rappeler que personne ne peut se prétendre à l'abri d'une fuite de données ou de tout autre problème informatique pouvant avoir des impacts sur les données personnelles.
Privacy by design
Vous avez déjà entendu cette expression, mais pour une fois elle n’est pas issue « de mes amis » du marketing, mais bel et bien du RGPD et de son article 25, dont le titre indique la couleur : « Protection des données dès la conception et protection des données par défaut ».
Cette « conformité par conception » n'est pas optionnelle : vous devez le faire dès lors que vous traitez des données personnelles. Cela implique par exemple de réfléchir dès le départ à l'usage de la donnée, à sa protection, à son utilité réelle (ai-je bien besoin du numéro de sécu pour identifier les utilisateurs de mon forum), à son accès, etc.
Faire une analyse (PIA)
Surtout avec des données sensibles, ou lorsque les risques sur l'usage des données personnelles sont élevés, la CNIL vous demandera une analyse d'impact relative à la protection des données. Seuls certains cas en sont exemptés.
Si vous ne devez plus la faire valider au préalable, comme de nombreuses procédures CNIL antérieures, vous devez la faire sérieusement et être capable de la fournir à la CNIL sur demande. Et elle ne le demandera pas toujours lors de la survenue d'un incident, elle peut le faire bien avant... Il faut même lui transmettre dans certains cas légaux ou quand le risque résiduel reste élevé. Bien sûr, cette analyse doit être mise à jour régulièrement, selon la vie du projet concerné.
Avoir un surveillant général
Les grandes entreprises se fendront d'un DPO (Délégué à la Protection des Données), et un simple correspondant suffira dans les petites. Mais il faut quelqu’un de clairement identifié. Les sociétés ne sont pas les seules concernées, mais aussi les collectivités territoriales, et finalement toutes les entités.
Tenir un registre des traitements
Les responsables sont tenus de recenser tous leurs traitements de données personnelles et de pouvoir en fournir la liste à la CNIL sur demande. Plus généralement, il faut être capable de prouver qu’on applique les règles en indiquant les mesures prises pour protéger les données personnelles.
La CNIL nous fournit de l'aide ici, sachant aussi que les petites entreprises (moins de 250 salariés) ont un peu moins de contraintes. En effet, les grandes entreprises doivent recenser, pour tous les traitements de données personnelles :
- les parties prenantes (représentant, sous-traitants, co-responsables, etc.) qui interviennent dans le traitement des données,
- les catégories de données traitées,
- à quoi servent ces données (ce que vous en faites), qui accède aux données et à qui elles sont communiquées,
- combien de temps vous les conservez,
- comment elles sont sécurisées.
Pour les petites, seuls les traitements suivants doivent être enregistrés :
- les traitements non occasionnels (exemple : gestion de la paie, gestion des clients/prospects et des fournisseurs, etc.) ;
- les traitements susceptibles de comporter un risque pour les droits et libertés des personnes (exemple : systèmes de géolocalisation, de vidéosurveillance, etc.)
- les traitements qui portent sur des données sensibles (exemple : données de santé, infractions, etc.).
Attention toutefois si vous faites une campagne marketing ponctuelle mais issue d'un traitement de nombreuses données personnelles ou de données sensibles : dès que le risque se révèle important, il faudra enregistrer le traitement, quelle que soit la taille de l'entreprise.
Et en cas de désastre
Il faut informer la CNIL en cas d’incident sur les données personnelles, principalement les fuites mais aussi les pertes (destruction, suppression) ! On pense souvent aux fuites, mais prenez le cas de données médicales qui seraient effacées par erreur : il y a aussi de possibles conséquences pour l'utilisateur (le patient, les praticiens, l'administration) !
Si l’incident constitue un risque au regard de la vie privée des personnes concernées, vous devrez notifier l’incident à la CNIL. En cas de risque élevé, vous devez également notifier les personnes concernées. Il vaut mieux s'y être préparé, car une communication à la va-vite peut se révéler plus désastreuse que l'incident lui-même.
Il n'est plus l'heure de savoir si on va être confronté à un tel incident, mais plutôt quand et combien de fois. Se rabattre derrière un obscur « incident » technique ne vous sauvera pas, et vous fera passer soit pour un cachotier, soit pour un incompétent.
Un exemple concret
Le diable se loge parfois dans des détails comme on peut le voir avec les solutions de CAPTCHA dont on vous parle aussi ici ou là. La solution reCAPTCHA de Google s'est faite retoquer par plusieurs CNIL européennes à cause du défaut de consentement. Expliquons.
En théorie, un CAPTCHA ne nécessite pas de consentement puisque cela rentre dans le cadre de l'intérêt légitime de l'entreprise, à savoir la lutte contre la fraude (à savoir empêcher l'envoi automatisé de formulaires par de vilains robots). La CNIL nous l'a confirmé en insistant toutefois sur une condition : le recueil des données ne doit servir qu'à ce seul usage (la lutte contre la fraude). Or, regardez bien :
Écran de test de reCAPTCHA (Google)
On voit bien un lien vers la politique de confidentialité de Google et les conditions d'utilisations, mais il s'agit des documents concernant l'usage de l'ensemble des produits Google sans discernement. En conséquence, les données recueillies par Google pour son CAPTCHA peuvent être réutilisées à d'autres fins et réciproquement !
Il faudrait donc soit que Google isole les données utilisées pour le CAPTCHA, ce qui est probablement impossible, car Google utilise justement une très grande partie des données personnelles qu'il collecte pour fiabiliser son CAPTCHA, soit que Google demande le consentement utilisateur pour son CAPTCHA, donc demander à cocher une case de consentement avant de pouvoir afficher la case à cocher « je ne suis pas un robot ». L'application StopCovid utilisait initialement ReCAPTCHA avant d'être contrainte par la CNIL de changer de fournisseur (cf. décision CNILMED-2020-015 du 15 juillet 2020).
La finalité et l'isolation des données ne sont donc pas à négliger, et à vouloir trop en faire on risque de se retrouver dans une situation impossible à faire évoluer. D'autres acteurs ont saisi cette opportunité sur le CAPTCHA pour proposer des solutions compatibles avec le RGPD. Nul n'est à l'abri de ce règlement, pas même Google !
Commentaires (59)
#1
Très clair, merci.
Juste une petite question concernant la durée de conservation des données : y a t’il une durée standard à annoncer à l’utilisateur, ou peut-on rester sur une durée genre ‘tant que vous utilisez nos services’ ?
#1.1
La CNIL conseille (aka sanctionnera sinon
) 1 à 2 ans de conservation des données d’un compte inactif. Après il faut purger.
#1.2
Sauf si t’as une obligation légale supérieure liée à ton activité
#1.3
Un exemple antérieur au RGPD : les associations doivent supprimé les données des anciens adhérent 1 an après la fin de leur dernière cotisation. L’année entre la fin de l’adhésion et la suppression des données étant pour permettre de les contacter pour leur proposer le renouvellement de leur adhésion.
#1.4
Il me semble que c’est 1 an après la dernière connexion de l’utilisateur. J’ai eu une alerte d’une ESN il y a quelques mois justement parce qu’ils avaient mon C.V. sur leur plateforme et que celui-ci serait supprimé si je ne m’y connectait pas.
#1.5
Officiellement, il n’y a pas de durée de conservation imposée par le RGPD. Ca fait partie de l’étude que le responsable doit faire vis à vis de la finalité de son traitement.
#1.6
Non, justement, il faut être précis. EDF a été condamné en partie pour ce flou quant au traitement des données (cf article de NextInpact sur le sujet ! ;-)) .
#2
Le RGPD s’applique dès lors qu’on traite les données d’européens ? Quel est la définition d’européens ? Citoyen d’un pays de l’UE ? Habitant ? Les deux ?
#2.1
L’article 3 du RGPD indique deux critères :
#3
Ca tombe bien, je suis développeur
Sans remettre en cause le détail de l’article (qui est somme toute très clair) et le travail de fond, je vais être très critique, mais de manière constructive.
Déjà, présenter le consentement comme obligatoire avec 5 exceptions n’est pas vraiment juste. Le RGPD ne met absolument pas en avant une des bases légales pour légitimer un traitement. Il existe 6 bases légales, dont le consentement. C’est quand même très différent d’un régime à base d’exception tel que présenté dans l’article.
L’article manque cruellement de détails pour les développeurs, cible pourtant annoncé en début d’article. Comment gérer la sécurisation des données ?
Le PIA (ou AIPD pour nous francophone, sachant PIA est aussi le nom d’un outil mis à disposition par la CNIL). Comme pour la base légale, je trouve que cela manque de précision. Le PIA n’est obligatoire que dans certains cas :
Après, il est possible de faire un PIA sur tous les traitements si on le souhaite. Mais pour en avoir déjà fait et les mises à jour qui vont avec, c’est un processus très chronophage !
Pour l’information à la CNIL en cas de violation (au sens large, allant des accès non autorisés à la perte de données), il est bon de rappeler que la déclaration initiale doit être faite 72h après la découverte de la violation. Il est ensuite possible de venir compléter le rapport initial ultérieurement quand on a plus de détails sur la violation :
J’aurais également rajouté une section sur la localisation des données. Les données stockées hors UE nécessitent des précautions. Notamment, l’usage de serveur situés aux Etats-Unis et/ou de prestataires Etats-uniens nécessitent une vigilance très particulière.
#3.1
En toutes logiques, la CNIL, comme les autres, vont demander l’application des best practices donc le top moumoute (redondance 3-2-1, chiffrement des données sensibles lors du stockage et dans les échanges entre SI, gestion et traçabilité sécurisée des accès, ..)
#3.2
Je ne pense pas que l’article avait comme but de donner des détails techniques sur le “comment” mais plus sur le “quoi”.
J’ai eu le même sentiment de manque d’information concrète pour le dev. C’est pas les dev qui doivent faire la liste des traitements réalisés, ni désigner le DPO. Nous pouvons au mieux en parler en donnant les risques encouru. Mais même là, j’ai régulièrement une analyse du risque au doigt mouillé qui fini : “avant qu’on se fasse contrôlé il y a du temps, il font les gros en premier”.
Mais peut-on refuser de réaliser un dev si la demande est clairement hors RGPD (collecte de données hors contexte métier) ? Malheureusement nous n’avons de droit de retrait !
Une IP étant une donnée personnelle, utiliser les CDN pour charger le JS/CSS/Image est-il possible ? Si oui, existe-il des limitations ? Au vu des décisions dans l’Europe, ce n’est pas possible dans que le CDN n’est pas la propriété du propriétaire du site…
Je m’attendais aussi à des conseils sur l’usage de service en ligne (tel que slack/discord, stack overflow, forums…), l’utilisation de dépendance externe (librairie tierce à l’entreprise), les questions posées sur Internet avec les logs ou le code source, les captures d’écran non floutées qui contiennent des données personnelles, le partage de secret (clé d’API, mot de passe).
J’ai souvent des remarques sur le fait que je floute (et je demande que les autres en fasse autant) beaucoup de chose sur mes captures d’écran que je partage via le slack/discord/team de l’entreprise. Mais en fait je sais pas ce que le presta en fait ni même si elles fuiteront pas un jour.
#3.3
Entièrement d’accord avec ces imprécisions et avec l’introduction qui prête à confusion.
La CNIL a publié un guide à destination des développeurs qui répond plus à cette introduction : https://www.cnil.fr/fr/la-cnil-publie-un-guide-rgpd-pour-les-developpeurs
#4
(edit: j’ai été devancé, avec une réponse bien plus précise)
#5
Ca existe vraiment ce cas ? Les seules fois ou j’ai vu des CAPTCHA, c’est pour forcer l’utilisateur à voir de la pub
#6
Merci pour cet article très clair.
#7
Tiens question à ceux qui savent.
Pour faire simple, on va dire que ma boite est une sorte d’intermédiaire technique qui permet à des PME de faire du marketing direct par SMS.
Quand un utilisateur se désabonne, on lui donne une adresse email de contact si il veut plus d’info.
Un des désabonnés m’a demandé de supprimer toutes les données qu’on a sur lui. Pas de soucis, j’ai que le téléphone, donc c’est simple…. Sauf que je lui ai dit que je ne supprimerai pas son numéro de téléphone car cela serait contraire à sa demande de désabonnement.
En gros, pour qu’un utilisateur ne reçoive plus de SMS, il me faut une “blocklist”, si je supprime son numéro, il n’est plus dans la blocklist et peut donc recevoir des SMS marketing et c’est donc en opposition avec son souhait.
Ai-je bien répondu, à votre avis ?
#8
En fait si quand même. Les 2 autres régimes généralement utilisables (contrat et intérêt légitime) sont soumis à un régime TRÈS strict (beaucoup de choses que tu envisages sous l’un de ces 2 régimes y est généralement explicitement interdit), du coup le consentement est trop souvent la seule base légale licite.
#9
Oui et non. La blackliste devrait être constituée par exemple d’un hash du n° de téléphone et pas du numéro de téléphone en clair. En théorie ça reste de la pseudonymisation et donc ça reste une DCP, mais ça élimine les possibilités de détournement de finalité à partir de la base de donnée des blacklists.
Et la bonne réponse serait du coup « on a bien purgé toutes vos données, par contre, sauf opposition explicite de votre part, on conserve le hash pour notre blacklist et vous voyez, on respecte bien la minimisation de données et les mesures techniques de protection »
#10
Oui tout à fait, faut toujours regarder ton cas à toi dans tous les cas. Mais en tout cas le nécessaire au contrat ou l’intérêt légitime ne tiendrait pas sur un compte « trop » inactif.
#11
Pas du tout d’accord. Juridiquement, une exception est très différente d’une base légale.
Une exception n’est pas opposable (ex. la copie privée n’est pas opposable aux mesures de protection anti-copie, car c’est une exception et n’est pas consacré dans la loi).
Le RGPD parle bien de base légal. Et non pas de consentement avec des exceptions dans 5 cas particuliers. Dans certains cas, il n’y a souvent que le consentement qui est valide (par ex. un site internet sur lequel il n’est pas nécessaire de s’inscrire), mais dans beaucoup de traitements, les obligations légales ou une base contractuelle sont largement exploitable.
La seule base que je déconseille fortement, c’est l’intérêt légitime. C’est la seule qui est subjective et soumise à interprétation, et elle peut facilement être retoquée. Et en cas de désaccord avec la CNIL, on sait d’avance que c’est la CNIL qui aura raison
#12
Je vais juste repréciser le but de mon petit papier : il est question de préciser quoi faire dans le cadre du RGPD, pour un développement informatique, et pas comment faire, car il faudrait une encyclopédie pour faire le tour du sujet. Après cela, nos lecteurs peuvent partager leurs avis et expériences, les commentaires sont faits pour ça et sont les bienvenus !
La relation avec l’employeur ou le donneur d’ordre est souvent complexe (en clair on redoute toujours le “je me fais virer si je fais pas”). Néanmoins, il y a toujours un responsable (légalement parlant) à un traitement : le dev peut toujours faire subtilement remarquer à celui-ci que s’il ne fait pas ce qu’il faut pour se conformer au RGPD, il est passible d’une amende mais aussi d’une peine d’emprisonnement mais dans ce cas là on passe dans le délictuel (= passage au tribunal correctionnel).
Attention : une IP n’est pas nécessairement une donnée personnelle. Et puis ici on peut l’utiliser pour un CDN car c’est un impératif pour la réalisation du contrat (= la délivrance du service de CDN).
#13
Tu devrais relire les GL sur l’intérêt légitime et l’obligation contractuelle. Tu serais très surpris…
La lutte contre la fraude bancaire ? Ni nécessaire au contrat (tu peux rendre le service sans, c’est juste que tu prends un risque) ni intérêt légitime (les scores réalisés nécessitent des violations de vie privée non proportionnés aux risques), consentement obligatoire… 🤣 Pas obligation légale parce que ce sont des obligations (PCI-DSS) d’organismes privés (GIE-CB ou autres) et non des textes réglementaires (seul LCB-FT l’est).
Les cas réellement obligation légales, contrat ou intérêt légitimes sont BEAUCOUP plus rares que tu ne le penses en pratique.
#14
Non, c’est justement refusé comme « nécessaire au contrat » parce que tu sais parfaitement fournir le même service sans CDN du tout (tu le fais toi-même avec ton infra en propre). C’est du coup exclusivement « intérêt légitime » mais c’est très fragile surtout fonction des CGU de ton CDN en face (cf décision CDN US et Schrems II). Et consentement impossible à appliquer en pratique. Ça veut donc dire juste devoir supprimer le CDN tout court car aucune base légale valide.
#15
Je ne sais pas si la liste avait pour objectif d’être exhaustive, mais l’orientation sexuelle est aussi une information classée comme “devant être autorisé pour des cas spécifiques” listée dans le considérant 71.
Attention, le DPO n’est pas responsable (au sens légal du terme). Il ne peut pas l’être, ça déclencherait un risque de conflit d’intérêt. Le DPO est le correspondant privilégié de l’autorité de protection des données et garant du respect de la conformité des traitements vis à vis de la réglementation. Typiquement pour l’exemple donné par Fdorin de demand de dev de fonctionnalité qui violerait le RGPD, c’est vers lui qu’il faut se tourner pour moi.
Le responsable au sens du RGPD (”Accountability”) est celui qui détermine la finalité de la collecte et du traitement. La fonction de DPO est incompatible avec la responsabilité du traitement.
Sinon vu qu’on parle de mise en oeuvre de la conformité RGPD, comment considérez-vous les points suivants vis à vis de Next Inpact ?
#16
Oups, erreur d’édition, effectivement il y a l’orientation et la vie sexuelle dans l’article 9 du RGPD.
Pour le DPO, le titre n’est pas adapté : le DPO a en effet un rôle d’information, de conseil et de contrôle, et doit être indépendant. Ce n’est pas le responsable du traitement des données, c’est un “surveillant général du RGPD” (entre autres) qui peut prendre la forme d’un DPO ou d’un correspondant pour les petites entités.
#16.1
Yep il faut corriger ce titre car là il est vraiment trompeur.
Sinon j’espère que vous mentionnerez aussi par la suite l’excellente formation “Atelier RGPD” de la CNIL. Très instructif et accessible, compter une bonne demi journée et une palette d’aspirine pour passer le second module (car le plus dense du lot vu qu’il traite les 8 principes du RGPD), mais indispensable à mes yeux.
Sinon j’ai peut être loupé le passage, mais justement en parlant de principe du RGPD, l’un des plus importants est celui sur la responsabilisation du .. responsable du traitement. C’est une notion très importante et structurante car elle conditionne aussi le fonctionnement des sous-traitants et la notion de co-responsable. Ce sont des principes dont découlent aussi l’aspect contractualisation avec son prestataire puisque le RGPD impose des clauses en ce sens.
#17
Merci pour la précision. J’ai été induis en erreur par l’introduction…
Qu’appelles tu GL ?
J’ai l’impression que tu parles d’expériences dans le domaine bancaire. Certains groupes bancaires sont connus pour faire du zèle dans le traitement des données au nom de la lutte contre la fraude bancaire. Comme tu le soulignes, l’intérêt légitime est tout à fait utilisable, à la condition que les atteintes à la vie privé soient proportionnées (ce qui n’est souvent pas le cas).
Après, comme tu le soulignes, il y a aussi des obligations légales. Tu cites le LCB-FT. Si tu fais ce qui est demandé au niveau de la loi, tu n’as absolument aucun souci pour légitimer ta base légale. Je connais beaucoup plus le domaine de la santé que le domaine bancaire. Et les bases utilisées sont soit le contrat, soit l’obligation légale, soit l’intérêt général (sauvegarde du patient). Si tu ne t’écartes pas de ce que tu dois faire (par obligation légale ou contrat), il n’y a aucune difficulté à justifier un traitement.
J’ai surtout l’impression que tu imagines de nombreux traitements (ex: lutte contre la fraude bancaire) à la marge d’un traitement de base (ex: fournir un compte en banque)
#18
GuideLines, en l’occurence
https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines-art_6-1-b-adopted_after_public_consultation_fr.pdf pour le 6(1)b « nécessaire au contrat » et https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_fr.pdf pour 6(1)f « intérêt légitime »
Je parle de fraude au sens général du terme, ça inclut aussi par exemple les portiques de sécurité de la RATP qui ne peuvent pas être couverts par « nécessaire au contrat » (tu peux parfaitement les supprimer sans compromettre le service « je paie pour que tu me transportes de A à B »).
Et la RATP ne peut pas non plus le mettre sous l’intérêt légitime parce que la CNIL a dit que les pass nominatifs étaient non proportionnés à l’objectif visé.
Beaucoup de choses que tu considères comme pouvant relever du 6(1)b ou du 6(1)f ne peuvent en fait pas les utiliser (lire pages 9 et suivantes des GL 2⁄2019) et seul le consentement reste valide.
Certes, mais encore une fois, il faut que ça relève réellement d’une obligation légale et pas de vague truc décidés par des entités de droit privé (et il y en a plein).
Tout à fait, mais dans les cas généraux, le consentement est réellement le truc qui représente 90% des cas au doigt mouillé. Et c’est bien tout le problème : personne ne veut avoir à gérer du consentement et donc plutôt que de virer le traitement, ils le font rentrer aux forceps dans contrat ou intérêt légitime…
Pas vraiment. EDPB a bien indiqué dans GL 2⁄2019 considérant 50 que la « lutte contre la fraude » (au sens large, pas que bancaire) ne pouvait pas relever du contrat mais uniquement de l’intérêt légitime. Et que l’intérêt légitime devait être nécessaire et proportionné en plus d’être légitime.
Tous tes services annexes ne peuvent par définition pas relever du contrat et devraient relever de l’intérêt légitime ou du consentement.
Dans BEAUCOUP de cas, ton intérêt légitime tombe et du coup sauf consentement, ton traitement annexe devient impossible.
Traitement annexe que toi, prestataire du service, tu considères pourtant comme une condition nécessaire à la réalisation de ton contrat et n’envisage pas du tout de faire sans. En d’autres termes, tu n’envisages pas de pouvoir rendre ton service principal sans être en non conformité RGPD à cause des finalités secondaires…
Tu as le choix entre fermer ta boîte ou être en non conformité. Je te laisse deviner ce que la plupart des gens choisissent…
#19
Merci pour vos précisions
#20
Le fantôme de Marc Rees a oublié de vous souffler que le règlement s’applique aux états membre qui doivent le mettre en application suivant les modalités propres à chaque état.
En l’occurrence, pour la France, nous sommes soumis à la loi française n° 2018-493 du 20 juin 2018 relative à la protection des données personnelles.
https://www.legifrance.gouv.fr/loda/id/JORFTEXT000037085952/2022-12-15/
#21
Voilà, maintenant, je sais à quoi tu fais référence. Merci :)
Attention quand même, l’un des documents n’est qu’un avis de 2014, soit 2 ans AVANT l’adoption du RGPD, et 4 ans avant sa mise en application !
Je n’ai rien trouvé de récent à ce sujet, seulement des trucs qui datent de 2009. Et là, le reproche de la CNIL n’est pas tant les pass nominatifs que la collecte, aux portiques, d’un horodatage associé au numéro du portique (donc le lieu) et au numéro d’abonné (donc la personne).
La CNIL relevait effectivement, déjà à l’époque, que les voyageurs avaient le droit de voyager anonymement, et regrettait que la version “anonyme” (= sans collecte) soit plus cher (par ex. en cas de perte, il fallait payer). Mais c’est cette collecte que la CNIL jugeait disproportionnée à l’époque, et non le pass nominatif en lui-même.
Et dans ce genre de situations, la CNIL relève généralement l’existence de mesures alternatives et moins intrusives pour motiver sa décision.
Dès lors qu’on respecte le principe de minimisation de la collecte des données, c’est-à-dire collecter uniquement ce dont on a besoin, ce n’est vraiment pas un souci.
Je pense qu’au global on est plutôt d’accord, juste qu’on ne part pas forcément sur la même base pour les traitements. Dans le cadre de mon boulot, j’insiste bien sur la minimisation auprès de mes clients, j’ai parfois fait supprimer des informations qui n’apportaient absolument rien (comme la profession d’un patient) et qui souvent, n’étaient que très très peu utilisées., voire la suppression pure et simple de certains traitements.
Mais comme tu le dis si bien :
Je suis entièrement d’accord avec ça. il ne faut pas faire n’importe quoi. Mais en faisant les choses correctement, contrat, intérêt légitime et obligation légale remplissent très bien leur rôle dans beaucoup de cas.
Sans oublier ceci :
;)
#22
Un Règlement Européen s’applique directement aux Etats-membres dès qu’il est promulgué, il n’y a pas de “mise en application” propres à chaque Etat contrairement à une Directive qui est à transposer dans le droit national.
Ici, la loi 2018-493 a été faite pour adapter la législation existante pour la rendre compatible avec le RGPD (et éventuellement préciser / ajouter des choses, ce que les Etats-membres ont le droit de faire). A noter que le RGPD a pas mal hérité de la loi Informatique et Libertés française.
#23
Pas tout à fait : un règlement n’a pas besoin d’être transposé dans le droit de chacun des états, à l’inverse d’une directive. Il s’applique dès parution (ou à la date de début d’application fixée par le règlement). Par contre il y a eu un travail d’adaptation et de mise en conformité du droit français, comme l’indique la CNIL, afin que des lois existantes antérieures ne soient pas en contradiction avec le RGPD, par exemple. Par ailleurs, il est aussi écrit dans le RGPD : “Le présent règlement laisse aussi aux États membres une marge de manœuvre pour préciser ses règles” (mais pas pour diminuer le niveau de protection, juste apporter des précisions dans certains cas).
#24
Ce sont des avis contraignants de WP29 aka EDPB, qu’ils retranscrivent régulièrement en version moderne. L’avis de 2014 a autant d’effets juridiques que celui de 2019 donc.
Si justement. Non seulement tu dois minimiser, mais en plus tu dois avoir la bonne base légale. Si tu as minimisé sous le régime de l’intérêt légitime ou du contrat mais qu’une APD requalifie ça en consentement parce que ni 6(1)f ni 6(1)b n’étaient possible, ton traitement n’en reste pas moins tout autant non conforme et illicite.
Encore une fois non justement. Beaucoup trop de finalités sont placées sous ces bases légales alors qu’elles peuvent et ne devraient qu’exclusivement relever du strict consentement et sont donc de facto illicites.
Il faudrait que je retrouve la condamnation en question, mais un mauvais choix de base légale, ça veut possiblement dire une condamnation à devoir effacer l’intégralité des données collectées (oui, parce qu’on ne peut pas changer de base légale en court de route). Et ceci même si elles étaient minimisées. C’est TRÈS con quand c’est l’intégralité de ta base client :)
La minimisation serait en fait même violée, parce que sous la base du consentement, les données n’auraient juste pas du/pu du tout être collectées (et on fait difficilement plus minimal que pas de données du tout).
#25
Le règlement s’applique partout, mais c’est l’état-membre qui fait appliquer le texte.
(subtilité juridique)
Si un état-membre échoue à faire appliquer le texte, la commission peut lancer une procédure d’infraction contre l’état-membre… et pas contre le citoyen (même s’il ne respecte pas le règlement) !
https://commission.europa.eu/law/law-making-process/applying-eu-law_en
Pour le reste, on dit la même chose: Il n’est pas nécessaire pour les états-membres de transposer le règlement (car il s’applique tel quel), mais il peut s’avérer obligatoire pour les états-membres de modifier les lois nationales si elles contredisent le règlement (ce qui était le cas pour la France).
#25.1
Là dessus oui on est d’accord. Peut-être ai-je mal interprété ton premier message où alors il n’était pas clair, mais la façon dont tu le disais c’était comme si la seule chose qui faisait foi dans le droit français était la loi d’adaptation de 2018 (soit en gros le fonctionnement de la Directive Européenne).
Ce sont bien deux choses complémentaires. Et dans tous les cas, oui, ce sont les Etats-membres qui appliquent le droit européen. (la CJUE étant là pour harmoniser l’interprétation et faire jurisprudence en cas de divergence)
#26
Beaucoup de si…. Mon propos, c’est juste pour dire que, contrairement à ce que tu affirmes, les bases contractuelles remplissent beaucoup de cases. Le problème, et tu l’as d’ailleurs soulevé dans ton commentaire précédent, c’est que certains essaient de faire rentrer de force de nombreux traitements là-dedans (notamment, ceux que j’ai qualifié de traitements annexes).
Mais il y a une différence majeur entre dire qu’une base est quasiment inutilisable et qu’il ne reste que le consentement, et ce planter largement dans la démarche de choix de la base légale.
Un mauvais choix de base légal pour un traitement en particulier ne signifie pas que les bases légales autres que le consentement sont inutilisables en général.
Oui, il y a des gros soucis, je te le concède volontiers, car beaucoup ont voulu garder exactement les mêmes traitements AVANT rgpd et APRES. Mais si tu prends le temps de faire les choses correctement, de réfléchir aux données collectées, au pourquoi, aux traitements, etc… Beaucoup de traitement sont éligibles aux bases contractuelles.
Effectivement, je me souviens d’avoir vu passer un truc dans le genre. Et oui, c’est normal. Maintenant, même si la base légale est erronée, l’intégralité des données n’est pas forcément à supprimer.
Pour reprendre ton exemple, si tu as des clients, tu as des factures. Tu as des obligations légales de conservation de données par rapport à cela ;) Mais toutes données non nécessaires à l’exécution de prestations en cours ou au respect d’obligations légales sont à supprimer (c’était ce qui ressortait du cas que j’avais vu).
Là, tu commences à partir dans des cas trop spécifiques, sans même les expliciter, pour pouvoir tenir un discours générique.
Là dessus, je ne suis absolument pas d’accord. Un avis de 2014 n’a pas autant d’effets juridiques alors que celui-ci a été remis à plat depuis. Il peut émettre des avis, mais pas des avis contraignants.
Par contre, il peut émettre des décisions contraignantes, dans le cas d’affaires en particulier, par exemple, lorsqu’il y a mésentente entre différentes autorités nationales. Ou alors j’ai mal compris son rôle.
#27
Non. Correction, les gens voudraient qu’elles cochent beaucoup de cases. Les GL sur le sujet sont très claires : ce qui est couvert par cette base légale doit être extrêmement limité (considérant 27 & 28 page 10 des GL 2⁄2019).
De la même manière qu’avoir un intérêt légitime pour une finalité ne veut pas automatiquement dire que tu peux te prévaloir de la base légale de l’intérêt légitime (il faut encore prouver la nécessité et la proportionnalité), une clause que tu mets dans ton contrat ne relève pas automatiquement de l’obligation contractuelle (il faut aussi prouver la stricte nécessité).
Non, mais que si tu t’es planté de base légale au départ, tu es en non conformité. Même si tu aurais pu te placer sous une autre base pour effectuer légalement la finalité.
L’avis de 2014 a le même poids légal que celui de 2019. D’ailleurs il est cité en référence dedans (note 26 de bas de page 16) et ses idées sont reprises textuellement.
Tant que ces GL WP29 (nouvellement EDPB) pré 2016 ne sont pas abrogées par EDPB (anciennement WP29), elles ont légalement le même effet que celles émises par EDPB post 2016.
Tu as mal compris. EDPB est comme la CNIL, un organe de droit souple. Ils ne peuvent pas légalement émettre d’avis « contraignant » au sens réglementaire (et se font sanctionner s’ils le font, comme la CNIL au Conseil d’État pour l’interdiction des cookie wall). Mais étant aussi les organes de sanction, forcément que c’est contraignant parce que les APD (via EDPB et l’article 63 du RGPD) n’iront pas à l’encontre des GL édictées et approuvées collectivement et à l’unanimité par elles.
L’absence de contrainte au sens légal du terme ne veut pas dire qu’il n’y aura pas sanction à la fin et reconnaissance de la non conformité via le non respect de ces GL. ET donc en pratique contrainte de respecter ces GL quand même, sous peine de sanction.
#28
Est-ce qu’un imei est une donnée personelle du coup ?
#28.1
Oui
#29
Depuis le début, je fais bien le distinguo entre le traitement “primaire” (ou objectivement nécessaire pour reprendre la terminologie du document), c’est-à-dire celui nécessaire à l’exécution d’un contrat, et les traitements “secondaires”. C’est exactement ce que les considérants disent.
Autrement dit, quand tu prends le soin de minimiser les données et les traitements, l’usage de la base contractuel couvre un large panel de cas d’utilisation, sans avoir besoin de recourir au consentement.
Voilà, donc quand tu fais correctement le boulot, et j’entends par là que tu réfléchis véritablement aux données que tu collectes dans le cadre de la fourniture d’un service et autres traitements que tu effectues, tu t’en sors très bien, car c’est justement “objectivement nécessaire”. Et c’est justement un des objectifs du RGPD : faire prendre conscience aux responsables de traitement des traitements réalisés et des données collectées.
Là dessus, on est d’accord ;)
Non, non non et renon. L’avis que tu cites (celui de 2014) concerne la directive 95/46/CE qui a été abrogée le 25 mai 2018 par la mise en application du RGPD. Ce document n’a donc plus aucune valeur “légal” aujourd’hui. Cela n’empêche pas qu’une partie de son contenu puisse être repris dans d’autres avis ultérieurs au RGPD.
EDPB est au dessus de la CNIL (de toutes les CNILs en fait) et est là pour gérer les cas transfrontaliers et les problèmes. Elles émets des avis sur des cas spécifiques qui ont valeur jurisprudentiel afin d’harmoniser les interprétations au niveau européen lorsqu’elle est saisie (soit par elle-même, soit par une autorité).
Son rôle est aussi de publier des lignes directrices, des recommandations et des bonnes pratiques. Mais cela reste des recommandations et non des exigences. C’est très important car cela signifie que le non respect des guides n’est pas directement sanctionnable. C’est donc très différent d’un avis contraignant.
#30
Encore une fois : non. La minimisation des données est l’étape initiale et obligatoire du RGPD, peu importe la base légale derrière. Toute finalité non minimale pour ton business est de toute façon à rejeter et est non conforme by design.
Pour chaque finalité survivante à la minimisation, tu dois alors trouver la base légale à retenir, et les GL montrent que dans 90% des cas, tu devras les placer sous le strict régime du consentement parce que ne sera pas strictement nécessaire à la réalisation du service (et non de ton business), donc pas contrat ni intérêt légitime, ou proportionné, donc pas intérêt légitime.
Tu vas du coup devoir encore élaguer dans tes finalités pour ton business tout en maintenant celle pour ton service, ou les placer sous consentement qui généralement tue ton business (mais pas ton service).
Tout le monde confond complètement les 2 mondes. Ton business n’est pas ce dont le RGPD traite, mais exclusivement ton service.
La gestion de fraude, l’amélioration du service, le suivi de ta compta ou de tes objectifs marketing ne sont PAS plaçables sous l’intérêt légitime ou le contrat (parce que non nécessaire à la fourniture du service ou trop intrusif sur la vie privée des utilisateurs par rapport aux avantages retirées) alors qu’ils sont nécessaires à ton business.
Et c’est là que ça coince en général, parce qu’on a construit la plus grosse partie de la viabilité de nos business sur des choses qui sont aujourd’hui illicites de par le RGPD. À de très rares exceptions près, aucune entreprise ne sait conserver son activité une fois passé le crible de la minimisation et de l’affectation des finalités restantes à des bases légales recevables.
L’intersection des bases légales acceptables au point de vue business par rapport à celle légalement acceptable pour le service est proche du vide. Typiquement pour le suivi marketing de ta boîte, il est inenvisageable de placer ça autre part que contrat ou intérêt légitime (parce que tes chiffres n’ont de sens que si tu touches 80-100% de ta base client) alors que le RGPD t’impose le consentement (et que tu en toucheras maximum 20-30% du coup, personne n’ayant d’intérêt à consentir à ce suivi pour tes beaux yeux).
Et même sous consentement, en touchant seulement 30% de ta base client, tes KPI business perdent du coup tout intérêt et deviennent non nécessaires puisque plus pertinentes, ne devraient du coup plus passer le crible de la minimisation et devraient être purement et simplement supprimées, conduisant à la fermeture de ta boîte qui ne sait plus fonctionner sans.
Non. Son boulot est d’homogénéiser l’ensemble des décisions des 27 APD et aucune APD ne peut traiter un dossier sans consulter EDPB avant. Tout décision, ligne directrice, avis ou sanction d’une APD est rendue exclusivement après consultation de l’ensemble des 26 autres APD. Toutes les APD n’ont donc d’autres choix que d’appliquer strictement les lignes directrices émises par EDPB (en auto-saisie ou sur demande d’une APD). Si ce n’était pas le cas, l’obligation de cohérence serait violé.
EDPB a d’ailleurs bien rappeler la règle récemment : https://twitter.com/EU_EDPB/status/1600414827607998464
#30.1
Alors pourquoi tu écris l’inverse sur ton blog : “Il suffit d’un seul des 3 critères [nécessité, proportionnalité, et le troisième n’est même pas mentionné] en défaut pour ne pas pouvoir se placer sous le régime de l’intérêt légitime.”. C’est faux, la nécessité c’est dans TOUS les cas. Pas que pour l’intérêt légitime. Merci d’arrêter de dire n’importe quoi sur le RGPD.
#31
Question, quand tu dis “marketing direct”, est-ce que tu parles de prospection/démarchage (les sms sont envoyés à froid à des gens qui n’ont rien demandé -> du spam quoi), ou de comm promotionnelle qui demande que la personne se soit inscrite (avec consentement) au préalable ?
Parce que dans le cadre de la prospection, effectivement il doit être possible de s’opposer, et donc il te faut une liste d’opposition. (et informer l’utilisateur que tu as besoin de conserver a minima un hash de son numéro pour ta liste d’opposition, comme dit par aeris22) (vous utilisez bloctel? :p )
Mais tu parles de “désabonnement” et pas d’opposition, or ce n’est pas la même chose. Pour qu’il y ait désabonnement, il faut qu’il y ait abonnement, et donc une liste de contacts ayant consenti (avec trace du consentement). Dans ce cadre là, tu n’es de toute façon pas censé envoyer de message à un numéro qui serait hors de ta liste d’abonnement, donc une blocklist n’a pas lieu d’être, pour respecter le RGPD ta boîte devrait avoir une allowlist. Tu devrais alors supprimer le numéro de tes bases, et le remonter au gestionnaire du consentement pour qu’il note qu’il n’a plus le droit d’utiliser le numéro à des fins de communication commerciale.
D’ailleurs, je ne suis même pas certain que la prospection SMS sans consentement préalable soit légale. Si j’en crois la cnil, non: https://www.cnil.fr/fr/la-prospection-commerciale-par-sms-mms
#31.1
Alors en fait ce n’est pas ma base de données, c’est celle de l’utilisateur de notre plateforme. A priori c’est ses clients et il me semble que la RGPD autorise la prospection de produits complémentaire à ses clients avec droits d’opposition.
Nous on leur demande lors de l’import de leur base de s’assurer qu’ils ont bien le consentement de leurs destinataires.
#31.2
En effet, s’il s’agit d’un client de l’entreprise, ça rentre dans le cadre d’une exception.
Du coup à l’exception près de conservation d’un hash plutôt que d’un numéro (minimisation tout ça), c’est all good.
Les guidelines de la cnil pour les listes d’opposition: https://www.cnil.fr/fr/comment-utiliser-une-liste-repoussoir-pour-respecter-lopposition-la-prospection-commerciale
#32
Bon, je vais m’arrêter là, car il semblerait que nous ne nous comprenions pas du tout (et que j’ai l’impression que l’on tourne en rond).
A t’entendre, il n’y a qu’une base légale : le consentement. Ce qui est bien loin de la réalité. Si je suis d’accord qu’il ne faut pas faire n’importe quoi avec les bases légales, et qu’on ne peut pas tout passer via l’intérêt légitime ou via les contrats, il est très dogmatique de dire qu’ils sont tellement restrictif qu’ils en sont inutilisables en pratique.
Une entreprise pré-RGPD, avec un business construit avant l’arrivée du RGPD se retrouve souvent bien enquiquinée car, comme tu le soulignes, le RGPD s’intéresse au service et non au business, et que l’entreprise essaie donc de se mettre en conformité en ne changeant rien et en mettant en place son registre des traitements (un peu caricatural, mais c’est ce que je constate autour de moi, enfin pour les entreprises qui s’intéressent un temps soit peu au RGPD).
Une entreprise post-RGPD qui construit son business en suivant les principes mis en avant par le RGPD s’en sort très bien et n’a pas de souci particulier pour user d’une base légale autre que le consentement.
Tu peux énoncer des contre-vérités à tout va, le fait de les répéter ne changera absolument pas la donne. Par exemple, le RGPD n’impose pas le consentement pour le suivi marketing. Il impose des mesures adaptées et proportionnées. Ce qui est extrêmement différent.
Il suffit de regarder, par exemple, la gestion des cookies, où la CNIL précise les mesures à prendre afin d’éviter de devoir demander le consentement et de pouvoir se baser sur une autre base comme l’intérêt légitime.
Tu démontres clairement la méconnaissance du fonctionnement de l’institution. Une APD peut traiter des dossiers sans avoir à consulter le CEPD avant. Et heureusement !! Sinon, pour toute décision concernant le plombier du coin il faudrait la consultation des 26 autres APD ? Heureusement que ce n’est pas ce qui est mis en place…
Le but du CEPD est, entre autres, de gérer les cas transfrontaliers (en désignant l’APD tête de file si besoin est) et les problèmes (en cas de désaccord entre APD) avec le pouvoir, dans ces cas précis, de donner des décisions contraignantes.
Par contre, certaines décisions des APD sont soumises à consultation effectivement (par ex. modification de la liste des traitements nécessitant une analyse d’impact).
#33
Sur reCAPTCHA, j’ai obtenu la supression de la solution sur le formulaire de l’IGPN https://twitter.com/DavidLibeau/status/1516041376542208012 et je suis en attente concernant le transfert des données aux USA (j’ai attaqué le site de l’Elysée pour que la CNIL se prononce).
#34
Faux, considérant 47 du RGPD : “Le traitement de données à caractère personnel strictement nécessaire à des fins de prévention de la fraude constitue également un intérêt légitime du responsable du traitement concerné.”
#35
Ce que tu cherches c’est le considérant 47 du RGPD qui indique que “Le traitement de données à caractère personnel strictement nécessaire à des fins de prévention de la fraude constitue également un intérêt légitime du responsable du traitement concerné.”
#36
Je suis déçu d’avoir pris un abonnement pour cet article qui reste encore flou sur le RGPD.
On est en 2022 et il n’y a toujours pas d’article concret avec des vrais exemples de A à Z.
J’ai lu les guides et livres blanc de la CNIL et malheureusement c’est toujours aussi flou et vague idem pour leur logiciel PIA qui n’est pas du tout compréhensible.
Obligé d’attendre les condamnations de la CNIL pour comprendre comment appliquer le règlement.
A noter aussi, parce que tout le monde l’oubli sauf la CNIL, le particulier qui héberge son forum sur son raspberry pi à la maison est aussi soumis au RGPD et donc peut avoir une amende. Ce n’est pas que pour les entreprises, mais aussi les particuliers et les associations, donc tout le monde.
D’ailleurs NextInpact pourrait faire un vrai dossier avec plusieurs articles expliquant comment ils mettront leur site nextinpact.com en conformité. Ca répondrait, entre autres, à ces questions sur la rétention des données :
#37
Je ne vois pas en quoi ce que je dis est en contradiction avec mon blog. La nécessité est effectivement partout, et dans le cas de l’IL, il faut en plus la légitimité et la proportionnalité.
Considérant 50 de EDPB 2/2019 : la fraude peut être sous IL uniquement si proportionné et nécessaire. Généralement elle ne l’est pas et enlever la lutte contre la fraude coûte moins cher pour moins de données moins de complexité moins de rétention et moins d’intrusion sur les droits, le tout sans remettre en question le service (vu qu’elle n’est de toute façon pas une obligation contractuelle parce que pas nécessaire au service, même considérant). Dans l’extrêmeme majorité des cas, la lutte contre la fraude ne passe pas le triple test de l’IL permettant de fonder le traitement sur cette base légale. Beaucoup de condamnation et de requalification en consentement à ce sujet par exemple sur le scoring bancaire pour l’obtention de prêt.
#38
Je doute que ça rentre dans le cadre d’une traitement de données personnelles. Les articles d’un journaliste appartiennent généralement au journal qui l’édite, et celui-ci reste crédité au nom du droit d’auteur.
Dans les cas de NXI, non. J’ai pointé ça dans mon premier commentaire #21 mais j’attends bien évidemment un assourdissant silence sur le sujet. De mon point de vue, NXI est en violation du RGPD sur différents points. Il est parfaitement possible que je me trompe, auquel cas je serais ravi d’en avoir l’explication.
Ca oui, les messages de personnes qui ont supprimé leur compte apparaissent en “anonyme_xxxxxx”.
Oui, cela lui permet d’exercer de lui-même son droit à l’effacement (Article 17). A noter que le droit à l’effacement doit s’appliquer aussi sur les sauvegardes de données (d’où sa complexité de mise en oeuvre).
Je dirais que c’est irrévocable, le droit à l’effacement exigeant la suppression ou l’anonymisation des données personnelles dans le cas où l’effacement est impossible. L’anonymisation est censée garantir l’impossibilité de ré-identifier la personne (au contraire de la pseudonymisation). La personne exerçant ce droit est donc censée être informée des tenants et aboutissants d’une telle demande.
A noter que le droit à l’effacement se doit d’être exercé de manière précise et la personne doit spécifier les données qu’elle veut effacer. Si par exemple elle veut effacer une photo sur une site, ça ne nécessite pas forcément la suppression de son compte.
#39
Mais le contenu du message est toujours là ? Il est également une DCP.
En outre quid si le message a été tout ou en partie cité par d’autres utilisateurs ? Et si d’autres utilisateurs ont cité le pseudo de l’utilisateur via les fonctionnalités “Répondre” ou “Citer” ?
#39.1
Dans le cas de NXI, le user cité sera toujours “anonyme_xxxxx”, ce qui répond au critère d’anonymisation du RGPD. C’est justement ce que la CNIL recommande comme méthode lorsqu’on parle de messages sur un fil de discussion pour éviter de perdre sa cohérence (mais aussi pour l’archivage de longue durée par exemple).
Sur les forums type phpBB, les users supprimés sont affichés en tant que “Guest” de mémoire.
#40
Attention, un commentaire ou un message n’est pas nécessairement une données à caractère personnel (ce n’est pas forcément identifiant, même de manière indirect). Mais cela peut l’être ou en contenir.
Par contre, les commentaires sont régis par d’autres droits, notamment le droit d’auteur.
#41
#42
Tu confonds nécessité de traitement pour un service et nécessité des données (minimisation). Ce n’est pas la même chose. La nécessité de traitement pour un service dans le cadre de l’intérêt légitime est défini par l’article 6(1)f, alors que la minimisation des données est prévu par l’article 5(1)c (et non 6(1)c comme écrit sur ton blog) pour tous les traitements pas seulement dans le cadre de l’intérêt légitime.