Comment appliquer les principes de Privacy by Design à un projet ?

Comme de nombreux principes présents dans le Règlement relatif à la protection des données personnelles (RGPD), le principe de Privacy by Design n’est pas nouveau. Certains éléments étaient déjà présents au sein de la Directive de 1995 qui précisait que les mesures de protection des données doivent s’appliquer tant au moment de la conception qu’à celui de la mise en œuvre du traitement.

Afin de mettre en œuvre pleinement ce principe et déterminer les mesures techniques et organisationnelles à appliquer au traitement, le règlement vise plusieurs facteurs que doit prendre en compte le responsable du traitement. Il s’agit d’une part de l’état des connaissances et des coûts de mise en œuvre et, d’autre part du traitement en lui-même et des risques qu’il présente pour les droits et libertés des personnes physiques. Toutefois, il ne s’agit pas des seuls éléments à prendre en compte. En effet, n’oublions pas que la priorité pour un responsable de traitement est de mettre en œuvre un traitement qui lui permette d’atteindre ses objectifs business. Typiquement, dans le cadre d’un logiciel, il est important de tenir compte de facteurs tels que l’expérience utilisateur ou l’optimisation des fonctionnalités du produit ou service créé. C’est au moment de la conception que tout se joue. Le challenge : appliquer les principes de protection des données tout en préservant les enjeux business. Alors comment fait-on concrètement lorsque l’on construit un nouveau projet ? Quels sont les enjeux métiers à concilier avec la protection des données personnelles ?

Quelles sont les différentes phases d’un projet ?

Afin d’illustrer nos propos, nous avons décidé de retenir le projet fictif suivant : la création d’un module de satisfaction client qui sera intégré au sein d’un outil de CRM (Customer Relationship Management/Gestion de la relation clients) déjà existant. Il existe évidemment différentes manières de construire un projet. Pour notre exemple, nous séquencerons notre projet de la façon suivante :

Phase 1 : Cadrage projet

Cette phase va couvrir les tâches suivantes :

o Identification du besoin
o Définition d’une solution fonctionnelle pour adresser le besoin
o Définition d’une solution technique permettant la mise en place de la solution fonctionnelle

Phase 2 : le Proof Of Concept (POC)

Cette phase consiste à réaliser un petit démonstrateur du produit ciblé avec l’objectif de valider le concept produit et de récolter des retours d’expérience. Cette phase inclut particulièrement les tâches suivantes :

o Conception : Spécification détaillée de la solution. Mise en place de l’ergonomie globale de la solution, des briques techniques à mettre en œuvre ou encore du type de déploiement qui est envisagé (logiciel à installer sur l’ordinateur des utilisateurs, solution proposée en SaaS, …)
o Développement : Développement logiciel de la solution, mise en place de l’infrastructure (si besoin) de la solution et tests internes
o Déploiement test : envoi de la solution à quelques utilisateurs cibles afin d’évaluer la solution
o Collecte du retour d’expérience : récupération et synthèse des retours utilisateurs afin de préparer la future première version de la solution

Phase 3 : Développement de la première version de la solution

o Re-travail de la conception : changement des spécifications de la solution afin d’adhérer aux remarques faites par les utilisateurs en phase de PoC
o Développement complet de la solution
o Déploiement de la première version

Phase 4 : Run

o Utilisation nominale de la solution par les utilisateurs
o Maintenance applicative de la solution
o Recueil des retours utilisateurs en préparation des futures versions
À noter qu’à l’état de l’art actuel, les phases 3 et 4 sont répétées régulièrement afin de produire de nouvelles versions et de s’aligner au mieux sur les besoins utilisateurs.

Dans quelles phases doit-on prendre en compte la protection des données ?

La réponse est presque toutes !

La phase de cadrage projet

Dans cette première phase, il convient de déterminer si un accompagnement en matière de protection des données sera nécessaire ou pas. Cela implique que le chef de projet soit en capacité de déterminer si son projet aura des impacts sur la protection des données.

La phase de conception du PoC

