Stratégie

Le Ceisar montre le décalage entre les principes et les usages des DSI

Les animateurs du Centre d'excellence de l'architecture d'entreprise de l'Ecole centrale de Paris se sont amusés à interroger les DSI, architectes, urbanistes et autres consultants sur ce qu'il faudrait faire pour être plus efficace, et sur ce qu'ils font en réalité. Il y a encore du chemin à faire.

PublicitéLe Ceisar, Centre d'excellence de l'architecture d'entreprise de l'Ecole centrale de Paris, a proposé cette semaine son bilan semestriel sous une forme originale : un sondage en direct sur les principes et les pratiques des DSI, architectes, urbanistes ou autres consultants présents dans l'assistance. Et le résultat n'a pas manqué de sel, car si tout le monde ou presque s'accorde sur les bonnes pratiques défendues par le Ceisar, ils sont très peu à les mettre en oeuvre. Animé par Jean-René Lyon et Pierre-Frédéric Rouberties, le Ceisar est piloté par ses sponsors, les grands groupes Air France/KLM, Axa, Michelin, Total, BNP Paribas. Chaque semestre, il produit traditionnellement des livres blancs tentant de débroussailler et de remettre au goût du jour les notions d'architecture du système d'information et d'architecture d'entreprise. Cette fois, le Ceisar a suivi plusieurs projets mené par ses sponsors, identifié les points de blocage, tiré des conclusions et formulé des suggestions. Des méthodes inadaptées à la création de solutions évolutives Ce sont ces suggestions qui ont été soumises au vote des participants (il y avait environ 130 votants, sur plus de 150 auditeurs). Par exemple: « Il serait bien que le sponsor d'un projet définisse son projet en une ou deux pages. » Car bien souvent, les équipes techniques doivent tâtonner pour comprendre quelle est la nature exacte du problème pour lequel on leur demande une solution. Cela a paru une évidence pour 86% des votants. Toutefois, ils étaient moins de 60% à dire que cela était faisable dans leur entreprise. De même, les observations du Ceisar ont mis en évidence l'inadaptation des méthodes actuelles de développement par rapport aux nouveaux besoins. En effet, la part des solutions dites de commodité (dont les besoins peuvent parfaitement être définis au préalable) décroît par rapport aux solutions évolutives. Et à 80%, les votants ont estimé que leurs procédures, adaptées à des projets définis, éventuellement contractualisés, ne convenaient pas. A plus de 93%, ils étaient même d'accord pour dire qu'il faudrait passer à une approche itérative. Sachant que la première version des développements devrait mettre l'accent sur l'architecture (d'accord à plus de 83%) plutôt que sur les fonctions. Ce qui paraît logique, le principe même d'une approche itérative étant de s'appuyer sur les bases posées lors de la première itération. Toutefois, on sait que ce type d'approche, apparenté aux méthodes agiles, est encore très rare, et, comme l'a souligné Jean-René Lyon, les procédures de recette sont totalement inadaptées. S'appuyer sur des fondations et réutiliser les composants existants Le Ceisar en a également profité pour sonder les présents sur les grandes idées qu'il défend. En premier lieu, le découpage du SI en solutions s'appuyant sur une fondation commune. Cette fondation doit rassembler tout ce qui est commun, réutilisable - ce qui peut représenter jusqu'à 70% du SI, selon Pierre-Frédéric Rouberties. D'après Jean-René Lyon, « des fondations puissantes permettent de réduire de moitié les charges et les délais des projets ». Et de demander aux votants: « Y croyez-vous ? ». Réponse : oui, à près de 79%. Commentaire de Jean-René Lyon, qui a fait toute sa carrière en vantant l'idée de composants réutilisables: « Il y a de l'espoir ! » Autre grande idée, l'utilisation de moteurs de règles et/ou de moteurs de workflow/BPM, afin de donner une plus large part au paramétrage, qui accroît la souplesse des solutions évolutives. Les votants ont jugé le recours à ces outils souhaitable, à plus de 82%. Mais les utilisent-ils ? 62% disent le faire dans moins de 10% des cas, 22% dans moins de la moitié des cas et 16% dans presque tous les cas. Le chef de projet devrait maîtriser l'architecture de la solution Les méthodes de gestion montrent aussi un fort décalage entre l'idéal et la pratique. Exemple: sachant que les gens se plaignent de devoir passer trop de temps avec trop d'interlocuteurs, il serait plus efficace, dans le cadre d'une approche itérative, que des acteurs du métier soient impliqués avec l'équipe IT. 92% des votants se sont dit d'accord. Quant à le pratiquer chez soi, c'est non à plus de 60%. Le chef de projet lui-même devrait passer d'un rôle finalement très administratif à un rôle de constructeur, maîtrisant l'architecture de la solution. Plus de 83% des votants ont opiné. Pour dire ensuite que ce n'était pas le cas chez eux, à 60%. Les dirigeants du Ceisar ont ensuite tenté de faire passer un message offensif, expliquant que les périodes de crise étaient les plus propices pour investir dans des projets de transformation. « Ce sont ces entreprises qui seront les mieux préparées pour la sortie de crise », nous a confié Pierre-Frédéric Rouberties. Mais d'avouer que dans la mesure où les projets de transformation et d'établissement de fondations sont des investissements à long terme, sans sponsor métier, il reste à trouver le moyen de convaincre les directions générales de financer les projets. Une gageure.