Présentation de l’accélérateur GDPR du Laboratoire du Club Urba-EA

La réglementation Européenne pour la protection des données personnelles, RGDP alias GDPR, a un fort impact sur le SI, tant pour le patrimoine que pour les projets.

Suite aux travaux réalisés dans le Club Urba-EA en 2017, pour 2018 nous proposons une avancée significative avec la réalisation d’une maquette d’accélérateur GDPR, en partenariat avec des éditeurs (Axway, DPO Consulting et Orchestra Network).

Ce projet inter-entreprises, mené en souscription auprès des membres du Club Urba-EA, vise à illustrer, sur des cas concrets, les apports d’une Architecture Data Centric configurée pour la GDPR.

 

Une séance d’information sur ce projet aura lieu :

 

Mercredi 6 décembre 2017

à 14h00

48, rue de Londres, 75008 PARIS

 

Vous pouvez vous y inscrire en contactant : chargedecommunication@urba-ea.org

Architecture Flexible et micro-services

Le développement de logiciels, après l’époque du SOA, et de ses architectures orientées services, a pris le chemin du développement fractionné en micro-services.

Les questions d’architecture se trouvent ainsi déplacées, sans que l’on puisse affirmer qu’elles gagnent en simplicité ou en complexité.

Dans le nouveau monde du bouillon de culture d’Hadoop, des solutions émergent, dans une découverte « botton-up » de l’architecture (Kafka est le produit phare de cette émergence).

L’architecture Flexible est, a contrario, une approche fondamentalement top down, partant des chaînes de valeur, de leurs invariants, avant d’entrer dans les visions du SI.

A la lecture de blogs d’évangélistes des microservices et des innovations des architectures événementielles, la synergie entre les 2 approches, l’une bottom up, l’autre top down, est fructueuse.

Sur ce sujet, voir le texte paru sur « Value-Architecture ».

Bonne lecture

La mutation de l’Architecture d’Entreprise avec le « Data Centric »

L’Architecture d’Entreprise « historique » en retrait

L’Architecture d’Entreprise s’est constituée par un lent processus de maturation, dans un contexte historique de technologies qui créaient de fortes contraintes, avec de multiples limitations, au regard des puissances technologiques que nous pratiquons maintenant.

Dans le monde actuel, nativement évolutif, cet historique pèse, et la discipline répond de plus en plus mal aux enjeux, se plaçant en retrait des mutations en cours.

L’Architecture d’Entreprise a toujours eu des leviers d’action limités

La fonction d’Architecte d’Entreprise provient du constat des errements créés par le désordre des projets.

Initialement, cette fonction se focalisait sur le périmètre des systèmes d’information, et a, pendant un temps, généré de grands projets avec une cible structurante pour le SI.

Cette époque est révolue, d’une part à cause des taux d’échec inhérents à de tels projets, de la complexité des migrations et intégrations, et de la réduction des moyens disponibles.

Une faible prise sur les projets

Dans l’idéal, ne pouvant casser le récif de corail du patrimoine SI, le plus efficace dans la durée serait un alignement progressif à une cible d' »urbanisme », au fil des projets.

Cet « urbanisme du SI » est une alternative pragmatique aux approches plus radicales fondées sur une démarche de structuration systématique et volontaire. L’Architecture d’Entreprise a en effet abouti à de lourdes méthodologies et une spécialisation professionnelle dont la justification est de plus en plus difficile, dans notre contexte d’agilité tout azimut (voir).

De toutes manières, tous ces efforts sont vains s’ils n’ont prise sur les projets.

Malheureusement, cette action sur les projets, dans le contexte méthodologique et technologique traditionnel, ne pouvait intervenir qu’à l’amont des projets. Dès lors plusieurs difficultés limitaient cet impact :

  • financement difficile des études nécessaires pour créer un apport de valeur tangible de la fonction EA,
  • multiplication des prérequis (cartographies, détours méthodologiques, gouvernance), discréditant la fonction,
  • rigidité de la démarche, adaptation aux aléas difficile, risque systémique accru (effet domino),
  • impossibilité de démontrer pratiquement l’intérêt pour le SI, et surtout l’apport métier.

De ce fait l’impact était affaibli, et on constatait que les projets prenaient, au long de leur cycle de développement, leur autonomie, continuant ainsi les errements habituels, au grand regret des Architectes d’Entreprise.

Finalement, les moyens de coercition de l’EA étant essentiellement théoriques, tout le monde se satisfaisait de la situation, les Architectes d’Entreprise dans leur « Tour d’Ivoire » et les acteurs projets dans leur « cambouis ».

