François Tabourot

Quelques heures de disponibilité me donnent l’occasion de partager avec vous une synthèse de ce que je considère comme la nouvelle gouvernance des Directions informatiques.

Je vous propose donc ces quelques lignes qui matérialisent selon moi, l’aboutissement d’une mutation initialisée il y a plus de dix ans. D’abord, assumons ensemble le fait que le business contraint l’IT et non l’inverse. Ainsi les cycles de vie des applications ont hérité de ceux des produits mis en œuvre par les processus métiers.

L’accélération du marché de l’économie réelle a confronté la Direction Informatique à un enjeu majeur de rapidité.  C’est autour de cette contrainte que la gouvernance a évolué. Mais faire plus vite il y dix ans avait un coût : celui de l’incohérence et de la maintenance. Finalement l’enjeu s’est précisé autour de l’idée de faire ‘rationnellement plus vite’.  C’est-à-dire faire en sorte que chaque projet s’inscrive dans un tout cohérent dont il hérite, qu’il contribue à enrichir, mais sans en perturber la stabilité. Une nouvelle gouvernance s’est progressivement mise en œuvre autour de deux axes : la mutation des infrastructures techniques, et l’évolution des méthodes de conception de systèmes.

Sur le premier sujet, la Direction informatique doit conduire un chantier de remplacement des infrastructures techniques intégrant des moteurs technologiques divers tels que l’interopérabilité, la communication, l’orchestration, le stockage, la sécurité… condition indispensable pour supporter le développement ‘rationnellement rapide’ de la couche applicative. C’est une première mutation délicate, telle que l’ont exposée plusieurs grandes organisations dans le cadre de la dernière réunion du CEISAR, en particulier du fait qu’elle n’a que la Direction Informatique comme client. Il faudra donc savoir ‘vendre’ ce sujet très technologique et dépourvu de ROI direct, à la Direction Générale pour qu’elle en devienne le sponsor.

Sur le deuxième axe de l’évolution des méthodes de conception, faire ‘rationnellement plus vite’ c’est pouvoir réutiliser  et paralléliser les tâches. C’est ce qu’a apporté la mise en œuvre des pratiques de l’architecture dans la gouvernance IT. Tout comme elles avaient révolutionné le génie civil quelques siècles auparavant, et l’industrie mécanique plus récemment, les pratiques d’architecture  bouleversent aujourd’hui les méthodes de conception de systèmes. Fondées sur les bases de l’approche systémique, elles permettent d’anticiper les problèmes de cohérence. Différentes vues dont les interfaces et les héritages sont connus, définissent un système à priori. On met ainsi à disposition des projets différents espaces de subsidiarité autorisant le travail collaboratif.

C’est de ces nouvelles pratiques de l’architecture que Mega fait la promotion bien au-delà de cet Aparté, dans le cadre de l’association CESAMES qu’elle sponsorise. C’est également le thème que nous avons choisi de développer dans le cadre de notre intervention à la conférence de l’Open Group le 23 septembre à Paris.

D’ici là passez d’excellentes vacances.

Quelques semaines depuis début septembre, durant lesquelles j’ai rencontré de nombreux directeurs des systèmes d’information. J’essaie de faire une synthèse et je suis partagé entre l’idée que leur métier n’a plus rien à voir avec ce qu’il était il y a seulement 10 ans et l’implacable constat que certains fondamentaux sont irrémédiablement les mêmes.

Dans le camp des changements, il y a bien sûr le contexte général de la mondialisation, l’accélération du temps, la révolution technologique et toutes les complexités associées. Au premier rang des fondamentaux, s’affiche la question centrale : comment fournir à l’entreprise des applications qui correspondent à ses besoins ? Question de la première heure, qui revient par la fenêtre à chaque fois qu’on la sort par la porte !

