Le polygone de Mandel de la GDPR protection des données personnelles

J’ai proposé, il y a quelques années, de représenter la combinaison de cycles et de parcours qui caractérise un écosystème, un type d’entreprise, … ou plus généralement l’activité complexe d’un système humain, social, économique, … sous la forme d’un polygone dont chaque segment symbolise un des cycles ou parcours typiques de la dite activité.

Ce « polygone de Mandel » (voir aussi) est en quelque sorte une signature.

Cette représentation permet une abstraction ultime, bien commode comme point de repère quand on aborde l’analyse des systèmes. Cela pourrait être une base de la systémique. D’une systémique adaptée au monde numérique, où l’événement est la source de toutes les transformations.

Après quelques temps d’analyse de la réglementation sur les données personnelles, le polygone typique apparaît clairement.

Parcourons les différentes faces de ce polygone :

Exercice des droits de la personne physique

La réglementation reconnait des droits de protection des données personnelles. Ceci existait déjà depuis la loi « informatique et liberté ». Les différents droits sont précisés, complétés et leurs modalités d’exercice explicitées. Plusieurs articles du Règlement Européen sont dédiés à ces définitions (droit à l’information, à la rectification, à la portabilité, à l’oubli, consentement, droit des mineurs, …) et modalités : par exemple le consentement doit être spécifique (pas de consentement passe partout), explicite, univoque (acte de la personne), libre (pas de relation de subordination).

Evénements et traitements

Tout système informatique réalise des traitements, et des données personnelles peuvent être impliquées dans de tels traitements.

La réglementation impose que ces traitements soient licites :

  • s’il s’agit de données « sensibles » (cf Article 9) un consentement de la personne est obligatoire
  • pour les autres données personnelles, le traitement doit avoir une base légale (contrat, intérêt légitime, obligation légale), sinon un contentement explicite est nécessaire.

Ce cycle opérationnel est donc encadré de façon fine (croisement personne, catégorie de données, traitements) et c’est le cœur de la « licéité ». Cette contrainte peut avoir un impact diffus au sein du SI et des processus de l’entreprise, même si, dans la majorité des cas, les traitements sont réalisés au titre de contrats existants.

La réglementation a une exigence structurante pour le SI : un registre des traitements doit exister et contenir des informations obligatoires sur chaque traitement (finalités, types de données, responsable, …).

Il ne faut pas perdre de vue que la GDPR est basée sur un changement de paradigme : finies les déclarations préalables à l’organisme de contrôle, maintenant la responsabilité est transférée à l’Entreprise. Celle-ci doit en particulier ouvrir son registre au contrôle, et disposer d’outils de démonstration de la conformité de ses traitements.

Ces exigences sont à la base de la proposition de plateforme de conformité mise au point par le Laboratoire du Club Urba-EA. En cible, cette plateforme, connectée aux services de traitement par APIs, attribue les droits à traitements en vertu des consentements. De façon plus immédiate, la plateforme centralise les traces de traitements concernant les données d’une personne, constituant ainsi un outil d’audit et de démonstration de la conformité. Elle trace aussi l’exécution des traitements de protection demandés (portabilité, droit à l’oubli).

Intrusions, violations, incidents

Du point de vue de la sécurité des données personnelles et des risques encourus par les personnes physiques, la réglementation souhaite un niveau de sécurité proportionné à ces risques.

Les défauts de sécurité apparaissent à l’occasion de divers événements, avec une menace croissante. Ce segment du polygone est donc un des plus sensibles pour respecter le droit à la sécurité. En cas de violations de données l’autorité de contrôle doit être prévenue dans un délai de 72 heures. Les personnes concernées doivent aussi être alertées explicitement.

Là encore, le principe de la Réglementation est de considérer l’entreprise comme responsable, à charge pour elle de faire la preuve de ses mesures de prévention (cryptage, anonymisation, architecture de sécurité,..), et de disposer d’outils de démonstration adaptés.

Administration de la Protection

