Technologies

Gérer le cycle de vie applicatif pour optimiser le service rendu par la DSI

---

Hewlett Packard Enterprise Services, PTC, Axway, Econocom et Capgemini ont participé à une réunion du CPI-B2B sur la gestion du cycle de vie applicatif (ALM) et ses apports à l'optimisation du service rendu par la DSI.

PublicitéL'ALM (Application Lifecycle Management - Gestion du cycle de vie applicatif) vise à gérer au mieux le patrimoine applicatif. L'un des problèmes récurrents des DSI est leur incapacité à maîtriser ce patrimoine. Hewlett Packard Enterprise Services, PTC, Axway, Econocom et Capgemini ont participé à une réunion du CPI-B2B (Club de la Presse Informatique B2B) sur l'ALM et ses intérêts le 25 novembre 2015. Ces prestataires ont ainsi pu expliquer les apports de l'ALM à l'optimisation du service rendu par la DSI.
« La définition de base de l'ALM est la gestion de l'applicatif à partir de sa conception, lors de sa fabrication puis pendant son maintien en conditions opérationnelles (MCO) avec, en cas d'évolution, rebouclage vers la conception » a commencé par définir Luc Arnaud, directeur du développement Application Services chez Econocom. L'ALM peut se décomposer en APM (gestion du patrimoine applicatif existant, le run), PPM (gestion des projets applicatifs, le build) et ADM (gestion de la maintenance corrective et évolutive).
Pour Adberrazak Dahmani, responsable testing chez Hewlett Packard Enterprise Services, « l'ALM est un processus global pour couvrir tous les besoins, un peu la carte Sesam-Vitale du SI ». On peut aussi le comparer au PLM (Product Lifecycle Management) dont ce n'est finalement qu'une déclinaison au logiciel. « On a souvent bien plus d'applications que ce que l'on croit car il ne faut pas oublier, outre le shadow-IT, les applications dans le cloud et celles embarquées, comme celles impliquées dans le scandale Volkswagen aux Etats-Unis » a relevé Eric Andrianarison, responsable technique ALM chez PTC.

Un outil de dialogue autant que d'optimisation

Philippe Roques, en charge de l'offre eAPM chez Capgemini, a rappelé les résultats de l'étude menée récemment par Capgemini. Adopter les bonnes pratiques en matière de gestion applicative permet ainsi de baisser le coût total de possession du SI de l'ordre de 37% mais aussi de diminuer les prises de risques et les temps de mises sur le marché, donc d'accroître l'agilité et l'efficience budgétaire. De plus, c'est aussi un outil pour améliorer le dialogue DSI/métiers, sous réserve de mettre effectivement en oeuvre les décisions prises.
A quoi sert concrètement l'ALM ? Jean Claude Bellando, directeur marketing Solutions chez Axway, a pris une image : « lorsque vous refaites votre salle de bain, devez-vous faire intervenir en premier lieu le carreleur, le peintre, le plombier ou l'électricien ? C'est la même problématique dans les projets informatiques. » L'approche « Big Bang » (qui, pour garder l'image, prive de salle de bains durant la totalité des travaux) n'est pas conseillée par Axway. Pour accroître l'agilité, il vaut mieux adopter une démarche de micro-projets successifs. Cela implique de disposer d'un socle stable (les murs, le sol, le plafond) avec des API clairement documentées (enduits et colles) pour chaque application. Chaque micro-projet pourra alors être mené dans des modes comme les pizza teams. Et chaque application exposera ses fonctions sous forme d'API dans un catalogue qui pourront être utilisées par les autres applications en fonction de droits accordés. Le cas échéant, si une application ou un individu abuse d'une API, un bon pilotage le repérera et l'accès à l'API pourra être coupé. « L'architecture prend une importance croissante dans la gouvernance des systèmes d'information car elle implique les règles de vie au sein du SI et donc les conséquences du comportement de telle application sur les autres » a noté Eric Andrianarison.

PublicitéChasser le Gaspi

Mener une démarche d'ALM commence par un recensement et une cartographie des flux applicatifs comme Laurent Sobanski, DSI de Habitat Toulouse, en a récemment témoigné. Et on peut ainsi repérer des applications inutiles ou des flux sans nécessité. Or ces applications et ces flux génèrent souvent des coûts, notamment de licences. « Payer de l'essence pour rouler poser rarement problème, payer de l'essence pour un véhicule à l'arrêt est nettement plus gênant » a relevé Jean Claude Bellando.
Une telle démarche permet aussi de savoir exactement qui utilise quoi pour quelle raison. On peut ainsi cartographier dans la foulée les processus métier au sein de l'entreprise. Et, du coup, on peut anticiper les conséquences d'une modification des processus ou du parc applicatif.

Etendre l'agilité à la mise en production

Une récente révolution technique et économique a bougé les lignes en matière de préoccupations des DSI : le cloud. Avant, l'agilité applicative se heurtait à la difficulté du déploiement du matériel. Avec le cloud, la mise en production n'est plus un problème : les ressources nécessaires peuvent être provisionnées en quelques instants. La frontière entre développement et mise en production n'a donc plus, dès lors, de raison d'être. On peut donc intégrer la mise en production au cycle de développement agile. Et c'est ainsi que l'on aboutit à DevOps.
« Dans le domaine de l'embarqué, il est difficile de mettre en oeuvre DevOps » a averti Eric Andrianarison. En effet, pour des raisons de sécurité, les onjets connectés peuvent ne pas avoir d'accès à Internet. Et il est impératif, bien souvent, que le produit soit réellement fiable. Comme l'observe le responsable technique ALM chez PTC : « vous n'accepteriez pas de monter dans un avion où le système de contrôle des moteurs est en phase béta ». Dans ce genre de cas, l'ALM doit donc intégrer la nécessaire certification des applicatifs dans le cycle de vie, en plus des phases déjà définies. Et ce même si DevOps prévoit le test dans sa méthodologie.

De l'applicatif au processus métier

Le maintien en conditions opérationnelles de l'application aboutit à la supervision applicative. Pour Luc Arnaud, « il faut maintenant corréler supervision et processus métier servis par les applications en question, ce que l'on nomme l'hypervision applicative. » Quand on pousse l'agilité jusque là, la DSI ne met plus en oeuvre des applications mais de véritables services présents sur un catalogue.
Et on peut gérer le porte-feuille applicatif en ayant en permanence dans le viseur les conséquences métier de toute décision. Eric Andrianarison rappelle le risque d'une telle démarche : « il faut se souvenir que l'optimum global n'est pas la somme des optimums locaux ». L'hypervision doit donc être elle aussi globale.

Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO

Partager cet article