Le plan de transformation pluriannuel du SI est un outil pour aligner le SI sur les ambitions de l’entreprise. Il est constitué d’une une feuille de route pertinente et adaptable aux imprévus qui surviendront à court et à long terme. Son élaboration implique et mobilise tous les acteurs sur lesquels repose sa réussite, c’est un projet managérial pour rendre l’entreprise plus performante.

L’alignement stratégique a remplacé le schéma directeur

Nul doute que les démarches de schémas directeurs que nous connaissions auparavant ont changé. Elles étaient souvent ponctuelles et très longues, voire peu opérationnelles. Le rythme croissant du changement les a finalement disqualifiées.

Pour autant les entreprises restent confrontées peu ou prou aux mêmes grandes questions, suivant leur situation :

• Optimiser les coûts ou assurer la pérennité des moyens informatiques ;
• Faire évoluer l’organisation et la gouvernance de la fonction SI ;
• Aligner le SI sur les enjeux opérationnels des métiers tout en restant agile.

Pour y répondre, les managers et les dirigeants -pas seulement la DSI- sont amenés à imaginer le SI de leur entreprise telle qu’elle devrait être demain, soutenu par une trajectoire d’évolution réaliste. Sans cette trajectoire, adossée au présent et ancrée dans la réalité, l’accroissement de performance attendu n’aura pas lieu.

Une fois les réponses trouvées, la réussite de la mise en œuvre tournera en définitive autour d’une seule question « Comment les acteurs feront-ils faire grandir l’entreprise, en intégrant leurs priorités d’évolution définies et leurs propres capacity plannings ? ».

C’est à ces questions de management qu’aboutissent toujours les travaux et qui conduisent à rechercher la mobilisation des parties prenantes dès la phase de conception. En effet chacun s’investira d’autant mieux dans la transformation qu’il aura participé à l’élaboration de la solution et qu’il s’y identifiera.

Mais que doit-on faire pour mobiliser les équipes ? Nous rappelons trois grands principes que l’on ne devrait jamais oublier.

Prendre de la hauteur ensemble

Quotidiennement, les Directions Opérationnelles sont habituées à fonctionner au présent, « au quarter », à engager des projets à court terme. Lors de l’élaboration d’un plan de transformation elles sont appelées à se projeter et à penser le long terme : il ne s’agit pas seulement de traiter des demandes d’évolution en souffrance, mais d’énoncer des enjeux d’évolution, des objectifs à moyen terme,  de repenser des processus, voire d’oser un nouveau « business model ».

C’est pour cela que le sponsor de la transformation doit impulser et maintenir un niveau d’ambition suffisant aux travaux, ménager un délai pour la réflexion, inciter et aider les directions à ajuster leur niveau d’engagement et leurs contributions.

Compte-tenu de la rapidité du cycle de transformation actuel (cf. l’évolution des applications des outils digitaux ou encore des réglementations), la mécanique des travaux doit être rapide, de l’ordre de 3 à 6 mois. Les travaux débouchent sur l’élaboration d’une cible, d’une trajectoire réaliste et d’un portefeuille de projets et d’initiatives transverses qui feront l’objet de révisions régulières. Cette révision sera l’occasion de prendre en compte des inflexions ou des nouveautés dans la stratégie, ou d’approfondir des sujets laissés de côté lors des cycles précédents.

La planification de la transformation, ponctuelle et orientée IT, devient collective et régulière, voire permanente.

Travailler (enfin) en équipe

Tous les acteurs de la transformation doivent être associés : Opérations, SI, Marketing, RH, finance, etc. Un  climat de confiance doit être installé : la transversalité, réclamée à cor et à cri pour construire une entreprise plus performante, repose sur l’interdépendance entre acteurs qui ne peut s’envisager que dans un climat de concertation.

Chacun doit être amené à un état de « dialogue constructif », quelle que soit la situation de départ : pour les uns, abandonner l’obéissance passive, pour les autres, laisser tomber les résistances, pour d’autres encore, apprendre à écouter. Il faut battre en brèche l’idée que l’on va faire un état des lieux et pointer du doigt les fautifs et promouvoir la  coopération.