Dès la phase de conception, il est primordial d’associer des référents en matière de protection des données. Ces référents doivent être en mesure de réaliser l’analyse juridique du projet et de la traduire techniquement au niveau du système d’information. Il s’agira donc la plupart du temps de deux personnes distinctes. Cette association ne doit pas non plus intervenir trop tôt. C’est aux équipes métiers qu’il incombe de prendre le temps de définir dans un premier temps :

– Les finalités du/des traitement(s), c’est-à-dire ce pourquoi le traitement est réalisé. Il peut bien sûr avoir plusieurs sous-finalités. Le tout est d’arriver, le plus en amont possible, à définir les différentes utilisations des données. Ce travail permettra au référent d’identifier s’il existe un ou plusieurs traitements et d’analyser si le principe de finalité est bien respecté. Dans notre exemple, il s’agit de créer un nouveau module qui permettra à ses utilisateurs de mesurer la satisfaction client.

– Les données qui seront utilisées pour chacune des finalités. Il est important d’identifier par finalité quelles sont les données qui pourront être utilisées. Le but de l’exercice est d’indiquer en face de chaque besoin les données qui paraissent nécessaires aux métiers et de justifier de ce besoin. Le rôle du référent ici sera de vérifier le respect du principe de minimisation des données. Il s’agira pour lui de définir, en concertation avec les métiers, les données qui sont strictement nécessaires et celles qui ne seront pas pertinentes. Il pourra par exemple proposer d’utiliser des données pseudonymisées dans le cadre de certains traitements en particulier quand il s’agit de réaliser des statistiques.

Dans notre exemple, il sera nécessaire d’identifier les données qui sont pertinentes pour la mesure de la satisfaction du client. Il s’agira par exemple de données telles que nom et prénom du contact au sein de la société cliente, ses coordonnées, le produit acheté, la formule d’abonnement retenu, les critères de satisfaction (ergonomie, facilité d’usage, efficience de l’outil, qualité du support), chiffre d’affaires de la société, le taux de satisfaction, le panier moyen, la fonction du contact et sa capacité budgétaire. L’ensemble de ces données peut être justifié au regard du besoin des métiers.

– Les durées de conservation des données qui seront adoptées, à savoir pendant combien de temps les métiers ont besoin d’accéder à ces informations. La réponse « sans limitation de durée » est bien entendu exclue. Cette information permettra aux référents de déterminer si le besoin exprimé est proportionné en termes de limitation de la conservation des données.

Une fois ces premiers éléments définis, il conviendra de les présenter aux référents qui ne manqueront pas de soulever de nouvelles questions :

Quelle est la base juridique du traitement ? Comment va-t-on informer les personnes ? Quel est le meilleur support ? Qui aura accès à l’outil ? A qui ces données seront-elles transmises ? Et en matière de gestion des droits des personnes, qu’avez-vous prévu ? Quelles mesures de sécurité avez-vous prévu d’appliquer ? A-t-on une fiche au sein du registre concernant ce traitement ? etc.

Toutes ces questions devront être résolues au cours d’échanges avec les référents. Pour une gestion efficace, il s’agit avec les référents de mesurer la fréquence de leur participation aux comités de pilotage et pourquoi pas en dédier certains aux questions spécifiques de la protection des données. Ils doivent en tout état de cause être associés aux différentes phases du projet. Ces travaux permettront aussi aux métiers de prendre conscience de la protection des données et de les aider à savoir détecter les sujets et se rapprocher des référents. Selon la gouvernance mise en place, il conviendra également d’associer le DPO (Data Protection Officer ou Délégué à la Protection des Données) et de définir avec lui les moments opportuns.

Une bonne pratique projet peut être d’identifier dans toute la documentation de conception de la solution, une partie dédiée au Privacy by Design. Dans celle-ci, seront consignées, par tous les intervenants, les informations et décisions prises autour des données utilisateurs. On pourra en particulier trouver, par exemple, la liste des données utilisateurs qui sont manipulées dans le cadre du projet, les justifications de leur usage et la validation (et éventuelles remarques) des référents.

La phase de développement du PoC

