La réglementation GDPR défi d'Architecture d'Entreprise

La prochaine réglementation de protection des données personnelles (GDPR) sera en application dans l'ensemble de l'Europe dès mai 2018.

Pourtant, les entreprises et organisations ne semblent pas prendre la mesure de l'enjeu, de la sensibilité du sujet, de sa complexité, et des risques.
Par exemple peu de DPO (Data Protection Officer) ont été désignés. Pourtant ce prérequis est nécessaire. Face à une réglementation complexe, les DPO auront-ils le temps de l'assimiler ? Auront-ils les moyens d'agir d'ici l'échéance ?

Chaque entreprise devra faire des choix pour appliquer cette réglementation d'une centaine d'articles, et d'autant de "considérants"... et faire face à d'éventuelles procédures individuelles et collectives. Dès la promulgation de cette loi, européenne, les responsabilités sont clairement posées. Les DPO seront en première ligne, comment seront-ils outillés ?

Une situation paradoxale

Certes la nouvelle réglementation prolonge les réglementations précédentes, mais elle en change la magnitude :

• s'appliquant dans toute l'Europe, elle devient de fait obligatoire pour les multi-nationales,
• elle introduit de nouveaux droits (portabilité des données, droit à l'oubli, droits des mineurs, droit d'information en cas de piratage des données, ...) et des modalités de mise en oeuvre contraignantes (consentement clair et explicite, information compréhensible,...),
• les procédures de recours et les amendes ont été sérieusement durcies par rapport aux règles précédentes, les amendes administratives pouvant s'élever jusqu'à 20 000 000 EUR ou 4 % du chiffre d'affaires annuel mondial de l'entreprise.

Pour les entreprises, dès lors qu'elles ont une activité qui nécessite l'usage de données personnelles, le risque est patent. On peut douter de cette réalité, mais divers "contre-pouvoir" auront là une voie de recours, et il serait étonnant qu'ils n'en fassent pas usage.

Paradoxe donc entre l'apathie des entreprises et organisations, et les risques encourus, juridiques, financiers, et de dérapage d'image au cas où une pratique non conforme apparaîtrait au grand jour.

Un "tsunami" pour le SI ?

La GDPR est une problématique globale, systémique, pour le SI. Un enjeu aux infinies répercutions, dans les dédales du patrimoine SI. Un problème de type "An 2000" ou "Euro", genre de dépense qui n'apporte pas de valeur, et dont le coût est imprévisible ?

Le sujet est, en soi, plus complexe qu'à l'ordinaire. Complexe et incertain, car, sur bien des articles du texte, plusieurs interprétations seront possibles.

L'incertitude est stratégique : quelle anticipation, quelle vision ? qui croire des plus optimistes (doute sur l'application du texte, probabilité de contournement,  jurisprudence favorable à l'entreprise,..), au plus pessimistes (rigueur des procédures, exigences sociétales croissantes, ... ) ?

L'incertitude est aussi technique. La mise en conformité du SI, peu étudiée jusqu'à présent dans l'attentisme ambiant, sera-t-elle :

• Rapide, peu coûteuse, localisée seulement en certains endroits du SI ?
• Ou au contraire, au long cours, impliquant de multiples adaptations interdépendantes ?

Une question typique "d'urbanisme du SI", "d'Architecture d'Entreprise" 

La problématique centrale de l'Architecture d'Entreprise (EA), est de faire évoluer "en douceur" et à moindre coût, un patrimoine SI. La GDPR, par delà les questions stratégiques posées, relève typiquement d'une telle problématique.

Avec le temps qui passe, le défi prend de la force : le temps de cycle de l'EA est un temps plus long que celui des développements agiles, de par la complexité de systèmes empilés, imbriqués et étendus.

Particulièrement dans de grandes structures, tous les systèmes ne sont pas centralisés, il existe des silos organisationnels, des filiales, des entités locales... alors que le risque propagé par la GDPR est un risque d'image global. Le risque technique existe dans ces diverses configurations, et, par la structuration du SI qu'elle a créé, l'Architecture est critique pour ce risque.

Du point de vue "architectural", distinguer "cœur GDPR" et annexes

Au vu de la réglementation, et de ses multiples dispositions, il faut se donner un point de vue architectural,  Ainsi peut-on distinguer, dans les fonctions requises, des fonctions "cœur" et d'autres "annexes".

La réglementation implique des fonctions "cœur" :

• Fonctionnements des traitements réalisés qui doivent être conformes : ne pas réaliser un traitement correspondant à une finalité pour laquelle le consentement n'a pas été recueilli.
• Limiter le champ sémantique et l'historique des informations au minimum requis pour les traitements consentis,
• Exécuter le droit à l'oubli, etc ...

Ces fonctions sont complétées par des fonctions annexes, qui bien que majeures, s’appuient sur les fonctions "cœur" :

• Recueillir et gérer les consentements
• Informer les personnes des incidents survenus (atteinte à la sécurité, ...)
• Tenir un registre des traitements,
• Gérer les demandes de portabilité, ...

Bien sûr, ce n'est ici qu'une esquisse d'analyse du sujet, sommaire. Mais elle vise à faire un premier tri, et, par exemple, de clarifier les subsidiarités possibles (selon les finalités, les profils de personnes, les pays, ...) à prévoir dans l'Architecture.

La vision "cycle de vie du patrimoine"

L'Architecture d'Entreprise, par une approche méthodologique très orientée "grand projet", pourrait inciter à un "urbanisme" "haussmannien" : casser de grandes zones du SI pour les refaire à neuf.

Ceci serait possible dans le cadre de grands programmes, mais l'opportunité est rare. Le responsable de la mise en place de la GDPR n'aura certainement ni le délai, ni les moyens pour cette thérapie chirurgicale.

Le problème est dès lors :

• d'une part de statuer sur le cas de nouveaux développements au sein du SI, pour qu'ils soient "nativement" conformes (approche dite "privacy by design")
• d'autre part de faciliter une migration progressive du patrimoine, au fil de l'eau, de façon déconcentrée, pour s'aligner à la conformité.

On retrouve là encore un grand classique de l'EA, et des défis de long terme auxquels elle répond.

Propager la conformité au sein de l'iceberg SI

De ces premières réflexions émergent quelques idées simples :

• le cœur d'architecture est clé pour la conformité à la GDPR, que ce soit pour le "privacy by design", ou pour la propagation de cette conformité au sein de l'iceberg du SI existant
• ce cœur d'architecture est fortement générique, car reposant sur un modèle semblable quelques soient les organisations (personnes, finalités, activités, consentements)
• le schéma typique, pour ce cœur, fondé sur des référentiels pour la structuration, et des "puits de données" pour le traçage des interactions, relève de l'Architecture Flexible.

En somme, malgré la complexité inhérente au sujet, pour les entreprises et organisations, une possible voie est tracée. 

L'initiative du Club Urba-EA

Le  Club Urba-EA a décidé de prolonger ses travaux sur les pratiques en entreprise, par la mise en oeuvre d'un Laboratoire de la Flexibilité, dans le but de tester et démontrer des architectures innovantes. Dans le cadre de ce Laboratoire, la question des données personnelles sera l'objet de réflexions et de réalisations concrètes de prototypes.

Le cas de la GDPR, par sa généricité et son universalité, permettra de réaliser un démonstrateur de "moteur de conformité GDPR". Il illustrera le framework dont les bases sont indiquées ci-dessus.
Un tel produit simplifié sera un accélérateur, et levier d'architecture, pour les projets que les entreprise et organisations auront à conduire dans les mois qui viennent.