Parc applicatif : que faut-il conserver, moderniser ou remplacer ?

Comment décider quelles applications conserver, moderniser ou remplacer ?

Un ERP installé depuis quinze ans. Une application métier utilisée par 30 collaborateurs. Deux outils qui couvrent presque le même besoin. Un développement interne dont le fonctionnement repose sur quelques personnes. Un logiciel qui fonctionne encore correctement, mais dont chaque évolution devient compliquée.

Dans une DSI, les applications s’accumulent plus facilement qu’elles ne disparaissent.

Et tant qu’elles fonctionnent, une réaction assez naturelle consiste à les conserver.

Pourtant, maintenir une application a un coût. Pas uniquement celui de ses licences ou de son hébergement. Elle mobilise des compétences, du support, de la maintenance, de la documentation, des interfaces, des infrastructures et parfois des technologies devenues difficiles à faire évoluer.

La rationalisation du parc applicatif ne consiste donc pas à supprimer des applications pour réduire leur nombre. Elle consiste à déterminer lesquelles créent encore suffisamment de valeur pour justifier les ressources qu’elles mobilisent.

Pour un DSI, quatre décisions sont alors possibles : conserver, moderniser, remplacer ou décommissionner.

Encore faut-il savoir comment arbitrer.

 

Pourquoi le parc applicatif devient-il progressivement difficile à maîtriser ?

Peu d’entreprises construisent leur système d’information à partir d’une feuille blanche.

Il évolue par couches successives.

Un ERP est installé. Une application métier est développée. Une acquisition apporte de nouveaux outils. Un besoin urgent entraîne l’adoption d’une solution SaaS. Une interface est créée pour connecter deux systèmes. Quelques années plus tard, un nouvel outil couvre une partie du même périmètre sans que l’ancien disparaisse complètement.

Pris individuellement, chacun de ces choix peut avoir été parfaitement justifié.

C’est leur accumulation qui finit par créer de la complexité.

Le DSI peut alors se retrouver avec :

• plusieurs applications répondant à des besoins proches ;
• des logiciels peu utilisés mais toujours maintenus ;
• des technologies anciennes devenues difficiles à faire évoluer ;
• des interfaces dont la suppression pourrait avoir des conséquences mal identifiées ;
• des contrats ou licences qui se renouvellent presque automatiquement ;
• des applications critiques dont la connaissance repose sur une ou deux personnes.

Le sujet n’est donc pas nécessairement d’avoir « trop d’applications ».

La vraie question est : chaque application présente dans le SI justifie-t-elle encore son coût, ses risques et les ressources qu’elle mobilise ?

 

Rationalisation du parc applicatif : commencer par cartographier avant de décider

La première erreur serait de commencer par une liste des applications à supprimer.

Avant toute décision, il faut savoir précisément ce que l’entreprise possède et à quoi cela sert.

Pour chaque application importante, une fiche relativement simple peut suffire.

Elle doit permettre d’identifier :

• son usage et les processus métiers concernés ;
• le nombre et le type d’utilisateurs ;
• son niveau de criticité ;
• son coût direct et, lorsque cela est possible, ses principaux coûts indirects ;
• les technologies utilisées et leur niveau d’obsolescence ;
• les interfaces et dépendances avec les autres éléments du SI ;
• les compétences nécessaires à son maintien ;
• l’éditeur, le prestataire ou les personnes qui en maîtrisent réellement le fonctionnement.

L’objectif n’est pas de créer immédiatement une cartographie parfaite.

Il s’agit d’obtenir suffisamment d’informations pour comparer les applications entre elles et identifier les premières zones de risque.

Une application peu coûteuse mais indispensable à la production ne sera évidemment pas évaluée comme un outil secondaire utilisé quelques fois par mois.

 

Les 7 questions à poser pour chaque application

Pour rendre l’analyse concrète, un DSI peut évaluer chaque application à partir de sept questions.

1. Quelle valeur apporte-t-elle encore aux métiers ?

C’est le premier critère.

L’application répond-elle toujours à un besoin réel ?

Combien de collaborateurs l’utilisent réellement ?

Supporte-t-elle un processus critique ou est-elle simplement conservée parce qu’elle existe depuis longtemps ?

Une application ancienne n’est pas nécessairement une mauvaise application. Si elle répond parfaitement au besoin, reste fiable et peut être maintenue dans de bonnes conditions, son âge ne justifie pas à lui seul son remplacement.

