L’architecture d’entreprise est souvent vue de manière négative par les projets : effort coûteux, dé-corrélé de leurs contraintes, etc. Pourtant « sur le papier » cette pratique est très ambitieuse et prometteuse. Examinons les conditions d’un recours efficace à l’Architecture d’Entreprise.
Management de projets : tout change, rien ne change
Dans mon parcours professionnel, j’ai croisé et continue de croiser des « maîtres » qui influencent mes approches et mes convictions. L’un d’entre eux disait « le coût de la correction d’une erreur de conception est multiplié par 10 à chaque fois que l’on franchit une étape dans un projet : 1 au moment du cadrage, 10 en conception, 100 en réalisation / test, 1000 après le déploiement (lorsque c’est une fonctionnalité inadaptée qui a été déployée auprès de centaines d’utilisateurs) ». C’était à la fin des années 1990, et on était encore à l’époque sous le règne (finissant) de la méthode Merise.
Depuis, la culture et les compétences en ingénierie informatique se sont développées. Les « primitives » aussi ont accru leur maturité. « Primitives » c’est le terme qu’employait ce maître pour parler des progiciels, des technologies d’intermédiation, bref de ce qui permet de construire un SI un peu comme un lego, sans avoir à développer spécifiquement chacune des pièces.
Cependant, rares sont les projets qui échappent aujourd’hui encore aux difficultés d’hier. On constate toujours une série de « manque » : de temps, de moyens, de savoir-faire, de discipline, de dialogue, etc. Plus que jamais, l’adage de mes débuts est vrai. D’ailleurs l’existence de « primitives » plus élaborées, ne résout pas le problème d’architecture globale. En effet, on peut construire un truc très moche avec des lego très beau !
Architecture d’Entreprise : l’art de traiter la complexité
Parmi les pratiques qui permettent de concevoir un SI, l’architecture d’entreprise est aujourd’hui celle qui apporte le maximum de garantie. Elle préconise l’extension des pratiques d’architecture du SI à l’ensemble des dimensions de l’entreprise. L’objectif poursuivi est d’éviter de ne penser l’architecture qu’en terme « d’architecture de solution informatique ». La réflexion sur ce type d’architecture est trop restrictive. Elle réduit le questionnement à la problématique informatique. Elle intervient aussi trop tard et n’est plus légitime à soulever des questions relatives au métier.
Un moyen de résoudre ce problème consiste à recruter des maîtrises d’ouvrage connaissant les applications. On espère ainsi conjuguer réflexion métier et réflexion solution. Mais alors on finit par oublier de faire un vrai travail de maîtrise d’ouvrage : étudier l’opportunité, et cadrer les besoins. Ils arrivent encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif est une liste de besoins.
L’architecture d’entreprise propose un cadre permettant d’assurer une continuité d’analyse entre les différentes phases du projet. Elle couvre aussi l’analyse d’opportunité en amont des projets. Mais alors pourquoi les problèmes ne sont-ils pas déjà résolus ? Sans doute la démarche est-elle perçue comme complexe à déployer et à s’approprier (c’est l’argument le plus souvent entendu). En effet, le déploiement d’une démarche Architecture d’Enterprise, appelle une transformation de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale. A défaut on verse immédiatement du côté obscure et l’on ne retient de l’approche que ce qu’elle a de plus hermétique : la méthode … inconcevable quand on manque de temps, manque de moyens, manque de savoir-faire, manque de discipline, manque de dialogue, etc. On finit par oublier la puissance d’analyse dont on pourrait tirer parti.
Ce n’est pas le marteau qui fait bouger la main, mais l’inverse
Quand cet outil d’analyse est remis à la place qu’il ne doit pas quitter, celle d’un simple outil, et qu’il est utilisé de la bonne manière, au bon endroit, par la bonne personne, on en voit immédiatement la valeur-ajoutée pour les projets. Et ce, sans attendre le déploiement des applications et le verdict des utilisateurs.Lorsque l’Architecture d’Entreprise est présente dès le point d’ignition du projet (ou avec bonheur, plus en amont encore : lors d’un schéma directeur) elle est a même de porter et fédérer toutes les dimensions de l’analyse et répondre aux attentes des acteurs de la transformation :
- Comprendre les enjeux de(s) projet(s), et leur intérêt par rapport à la stratégie métier, pour donner des perspectives au(x) projet(s
- Identifier conjointement les impacts pour le métier et la DSI, en animant le dialogue bipartite métier/IT qui soutient la transformation
- Pouvoir identifier les ressources et les capacités d’évolution qu’il faudra mobiliser, et vérifier qu’elles sont bien disponibles (à quoi servirait une cible, sans la capacité d’évolution pour l’atteindre ?)
- Donner aux équipes concernées les repères communs et partagés qui sont nécessaires pour fédérer les visions personnelles (forcément partielles et partiales)
- Livrer les premiers plans ré-exploitables de la cible à atteindre sous forme de schémas non équivoques
- Créer la mobilisation autour du projet en propageant les nouvelles représentations mentales qu’implique la cible
- Etc. (liste non exhaustive)
En résumé, l’architecte d’entreprise fait exister le projet avant qu’il n’existe. Puis elle l’accompagne dans son cycle de vie vers sa réalisation (son accomplissement !). Disposer d’un plan de route pour conduire une transformation est tellement utile lorsque les projets sont stratégiques, transverses et complexes. Faisons-le savoir, comme monsieur Jourdain pour la prose, l’architecte d’entreprise fait du management, sans qu’on le sache ! Mais lui, il le sait.
