RGPD : Un guide pratique pour les d?veloppeurs

Cet article vous expliquera les grandes lignes de la RGPD (R?glementation G?n?rale sur la Protection des Donn?es).

Il vous pr?sentera les aspects concernant le d?veloppement, la loi entrant en vigueur le 25 mai 2018.

Article lu   fois.

Les deux auteur et traducteur

Site personnel

Traducteur : Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

1. Introduction

Vous avez probablement entendu parler de la RGPD (R?glementation g?n?rale sur la protection des donn?es - General Data Protection Regulation?- GDPR en anglais), la nouvelle r?glementation europ?enne qui s'applique ? tout le monde. Si vous travaillez dans une entreprise de taille importante, il est fort probable qu'un processus de mise en conformit? soit en cours.

Cette r?glementation est une loi qui doit ?tre suivie dans tous les pays europ?ens (mais qui s'applique aussi aux entreprises hors d?Europe qui ont des utilisateurs en Europe). Dans ce cas particulier, elle s'applique aux entreprises non europ?ennes, mais qui ont des clients europ?ens, ce qui est le cas de la plupart des entreprises. Je ne vais pas entrer dans un autre livre blanc ??les douze r?alit?s sur la RGPD?? ou ??les sept mythes sur la RGPD??, souvent destin?s aux managers ou aux juristes. ? la place, je vais me concentrer sur ce que la RGPD signifie pour les d?veloppeurs.

Pourquoi suis-je qualifi? pour cela?? Pour plusieurs raisons. J'ai ?t? conseiller du vice-premier ministre d'un pays de l'Union europ?enne, et, car j'ai ?t? expos? et ai moi-m?me ?crit une l?gislation. Je suis familier avec le jargon juridique et du fonctionnement du cadre r?glementaire en g?n?ral. Je suis aussi un d?fenseur de la vie priv?e et j'ai ?crit sur la RGPD dans le pass?, c'est-?-dire ??avant que ce soit cool?? (protecting sensitive data, the right to be forgotten). Et enfin, je travaille actuellement sur un projet qui (parmi d'autres choses) vise ? aider ? couvrir certains aspects de la RGPD.

Je vais essayer d'?tre complet et de couvrir autant d'aspects que possible de la r?glementation qui concernent les d?veloppeurs. Et tandis que les d?veloppeurs seront principalement pr?occup?s des changements ? effectuer sur leurs travaux, il n'est pas improbable qu'un gestionnaire moins averti arrive au dernier moment, r?alisant que la RGPD sera en vigueur demain demandant ??que devrions-nous faire pour que notre syst?me/site interne soit conforme????

2. Les principes et droits des utilisateurs

Les droits de l'utilisateur/du client (mentionn? en tant que ??sujet de donn?es?? dans la r?glementation), qui, je pense, rel?vent du d?veloppeur sont?:

  • le droit ? l'effacement (le droit d'?tre oubli?/supprim? du syst?me)?;
  • le droit ? la restriction du traitement (vous gardez toujours les donn?es, mais les marquez comme ??limit?es?? et ne les touchez pas sans un consentement suppl?mentaire de l'utilisateur)?;
  • le droit ? la portabilit? des donn?es (la possibilit? de les exporter dans un format lisible informatiquement)?;
  • le droit ? la rectification (la possibilit? d'avoir ses donn?es personnelles corrig?es)?;
  • le droit d'?tre inform? (avoir des informations humainement lisibles, plut?t que de longues conditions)?;
  • le droit d'acc?s (l'utilisateur devrait pouvoir voir toutes les donn?es que vous avez sur lui).

De plus, les principes de base pertinents sont?:

  • la minimisation des donn?es (ne pas collecter plus de donn?es que n?cessaire)?;
  • l'int?grit? et la confidentialit? (toutes les mesures de s?curit? que vous pouvez imaginer pour prot?ger les donn?es et des mesures pour garantir que les donn?es ne seront pas modifi?es de mani?re inappropri?e).

Encore plus, la r?glementation requiert la mise en place de certains processus ? l?int?rieur des structures traitant des donn?es personnelles (structures de plus de 250 employ?s ou traitant un volume significatif de donn?es), et ceci inclut de garder un enregistrement de tous les traitements r?alis?s, incluant les transferts ? d'autres intervenants tiers, ce qui inclut les fournisseurs de services cloud. Aucune exception n'est pr?vue en fonction de la taille de la structure qui traite les donn?es. ??Je suis petit, la RGPD ne me concerne pas?? est un mythe.

Il est important de savoir ce qu'est une ??donn?e personnelle??. Fondamentalement, il s'agit de chaque morceau de donn?e pouvant ?tre utilis? pour identifier une personne de fa?on unique ou d'une donn?e ?tant d?j? une personne identifi?e. Ce sont les donn?es que l'utilisateur a explicitement fournies, mais aussi les donn?es que vous avez collect?es sur lui par le biais d'un tiers, ou bas?es sur son activit? sur le site (ce qu'il a consult?, ce qu?il a achet?, etc.).

Ceci ?tant dit, je vais lister un nombre de fonctionnalit?s qui devront ?tre impl?ment?es et quelques astuces sur comment le faire. Notez que (comme indiqu? dans chacune d'entre elles), elles ne devront pas forc?ment ?tre automatis?es, vous pouvez avoir un processus manuel en place. Mais pour les syst?mes les plus gros, il sera mieux d'automatiser.

3. Les fonctionnalit?s ? impl?menter

3-1. Oubliez-moi

Pour la fonctionnalit? ??Oubliez-moi??, vous devez avoir une proc?dure qui prend en param?tre un identifiant utilisateur et efface toutes ses donn?es personnelles (dans le cas d'une collecte sur la base d'un consentement ou bas?e sur l'int?r?t l?gitime du responsable des donn?es personnelles (voir plus bas) et non pas en raison de l?ex?cution d'un contrat ou d?obligation l?gale).

Il est utile pour les tests d'int?gration d'avoir cette fonctionnalit?(pour un nettoyage apr?s test), mais cela peut ?tre difficile ? impl?menter selon le mod?le de donn?es. Dans un mod?le de donn?es ordinaire, supprimer un enregistrement peut ?tre facile, mais certaines cl?s ?trang?res peuvent ?tre enfreintes. Cela signifie que vous avez deux options?:

  • vous assurer que vous autorisez les cl?s ?trang?res pouvant ?tre ? NULL (par exemple, une commande a g?n?ralement une r?f?rence ? son auteur, mais quand l'utilisateur demande la suppression de ses donn?es, vous pouvez donner la valeur NULL au userID)?;
  • ou vous assurer de la destruction de toutes les donn?es relatives (par exemple en cascade).

Ceci peut ne pas ?tre souhaitable, exemple?: si les commandes sont utilis?es pour tracer les quantit?s disponibles, ou ? des fins comptables.

C'est un peu plus compliqu? pour l?approvisionnement d??v?nements, ou dans des cas extr?mes, ceux incluant un genre de blockchain/de hash de structure/cha?ne de donn?es inviolable. Avec l'approvisionnement d??v?nements, vous devriez pouvoir retirer un ?v?nement pass? et r?g?n?rer des instantan?s interm?diaires. Pour les structures de type blockchain, faites attention ? ce que vous y stockez, et ?vitez d'y mettre des donn?es personnelles d'utilisateurs. Il y a l'option d'utiliser une fonction de hashage cam?l?on, mais c'est sous-optimal. Vous devez globalement constamment penser ? comment supprimer les donn?es personnelles. Et ??Notre mod?le de donn?es ne le permet pas?? n'est pas une excuse. Et ? propos des sauvegardes?? Id?alement, vous devez garder une table s?par?e pour les identifiants des utilisateurs oubli?s, donc ? chaque restauration d'une sauvegarde, vous r?oubliez les utilisateurs oubli?s. Cela signifie que la table devrait ?tre dans une base de donn?es s?par?e ou avoir un processus de sauvegarde/restauration s?par?.

3-2. Notification des suppressions aux tiers

Supprimer les donn?es de votre syst?me c'est une chose, mais vous ?tes aussi oblig? d'informer tous les tiers ? qui vous avez pouss? les donn?es. Donc, si vous avez envoy? des donn?es personnelles ? des services externes tels que Salesforce, Hubspot, Twitter, ou tout autre fournisseur de service cloud, vous devrez appeler une API de leur cru permettant la suppression de donn?es personnelles. Si vous ?tes un tel fournisseur, votre point final ??oubliez-moi?? devra ?tre apparent. Appeler l'API tierce pour supprimer des donn?es n'est pas tout, quoique. Vous devez ?galement vous assurer que l'information n'apparaisse pas dans des r?sultats de recherche. Maintenant, c'est d?licat, car Google n'a pas d'API de suppression, seulement un processus manuel. Heureusement, c'est seulement pour les pages de profils publics navigables et accessibles par Google (et d'autres moteurs de recherches, bien entendu), mais vous avez toujours ? prendre des mesures. Id?alement, vous devriez faire retourner une erreur HTTP 404 sur la page de donn?es personnelles pour qu'elle puisse ?tre supprim?e.

Article 19 de la RGPD.

3-3. Restreindre le traitement

Dans votre panneau d'administration, o? il y a une liste d'utilisateurs, il devrait y avoir un bouton ??restreindre le traitement??. La page r?glages utilisateur devrait ?galement l'avoir. Lors de son clic (apr?s lecture de l'information appropri?e), il devrait marquer le profil comme restreint. Cela signifie qu'il ne devrait plus ?tre visible par l'?quipe du backoffice, ou publiquement. Vous pouvez impl?menter ceci avec un simple drapeau ??restreint?? dans la table ??utilisateurs?? et un peu de clauses ??si?? ici et l?.

Article 18 de la RGPD.

3-4. Export des donn?es

Il devrait y avoir un autre bouton ??export des donn?es??. Lors de son clic, l'utilisateur devrait recevoir toutes les donn?es que vous poss?dez sur lui. Ce que sont exactement ces donn?es d?pend du cas de figure. Habituellement, il s'agit d?au moins les donn?es que vous supprimez avec la fonctionnalit? ??oubliez-moi??, mais peut inclure des donn?es additionnelles (ex. les commandes faites par l'utilisateur ne devraient pas ?tre d?truites, mais incluses dans le dump). La structure du dump n'est pas strictement d?finie, mais ma recommandation serait de r?utiliser les d?finitions de schema.org. Autant que possible, soit JSON ou XML. Si les donn?es sont suffisamment simples, un simple export CSV/Excel devrait ?tre suffisant.

Quelquefois, l'export de donn?es peut prendre du temps, le bouton peut donc d?clencher un processus en t?che de fond, qui pourra ensuite notifier l'utilisateur par mail quand ses donn?es seront pr?tes (Twitter par exemple le fait d?j?, vous pouvez demander tous vos tweets et les obtenir apr?s un moment). Vous ne devez pas forc?ment impl?menter un export manuel, bien que ce serait plus pratique. Il est suffisant d'avoir un processus en place permettant aux utilisateurs de demander l'acc?s ? leurs donn?es, qui peut ?tre un processus manuel de requ?te sur la base de donn?es.

Article 20 de la RGPD.

3-5. Permettre aux utilisateurs d'?diter leur profil

Cela semble une r?gle ?vidente, mais elle n'est pas toujours suivie. Les utilisateurs doivent pouvoir modifier toutes les donn?es les concernant, incluant les donn?es que vous avez collect?es depuis d'autres sources (par exemple en utilisant un login avec Facebook vous devriez avoir r?cup?r? leur nom et adresse). R?gle g?n?rale, tous les champs dans votre table ??utilisateurs?? devraient ?tre ?ditables via l'interface graphique. Techniquement, une rectification peut ?tre faite via un processus de support manuel, mais ceci revient normalement plus cher pour une entreprise que de simplement avoir le formulaire pour le faire. Cependant, il y a un autre sc?nario, quand vous avez obtenu les donn?es d'autres sources (c?est-?-dire les utilisateurs ne vous ont pas fourni directement le d?tail de leurs informations directement). Dans ce cas, ils devraient quand m?me y avoir une page o? ils peuvent en quelque sorte s'identifier (via une adresse mail et/ou une confirmation par SMS) et obtenir l'acc?s ? leurs donn?es.

Article 16 de la RGPD.

3-6. Consentement par cases ? cocher

??J'accepte les termes et conditions?? ne sera plus suffisant pour pr?tendre que l'utilisateur a donn? son consentement au traitement de ses donn?es. Donc, pour chaque activit? particuli?re de traitement, il devrait y avoir une case ? cocher s?par?e sur l'?cran d'enregistrement (ou le profil utilisateur). Vous devrez garder ces cases ? cocher dans des colonnes s?par?es de la base de donn?es, et laisser l'utilisateur retirer son consentement (en d?cochant ces cases depuis son profil, voir le point pr?c?dent). Id?alement, ces cases ? cocher devraient provenir directement de l'activit? de traitement de l'enregistrement (si vous en gardez un).

Notez que ces cases ? cocher ne devront pas ?tre pr?s?lectionn?es, ceci ne comptant pas comme un ??consentement??. Une autre chose importante ici concerne le machine learning/l'intelligence artificielle. Si vous allez utiliser les donn?es des utilisateurs pour entra?ner vos mod?les ML, vous devrez ?galement obtenir le consentement pour cela (sauf ? des fins scientifiques, lesquelles ont un traitement sp?cifique). Notez ici le traitement appel? ??int?r?t l?gitime??. C'est ? l'?quipe juridique de d?cider ce qui est d'un int?r?t l?gitime, mais le marketing direct est inclus dans cette cat?gorie, comme tout traitement de bon sens relatif ? l'activit? commerciale. Si par exemple vous collectez des adresses d'exp?dition, c'est ?videmment l?gitime. Toutes les activit?s de traitement ne n?cessitent pas de cases ? cocher de consentement.

Article 7 de la RGPD.

3-7. Redemande de consentement

Si le consentement qu'ont donn? les utilisateurs n'?tait pas clair (exemple?: simple accord aux termes et conditions), vous devrez le r?obtenir. Pr?f?rez donc une fonctionnalit? de mass-mailing pour demander aux utilisateurs d'aller dans leur page de profil et v?rifier toutes les cases ? cocher pour les traitements sur leurs donn?es personnelles.

3-8. Voir toutes mes donn?es

Ceci est similaire au bouton ??export??, mis ? part que les donn?es devraient ?tre visibles dans une interface graphique r?guli?re plut?t que dans un format JSON/XML. Je ne dirai pas que c'est obligatoire, et vous pouvez le laisser comme une fonctionnalit? ??souhaitable??. Par exemple, Google Map vous montre votre historique de position, tous les endroits o? vous avez ?t?. C'est une bonne impl?mentation du droit d'acc?s (bien que Google soit loin d'?tre parfait quand la vie priv?e est concern?e).

Ce n'est pas tout ? propos du droit d'acc?s. Vous devez laisser les utilisateurs non enregistr?s savoir si vous avez des donn?es les concernant, mais ce serait plus un processus manuel. Le minimum id?al serait d'avoir une fonctionnalit? ??v?rification par mail??, ou vous contr?leriez si vous avez des donn?es concernant une adresse mail particuli?re. Vous devez dire ? l'utilisateur de quelle fa?on vous traitez ses donn?es. Vous pouvez simplement imprimer tous les enregistrements dans votre registre de traitement des donn?es pour lequel l'utilisateur a consenti.

Article 15 de la RGPD.

3-9. Contr?le de l'?ge

Vous devrez demander l'?ge des utilisateurs, et si l'utilisateur est un enfant (moins de seize ans), vous devrez demander la permission des parents. Il n'y a pas de moyen clair ? ce sujet, ma suggestion est d'introduire un flux, o? l'enfant devra sp?cifier le mail d'un parent, qui pourra donc confirmer.

?videmment, les enfants pourront tricher sur leur date de naissance, ou fournir une fausse adresse mail parentale, mais vous aurez fait votre travail conform?ment ? la l?gislation (c'est un des v?ux pieux de la r?glementation).

Article 8 de la RGPD.

3-10. Ne pas garder les donn?es plus que n?cessaire

Si vous avez collect? les donn?es pour un usage sp?cifique (ex. livrer un produit), vous devez les supprimer/les anonymiser aussit?t que possible. Beaucoup de sites d'e-commerce offrent une option ??acheter sans inscription??, dans quel cas, le consentement n'est valable que pour la commande particuli?re. Vous devrez donc avoir une t?che programm?e pour anonymiser p?riodiquement les donn?es (supprimer les noms et adresses), mais seulement apr?s la r?union de certaines conditions, exemple?: confirmation de livraison du produit. Vous pouvez avoir un champ dans la base pour stocker la date limite ? partir de laquelle les donn?es devront ?tre supprim?es, et cette date limite peut ?tre ?tendue en cas de probl?me de livraison.

Article 5 de la DPDR.

3-11. Les cookies

Les cookies sont un sujet de r?glementation diff?rent (une directive qui deviendra bient?t une r?glementation). Cependant, la RGPD va encore changer les choses ?tant donn? que les cookies traceurs sont concern?s. J'ai d?crit mon opinion sur les cookies traceurs dans un post s?par?.

4. Les choses ? faire

Voici maintenant une liste de choses ? faire. La plupart concernent les mesures techniques n?cessaires pour prot?ger les donn?es personnelles (d?crites dans l'article 32). Il s'agit plus d'infrastructure que du d?veloppement, mais souvent l'application devra ?tre ?tendue pour les supporter. J'ai ?num?r? la plupart de ce que je pouvais penser dans un post pr?c?dent. Une note importante est que ce n'est pas exig? par la r?glementation, mais c'est en tout cas de bonnes pratiques et aide ? prot?ger les donn?es personnelles.

4-1. Chiffrage des donn?es en transit

Cela signifie que la communication entre votre couche applicative et votre base de donn?es (ou votre queue de message, ou tout composant que vous avez) devrait se faire ? travers TLS. Les certificats pourraient ?tre autosign?s (et ?ventuellement ?pingl?s), ou vous pourriez avoir une autorit? de certification interne.

Diff?rentes bases de donn?es ont des configurations diff?rentes. Certaines bases de donn?es ont besoin de dialoguer entre plusieurs n?uds, qui devraient aussi ?tre configur?s pour utiliser du chiffrement.

4-2. Chiffrer les donn?es au repos

Cela d?pend encore de la base de donn?es (certaines offrent un chiffrement au niveau des tables), mais peut aussi ?tre au niveau machine. Ex. en utilisant LUKS. La cl? priv?e peut ?tre stock?e dans votre infrastructure, ou dans un service cloud comme AWS KMS.

4-3. Chiffrer vos sauvegardes

Un peu ?vident.

4-4. Impl?mentation de la pseudomysation

Le cas d'utilisation le plus ?vident est quand vous voulez utiliser des donn?es en production pour des serveurs de tests/mises en sc?ne. Vous devrez changer les donn?es personnelles en ??pseudonymes??, de fa?on ? ce que les gens ne puissent pas ?tre identifi?s. Quand vous poussez des donn?es ? des fins d'apprentissage automatique (? des tiers ou non), vous pouvez aussi le faire.

Techniquement, cela pourrait signifier que votre objet utilisateur peut avoir une m?thode ??pseudonymise?? qui applique un hash+sel/bcrypt/PBKDF2 pour les donn?es pouvant ?tre utilis?es pour identifier une personne. La pseudonymisation peut ?tre r?versible ou non, d?pendant de l'usage (la d?finition dans la r?gulation implique la r?versibilit? bas?e sur une information secr?te, mais pas en cas de donn?es de test/mises en sc?ne). Certaines bases de donn?es ont de telles fonctionnalit?s int?gr?es, ex.?: Oracle.

4-5. Prot?ger l?int?grit? des donn?es

C'est une chose tr?s large, et peut simplement signifier ??avoir un syst?me d'authentification pour modifier les donn?es??. Mais vous pouvez faire plus, m?me aussi simple qu'un checksum, ou une solution plus compliqu?e (comme celle sur laquelle je travaille). Cela d?pend des enjeux, de la fa?on dont les donn?es sont acc?d?es, d'un syst?me particulier, etc. Le checksum peut ?tre de la forme d'un hash de toutes les donn?es d'un enregistrement de la base, qui devra ?tre mis ? jour ? chaque fois que l'enregistrement est modifi? via l'application. Ce n'est pas une garantie forte, mais c'est au moins quelque chose.

4-6. Avoir votre registre RGPD des activit?s de traitement dans autre chose qu'Excel

L'article 30 stipule que vous devriez garder un enregistrement de tous les types d'activit?s o? vous utilisez des donn?es personnelles. Cela sonne comme de la bureaucratie, mais peut ?tre utile. Vous serez capable de lier certains aspects de votre application avec ce registre (ex. les cases ? cocher de consentement, ou votre trace d'enregistrement d'audit).

Mettre en place un simple registre ne devrait pas prendre beaucoup de temps, mais les besoins de l'entreprise pour cela viennent de quiconque est responsable de la conformit? RGPD. Mais vous pouvez aussi les informer que l'avoir dans un fichier Excel ne le rendra pas facile pour vous en tant que d?veloppeur (imaginez avoir ? fouiller dans le fichier Excel, pour pouvoir le parser et impl?menter une fonctionnalit?). Un tel registre pourrait ?tre un microservice/une petite application d?ploy?e s?par?ment dans votre infrastructure.

4-7. Loguer les acc?s aux donn?es personnelles

Chaque op?ration de lecture d'un enregistrement de donn?es personnelles devrait ?tre logu?e, pour que vous sachiez qui y a acc?d? et pour quel usage. Cela ne d?coule pas directement de la r?glementation, mais c'est implicite concernant les responsabilit?s.

Qu'en est-il des r?sultats de recherche (ou listes) contenant des donn?es personnelles sur plusieurs sujets?? Mon pressentiment que simplement loguer ??utilisateur X a fait une recherche sur le crit?re Y?? devrait suffire. Mais n'affichez pas trop de donn?es personnelles dans les listes, par exemple voir comment Facebook vous fait passer par des cercles pour obtenir l'anniversaire d'une personne.

Certains ont trait? l'article 30 comme une exigence de garder un log d'audit. Je ne pense pas qu'il dit cela. Au lieu de ?a, les entreprises de plus de 250 personnes (ou les entreprises traitant r?guli?rement des donn?es) doivent garder un registre des types d'activit? de traitement (c?est-?-dire quel usage vous faites des donn?es).

Il y a d'autres articles sur le r?glement qui laissent entendre que garder un log d'audit est une meilleure pratique (pour prot?ger l'int?grit? des donn?es aussi bien que s'assurer qu'elles n'ont pas ?t? acc?d?es sans une raison valable).

4-8. R?pertorier toutes les API clients

Vous ne devriez pas autoriser les API anonymes ? acc?der aux donn?es personnelles. Je dirais que vous devez demander le nom de l'entreprise et le nom du contact pour chaque utilisateur de l'API lors de l'inscription, et les ajouter au registre de traitement des donn?es.

5. Les choses ? ne pas faire

5-1. N'utilisez pas les donn?es pour d'autres buts que ceux accept?s par l'utilisateur

Ceci est suppos? ?tre l'esprit de la r?glementation. Si vous voulez exposer une nouvelle API ? un nouveau type de clients, ou voulez utiliser les donn?es pour de l'apprentissage automatique, ou d?cidez d'ajouter des publicit?s ? votre site bas? sur le comportement des utilisateurs, ou encore vendre votre base de donn?es ? un tiers, r?fl?chissez ? deux fois. J'imaginerais un bouton pour envoyer des notifications par mails aux utilisateurs pour leur demander la permission (ou si vous utilisez un r?pertoire tiers, il vous fournira probablement une API). Donc, lors de l'ajout d'une nouvelle activit? de traitement (et l'ajout ? votre registre), envoi d'un mail en masse ? tous les utilisateurs desquels vous souhaiteriez le consentement. Notez ici que cette autorisation peut ?tre ajout?e dynamiquement.

Article 6 de la RGPD.

5-2. Ne pas loguer les donn?es personnelles

Se d?barrasser des donn?es personnelles depuis des fichiers de log (sp?cialement si elles sont fournies par un service tiers) peut ?tre fastidieux ou m?me impossible. Loguez donc juste les identifiants si n?cessaire, et assurez-vous que les anciens fichiers de log sont nettoy?s, juste au cas o?.

5-3. Ne mettez pas de champs sur l'enregistrement/le formulaire de profil dont vous n'avez pas besoin

Il est toujours tentant de placer autant de champs que le designer le souhaite, mais sauf si vous avez absolument besoin des donn?es pour fournir votre service, vous ne devriez pas les collecter. Vous devrez probablement toujours collecter les noms, mais ? moins de livrer quelque chose, une adresse personnelle ou un num?ro de t?l?phone est inutile.

5-4. Ne supposez pas que les tiers sont conformes

Vous ?tes responsable s'il y a une fuite de donn?es chez un tiers (c?est-?-dire le tiers effectuant le traitement) ? qui vous avez envoy? des donn?es personnelles. Donc avant d'envoyer des donn?es ? un autre service via une API, assurez-vous d'au moins un niveau de protection basique. Si ce n'est pas le cas, signalez-le ? la direction.

5-5. Ne supposez pas que d'avoir une norme ISO vous rend conforme

Les informations standards de s?curit? et m?me les standards de donn?es personnelles sont un bon point de d?part et repr?senteront probablement 70?% des ?l?ments requis par la r?glementation, mais ne sont pas suffisants. La plupart des choses list?es ci-dessus ne sont couvertes par aucun de ces standards.

6. Conclusion

Globalement, le but de la r?glementation est de vous faire prendre des d?cisions conscientes lors de traitements de donn?es personnelles. Elle impose les meilleures pratiques de mani?re l?gale. Si vous suivez les conseils pr?sent?s ci-dessus et concevez vos mod?les de donn?es, vos stockages, vos flux de donn?es, et vos appels d'API avec la protection des donn?es ? l'esprit, vous ne devriez alors pas vous inqui?ter des amendes ?normes pr?conis?es, elles sont pour les cas extr?mes, comme Equifax par exemple. Les r?gulateurs (les autorit?s de protection de donn?es, comme la CNIL en France) auront tr?s probablement des listes de contr?le auxquelles vous devrez d'une mani?re ou d'une autre r?pondre, mais si vous suivez les meilleures pratiques, cela ne devrait pas ?tre un probl?me.

Je pense que les fonctionnalit?s ci-dessus peuvent ?tre impl?ment?es en quelques semaines par une petite ?quipe. Soyez m?fiant quand un gros vendeur vous offre une solution g?n?rique et plug and play de ??conformit? RGPD??. RGPD ne concerne pas uniquement les aspects techniques ?voqu?s, il a des implications de traitements et d'organisation. Mais soyez aussi m?fiant si un consultant pr?tend que RGPD est compliqu?e. ?a ne l'est pas. ?a repose sur quelques principes de base qui sont en tout cas de bonnes pratiques.?Donc, ne les ignorez pas.

7. Notes de la r?daction

R?glement europ?en traduit en fran?ais.

La r?daction remercie Bozhidar Bozhanov pour son autorisation de traduction de son article GDPR ? A practical guide for developer.

La r?daction remercie ?galement Chrtophe pour sa traduction et Claude LELOUP pour sa relecture orthographique.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2017 Bohzo. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.