GDPR : l’Architecture d’Entreprise doit créer les fondements durables

La réglementation sur la protection des données personnelles concerne de nombreuses entreprises au titre des clients, des prospects, des salariés, des partenaires…

Qui est responsable en cas de non-conformité : en premier lieu les dirigeants, et les Directeurs aux quels ils ont délégué la responsabilité. Mais les sanctions ne sont pas les seuls risques pour l’Entreprise ou l’Administration publique : en cas de scandale, l’image est atteinte, comme toutes les affaires liées à la sécurité, à la traçabilité, qui se sont produites, et se produiront dans notre société obsédée par les rendements d’échelle et la transformation numérique.

Le sujet GDPR est un sujet global.

Sur le plan du SI, il en va de même. Certes, à la DRH de prendre les bonnes mesures pour protéger les salariés, à la Direction Financière d’en faire de même pour les prestataires, à la Direction commerciale de veiller à la déontologie vis à vis des prospects et des clients, etc … Mais, somme toutes, les personnes physiques, quelles qu’elles soient vis à vis de l’entreprise, ont les mêmes droits. Certes les traitements sont atomisés, les données peuvent être éparses, mais, au final, le DPO doit avoir la même vision sur tous ces archipels, et veiller à la licéité de tous les traitements de données personnelles, où qu’ils soient gérés au sein de l’organisation métier et DSI.

La réglementation pousse l’Entreprise à voir son SI autrement, par rapport aux données personnelles : un SI centré sur ces données. Certes, il ne s’agit pas de déconstruire le SI pour l’organiser sur cet axe… Il s’agit simplement de se doter d’une Architecture adaptée.

Dans les grands groupes, il existe souvent une équipe centrale en charge de l’Architecture, de ce que l’on appelait l’urbanisme du SI, et qu’on baptise maintenant Architecture d’Entreprise.

A cette équipe centrale de régler une bonne fois ce problème central, en créant les fondamentaux d’une Architecture conforme à la GDPR. Confier cette responsabilité à chaque Direction des systèmes d’information de chaque métier serait une démission éclatante, prouvant l’inefficacité de cette structure centrale. La GDPR, problématique transversale, la concerne au premier chef, il en va de sa responsabilité, les Directions métiers n’étant responsables que de l’adaptation aux particularités métier.

L’évidence de cette responsabilité, qui ne semble pourtant pas caractériser les très grandes structures, apparaît avec le projet d’accélérateur GDPR du Laboratoire du Club Urba-EA : on voit clairement, à terme, l’émergence d’APIs à imposer aux nouveaux projets et aux évolutions du patrimoine SI. C’est justement le rôle de l’équipe centrale de l’Entreprise ou du Groupe ! A elle de lever la tête du guidon, de dépasser le recensement des applications et des impacts épisodiques de la réglementation : si l’infrastructure transverse n’est pas créée, les errements actuels perdureront. L’investissement, en terme de normes et d’APIs est faible, infinitésimal par rapport aux enjeux d’image et de pénalité, et aux budgets de programmes et projets de court terme de mise en conformité.

 

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

Le Laboratoire du Club Urba-EA a pour objectif de mettre au point des architectures de système d’information innovantes, et traitant des sujets d’actualité partagés par les membres du Club.

Il s’agit, au delà des approches académiques ou des pré-requis méthodologiques, de démontrer en pratique l’apport de l’architecture, face aux multiples défis auxquels sont confrontés les entreprises privées et Organismes publics.

La réglementation Européenne sur la protection des données personnelles, GDPR alias RGDP, présente ce type de défi, aux nombreuses implications, immédiates et dans la durée. Elle a clairement un impact architectural majeur, qui ne peut se résumer à telle ou telle solution d’éditeur ou d’architecture.

Chaque entreprise se doit de mener un programme de travaux pour se rendre conforme, en fonction des spécificités de son activité, de ses procédures, de son patrimoine applicatif.

Le projet d’accélérateur GDPR vise à faciliter ce programme : en accélérer l’application, aider à identifier les architectures, et amorcer des solutions pratiques.

Cet accélérateur est fondé sur :

  • un partenariat avec des éditeurs qui apportent les briques de base d’une telle architecture :
    • la vision DPO et responsable de traitement (registre des traitements, …), au travers du produit MyDPO de DPO Consulting, cabinet juridique spécialisé sur la protection des données personnelles,
    • la gestion transversale des données personnelles et des demandes des personnes à ce sujet (consentement, oubli, portabilité, …), au travers du produit de MDM EBX, de Orchestra Networks, spécialisé sur la modélisation et la mise en oeuvre de référentiels de données partagés,
    • la gestion de solutions d’intégration et d’interconnexion, au travers des produits d’Axway dont c’est la spécialité,
  • la garantie de conformité à la réglementation (Privacy by Design) au travers d’une cible d’Architecture : mise en oeuvre des principes de l’Architecture Flexible, avec un « puits d’événements » assurant la traçabilité des actions prises sur les données personnelles (voir la cible d’architecture GDPR-EA publiée sur le présent site, schéma repris ci-dessous),
  • l’utilisation de la technologie émergente de « l’event sourcing » pour satisfaire les besoins de performance et de scalabilité nécessaires,
  • enfin, et ce point est fondamental, l’introduction progressive des composants d’Architecture selon le modèle en spirale, et la figure de style de MDM non-intrusif.

 

Cible d’architecture de conformité GDPR-EA (2017)

 

Les objectifs et livrables du projet sont, pour fin 1er trimestre 2018 :

  • L’identification des grands impacts SI de la réglementation GDPR,
  • La conception d’une architecture générale cible qui répond à un ou plusieurs cas d’usage métiers identifiés,
  • La mobilisation optimale des composants progiciel et des puits d’événement, dans un schéma reconfigurable et adaptable au cas de chaque entreprise
  • La mise en œuvre et l’accessibilité du prototype opérationnel aux souscripteurs,
  • La mise à disposition des livrables projets (documents, sources IT) aux souscripteurs.
Cible GDPR non intrusif (2018)

Cet accélérateur est piloté par le Groupe d’Entreprise du Club qui ont souscrit au projet. Le Groupe définit les cas d’usages et priorités.

En mutualisant ces travaux, en bénéficiant de l’appui des éditeurs qui mettent à disposition du projet leurs produits, en investissant sur les nouvelles architectures événementielles (puits d’événements, event sourcing), le projet apporte aux adhérents des résultats facilement transposables dans leur contexte. Cet accélérateur permet, mieux que des spécifications, des investissements rapides sur des bases qualifiées.

 

Pour participer au projet, demander le formulaire de souscription au secrétariat du Club, ou télécharger le formulaire , et renvoyez-le (mail : chargedecommunication@urba-ea.org ).

Ont adhéré au projet les Groupes suivants :

  • Aéroports de Paris
  • Acoss (Agence Centrale des Organismes de Sécurité Sociale)
  • RATP
  • Banque de France
  • Le Groupe VYV (issu de la fusion des mutuelles d’Harmonie Mutuelle et Mgen)
  • le Groupe Agrica

Les adhérents au projet se sont réunis pour engager les travaux , le 18 janvier à Paris.

Une initiative originale, qui place l’Architecture d’Entreprise au premier plan, et comme atout stratégique pour transformer les fondements du SI, en synergie avec le séisme réglementaire de la GDPR.

 

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.