Au centre du dispositif préconisé, et exigé par la Réglementation, est placé le Data Protection Officer. Il doit veiller au fonctionnement interne, et correspondre avec l’autorité de contrôle. Il sera aussi en première ligne en cas de contentieux, provenant d’associations, ou de procédure d’amende administrative initié par l’autorité de contrôle (les fameux 4% du chiffre d’affaires mondial).

Cette fonction de DPO doit donc être dotée d’outils pour surveiller la conformité, détecter les incidents, informer les personnes et l’autorité, … et démontrer la sécurité et la conformité. Certains outils plus généraux du marché peuvent remplis ces fonctions (pour la partie sécurité), mais des outils spécifiques GDPR ne sont pas matures. Il faudra faire appel à des développements internes ou des co-développements. Le fait de disposer de la cible de plateforme proposée par le Laboratoire peut dynamiser ce partage et faciliter une telle économie d’échelle.

Vie des traitements

Avec la vie des traitements apparaît un volet de la réglementation fondamental. On parle de « Privacy by Design » : il s’agit de faire en sorte qu’un nouveau traitement n’introduise pas de risque pour les données personnelles. Il faut donc qu’il soit « conforme » sur tous les aspects vus : licéité lors des traitements, exercice des droits (par exemple révocation d’un consentement, effacement des données qui ne sont plus nécessaires, portabilité,…) respect des finalités, sécurité (pertes, fuites de données …).
Dans ce but les nouveaux traitements, et évolutions de traitements existants, doivent faire l’objet d’une étude d’impact (PIA : Privacy Impact Assessement).

Cette étude d’impact doit examiner le volet informatique du nouveau traitement, en anticipant sur l’architecture, elle concerne donc les projets bien avant la date d’entrée en vigueur en mai 2018 de la GDPR. De ce point de vue beaucoup d’entreprises qui n’ont pas anticipé cette échéance auront quelques difficultés. En effet le projet GDPR est un projet transversal, impliquant de nombreuses dimensions de l’organisation, un projet complexe, pluri-disciplinaire (juridique, IT, sécurité, organisation, communication, formation,…).

Bien sûr une telle évolution ne pourra être immédiate pour l’ensemble du patrimoine des traitements, un délai de 2 ans pour la mise en conformité est prévu par le dernier des « considérants » qui accompagnent les articles du Règlement.

Vie de la Réglementation

Dernier des cycles à étudier : à tout seigneur tout honneur, la réglementation elle-même évoluera.

Des adaptations nationales sont prévues dès à présent, en nombre heureusement limité, car leur multiplication aurait un effet néfaste sur l’efficacité et la crédibilité du texte. On a raison en effet de reprocher à la Commission de vouloir tout régenter de Bruxelles, sans appliquer la subsidiarité.

De plus, avec le degré de complexité atteint, et la superposition avec d’autres réglementations, par secteur professionnel par exemple, il y a des zones de flou, de pratique, qui se révéleront. Et la jurisprudence sera aussi progressivement à prendre en compte.

La plateforme de conformité proposée par le Laboratoire répond à cette problématique, car elle se base sur des éléments d’architecture des données durables : les grains opérationnels, les grains d’exercice des droits, qui composent une architecture flexible.

Une entrée vers les chaînes de valeur

La méthode de la Trame Business dont ce texte est une illustration, permet d’aller plus loin dans cette approche systémique.

En effet les schémas précédents ne structurent ni les configurations économiques (par exemple la fonction de DPO peut être partagée, tel traitement peut être en tout ou partie sous-traité, …), ni l’organisation (qui peut être centralisée, répartie, subsidiaire), ni les processus, ni le SI.

Afin de quitter le niveau d’abstraction proposé par le polygone, il faut examiner les chaînes de valeur, segment par segment. C’est ce qu’on appelle l’analyse d’un « univers de valeur ». Notre polygone nous amène donc à l’analyse de 6 univers de valeur, chacun dédié à une « transformation » caractéristique, et à ses chaînes de valeur. Sur le blog de René Mandel on peut trouver plusieurs exemples de tels univers.

