Privacy by Design : cas de l’accélérateur GDPR

La Réglementation Européenne de Protection des données personnelles (GDPR alias RGDP) prévoit que, dès la conception des projets, ceux-ci soient conformes. Ce « Privacy by Design » est une disposition particulièrement économique et prudente pour les très nombreuses entreprises et organisations soumises à cette réglementation. En effet, elle leur évite les coûteux frais d’adaptation, en particulier pour les applications informatiques qui représentent près de 70 % du coût de mise en conformité à la GDPR.

Composante architecturale du Privacy by Design

Le Privacy by Design se décline en de nombreux aspects (organisation, processus, juridique, sécurité informatique) qui concernent autant de responsabilités internes.

Parmi tous ces aspects, la composante architecturale est sans doute celle qui a le plus d’impact potentiel, le plus fort effet de levier. En effet la réglementation est transverse à l’entreprise, quelles que soient les personnes concernées (clients, salariés, prospects, partenaires, ..), et quels que soient les « traitements » et « finalités ».

L’architecture Privacy by Design s’impose donc à toutes les organisations de l’entreprise : sa qualité fondera la qualité des solutions locales ou subsidiaires, ou, a contrario, ses défauts se propageront dans tous les domaines du SI de l’Entreprise.

Dans de grands comptes, il existe une équipe d’Architecture d’Entreprise : il lui revient en toute évidence, sauf à démissionner de son rôle, de définir le socle de conformité commun à l’Entreprise.

D’ailleurs, il serait pour elle illusoire de s’en remettre au marché des éditeurs et autres fournisseurs de service : ce marché est historiquement fragmenté et organisé face aux silos des métiers. Bien sûr chaque éditeur affirme qu’il répond au problème dans sa globalité. Mais il ne peut le faire de par sa position spécialisée. Et s’il propose une architecture globale, une architecture intégrée, elle pousse le client, d’intégrations en intégrations, à confier toutes les clés de son SI. Autre démission dangereuse sur un sujet hyper-sensible. Soyons lucides : les GAFA sont les mieux placés pour une offre globale et transversale. No comment.

Le sujet parait d’ailleurs insoluble, tant les données personnelles se sont subrepticement localisées dans de nombreux domaines du SI, avec des duplications incontrôlées, des conservations non-gérées,…

Le modèle architectural de conformité

Du point de vue architectural, le problème se divise, grâce à la cohérence de la réglementation, à l’application des canons de l’Architecture Flexible, en un problème architectural central majeur, et 4 problèmes subsidiaires.

La plateforme de conformité

La question majeure est celle de l’architecture de conformité : le principe est simple, mettre en commun l’ensemble des fonctions communes nécessaires, et les rendre les plus « génériques » possible. On aperçoit ainsi 3 dimensions de généricité :

  • par rapport aux différentes catégories de personnes (catégories prévues dans la réglementation : clients, salariés, etc.)
  • par rapport aux différents « traitements » (répertoriés dans le registre légal article 30, du point de vue informatique, déclinés en « applications »)
  • par aux différents droits des personnes (accès, consentement, oubli, portabilité, opposition, limitation, correction, …)

Cette architecture de conformité, ainsi définie, est réduite : une cinquantaine de données réparties entre une douzaine de tables relationnelles ou équivalent, représentant un petit nombre d’objets génériques. Une « clé de voûte » de la conformité, strictement identique d’une organisation à l’autre. Dans l’optique du Privacy by Design, le respect de cette architecture est facile et peu coûteux, il se limite à des principes d’interface, par exemple par API, et de traçage par des « puits d’événements » dédiés, qui constituent le cœur de la « plateforme de conformité ».

Les 4 « façades » : des conformités subsidiaires

Dans le modèle architectural de conformité, dont la plateforme constitue l’élément central, celle-ci interfonctionne avec 4 façades. Ces façades sont des domaines d’intégration orientés vers 4 problématiques spécifiques. Elles sont, dans une vision générique, globale et systémique, les suivantes:

La façade personne : intégrer aux différents canaux d’interactions avec les personnes, et quelles que soient les variantes technologiques, les prescriptions de la réglementation pour informer, recueillir les demandes de droit, mettre à jour les consentements, etc… Certes cette intégration se subdivise selon les catégories de personnes (en particulier celles qui sont référencées dans le registre obligatoire au titre de l’article 30), et soulève les classiques sujets de référentiel des personnes, de cohérence, voire de subsidiarité. La GDPR peut être une opportunité, ou non, de faire le ménage dans cette « façade personnes ». A tout le moins, dans le Privacy by Design, on alignera le CRM, la GRH, le marketing, aux modalités d’interaction exigées par la réglementation.

La façade du patrimoine a une autre dimension de complexité, car les traitements sont dispersés dans les applications « métier » diverses et variées. Il faudra ici appliquer le cœur de l’exécution des droits, conforme aux consignes générales (frugalité, limitation de la conservation, …) et appliquant les droits demandés par les personnes. Dans le Privacy by Design, grâce à la plateforme, bien des aspects sont simplifiés, et l’effort « urbanistique » sera de répondre aux demandes des personnes (accès, correction, portabilité, …), et en respectant le protocole porté par la plateforme. Dans l’absurde, si un tel effort n’est pas imposé aux projets, on créerait une évidente et coûteuse dette d’urbanisme.

La façade des modèles, regroupe la description du patrimoine SI bien connue des Architectes et des Data Officer : on y décrit les applications, les données, les processus. Ces informations sont précieuses pour formater le registre, et orienter l’accès aux données. Là aussi il faudra mettre en place les interfaces, les API, les points de vérité, pour relier les métiers (Architectes, responsables de traitement, DPO, CDO, …) autour d’un équilibre de gouvernance intégrant les conformités qui s’imposent à l’organisation (GDPR, LCB-FT, et conformités sectorielles).

La façade DPO, de protection des données, est dédiée, quant à elle, aux métiers de la protection (Data Protection Officer, responsables de traitements, RSSI, …). Elle doit aussi impérativement être outillée, autour du registre obligatoire qui en est l’élément clé. Ce registre ne doit pas se limiter à un rôle documentaire passif : il est le composant informatique central de l’architecture et du Privacy by Design, interfonctionnant par API avec la plateforme et la façade des modèles. Le registre est le point de vérité sur les traitements, finalités, catégories de personnes et de données.

Avec le principe du « Privacy by design » un traitement doit être, en matière de protection des données personnelles, conforme dès sa conception. Dans cette optique, il est impératif que les modalités d’intégration prévues soient respectées.

Le modèle d’intégration à appliquer

Dans le cas de l’accélérateur GDPR, la plateforme de conformité mise en oeuvre par l’accélérateur apporte des garanties, mais à plusieurs conditions :

  • que la plateforme soit bien utilisée, selon les modalités d’intégration prévues,
  • que le nouveau traitement prenne en charge la part de conformité qui lui revient,
  • avec une implication distincte selon les « façades » (personnes, DPO, patrimoine).

Utiliser la plateforme selon les modalités d’intégration prévues

La plateforme a plusieurs fonctions, et il est souhaitable, pour un fonctionnement optimal, de respecter le « monopole » de ces fonctions :

  • enregistrer, tracer les « demandes » des personnes (le terme « demande » est générique : il désigne toutes les demandes faites au titre des articles  de droit des personnes : articles 5 à 22),
  • enregistrer et tracer toutes les actions, automatiques ou non, faites en vertu de la GDPR, à la suite de demandes ou d’autres événements,
  • répertorier les traitements (au sens de l’article 30).

Dans le cadre d’un nouveau traitement, ou de la modification d’un traitement, le Privacy by Design implique que le traitement respecte cette architecture, qui fournit un cadre fonctionnel pour tous les composants du SI, en particulier en utilisant les moyens techniques proposés pour interfonctionner avec la plateforme.

Chaque traitement prend en charge la part de conformité qui lui revient

La conformité est obtenue d’une part du fait de l’architecture (modalités de gestion des exigences, traçage des exécutions, registre à jour et utilisé par l’architecture pour faire le lien traitement-catégorie de personne…), d’autre part du fait du fonctionnement du traitement en cause (par exemple appliquer les exigences des personnes (exercice des droits, consentements,…) demandées pour ce traitement).

La part de conformité dévolue au traitement peut varier selon la maturité de la plateforme :

  • dans une version initiale, par exemple pour les consentements, au cas où le consentement est nécessaire, l’application qui réalise le traitement doit rechercher dans le puits des demandes l’existence d’un consentement valide émanant de la personne
  • dans une version plus évoluée de la plateforme, cette recherche est faite par la plateforme et se traduit par une réponse de validation ou d’invalidation du traitement.

Une implication distincte selon les « façades » (personnes, DPO, patrimoine)

La conformité incombant à un composant, ou à une application, est distincte selon les « façades » où cet élément intervient :

L’exemple d’exécution du traitement est le cas de la façade patrimoine, le cas standard d’invocation de la plateforme,

  • mais il y a aussi le cas des traitements à réaliser par les applications ou composants de la façade personne. Ceux-ci ont en charge le dialogue avec les personnes dans des cas types : CRM, RH, clients, … Ils disposent d’informations fournies par le registre, les référentiels et puits de la plateforme et doivent les fournir selon des modalités conformes (transparence, simplicité, …), avec une ergonomie adaptée,
  • de même les composants de la façade DPO devront fournir les dialogues conformes, essentiellement en terme fonctionnel, aux responsables des traitements et au DPO.

Liste des interfaces à respecter

En pratique le Privacy by Design impose dans le cas de la « façade personnes » le respect d’interfaces :

  • Dépôt des demandes (puits des demandes), consultation des demandes : respect de la norme « pivot des demandes »
  • Dépôt et mise à jour des consentements : respect de la norme « pivot des consentements »
    Interface de consultation du registre
  • Consultation de la façade des modèles (applications, données)

 

Dans le cas de la façade « patrimoine » :

  • Consultation des demandes (puits des demandes)
  • Dépôt des exécutions (puits des exécutions) : respect de la norme « pivot des exécutions »

Les différents cas d’interfaces sont repris dans le tableau ci-dessous.

Nomenclature interfaces