Il revient au sponsor du plan de transformation, de prévoir un dispositif d’étude favorisant un mode de management bienveillant où les liens de subordination, les conflits trop appuyés, laissent place à plus de solidarité, plus d’échanges mais aussi plus de créativité. Chacun apporte ainsi sa valeur ajoutée à l’édifice commun et en retire plus de motivation en retour.

Faire évoluer le rôle de la DSI et des équipes IT

Enfin, le plan de transformation SI a pour destinataires l’ensemble des directions métiers. L’intrication croissante des prérogatives métiers et de celles de l’IT, notamment avec les démarches de digitalisation, conduit toute l’entreprise à fonctionner en partenariat avec sa DSI.

Pour les entreprises, où la DSI est encore vue comme un fournisseur de moyens, c’est un premier gros changement de culture à engager. Cela ne va pas forcément de soi quand les métiers ont pris d’autres habitudes et que la DSI se comporte comme une Direction Technique. En tout cas, la DSI peut profiter de l’opportunité de la démarche pour poser sur elle-même un autre regard. Bref, faire son marketing.

Finalement, l’élaboration du plan de transformation SI ne serait-il pas la seule occasion d’expérimenter de nouveaux modes de fonctionnement sollicitant toute l’entreprise ? La démarche ne pourrait-elle pas porter un projet d’entreprise à l’heure ou la performance de l’IT est une condition de survie ?

Ce serait alors une opération qui tirerait vers le haut toute l’entreprise et permettrait de se tourner vers le futur avec plein de bonnes intentions managériales : communiquer, faire confiance, responsabiliser, orchestrer, soigner l’ambiance, … dont on sait depuis longtemps qu’elles sont la clé de la motivation, de la performance et d’une bonne adaptation au changement.

Les projets et la trajectoire de transformation en seraient les premiers bénéficiaires. On commence quand ?

Voilà un nouveau métier qui fait parler de lui. Le CDO serait-il le nouvel architecte « Digital » ? Par certains côtés, il s’en rapproche et peut même le concurrencer. Ce serait dommage : chacun doit mener à bien sa mission, dans un esprit collaboratif. Nous montrerons ici comment l’architecte peut aider le CDO dans ses fonctions pour mener à bien la transformation digitale.

En se retournant rapidement sur le passé, il est facile de constater combien nos métiers ont évolué. Hier urbaniste, aujourd’hui architecte SI ou architecte d’entreprise suivant les appellations. Chacun a maintenant son architecte : architecte métier, architecte de solution / technique, etc.

Quels seront les architectes de demain ? Le CDO (Chief Digital Officer) est-il l’avenir de l’architecte ? Ou un nouvel allié de la transformation digitale ? Mais d’ailleurs quel est son rôle ?

Le CDO travaille sur la chaîne de valeur dixit Les Echos. Il a donc un rôle d’architecte métier, un lien vers les processus et les pilotes de processus.

Il a la vision la plus large de l’entreprise ou comme le dit « l’usine digitale » « Leur job consiste au contraire à casser tous les silos de l’entreprise et de ses métiers ». L’architecte métier ou le pilote de processus avaient ce rôle-là. Faire coopérer l’ensemble des parties prenantes pour trouver des solutions nouvelles est aussi une partie du rôle de l’architecte d’entreprise.

« En général, ils commencent par faire un état des lieux pour identifier les projets déjà lancés par l’entreprise, ses besoins et les personnes impliquées. ». Qui a la connaissance de tous les projets ? leur périmètre ? les outils ? L’architecte d’entreprise a ce rôle dans les entreprises et doit donc être un point d’entrée pour notre CDO.

Côté constat, cet article nous dit : « un tiers des CDO interrogés regrettent « que leur niveau hiérarchique et leur pouvoir sont inadaptés aux enjeux de leur fonction. » » C’était bien le constat des architectes d’entreprise pendant des années et cela l’est encore fortement aujourd’hui. Le besoin de transversalité, de convaincre est encore bien présent dans les entreprises. L’architecte d’entreprise qui a été confronté à ces problématiques doit pouvoir aider ce nouvel arrivant.

