Le GDPR (ou RGPD en français) est le nouveau règlement européen en matière de protection des données personnelles. Pas d’inquiétude, je ne vais pas faire de présentation complète du sujet! C’est indigeste et je ne suis pas coutumier des gros dossiers. Il s’agit d’un article de vulgarisation, il y a des raccourcis et des approximations, l’objectif est de donner un aperçu grossier de ce que la GDPR implique.
De plus, l’article sera très grandement inspiré de l’article anglophone de Bozho (n’hésitez pas à lire la version originale), ce dernier est très orienté pour les développeurs. Nous allons plutôt parler fonctionnalité et implémentation que règlement.
Le GPDR en bref
Si vous avez déjà de bonnes notions sur le sujet de le GDPR et qu’un rafraichissement de mémoire n’est pas nécessaire passez ce chapitre.
Le GDPR, pour General Data Protection Regulation, ou RGPD, pour Règlement général sur la protection des données est un nouveau règlement européen applicable à la date du 25 mai 2018. Ce dernier redéfinit complètement les obligations des entreprises envers les données personnelles de leurs utilisateurs et clients.
Le RGPD regroupe une centaine d’articles qui seront autant de lois dans chacun des pays de l’union européenne. Mais si je dois résumer en une dizaine de points importants :
- Il s’agit d’un règlement, avec des articles de loi et non une directive
- Des sanctions extrêmement lourdes, 20 M€ minimum ou 4% du chiffre d’affaires mondiales
- Déclaration contraignante de l’utilisation des données utilisateurs
- Obligation de sécurisation des données (chiffrement et anonymisation)
- Obligation de déclaration des fuites de données sous 72 heures après la découverte
- Ne pas collecter de données superflues
- Le traitement des données recueillis doit être justifié et transparent
- Proposer des mentions légales intelligibles (compréhensibles pour un humain non juriste)
- Respect du droit à la portabilité des données
- Droit a l’oubli
- Et bien d’autres ….
Je vous laisse découvrir ce très bon dossier (20 minutes de lecture environ) pour aller plus loin sur le sujet si vous êtes curieux.
Qui est concerné ? Toutes les entreprises européennes et toutes entreprises ayant des clients en Europe.
Il y a plein de changements dans la gestion des données en perspective. Aujourd’hui, cette gestion de données est souvent l’affaire des logiciels et par conséquent des développeurs.
Impact de le GDPR (ou RGPD) sur les développements
L’ensemble des obligations qui découle de le GDPR vont nous (les développeurs) obliger à revoir certaines fonctionnalités des logiciels gérant des données personnelles.
Commençons par une définition, qu’est-ce-que sont les données personnelles ? Ce sont l’ensemble des données qui permettent d’identifier directement ou indirectement (par recoupement par exemple) une personne.
Le droit à l’oubli
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.
Avoir une telle fonctionnalité est également intéressant en intégration pour tester, par exemple, différents uses cases.
Cependant, tout n’est pas si simple, de nombreuses données de votre application seront probablement liées (par des clefs étrangères, en base, le plus souvent) à l’utilisateur. Deux choix principaux s’offrent à vous : supprimer l’ensemble des données liées à cet utilisateur (cascade) ou vider la valeur des clefs étrangères.
Autre précision importante, il faut notifier l’ensemble des logiciels/API et autres services tiers (service cloud, réseaux sociaux) pour qu’ils suppriment l’ensemble des données personnelles de l’utilisateur.
Export de données
Le GDPR prévoit que l’utilisateur puisse récupérer l’ensemble de ces données personnelles. Il est indispensable de prévoir une fonction qui permet à l’utilisateur d’exporter ces données. Les données à lui retourner sont celles que vous auriez effacées si ce dernier exerce son droit à l’oubli.
L’ensemble de ces données doit impérativement être dans un format standard pour respecter l’interopérabilité demandée par le GDPR. Cela peut simplement être un fichier XML ou JSON, en utilisant, par exemple, le formalisme défini par schema.org.
Quelques grosses entreprises comme Google, Facebook ou Twitter ont déjà implémentés cette fonctionnalité, je vous laisse tester par vous-même c’est assez effrayant de voir la taille des archives…
Donner à l’utilisateur le droit de modifier ces données
Ce point semble évident… mais l’utilisateur doit pouvoir modifier ces données personnelles. Un détail tout de même, il en est de même des informations que vous avez récupérées via des applications tierces, comme Facebook par exemple.
Rien n’oblige à avoir des formulaires éditables, cela peut passer par une demande de modification manuelle à un support. Mais un formulaire reste tout de même beaucoup moins cher à entretenir à terme!
Gestion du consentement utilisateur
Le GDPR prévoit également que l’utilisateur autorise le traitement de ces données personnelles. Il peut également revenir à n’importe quel moment sur les droits qu’il a donné dans le passé. Une simple validation des conditions d’utilisation ne suffira plus. De plus, par défaut, les droits devront être désactivés.
Par conséquent, l’utilisateur doit pouvoir avoir une interface qui lui permette de gérer les autorisations qu’il donne à votre application/site web. On peut imaginer un ensemble de switch ou de checkboxs afin de gérer chacun des droits demandés. Ci-contre un exemple de ce que fait endroit pour chaque application aujourd’hui.
NB : Les données nécessaires à des obligations légales (facture, fiche de paie etc…) seront soumis à une régime particulier et ne nécessiteront pas d’autorisation si l’utilisation de ces dernières est exclusif aux obligations légales.
Vérification de l’âge
Une autre évolution apportée par le GDPR est l’ajout d’un âge de consentement parental. Si un utilisateur de moins de 16 ans s’inscrit sur une plateforme, il est nécessaire de demander le consentement des parents. Ici difficile de donner des recommandations, on sait à quel point les systèmes de vérification pour les sites pour adultes sont efficaces…
Un piste est de demander un email parental, mais les petits malins auront vite fait de demander à un ami ou de créer une seconde adresse email afin de s’auto-valider.
Ne gardez pas les données plus longtemps que nécessaire
Là encore, le GDPR change les règles, une fois que vous avez utilisé une donnée, cette dernière doit être supprimée ou anonymisée. La loi ne permettra plus de conserver une donnée pour un traitement ultérieur non-défini.
Pour ce cas, partons d’un exemple, pour un site de e-commerce, cela veut dire qu’une fois que la livraison est effectuée (produit arrivé chez le client) les données liées cette commande comme les données bancaires, l’adresse ou les noms doivent être supprimées.
La solution technique résidera probablement dans un script s’exécutant à intervalles réguliers qui vérifiera si la condition de suppression des données (dans notre exemple, la validation de la livraison) est remplie et qui les effacera si c’est le cas.
Protection des données dans le GDPR
Le GDPR formalise aussi certaines bonnes pratiques liées à la sécurité des données :
- Chiffrer les communications entre machine (over HTTP avec TLS par exemple)
- Chiffrer les bases de données ou les disques machines où les données utilisateurs sont stockées (par exemple avec LUKS)
- Chiffrer vos backups
- Anonymiser/pseudonimiser les données en tests, de même pour les algorithmes de machine learning (hash + salt les données par exemple)
- Tenir un journal des modifications de données personnelles, cela sera très utile pour la mise en place des permissions à demander par exemple…
- Logger les accès aux données privées, attention toutefois à ne pas écrire dans les logs de données personnelles
Ce qu’il ne faut surtout pas faire
Il faut absolument respecter certaines règles pour être conforme aux règles de le GDPR:
- Ne jamais utiliser de données utilisateurs sans demander d’autorisation explicite quel que soit l’objectif final (machine learning, publicité, exposition des données via API)
- Ne pas mettre de données personnelles dans les logs de votre application
- Ne récupérer les données que si elles sont nécessaires dans vos formulaires (inscription, commande …)
- Vérifier que les parties tierces respectent également le GDPR, l’application principale est responsable des données transmises à ces tierces parties
- Être ISO XXXXX ne veut pas dire respecter la GPDR, certes le gros du travail est déjà fait, mais cela n’est pas suffisant
Les sous-traitants ne sont pas responsable de la bonne application du GDPR
Une action administrative de la CNIL contre Darty à déboucher sur une décision contre Darty.
Pour faire simple, Darty passe par un sous-traitant pour la réalisation de son site web, il se trouve que, dans un formulaire de contact, il y a une faille de sécurité béante, qui ne sera pas corrigée rapidement malgré l’avertissement de la CNIL.
D’une manière générale, une entreprise est responsable de l’ensemble de ces outils informatiques même si ces derniers sont développés et maintenus par un tiers!
Pour finir
Avoir connaissance des grandes lignes de cette nouvelle régulation est important, à plusieurs égards.
Premièrement, vous pourrez en parler à votre responsable et/ou votre client afin de savoir s’il a conscience des changements de régulation à venir et éviter une amende potentielle de plusieurs millions.
Deuxièmement, les obligations de la GPDR vous donnent les grandes lignes pour une mise en place d’une gestion de données sensibles, chose que beaucoup de petites sociétés sont souvent incapables de faire, par manque de compétence, au sein de l’entreprise.
Et enfin pour les utilisateurs, cette réglementation va obliger les entreprises à plus de transparence sous peine de se voir lourdement sanctionnées. Cette transparence permettra à l’utilisateur de reprendre, un peu, le contrôle de ces données. Comme utilisateur, j’ai hâte de voir les effets d’ici quelques mois de cette régulation sur les entreprises qui basent leurs modèles économiques sur l’exploitation des données personnelles (google, facebook et consorts).
Si vous avez apprécié l’article, vous pouvez le partager pour mon plus grand plaisir ;). Et laissez moi un retour sur cet article en attribuant une note (système d’étoiles en dessous de l’article) ou en laissant un commentaire.
Sources :
- [EN] L’article anglophone de Bozho dont je me suis largement inspiré
- [FR] Dossier RGPD plus complet
- [FR] article wikipedia
«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.
Comment un article de 1300 mots (présentation et conclusion comprise) 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.
Je t’invite avec plaisir à faire un commentaire plus constructif, je l’intégrerai volontiers au sein de l’article pour le compléter!
J’ai ajouté une petite phrase dès l’introduction pour enlever toute ambiguïté sur l’objectif de l’article.
Je reposte ici mon commentaire dans le Journal du Hacker :
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
Ok merci pour ta réponse.
J’imagine qu’à la base le texte a été crée pour cibler Facebook, Google etc…
J’espère juste qu’il sera utilisé à bon escient, comme tu le dis lorsque qu’il y a atteinte à l’intégrité physique et/ou morale des personnes, et non à tout bout de champs pour remplir les caisses …
Tu maîtrises vraisemblablement le sujet plus que moi, je ne vais pas contredire tes arguments. Très clairement mon article visez plus à vulgariser le sujet pour que les gens s’y intéressent. C’est chose faite, c’est un de mes articles les plus lus en 2 jours.
Si des personnes veulent creuser le sujet, j’ai linké quelques liens et il y a le règlement qui est aussi disponible.
Merci pour ton retour (très) intéressant !
Je trouve ton article très bon et surtout opérationnel ce qui est rare sur le sujet. Peut être manque t’il la manière de gérer la portabilité des données d’une entreprise vers une autre ? On ne voit pas vraiment un client demander cela directement mais c’est pourtant une vraie obligation. Je suis curieux de savoir comment tu gérerais ça.
Merci Canteau! Je n’ai pas connaissance de standard global, je pense que le monde bancaire en a un (mobilité bancaire depuis début 2017 si je dis pas de bêtise).
Pour moi, les solutions facebook, google etc… sont les meilleurs. Permettre à l’utilisateur de récupérer ces données dans des formats standards (XML, JSON) en suivant comme je l’indique un formalisme dit « classique » tel que celui de schema.org. C’est à l’autre entreprise de permettre l’import adapté, si elle le souhaite.
Bonjour, parfois on parle aussi du RGPD, vous devriez ajouter l’abréviation à votre article pour améliorer le référencement.
Bonjour, Effectivement c’est l’anagramme Français. C’est une bonne idée !
C’est un intéressant travail de synthèse, et vous citez vos sources : bravo. Par contre, dommage de ne pas avoir consulté les sources de vos sources. Avez-vous lu le RGPD ? Pour l’avoir consulté, je n’ai pas trouvé un certain nombre de notions, telles que l’obligation d’avoir un bouton d’export automatisé (cf Article 20, « droit à la portabilité » du RGPD), ni d’obligation de chiffrer les données (mais plutôt obligation de se poser la question, cf Article 32 « Sécurité des données à caractère personnel » du RGPD).
Enfin, concernant Darty, la source (la CNIL) précise pourquoi elle a infligé une amende de 100k€ : non pas pour la fuite des données, mais pour ne pas avoir désactivé le formulaire incriminé tout en ayant dit le contraire (= mentir à la CNIL) et pour ne pas avoir bouché le trou de sécurité signalé 15 jours plus tôt. Source: https://www.cnil.fr/fr/darty-sanction-pecuniaire-pour-une-atteinte-la-securite-des-donnees-clients
Merci pour ton retour, non je n’ai pas lu intégralement la RGPD. Certains passages et surtout plusieurs sources sur le sujet(dont j’ai retenu les plus intéressante) . Une fois les grosses lignes comprises, je parle avec mon expérience de développeur plus que mon expérience de juriste (qui est nulle …). Ce que je propose, ce sont des exemples d’implémentation possible.
Effectivement, je n’étais pas remonté jusqu’à la déclaration sur le site web de la cnil, j’ai écris ce paragraphe au dernier moment, un peu trop rapidement. Je pense que l’idée principale reste valable, l’entreprise est responsable de la protection de ces données même si elle passe par des sous-traitants. EDIT : J’ai légèrement modifié le paragraphe!
Une question législation : Le GPDR est un règlement Européen, mais si un de mes sites tourne sur un serveur situé en Inde, cette règlementation s’applique-t-elle encore parce que j’ai une entreprise française, ou alors est-ce le lieu du serveur hébergeant le site qui est pris en compte ?
Pour simplifier, toutes les entreprises en Europe ou travaillant avec l’Europe sont concernées.
Plus précisément (de mémoire), toute entreprise de l’union européenne ou toute entreprise qui traite des données des citoyens présents au sein de l’union européenne (pas forcement citoyen européen) est concerné par ce règlement. Donc à priori ton entreprise Française est concerné.
Le RGPD s’applique au traitement des données à caractère personnel effectué dans le cadre des activités d’un établissement d’un responsable du traitement ou d’un sous-traitant sur le territoire de l’Union Européenne, que le traitement y ait lieu ou non.
Donc, si le traitement est techniquement réalisé en Inde, mais que l’entreprise réside dans l’Union, le RGPD s’applique.
J’ajoute que le RGPD s’applique également si l’entreprise ne réside pas dans l’Union Européenne et qu’elle traite des données de résidents européens dans un contexte de vente de biens ou de services, ou qu’elle réalise le profilage du comportement de résident de l’Union, à condition que le comportement profilé le soit sur le territoire de l’Union.
Donc, pour résumer, si ton entreprise manipule des données personnelles directement ou indirectement et réside sur le territoire de l’Union, ou qu’elle n’y réside pas et qu’elle profile le comportement de résident de l’Union ou qu’elle y fait de la vente de bien ou de service en collectant de la données personnelles de résident de l’Union, alors le RGPD s’applique.
(source https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre1#Article3)
Merci à tous pour vos réponses, qui soulèvent chez moi une autre question :
Comment dans la pratique, des sanctions pourraient-elles être infligées à une entreprise située dans un paradis fiscal à l’autre bout de la planète, dont le site est hébergé sur le sol de ce dernier ?
Cela me paraît compliqué à mettre en oeuvre par la CNIL, non ?
Il ne faut pas négliger les instances juridiques et judiciaires internationales de l’Union qui peuvent être actionné par la CNIL et utiliser le droit international pour demander la fermeture du service.
Après, dans quel délai… je n’ai pas la prétention d’avoir la réponse, mais si l’infraction est importante ou susceptible de porter atteinte à l’intégrité morale ou physique des personnes, je pense qu’on pourrait être surpris.
Le RGPD est un texte qui a été clairement forgé pour être utilisé et efficace (et certains vont même jusqu’à dire qu’il est taillé sur-mesure pour atteindre certaines cibles, et ce n’est pas l’affaire Facebook/Whatsapp qui va infirmer cette rumeur), donc je doute que le bâton ne soit pas en mesure de taper comme il faut sur qui il faut (ou du moins, j’espère que c’est bien le cas, sinon, ça va être la porte ouverte à absolument tout et n’importe quoi).
Bref, si t’es pas dans les clous, je pense que tu es vraiment susceptible de prendre très cher.
Ping : Dossier : du RGPD à l'ERP : l'impact sur l'organisation des ESN (1/2)
Vous écrivez: « Les sous-traitants ne sont pas responsable de la bonne application du GDPR »
Ouh la, attention : c’est totalement faux !
Sous le GDPR, bien au contraire, le « sous-traitant » a également et pleinement une part de responsabilité dans le traitement qu’il effectue pour le compte du « responsable du traitement ». C’est une des grandes nouveautés du règlement GDPR par rapport à la directive actuelle ( 95/46/CE ).
https://www.cnil.fr/fr/reglement-europeen-sur-la-protection-des-donnees-un-guide-pour-accompagner-les-sous-traitants
Accessoirement, la CNIL est une autorité administrative qui a légitimité pour décider de sanctions (conformes aux textes bien entendu).
Dans l’affaire Darty, ce n’est donc pas « une action en justice » mais une sanction administrative. Et cette sanction correspond à une application du texte actuel (directive 95/46/CE) et non pas le GDPR qui n’est pas encore en application.
Sous le GDPR, le sous-traitant pourra (aussi) être sanctionné en cas de manquement à ses obligations.
Non seulement des raccourcis et des approximations comme annoncé en début d’article, mais de (graves) erreurs également: ne laissez pas penser à des développeurs sous-traitants qu’ils n’ont pas de responsabilité dans le traitement qui leur est confié !
Pour le premier point, effectivement, j’ai pas fait attention au mot utilisé, je corrige, merci.
Pour le second, je n’ai jamais stipulé que la condamnation est au titre de la GDPR. Et bien entendu que le sous-traitant pourra avoir des sanctions, il y a forcement des contrats entre une entreprise et ces prestataires. Une erreur ou une négligence coûtera cher aux prestataires au titre de ce contrat et, à confirmer, en cas de négligence avér,é il pourrait être poursuivi également.
Vous comprenez bien que je ne ferai pas un article en conseillant un certains nombres d’implémentations possibles et en invitant à creuser le sujet, tout en dédouanant les développeurs qui ne mettrait pas cela en place.
« Logger les accès aux données privées, attention toutefois à ne pas écrire dans les logs de données personnelles »
Le login utilisateur est-il une donnée privée ? J’espère qu’on peut toujours loguer le login de la personne à l’origine de l’action, genre « User wodric logged in » ou « Settings modified by user wodric »
De mon point de vue, oui. Pour plusieurs raisons : Le login est au choix de l’utilisateur il peut y mettre son nom, prénom ou d’autres informations permettant de l’identifier s’il le souhaite. Pour prendre l’exemple du pseudo Wodric, je l’utilise sur plusieurs sites dont ce blog où pas mal de mes informations sont public, donc par recoupement il est facile de comprendre qui est « Wodric ». Lel pseudo permet de retrouver directement ou indirectement une personne.
Le plus simple est, je pense, d’utiliser l’id en base de l’utilisateur.
J’ai pu poser cette question h*du login dans les logs hier à un spécialiste du sujet.
En fait c’est assez simple : la GRPD n’empêche pas d’enregistrer des informations personnelles, mais demande de pouvoir argumenter de leur pertinence / besoin, tracer où elles se trouvent et définir une durée de vie en rapport avec le besoin.
Donc dans le cas du fichier de log d’une application legacy qui ne peut pas (facilement) être modifiée, c’est pas un souci. Il suffit de définir une politique claire vis à vis du stockage et de la durée de vie de ces logs. En fait même une appli normale peut logger le login dans ses logs car le problème n’est pas à ce niveau. La question est : où sont stockés les logs et pour combien de temps?
Maintenant si pour des raisons légales vous avez obligation d’archiver ces logs pour une durée de 2 ans pas exemple, alors cette obligation prend le dessus sur la GRPD.
Merci pour ce retour.
De manière générale, ne logger qu’un Id et non des données est une bonne pratique niveau sécurité. Si une fuite à lieu un jour, cela peut vite être problématique dans des secteurs sensibles .
Exemple concret, je suis prestataire d’une banque privé en ce moment, exposer des noms de clients serait extrêmement dommageable pour l’image de la banque.
Je pense que l’anonymisation des logs est une bonne pratique. Nous avons généralement très facilement le moyen de le faire (en utilisant les ids) pourquoi s’en priver.
Concernant l’historisation des logs, c’est un tout autre sujet, soumis à différentes obligations légales.
Bonjour,
J’ai du mal avec le terme « responsable de traitement », « s’assurer du fondement juridique du traitement » etc.
J’ai l’impression que le terme traitement est utilisé partout pour plein de chose.
Auriez-vous une définition clair d’un responsable de traitement?
Sinon super article, merci 🙂
Hello Mathieu,
Le responsable du traitement, c’est celui qui décide à quoi le fichier constitué avec les données personnelles des usagers va servir et par quels moyens on va exploiter ces données.
Ce que dit l’article 4.7 du RGPD :
«responsable du traitement», la personne physique ou morale, l’autorité publique, le service ou un autre organisme qui, seul ou conjointement avec d’autres, détermine les finalités et les moyens du traitement; lorsque les finalités et les moyens de ce traitement sont déterminés par le droit de l’Union ou le droit d’un État membre, le responsable du traitement peut être désigné ou les critères spécifiques applicables à sa désignation peuvent être prévus par le droit de l’Union ou par le droit d’un État membre;
La personne concernée par le traitement de ses données personnelles a un droit d’information complet imposé par le RGPD et qui peut être sanctionné, en cas de violation, par de fortes amendes
Bonjour Wodric et félicitation pour cet article. C’est vraiment bien que les développeurs s’emparent du RGPD et anticipent les modifications et changements à venir ! J’attire votre attention sur la question du consentement.
Une checkbox ne suffit pas à rendre un consentement valable. Il faut en effet fournir un certain nombre d’informations :
1. quelle est la finalité du traitement ? Quelles données précisément, à quoi servent-elles, pendant combien de temps sont-elles stockées ?
2. ses données données font-elles l’objet d’un traitement automatisé ? si oui, il faut permettre une intervention humaine sur réclamation
3. qui est le responsable du traitement, quelles sont ses coordonnées ?
4. les données sont-elles envoyées en dehors de l’UE ? Si oui, quelles mesures ont été prises pour les protéger ?
5. comment retirer mon consentement ?
De plus, il est désormais de la responsabilité de l’entreprise de conserver une preuve attestant du consentement. Cette preuve peut être, par exemple, un enregistrement horodaté, du clic sur la checkbox.
Bref, ça fait pas mal de boulot pour une simple case à cocher 😉
Bonjour Romain,
Désolé du délai de réponse.
Oui de simple checkboxs ne suffisent pas il faut premettre à l’utilisateur de comprendre quel est l’implication d’accepter chaque check box. On peut imagine panel dépliant pour avoir toutes les informations, ou même avec les infos entre chaque demande d’autorisation.
Il faut effectivement qu’un ensemble d’information soit disponible à l’utilisateur dont celle que tu as cité.
« il est désormais de la responsabilité de l’entreprise de conserver une preuve attestant du consentement. » -> Tout à fait ! C’est tout l’enjeux de la GDPR, l’entreprise doit démontrer que l’utilisateur accepte chaque traitement de ces données personnelles
C’est étonnant l’article ne parle pas du tout des cookies, un point de rappel me semble intéressant.
Ping : RGPD, quel impact pour les ERP ? par @pscoffoni - Philippe Scoffoni - Logiciel libre, open source, numérique