5 questions des chefs de projet autour du RGPD (avec les réponses !)

« Est-ce que je peux conserver des données réelles en base de test ? »

Cette question revient très, très souvent de la part de développeurs ou chefs de projet. L’absence de lignes directrices spécifiques à ce sujet entraine une grande incertitude des professionnels du numérique. Pourtant, différents éléments nous permettent d’apporter une réponse claire à cette question.

Le principe, c’est que vous ne devriez utiliser que des données fictives ou anonymisées, dès que cela est possible, en dehors de l’environnement de prod (c’est-à-dire en bases de dev, de test, de préprod, etc.).

Dans certains cas, toutefois, l’utilisation de données réelles est nécessaire : par exemple pour reproduire une erreur, dans le cadre de la maintenance corrective. L’utilisation des données réelles en base de test ne contrevient pas au RGPD dans ce cas, la finalité étant considérée comme compatible avec la finalité initiale.

Attention : les données réelles doivent dans ce cas être supprimées dès que les tests sont effectués (ou la montée de version réalisée). Par exception, si les tests avec données réelles sont nécessaires de manière très fréquente, les données peuvent être conservées sur la base de test, mais doivent être renouvelées régulièrement.

Dans tous les cas, vous devez vous assurer que la sécurité des données en base de test est aussi forte que sur l’environnement de prod, et vous devez limitez les destinataires ayant accès à ces données (seule l’équipe qui travaille sur le projet doit y avoir accès !).

« On est en train de paramétrer le mécanisme de purge, et on doit choisir les données qu’on conserve pour des stats. Jusqu’où est-ce qu’on peut aller ? »

Déjà, on note le bon réflexe d’intégrer un mécanisme de purge des données obsolètes, en application du principe de limitation des durées de conservation.

Il est possible de ne pas supprimer l’ensemble des informations d’une base en fin de vie, par exemple pour produire des statistiques, à condition que les informations soient réellement anonymisées, c’est-à-dire qu’il ne soit pas possible de réidentifier les personnes concernées.

Dans un premier temps, commencez par supprimer les données directement identifiantes (nom, prénom, mail…) et autres informations uniques (numéro de contrat, adresse IP, téléphone, NIR…).

Dans un second temps, vérifiez si les personnes ne pourraient pas être réidentifiées par combinaison d’information. Par exemple, des personnes peuvent être réidentifiées à partir de données de géolocalisation, ou en combinant plusieurs informations telles que la civilité, la date de naissance et le code postal (données qui ne seraient pas identifiantes prises individuellement).

Une fois assurés que les personnes ne peuvent pas être réidentifiées, directement ou indirectement, y compris par combinaison d’information, vous pouvez considérer votre mécanisme d’anonymisation conforme. (Au fait : lorsqu’on parle de suppression ou anonymisation des données, on parle bien de hard delete avec suppression en base !)

« Je reçois des instructions contraires au RGPD : puis-je être pris en défaut ? »

Les sanctions se suivent et ne se ressemblent pas toujours, et il est parfois difficile d’imaginer qui, du client ou du prestataire, sera sanctionné si un site web ou un logiciel n’est pas conforme au RGPD.

Attention : si le client est généralement « responsable de traitement », au sens du RGPD, le prestataire peut voir sa responsabilité engagée dans certains cas.

• Exemple 1 : Une agence web implémente un système de tracking sur le site de son client, sans l’en informer, et sans ajouter de modale de consentement. L’agence web pourra être sanctionnée : elle doit informer le client des utilisations de données personnelles, surtout si le client n’est pas un spécialiste.
• Exemple 2 : Une ESN conserve des données réelles sur ses plateformes de test, pour une durée plus longue que ce qui est nécessaire. L’ESN elle-même pourra être sanctionnée.

Dans notre question, la situation est assez différente, puisque le client donnerait lui-même des instructions contraires au RGPD. En vertu de votre devoir de conseil, vous devez alerter le client si ses instructions contreviennent au RGPD (faites le par écrit pour en conserver une trace !). Si le client persiste, il sera bien responsable des éventuelles non-conformités.

« On me demande de retirer le gestionnaire de cookies, tout en conservant l’outil d’analyse d’audience… help ! »

En principe, l’utilisation de cookies d’analyse d’audience (tels Google Analytics) nécessite effectivement de recueillir le consentement des utilisateurs.

Pour cela, je recommande évidemment Orejime, notre gestionnaire de cookies open-source, accessible (RGAA), léger (moins de 15kB !), RGPD friendly et 100% paramétrable.

Toutefois, l’article 82 de la loi informatique et libertés prévoit des exemptions au recueil du consentement, en particulier pour les cookies nécessaires à la fourniture du service. Par exemple, on ne demande pas l’accord de l’utilisateur pour le cookie enregistrant son panier d’achat ou le choix de la langue, ou encore les cookies d’authentification.

La CNIL considère depuis 2021 que les cookies d’analyse d’audience peuvent être considérés comme nécessaires et donc être exemptés à certaines conditions. Concrètement, l’autorité met à disposition une liste des outils respectant ces conditions et que vous pouvez donc utiliser sans intégrer de gestionnaire de cookies.

Dans notre cas, la demande est donc tout à fait envisageable, dans le respect du RGPD ! Pour une solution fiable d’analyse d’audience, hébergée en France et bénéficiant de l’exemption de consentement, Boscop vous propose un hébergement de la solution Matomo.

« Minimisation des données OK, mais concrètement je peux demander la date de naissance, la civilité ou le numéro de téléphone dans un formulaire ? »

Le principe de minimisation impose de ne collecter que les données pertinentes et nécessaires au regard de l’objectif de la collecte.

Concrètement, il est possible de collecter des données qui ne seraient pas strictement nécessaires pour atteindre l’objectif, à condition qu’elles restent pertinentes et ne soient pas collectées de manière obligatoire.

Par exemple, pour un formulaire de création de compte, la civilité ne pourra généralement pas être considérée comme strictement nécessaire, mais reste pertinente (pour envoyer des mails personnalisés « Bonjour Madame ! »). Il est donc possible d’intégrer un champ « civilité », mais facultatif !

Le raisonnement sera identique pour le numéro de téléphone : souvent le numéro n’est pas nécessaire si l’utilisateur renseigne déjà un mail, mais reste pertinente s’il préfère ce mode de communication.

En ce qui concerne la date de naissance, pourquoi en avez-vous besoin ? Connaitre les tranches d’âge des utilisateurs ? L’année suffit… Envoyer un mail d’anniversaire ? A l’inverse, l’année n’est pas nécessaire !

La réflexion sera bien sûr à adapter à vos formulaires selon le contexte, et pour chacune des données collectées.

Vous voulez approfondir les questions abordées dans cet article ? Chez Boscop, nous formons les chefs de projet web (ou chef de produit – product owner) à la protection des données et au RGPD. Consultez le programme de la formation et contactez-nous pour connaitre les prochains créneaux de formation !