Le CDO apporte de nouvelles dimensions dans l’entreprise en tant que champion de la transformation, il a plusieurs cordes à son arc, comme le précise l’Express :

« Il faut qu’il ait un très bon vécu marketing pour comprendre comment cette transformation doit servir l’activité. ». Le CDO doit comprendre le monde qui l’entoure pour en faire profiter son entreprise et la faire avancer dans sa transformation digitale. C’est un peu la « voix du client » comme on l’appelait avant. Le rôle de l’architecte d’entreprise est pour l’instant plus tourné vers l’intérieur de l’entreprise, en ce sens, où il n’est pas l’instigateur des nouveaux projets de transformation digitale.

« Il doit, aussi, bien maîtriser la gestion des talents : comment les recruter, les fidéliser ». Pour réussir sa transformation, le CDO doit savoir s’entourer, un bon architecte d’entreprise qui saura transmettre vers les DSI tout en intégrant les contraintes de l’existant et en respectant les coûts est un atout important pour un CDO.

Le CDO est le nouveau « champion de la transformation », il incarne la volonté d’un comité exécutif de transformer l’entreprise vers le Digital et le numérique. Il est un nouveau rôle à part entière qui s’appuie sur des rôles déjà existants dans l’entreprise (métier, marketing, DSI etc.). L’architecte d’entreprise se doit d’être au premier rang de la transformation digitale. Il doit être une courroie de transmission à l’intérieur de l’entreprise dont le CDO serait le moteur ! Il parle déjà avec les métiers et avec la DSI. Il est à même de proposer des solutions afin d’intégrer correctement tous les nouveaux usages et outils du Digital dans le SI de l’entreprise tout en augmentant la qualité du SI (rationalisation de l’existant, intégration de nouveaux outils en remplacement des anciens et non en doublon etc.). Architecte d’entreprise et CDO sont des rôles complémentaires dans l’entreprise.

Il semble donc naturel que le CDO et l’architecte d’entreprise s’allient pour faire basculer les entreprises vers un SI toujours plus puissant et au service des clients tout en restant le plus évolutif et le moins cher possible, d’ici la prochaine (r)évolution…

Le CDO est un profil récent dans les entreprises et il doit encore trouver sa place (lire aussi cet excellent article). Je pense que nous n’avons pas fini de parler de l’évolution et des interactions entre les profils (anciens, nouveaux et à venir, éphémères ou durable…) intervenant dans la Transformation Digitale.

Il doit faire une architecture de son temps avec les techniques de son temps

Pour expliquer aux non-initiés l’architecture du SI, on la compare toujours à l’architecture des villes, à l’urbanisation. Une interview récente de Catherine Jacquot (présidente du Conseil national de l’ordre des architectes) montre que les 2 pratiques ont toujours les mêmes points communs. Aussi bien pour montrer l’intérêt qu’elles apportent pour la société tant du point de vue qualitatif que monétaire, que dans l’évolution des pratiques et des outils.

Dans cette interview, les questions du journaliste sont aussi révélatrices que les réponses de l’intéressée. Ce sont les mêmes sujets qui reviennent et que l’on entend dans toutes nos missions : Quelle est votre valeur ajoutée ? N’êtes-vous pas trop cher ? etc.

Quelques phrases sont particulièrement marquantes.

Le phénomène […] empile des strates d’erreurs de différentes époques.

C’est la base même du constat que nous faisons sur les SI de nos entreprises. Toutes ces strates empilées depuis des années et qu’il est très difficile de remettre à plat. Les grands projets de transformation sont difficiles à justifier par les temps qui courent. Il faut être opportuniste et profiter des effets d’aubaine (le digital par exemple) pour proposer des évolutions qui vont dans le sens de la simplification et de la rationalisation et non pas faire que ce soit une couche de plus dans l’empilement.

Ces professionnels sont formés pour mener à bien un projet, y apporter des qualités de construction, d’usage et de confort tout en sachant l’insérer dans l’environnement.

C’est bien là le travail de l’architecte. Proposer des solutions en respectant les normes existantes. Savoir innover quand il le faut. Mettre en avant les usages. Les architectes du SI sont des professionnels et ils doivent faire en sorte d’attirer le respect de leurs clients grâce à la valeur ajoutée apportée par leur travail.

