Décider de garder ou remplacer un logiciel métier vieillissant

Décider de garder ou remplacer un logiciel métier vieillissant

Quand l’incident transforme une gêne en décision

Situation illustrative : un lundi matin, l’application qui pilote les commandes fonctionne encore, mais une interface bloque les expéditions. L’éditeur ne maintient plus la version installée, le développeur qui connaît les traitements nocturnes part bientôt, et le métier refuse une interruption en pleine saison. Le directeur général demande au DSI une réponse apparemment simple : faut-il garder ce logiciel ou le remplacer ? Son âge ou son apparence ne tranchent rien. L’enjeu est de maintenir l’activité critique dans des conditions maîtrisées. Un logiciel ancien peut rester fiable ; un produit récent peut déjà être dangereux s’il est mal intégré, dépend d’un fournisseur fragile ou repose sur des données incontrôlées.

Comprendre ce qui rend réellement l’application vulnérable

Le vieillissement n’est pas une date : c’est l’accumulation de dépendances difficiles à gouverner. Il faut distinguer la dette technique, l’obsolescence des composants, l’absence de support, la rareté des compétences, les contournements manuels et l’écart entre le logiciel et les processus actuels. Cette décomposition évite de confondre fonctionnement présent et viabilité future.

Le DSI doit cartographier la chaîne complète : utilisateurs, flux entrants et sortants, interfaces, traitements différés, habilitations, infrastructures, sauvegardes, contrats et personnes clés. Une application qui semble isolée peut alimenter la facturation, les stocks ou des engagements clients. Son indisponibilité n’est alors qu’un risque parmi d’autres ; une donnée incohérente propagée silencieusement peut être plus grave. Le diagnostic porte donc sur les modes de défaillance et leurs conséquences, pas seulement sur la disponibilité affichée.

Comparer trois trajectoires, pas deux produits

L’arbitrage utile oppose rarement le statu quo à un grand remplacement immédiat. Trois trajectoires doivent être chiffrées et testées. La première consiste à conserver en sécurisant : documentation, supervision, sauvegardes restaurables, réduction des droits, contrat de support adapté et transmission des compétences. La deuxième organise une modernisation ciblée : composant remplacé, interfaces encapsulées ou fonctions progressivement séparées. La troisième engage le remplacement complet, avec reprise des données, adaptation des processus et extinction de l’ancien système.

Chaque scénario doit présenter son coût complet, son délai crédible, ses ressources rares, ses dépendances et son risque résiduel. Le remplacement crée aussi des fragilités : double exploitation, défauts de migration, perte de fonctions implicites et surcharge des experts. Conserver réduit le choc immédiat mais peut fermer rapidement des options si le support, les pièces techniques ou les compétences disparaissent.

Construire la décision à partir de preuves opérationnelles

La démarche commence par nommer un sponsor métier et un responsable de décision. Ensuite, l’équipe fixe pour chaque processus critique l’interruption tolérable, la perte de données acceptable et le mode dégradé. Elle vérifie ces affirmations par des tests : restauration d’une sauvegarde, bascule d’une interface, extraction des données, reprise d’un traitement et exécution d’une journée représentative sans l’expert historique.

Puis viennent les options. Pour chacune, le DSI produit une trajectoire séquencée, les prérequis non négociables et des portes de sortie. Un pilote n’a de valeur que s’il teste les difficultés décisives : qualité de la reprise, temps de traitement, droits d’accès, fonctionnement des interfaces et acceptation du processus cible. Enfin, le comité arbitre explicitement entre continuité, coût, risque et capacité d’exécution. Cette logique rejoint l’approche de Révolution Numérique !, qui relie les choix technologiques aux enjeux métier, aux dépendances fournisseurs et à la capacité réelle de décider.

Suivre les indicateurs qui annoncent la perte de contrôle

Le tableau de bord doit rester court et orienté décision. Il peut suivre la fréquence des incidents bloquants, le délai de rétablissement, le nombre de composants sans support, la part des opérations reposant sur des manipulations manuelles, la réussite des restaurations, la couverture documentaire et le nombre de personnes capables d’exploiter le système sans assistance exceptionnelle. Pour un remplacement s’ajoutent la qualité des données migrées, la réussite des scénarios critiques et la capacité de double fonctionnement.

Aucun indicateur ne décide seul. Une application stable mais impossible à restaurer demeure vulnérable. Un projet respectant son calendrier mais incapable de reprendre l’historique utile n’est pas prêt. Les seuils d’alerte doivent donc déclencher une action prévue : renforcer, réduire le périmètre, suspendre une étape ou préparer la sortie.

Éviter les erreurs qui rendent le choix irréversible

La première erreur consiste à laisser le fournisseur cadrer seul le problème : il connaît son produit, pas nécessairement les priorités de l’entreprise. La deuxième est de recopier dans le nouvel outil les exceptions et contrôles manuels de l’existant. La troisième est de sous-estimer les données : doublons, historiques incomplets et règles non documentées apparaissent souvent trop tard. La quatrième est d’annoncer une date avant d’avoir sécurisé les experts, les environnements, les décisions métier et les contrats.

Il faut aussi refuser le projet héroïque mené en parallèle de toutes les autres priorités. Si les mêmes spécialistes maintiennent l’ancien système, corrigent les incidents et préparent la migration, la capacité devient le premier risque. DSI EN CRISE est pertinent ici comme grille de reprise du contrôle : rendre visibles les responsabilités, les dépendances et les arbitrages plutôt que masquer la difficulté derrière un nouvel outil.

Trancher, puis rendre l’arbitrage révisable

Garder est défendable si les risques critiques sont réduits, les compétences transmissibles, les données récupérables et une trajectoire de sortie demeure possible. Remplacer devient nécessaire lorsque l’entreprise ne peut plus garantir la continuité, corriger les vulnérabilités, faire évoluer un processus essentiel ou éviter une dépendance sans alternative crédible. Entre les deux, une modernisation progressive peut acheter du temps, à condition de ne pas devenir un report indéfini.

La décision finale doit tenir sur une page : scénario choisi, risques acceptés, mesures immédiates, budget, responsables, jalons et conditions de réexamen. Le dirigeant n’achète pas la jeunesse d’un logiciel ; il choisit le niveau de maîtrise qu’il veut conserver sur une opération vitale. Le bon arbitrage n’est donc pas celui qui promet zéro risque, mais celui dont les conséquences, les limites et la voie de repli sont comprises avant l’engagement.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique