Extension de l’accélérateur à l’ensemble des articles de la GDPR

L’accélérateur GDPR se développe par démarche incrémentale. La version initiale est réduite à quelques articles de la loi européenne, mais la couverture de l’accélérateur sera progressivement étendue à plusieurs articles.

La cible de l’accélérateur est une couverture totale, prenant en compte l’ensemble des articles.

Pour ce faire, l’architecture proposée actuellement n’est pas, dans ses grands principes, remise en cause, mais elle doit être complétée. La prise en compte de certains articles nécessite des évolutions.

On peut lister les différentes questions qui se posent :

  • accès aux informations détaillées
  • gestion des durées de rétention des informations
  • gestion des données sensibles
  • cas des mineurs
  • violations de données, portabilité

Nous reprenons ces questions ci-dessous, et les réponses qu’on peut leur apporter.

Accès aux informations détaillées

Le droit d’accès, puis le droit de rectification, concerne des informations détaillées. Ces informations relèvent d’une « maille » plus fine que celle qui est répertoriée dans le registre : dans celui-ci il y a simplement le lien entre traitement et catégorie d’informations.

On pourrait créer par ailleurs un lien entre traitement et informations détaillées. Une première solution est de disposer d’un dictionnaire de données qui détaille les catégories d’information du registre.

En toute hypothèse un dictionnaire de données est nécessaire. De plus, pour l’établissement du projet de mise en conformité, et pour maintenir la conformité au niveau souhaité, il semble incontournable d’avoir à gérer une « référence croisée » données-traitements. Ceci est réalisé par les outils du monde de la gestion des patrimoines de données et de traitements. Le registre des traitements et le dictionnaire de données, nécessaires au monde « opérationnel » de l’accélérateur et de sa plateforme, doivent donc être alimentés par ces systèmes, par des interfaces, des API ad-hoc.

On peut voir cet ensemble du dictionnaire et du registre comme relevant d’une problématique de MDM, avec les problèmes de gestion de qualité, de workflow, de gouvernance habituels.

Dans le cadre de la GDPR, le point d’entrée est la finalité : il n’est pas dit que la même information, intervenant dans différentes finalités, doive être identique. D’ailleurs la personne est en droit de corriger les informations, c’est à dire de supprimer une incohérence du SI, ou de maintenir une apparente incohérence. Le point juridique est de savoir quel est le statut d’un traitement de mise en qualité d’une donnée personnelle qui serait dupliquée dans le patrimoine. Du point de vue pratique, il faut identifier les redondances d’information au sein du patrimoine, afin de tracer de tels traitements de mise en qualité, et de leur attribuer une licéité certaine.

Ce thème est délicat : il concerne la référence croisée fournie par le dictionnaire données-traitements, son niveau de finesse, et la mise en qualité de cette correspondance.

Du point de vue de la plateforme de conformité, on se contentera de disposer d’un dictionnaire confrontant une nomenclature d’informations, et un registre de traitements : ceci permet de trouver les informations concernées par un traitement, et d’enregistrer des demandes d’accès et de correction. Bien sûr, ces nomenclatures et registres doivent être historisés, ainsi que la table de référence croisée, avec des dates qui autorisent une évolution de ce cadre de référence.

Gestion des durées de rétention des informations

Que ce soit pour le « By Design » ou le droit à l’oubli, il faut gérer la durée de rétention de l’information. Ceci concerne aussi notre référence croisée, car rien ne prouve que, sur la même information, la durée de rétention soit uniforme : elle dépend évidemment de la finalité.

La référence croisée doit donc fournir la durée de rétention nominale. Le puits des exigences trace la demande spécifique d’une personne, la demande d’oubli, qui est assimilable à une demande de correction. La subtilité est que l’oubli est contextuel du traitement, ce qui peut devenir difficile à gérer dans une organisation de données maîtres.

Gestion des données sensibles

Les données sensibles, articles 9 et 10, doivent bien sûr être repérées dans le dictionnaire. Là encore, il est possible que la sensibilité d’une donnée soit fortement liée à la finalité, et doive donc être attribuée au niveau de la référence croisée. Ce point est aussi très important à tracer, par exemple par un workflow de gouvernance du référentiel constitué par la référence croisée.

Cas des mineurs

Le cas des mineurs est à prendre en compte :

  • une personne est dépositaire de leurs droits tant qu’ils n’ont pas atteint l’age,
  • puis ils trouvent leurs droits, et cela doit être explicité.

La façade personne doit donc gérer cette forte contrainte. Il est probable que le régime transitoire créé au moment du passage à majorité aura des conséquences sur le modèle de données des composants de la plateforme (double identification de personne pour les mineurs).

Violations de données, portabilité

La prise en compte de certains articles, comme la violation de données, la portabilité… devrait être transversale. Il faudra des traitements spécifiques pour répondre aux prescriptions de la réglementation. Tous ces traitements ne justifient pas une automatisation, coûteuse pour un flux faible, voire exceptionnel. Mais qu’ils soient automatisés ou semi-automatiques avec un workflow, il faudra les référencer dans le registre, et en tracer l’exécution dans le puits des exécutions.