La réglementation RGPD se durcit : tant mieux.

Ahh, la réglementation RGPD.

Voila un thème qui a alimenté les blogs, discussions, conseils et formation.

En bien c’est loin d’être terminé.

Le 4 Mai dernier, l'European Data Protection Board a édité un document “Guidelines 05/2020” qui précise les conditions nécessaires pour recueillir le consentement explicite des utilisateurs pour installer des cookies (ces “traceurs” qui s’installent sur l’ordinateur ou le smartphone d’un utilisateur).

Dans ce copieux document (de 31 pages!), on trouve plusieurs cas concrets de pratiques jugées non conforme à la réglementation RGPD. J’en ai sélectionné 3 que je constate régulièrement.

Cas #1 : une app mobile de retouche photo demande l'activation de la géolocalisation.

Elle indique que les données GPS collectées sont à des fins de publicité ciblée. Si l'utilisateur n'accepte pas, il ne peut pas utiliser le service. C’est non conforme, car :

• la géolocalisation n'est pas nécessaire pour l'utilisation des fonctions de l'app. On peut faire les retouches sans géolocalisation.
• le chantage "c'est à prendre ou à laisser" ne constitue pas un choix librement donné à l'utilisateur sur la collecte de ses données personnelles.

Cas #2 : Votre site Internet impose une pop-up bloquante pour accepter les cookies. Tant que l'utilisateur n'a pas cliqué, il n'a pas accès au contenu du site ("cookie wall").

→ non conforme, car l'acceptation des cookies marketing n'est pas techniquement nécessaire à la lecture de la suite et il n'y a pas de "libre choix" laissé à l'utilisateur.

Et si l'utilisateur défile la page, impossible de considérer cette action comme une acceptation implicite des cookies. Un consentement explicite et non ambigü doit être obtenu si l'on veut installer un cookie marketing tel qu'un pixel Facebook.

Cas #3 : Votre application possède un système de collecte des performances comportant des données personnelles. C'est activé par défaut, et l'utilisateur doit aller dans un menu de configuration pour le désactiver.

→ non conforme. On doit lui demander son consentement à l'installation, par une case à cocher explicite (et décochée par défaut!).

Pourquoi est-ce une évolution favorable ?

Dans beaucoup de projets, la prise en compte de la réglementation sur la gestion des données personnelles s’est simplement traduite par une sur-enchère de notifications, de pop-us agaçantes, de petites lignes et de mails qu’on ne lit pas.

Et ça libère un boulevard pour les alternatives qui ont pris le problème dans l’autre sens : comment prendre en compte le respect des données privées de façon à n’avoir jamais besoin de demander à l’utilisateur un consentement explicite ?

Les projets informatiques respectueux de la vie privée, c’est un peu comme les produits bio. Une partie des utilisateurs est d’accord pour payer plus cher un produit plus respectueux.

Pourquoi est-ce plus cher ?

Parce que certains service fondent leur modèle économique sur la publicité. L'accès au service est d’un coût très faible voire "gratuit" pour les utilisateurs, en échange de leurs données personnelles.

On parle plutôt de "pseudo gratuit", puisqu'on achète un service en données personnelles plutôt qu'en euros. Les données sont ensuite revendues sous forme de publicité ciblée pour nous inciter à acheter d’autres trucs.

Mais au delà du prix, j’ai constaté qu’un service respectueux de la vie privée va conduire à mieux sélectionner ses utilisateurs.

L’exemple d’un échec personnel.

Il y a quelques mois, j’ai codé un outil de mesure d’audience sans cookie pour éviter ces fenêtres pop-up demandant d’accepter les cookies à chaque visite d’un site.

Très fier de la conception technique (ElasticSearch, ReactJS, Lambda functions netlify), j’ai souhaité le faire connaître auprès de concepteurs de sites internet pour avoir leur avis. J’ai utilisé pour cela une technique un peu borderline pour les contacter, en codant un script Python qui chaque jour :

• va sur le site de l’AFNIC pour connaître les noms de domaines en “.fr” déposés la veille,
• comme la liste de l’AFNIC est publiée sous la forme d’une image, je la passe à un OCR Google Vision API qui la transforme en texte,
• pour chaque domaine j’interroge l’annuaire whois (avec un proxy car l’adresse IP est bannie au bout d’un moment) et tente de trouver un email de contact public du webmaster,
• j’envoie un email “Hey! Voulez-vous tester mon produit ?” à chaque email de contact. Soit en moyenne 150 mails par jour.

Ca a plutôt bien marché. J’ai récolté pas mal d’inscriptions. Et aussi quelques retours moins sympas me demandant d’expliquer comment j’ai obtenu leur adresse mail. J’ai toujours répondu, en indiquant la démarche à suivre pour que leur adresse ne soit plus publiée sur le whois. Mais je comprenais bien que le moyen était perçu comme intrusif, et non respectueux de la vie privée.

En dépit des bons chiffres obtenus, c’était un échec. Aucun des inscrits n’était réellement intéressé pour donner un avis sur le service.

Et même pire que cela : en discutant avec les mécontents, je comprenais que je faisais fuir les utilisateurs qui auraient été les plus intéressés ! J’ai rapidement mis fin à cette pratique de Growth Hacking inadaptée.

La protection des données personnelles est bon pour votre projet.

Au final, la façon dont on gère les données privées utilisateurs est une valeur qui structure un projet. C’est un cadre à poser en début de projet.

L’enjeu n’est pas seulement réglementaire. Il ne s’agit pas seulement d’ajouter la fenêtre d’avertissement, ou les petites lignes pour se conformer à un texte.

Il s’agit surtout d’instaurer un climat de confiance avec ses utilisateurs pour co-construire avec eux le logiciel.