Portefeuille applicatif et rationalisation : par où commencer

Commencer par l’inventaire

Les tableurs divergent, les responsables changent, et plus personne ne sait quelles applications méritent leur place. La gestion du portefeuille applicatif tient un inventaire unique et traite les applications comme un portefeuille à mesurer, à comparer et à rééquilibrer.

Pour chaque application, l’inventaire dit qui en est responsable, quel fournisseur la livre, où elle en est de son cycle de vie, ce qu’elle coûte, dans quel état elle se trouve et ce qui en dépend. La rationalisation s’appuie sur cet inventaire.

Les informations qui font décider

Une liste dit ce que l’entreprise possède. Le portefeuille y ajoute les informations qui font décider, relevées à intervalles réguliers. Sans elles, chaque renouvellement, audit ou transformation recommence le même travail de reconstitution.

Dans ArchiLU, chaque application est reliée à ses capacités, processus, interfaces, technologies et contrats : avant d’y toucher, son responsable voit ce qui en dépend. Tous les douze mois, chaque responsable reçoit une tâche pour confirmer ses objets.

• Responsabilité : un responsable nommé pour chaque application, côté métier et côté IT.
• Exposition aux fournisseurs : les éditeurs dont l’entreprise dépend, et la concentration de cette dépendance.
• Technologies : la pile derrière chaque application et les versions dont le support se termine.
• Cycle de vie : du pilote à l’exploitation, puis au retrait.
• Dépendances : qui appelle quoi, pour ne rien retirer à l’aveugle.
• Contrats et coûts : licences, échéances et renouvellements.

La rationalisation, une décision récurrente

La rationalisation décide quelles applications garder, faire évoluer ou retirer. Elle revient à chaque cycle budgétaire et à chaque renouvellement de contrat. Le but : réduire les doublons, supprimer les coûts évitables et baisser le risque sans casser l’activité qui s’appuie sur ces systèmes.

Une application coûteuse qui soutient un processus réglementé ne devient pas candidate au retrait parce qu’elle ressort en rouge dans le budget. À l’inverse, une application bon marché peut être la plus risquée du parc si elle tourne sur une technologie sans support et que plus personne ne connaît son fonctionnement. La décision pèse donc ensemble la valeur, la qualité, le coût et le risque.

Le modèle TIME : tolérer, investir, migrer, éliminer

Le modèle TIME de Gartner place chaque application selon sa valeur métier et sa qualité technique. Le quadrant suggère une action par défaut. Le modèle ouvre une discussion structurée ; les responsables tranchent les cas limites.

Dans ArchiLU, la vue TIME place chaque application selon l’avis de ses utilisateurs et la part de ses technologies encore supportées. La classe reste une décision enregistrée avec son motif : le responsable de l’application la propose, l’architecte d’entreprise la tient. Après « Éliminer » ou « Migrer », le responsable choisit de préparer le retrait ou d’ouvrir une demande. L’avis des utilisateurs est privé : il ne se lit qu’en agrégat, sur douze mois et à partir de cinq répondants.

• Tolérer : faible valeur, technique saine. L’application reste, sans nouvel investissement, sous surveillance.
• Investir : forte valeur, technique saine. L’application est protégée et modernisée ; la nouvelle dépense va là.
• Migrer : forte valeur, technique fragile. L’application change de plateforme ou est remplacée avant de devenir un passif.
• Éliminer : faible valeur, technique fragile. L’application est retirée, avec le coût et le risque qu’elle portait.

Coût, santé et risque

Le modèle TIME donne la forme de la décision ; trois familles d’informations disent avec quelle confiance la prendre. Le coût couvre la licence, l’hébergement, le support et l’effort interne. La santé couvre l’adéquation fonctionnelle, la stabilité, la satisfaction des utilisateurs et l’actualité de la technologie. Le risque couvre la fragilité du fournisseur, les points de défaillance uniques, l’exposition réglementaire et les composants en fin de vie.

Dans une banque, une application proche des paiements, chez un fournisseur fragile et sur un environnement d’exécution sans support, pose une question de risque bien avant une question de coût. Dans un organisme public, un traitement de formulaires ancien, peu coûteux et compris par un seul développeur proche de la retraite, est un risque de continuité. Les informations restent les mêmes ; leur poids change selon le secteur.

Dans ArchiLU, un contrat s’impute aux applications qu’il couvre, avec la justification de la répartition, et la page Contrats donne l’échéance et le renouvellement automatique repéré. Chaque application montre sa pile technique ; à 90 jours d’une fin de support, un case s’ouvre : prolonger, migrer, retirer ou accepter le risque.

Dette technique et coût de l’attente

La dette technique est l’écart entre la façon dont une application est construite aujourd’hui et celle qui la rendrait sûre, maintenable et adaptable. Elle cause rarement une panne spectaculaire. Elle se voit dans l’effort de maintenance qui augmente, les changements qui ralentissent, la dépendance à quelques personnes et une surface de sécurité mal connue.

Elle change le calcul de la rationalisation. Une application bon marché sur la ligne de licence peut coûter cher une fois chiffrés l’effort de maintenance et le risque d’une exploitation sans support. Rendre la dette explicite, application par application, l’empêche de décider de la feuille de route à la place des responsables.

Retrait et coût total de possession

Décider de retirer une application est la partie facile ; la retirer sans incident demande de la préparation. Les retraits manqués butent sur des dépendances cachées, des obligations de conservation des données et un reporting en aval dont personne ne connaissait l’existence. Le séquencement aide : couper les interfaces entrantes, archiver les données, puis retirer l’application.

Dans ArchiLU, « Retirer » ouvre un case en quatre étapes : impact, remplacement, décision et exécution. La revue du portefeuille donne le coût des candidates au retrait, l’économie estimée et l’économie constatée, chacune avec sa période et sa devise ; un inconnu n’y compte jamais pour zéro.

Le coût total de possession compte la licence et l’hébergement, mais aussi la mise en œuvre, l’entretien des intégrations, la maintenance interne, le support et le surcoût d’une technologie vieillissante. Deux applications à la même ligne de licence peuvent avoir des coûts totaux très différents, et cet écart fait souvent passer une décision de tolérer à migrer ou à éliminer.

Après une fusion

Deux parcs réunis portent souvent plusieurs applications pour la même capacité. Le travail part de la carte des capacités : chaque capacité portée par plusieurs applications désigne un doublon à examiner.

Dans ArchiLU, le tableau de bord montre les capacités portées par plusieurs applications. Chaque doublon passe par sa classe TIME, puis par le retrait ou par « Fusionner », qui reporte ses liens sur l’application qui reste. L’économie de chaque parc se lit dans sa devise.

Tenir la rationalisation dans la durée

Un audit de rationalisation ponctuel vieillit vite : de nouvelles applications arrivent, les responsables changent, et l’inventaire retourne au tableur. La gouvernance garde le portefeuille à jour avec un responsable de l’inventaire, une revue régulière et une règle : aucune application n’entre dans le parc sans responsable, sans place dans le modèle et sans cycle de vie déclaré.

La rationalisation tient mieux quand elle suit les rythmes existants : cycles budgétaires, renouvellements de contrats, jalons de transformation. Les décisions durent quand le portefeuille est le même modèle que celui des architectes, de la finance et des risques.