Le ton économique change et le mot priorité prend soudainement plus de poids. Un budget serré force une question utile : si cette application arrête demain matin, quel processus s’arrête avec elle et combien de temps peut-il attendre?

La réponse demande davantage qu’une liste de serveurs. Je commencerais par un graphe de dépendances. Une application de commandes peut appeler un service de crédit, écrire dans SQL Server, déposer un fichier pour l’entrepôt et utiliser Active Directory. Couper le petit serveur de fichiers parce qu’il semble peu utilisé peut donc bloquer l’expédition, même si personne ne le nommait dans le budget du système de commandes.

client -> application Commandes -> SQL Server
                    |             -> service Crédit
                    `------------- > partage Entrepôt -> expédition

Chaque nœud reçoit un propriétaire, un coût annuel, une fenêtre de service, un objectif de reprise et les consommateurs connus. Le dessin n’a pas besoin d’être parfait; il doit montrer ce qu’une décision risque d’entraîner.

Calculer un coût qui inclut le travail

La licence et le matériel sont visibles. Le soutien, les interfaces et les opérations le sont moins. Pour comparer deux applications semblables, je ferais un calcul simple :

coût annuel = licences
            + amortissement du matériel
            + heures de soutien x taux chargé
            + sauvegarde et stockage
            + coût moyen des incidents

Un outil à 5 000 $ de licence qui exige 400 heures de soutien à 75 $ coûte déjà 35 000 $ avant le serveur. À l’inverse, une plateforme chère peut être rentable si elle retire chaque semaine des saisies manuelles et des erreurs mesurables.

Le coût d’une panne doit rester séparé de sa probabilité. Si une journée d’arrêt vaut 100 000 $ et qu’on estime une chance annuelle de 5 %, l’exposition moyenne est 5 000 $. Cette moyenne n’autorise pas à ignorer le scénario : la trésorerie et les clients vivent la journée complète lorsqu’elle arrive. Le calcul sert à comparer une protection, pas à promettre l’avenir.

Pour retirer un système, je suivrais une séquence réversible :

1. confirmer les propriétaires et les dépendances dans les logs, pas seulement en réunion;
2. sauvegarder et tester l’export dans un format lisible;
3. couper d’abord l’accès entrant ou passer en lecture seule;
4. observer pendant une période convenue;
5. éteindre avant de supprimer, avec un plan de retour daté.

Pendant l’observation, je journaliserais toute tentative de connexion vers le service éteint. Un appel oublié fournit le nom de la machine consommatrice et l’heure du besoin. On peut alors remettre temporairement le service, corriger cette dépendance et recommencer, plutôt que découvrir le lien après l’effacement des données.

Les économies rapides les plus dangereuses déplacent le coût. Reporter les correctifs augmente la surface d’attaque. Réduire la rétention peut rendre une enquête impossible. Sauter un test de restauration conserve un backup dont personne ne connaît la valeur. Je distinguerais donc une vraie élimination de dépendance d’un risque simplement repoussé.

Je ne construirais pas un inventaire de quarante pages avant d’agir. Je choisirais les dix services les plus coûteux ou critiques, mesurerais leurs liens et trouverais un doublon qu’on peut retirer proprement. Le TI montre sa valeur lorsqu’il sait à la fois ce qui peut disparaître et ce qu’une coupe apparemment petite ferait arrêter derrière.