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 GPDR.

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 GPDR.

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 GPDR.

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 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 GPDR.

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 GPDR.

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 GPDR.

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 GPDR.

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 GDPR 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. Chiffrement 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 pseudomisation

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é, 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 dirai 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 GPDR.

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 traitement 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é GPDR ». GPDR 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 GPDR 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.