Le 'Lean IT' a beau être un concept à la mode chez les fournisseurs pour continuer de vendre des produits en ces temps de crise économique, il n'en reste pas moins une idée à regarder attentivement. Plusieurs analystes de Forrester Research ont mis le sujet en valeur durant les trois jours de la conférence européenne du cabinet d'études, la semaine dernière à Berlin. L'idée du 'lean', "mince" en anglais, vient de l'industrie. Dit simplement, cela consiste à améliorer l'efficacité d'une chaîne de production, à réduire les efforts et dépenses inutiles et à instaurer une culture d'amélioration permanente. L'exemple le plus célèbre est celui de Toyota. A ses débuts, raconte John Rymer, vice-président et analyste principal, le fabricant d'automobiles japonais était allé voir Ford et General Motors, et avait conclu qu'il n'avait pas les moyens de s'offrir une organisation aussi complexe. Toyota a donc mis en place des processus plus simples. On connaît la suite de l'histoire. La stratégie lean convient à toute entreprise orientée services L'informatique, qui cherche à industrialiser ses processus, ne pouvait passer à côté du 'Lean'. D'autant, explique Alex Peters, analyste principal, que tout est aujourd'hui proposé sous forme de services. Or, dit-il, "les principes du Lean sont universels, ils s'appliquent à tous les services, et peuvent être mis en oeuvre dans tout type d'entreprise". Au sein des entreprises mêmes, une stratégie 'lean' peut viser deux grands domaines : la conception des applications et l'exécution de ces applications. Pour la partie conception, John Rymer et Dave West, analyste senior, se sont efforcés de démontrer que les principes du 'lean' pouvaient se combiner avec ceux des méthodes agiles afin d'accélérer la création des applications d'impliquer davantage les développeurs et les utilisateurs, et de minimiser les risques d'échec. Etre 'lean' et agile en 7 recommandations Les deux analystes ont expliqué n'en être qu'au début de leur réflexion sur le sujet. Néanmoins, ils ont déjà défini une tactique en 7 points : 1) constituer des équipes de développeurs talentueux (et les écouter) ; 2) adopter des outils et des plateformes adaptés à l'objectif ; 3) respecter les standards ; 4) suivre des processus 'lean' et agiles ; 5) s'appuyer sur l'Open Source ; 6) optimiser les environnements de déploiement ; 7) se concentrer sur les applications essentielles au métier et externaliser le reste. Certains conseils relèvent du pur bon sens. Certains peuvent entrer en contradiction avec la politique de l'entreprise. Le fait d'adopter des outils et/ou des plateformes spécifiques à un projet est généralement interdit : il faut suivre les recommandations édictées par un bureau d'études interne. Simplement, fait remarquer Dave West, "les architectes ne vivent pas nécessairement au même rythme" que les développeurs. Ce qui présente une certaine logique : se retrouver à gérer du java ici, du PHP là, du Ruby ici et du Python là simplement parce que tel ou tel développeur en a décidé ainsi à un moment T tournerait vite au cauchemar intégral. Donner "un certain degré de liberté" aux développeurs [[page]] John Rymer et Dave West reconnaissent cela, mais plaident pour "un certain degré de liberté", qui fera par exemple qu'une équipe projet pourra utiliser Spring ou Tomcat plutôt que le framework ou le serveur d'applications recommandé. Dave West précise aussi que les méthodes agiles minimisent le risque associé à ces dérogations pour ce qui a trait à la maintenance. Le développement par itérations engage en effet le développeur sur le long terme : le socle qu'il développe en premier doit être de qualité dans son propre intérêt, puisqu'il s'appuiera dessus pour délivrer au fur et à mesure du projet les fonctionnalités demandées. Le même principe de liberté et d'encadrement prévaut, pour Forrester, en ce qui concerne l'Open Source. Même dans les entreprises déclarant ne pas recourir aux logiciels libres, leur usage est courant, soulignent les analystes. Car les développeurs ont une tendance naturelle à rechercher l'efficacité - un principe du 'lean' - en utilisant des outils ou des briques Open Source. "Ne laissez pas les développeurs faire cela dans leur coin", avertit Dave West, qui encourage les entreprises à encadrer cette pratique pour en bénéficier tout en maîtrisant les risques. Eviter les logiciels aux fonctionnalités inutiles Un autre objectif du 'lean' dans la conception d'applications consiste à éviter les fonctionnalités inutiles. Tant pour les applications développées sur mesure (les méthodes agiles permettent d'ailleurs de raffiner les exigences au fur et à mesure) que pour les applications du commerce, dont les analystes ont dénoncé l'inflation des fonctionnalités, parlant de "bloatware" ("inflagiciel" ?). Alex Peters est revenu sur le sujet dans une autre session, qu'il a axée vers les responsables de production. Outre ce conseil, il a enjoint les entreprises à prendre des mesures simples, qui ne demandent pas de financement particulier. "Plutôt que de sur-optimiser votre système d'appels entrants pour la correction d'incidents, installez des équipements améliorant la qualité en amont." Une DSI bicéphale : un courtier en services et un fournisseur de services Le reste, estime Alex Peters, est affaire de transformation : pour lui, les DSI doivent s'organiser en fonction de la configuration des directions métier. "Faites correspondre votre portefeuille de services avec les profils de vos clients métier." Cette transformation exige une dichotomie de la DSI, avec d'un côté un "IT supply manager", autrement dit un fournisseur de services technologiques qui sera mis en compétition avec les services externes, et de l'autre côté un "demand broker", un courtier qui sélectionnera la bonne combinaison de services pour répondre aux besoins des directions métier. Toutes ces notions impliquent des révolutions culturelles pour lesquelles toutes les entreprises ne seront pas prêtes. Pour un manager décidé à s'inspirer du 'lean IT', la crise économique représente une belle opportunité, car qui dit 'lean' dit plus grande efficacité, moins de gâchis, et donc a priori plus de réduction des coûts. Toutefois, prévient Alex Peters, la stratégie 'lean' vise plus l'amélioration des processus que les économies : "lean n'est pas synonyme de skinny [maigre] !"