Pour un budget donné, un architecte fera toujours mieux qu’un non-architecte

Cela parait évident, et pourtant, il fait bon le dire ! Oui, l’architecte a un savoir-faire, et les solutions qu’il propose ont de la valeur. Cela ne coûte pas forcément plus cher, car l’architecte sait prendre en compte les contraintes qui s’imposent à lui, et proposer les meilleures solutions.

Son intervention apporte des qualités sans surcoût, « juste avec de la marge en moins pour les constructeurs »

L’architecte saura négocier les aménagements qui optimisent les coûts et les délais tout en respectant au mieux le cahier des charges. Il saura distinguer ce qui est indispensable de ce qui ne l’est pas. Il saura négocier et faire respecter les engagements de coûts et de délais de réalisation du projet. Totalement neutre, l’architecte est indépendant des solutions qu’il préconise : il peut ainsi mettre en concurrence les maîtrises d’œuvre, les challenger et en tirer le meilleur parti. C’est à ce titre que l’architecte saura montrer que sa prestation n’est pas une source de coût mais un gage de qualité.

Il faut faire une architecture de son temps avec les techniques de son temps.

L’architecte doit évoluer avec son temps. D’urbaniste, il est devenu architecte d’entreprise. Les entreprises vont continuer à évoluer, les SI seront de plus en plus inter connectés, de plus en plus complexes. Afin de continuer à apporter les meilleures solutions pour les SI des entreprises, les outils et techniques de l’architectes doivent évoluer. Les architectes sont à même de réfléchir à l’avenir de leur métier pour proposer les solutions les plus adaptées au monde digital, à l’internet des objets, à l’uberisation des entreprises…

L’architecture d’entreprise est un métier jeune et qui évolue rapidement. L’architecte d’entreprise reste le maillon indispensable dans la maîtrise de l’évolution et de la transformation au sein des entreprises. Les entreprises doivent continuer à s’appuyer sur les compétences des architectes d’entreprise et leur donner la place qui leur revient, car l’architecte d’entreprise assure une maîtrise de la transformation vers des SI toujours plus efficaces, évolutifs et économes…

Lire Ecrire Compter Coder est le titre d’un petit livre paru il y a un an aux éditions FYP. Il intéressera tous ceux qui s’intéressent à l’enseignement de l’informatique, mais il va plus loin, il pose aussi la question de la bonne utilisation de la société numérique.

On l’aura noté, le titre est à l’infinitif. La quatrième de couverture, quant à elle, se conjugue au définitif : on peut y lire que l’ouvrage « traite de la nécessité d’apprendre le code pour toutes les générations et explique comment y parvenir ». Faut-il faire comme l’Estonie, qui vient de rendre obligatoire l’enseignement de l’informatique dès l’âge de 7 ans ?

Mais à l’intérieur du livre, le propos est plus nuancé.

Les auteurs expliquent que l’apprentissage du code ne résout pas tout : le code est un moyen et pas une fin en soi. Après tout, beaucoup de personnes savent utiliser une machine à laver ou une voiture, sans pour autant savoir vraiment comment elle fonctionne, et encore moins comment la réparer !

Un des points intéressants de l’ouvrage est de montrer que l’enseignement du code relève de l’apprentissage par l’action. Autrement dit, de l’expérimentation. Tout comme naguère on apprenait la biologie des réflexes en excitant une patte de grenouille, l’apprentissage par la pratique est souvent nettement plus efficace que la théorie,  et en tous cas, la renforce.

Le code se découvre par l’expérimentation : ceci ravira les tenants de certaines pédagogies !  Il est bien connu que dans beaucoup de domaines, la technique a précédé la science : en d’autres termes on a découvert l’utilisation pratique du feu bien avant d’en comprendre la chimie… Le parallèle avec la chirurgie est particulièrement éclairant : le chirurgien apprend beaucoup en disséquant puis en opérant, la connaissance théorique du corps ne suffit pas.

