GDPR - interview

Échange impromptu et sans langue de bois avec Ludovic Nachury (Linkedin) de Phocea Tech, qui a posé à Thomas des questions dans le cadre d'un article sur le RGPD pour Gomet'. Nous retranscrivons ici les questions et réponses de façon très brute, sans (quasi) aucune édition.

Pour bien commencer, voici le texte:

Disclaimer de Thomas : je ne suis une personne très versée dans le droit et ce genre de problématiques, mon point de vue sur le GDPR est donc une lecture personnelle d'ingénieur en data science.

En premier lieu, on parle de privacy by design et de privacy by default. Quel impact cela a t-il sur la façon dont on collecte les données ? Que faut-il changer pour obtenir des données qui soient conformes ?

On parle de l'article 25, qui est très explicite.
Je t'y renvoie pour la base.

La pseudonymisation, c'est un peu la nouveauté.

C'est, en gros, faire en sorte de ne pas stocker les informations personnelles en clair et avec des liens faciles à établir en cas de fuite. Au lieu de stocker les informations sur Thomas Gerbaud sous la forme d'une grande table avec mon nom en deuxième colonne (la premiere est l'index) et accessible à plein de gens, on pourra stocker mon nom dans une table séparée, secrète, et lui faire correspondre une clé totalement illisible, puis relier les autres tables à cette clé illisible : on ne saura pas directement qu'il s'agit de moi, mais plutôt de mSsXeRgtQheCT6dMHn2oHh5bgISyPG8P.

Les informaticiens aiment bien jouer avec des commandes du genre :
cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1

Une autre possiblité est d'utiliser des fonctions de hachage pour obtenir des correspondances (presque) parfaites entre un nom en clair et son écriture dans la base.

Bref, ça va ajouter une couche de traitement sur le stockage. Les autres points sont plutôt des déclarations d'intention: on stocke souvent tout ce qu'on peut, en se disant qu'on s'en servira sûrement plus tard. GDPR nous dit que non, il ne faut stocker que ce qui est nécessaire. Pourquoi pas, oui, dans un monde parfait où on sait très clairement où on va. Dans les faits, j'attends de voir - hors cas pathologiques, évidemment.

Ex personnel: sur mon site oceandata.io, ce qui m’intéresse c'est le trafic général et les pages visitées : pour être dans l'esprit de l'article 25, je ne vais stocker que l'heure de la visite, la provenance de la personne et les pages visitées. Pas la version de son navigateur ni la résolution de l'écran, encore moins l'IP. Par contre, le pays pourra me servir plus tard : dois-je le stocker ?

Bon, dans les faits, c'est mon hebergeur et Google Analytics qui le font :-)

Concernant la sécurité par design/défaut, le législateur impose une gestion fine des droits d'accès à ces données. Ex: si tu cherches les produits achetés par tes clients, tu n'es pas intéressé a priori par leurs noms/prénoms/adresses. Donc GDPR engage à séparer ces informations - et c'est une bonne choses. Dans les faits, je doute qu'on aille réellement repenser tous les schémas des bases de données et tout remettre à plat pour être GDPR-compliant. Ça impliquerait de revoir toute la tuyauterie des accès machines aux données - un coup à mettre les logiciels par terre ! Ou ajouter une couche d'abstraction entre le programme/utilisateur et la base proprement dite, via une API. Pourquoi pas. Sur de nouvelles bases, oui, c'est faisable. Ça complexifie, par contre, et ça peut avoir un impact sur les perfs.

Encore faut-il pouvoir contrôler réellement les acces aux différentes tables ... Ca dépend des modèles de bases. Pas sur que ca amuse beaucoup les DBA.

Au final, ce sont pour moi de belles déclarations d'intention, qui nécessitent de revoir tout les schémas internes des bases et la tuyauterie. Je doute que ce soit réellement suivi : les boites sont frileuses quand il s'agit de toucher à leurs bases de données, et les dettes techniques sont, et je m'avance peut-être, plutôt affolantes.

Sur la pseudonymisation, si je comprends ce que tu m'expliques, c'est globalement maîtrisé côté IT mais ça aura un coût. Au-delà de la partie audit, est-ce qu'on peut considérer que la RGPD aura un coût en matière de hardware / hébergement ? C'est aussi ce que je comprends de ce que tu écris sur la gestion des droits d'accès.

Oui. Jouer avec des accès plus précis demandera forcément du temps humain. Sur l'infra physique, non, pas trop normalement. On peut imaginer de la (dé-)pseudonymisation à la volée, évidemment, ce qui pourrait avoir un impact sur les perfs. Mais est-ce un cas réaliste ?

Quant à la dette technique, il me semble que les entreprises n'ont pas le choix. Le règlement entre en vigueur fin mai, les entreprises ne seront pas sanctionnées si elles ne sont pas à jour mais si elles sont contrôlées elles devront montrer qu'elles vont corriger ce qui doit l'être, "on a une dette technique" ne suffira pas comme réponse :)

Tout à fait.

Mais je parle plutôt de dette technique envers les DBA et autres salariés qui maîtrisent seuls l'infra et les bases. Le guru, quoi ! Cf Brent du Phoenix Project (lisez-le !).

Au-delà de la conformité, il me semble que le RGPD pose un problème de qualité des données, pour des sociétés pas forcément mal intentionnées mais pas toujours bien organisées. Est-ce qu'à ton avis c'est souvent le cas ? Et comment faire dans ce cas pour expurger de jeux de données ce qui ne devrait pas s'y trouver ?

Qualité ? Ce point m'a échappé. Quantité, oui, clairement.
En gros, GDPR implique :

  1. Un audit data : "que stocke-t-on, comment, sur qui, pourquoi faire ?  S'est-on assuré que ces informations dont on dispose sur ce Jean Dupont  de Grigny ont bien été recueillie avec son consentement éclairé - car on  lui aura expliqué pourquoi il nous faut les stocker". Clairement, ce  point va piquer.
     
  2. Un audit technique, cf art 18 et 22 sur la limitation du traitement  et le profilage (vaste terme qui englobe beaucoup de choses, cf les def  de l'art 4), point à mon humble avis totalement ignoré par les  entreprises ... et pourtant, au coeur du projet !
     
  3. une refonte totale de l'acquisition des données à des sources  tierces. Peut-on encore acheter des données à des tiers ?

Ce que je me dis souvent, pour être un peu provoc (pas du tout le genre de la maison), c'est qu'au vu du travail requis pour être en conformité stricte, il vaudrait mieux jeter tout ce qui n'est pas réellement indispensable et repartir de zéro. Et débrancher les recueils d'informations issus des sites webs.

Du coté du e-marketing, ca va vraiment leur faire bizarre. Criteo toussa...

A quel point est-ce automatisable? Existe t-il aujourd'hui des outils permettant de réaliser "simplement" des opérations de ce type ? J'ai vu que la CNIL propose le sien, PIA, depuis peu.

On rentre tout à fait dans mon domaine !

Ces étapes se rapprochent des étapes d'ETL (extract/transform/load) et elles sont fondamentalement manuelles.

Le process complet n'est donc pas automatisable, mais pour qui sait s'y rendre et maîtrise les outils, ça peut tout de même aller vite, si on a la bonne approche. Je n'ai rien vu de concret en terme d'offres réelles, cela dit ...

Au final, il faut (forcément) analyser toute l'IT et les process incluant un traitement de donnée. Toute la chaîne, donc. Vaste programme.

Je m'explique sur la qualité: dans de très nombreuses boîtes avec qui j'ai pu discuter, dès qu'elles ont voulu exploiter leurs données, elles se sont rendues compte qu'elles étaient de mauvaise qualité, avec des informations mal rédigées, avec des informations n'apparaissant pas dans les bons champs ... Or, puisqu'avec RGPD l'utilisateur peut demander ses données, les entreprises vont devoir fournir des données "propres". Est-ce que ce nettoyage est automatisable ?

Ah ok, dans ce cas, oui, pourquoi pas.

Une sorte de nettoyage par le vide, et en profiter pour remettre les choses au propre, respecter les formats etc. Ce serait une bonne idée. Pas sur que ce soit très populaire, ahah !

Le point sur les données tierces est très intéressant. Si je comprends bien, un éventuel outil d'audit RGPD doit vérifier non seulement la  compliance des bases internes mais aussi celle des bases externes  utilisées. Si je reprends l'exemple Criteo, il faudrait que Criteo s'engage sur sa compliance.

Oui, de ce que je comprends. Ca ne peut que fortement impacter ce genre de boites : il faudrait demander aux gens s'ils sont ok pour du reciblage etc.

En tant que spécialiste de la data science, as-tu été régulièrement sollicité sur le sujet ? Et (sans citer de noms) pour quels type de mission ?

Pas directement. Les gens me demandent souvent des informations sur le sujet, mais pas plus. Je ne les sens pas vraiment terrorisés. D'ailleurs, je co-construis un projet sur le sujet, avec deux autres entrepreneurs. Nous allons proposer un outil adaptable, sur-mesure et efficace pour répondre aux demandes des utilisateurs. Je m'occupe bien entendu de la partie traitement et matching, coté back-office, avec certains outils de machine learning. Le projet est phase de lancement commercial et nous n'avons pas encore fait de communication. Il s'appelle Dataminit, et vise les ETI et grands comptes. Je te ferai passer de la com' quand nous l'aurons faite ... ça se passera sur dataminit.com.

En résumé, nous prenons en charge tout le recueil des demandes utilisateurs, la vérification (+KYC), l'interrogation des bases internes, la mise à disposition des données le cas échant et le suivi de la demande. Le tout le plus pragmatiquement possible, puisque c'est notre ADN et notre façon de travailler. Les retours que nous avons sont déjà très intéressants !

En particulier, as-tu été sollicité pour des missions de formation de salariés, et plus particulièrement de DPO ?

Pas encore.

Au-delà de  mes questions, c'est ton vécu par rapport à ce sujet qui m'intéresse.

En fait, le vrai sujet immédiat du GDPR, que peu ont compris, est le suivant :

  • comment permettre aux citoyens de faire leurs demandes aux entreprises ?
  • Comment s'assurer de la légitimité de leur demande, de leur réelle identité derrière le formulaire qu'ils ont rempli ?
  • Comment recouper cette identité partielle (des Jean Dupont habitant dans le 91 il y en sûrement des dizaines) avec les données présentes et fragmentées dans les bases de l'entreprise cible ?
  • Quelles données lui fournir ?
  • Car c'est une obligation légale de faciliter et recueillir ces demandes, puis de répondre _ans un délai d'un mois. Ce travail est complexe et les erreurs ne sont pas vraiment autorisées ...

Au final, au risque de me répéter, GDPR est complexe, peu compris et attaque les entreprises sur un de leur point faible : la gestion des données internes. La réponse est en partie technique, et implique un travail sur-mesure et spécifique, que les grosses ESN auront du mal à réaliser - ou alors, à des prix idiots.

Voilà.
C'est trop long.
J’espère avoir été au moins un peu clair.

Thomas Gerbaud