Le RGPD expliqué par un développeur

Bonjour à tous. Merci d'être là.

On va commencer par un petit sondage puisque j'aime bien savoir à qui je parle. Qui est ingénieur, ergonome ou ingénieur UX ici ? personne c'est bien dommage. Qui administrateur système ? On va presque pouvoir se faire un poker. Qui est développeur? ça c'était facile. Qui est free lance? Ok c'est pas beaucoup. Je suis surpris. Qui travaille chez un éditeur ? Qui travaille en société de services SS2i ou boîtes à viande ? non mais je travaille dans une, donc je me permets...

Je vais me prendre un SCUD de mon employeur mais c'est pas grave.

Ça tombe bien que vous soyez là parce que... Alors qui est un peu tout ça aussi ? Parce qu'il y a aussi ces profils un peu mouton à cinq pattes qui font un peu tout genre : j'en suis un aussi. Donc ça tombe bien vous soyez là parce que vous êtes concerné par ce truc pour votre malheur votre bonheur ça dépend.

Moi quand je l'ai découvert ce truc, je l'ai lu à plusieurs reprises.

En soit c'est pas très long : ça fait 99 articles. 99 articles de textes de lois.

Pour l'exemple un texte de loi ça ressemble à ça.

J'ai forcé un peu le trait ! C'est presque le pire que j'ai pu trouver mais globalement c'est assez représentatif.

Du coup on comprend rien surtout quand on est développeur, qu'on n'a pas l'habitude du tech juridiques.

Du coup moi j'ai cherché à simplifier.

Et du coup le titre officiel de cette conférence est le RGPD expliqué par un développeur mais le vrai titre ça devrait être un truc dans ce genre là.

C'est tout de suite plus clair.

On va continuer dans cette voie en fait. J'ai essayé de simplifier tout ça pour que vous compreniez d'un point de vue technique.

Ce que le RGPD va impliquer dans vos pratiques quotidiennes et au niveau des votre outillage.

On va placer un peu le contexte quand même.

Avec un petit rappel, le RGPD c'est un règlement européen ce qui veut dire que il prend le pas sur toutes les législations locales de tous les pays européens ces derniers ont une légère marge de manœuvre pour l'adapter à leurs besoins spécifiques, mais il faut que ça respecte l'esprit du texte.

Vous attendez pas à ce que ce qui se passe au sénat en ce moment ou ailleurs dans d'autres pays, vienne assouplir le règlement : ça ne se fera pas.

L'Europe a mis 4 ans pour en accoucher, ils ne vont pas remettre le truc sur la table avant bon moment. Ça a coûté du temps, de l'argent.

Petite précision qui a son importance : il va rentrer en application dans dix-sept ou dix-huit jours, le 25 mai c'est dans pas très longtemps.

Une question que j'ai pas posée au départ : qui est prêt pour le RGPD? okay...

Bon, le RGPD est basé sur une définition, qui est celle de la donnée personnelle.

Qu'est ce que c'est une donnée personnelle au sens RGPD? C'est tout ce qui vous permet de vous identifier directement ou indirectement.

Le indirectement voulant dire que ça inclut tout ce qui est profilage.

Donc ça peut être votre nom, votre prénom, votre date de naissance, vos empreintes digitales, votre ADN, votre appartenance ethnique, etc etc. Et votre comportement sur internet aussi.

À partir de là, le RGPD défini des obligations et des responsabilités pour ceux qui collectent et utilisent les données d'un point de vue légal et technique. Donc moi je vais me concentrer sur l'aspect technique, mais il y a aussi des obligations légales.

Chose importante à comprendre : peu importe que vous travaillez pour un employeur étranger en dehors de l'Europe, ou que vos données soient stockées à Tombouctou en Russie whatever, ça rien à carrer ! le RGPD dit qu'à partir du moment où les données appartiennent à un citoyen de l'union européenne le RGPD s'applique. Et comme vous pouvez pas savoir à l'avance qui va s'inscrire sur votre service ou utiliser votre application, en fait le RGPD concerne virtuellement tout le monde.

Donc ne croyez pas que parce que vous travaillez par amour pour Amazon, Google ou etc, etc que vous n'avez pas d'obligation : c'est faux.

À partir de tout ça, le RGPD définit des règles de bonne conduite qui vont nous obliger à modifier notre comportement, parce que jusqu'à maintenant quand on nous demande de collecter une donnée , qu'est ce qu'on fait nous développeurs d'habitude, On prends notre clavier, on arrête de jouer aux échecs et de regarder les dents de la mer, et on commence à faire ce qu'il faut pour mettre les données dans un endroit à peu près sécurisé.

Enfin en tout cas on le pense au départ...

Et on est bien content ! Et une fois qu'on a fait le taf, ben on passe à autre chose...

Sauf que tout ça, c'est juste un gros tas de merde et on le sait ! Tous au fond de nous mêmes, on le sait, qu'on fait de la merde, quand on fait ça.

Qui n'a jamais fait ça dans sa vie ? Menteur ! Obligé. Et surtout toi en plus ! Ça balance un peu... Il faut réveiller les gens : il est 9 heures.

Alors pourquoi c'est un gros tas de merde ? Parce que les données personnelles, ça vaut de l'argent, et pas qu'un peu.

