Le coût invisible des applications qui ne sont plus utilisées

10 novembre 2026

Imaginons une situation volontairement illustrative. Lors d’une revue budgétaire, un DSI repère un abonnement SaaS dont aucun métier ne revendique l’usage. La dépense paraît modeste et la résiliation risquée. Il décide donc d’attendre. Six mois plus tard, l’outil existe toujours : comptes actifs, connecteur avec l’annuaire, données conservées et prestataire sollicité à chaque incident. Personne ne l’utilise pour produire, vendre ou décider, mais plusieurs équipes le maintiennent. L’application consomme silencieusement de l’argent, du temps et de la maîtrise.

Une facture ne révèle qu’une fraction du coût

Le prix de licence est le poste le plus visible, rarement le plus instructif. Une application peu utilisée mobilise encore identités, contrat, support, supervision, mises à jour, sauvegardes et parfois interfaces avec l’ERP. Elle ajoute des composants à documenter, auditer et restaurer.

Le coût devient organisationnel lorsque personne ne peut décider de son avenir. Le métier ne revendique plus l’outil, mais refuse le risque d’une suppression. La DSI paie sans posséder la décision fonctionnelle. Les achats négocient sans connaître les dépendances. Le RSSI voit une surface d’exposition sans pouvoir statuer sur les données. Chaque acteur protège son périmètre ; collectivement, l’entreprise conserve l’indécision.

L’usage faible n’est pas une preuve d’inutilité

Supprimer sur la seule base des connexions serait une erreur. Certaines applications servent rarement, lors d’une clôture annuelle, d’une urgence ou d’une consultation d’archives. D’autres exécutent des traitements automatisés sans utilisateur visible. Inversement, une connexion régulière peut provenir d’un compte technique ou d’une habitude sans valeur.

Le dirigeant IT doit distinguer usage humain, exécution technique, valeur pour un processus et conservation. Il évite ainsi de tout maintenir par précaution ou de supprimer sans vérifier les fonctions résiduelles. La bonne question n’est pas « combien d’utilisateurs se connectent ? », mais « quelle activité échoue, ralentit ou devient non conforme si ce service disparaît ? » Une réponse imprécise appelle une instruction, pas une condamnation.

Cartographier avant de décider

La démarche commence par un inventaire limité aux applications suspectées d’être dormantes, plutôt que par un grand recensement interminable. Pour chacune, une fiche courte réunit : propriétaire métier, responsable technique, processus soutenu, population réellement active, données hébergées, interfaces entrantes et sortantes, contrat, échéance, modalités d’export et scénario de secours.

Vient ensuite une vérification contradictoire. Les journaux montrent connexions, traitements et échanges. Le métier confirme les usages et périodes particulières. Finance et achats consolident les coûts directs. Le RSSI qualifie comptes, privilèges et données. Cette lecture rejoint l’approche proposée dans Révolution Numérique ! : regarder ensemble gouvernance, applications, budget, fournisseurs, cybersécurité et dépendances.

Enfin, chaque application reçoit une décision datée : conserver, réduire, remplacer, archiver ou retirer. Sans responsable, échéance et condition de sortie, la revue produit seulement un tableau supplémentaire.

Mesurer ce qui entretient réellement l’application

Quelques indicateurs suffisent s’ils conduisent à une décision. Le nombre d’utilisateurs nominatifs actifs doit être rapproché du nombre de licences payées. Le volume de tickets et d’heures de support révèle l’effort d’entretien. Le nombre d’interfaces, de comptes techniques et de certificats montre la dépendance cachée. La date du dernier export testé renseigne sur la capacité de sortie. Le délai restant avant renouvellement mesure l’urgence contractuelle.

Il faut aussi suivre la part des applications dotées d’un propriétaire métier, d’une criticité validée et d’une décision de cycle de vie à jour. Ces indicateurs rendent les situations comparables et révèlent les dossiers où l’entreprise paie pour éviter de trancher. Le tableau de bord ne récompense pas le nombre de suppressions ; il mesure coûts retirés, risques fermés et dépendances éliminées.

Retirer sans provoquer une panne différée

La suppression doit être conduite comme un changement opérationnel. Il faut d’abord geler les nouveaux usages et les créations de comptes, puis exporter les données dans un format exploitable, documenter les règles de conservation et identifier les destinataires des archives. Les interfaces sont arrêtées dans un ordre maîtrisé, avec surveillance des erreurs dans les systèmes voisins. Les droits, secrets techniques, certificats, agents et règles de pare-feu associés doivent ensuite être révoqués.

Une courte période de réversibilité peut être utile : accès fermé, service figé et procédure de réactivation. Elle ne doit pas devenir permanente. À son terme, le métier confirme les contrôles, la DSI vérifie l’absence de flux résiduel et les achats obtiennent la preuve de résiliation. Le retrait n’est achevé que lorsque dépendances et données ont un sort démontrable.

Les erreurs qui recréent la dette

La première erreur consiste à lancer une « chasse aux licences » conduite uniquement par l’objectif d’économie. Elle incite les métiers à défendre leurs outils et masque les coûts techniques. La deuxième est de migrer les données vers une nouvelle plateforme sans supprimer l’ancienne : l’entreprise finance alors deux environnements et conserve deux vérités possibles. La troisième est d’accepter une archive inexploitable, propriétaire ou non testée. Une donnée théoriquement récupérée peut rester pratiquement perdue.

Il faut également éviter les exceptions sans date, les propriétaires collectifs et les décisions conditionnées à une hypothétique transformation future. Une exception utile précise le risque couvert, son responsable et sa prochaine revue. Sinon, elle devient le mécanisme officiel de l’inaction.

L’arbitrage final appartient à la gouvernance

Conserver une application dormante peut être rationnel si son retrait coûte davantage à court terme, si un usage rare reste critique ou si la sortie doit attendre une échéance technique précise. Mais cette conservation doit devenir une décision explicite, chiffrée dans ses composantes connues, assortie de contrôles et limitée dans le temps.

Le dirigeant IT n’a donc pas à promettre un portefeuille sans aucune application inutilisée. Il doit empêcher qu’une absence d’usage se transforme en absence de décision. L’arbitrage le plus solide confronte trois coûts : continuer, retirer maintenant, ou préparer une sortie ultérieure. Puis il choisit un responsable et une date. C’est ainsi qu’un inventaire technique devient un acte de gouvernance : non pas supprimer pour afficher une économie, mais retirer les dépenses, les accès et les dépendances qui ne soutiennent plus aucune activité assumée.