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