Je regarde, j’analyse et je suis bien obligé de me dire que sur le thème de l’expression de besoins on est toujours dans la même difficulté de dialogue entre l’utilisateur et son assistance à maîtrise d’ouvrage ; le développeur et son assistance à maîtrise d’œuvre et depuis quelques années l’architecte ou l’urbaniste garant de la meilleure réutilisation du legacy.
On invente de nouvelles méthodes ou de nouvelles responsabilités, mais au fond, on ne fait que faire du pousse-pousse en essayant de déporter ou de diluer la responsabilité du sujet récurent : quelqu’un doit dire ce qu’il faut faire, un autre comment le faire  et un troisième s’engager à le faire.

Dans l’intimité de cet aparté, je voudrai partager avec vous la conviction que si l’évolution des méthodes, en particulier de modélisation, accompagne celle de la complexité des projets informatiques, elles ne pourront jamais compenser le talent des professionnels garant de leur réussite. Il y a là un véritable enjeu de reprofessionnalisation de ces métiers, et j’espère que le marché de l’emploi laisse quelques visionnaires dans ce vaste domaine de la maîtrise d’ouvrage, que l’histoire proche reconnaitra sans doute comme une pratique de développement durable de nos grandes organisations. Pour que cette prédiction se réalise, c’est un message qui devra sortir de cet aparté…

Au début de l’été 2008, Isabelle Chevret* avait organisé une intervention de Mega dans une table ronde sur le thème de la gouvernance informatique. De la synthèse des échanges sur l’estrade comme dans la salle, je suis revenu avec le sentiment récurrent qu’il est toujours aussi difficile d’être Directeur des Systèmes d’Information (DSI).

Si proposer et faire valider sa politique de gouvernance reste le premier travail d’un DSI dans sa relation avec le comité de Direction, il n’en demeure pas moins important pour lui de définir les justes moyens, en particulier méthodologiques, dont il doit se doter pour sa mise en œuvre. Ma conviction est que pour faire face à la double pression des délais et des budgets qui pèsent sur ce processus de gouvernance, objectiver l’engagement de la DSI avec ses partenaires reste le meilleur moyen de gérer la pression qui accompagne les projets de refonte du SI.

Parmi les différentes sources de pression figure au premier plan la capacité à contractualiser l’expression de besoin au démarrage des grands projets. C’est précisément sur ce thème que les équipes de Mega, consultants et techniciens, ont réfléchi à ce que pourrait apporter les techniques de modélisation dans ce domaine. Ils ont d’abord confirmé, qu’en termes d’équilibre des problèmes à traiter vis-à-vis de l’objectif à atteindre, la formalisation du besoin initial s’avère beaucoup plus sensible que tout autre problème de productivité du développement informatique. Ils ont ensuite attiré mon attention sur l’importance du juste emploi des pratiques de modélisation, et en particulier graphiques, dans ce domaine particulier traditionnellement réservé à la ‘permissivité’ des outils bureautiques. C’est dans ce contexte qu’est née la solution MEGA System BluePrint.

Précisément positionnée entre la nécessité d’en dire suffisamment et la peur d’en raconter trop au titre d’un cahier des charges. C’est un parti pris qui traduit notre conviction, que dans les grands projets, bien exprimer ce qu’il y a à faire est un facteur de productivité supérieur à l’idée de le découvrir et l’affiner dans des itérations de cycle de développement rapide.
Comme toujours, c’est bien évidement le marché qui aura raison, mais j’avoue que je suis impatient d’en débattre avec lui, et si possible cette fois, pas en aparté…

*Isabelle Chevret est Directeur Marketing et Communication

Quel mois de mars !

En cette période de concentration maximum imposée par les conditions économiques mondiales, il y a encore de l’espace pour de belles rencontres et d’enrichissants échanges autour des thèmes qui constituent le cœur de l’offre de Mega.

J’ai en effet eu le plaisir de passer en mars de longues heures à échanger avec des professionnels expérimentés, pour parler des enjeux des projets d’architecture d’entreprise. Que la discussion s’engage avec un analyste, un consultant, ou un client, il y a finalement un point commun que nous partageons tous : il y a incontestablement un intérêt implicite à la mise en place d’un référentiel, qui décrit et architecture les ressources de l’entreprise vis-à-vis de critères de rangement, et en particulier de repères métiers.

