Aujourd'hui on va parler d'un sujet complexe et considéré comme "relou" par beaucoup de monde ... le R.G.P.D et la protection des données !
Je sais ... pas cool comme premier article mais pourtant essentiel quand il s'agit de notre cœur de métier : les données personnelles.
En Avril la CNIL a publié un rapport où elle fait état de 16433 plaintes (soit une augmentation de 35% par rapport à l'an dernier) et c'est sans compter les personnes qui subissent le préjudice sans rien dire.
Lors de mon premier contrat, on m'a demandé de faire une application pour une association. Cette asso devait administrer des données personnelles de membres (environ 200).
Sans trop savoir où je mettais les pieds, j'ai fais l'application comme une simple application de gestion de CRUD puis vient le moment de commencer le déploiement. Et là ... grosse crise de panique.
Mais comment je vais protéger les données ?!
C'était une question à laquelle je n'étais évidement pas préparé puisque je n'avais jamais géré des applications pour d'autres personnes.
Après quelques recherches je me suis rendu compte qu'il n'était pas forcément très difficile d'appréhender la question et c'est grâce aux précieuses données fournies par la CNIL qu'on peut y arriver.
Tout commence par ici : Les 6 grands principes du RGPD.
1er pilier : La finalité des données
Dèjà, première question : "Ai-je besoin de collecter toutes ces données ?".
Ici le but est de prendre du recul sur la finalité de l'utilisation.
Pour une application de gestion de livres, ai-je besoin de stocker le nom et prénom d'un utilisateur, son adresse postale, une date de naissance ? Je ne pense pas, un simple nickname suffirait.
Souvent quand on parle de code on dit "keep it simple", ça vaut aussi pour le RGPD. Plus vous restez simple, plus c'est simple à gérer.
2ème pilier : La base légale du traitement
Seconde question : "Comment avertir l'utilisateur pour les données récupérées ?"
Là c'est un peu plus délicat car déjà il faut se demander ce qu'on peut récupérer sans un consentement explicite en fonction de la base légale de traitement.
Il y a 6 bases légales de traitement :
- le consentement
- le contrat
- l’obligation légale
- la sauvegarde des intérêts vitaux
- l’intérêt public
- les intérêts légitimes
En fonction de la/les base(s) légale(s) choisie(s) (et cohérente(s) avec ton application), tu auras plus ou moins de latitude pour la récolte des données qui te seront utiles.
La plus simple ici, c'est la n°1 : le consentement. Tu dois demander à l'utilisateur de de te donner son consentement lors de la soumission d'un formulaire ou le dépôt d'un cookie sur son navigateur.
C'est simple, net et précis. On est en mode "opt-in" c'est à dire que l'utilisateur doit cocher une case volontairement (et pas que cette case soit pré-cochée) pour confirmer son choix de traitement des données personnelles et qu'il est éclairé de l'utilisation de ses données (un lien vers les mentions légales par exemple).
Pour la base légale d'un contrat, le traitement des données est plus implicite puisque c'est pour l'exécution d'un contrat entre l'utilisateur et le site qu'il est nécessaire d'obtenir les données, par conséquent, si contrat signé, alors la collecte est autorisée. (Exemple, inscription à une assurance, on a besoin pour le contrat d'obtenir des données personnelles.
Le fonctionnement du site web reposant sur les données de la personne, il est établit qu'elle autorise implicitement les données) cependant si d'autres données sont récoltés à d'autres fins (marketing par exemple) il sera nécessaire d'obtenir un consentement explicite (plusieurs cases à cocher par exemple et être sur plusieurs bases légales).
L'obligation légale quand à elle, c'est par exemple le site des impôts. Ils ont les données des utilisateurs sans avoir obtenu le consentement car régit par une réglementation ou une loi.
La sauvegarde des intérêt vitaux, ce serait les hôpitaux par exemple, pour des traitements vitaux de personnes inconscientes par exemple (Don d'organes etc ...).
L'intérêt public serait pour la gestion des registres électoraux ou lors de recensement par exemple.
Et enfin l'intérêt légitime serait sur des services où l'utilisateur a intérêt supérieur à donner ses données. Par exemple des sites de lutte contre la fraude.
Certaines notions peuvent être subtiles mais le site de la CNIL est très bien fait pour ne pas être perdu.
| Base Légale | Nécessite un consentement | Exemple |
|---|---|---|
| Le consentement | Doit demander le consentement explicite de l'utilisateur et fournir une explication du traitement des utilisateurs | Forum |
| Le contrat | Les données nécessaires à l'exécution (Et uniquement) sont récoltées sans consentement | Assurances, Achat en ligne |
| L'obligation légale | Régit par un texte de loi ou une réglementation stricte. Pas besoin de consentement | Impot.gouv, Police Nationale ... |
| La sauvegarde des intérêt vitaux | Absence de consentement à cause d'un contexte vital | Fonctionnalité d'un hôpital (transplantation vitale) |
| L'intérêt publique | Régit par un texte de loi ou une réglementation stricte. Pas besoin de consentement | Police Nationale, registre électoral ... |
| Les intérêts légitimes | Absence de consentement car l'intérêt de l'utilisateur prévaut sur l'autre partie. | Site luttant contre la fraude, amélioration de l'accessibilité etc ... |
Garde à l'esprit que plusieurs bases légales peuvent être utilisées sur la même appli en fonction de la finalité des données.
3ème pilier : Le droit des utilisateurs
Maintenant que nous avons ses données, l'utilisateur est en droit d'effectuer des actions sur ses données comme un droit de modification, de suppression, et il est de la responsabilité du site de les faire valoir.
Cependant en fonction de la base légale et de la finalité du traitement, il n'est parfois pas légitime pour l'utilisateur d'en faire la demande. Ici tu trouveras plein d'infos sur les différents droits qu'un utilisateur peut exercer.
4ème pilier : La durée de conservation
On ne peut pas garder pour une durée indéterminée les données des utilisateurs. En fonction du secteur d'activité, la durée peut varier.
Exemple : Un compte d'un utilisateur peut être désactivé ou anonymisé si la dernière connexion remonte à 2 ans ou une facture peut être gardée pendant 6 ans (délai légal de conservation en France pour les documents fiscaux).
5ème pilier : La sécurisation des données et l'identification des risques
C'est souvent ici que les fuites de données sont fatales.
"La pseudonymisation et l'anonymisation des données"
La pseudonymisation des données consiste à modifier les données personnelles lors du traitement afin de ne pas pouvoir relier au premier coup d'œil que telle donnée, appartient à telle personne.
Exemple : On change Paul en Bernard et Marie en Josette.
On a donc un tableau de correspondance mais les données visibles ne sont pas les vraies.
C'est pratique, mais dans l'utilisation ce n'est pas vraiment top pour de la production. Si on envoie un email à Marie en l'appelant Josette, ça fait tâche !
C'est pour cela que la pseudonymisation est réservée aux environnements de test afin que les développeurs n'aient pas accès aux données véritables mais puissent travailler avec des données "réelles".
En prod, on va plutôt anonymiser les données, c'est à dire qu'on aura recours au chiffrement des données (comme les mots de passe) lors du stockage afin de compliquer la tâches aux utilisateurs malveillants pour récupérer des données.
Si une fuite de données est recensée, alors ce sera moins grave d'avoir "$2a$12$9SY/K6yfO0TJBEeV6btGkOQbEiLaxqZlLwu90JN1U/DRdC6h7GjFe" plutôt que "marie@example.com".
Alors oui c'est plus compliqué (mais pas insurmontable) à mettre en place et ça te garantis un sommeil tranquille !
Principe de chiffrement / déchiffrement
| Type d'environnement | Type de données |
|---|---|
| Développement (ENV = DEV) | Fausse data, fixtures, API tierces => dummyjson |
| Test (ENV = TEST) | Fixtures, pseudonymisation des données<br /> |
| Production (ENV = PROD) | Anonymisation des données |
On peut même aller plus loin dans l'affichage des données.
Prenons pour exemple un dashboard de site de vente en ligne.
On pourrait ne pas afficher l'adresse postale d'un utilisateur afin que même l'utilisateur du back-office n'ait pas accès aux informations qui ne lui sont pas pertinentes, ou bien flouter les informations et lorsque la personne a besoin de l'information, elle devra cliquer sur un bouton pour déflouter et ainsi n'en avoir l'accès qu'au moment où elle en a vraiment besoin (action qui pourrait être enregistrée pour plus de sécurité).
6ème pilier : La mise en conformité continue
Et enfin dernier point, comme la veille techno est indispensable, il est aussi indispensable de se maintenir à jour sur les finalités des données personnelles pour mettre à jour la base de traitement de l'application.
En début d'article j'avais évoqué ma crainte sur la gestion des données personnelles des utilisateurs.
Pour me rassurer, j'ai demandé un rendez-vous avec la CNIL qui propose ce type de service (et gratuitement !) afin de pouvoir débloquer certaines situations dans l'intérêt des deux partis.
Pendant la visio j'ai présenté le site, comment je traitais les données, l'anonymisation etc ... ils ont apporté plusieurs axes d'amélioration et n'hésitent pas à complimenter certaines démarches ... Bref ils sont plutôt dans le conseil et la bienveillance que dans la répression (du moins quand on sollicite un rendez-vous spontanément 😜).
N'hésites pas si tu as des questions à leur demander un rendez-vous également. Ils ne sont pas forcément réactifs dû au nombre de demandes mais ils te répondront toujours.
Je ferai une suite à cet article pour montrer comment on anonymise une donnée avec Symfony afin d'avoir quelque chose de complet à propos du traitement des données personnelles pour un développeur.