Il y en a qui disent que c'est le pétrole du 21e siècle, et c'est pas pour rien.

Et du coup des grandes entreprises comme des PME, comme plein de gens, collectent de la data et font n'importe quoi avec en termes de stockage, de sécurisation, de monétisation etc etc. Et du coup qu'est ce qui se passe ? Il se passe ça : régulièrement il y a des failles de sécurité qui sont exploitées pour sortir des centaines de millions de données de bases de données et puis qui sont mis sur ce qu'on appelle le darknet.

Attention ça fait peur.

Reste qu'il y a des données qui partent dans la nature et on parle de données bancaires, des données lamda, des données gamers, des données d'orientation sexuelle etc etc Ça touche des domaines hyper variés.

Le but du RGPD, en gros, c'est de dire : "il y en a marre il faut arrêter ça".

En tant que développeur; on est responsables de ça. Le code qu'on produit manipule ces données. Il y a quelqu'un qui a dit un jour Pas la peine que je le répète, je pense que tout le monde a compris.

Donc du coup qu'est ce que fait le RGPD ? Il responsabilise beaucoup plus fortement tout le monde.

Et la première chose qui fait pour responsabiliser les gens, c'est dire : "attention si tu fais pas ce qu'il faut; tu vas t'en prendre plein la gueule" De manière graduée, mais tu vas t'en prendre plein la gueule et ça peut faire très très très très mal.

Je vais pas revenir sur les chiffres 2% du CA mondial etc etc. C'est des données qui courent sur le net depuis longtemps.

C'est un bel épouvantail : est ce que ce sera appliqué ? J'en sais rien, je l'espère à titre perso.

Alors du coup, qu'est ce qu'on va devoir faire un nous en tant que développeur maintenant qu'on a posé le contexte ? Vous allez devoir avoir un rôle de conseil par rapport à votre client.

Et ça on ne l'a jamais fait jusqu'à maintenant à ce niveau là. C'est à dire que, le jour où votre client va venir vous dire : "je veux que tu stockes en plus dans ta base de données, une date de naissance" Pourquoi ? C'est la première chose qu'il faudra que vous lui demandiez. Et pourquoi vous allez devoir lui demander pourquoi ? Parce que vous allez devoir définir si c'est légal ou pas. Et vous allez devoir l'avertir si ça ne l'est pas.

Et on n'est pas dans la technique là, on est bien d'accord. Mais n'empêche que ça maintenant c'est votre responsabilité.

Alors il y a six contextes légaux pour collecter de la donnée.

La première : vous avez obtenu le consentement de l'utilisateur. À chaque fois que je vois Rample, j'ai l'impression de voir Mark Zuckerberg, c'est bizarre.

La deuxième raison valable pour collecter de la data, c'est l'obligation légale. Je voulais mettre un panneau 80 pour troller encore plus le truc, mais j'ai pas trouvé.

La troisième possibilité pour collecter de la data, c'est l'exécution des missions d'intérêt public ou relevant de l'exercice de l'autorité publique. Voilà quand on s'appelle Walker on a le droit tout faire, pas de problème.

Attention un peu de gore...

Le quatrième contexte légal, c'est l'intérêt vital. C'est à dire que la personne qui collecte la donné, elle en a besoin dans l'intérêt de votre vie.

Typiquement les médecins.

Le cinquième c'est l'intérêt légitime, alors ça va être un beau sujet de contentieux ça, parce que définir l'intérêt légitime, ça va être compliqué, mais on voit là : collecter de la donnée pour faire du vin pourquoi pas ? Mais est ce que c'est vraiment légitime ? J'ai pas trouvé mieux comme silde et c'est pour ça je suis tombé là dessus.

et le dernier, c'est l'exécution d'un contrat.

Ça calme un peu le Terminator, je sais.

Donc voilà il ya six contextes leggaux que vous allez devoir identifier dans votre métier, par rapport aux demandes de votre client, ou de vous même si vous êtes votre propre éditeur.

En outre, le RGPD impose le concept de privé par défaut.

Ça veut dire que, quand vous allez collecter des données, vous n'allez plus pouvoir collecter la totalité des données que vous pouvez collecter. Il va falloir collecter le strict minimum indispensable au traitement que vous voulez effectuer.

Ça tombe bien on va gagner de l'espace de stockage sur les clouds divers et variés, ça coûtera moins cher.

C'est le principe de minimisation.

Si vous n'avez pas besoin de la donnée, vous ne la collectez pas.

Vous n'avez pas besoin de la date d'anniversaire parce que jamais vous souhaiterez bon anniversaire à vos utilisateurs, vous collectez pas la donnée. Et même souhaiter bon anniversaire par e-mail à un utilisateur, est ce que c'est vraiment pertinent ? À vous de voir.

De toute façon, vous allez devoir apporter la preuve que vous avez besoin de faire cette collecte de données.

ça veut dire quoi ? Ça va vouloir dire rédiger de la doc qui quand l'autorité de contrôle viendra chez vous pour vous demander des comptes, servira de justificatif.

Ce sera pas à l'autorité de contrôle de prouver que vous avez bien fait les choses, c'est à vous de prouver que vous avez bien fait les choses. Et la doc, il faut pas rêver, c'est pas votre client qui va l'écrire. Ça va être vous développeurs.