Des investissements transverses minimalistes

Pourtant des besoins de transversalité apparaissent et motivent des actions pour sortir du cadre habituel des « silos » qui caractérisent la plupart des SI historiques.

Mais ces investissements transverses sont minimalistes. Ce sont :

  • les projets de Master Data Management, qui sont parsemés de difficultés et ont bien de peine à trouver les compromis qui satisfassent les divers points de vue, et des intérêts souvent divergents.
  • les projets de rationalisation des flux et échanges inter-applicatifs, qui se limitent à la mise en place de formats « pivots » entre les silos, et perpétuent, de fait, les fonctionnements lents et massifiés traditionnels.

Ces travaux ont une connotation technique telle que les métiers se sentent peu concernés.

Une discipline qui se réfugie dans la méthodologie et le détour

Du fait des fortes contraintes des anciennes époques technologiques, même si le besoin d’une vision globale procurée par l’EA était reconnu, cette approche s’est figée dans une posture académique.

La discipline s’est réfugiée dans une spirale méthodologique, accumulant les versions, le discours, et ne trouvant d’issue que dans le détour, et la recherche d’une cible idéalisée.

Avec l’inertie du bagage académique, l’évolution de l’EA ne pouvait être que de plus en plus en retard sur les évolutions du contexte, sur tous les aspects technologiques (méthodes agiles, micro-services, Big Data…), de Business, et d’usage.

L’Architecture d’Entreprise pilote stratégique des mutations

Cependant, la bonne nouvelle est que l’Architecture d’Entreprise peut disposer de moyens d’action opérationnels et de court terme, créant ainsi une situation totalement inconnue, une rupture, aux multiples effets bénéfiques.

Ainsi, l’Architecture d’Entreprise qui pourrait rester « à la traîne », peut-elle anticiper, selon son rôle traditionnel de visionnaire, et passer à l’acte au travers des projets. Elle peut devenir le pilote stratégique des mutations.

La possibilité d’action opérationnelle à court terme est un changement majeur pour l’EA

Par rapport aux acteurs des projets, l’Architecture d’Entreprise peut proposer une offre concrète de « composants d’intégration », qui leur permet de se focaliser sur la réponse aux besoins spécifiques d’un domaine métier, en s’appuyant sur des services transverses.

Les règles d’urbanisation proposent, et imposent, d’utiliser le levier des données et événements de référence, pour rationaliser progressivement le patrimoine SI, et le doter d’une flexibilité indispensable à l’agilité.

Ce nouveau moyen d’action est une rupture, qui rend obsolètes les lourds investissements méthodologiques, puisque le détour qu’ils préconisent peut être évité. Le chemin de migration et de découverte d’une cible se parcourt en effet progressivement, avec une validation et des apports de valeurs incrémentaux.

Une rupture visible et collant à l’actualité

Dans le parcours historique de la discipline d’Architecture d’Entreprise, cette rupture est majeure : elle donne, enfin, une visibilité et une crédibilité pratique, qui ont jusqu’à présent cruellement fait défaut.

Ce fait arrive à point nommé, car la mutation de la Société exige de l’Entreprise de plus en plus de transversalités, en particulier :

  • pour répondre aux exigences d’immédiateté et d’ubiquité du Digital
  • pour satisfaire des cadres réglementaires qui ignorent les divisions historiques par fonctions et métiers

L’Architecte d’Entreprise peut dès lors s’imposer comme l’acteur de référence, pragmatique, directement opérationnel pour la transformation de l’Entreprise.

Un acteur qui donne du sens

Ce nouveau positionnement opérationnel pourrait être confié à d’autres acteurs de l’Entreprise. Cependant, de par ses autres missions, d’intelligence des transversalités, de compréhension des cibles, raison d’être finale de la profession, l’Architecte d’Entreprise donne du sens à cette impulsion de court terme.

Car l’Architecte d’Entreprise doit intégrer, dans sa vision et ses actions, les principales dimensions  de l’Entreprise et de son modèle d’affaires. Traditionnellement, cette vision ne pouvait trouver d’aboutissement qu’à terme, au travers d’évolutions d’un patrimoine SI rigidifié. Le Data Centric, et plus particulièrement l’Architecture Flexible, permettent le changement de paradigme, et d’introduire de la flexibilité dès le court terme.

Les missions traditionnelles et cette ouverture opérationnelle se confortent en un ensemble ou chaque composante est indispensable : il faut de l’action et aussi du sens.