Le code apprend l’algorithmique, il apprend à penser et à formaliser une méthode. Et tout cela  dans un but concret : il ne s’agit pas de coder pour coder, mais de coder pour résoudre un problème. Tester le code permet immédiatement de vérifier si la méthode fonctionne : lorsqu’on se trompe, on peut recommencer, et il y a souvent plusieurs solutions possibles. Tout comme en Open source, l’apprenant est valorisé par la possibilité d’améliorer le fonctionnement d’un code existant, ou de découvrir de nouvelles méthodes. De plus il est largement possible d’apprendre de manière autonome, le transfert de connaissance ne se fait plus seulement dans le sens professeur => élève. Au contraire, on peut apprendre en groupe de pairs : le parallèle est évident avec les méthodes agiles ! L’apprentissage ne se fait plus en « présentiel » (le professeur face à la classe). Autre avantage : il n’est plus nécessaire d’apprendre la même chose à tout le monde…

L’apprentissage du code peut également être un moyen ludique de faire réfléchir à des règles de société. Un des exemples cités concerne la découverte du code de la route grâce à la programmation des feux de croisement.

Savoir coder est également bien utile pour comprendre le monde qui nous entoure – par exemple, comment les entreprises font usage des technologies pour nous proposer des produits et des services ciblés. Mais aussi, comment les individus peuvent orienter les choix de société : à l’image de l’Open source, tous les citoyens peuvent collaborer et influer sur les lois qui nous gouvernent, ces lois n’étant pour les auteurs que le code qui régit le fonctionnement de la société. Il est donc important de ne pas laisser la production de ces codes dans les mains d’une petite fraction d’intérêts. En la matière, l’avènement de plates-formes comme Change.org, qui permet à des citoyens de pétitionner, montre que le chemin à accomplir est encore très long…

Le dernier tiers de l’ouvrage est consacré aux pistes possibles pour apprendre à coder aux enfants et aux adultes. Les auteurs y présentent de nombreuses expériences de manière factuelle, y compris celles qui ne vont pas dans le sens de leur discours. Une preuve d’objectivité qui les honore.

Lire Ecrire Compter Coder, de Frédéric Bardeau et Nicolas Danet, disponible sur toutes les bonnes plates-formes web.

Quelle est la fonction d’un stylo ? A cette question, 99% des personnes interrogées répondront spontanément : à écrire, bien sûr !

L’architecte fonctionnel fait partie des 1% restants. Pour lui, la fonction du stylo est de libérer un fluide permanent sur un support durable. On l’oublie souvent, ce n’est pas le stylo qui écrit, mais  la main qui le tient !

Confondre usage et fonction n’est pas très grave dans la vie quotidienne. Mais pour l’architecte, la différence est fondamentale. Impossible de concevoir un système sans comprendre comment il fonctionne !

Plus important encore, l’architecte fonctionnel est toujours à la recherche de mutualisations. Or, ce sont les fonctions que l’on mutualise. Notre bon vieux stylo n’a qu’une seule fonction, mais il est apte à de nombreux usages : écrire, mais aussi dessiner, approuver un document par une signature, ou encore différencier les vêtements de nos enfants par une marque qui nous permettra de les récupérer (les vêtements, pas les enfants) à la sortie de l’école…

Analyser la fonction pour bien construire

Comme son nom l’indique, la fonction décrit le « comment » (comment ça marche) alors que l’usage décrit le « quoi » : ce qu’on peut faire avec.

Prenons l’exemple des véhicules à moteur : en majorité, leur fonctionnement repose sur la combustion de carburant. Pour les construire, pour en optimiser le rendement, il faut comprendre les lois universelles de la thermodynamique. Ces lois s’imposent à tous, constructeurs et  conducteurs.

A l’inverse, l’usage des véhicules peut être « customisé », en grande partie adapté à chacun, ou presque : quel rapport entre une moto, un camion de 35 tonnes, ou un 4×4 ?

Certaines ruptures technologiques permettent de modifier les usages, d’autres non. L’arrivée des véhicules électriques, par exemple, n’a guère modifié les usages : avec une voiture électrique, on ne peut pas faire plus de choses qu’avec un véhicule à moteur, et même plutôt moins dans l’état actuel des techniques. En revanche, optimiser leur fonctionnement demande à comprendre d’autres lois : celles de l’électromagnétisme, et du stockage de l’électricité.

