Ainsi doit-on s’interroger sur une application qui ne donne plus satisfaction en termes de fonctionnalités et dont le coût en maintenance croît : quelle valeur a-t-elle pour l’entreprise ? Est-ce
une valeur purement utilitaire ? A-t-elle de l’importance pour les métiers tout en restant relativement standard ? Est-ce que cette application est directement liée au chiffre d’affaires, aux performances, à la productivité, à la capacité d’innovation ? Si elle est utilitaire, peut-on l’obtenir autrement en consommant moins de ressources, de temps et d’effort ? On peut envisager dans certains cas de remplacer cette application par un service en mode Saas (Software As A service) si l’équation valeur est respectée, le tout étant de pouvoir le déterminer en positionnant l’application sur les axes d’analyse, comme dans l’exemple de la figure ci-dessous.
PositionnementAppli.png Figure 6-6.
Positionnement de la « valeur » des applications sur les axes d’analyse
Dans l’illustration ci-dessus, on peut s’interroger sur la nécessité de maintenir l’application B en interne. Apparemment, il s’agit d’une application de back office/support, dont l’architecture est insuffisamment robuste et/ou ouverte et évolutive, la sécurité n’est pas satisfaisante et elle consomme trop de ressources humaines pour un service somme toute moyen à un coût excessif. Doit-on l’externaliser en « tierce maintenance applicative », c’est-à-dire confier la maintenance à un tiers professionnel ? Cela coûtera sans doute plus cher que l’apport puisqu’il faudra de toute façon une remise à niveau avant l’externalisation. Peut-on la remplacer en mode Saas ? Si l’offre existe pour une couverture des fonctions optimales, c’est sans doute une des meilleures solutions.
L’application A et l’application C présentent d’autres cas de figure.
L’application C est une application dans la droite ligne de la stratégie marketing de la DSI, elle est développée et maintenue par les bonnes ressources et sans doute dispose-t-elle des niveaux de services optimum pour les attentes des utilisateurs.
L’investissement est clairement nécessaire mais les coûts semblent un peu trop élevés, qu’en est-il réellement ?
L’application A est sans doute critique pour le métier, voire stratégique, et les coûts sont optimisés pour la satisfaction d’un ensemble optimum de besoins. Cependant, le ratio sur l’axe ressources humaines est insatisfaisant. Y-a-t-il un bon dimensionnement des ressources ? L’application requiert-elle trop de ressources rares ou y-a-t-il un risque de perte de connaissances et d’expertises (départ de personnes expertes pour retraite ou démotivation) ?
Comprendre le cycle de vie des évolutions
Une fois l’analyse du portefeuille applicatif effectuée et les décisions prises (investissement pour un effort de maintenance préventive plus ou moins grand, réarchitecture, remplacement par des services en mode abonnement, redimensionnement des ressources ou redocumentation, etc.), encore faut-il gérer le cycle de vie des évolutions.
Il s’agit ici de mettre en place l’ensemble des processus, outils et méthodes qui permettent de gérer de manière efficace (en termes de
« valeur », au sens qualité du résultat produit en réponse à la demande versus coût de l’évolution), l’évolution des applications patrimoniales. C’est un besoin qui va bien au-delà de la gestion des exigences et des demandes de changements et qui doit progressivement conduire à la mise en place des meilleures pratiques, ou à l’évolution des pratiques, dans toutes les étapes du cycle de vie telles que décrites dans la figure ci-dessous, avec des points-clés de décision qui sont à gérer au niveau du portefeuille applicatif, par un comité stratégique.
LLM.png
Figure 6-7.
Cycle de vie de l’évolution des applications patrimoniales Pour autant, la gestion du changement est une composante-clé dans ce cycle d’évolution car, nous l’avons vu, des demandes de changement non gérées dans le cycle de vie d’un projet déstabilisent toute la construction et mettent en danger l’atteinte des résultats. Dans le cycle de la maintenance, si elles sont faites hâtivement ou sans tenir compte des impacts sur l’existant, elles conduisent à des défauts de qualité, des risques d’erreur en production et des incohérences globales.
Il faut donc, pour toute demande de changement, avoir un dispositif qui évalue la nature et la complexité de la modification demandée, la criticité fonctionnelle et les risques d’impact (sur les composants du système existants). Ce sont des paramètres indispensables à la décision de réalisation et, le cas échéant, à la planification de la réalisation, afin de dimensionner en conséquence les ressources et les tests nécessaires.
Trois aspects majeurs liés à la gestion des changements sont problématiques aujourd’hui, et nécessitent encore des évolutions des méthodes et outils pour optimiser leur traitement. Il s’agit de l’analyse d’impact, l’optimisation des tests et le calcul des unités d’œuvre pour estimer le temps de réalisation et d’intégration d’une modification.
Par manque de documentation, de connaissance des applications et de dispositif d’aide à l’analyse, le temps d’analyse d’impact pour les applications existantes est long et le résultat souvent incomplet.
En réaction, particulièrement quand la demande d’évolution est faite sous pression, les tests sont bâclés et ne couvrent pas tous les cas qu’ils devraient. Cela est également le cas dans un projet où plus une modification demandée sera proche de la fin du parcours, plus son impact pourra être significatif, et plus il pèsera sur les délais, coûts et qualité du projet.
À un certain stade, les projets doivent faire passer les demandes de changement vers une version suivante. Si une certaine flexibilité est possible jusqu’au stade des spécifications détaillée, une fois les développements lancés, seules les modifications critiques doivent être prises en compte, et une fois l’application stabilisée, les demandes doivent rentrer dans un cycle d’évolution des versions de l’application.
En maintenance, toute solution qui permet de fournir une aide automatisée à l’analyse des dépendances entre objets et composants de milliers de lignes de code est bien sûr à considérer de près.
Quant aux tests, comme il s’agit en grande partie de tests de non-régression, la mise en place d’un référentiel de cas de tests sur la
durée de vie d’une application est une bonne pratique à ne pas négliger.
La problématique des unités d’œuvre est autre, nous y reviendrons au chapitre 9, p.230.