Image

Actualités

22.02.2017 []

Projet de démonstrateur de moteur de conformité à la GDPR (Privacy by Design)

La nouvelle réglementation européenne (GDPR) sur les données personnelles impose le consentement explicite des personnes physiques sur la finalité des traitements utilisant leurs données.

Elle doit être en application en mai 2018 pour les entreprises et administrations, avec un arsenal de pénalités dissuasif.

On comprend aisément que le patrimoine SI actuel n’est pas en conformité avec cette réglementation. Dans les grandes entreprises et organisations, au delà des finalités initiales, des « propositions de valeur » complémentaires sont apparues. Certaines clauses complexes créent une insécurité juridique, et on peut craindre alors qu’il faille revoir les règles d’alignement à la Réglementation. On se doute que les impacts sont multiples, diffus, voire évolutifs. Un travail difficile à évaluer, et des délais bien courts.

On est face à une problématique type An 2000 ou Euro, avec plus de subtilité juridique.

Une approche est d’évaluer les écarts, les risques, et de prioriser. Des prestataires sont sur le sujet. Des guides sont élaborés. La complexité du discours juridique est importante, et jette un trouble cachant l’essentiel.

Dans le fond, l’implication de l’Architecture du SI est évidente : l’Architecture existante a été conçue alors que certaines contraintes n’existaient pas, ou existaient sous une forme réduite (déclaration à la Cnil…) et fragmentée par pays.

Maintenant la question est différente, globale, et la responsabilité clairement transférée aux entreprises et organisations (désignation d’un DPO, Data Protection Officer).

Ce sujet ne pourra être traité au long cours sans un alignement de l’Architecture. Il ne pourra l’être par Big Bang, mais par une évolution progressive, et une adaptation aux impératifs et risques majeurs.

Typiquement une Architecture Flexible est nécessaire. Flexibilité d’adaptation au contexte architectural, flexibilité aussi pour coller aux évolutions. Justement le Club Urba-EA a créé le Laboratoire de la Flexibilité pour tester des Architectures innovantes.

L’opportunité est de monter un démonstrateur simplifié d’un « moteur de conformité » à la GDPR. Dans le principe, il s’agit tout simplement, pour une Entreprise ou une Administration, de mettre au centre de son SI, et de ses échanges et interactions (quels que soient les protocoles ou latences), une plateforme du type de celle définie pour l’Architecture Flexible. Cette plateforme vérifie la conformité de ces interactions (au niveau du « grain » fin) : pour chaque personne, et selon les règles à appliquer, elle les autorise, ou émet le signal approprié, au cas par cas.

On peut démontrer ce fonctionnement pour un projet neuf, avec des cas types de traitements construits en symbiose avec la plateforme de démonstration. Cette simplification a du sens, car, si on ne sait pas traiter ce sujet, on ne pourra pas, a fortiori, s’attaquer au « plat de spaghetti » du patrimoine existant.

Dans le même ordre d’idée, on pourra démontrer le fonctionnement d’un embryon de « puits » destiné à tracer les interactions et traitements concernant les personnes. Ce composant, très peu intrusif, permettrait d’auditer le fonctionnement d’une partie du patrimoine, au regard de la réglementation. L’avantage est aussi qu’il préfigurerait le fonctionnement nominal en cible, en préfigurant le puits d’historisation pour la traçabilité.

Ce n’est donc pas techniquement un saut dans l’inconnu, on dispose largement des technologies nécessaires (API management, data integration, SGBD, …). D’une entreprise à l’autre la question de la conformité se pose dans une logique similaire, il faut simplement changer le paramétrage des finalités, traitements et consentements. C’est un sujet générique global (tout pays, transverse aux métiers).