En matière de protection des données, tel que précisé plus haut, une bonne pratique consiste à intégrer le suivi de la protection des données dans la comitologie projet. Il est important d’intégrer de manière régulière une session de suivi dans un comité projet (comité opérationnel, planification de sprint, …). L’idée de ces points de suivi étant de s’assurer que les recommandations faites par les référents sont bien appliquées et qu’il n’y a pas de nouveaux sujets identifiés à partager avec eux (besoins de nouvelles collectes de données, impossibilité de mettre en place techniquement des fonctionnalités liées à la protection de la données, …). Ainsi, un suivi dit Agile de la mise en place de la protection de la donnée est effectué et permet une mise en place efficace et adaptée des mécanismes associés.

Les phases de déploiement et de collecte du retour d’expérience

Il s’agit d’un nouveau moment clé. En effet, le lancement du PoC permettra d’identifier les carences du projet et très probablement de nouveaux besoins.

Dans notre exemple, un besoin d’utiliser les données collectées dans le cadre du traitement de satisfaction client a été détecté afin de prioriser les développements à réaliser sur l’outil. Pour cela il sera nécessaire de collecter en plus le nombre de clics sur les différentes fonctionnalités. Ce nouveau besoin constitue une finalité distincte de la mesure de satisfaction client et la collecte de cette nouvelle donnée implique de se reposer un certain nombre de questions :

S’agit-il d’une donnée personnelle ? Est-il possible de l’anonymiser ? Est-il possible de la « pseudonymiser » ? Cela a-t-il des conséquences sur l’information et les droits des personnes ? Quels sont les métiers qui pourront accéder à cette information ?…

Une nouvelle analyse sera nécessaire et les mesures techniques et organisationnelles devront être adaptées.

Les phases liées au développement de la version complète de la solution

Lors du développement de la version complète, le suivi de la mise en place de la protection des données personnelles doit être maintenu au travers des mécanismes proposés précédemment : notamment intégration de session de revue dans la comitologie projet et maintien des informations de protection dans la documentation de conception. Celui-ci peut être adapté en fonction des évolutions de la solution et des besoins de collecte ou de manipulation de données. En effet, certaines phases nécessitent une implication plus ou moins forte des référents.

Quelques mots sur les phases de Run

Une fois le Run lancé, tout développement d’une nouvelle version peut être vu comme le démarrage d’un nouveau projet. Le conseil va donc être d’appliquer ce qui a été proposé précédemment tout au long du projet. À noter un point d’attention sur les phases de maintenance opérationnelle et de support. En effet, les échanges avec les utilisateurs par exemple au travers du système de ticketing impliquera une manipulation des données d’utilisateurs par les équipes de développement. Un suivi attentif de toutes ces interactions doit être réalisé en collaboration avec les référents (adoption de process de gestion embarquant les sujets de protection des données). Enfin, le processus de conception et d’exploitation doit prendre en considération l’ensemble du cycle de vie d’un service ou d’un produit, de la planification initiale à la suppression du service/du produit. Dès lors, il conviendra également d’anticiper ce qu’il adviendra de la donnée.

Quels sont les avantages du Privacy by Design ?

Les avantages d’une approche Privacy by Design dans le déploiement d’un nouveau projet peut notamment permettre une réduction des risques juridiques liés à un manquement à la règlementation et démontrer sa capacité à fournir des services conformes à la législation.

Cela constitue dès lors un avantage compétitif et peut permettre également une réduction des coûts de développement des services dans la mesure où la protection des données n’est pas prise en compte seulement en toute fin de projet. En effet, une prise en compte trop tardive peut impliquer une remise en cause du projet, une augmentation de la charge de travail et un retard dans le lancement. Il est donc important d’intégrer la protection des données aux processus d’ingénierie dès la phase de conception et de les remettre régulièrement en question.

Enfin, tout ce travail réalisé devra être conservé car il contribuera à la documentation du traitement et donc à démontrer le respect des principes de Privacy by Design et d’Accountability, soit la capacité pour le responsable de traitement à démontrer sa conformité au RGPD.

Je partage