Qui écrit la doc ici ? De la doc technique ? Je compte un tiers de menteurs.

Pas grand monde...

Alors moi j'ai une suggestion, c'est une suggestion.

Si vous connaissez pas, je vous le dis je suis très intéressé par la QA et les tests. Moi je vous propose d'intégrer votre documentation à ce niveau là dans les fixtures gherkin.

Normalement si vous travaillez correctement vous écrivez les tests fonctionnels, ça change pas énormément votre workflow et votre doc se rédige d'elle même.

C'est une suggestion.

Pourquoi va falloir connaître aussi la raison de la collecte ? Parce que il y a aussi le concept de ce qu'on appelle le privacy by design.

C'est à dire que vous allez devoir concevoir vos applications ou les mettre à jour, si elles existent déjà. Pour garantir l'intégrité, la confidentialité et la sécurité des données.

Et c'est pas anodin.

Parce que, en plus ça va dépendre de la sensibilité des données. Vous n'allez pas gérer un nom, un prénom, une date de naissance comme vous allez gérer une orientation sexuelle une donnée ADN ou des données bancaires.

Là, il y a un gradient à trouver et à ajuster en fonction des besoins.

Alors qu'est ce qu'on a dans notre besace pour faire ça Le premier évidemment c'est le chiffrement.

C'est une machine Enigma. Pour ceux qui savent pas, ce que c'est : c'est une vieille machine de chiffrement qui date des années 40, qui a donné un avantage décisif aux allemands pendant la dernière guerre.

Et qu'est ce que ça veut dire chiffrement ? Ça veut dire qu'il va falloir tout passer en HTTPS, ça tombe bien, c'est dans l'air du temps. Et va encore falloir le faire correctement.

C'est à dire que ça va être du TLS 1.2 minimum et il n'y a aucune raison de descendre en dessous de ça. Ça veut dire aussi abandonner définitivement FTP pour passer sur du SFTP, du SSH du VPN pour tout ce qui est transmission de données entre serveurs pour faire des sauvegardes, etc, etc.

C'est pareil, des fois on n'est pas à jour là dessus.

Autre chose, outre le chiffrement au niveau réseau, on va être obligé aussi de chiffrer tout ce qui est bases de données ou partition qui héberge les données, à vous de voir comment vous voulez faire en fonction de votre contexte. Il y a des avantages et des inconvénients dans les deux solutions, mais ça va devenir un incontournable.

Un principe aussi dont vous avez peut-être entendu parler si vous vous intéressez un peu aux RGPD, c'est ce qu'on appelle la pseudonymisation. Alors la pseudonymmsation, c'est très exactement ça : la personne là, vous ne pouvez absolument pas l'identifier si vous n'avez pas son visage, qui est stocké ailleurs, à part. La pseudonimisation c'est ça.

C'est à dire que vous allez manipuler vos données pour que vous ne puissiez plus identifier d'une manière certaine les personnes sans utiliser une information tierce qui est stockée ailleurs ! Sur un autre serveur, dans une autre base de données, qui est sécurisé à part entière.

Or, y a plein de façons de le faire. Ça peux passer par du chiffrement partiel, du salt etc.

En PHP, j'ai pas trouvé des outils qui permettent de le faire facilement. Si vous en avez, je suis preneur.

Alors, c'est pas une garantie suffisante la pseudonimisation, attention ! Même la CNIL, enfin, l'Union Européenne le reconnaît dans le RGPD pas la CNIL.

Le RGPD dit bien que la pseudonimisation, c'est un moyen mais ce n'est pas une fin.

C'est pas parce que vous faites de la pseudonimisation que vous êtes ceinture et bretelles. La pseudonimisation, même quand elle est bien faite, elle peut permettre de remonter à la donnée d'origine.

Donc, il faut faire attention avec ça.

Il ne faut pas uniquement faire ça.

Alors, une autre bonne pratique consistera à limiter les accès aux données. C'est-à-dire vous assurer que quand quelqu'un viendra modifier ou supprimer des données, c'est bien la personne qui en est le propriétaire. Ça veut dire quoi ? Ça veut dire potentiellement généralisation d'authentification à deux facteurs.

C'est pas anodin dans les sites de e-commerce etc. où on parle de taux de conversion etc. C'est un peu comme le 3d secure : c'est plus compliqué, ça va déranger l'utilisateur.

Voilà ! Et en plus, il va falloir développer les interfaces etc pour faire tout ça.

Il va falloir en tenir compte pendant les avant-ventes, etc etc.

Alors pour la même raison, une pratique assez courante, c'est des personnes qui se partagent le même compte utilisateur.

Que ce soit les utilisateurs finaux ou les devs, où les adminsys etc. Tout le monde a le même compte. Ça, il faut arrêter parce que vous allez devoir tracer tous les accès aux données. Et si tout le monde se partage le même compte ça va être difficile.

Et ça ,c'est une obligation légale.

Vous allez être obligé de tracer tous les accès aux données. Vous ne pouvez plus partager un même compte avec quelqu'un.