Un acteur clé du programme de transformation du SI et de l’Entreprise

La transformation de l’Entreprise, dans toutes ses dimensions, est tributaire de celle du SI. En particulier pour les exigences du « Programme Digital », et des contraintes réglementaires que nous avons cité.

Ce nouveau paradigme a de multiples conséquences :

  • sur la conduite du changement,
  • sur la démarche de conduite d’un programme « digital »,
  • sur la mise en oeuvre des composants d’architecture technique,
  • sur la stratégie d’achat (progiciels, composants du marché),
  • sur les méthodologies de projet (prise en compte des synchronisations, développement des API, gouvernance,…),
  • sur l’organisation autour des données,
  • et, bien sûr, le métier même d’Architecte d’Entreprise.

L’Architecte d’Entreprise devient ainsi un acteur incontournable de la transformation du SI, et par ce truchement, de l’Entreprise. Il participe au pilotage stratégique des mutations, et y apporte les composants essentiels.

Le quatrième pilier de l’EA

L’Architecture d’Entreprise a pris sa place en s’appuyant sur 3 bases fondamentales à son apport de valeur :

  • une vision à terme, indispensable pour converger, simplifier, réformer,
  • une conscience de la déformation du socle technologique, des dettes et opportunités associées,
  • le dépassement des silos, par la prise en compte des transversalités de l’Entreprise

L’Architecture Data Centric, et en particulier le type de solution proposée par l’Architecture Flexible, apporte un quatrième pilier, qui sera indissociable des autres.

On pourrait voir cet impact comme local, en certains points du SI, ou sur certaines particularités technologiques. En réalité il concerne tout le SI, toutes les technologies, toutes les chaines de valeur, pour le bienfait de l’Entreprise, et le renouveau d’une profession en voie d’assoupissement.

 

GDPR : Groupe de Travail du Club Urba-EA

Un Groupe de Travail du Club Urba-EA est constitué au sujet de la nouvelle réglementation Européenne GDPR sur les données personnelles (RGDP en français). Le premier semestre 2017 a permis de faire le tour des différents articles du règlement Européen, et de leurs nombreux impacts pour les Entreprises et Organisations.

Ces impacts sont à prendre en compte par l’Architecture d’Entreprise, en particulier :

  • Dans la définition des cibles de SI qui doivent être conformes aux prescriptions de protection des données personnelles (Privacy by Design)
  • Dans l’accompagnement des projets qui doivent appliquer les dispositions générales imposées par la Réglementation (portabilité, droit à l’oubli, consentement, …).

L’Architecture d’Entreprise permet d’éviter la dispersion des efforts, et met en commun un minimum de contrôle pour prouver la conformité et garantir l’alignement aux axes majeurs du Règlement.

Le Groupe de travail aura au deuxième semestre pour objectifs :

  • De produire une adaptation à la GDPR du Guide d’usage de la Trame des Activité d’Architecture d’Entreprise définie par le Club Urba-EA (ce guide est téléchargeable sur le site du Club),
  • De prolonger la définition de la Cible GDPR-EA, par un guide de mise en œuvre de cette cible,
  • D’identifier les produits d’aide à la mise en œuvre de la GDPR (composants GDPR, normes d’API, KPI, …), à élaborer en 2018 dans le cadre du Laboratoire du Club.

Pour ces travaux, le Club sera assisté par son partenaire juridique pour la GDPR, le cabinet DPO Consulting. Des contacts seront aussi pris avec des industriels de l’IT susceptibles de contribuer à la définition des produits envisagés.

Le Groupe de Travail sera animé par René Mandel, Nicolas Chevalier et Bruno Rizzi.

Le Groupe de Travail est ouvert sans conditions aux membres du Club Urba-EA.

Réglementation sur les données personnelles : partenariat Club Urba-EA DPO Consulting

Le Club Urba-EA a signé un partenariat avec le cabinet d’avocat DPO Consulting, cabinet spécialisé sur la protection des données personnelles.

Le Club dispose ainsi, dans ses actions sur la GDPR, du soutien d’une entreprise leader sur ce marché, et qui pourra nous apporter sa connaissance juridique et ses retours d’expérience sur les projets GDPR.

Dans le cadre de ce partenariat, lors du Collogue organisé par DPO Consulting, René Mandel a présenté l’analyse du Club des impacts SI de la GDPR.

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.

Puits de données et puits de meta-données

L’analyse de la réglementation sur les données personnelles donne l’occasion d’une réflexion sur les puits de données.