2. Combien coûte-t-elle réellement ?

Le coût d’une application ne se limite pas au prix de la licence.

Il faut essayer d’intégrer :

• licences et abonnements ;
• hébergement et infrastructure ;
• maintenance ;
• support ;
• prestations externes ;
• temps passé par les équipes internes ;
• coût des interfaces ;
• incidents et corrections ;
• éventuels développements spécifiques.

Cette vision permet parfois de constater qu’une application apparemment peu coûteuse mobilise en réalité beaucoup de ressources.

3. Quel risque ferait courir son indisponibilité ?

Une application peut avoir peu d’utilisateurs et être extrêmement critique.

C’est par exemple le cas d’un outil utilisé par une petite équipe mais indispensable à la facturation, à la production, à la logistique ou à une obligation réglementaire.

Il faut donc évaluer les conséquences d’une indisponibilité :

• quelques utilisateurs gênés pendant quelques heures ?
• un processus métier bloqué ?
• une production interrompue ?
• une perte de chiffre d’affaires ?
• un risque réglementaire ou de sécurité ?

La criticité doit peser fortement dans la décision.

4. L’application est-elle encore maintenable ?

C’est ici que la dette technique devient visible.

Le logiciel est-il toujours supporté par son éditeur ?

Les technologies utilisées sont-elles encore maîtrisées ?

Les mises à jour peuvent-elles être réalisées normalement ?

La documentation est-elle suffisante ?

Les corrections prennent-elles de plus en plus de temps ?

Une application qui fonctionne aujourd’hui peut malgré tout devenir un risque si sa capacité à évoluer ou à être corrigée se réduit progressivement.

5. Combien de personnes savent réellement la maintenir ?

Cette question est souvent sous-estimée.

Une application peut sembler parfaitement stable jusqu’au départ de la seule personne qui maîtrise son architecture, son paramétrage ou ses interfaces.

Le bon indicateur n’est donc pas uniquement le nombre de personnes affectées au sujet.

Il faut demander :

si notre expert principal était indisponible pendant trois mois, serions-nous capables de maintenir cette application normalement ?

Si la réponse est non, le risque doit être identifié.

6. Existe-t-il déjà une autre application capable de couvrir le même besoin ?

Les doublons apparaissent progressivement.

Une filiale utilise un outil différent. Un nouveau SaaS est adopté. Une fonctionnalité autrefois absente de l’ERP devient disponible. Une application historique continue néanmoins d’exister.

La rationalisation consiste alors à regarder si plusieurs solutions pourraient être regroupées.

Mais attention : deux outils présentés comme équivalents sur le papier ne couvrent pas nécessairement les mêmes usages sur le terrain.

La décision doit donc associer les métiers concernés.

7. Quel effort faudrait-il pour la remplacer ?

Remplacer une application coûte également de l’argent.

Migration des données, interfaces, paramétrage, reprise de l’historique, formation, accompagnement des utilisateurs, tests, période de coexistence : la facture peut être importante.

Il faut donc comparer le coût du maintien avec le coût et le bénéfice réel du changement.

Moderniser pour moderniser n’est pas une stratégie.

 

La matrice pratique : conserver, moderniser, remplacer ou décommissionner ?

Une fois ces sept critères analysés, chaque application peut être orientée vers l’une de quatre décisions.

CONSERVER

Une application peut être conservée lorsqu’elle :

• apporte une valeur métier claire ;
• reste fiable et correctement maintenue ;
• présente un coût cohérent avec son usage ;
• ne crée pas de dépendance excessive ;
• reste suffisamment évolutive.

Conserver ne signifie pas ne rien faire.

Il faut continuer à documenter, maintenir, sécuriser et surveiller son évolution.

MODERNISER

La modernisation devient pertinente lorsque l’application conserve une forte valeur métier mais que son socle technique commence à poser problème.

Cela peut passer par :

• une montée de version ;
• une évolution d’architecture ;
• une migration d’infrastructure ;
• la suppression de développements devenus inutiles ;
• la modernisation des interfaces ;
• une meilleure documentation.

L’objectif est de préserver la valeur fonctionnelle tout en réduisant le risque technique.

REMPLACER

Le remplacement peut être envisagé lorsque l’application reste nécessaire mais que son maintien devient trop coûteux, trop risqué ou trop contraignant.

Quelques signaux doivent alerter :

