L’informatique a-t-elle progressé depuis l’An 2000 ?

Souvenez-vous du scandale qu’a été le « passage à l’An 2000 », et des coûts faramineux pour la société qu’a entraîné la nécessité d’ajouter deux chiffres à une date ! (certes, l’événement était inattendu !)

La communauté informatique a dû, au moins, en tirer la leçon. Quelques doutes nous assaillent, cependant, quand nous entendons que, pour assurer la conformité aux nouvelles réglementations, la première chose à faire est d’inventorier les traitements. Les entreprises s’y mettent dare-dare, mais sans viser l’exhaustivité, car celle-ci paraît hors d’atteinte. (impression de déjà-vu)

  1. Les budgets nécessaires pour assurer la conformité au RGPD (Règlement général pour la protection des données),
  2. les amendes à venir en cas d’échec (on ne manque pas d’oiseaux de mauvais augure)…

…voilà de bons indicateurs des progrès méthodologiques réalisés ces dernières décennies et du niveau de professionnalisme atteint dans la maîtrise des systèmes d’information. Il suffira de faire les comptes. Il suffira de comparer ces sommes aux économies que l’on a cru réaliser en se débarrassant des méthodes et en rognant sur la formation.

Il faudra un peu de rigueur pour assurer la conformité et un peu de créativité pour tirer parti de la pression réglementaire. Les méthodes traditionnelles ou récentes ne suffisent pas, puisque leur horizon est celui du projet et de l’application. Notre sujet réclame une approche globale, celle de l’architecture.

Il s’agit aussi de coordonner différents points de vue :

  • juridique (l’aiguillon de la loi),
  • stratégique (l’occasion à saisir pour créer de la valeur, plutôt que d’adopter une posture défensive),
  • communication et marketing (les enjeux d’image et de confiance),
  • organisation (l’impact sur les comportements des collaborateurs et sur les processus – pas seulement une case de plus dans l’organigramme),
  • informatique (la technologie à dompter).

Cette transformation convoque, donc, toutes les spécialités de l’architecture – métier, organisation, logique, technique, physique -, placées normalement sous l’égide de l’architecture d’entreprise qui doit en assurer la cohérence.  L’architecture générale de l’entreprise est, elle-même, dans les mains de la direction générale (si ce n’est pas le cas, autant dire qu’elle ne sert à rien).

La protection des données analysée à travers le Repère Praxeme

Le schéma ci-dessus illustre cette approche. L’analyse intentionnelle révèle des exigences et orientations auxquels doivent répondre des éléments dans les autres aspects de la réalité de l’entreprise. Les flèches pointillées représentent les relations de traçabilité (ou de référence). Par exemple, des paragraphes du RGPD imposent de repérer les informations sensibles. Leur description est formalisée principalement dans l’aspect sémantique de l’entreprise, c’est-à-dire son patrimoine de connaissances. D’autres paragraphes conduisent à mettre en place des rôles et activités particulières, mais aussi à injecter la surveillance dans l’ensemble des processus. Ce travail de conception organisationnelle ressortit à l’aspect pragmatique. Les exigences de la réglementation  se projettent ainsi dans tous les aspects de l’entreprise, justifiant les dispositions à mettre en place.

Le schéma ne peut montrer qu’une synthèse de cet effort. Le travail doit être mené de façon plus détaillée, à travers des modèles précis, faute de quoi il est impossible de dominer la complexité de l’exercice. Ici, le dispositif clef est le référentiel de description de l’entreprise. 

Cet outillage est bien connu et peut s’appuyer sur des standards internationaux. Quelques compléments sont nécessaires. Les méta-données comme la sensibilité des informations, la finalité de leur collecte et leur durée de conservation s’ajoutent au méta-modèle (= la définition des éléments nécessaires à la description). Ceci peut se mettre en place rapidement. Les fonctions d’historique des données (data lineage) et d’alerte (délai de conservation dépassé) peuvent être traitées une bonne fois pour toutes par la conception logique. Les solutions de sécurité (détection des brèches…) doivent, bien sûr, être systématisées. Le reste est affaire de discipline. En travaillant de la sorte, autour du référentiel de description, l’entreprise dispose d’une description précise de ce qu’elle est et de ce qu’elle veut devenir. En cas d’évolution importante, elle n’aura pas besoin de commencer par un inventaire fastidieux, et pourra aller droit au but.

Recommandations pour les programmes de mise en conformité

Il est, néanmoins, plus probable que les projets de mise en conformité passent par des raccourcis. On dénoncera l’approche présentée ici, comme théorique – c’est le mot généralement utilisé pour exclure tout effort que l’on n’est pas prêt à consentir, effort de compréhension ou de mise en pratique. On préférera court-circuiter les aspects « métier », « abstraits » : la traçabilité sera établie directement entre les composants logiciels (à grosse maille) et les exigences de la réglementation. On donnera les habituelles justifications économiques, totalement fallacieuses : faire vite, moins cher. Le genre d’argument qui ont conduit au scandale de l’An 2000 et à d’autres gabegies.

Nous saurons bientôt si la communauté a progressé… ou si nous vivons dans un jour sans fin.

 

Quelques éclaircissements sur le chantier Praxeme

Méthodologie d’entreprise

Dès l’origine, Praxeme s’est voulue comme une méthodologie d’entreprise, c’est-à-dire une réponse au besoin patent que rencontrent les entreprises et que perçoivent les dirigeants : articuler les expertises, les mettre en synergie. Conséquence : l’expression « Enterprise Architecture » (EA) a été prise au pied de la lettre, comme désignant une discipline qui pense l’entreprise comme un tout, dans toutes ses dimensions. Dès lors, Praxeme se sépare des méthodes proposées sous l’étiquette EA et qui sont toutes dans la sphère de l’informatique. Zachman, avec son questionnaire du Quintilien et son approche matricielle, aurait pu couvrir l’entreprise, mais sa façon de répondre (What = Data) lui a fait manquer la cible. On ne peut pas lui en vouloir : les déterminations historiques et culturelles ne pouvaient pas produire, à l’époque, un autre résultat.

