Rationalisation applicative : la méthode terrain pour réduire le parc et les coûts de maintenance

La rationalisation applicative est presque toujours le premier chantier qu'on me confie quand j'arrive comme architecte d'entreprise dans un grand groupe. Le diagnostic ne varie quasiment jamais : un paysage applicatif qui a grandi de manière organique, au fil des projets tactiques et des fusions, avec des redondances fonctionnelles partout, des applications maintenues par habitude plutôt que par nécessité, et un coût de run qui dérive d'année en année jusqu'à étouffer le budget d'innovation. Personne ne sait dire avec certitude combien d'applications le SI compte réellement, ni lesquelles servent encore une finalité métier vivante.

En quinze ans de missions, j'ai appris que la rationalisation applicative échoue chaque fois qu'on la mène comme un exercice de réduction de coûts purement IT, et qu'elle réussit chaque fois qu'on l'ancre sur les capacités métier. La question n'est pas « quelles applications peut-on éteindre ? » mais « que sait faire l'organisation, et chaque capacité est-elle sur-outillée, sous-outillée ou correctement servie ? ». Cet article décrit la méthode que j'applique sur le terrain, de la cartographie initiale aux arbitrages, avec des résultats mesurés.

Pourquoi un parc applicatif dérive — et pourquoi le couper ne suffit pas

Un parc applicatif ne devient jamais redondant par mauvaise intention. Il dérive parce que chaque projet, pris isolément, a fait un choix rationnel : acheter un outil de plus, dupliquer une fonction pour aller plus vite, contourner une application jugée trop rigide. Au bout de trois décennies, le résultat agrégé est ingérable, alors que chaque décision unitaire se défendait.

C'est pourquoi attaquer la rationalisation par la seule liste des applications est une erreur classique. On obtient un débat sans fin où chaque propriétaire défend son outil, sans grille de lecture partagée. Le bon point d'entrée n'est pas l'application — c'est la capacité métier : ce que l'organisation sait faire, indépendamment de l'outil qui le supporte. Une fois ce référentiel posé, la redondance n'est plus une opinion, c'est un fait visible.

Ancrer la rationalisation sur la carte des capacités métier

Avant toute matrice d'évaluation, je stabilise une carte des capacités métier sur deux à trois niveaux. La capacité décrit le « quoi » — Gérer le sinistre, Exécuter un paiement, Acquérir un client — et reste stable dans le temps, neutre vis-à-vis de la technologie. C'est exactement ce qui en fait un bon ancrage : une application va et vient, une capacité demeure.

Concrètement, j'anime des ateliers courts avec les directeurs métier pour valider 5 à 8 capacités de niveau 1, déclinées en 30 à 50 capacités de niveau 2. On évite le piège du processus : la capacité n'est pas une étape de traitement (le « comment »), elle est une aptitude. Tant qu'on n'a pas séparé proprement le quoi du comment, les cartes deviennent illisibles et changent à chaque réorganisation.

Cette carte devient la colonne vertébrale de toute la démarche. Elle sert de langage commun entre la direction générale, la DSI et les équipes de delivery, et surtout elle conditionne la suite : on ne rationalise pas des applications dans le vide, on rationalise le support d'un parc applicatif à des capacités hiérarchisées par leur valeur stratégique.

Cartographier avec ArchiMate® : rendre visible l'invisible

La cartographie est ma première action concrète. J'utilise ArchiMate® pour modéliser les liens entre capacités métier, applications et infrastructure — pas comme un exercice académique, mais comme l'instrument qui rend visible l'invisible. Le diagramme qui change tout, c'est la matrice capacités × applications : en lignes les capacités, en colonnes le parc applicatif, et aux croisements le support effectif.

Quand un DSI voit sur une seule vue que trois applications couvrent la même capacité pour trois filiales différentes, la discussion cesse d'être politique pour devenir factuelle. Les configurations parlent d'elles-mêmes :

• Une capacité couverte par plusieurs applications redondantes : candidate naturelle à la consolidation.
• Une capacité stratégique reposant sur un fichier Excel ou un système fantôme : risque à traiter d'urgence.
• Une capacité peu stratégique sur-outillée : économie facile à capter.
• Une application orpheline ne servant plus aucune capacité vivante : candidate à l'élimination pure.

Je modélise ces vues dans ArchiMate® 3.2 et je les industrialise dans un référentiel (MEGA HOPEX, LeanIX ou Ardoq selon le contexte) en exploitant la relation native entre Application et Capability. L'outil n'a d'intérêt que parce qu'il maintient ces liens à jour ; le diagramme dessiné une fois pour une réunion ne sert à rien.