• technologie ou version en fin de support ;
• incidents récurrents ;
• évolutions trop complexes ;
• expertise devenue très rare ;
• coûts de maintenance qui augmentent ;
• solution du marché désormais mieux adaptée ;
• impossibilité d’accompagner les nouveaux besoins métiers.

La question à poser n’est alors pas seulement « combien coûte le nouveau projet ? », mais aussi « combien nous coûtera le maintien de l’existant pendant les trois ou cinq prochaines années ? »

DÉCOMMISSIONNER

C’est parfois la décision la plus difficile.

Une application est rarement supprimée parce que personne n’en veut plus officiellement.

Il reste souvent quelques utilisateurs, quelques données ou un ancien processus qui empêchent de l’arrêter.

Pourtant, le décommissionnement doit être envisagé lorsqu’une application :

• n’apporte plus suffisamment de valeur ;
• possède très peu d’utilisateurs ;
• fait doublon avec une autre solution ;
• correspond à un processus abandonné ;
• mobilise des ressources disproportionnées par rapport à son usage.

La suppression doit évidemment être préparée : archivage des données, dépendances, obligations de conservation, interfaces et utilisateurs doivent être vérifiés avant l’arrêt.

Un scoring simple pour prioriser les décisions

Pour éviter que la rationalisation reste théorique, il est possible d’utiliser une notation très simple.

Pour chaque application, attribuez une note de 1 à 5 sur les critères suivants :

Critère	1	5
Valeur métier	faible	indispensable
Criticité	faible	critique
Coût de maintien	faible	très élevé
Obsolescence	faible	très forte
Dépendance à des compétences rares	faible	très forte
Redondance avec d’autres outils	aucune	très forte
Difficulté de remplacement	simple	très complexe

Cette notation ne doit pas produire automatiquement la décision.

Elle permet surtout de faire ressortir les applications qui méritent une analyse prioritaire.

 

Une application avec forte valeur métier:

+ forte obsolescence sera probablement candidate à une modernisation ou un remplacement.

+ forte redondance + coût élevé sera une bonne candidate au décommissionnement.

+ faible risque + coût maîtrisé n’a probablement aucune raison d’être remplacée à court terme.

C’est cette comparaison qui rend la cartographie réellement utile.

 

Attention à ne pas transformer la rationalisation en projet uniquement IT

Une DSI ne peut pas décider seule de supprimer une application métier sous prétexte qu’elle coûte cher ou qu’elle semble peu utilisée.

Le nombre de connexions ne dit pas tout.

Un outil utilisé une fois par mois peut être essentiel à la clôture comptable, à une déclaration réglementaire ou à un processus industriel.

La bonne démarche consiste donc à associer :

• la DSI pour les aspects techniques et économiques ;
• les métiers pour la valeur et les usages ;
• la cybersécurité pour les risques ;
• les achats lorsque des contrats importants sont concernés ;
• la direction lorsque les arbitrages ont un impact stratégique.

Le patrimoine applicatif est un sujet IT, mais ses conséquences sont largement métier.

Faut-il commencer par les applications les plus anciennes ?

Pas nécessairement.

L’âge constitue un indicateur, pas une décision.

Une application ancienne, stable, documentée et peu coûteuse peut présenter moins de risques qu’une application récente, mal intégrée et très dépendante d’un fournisseur.

Pour lancer la démarche, il peut être plus efficace de rechercher trois catégories d’applications:

– à risque, parce qu’elles sont critiques, obsolètes ou dépendantes de compétences rares.

– coûteuses, parce que leur coût réel semble disproportionné par rapport à leur valeur.

– redondantes, parce que plusieurs outils couvrent tout ou partie du même besoin.

Ces trois listes permettent généralement d’identifier rapidement les premières priorités.

Et si la DSI ne dispose pas des compétences nécessaires pour faire évoluer l’application ?

La rationalisation du parc applicatif fait parfois apparaître un autre problème : l’entreprise sait qu’une application doit évoluer, mais ne possède plus les ressources nécessaires pour mener le projet.

Il faut alors distinguer le besoin durable du besoin temporaire.

Si la compétence sera nécessaire pendant plusieurs années et doit rester au cœur de la DSI, le recrutement peut être pertinent.

Si l’entreprise a besoin d’une expertise ciblée pour auditer, migrer, moderniser ou remplacer une application, la prestation de service permet de renforcer ponctuellement l’équipe.

Enfin, lorsqu’un programme de rationalisation ou de transformation nécessite temporairement un pilotage expérimenté, le management de transition peut constituer une troisième réponse.