Par rapport à l’architecture d’entreprise

Donc, Praxeme n’est pas une méthode d’architecture, fût-elle d’entreprise. Si nous disons « méthodologie d’entreprise » ou « méthodologie de transformation d’entreprise », c’est pour affirmer l’ambition de créer le creuset dans lequel toutes les approches de l’entreprise viendront converger et se fondre en un nouvel alliage. Le sujet est donc, en premier lieu, d’identifier les multiples rationalités qui traversent l’entreprise et de les amener à se reconnaître et à mieux cohabiter. Pour cela, il est besoin d’adopter une posture de méta-rationalité (non d’hyper-rationalité, car elle a bien conscience de la rationalité limitée, ce qui la teinte de modestie). Bien sûr, une méthodologie d’entreprise ménage sa place à l’architecture d’entreprise, discipline clef dans la transformation de l’entreprise (au même titre que la conception stratégique, l’organisation et bien d’autres disciplines).

Ces deux points, combinés, obligent à repenser les fondations et même à rechercher un autre sol pour fonder le nouvel édifice. Certes, la tradition informatique joue un rôle non négligeable dans cette perspective, non seulement du fait de nos trajectoires individuelles (ce serait un peu mesquin) mais surtout par la nature même de l’informatique, intermédiaire obligé entre le réel et l’idéel. (Je ne m’étends pas ; je me contenterai de renvoyer au maître ouvrage de Pierre Lévy, La machine univers.)

C’est ainsi qu’il est apparu nécessaire d’identifier les règles pour construire le cadre de référence, la grille de lecture à appliquer à l’entreprise. De là, la nouvelle version de la Topologie du Système Entreprise. Un chiffre pour juger de notre recherche : la version 1 de la TSE comptait 8 aspects dont 4 liés à l’informatique ; la version 2 n’en compte plus que 7, l’informatique étant une des composantes de deux des aspects. Le document PxPRD-01, inscrit au catalogue de la version 2, présentera ces règles et le résultat de leur application. Ce sujet a été présenté dans la formation exceptionnelle « Business Architecture & Transformation« .

Rapprochement entre référentiels de pratiques

Mieux intégrer l’EA avec des référentiels de pratiques comme ITIL ou COBIT va évidemment dans le bon sens, d’autant que ces référentiels ont tendance eux-mêmes à élargir leur domaine et à élever leurs aspirations. Mais pourquoi se limiter aux pratiques informatiques ? N’est-il pas aussi important, pour réussir son architecture d’entreprise, de la coupler à la conception des processus, donc à l’organisation, ou à la modélisation éthique et à la stratégie comme discipline ? Ces domaines s’appuient aussi sur des référentiels ou, du moins, sur une littérature abondante et une tradition riche. Il faudra bien réussir la connexion, sauf à rester confiner dans le champ de l’IT et à amputer notre capacité d’innover.

A propos d’agilité

En ce qui concerne l’agilité, nous sommes face à une contradiction. C’est surtout la contradiction d’essence entre le mode projet (portée locale et à court terme) et la portée système (vision long terme et globalisante de l’architecture). La nécessité de concilier stabilité et agilité de l’entreprise amène à penser le rapport entre :

  • agilité des activités de transformation, d’une part,
  • qualité de l’architecture, d’autre part.

La proposition de Praxeme pour résoudre l’équation consiste à réorganiser les activités de transformation, architecture et projet compris, autour du Référentiel de description de l’entreprise. Ce pot commun n’est, certes, pas facile à construire et il y faut une gouvernance subtile et décidée. Mais, quand il existe, c’est le moyen de gagner sur les deux tableaux : préserver la puissance et l’ambition de la vision architecturale, d’un côté, et accélérer les projets en les guidant vers l’intérêt commun, de l’autre. Ici nous touchons à la complexité de l’entreprise, complexité qui tient, en grande partie, à sa substance mélangée. C’est justement le rôle de la méthode d’analyser la nature de ce matériau, d’en séparer les éléments pour créer les conditions opératoires. La propagande sur les projets agiles, seule, ne peut pas suffire ; le platonisme de l’architecture idéale (top-down…), seul, ne mène nulle part. Il faut combiner les deux.

En résumé

« Refonder l’architecture d’entreprise » : c’est, je crois, ce que nous avons fait ou plutôt, c’est la conséquence presque involontaire de notre approche holistique de l’entreprise : voulant embrasser toute la réalité de l’entreprise et ordonner toutes les informations et les décisions qui la concernent, nous rencontrons, sur notre chemin, les disciplines et nous leurs assignons des responsabilités dans la perspective plus vaste de la transformation.
« Assembler les pratique » : Praxeme s’est toujours présentée comme une approche interdisciplinaire, un cadre pour coordonner les différentes pratiques et un vecteur pour amener les apports scientifiques et les mettre au service de l’entreprise.
Sur l’agilité : le grand sujet n’est pas l’agilité des projets. Au début de années 80, James Martin avait déjà dit l’essentiel avec sa méthode RAD trop rapidement interprétée comme l’autorisation de jeter les modèles par dessus bord. Il faudrait un jour qu’un économiste chiffre le désastre économique qui s’en est suivi. Le grand sujet est l’agilité de l’entreprise, laquelle réclame justement un gros effort d’architecture et une approche rigoureuse.