Ça veut dire aussi en terme de base de données, une bonne pratique consistera à utiliser un utilisateur qui a des accès en lecture seule sur la base de données pour tout ce qui est lecture et un utilisateur spécifique pour tout ce qui est modifications. Et cet utilisateur spécifique en modification, il pourrait avoir des droits suivant ce qui permet de faire sur des tables ou des colonnes spécifiques de la base de données.

On est loin d'une granularité où on met un utilisateur qui grosso modo à les droits root sur la base de données et peut tout faire.

Ça veut dire gérer plusieurs utilisateurs gérer plusieurs clients etc etc Alors, il va aussi falloir qu'on s'arme un peu plus. Aujourd'hui qu'est ce qu'on a, qu'est-ce qu'on utilise dans notre quotidien pour un évaluer la sécurité de nos applications ? Il y a des outils qui existent mais qui les utilise vraiment ? Qui fait des audits de sécurité sur ses développements ? Une, deux, trois, quatre et demi.

On est à peu près 70.

Va falloir se renforcer là dessus parce que comme la charge de la preuve elle devient notre responsabilité, va falloir montrer qu'on a fait des audits en interne ou en externe, et qu'on est arrivé à quelque chose de satisfaisant. On est bien d'accord, le RGPD le reconnaît aussi que le risque zéro n'existe pas mais il va falloir montrer que vous avez fait tout ce que vous pouviez pour sécuriser vos devs.

Alors, un petit truc sympa aussi : quelque chose qu'on oublie souvent : les logs. On loggue tout en théorie, quand on fait notre boulot correctement.

Et ben dans les logs on envoie souvent sans le savoir des informations intéressantes, dont des données personnelles.

Et dites pas que ça n'arrive jamais, c'est arrivé pas plus tard, que je crois, la semaine dernière.

Voilà. Donc va falloir penser aux log aussi.

À les désactiver en prod, et à faire attention à ce qu'on y envoie parce que vous pourriez avoir des problèmes.

Ça veut dire aussi, que par sécurité, il va falloir mettre en place des crons, ou quelque chose qui va faire le ménage régulièrement dans vos journaux, pour éviter que les données soient stockées advitam eternam.

On va y revenir un peu sur cette histoire de suppressions.

Alors, je reviens sur cette histoire de gradation.

Le RGPD dit bien que l'effort de sécurisation doit être proportionnée la sensibilité de données. Ça veut dire que, si vous avez des données sensibles et que vous faites de la sécurité insuffisante c'est pas bien. Et a l'inverse si vous mettez les moyens complètement disproportionnés pour protéger des données qui n'en valent pas la peine c'est pas bien non plus. Alors le problème tout ça c'est que c'est un peu flou, où est le seuil ? Ce qui est raisonnable pour moi ne sera pas forcément pour vous ou pour la personne qui va venir contrôler.

Donc il y a un équilibre à trouver et il n'y a pas de recette magique non plus la dedans.

Autre problème, purement technique pour nous. On utilise tous des services tiers : du Google Analytics, des services dans le cloud.

Plein de choses.

il va falloir s'assurer que tout ça c'est RGPD compliant.

Et c'est pas anodin parce que c'est pas simple.

AWS clament qu'il est RGPD compliant, c'est écrit partout.

Sauf que, quand vous suivez l'actualité américaine, il y a un truc qui s'appelle le "cloud act" qui dit que les autorités américaines ont toute latitude pour aller piocher les données qu'ils veulent chez les hébergeurs US.

Du coup, lui le RGPD, il dit oui mais vous devez garantir la confidentialité des données.

Qui a tort ? Qui a raison ? Concernant Google Analytics, personnellement j'ai reçu une flopée d'e-mails de Google censée m'expliquer ce que ça allait changer le RGPD par rapport au tracking.

Je les ai lu en diagonale parce que j'avais pas beaucoup de temps a y consacrer et en plus c'est pas mon coeur de métier, mais j'avoue que j'ai rien capté. Donc le mieux que je vous recommande c'est d'utiliser Matomo.

Ça fait le même boulot que Google Analytics, c'est du self hosted et ça marche très bien.

Après, à vous de voir.

Une bonne pratique aussi, qu'il va falloir intégrer, c'est la veille juridique.

Enfin dans la veille juridique... Je vais trop vite pardon, c'est la veille de sécurité.

Qui va consulter les CVE de PHP, nginx, etc régulièrement ? C'est pareil, bon allez, on va dire 6 personnes dans la salle.

Ça, va falloir que ça devient de votre quotidien aussi. Parce que vous allez devoir être responsable de la sécurité des données.

Il va falloir maintenir tout ça.

Et c'est pas anodin non plus, parce que comme c'est une veille technologique à part entière quasiment à faire du faire de la sécu c'est vraiment pas simple.

faut savoir faire le tri entre le bon grain et l'ivraie on l'a vu avec la faille PGP là où tout le monde a crié "c'est la fin du monde", mais au final, on s'en fout. Donc falloir faire attention à tout ça.

Qu'est-ce que ça va changer aussi ? Ca va changer des choses en terme d'ergonomie.

Parce que, au moment où vous allez demander à votre utilisateur de vous donner ses données, il va falloir l'informer de tout un tas de choses.

De la raison de la collecte, de qui va les manipuler, qui va manipuler ces données, à qui elles vont être transférées.

