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 ? »

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.

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.

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.

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.

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

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.

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 :

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▲