La séparation des cycles structure les processus, les transformations réalisées par les logiciels, et les informations elles-mêmes.

Dans le cas de la GDPR, on retrouve, dans l’organisation de la cible GDPR-EA proposée par le Club Urba-EA, l’articulation entre ces cycles. On en déduit clairement que l’organisation de la cible, loin d’être issue de la fantaisie d’un analyste, est rationnelle et durable, car fondée sur la segmentation illustrée ci-dessus.

Une architecture du SI indépendante de l’Organisation

L’architecture traditionnelle résulte de l’organisation de la maîtrise d’ouvrage

Traditionnellement l’architecture du système d’information était « moulée » sur l’Organisation. En effet, naturellement, la vision locale des « maîtres d’ouvrage » se traduisait, depuis l’expression des besoins jusqu’à la validation des projets, par une structuration du SI. Les synergies, les transversalités, entre les divers composantes du SI, se limitaient à un périmètre local.

Les SI se sont ainsi développés « en silos ». L’urbanisme des SI, puis l’Architecture d’Entreprise ont compensé cette tendance centrifuge, en proposant des projets transverses, une gouvernance centrale, des cibles communes, des architectures de confrontation, de consolidation.

Tous les modèles d’architecture sont désormais possibles

A l’époque du « data centric » faut-il que les architectures soient déformées, gouvernées, dans tel ou tel modèle ?

On voit bien qu’avec la technologie actuelle tout est possible : que le système évolue, au cours des projets, autour d’un modèle central, ou au contraire par une nébuleuse de systèmes synchronisés, ou toute solution hybride… tous ces modèles sont viables.

Mais les transformations d’architecture sont difficiles

En réalité, même si tout est possible sur une feuille blanche, le changement de modèle s’avère extrêmement difficile. Les migrations sont complexes. Les big bang sont coûteux et traumatisants. La gouvernance réveille de vieux conflits, pose des questions de principe, de préséance, … les positions figées sont archaïques au regard des potentiels technologiques.

Le problème est qu’on ne sait pas cibler l’usage de la technologie sur les quelques points de blocage de l’évolution d’ensemble de ces systèmes. On voudrait que les systèmes soient, dans toutes leurs composantes, mis en mouvement, ce qui est bien sûr complexe, et impossible dans une échelle de temps raisonnable. On pense au mieux que la définition d’une cible permettra d’atteindre progressivement l’objectif. Malheureusement ce type de solution, encore viable il y a quelques années, est dépassé et discrédite les Architectes d’Entreprise, et leurs diverses écoles, leurs certifications et lourdes méthodologies.

Pour transformer l’architecture, placer l’Architecture Flexible en son cœur

Abandonnant ces ambitions irréalistes, on se concentre sur le cœur d’une architecture en l’Etat de l’Art : une plateforme d’intégration. On agit sur ce noyau et sur ce noyau seulement. C’est ce que propose l’Architecture Flexible, en définissant une telle plateforme, qu’elle soit centralisée ou composée de systèmes autonomes synchronisés.

L’exemple de la réglementation sur les données personnelles

Par exemple, pour répondre aux impératifs de la gestion des données personnelles (RGPD alias GDPR), il faut introduire de nouvelles transversalités. Cela peut se faire de façon dispersée en instillant les fonctions nécessaires dans les différents silos. Cela peut aussi se faire grâce à une plateforme partagée, dite « plateforme de conformité ». Cette dernière solution permet une introduction progressive, et opportuniste, des fonctions de conformité, sans big bang, et avec une géométrie variable.

 

En somme, juste retour des choses, il devient alors plus facile de changer un SI flexible, pour l’adapter à l’Organisation, tout en préservant les transversalités, et les invariants, que de se lancer dans le changement frontal de l’Organisation. A terme, avec un tel SI flexible, l’optimum organisationnel, libéré des rigidités du SI, sera trouvé par transformation progressive, et adaptation darwinienne.