Bien sûr, dans le cas du « démonstrateur », on se limitera à quelques cas d’usage typiques (rejet d’un traitement qui ne satisfait le consentement d’une personne, mise à jour par une personne de ses consentements, audit des traces enregistrées par le moteur, …). On ne cherchera pas non plus à instancier ce moteur sur une architecture technique cible de référence, ni à l’adapter à celle de telle ou telle entreprise. Il s’agit d’un démonstrateur « fonctionnel ».

Les fonctions, enrichies et sécurisées, seront à reprendre par chaque entreprise pour les implanter sur son architecture interne, son espace sécurisé (résistance aux intrusions, scalabilité, cohérence…), et en vertu de sa stratégie de prise de risque juridique. Elle pourra dès lors faire état de son engagement vers ce qu’il est convenu d’appeler une « Privacy by Design« .

De ce fait le démonstrateur pourra être réalisé dans des coûts et délais raisonnables. Pour chaque entreprise partenaire, il pourra servir de base pilote dans le cadre d’une transposition en « vraie grandeur », sur son contexte spécifique. Il permettra aussi d’illustrer les chemins de migration et de bascule progressive, et par ensembles réduits, du patrimoine existant à mettre en conformité. On s’intéressera à des cas types représentatifs choisis par les partenaires (campagne marketing, …), en esquissant les solutions qui se présentent, dans tel contexte architectural (CRM, ESB, …).

Ce projet pourrait aussi montrer l’utilisation d’une « architecture inversée », laissant certains utilisateurs gérer leurs propres données personnelles. On peut envisager de prototyper ainsi, autour du démonstrateur, différents scénarios d’architecture plus ou moins inversée, par exemple se basant sur la technologie émergente de la blockchain.

Au delà de cette première phase de réalisation d’un démonstrateur, le Club Urba-EA n’a pas vocation à finaliser un produit à mettre sur le marché. Le Laboratoire de la Flexibilité, ayant rempli sa mission, pourra développer une démarche similaire sur d’autres sujets.

Ce projet simple et rapide a un très fort ROI, permettant d’accélérer et de fiabiliser les travaux de mise en conformité à la réglementation. Un projet agissant au cœur du SI des grands opérateurs, tout en préparant les architectures de « self data » futures.

Voir aussi sur le blog de R Mandel.

12.02.2017 []

Management de la Data... que couvre le terme Data?

Comme seconde base de travail, nous vous proposons d’adopter une définition large du terme Data couvrant l’ensemble des informations sous…

LIRE L'ARTICLE

[]

Gestion de la Data vs Gouvernance de la Data - Définition

Comme base de travail pour notre projet nous vous proposons ces définitions issues du CIGREF. La gestion des données (ou…

LIRE L'ARTICLE

16.09.2016 []

Prochaine et dernière réunion du Groupe Projet : Jeudi 27 Octobre 14:30

La réunion se tiendra dans les locaux d’Oresys rue de Londres. Avec Michel on vous y présentera et soumettra a…

LIRE L'ARTICLE

27.06.2016 []

Vie du projet "Vers une AE data centric" - prochaine réunion le 5 juillet à 9h 30

Bonjour,   Vous trouverez dans l’espace du projet, sur le site du Club, l’ensemble des documents diffusés à ce jour…

LIRE L'ARTICLE

20.06.2016 []

Re: Datalake: Définition du Gartner transmise par Pierre Nénert / puits de données

Justement, avec toutes ces belles métaphores, il est parfois difficile d’y voir clair… en eaux troubles ! J’essaie de contribuer…

LIRE L'ARTICLE

[]

Re: Datalake: Définition du Gartner transmise par Pierre Nénert / puits de données

Justement, avec toutes ces belles métaphores, il est parfois difficile d’y voir clair… en eaux troubles ! J’essaie de contribuer…

LIRE L'ARTICLE

[]

Re: Datalake: Définition du Gartner transmise par Pierre Nénert / puits de données

Une fois encore les « informaticiens » font preuve d’une tendance à bricoler la sémantique des mots pour essayer de se caler…

LIRE L'ARTICLE

« Page précédentePage suivante »