il va falloir aussi l'informer de ses droits : qu'il a des droits de modification de rectification, d'opposition, de suppression. Et s'il a donné son consentement, il va falloir lui expliquer aussi qu'il pourra le retirer son consentement.

Ça veut dire qu'il faudra développer aussi l'interface qui vient derrière ça.

S'il y a des nouvelles données qui sont collectés pour une raison X ou Y, faudra enrichir tout ça.

Il y a aussi truc qui s'appelle le droit de limitation : le droit de limitation c'est un truc un peu bâtard.

Vous avez le droit de conserver les données, mais vous n'avez absolument plus le droit de les utiliser.

Ça veut dire quoi ? De ce que j'en ai compris, ça veut dire qu'il faut sortir de votre base de données de prod classique entre guillemets ces données là, et les stocker ailleurs.

Pour être certain qu'elles ne sont jamais accédées.

Et pendant une durée que l'utilisateur vous indiquera, en plus.

Cerise sur le gâteau, Ça s'applique aussi aux cookies.

Tous les cookies qui permettent de traquer les utilisateurs, tout ce qui n'est pas cookies technique dit cookies de session, tout ce qui est posé par Google Analytics et consorts, vous allez devoir justifier l'utilisation de ces cookies et l'utilisateur pourra ou non, vous dire je suis d'accord je ne suis pas d'accord, et si jamais ils refusent vous ne pourrez pas lui interdire l'accès aux services.

Et ça, vous devrez aussi le dire à votre client.

Non tu ne peux pas subordonner l'accès à ton service à l'acceptation des conditions d'utilisation, c'est illégal.

Petite subtilité, les consentements doivent être éclairés et actifs.

Ce qui veut dire que, c'est comme le sexe : quand votre partenaire vous dit rien, ça veut pas dire qu'il est d'accord.

Ça veut dire qu'il va falloir ajouter une case à cocher, et un bouton sur lequel il devra cliquer, pour que vous puissiez avoir la preuve de son consentement.Parce que c'est sera aussi à vous de prouver que vous avez obtenu son consentement. Si vous pouvez pas le faire vous n'êtes pas bien.

Alors concrètement, qu'est ce que ça veut dire ? En termes d'ergonomie il va y avoir des nouvelles interfaces à inventer tout simplement. Il va falloir travailler avec les ergonomies UX, pour pouvoir le faire. V'est pour ça que je posais la question sur les ergonomes au départ.

Il y a clairement des nouvelles interfaces à inventer ici.

Il y a des travaux qui sont en cours là dessus.

Ça pose plein de problèmes : il y a des tests qui ont été faits et on a globalement 70 % des gens qui, quand on leur présente un formulaire RGPD compliant, ils donnent pas leur données.

Je vous laisse imaginer ce que ça implique pour un site de e-commerce ou quelque chose de ce genre.

C'est pas tout, il y a beaucoup de choses ! Une fois que vous aurez collecté les données, la communication avec le propriétaire des données ne va pas s'arrêter du jour au lendemain.

Parce que vous allez devoir l'informer. Et l'informé de quoi ? L'informer du fait que vous vous êtes fait hacké.

Et que ses données elles sont peut-être partie dans la nature.

Impossible de planquer le truc sous le tapis. Si jamais vous le faites et que ça vient à être découvert, là franchement vous serez vraiment très très très mal. Et je pense que la sanction sera terrible.

Alors ça veut dire quoi ? C'est bien beau de dire qu' il faut avertir les utilisateurs que leurs données ont été hackées par quelqu'un. Il faut être en mesure de le détecter.

C'est pas simple de détecter qu'on a été hacké et puis en plus, détecter qu'on a été hacké c'est une chose, mais il faut aussi détecter quelles données ont été subtilisés pour pouvoir prévenir les personnes concernées.

Ça veut dire qu'il va falloir renforcer beaucoup la supervision de notre applicatif et du serveur qui l'héberge pour pouvoir détecter des comportements anormaux.

Reste à définir ce que c'est un comportement anormal. Des choses évidentes : si vous savez que votre base de données fait 94 GO et qu'un jour vous détectez un pic de 94 GO sur votre bande passante et sur vos graph de supervision vous pouvez vous dire qu'il y a eu un problème quelque part.

Mais en dehors de ça c'est pas simple.

Donc voilà ! Il y a une vraie problématique, j'ai pas la prétention d'avoir les réponses.

Mais dans tous les cas ça veut dire quoi ? Ça veut dire qu'il va falloir discuter avec les adminsys.

C'est toujours un plaisir de discuter avec les adminsys. Je me permets de les bâcher, j'en suis un aussi.

En général ils veulent pas parler donc c'est compliqué. Mais on est en plein dans la continuité du mouvement devops en fait.

On va pas vraiment avoir le choix là dessus.

Encore une cerise sur le gâteau, les données vont avoir une date d'expiration.

Aujourd'hui, vous récupérez une donnée, vous la mettez dans votre base de données, et elle y reste. Et vous faites tout pour qu'elle y reste, parce que vous la backupez 14 fois, etc, etc Vous faites de la réplication, vous les revendez à des tiers, parce que voilà, c'est votre business.

Pourquoi pas ? Ça se respecte après tout.

