Comment traiter les applications orphelines après une fusion

Une fusion est juridiquement achevée, les organigrammes sont publiés, mais une application continue de produire les étiquettes d’expédition d’un site industriel. Son développeur historique a quitté l’entreprise, le contrat de support est introuvable et personne ne sait si les sauvegardes sont restaurables. Cette situation est illustrative, mais le dilemme est bien réel : faut-il couper un outil non maîtrisé, au risque d’arrêter l’activité, ou le conserver, au risque d’entretenir une dépendance invisible ? Le dirigeant IT ne doit choisir ni l’aveuglement ni la purge immédiate. Il doit transformer une inconnue opérationnelle en décision gouvernée.

Reconnaître l’orphelin au-delà de l’inventaire

Une application n’est pas orpheline parce qu’elle est ancienne ou peu documentée. Elle le devient lorsqu’aucun responsable n’assume simultanément son usage, son risque et sa trajectoire. Elle peut encore avoir des utilisateurs, un serveur et même un budget, tout en étant dépourvue de propriétaire métier, d’équipe technique compétente, de fournisseur engagé ou de contrat exploitable. Après une fusion, cette rupture de responsabilité est fréquente : le sponsor a changé de fonction, l’équipe absorbée a été dispersée, la licence appartient à une autre entité ou l’outil dépend d’un annuaire destiné à disparaître.

Le premier geste n’est donc pas de compléter un catalogue décoratif. Il consiste à identifier, pour chaque application, qui peut autoriser une dépense, accepter un risque, confirmer la criticité et décider d’un arrêt. Tant que ces quatre réponses manquent, l’application reste un objet sans gouvernance, même si sa fiche technique paraît complète.

Mesurer le risque par les chaînes d’activité

Classer les applications selon leur technologie conduit souvent à sous-estimer les petites solutions. Un tableur enrichi, un exécutable local ou une base départementale peuvent commander une étape indispensable entre l’ERP, la banque et la logistique. Le DSI doit partir des chaînes d’activité : que se passe-t-il si l’outil devient indisponible, produit une donnée erronée ou perd ses accès ? Quel processus s’arrête, quel contournement existe et qui saura l’activer ?

Cette analyse doit couvrir les dépendances techniques et humaines : interfaces, comptes de service, certificats, postes spécifiques, tâches planifiées, formats de fichiers, compétences rares et clauses fournisseurs. Le RSSI y ajoute l’exposition, les privilèges, les données manipulées, la journalisation et la capacité à corriger une vulnérabilité. Une application discrète mais irremplaçable mérite davantage d’attention qu’un outil visible dont l’arrêt est facilement réversible.

Installer un sas de sécurité avant de migrer

L’urgence pousse parfois à intégrer toutes les applications au nouvel environnement. C’est dangereux : connecter trop vite un outil inconnu étend sa surface de confiance et peut importer des faiblesses dans le système cible. À l’inverse, l’isoler brutalement peut rompre une interface essentielle. Le bon compromis est un sas temporaire, explicitement gouverné.

Ce sas combine des mesures proportionnées : limitation des flux, comptes nominatifs ou secrets renouvelés, sauvegarde vérifiée, supervision minimale, restriction des droits et procédure de continuité. Chaque exception reçoit un responsable, une justification, une date de réexamen et une condition de sortie. Le caractère temporaire doit être crédible : sans échéance inscrite dans les arbitrages de la fusion, le sas devient une zone grise permanente. Sécuriser n’équivaut pas à pérenniser ; cela achète du temps pour décider sans exposer inutilement l’entreprise.

Construire quatre trajectoires, pas une migration unique

Chaque application doit rejoindre l’une de quatre trajectoires : conserver sous contrôle, remplacer, absorber dans une solution cible ou retirer. La décision combine la valeur métier, le risque, le coût complet, la dépendance fournisseur et l’effort de transition. Elle ne doit pas être dictée uniquement par la préférence technologique de l’acquéreur ni par la résistance de l’entité intégrée.

Conserver suppose de nommer un propriétaire, rétablir le support et financer une durée définie. Remplacer exige un processus cible et une reprise de données réaliste. Absorber impose de vérifier que la solution commune couvre les exceptions réellement utiles, sans reproduire toutes les personnalisations historiques. Retirer demande de traiter les archives, les interfaces, les accès et les obligations de conservation applicables avec les responsables compétents. Une cinquième catégorie, « à étudier », peut exister brièvement ; elle ne doit jamais devenir un parking budgétaire sans décideur.

Piloter la réduction de l’incertitude

Le tableau de bord utile ne compte pas seulement les applications supprimées. Il mesure la diminution du risque non attribué. Quelques indicateurs suffisent : proportion d’applications avec propriétaire métier et technique nommés, dépendances critiques confirmées, sauvegardes restaurées lors d’un test, comptes de service rattachés à un responsable, contrats régularisés, exceptions de sécurité encore ouvertes et décisions arrivant à échéance.

Il faut également suivre les flux plutôt que le seul stock : nombre d’orphelins qualifiés, arbitrés et effectivement sortis du sas pendant la période. Un portefeuille peut sembler stable alors que les dossiers les plus risqués n’avancent pas. Le comité d’intégration doit donc examiner les blocages nommément : donnée impossible à extraire, métier indisponible, fournisseur muet, budget non arbitré ou dépendance non testée. Chaque blocage appelle une décision, pas une couleur supplémentaire dans un reporting.

Éviter les décisions qui recréent l’orphelinat

Trois erreurs reviennent. La première consiste à confondre faible nombre d’utilisateurs et faible criticité. La deuxième est de lancer une rationalisation financière avant d’avoir cartographié les dépendances, puis de découvrir qu’une licence supprimée soutenait un processus vital. La troisième est de migrer les serveurs sans transférer les responsabilités : l’application change d’hébergement, pas de statut.

L’arbitrage final appartient à une gouvernance réunissant métier, IT, cybersécurité, finance et, lorsque nécessaire, fonctions juridiques ou conformité. Le dirigeant IT formule une recommandation explicite : risque accepté jusqu’à une date, investissement autorisé, remplacement engagé ou arrêt préparé. Il documente aussi ce qui ferait réviser la décision. Cette lecture à 360 degrés rejoint l’approche de « Révolution Numérique ! » : regarder ensemble stratégie, opérations, architecture, sécurité, coûts et fournisseurs. Une fusion réussie ne supprime pas mécaniquement l’ancien système ; elle rend chaque dépendance visible, attribuée et réversible.

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