Privacy by design : quelles solutions pour protéger les données de ses utilisateurs ?

Le scandale qui a touché Facebook au mois de mars et l’arrivée du RGPD dans la législation européenne ont bien servi à une chose : sensibiliser davantage le grand public sur le besoin imminent de protéger ses données personnelles. Matthias Dugué, tech evangelist à Always Data, présente à l’occasion du BlendWebMix son guide pratique pour concevoir et développer son service en accord avec le respect des données personnelles des utilisateurs.

De la nécessité de responsabiliser ses utilisateurs

Parce que nous vivons dans un environnement où la technologie évolue à toute vitesse, l’adaptation à ces innovations n’est pas une mince affaire. Là où de plus en plus de personnes sont munies d’un smartphone, très peu savent ce qu’il se passe dans ce petit bloc de matériaux pas très recyclables. Il en va de même pour les données personnelles. Le problème, avant l’explosion du scandale Facebook et l’arrivée du RGPD, est que la sensibilisation et l’intérêt portés sur ces questions étaient quasi nuls pour les utilisateurs. La technologie utilisée sur ces produits n’est pas accessible et compréhensible par tous, son fonctionnement non plus, et les conséquences n’étaient pas concrètes.

Pour Matthias Dugué, la révélation de la manipulation des données par Cambridge Analytica a soulevé un effet pervers bien précis : malgré sa position de géant des internets, Facebook n’a pas su garantir la protection des données de ses utilisateurs. Pourquoi ? Parce que ces mêmes utilisateurs ont bel et bien autorisé l’application de Cambridge Analytica à accéder aux données de leur compte et ceux de leurs amis. Un réflexe largement adopté par tous sur Internet et notamment sur mobile : qui n’a jamais machinalement autorisé une application à accéder aux contacts, à sa localisation, à son appareil photo (comme Snapchat, Twitter, Instagram etc.) ou à d’autres paramètres plus étranges comme la connexion Wi-Fi ? « Les gens disent « oui » car on n’a pas éduqué nos utilisateurs à lire nos permissions. On leur a appris que c’était chiant, que c’était indigeste à lire, avec des conditions générales de dingue où il fallait signer simplement en bas de la page », argumente le développeur.

Pour Matthias Dugué, il faut donc rééduquer les utilisateurs à s’intéresser à ce que l’on fait de leur données. Mais la route qui mène à une totale conscience des enjeux sera longue. En attendant, il faut donc aussi « les protéger d’eux-mêmes ».

Les 7 commandements du Privacy by design

C’est là qu’intervient le concept de Privacy by design. L’idée est née en 1995, quand l’équivalent de la CNIL au Canada et aux Pays-Bas se sont rassemblés et ont publié un rapport expliquant pourquoi la liberté numérique est importante et pourquoi la protection de la vie privée est essentielle. À cette époque, tout cela reste encore très théorique et il n’existe aucune application concrète sur laquelle s’appuyer. Pendant plus de 20 ans, la mise en application du concept stagne, jusqu’au lancement du RGPD en 2018.

Le Privacy by design se définit par 7 lois appelées « lois de l’identité » :

1. Être proactif et non réactif, il ne faut pas attendre que votre donnée fuite, qu’il y ait un problème, il faut le prévoir en amont. Il faut prévoir d’où ça peut sortir, dans quel état, quels sont les mesures à prendre quand ça arrive (car le tout n’est pas de savoir si ça va fuiter, mais quand et comment).
2. La protection des données personnelles doit être un réglage par défaut. Toute donnée doit être protégée, quelle qu’elle soit.
3. Cette protection doit être incluse dans le design, ce n’est pas juste un plug-in en plus dans le système qui rajoute de la privacy.
4. Ce doit être « full-fonctionnality », c’est-à-dire que ce n’est pas parce qu’un utilisateur désactive certains services qu’il doit perdre certains éléments du produit. En désactivant des permissions, l’utilisateur ne doit pas être pénalisé.
5. Il faut que ce soit de la sécurité end-to-end, que ce soit donc chiffré de bout en bout et que les utilisateurs sachent ce qu’ils se passent.
6. Il faut qu’ils puissent accéder à cette information et que ce soit ouvert, documenté, disponible, avec des points de contact.
7. Garder l’utilisateur au centre de ses initiatives, l’utilisateur est notre client et non notre régie pub.

Le Privacy by design dans la conception, l’implémentation et l’exécution

Comment cela se traduit dans la pratique ? Dès la conception, il faut commencer à intégrer la privacy dans le service et lister des points à contrôler. À chaque intégration d’une nouvelle feature, il convient de s’assurer que cette feature et les éléments remplissent les conditions de la checklist. Des frameworks existent pour assurer la compliance RGPD et assurer le privacy by design, Matthias Dugué recommande de s’appuyer sur ces documentations afin d’obtenir une première base de travail, à adapter ensuite pour garantir une protection optimale.

Concrètement, le réflexe est de ne jamais demander plus de permission que nécessaire dans son appli, et la tester afin que tous les pré-requis soient vérifiés. « Dans l’implémentation, vous oubliez tout ce qui est frameworks de permission déjà prêts, qui ont la fâcheuse tendance à demander par défaut tous les accès« , préconise Matthias Dugué. Il convient également de faire des tests fonctionnels sur les environnements d’outils et d’automatiser au maximum.

Le développeur démontre dans sa conférence l’exemple du site Femmes Numériques, qui dispose du bandeau cookie mais ne les pose pas tant que l’internaute ne l’a pas accepté, et propose d’accepter ou de personnaliser la pose de ces cookies. En cliquant sur personnaliser, le menu affiche une pop-up avec les services susceptibles de poser les cookies : il n’y en a que 4.

Dans l’exécution, il faut bien veiller à ne récolter uniquement les données dont on a besoin. On doit également veiller à :

• Minimiser les données échangées avec les services tiers
• Pseudonymiser la donnée
• Vérifier les formulaires. À chaque saisie d’information, de la donnée est créée. Si vous rajoutez un nouveau champ, repassez par l’étape de la checklist et demandez le consentement à votre utilisateur
• Supprimer régulièrement la donnée collectée. La donnée a une durée de vie, une fois qu’elle ne sert plus, elle devient obsolète et meurt.

Cela se traduit également dans l’expérience utilisateur. Ces derniers ont besoin d’être également sensibilisés en leur proposant diverses possibilités :

• Fournissez des réglages simples, et des notices claires à valider
• N’exigez pas de passer par des services externes
• Pas de partages sur les réseaux sociaux par défaut
• Séparer les consentements (shared data vs analytics), un consentement ne vaut pas l’autre

Matthias Dugué préconise également de faire appel à des frameworks de notification pour informer l’utilisateur de nouvelles fonctionnalités et des nouvelles autorisations que cela implique, et d’éviter au possible l’identification par les réseaux sociaux, qui sont de véritables passoires à données.

Enfin, pour tester votre service, vous pouvez faire appel au dispositif OWASP (The Open Web Application Security Project) et son top 10 des risques de la vie privée. « Si vous êtes capables de contrevenir à ces risques, c’est une bonne base de début. Vous devez garder à l’esprit que vous cherchez à tracer les données et non pas les utilisateurs et les utilisatrices. Il faut concevoir que la donnée nait, vit, meurt et a donc une durée de vie ». Tout comme cette donnée, votre service sera également amené à mourir un jour. En fin de vie de votre service, n’oubliez pas de :

• Rappeler aux utilisateurs leur droit d’accès aux données
• Faciliter l’export
• Supprimer les données des comptes supprimés
• Supprimer les données à la fermeture du service