Mais ça c'est fini ! Aujourd'hui au moment où vous allez collecter la donnée, vous allez devoir dire en plus de tout le reste, à votre utilisateur : "ta donnée je vais la garder pendant x jours/mois/années pour telle raison".

Une fois ce délai expiré on efface. On déplace pas : on efface.

Donc si vous réfléchissiez à des problématiques type CQRS, etc, Il y a quelques petits challenges techniques intéressants.

Ça veut dire quoi concrètement ? Techniquement, chaque fois que vous allez collecter de la donnée vous allez devoir ajouter un champ pour savoir quand est-ce que vous allez devoir la supprimer.

C'est pas anodin non plus.

Toujours un plaisir de manipuler le temps en informatique.

Ça veut dire aussi qu'il va falloir développer le code nécessaire à l'effacement des données.

Ça veut dire du boulot en plus.

il faudra être certain que c'est bien fait et en plus si vous avez cédé les donnés à des tiers, chose que vous pouvez faire si vous avez avertit l'utilisateur, que vous alliez céder ses données, pour une raison X ou Y à des tiers. Vous avez droit de le faire.

Sauf qu'il faudra avertir ces tiers que les données sont expirées et qu'ils doivent aussi les supprimer.

Il faudra pouvoir prouver que vous l'avez fait.

Toujours cette charge de la preuve.

On continue toujours dans les petites nouveautés : l'utilisateur va pouvoir récupérer ses données personnelles.

Et pas n'importe comment, vous n'allez pas lui fournir un truc infâme encoder, whatever... Non il faut dans un format lisible par une machine, et qui sera exploitable facilement pour être transféré ailleurs.

bonjour JSON, bonjour XML, bonjour archive ZIP etc. Il y a plein de façons de le faire (tarball) mais dans tous les cas c'est aussi du boulot en plus.

Et c'est une obligation.

Impossible de faire l'impasse là dessus.

Ça veut dire que si on vous demande d'ajouter de nouvelles données dans la base de données, va falloir aussi modifier les scripts correspondants en termes de maintenance etc, va y avoir du taf supplémentaire aussi.

Il y a une autre problématique posée par le RGPD, c'est que, au moment où vous collectez les données, vous allez devoir dire à la personne : "tes données vont être manipulés par telle personne ou telle catégorie de destinataires" Si les développeurs sont pas cités, de mon point de vue dans l'absolu, pas touche.

Et de toute façon, c'est une mauvaise pratique de manipuler les données de prod en dev.

Donc du coup, qu'est ce que ça veut dire ?ça veut dire que vous allez devoir faker la plupart des données que vous allez utiliser en prod. Enfin pardon pas en prod justement, en test ou en recettes.

avec des outils comme Faker par exemple. Et si par hasard vous avez la bénédiction du responsable du traitement des données, donc la personne qui a ordonnée la collecte ou que l'utilisateur a donné son autorisation de toute façon, vous devrez sur votre poste de travail garantir l'intégrité et la sécurité et la confidentialité des données.

Ça veut dire en gros appliquer les mêmes recettes que celles que vous aurez appliquées en prod pour les sécuriser et les garantir.

Du coup moi j'ai envie de dire que c'est presque plus simple de pas du tout y toucher et d'utiliser de la donnée générée.

Au moins, il y aura pas de problème.

Et si, par hasard parce que ça nous est tous arrivé de recevoir un dump de 500 GO de données dans notre boîte e-mail qu'on n'avait pas demandé. Si jamais vous avez accès à des données pour une raison X ou Y, il va falloir le signaler à ce qu'on appelle le DPO ou le Data Protection Officer le slide est un peu biaisé. Le rôle du DPO, ce n'est pas de sanctionner, le rôle du DPO est d'assurer la traçabilité, et garantir que tout ce qui est fait en ce qui concerne les données personnelles est fait dans le respect du RGPD.

Donc ça se passera pas comme ça, mais je trouvais le slide marrant.

Autre obligation, vous devez garantir que les interfaces qui permettent à l'utilisateur de modifier, supprimer, retirer son consentement etc, sont accessibles.

Je vais pas dire H24 mais la plupart du temps.

Donc ben, Bonjour les SaaS genre Clever Cloud etc et, il va falloir faire les choses sérieusement et arrêter d'utiliser OVH en offre de base quoi.

Pardon pour le troll.

Et si ça suffisait pas tout ça, vous allez aussi avoir des obligations vis-à-vis de ces autorités de contrôle. Alors quand on dit autorités de contrôle en France, on pense automatiquement à la CNIL. Il y a aussi des CNIL Européennes.

La CNIL Française a dit qu'au 25 mai...

Elle a tenu un discours un peu particulier : il y a un an elle disait au 25 mai, ça vache shlagué. Bon maintenant elle c'est rendue compte que même elle n'était pas prête.

Donc du coup elle commence à dire on va juger sur l'effort qui a été fait pour se rendre compatible avec le RGPD.

Ça c'est le discours de la CNIL Française.

Il y a plein d'autres CNIL en Europe. On sait pas comment vont gérer les autres.

Petit warning.

Bon, qu'est ce que ça veut dire avoir des obligations vis-à-vis de la CNIL? ça va être notamment une obligation de documentation.