Identifier les fonctions à mutualiser

Différencier la fonction de l’usage est également indispensable pour identifier les possibilités de mutualisation. Au 19^ème siècle, l’essor de l’industrialisation ne fut possible que par la mutualisation : la gravure ci-dessous montre des dizaines de machines à filer alimentées par une seule machine à vapeur, au moyen de multiples poulies.

En langage d’aujourd’hui, un architecte fonctionnel pourrait décrire cette solution en ces termes : les ingénieurs de l’époque avaient mutualisé la fonction la plus coûteuse, transformer l’énergie thermique en énergie cinétique. Ils l’ont implémentée dans un seul composant : la machine à vapeur. Ensuite grâce à un système d’échange – arbres de transmissions, courroies, et poulies -, ils ont mis à disposition cette énergie sous forme de service, prête à utiliser par des dizaines de machines.

On peut noter au passage que ces consommateurs de services pouvaient en faire des usages différents : carder, filer, tisser…

Application aux systèmes informatiques

Tout comme dans une manufacture, la fonction est mutualisable aussi dans un système informatique. Par exemple, la composition de document est utilisable pour de nombreux usages : éditer des propositions, des contrats, des relevés de compte, ou encore des messages publicitaires. C’est ce qui explique le succès des outils d’éditique.

De même, on peut utiliser les mêmes formules pour calculer les frais à facturer à ses clients, et les commissions à verser à ses partenaires. Pour autant, rares les entreprises qui ont dévolu ces deux usages à un composant logiciel unique ! Et pourtant, ces calculs sont souvent complexes, et avoir à maintenir un seul moteur de calcul coûterait bien moins cher.

L’analyse fonctionnelle, c’est l’analyse de la valeur

Identifier la fonction pour la mutualiser est une des clés de la création de valeur, que ce soit dans la téléphonie mobile, dans la multiplication des outils de médiation (middlewares, ESB, EAIs…) qui mutualisent les fonctions d’échange ; et bien entendu dans le Big Data, promesse d’une exploitation fine des données qui commence à frôler les capacités de l’intelligence humaine.

L’évolution des technologies fait que de nouveaux champs du possible s’ouvrent à la mutualisation ; de plus en plus de fonctions sont mutualisables.

Quant au stylo, le clavier et le document numérique l’auront bientôt relégué au rayon des antiquités. Je vais quand même en conserver quelques-uns, par nostalgie, et pour me gratter l’oreille au cas où …

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, les technologies, la culture de projet et les compétences en ingénierie informatique se sont développées. Il existe aujourd’hui un grand nombre de  « briques technologiques » utilisables pour assembler un SI 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 « manques » : manque de vision, de temps, de moyens, de savoir-faire, de discipline, de dialogue, d’analyse des besoins, etc. Plus que jamais, l’adage de mes débuts continue de se vérifier. D’ailleurs l’existence de « briques technologiques » de plus en 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 beaux !

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 termes « d’architecture de solution informatique », qui est une réflexion trop restrictive car elle réduit le questionnement à la problématique informatique.

Pour compenser cela, les DSI font parfois intervenir sur les projets des maîtres d’ouvrage connaissant les applications, afin de conjuguer réflexion sur le métier et réflexion sur la solution. Cependant cela détourne souvent le maître d’ouvrage de son rôle : étudier l’opportunité et cadrer les besoins. Il arrive encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif 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 évolution de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale et par la mobilisation des équipes. A défaut on verse immédiatement du côté obscur 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 le parti qu’on pourrait tirer de cette réflexion pour l’analyse.

Ce n’est pas le marteau qui fait bouger la main, mais l’inverse

Quand cet outil d’analyse est utilisé correctement, de  manière pragmatique, 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 à 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 des projets, et leur intérêt par rapport à la stratégie métier, pour donner des perspectives aux projets
• 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 sous forme de schémas non équivoques, ainsi que des trajectoires appropriées pour l’atteindre
• Créer la mobilisation autour du projet en propageant les nouvelles représentations mentales qu’implique la cible
• (liste non exhaustive)

En résumé, l’Architecture 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.