Là où le débat se complexifie graduellement, c’est lorsque l’on cherche à passer de l’implicite à l’explicite d’une part, à se mettre d’accord sur la nature des ressources qui relèvent de cette pratique, mais aussi et surtout lorsque se pose la question du ‘comment fait-on’.

Sur ce dernier point, j’arrive presque à la conclusion que le foisonnement des acteurs et des idées sur ce sujet finit par nuire au sujet lui-même, à son intention stratégique et au consensus initial. D’ailleurs quand on y regarde de plus près, s’il fallait résoudre la combinatoire des méthodes, des frameworks, des acteurs, des outils, des courants de pensée possibles dans la recherche d’un optimum pour justifier son initiative d’architecture d’entreprise, on ne démarrerait probablement jamais le projet !

Néanmoins deux idées fortes se dégagent à mon avis, et ce sont celles que j’ai développées lors d’interventions publiques récentes. D’abord, la pratique de l’EA s’inscrit dans la logique des démarches Qualité. L’inventaire permet de mettre de l’ordre et en particulier de supprimer les doublons en optimisant précisément l’architecture des ressources. L’élaboration d’un cadre de référence permet enfin, à l’issue de son effort de constitution initial, de régler a priori une partie des problèmes d’intégration des initiatives projets, en les dotant au départ de contraintes d’environnement.

A quoi et à qui cela est-il utile ? Dans le monde industriel par exemple, l’architecture garantit que le capot d’une voiture se fermera bien correctement, même avec le moteur posé dessous. Dans nos métiers, l’architecture sert en priorité la productivité des équipes informatiques qui vont être plus réalistes dans l’évaluation de l’effort de développement ou de migration à fournir du fait de leur meilleure maîtrise du contexte dans lequel ils s’inscrivent. C’est cette logique de retour sur investissement qui est la plus utilisée pour justifier le budget d’une telle initiative.

Pourtant il existe un autre levier qui, entre les mains du DSI, fait du référentiel d’architecture d’entreprise un outil de pilotage et de mesure de la capacité objective de transformation des opérations. En effet, si l’on considère le niveau de dématérialisation des entreprises, on peut admettre aisément que leur système d’information en est également le principal système opérant. De ce fait, toute qualification d’une hypothèse de transformation s’instruit à partir de la mesure de l’agilité réelle de son SI. De ce point de vue, l’EA émerge comme un outil au service d’une pratique de management des projets de transformation. Elle s’appuie toutefois sur une vision qui considère que l’optimisation des opérations est un facteur de création de richesse pour l’entreprise elle-même et pour ses actionnaires.

C’est un autre sujet qui me tient à cœur et dont je ne manquerai pas de vous parler prochainement, en aparté.

La dernière réunion internationale de la force de vente de Mega a donné lieu à un passionnant débat interne sur le thème de l’architecture d’entreprise. J’ai découvert à l’occasion de celui-ci que selon les pays, les cultures, peut-être aussi selon les niveaux de maturité, cette appellation recouvre parfois une notion de moyens, parfois une idée de projet ou de livrable qui serait porteur de sa propre finalité : faire un projet d’architecture d’entreprise.

J’ai personnellement défendu le point de vue qu’il existe une pratique de l’architecture d’entreprise, vu comme un ensemble de techniques de modélisation de l’entreprise et de ses ressources (en particulier informatiques), et qu’il convient d’en définir le bon usage, au regard de deux des préoccupations majeures des DSI : planifier l’évolution du SI, faire des cahiers des charges pour maitriser les développements relatifs. C’est d’ailleurs selon cette vision, que l’offre Mega 2009 qui arrive très prochainement sur le marché, a elle-même été structurée.

J’ai trouvé ce débat très intéressant, et j’ai donc décidé de le poursuivre avec vous à l’occasion de l’évènement qu’organise à Paris marcusevans le 19 et 20 mars 2009 autour de ce thème.

Si l’on ne se croise pas le 19 mars dans le contexte de mon intervention, nous continuerons quoi qu’il en soit d’en discuter en aparté.