Une obligation de documentation pour justifier la justesse - ça fait un peu bizarre de dire comme ça - la justesse des technologies utilisées pour sécuriser les données.

Encore une fois, la charge de la preuve, c'est à vous de la porter et que vous avez fait les bons choix techniques qui permettent de garantir que, par rapport à leur sensibilité, les données sont correctement protégées dès le départ.

Évidemment, il va falloir maintenir la doc. J'en vois un qui baille, et merde tu t'ennuies tant que ça ? Donc voilà, va falloir apporter la charge de la preuve, et ça va pas être simple parce que on prend des décisions à un instant T, en fonction de ce qu'on sait faire, en fonction des risques qu'on a identifiés, et on n'est pas infaillibles.Et peut-être une personne extérieure, elle aura une autre vision. Et là il va falloir discuter.

Donc si en plus vous n'avez pas de documentation; quand la personne se pointe vous n'êtes pas bien.

Et enfin dernier point, l'autorité de contrôle devrait être notifiée dans les 72 heures, d'une faille de sécurité concernant les données dites sensibles : tout ce qui a trait à l'origine ethnique, la sexualité, la santé etc etc ça veut dire déjà qu'il faut être capable de détecter la faille. Et après il faut être capable de fournir les informations nécessaires à la CNIL parce qu'il va falloir lui donner entre autres la nature de la violation, le nombre approximatif de personnes concernées, les types de données susceptibles d'avoir été corrompus, il va falloir pouvoir identifier tout ça.

Et encore une fois il va falloir documenter les attaques, leurs effets et les mesures qui ont été prises pour plus qu'elle se reproduise. On va avoir les bouts des doigts carrés les mecs.

Alors qu'est ce qu'on peut dire de tout ça? Ben moi mon point de vue, le RGPD, il va avoir un impact qui est vraiment loin d'être négligeable dans nos pratiques quotidiennes.

A tout point de vue, que ce soit méthodologiques ou technique, on va être obligés d'utiliser des nouveaux outils, on va être obligé de réfléchir différemment.

On va être obligé de faire du Légal Driven Development. Et en plus de faire du TDD. Qui fait du TDD ici ? Ouais le légal c'est mort.

Ça veux dire aussi que, quand on va estimer notre charge de travail, il va falloir comme augmenter un peu les curseurs parce que tout ça, ça implique du boulot.

Va falloir fournir des données, des formulaires adaptés. Va falloir modifier des structures de bases de données. Va falloir maintenir des choses qu'on a et qu'on ne faisait pas jusqu'à maintenant.

On va être obligé d'avoir des interactions supplémentaires avec les adminsys. Avec le DPO, qui va devenir un incontournable.

Donc voilà. Ça va être du boulot, faut pas se mentir. Et pourtant c'est pas nouveau.

Tout le monde dit : "le rgpd gna gna" Non c'est pas vrai ! Dans la loi informatique et libertés de 1978, il y a déjà la minimisation, il y a déjà les droits de modifications, rectification etc, Juste nous les développeurs, et je pense qu'on est tous pareil, moi quand je suis devant mon écran et que je dois donner mes informations perso pour m'inscrire à un service etc, ça me fait chier, je suis premier à râler et pourtant quand moi, dans mon boulot on dit faut que tu demandes à l'utilisateur ces données-là, ces données-là...

Ça m'en touche une sans faire bouger l'autre. Et ça, c'est pas normal.

On n'est pas censé ignorer la loi. Et on devrait avoir un minimum d'éthique.

Et traiter les données des autres comme on traite les nôtres.

Et ça on le fait pas, le RGPD il est là pour ça.

Et, (je vais le laisser finir) Voilà.

Ça va être comme ça.

Pour finir, une petite règle d'hygiène.

Si vous savez pas quoi faire vis-à-vis du RGPD, je vous propose de traiter les données persos comme de la matière radioactive.

Si vous savez pas la ramasser, vous ne l'a ramassez pas. Si vous savez pas la stocker, vous ne la stockez pas.

Si vous savez pas vous en débarrasser, vous ne la ramassez pas.

C'est aussi simple que ça.

Et là au moins vous ne serrez pas emmerdé.

Alors, viens le petit moment des remerciements.

Le RGPD c'est un texte législatif, juridique. Je suis pas juriste, je suis un pur techos, comme vous.

J'ai demandé de l'aide, donc je voudrais remercier Rayna Stamboliyska (j'espère que j'ai pas écorché son nom de famille), Xavier Mouton-Dubosc, Benjamin Benifei et Marc Rees de NextImpact qui a écrit un excellent article, qui m'a beaucoup aidé pour préparer cette conférence.

Ben voilà, j'ai fini.

C'est le petit mignon de la fin.

Et maintenant j'attends vos questions.

- On a 6/7 minutes pour les questions, donc n'hésitez pas. - J'avais même pas répété.

- Salut - Salut - J'ai une question sur imaginons, que je suis organisateur du PHPTour et, je dois donner les données de toutes les personnes qui sont ici à un tiers qui gère le contrôle d'accès aux conférences.

Et tu disais qu'on n'a pas le droit d'interdire l'accès aux services, mais du coup si j'accepte pas de filer les datas à ce tiers est-ce que j'ai quand même le droit de participer ? - En théorie l'AFUP n'a pas le droit de te refuser l'accès au PHP Tour C'est la loi.