Dans le monde opérationnel, qui est l’objet des interactions, des flux, des échanges de données, on repère facilement les « puits de données ». En effet, dès lors qu’il y a un cycle, on peut lui consacrer un puits, qui, à l’occasion des événements du cycle, trace les données caractérisant l’objet concerné par l’événement (changement d’état de l’objet) et celles qualifiant l’événement.

De façon plus globale, la méthode « Trame Business » propose un modèle de tous les cycles et parcours : le polygone de valeur (ci-dessous, le cas des « utilities »).

Polygone de valeur : Identification des puits

Pour une description plus complète de cette méthode voir le site « Value Architecture ».

Dans le cas de la GDPR, il nous faut :

  • enregistrer les consentements pour les données d’une personne, vis à vis de traitements. Cet enregistrement doit être historisé, car la personne peut, à tout moment, retirer son consentement. Il s’agit donc d’un puits dédié au cycle des consentements. Il concerne des meta-données : le dictionnaire des informations de telle personne,
  • enregistrer les validations de traitement accordées lors des demandes de traitement des données de telle personne. Il s’agit là de données « opérationnelles » utiles aux traitements.

On aura donc, dans le premier cas, un puits de meta-données, et dans le deuxième, un puits de données.

En somme, la figure de style « puits » peut être utilisée quel que soit le cycle, tout est une question de vision. Il n’y a pas de monde opérant, mais plusieurs visions des mondes, comme dans un infini kaléidoscope.

Les visions amenées par ces différents cycles et parcours apportent leur lumière sur autant de transformations, qui se combinent en fractales à l’infini. Comme les multiples vies dans un écosystème.

On sort ainsi du cadre stéréotypé de la systémique.

 

Projet de « plateforme de conformité à la GDPR » (Privacy by Design)

La nouvelle réglementation européenne (GDPR) sur les données personnelles impose le consentement explicite, clair et révocable, 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, pas de gestion fine des consentements,…) 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 qui est en première ligne).

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’une « plateforme 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 (et en particulier l’état des consentements, validés ou révoqués), 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 cette plateforme de conformité. 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 « puits » destiné à tracer les interactions et traitements concernant les personnes. Ce composant, non intrusif, permettrait d’auditer le fonctionnement d’une partie du patrimoine, au regard de la réglementation. L’avantage est aussi qu’il préfigure le fonctionnement nominal en cible, en créant le puits d’historisation pour la traçabilité (nécessaire à la portabilité des données, aux droits à l’information, à l’oubli, à l’opposition, …).

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. La rupture, par rapport à la réglementation en vigueur actuellement, est l’exigence de finesse dans le croisement personnes-données-traitements et finalités qui est le « grain » opérationnel d’exécution des consentements. La gestion des consentements prévue à l’Article 7 du règlement (« le responsable du traitement est en mesure de démontrer que la personne concernée a donné son consentement au traitement de données à caractère personnel la concernant »… »La personne concernée a le droit de retirer son consentement à tout moment ») ainsi que le droit d’opposition à la prospection (Article 21) impliquent un grain d’exécution fin et daté.

La structure ainsi créée, plus exigeante que celle découlant de la réglementation précédente, place l’autorisation de conformité (la licéité) au cœur du SI. C’est un sujet générique global (tout pays, transverse aux métiers), et stable car fondé sur l’architecture de la réglementation.

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 la plateforme, …). 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 (le Club pouvant travailler par exemple en co-développement avec certains partenaires). 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, ou en liaison avec des projets concernant les données personnelles.

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.

Une réunion d’information est organisée le 5 avril à Paris (une première réunion a intéressé 40 personnes de divers profils : CIL, Data Officer, Architecte…). Pour vous inscrire et recevoir une invitation.

Voir aussi sur le blog de René Mandel.

Gestion des données personnelles : impacts sur l’Architecture des SI

La Réglementation Européenne sur la gestion des données personnelles (GDPR) s’appliquera aux entreprises et organisations en mai 2018.

Cette réglementation implique une mise en conformité du patrimoine SI, pour répondre aux droits des personnes de contrôler leurs données personnelles et d’approuver les finalités des traitements.

Les conséquences de cette Réglementation sont donc multiples et étendues à l’ensemble du SI.

Afin de cibler l’initiative que peut prendre le Club Urba-EA face à ce sujet majeur, toute entreprise ou organisation peut répondre à l’enquête ouverte en suivant le lien ci-dessous :

Enquête GDPR du Club Urba-EA

Par avance merci pour vos réponses.