L’objectif n’est pas d’externaliser systématiquement la transformation du SI.

Il est de disposer des bonnes compétences pendant la durée nécessaire tout en conservant la maîtrise des décisions et de la connaissance en interne.

La checklist du DSI : par où commencer lundi matin ?

Une démarche de rationalisation n’a pas besoin de commencer par un programme de plusieurs mois.

Une première analyse peut être lancée avec cinq actions concrètes :

1. Lister les applications réellement utilisées, en commençant par les principaux périmètres métiers.
2. Identifier les propriétaires métier et IT de chaque application.
3. Repérer les applications critiques, redondantes ou techniquement fragiles.
4. Noter les applications prioritaires avec les 7 critères proposés dans cet article.
5. Sélectionner 5 à 10 applications à analyser en profondeur, plutôt que de vouloir immédiatement traiter l’ensemble du patrimoine.

Cette première photographie permet déjà d’ouvrir les bonnes discussions avec les métiers et la Direction.

Rationaliser ne signifie pas forcément réduire

La rationalisation du parc applicatif ne doit pas devenir une course au nombre d’applications supprimées.

Une DSI avec 200 applications n’est pas nécessairement mieux gérée qu’une DSI qui en possède 400.

L’enjeu est ailleurs.

Chaque application doit avoir une raison suffisamment claire d’exister.

Elle doit apporter une valeur identifiable, présenter un niveau de risque maîtrisé et mobiliser des ressources cohérentes avec son importance pour l’entreprise.

La question à poser à la rentrée n’est donc pas :

« Combien d’applications pouvons-nous supprimer ? »

Mais plutôt :

« Si nous devions aujourd’hui justifier le maintien de chacune de nos applications, pour lesquelles aurions-nous du mal à répondre ? »

Ce sont probablement celles-là qu’il faut commencer par analyser.

 

FAQ – Rationalisation du parc applicatif

Qu’est-ce que la rationalisation du parc applicatif ?

La rationalisation consiste à analyser les applications du système d’information afin de déterminer lesquelles doivent être conservées, modernisées, remplacées, regroupées ou décommissionnées en fonction de leur valeur, de leur coût et des risques associés.

Comment savoir si une application doit être remplacée ?

Plusieurs signaux peuvent justifier une analyse : obsolescence technique, fin de support, incidents fréquents, coûts croissants, difficulté à trouver les compétences nécessaires, faible capacité d’évolution ou existence d’une solution mieux adaptée.

Une application ancienne doit-elle forcément être remplacée ?

Non. L’âge ne constitue pas à lui seul un critère suffisant. Une application ancienne peut rester pertinente lorsqu’elle apporte une forte valeur métier, reste maintenable, sécurisée et économiquement cohérente.

Comment identifier les applications à supprimer en priorité ?

Il est pertinent de commencer par les applications peu utilisées, redondantes, coûteuses ou correspondant à des processus qui n’existent plus. Avant tout décommissionnement, les données, interfaces, obligations réglementaires et dépendances doivent néanmoins être vérifiées.

Qui doit participer à la rationalisation du parc applicatif ?

La DSI doit piloter la dimension technique, mais les métiers doivent être associés pour évaluer les usages et la valeur réelle des applications. Selon les sujets, cybersécurité, achats, finance et Direction générale peuvent également intervenir.

 

S-quaar – Prestation, Recrutement et Management de transition IT & Digital

S-quaar accompagne les entreprises dans leurs enjeux de recrutement et de renforcement des équipes IT & Digital, à travers trois solutions complémentaires : recrutement en CDI, prestation de service et management de transition.

Nous intervenons auprès de PME, ETI et grands groupes sur l’ensemble des métiers de la DSI : infrastructure, systèmes et réseaux, développement, data, cybersécurité, cloud, ERP, gestion de projet, architecture SI et fonctions de management.

Notre approche repose sur une compréhension précise du besoin et une sélection exigeante afin de proposer des experts IT pertinents, fiables et rapidement opérationnels, selon le contexte et la durée du besoin.

S-quaar intervient principalement en France et accompagne également ses clients sur d’autres fonctions stratégiques : Finance, RH, Juridique et Industrie & Supply Chain.

Contact

Roxane : r.lebreton@s-quaar.fr / 07.89.00.34.14
Nicolas : n.buniowski@s-quaar.fr / 06.77.13.11.92
www.s-quaar.fr