Le traitement des données ne doit pas être subordonnée à l'accès aux service. C'est marqué.

Donc en théorie je te réponds oui. Après comment ça va être vraiment transcris ? Ce qu'il faut bien comprendre c'est que même la CNIL, elle n'a pas une vision très claire de comment tout ça, a va fonctionner. Le RGPD n'aborde absolument pas l'aspect technique au delà de la pseudonimisation, c'est limite le seul terme technique qu'on trouve dedans. Il y a le principe de minimisation, pas très technique, mais il n'y a aucune solution clé en main.

Moi j'ai posé plusieurs questions à la CNIL quand j'ai préparé la conf. J'attends toujours les réponses donc après c'est la CNIL, française, ils paraît que la CNIL anglaise est beaucoup plus réactive.

J'ai malheureusement pas eu le temps de la contacter, mais tout ça, c'est sujets à interprétation : il va falloir surveiller la jurisprudence.

Donc on va vraiment avoir besoin de faire une veille juridique, aussi pour savoir comment le RGPD est transposé et est appliquée dans la vraie vie.

je vais être honnête, il y a une notion de fantasme là dedans, maintenant moi je trouve ça super à titre perso, c'est génial. Maintenant c'est techniquement et commercialement qu'Il va falloir trouver un terrain d'entente.

Est ce que j'ai répondu à ta question ? ok, question suivante.

- Merci pour la conf c'était super intéressant tu parlais de surveiller ses infrastructures, appli, ect. Est ce que du coup dans le RGPD, il y a l'obligation de monitorer son système ? - Il n'y a rien de technique dans le RGPD.

Le RGPD te dit que tu dois pouvoir notifier en cas de faille de sécurité. La façon dont tu t'y prends, c'est pas son problème.

- ok, merci - Voilà Une autre ? Il y en a deux en bas, au deuxième rang - Salut, merci, c'était vraiment super intéressant.

Moi, je me pose une question au vu de, bon tu nous as bien briefé pour un début de journée, maintenant je pense que tout le monde a le moral dans les chaussettes.

- Désolé - Non mais tu fais ça à chaque fois donc on prend l'habitude.

Du point de vue des petites structures, qu'on soit du côté du développement ou des clients, quel est ton point de vue sur l'impact que va créer le RGPD ? Moi mon sentiment c'est que ça met la barrière très très haut et que du coup ça va être compliqué pour un entrepreneur de se doter d'outils qu'il peut faire développer aujourd'hui et qui demain vont peut-être le coûter deux fois plus cher est-ce que c'est pas un moyen de rendre toujours plus complexe l'application et au final de dire ben elle n'est plus accessible à tout le monde.

- Nul n'est censé ignorer la loi, et oui aujourd'hui, maintenant le RGPD, je pense que c'est une épine dans la savate de plein de gens.

Maintenant c'est une période de transition, on va apprendre.

Les outils vont se développer s'il n'existent pas. Les interfaces sont aujourd'hui en cours, on a bootstrap typiquement tu vois qui résout plein de problèmes d'interface d'UX, quasiment naturellement je pense qu'on va avoir l'équivalent d'un bootstrap pour le RGPD qui va arriver, il ya un truc qui s'appelle tarteaucitron.js qui a l'air bien foutu pour gérer justement les droits les cookies etc Aujourd'hui oui, ça va être compliqué, mais on va être obligé de s'y faire.

Et ça va rentrer dans le flot de production je pense. Ça va demander du temps, effectivement, ça va coûter plus cher, ça va coûter de l'argent pendant un certain temps, mais quand on saura faire, ce sera comme faire un formulaire d'authentification, ça ne reste que de la collecte de données il n'y a rien d'insurmontable techniquement.

On a juste des petites choses, plein de petites choses à faire. Un peu plus de la paperasse.

Moi, à titre perso, je suis prêt à le faire, si je peux avoir la garantie que les données vont pas partir dans la nature et vont servir à gagner de l'argent à quelqu'un sans que j'en vois la couleur.

Donc le fond de ta question, si je la résume jusqu'au bout, c'est dans quel monde vous voulez vous vivre ? Voulez-vous être un produit ou pas ? Moi j'ai décidé, que moi pourquoi pas, mais mes enfants c'était juste hors de question.

Je pousse le truc un peu loin mais, on en est à ce niveau là en fait c'est tout ça, ça se résume à ça. Dans quel monde vous voulez vous vivre ? Et c'est votre responsabilité en tant que développeur. Le code il est partout partout, même dans la table de mixage là bas, je suis sûr qu'il y a un bout de code.

Donc voilà : dans quel monde voulez vous vire ? Est-ce que ça va empêcher les petits entrepreneurs ? les PME ? Je pense que toutes les lois qui sortent, je sais qu'il y a un personnes dans la salle qui va parler du contrat de travail le contrat de travail à des obligations légales et je suis sûr que ça fait chier les entrepreneurs.

Sinon il y aurait pas de RH de toute façon. Tu vois ? On est dans un monde où les lois sont obligatoires sinon ça deviens le far-west.

J'y peux rien il va falloir vivre avec, deal with it.