Évaluer le parc : la matrice TIME enrichie de critères terrain

Une fois le support cartographié, j'évalue chaque application avec la matrice TIME — Tolérer, Investir, Migrer, Éliminer. Mais la matrice brute ne suffit pas : je l'enrichis systématiquement de critères chiffrés et adaptés au contexte, sinon le classement reste subjectif.

• Dette technique mesurée (obsolescence du socle, support éditeur, niveau de couplage).
• Coût de maintenance annuel, run et licences compris.
• Nombre d'utilisateurs actifs réels, pas déclarés.
• Valeur stratégique de la ou des capacités servies.
• Alignement avec la trajectoire cible du SI.

Chaque application est passée au crible avec les équipes métier et IT, jamais en chambre. Le croisement « valeur stratégique de la capacité » × « qualité du support » donne une heatmap qui hiérarchise les décisions sans débat : on investit là où une capacité critique est mal servie, on élimine là où une capacité secondaire est sur-outillée.

La phase de décision : le moment le plus politique

La cartographie et l'évaluation sont les parties faciles. La phase de décision est la plus politique, parce que derrière chaque application il y a une équipe, un budget, parfois un ego. C'est précisément là que mon statut d'architecte externe devient un atout : je peux poser les questions difficiles sans porter les enjeux internes.

« Cette application a 12 utilisateurs et coûte 200 K€ par an de maintenance — quel est le plan ? » Posée par un consultant externe et adossée à des faits, la question devient discutable sans devenir une attaque personnelle. Je traite les quick wins en premier : les éliminations sans risque, les doublons évidents. Ils démontrent vite la valeur de la démarche, libèrent du budget et embarquent les équipes pour les arbitrages plus lourds qui suivront.

Je formalise toujours la cible avec le même vocabulaire que l'existant : la transformation devient ainsi l'arbitrage explicite entre un état current et un état cible, capacité par capacité. On ne demande plus « faut-il garder cette application ? » mais « quel parc minimal couvre nos capacités stratégiques au meilleur coût ? ».

Gouverner la cible pour qu'elle ne dérive pas à nouveau

Rationaliser sans gouvernance, c'est vider la baignoire sans fermer le robinet : le parc se reconstitue en deux ou trois ans. Je couple donc toujours le chantier à quelques garde-fous durables. Un principe simple — « acheter avant de construire », « une seule application de référence par capacité » — vaut mieux que dix règles que personne n'applique.

Le second levier est l'instruction systématique des nouveaux projets au regard de la carte des capacités : tout investissement applicatif doit déclarer la capacité qu'il sert et justifier pourquoi le parc existant ne suffit pas. C'est cette discipline, et non le grand nettoyage initial, qui maintient les économies dans la durée. Sans propriétaire métier au comité de direction, le référentiel redevient vite un objet IT abandonné dès le départ du consultant.

Les résultats observés et les pièges à éviter

Les résultats que j'ai mesurés en mission sont significatifs : une réduction de 20 à 30 % des coûts de maintenance applicative, une simplification nette des flux d'intégration, et surtout une bien meilleure agilité du SI pour absorber les nouveaux projets. On élimine couramment 25 à 35 % des étapes ou des doublons d'un parc qui a dérivé longtemps. La rationalisation n'est pas une fin en soi — c'est un enabler de transformation.

Trois pièges reviennent. Confondre exhaustivité et valeur : vouloir tout cartographier avant la moindre décision épuise le sponsor. Confondre capacité et application : sans l'ancrage capacité, on coupe à l'aveugle et on supprime parfois le support d'une capacité critique. Et sous-estimer la politique : une rationalisation est d'abord une conduite du changement, pas un exercice de tableur.

Ce que je retiens du terrain

La rationalisation applicative réussie ne commence jamais par la liste des applications. Elle commence par la carte des capacités métier, qui transforme un débat d'opinions en faits arbitrables. La cartographie ArchiMate® rend visible la redondance, la matrice TIME enrichie hiérarchise les décisions, et la gouvernance empêche le parc de dériver à nouveau.

Le vrai indicateur de succès n'est pas le nombre d'applications éteintes. C'est la capacité retrouvée de l'organisation à investir là où ça compte, parce qu'elle voit enfin clairement ce qu'elle fait, avec quels outils, et à quel coût.