Le projet de remplacement s’est bien passé. Le nouveau système est en production, les utilisateurs ont basculé, le comité a prononcé la clôture. L’ancien système, lui, devait s’éteindre « une fois les derniers usages migrés ». Deux ans plus tard, il tourne toujours. Plus personne ne s’en sert pour travailler, mais un état mensuel y puise encore des chiffres, une direction pense qu’il faudra peut-être y retrouver de l’historique en cas de contrôle, et une interface continue de déposer un fichier quelque part.

Il ne coûte pas rien. Il consomme des licences, des sauvegardes, une fenêtre de maintenance, un socle technique qui vieillit, des correctifs qu’il faut appliquer sans jamais pouvoir tester complètement, et il produit chaque année la même remarque d’audit. Surtout, personne ne sait nommer la personne qui aurait aujourd’hui l’autorité de l’éteindre.

Ce scénario n’est pas un accident de gouvernance : c’est le comportement par défaut de toute organisation. Les parcs applicatifs croissent de façon monotone. Chaque année en ajoute ; presque aucune n’en retire. La cause n’est ni la négligence ni le manque de méthode. C’est qu’arrêter un système est la seule activité du cycle de vie qui n’a ni sponsor, ni ligne budgétaire, ni bénéfice visible pour celui qui devrait la financer. Le décommissionnement échoue rarement pour des raisons techniques. Il échoue parce que le droit d’éteindre n’a jamais été attribué à personne, et parce que les conditions du retrait n’ont pas été écrites au moment où elles ne coûtaient rien : à la mise en service.

Le parc ne décroît jamais

L’asymétrie est structurelle et mérite d’être regardée de près, parce qu’elle explique pourquoi le problème résiste aux bonnes intentions.

Mettre un système en service dispose d’un porteur, d’un dossier, d’un bénéfice énonçable et d’une date d’inauguration. L’arrêter ne dispose de rien de tout cela. Le bénéfice est diffus — un peu de licence, un peu d’exploitation, un peu moins de surface exposée — et se répartit sur des budgets qui ne sont pas ceux qui paieront l’effort. Le coût, lui, est concentré et immédiat : c’est un projet, mené par des équipes déjà occupées ailleurs, sur un système que plus personne ne maîtrise. Et le risque est asymétrique : réussir ne rapporte rien de visible, casser quelque chose se remarque immédiatement.

Chaque arbitrage individuel est donc parfaitement rationnel. Reporter l’extinction est toujours le choix prudent, pour chacun, pris isolément. C’est la somme de ces décisions localement justes qui produit un parc qui ne fait que grossir — et c’est pourquoi aucune exhortation à « faire le ménage » n’y change quoi que ce soit.

Ce que cette accumulation coûte réellement n’apparaît pas non plus sur une ligne. Les licences et l’infrastructure sont la partie mesurable, et c’est la plus faible. Le coût dominant est un coût d’attention : chaque système du parc prélève une part de la capacité à appliquer des correctifs, à instruire des audits, à maintenir vivante une compétence, à tester des interfaces à chaque changement voisin. Il prélève aussi une part de la capacité à décider : plus le parc est étendu, plus le périmètre d’une transformation devient coûteux à seulement cadrer.

Les systèmes résiduels les plus chers sont d’ailleurs précisément ceux dont on dit qu’ils « ne coûtent presque rien à laisser tourner ». Ils portent un socle technique en fin de vie, une compétence en voie de disparition et une dépendance dont plus personne ne se souvient. Leur coût n’est pas dans leur exploitation courante : il est dans le jour où il faudra y toucher.

Les quatre verrous

Quand une organisation tente réellement d’éteindre un système, elle rencontre quatre obstacles distincts. Les confondre est la principale raison pour laquelle les campagnes de rationalisation s’arrêtent après le premier cas difficile.

Le verrou de l’usage. Personne ne sait qui s’en sert encore. L’usage déclaré et l’usage réel divergent toujours, et l’usage résiduel n’est presque jamais la fonction principale du système : c’est un état, un export, une consultation occasionnelle en fin de trimestre. Tant que cette question reste ouverte, la réponse de précaution — « on ne peut pas encore » — est imbattable, parce qu’elle ne demande à personne de prendre un risque. La mesure de l’usage effectif, par les connexions, le trafic et les lectures réellement observées, transforme une crainte diffuse en une liste courte d’interlocuteurs identifiés. C’est le préalable à tout le reste.

Le verrou de la dépendance. Un système que plus personne n’appelle officiellement peut continuer d’alimenter trois autres applications par des échanges que personne n’a catalogués : un fichier déposé chaque nuit, une lecture directe en base, une table partagée. Le projet de retrait découvre alors la cartographie des dépendances qui n’a jamais été tenue — et il la découvre au pire moment, une fois l’effort engagé et le calendrier annoncé.

Le verrou de la donnée. C’est le plus lourd, et celui que les plans de retrait anticipent le moins. Éteindre une application n’est pas supprimer ses données, et trois questions bien différentes sont ici constamment confondues : ce qui doit être conservé au titre d’une obligation de rétention, ce qui doit rester accessible au métier parce qu’il constitue l’historique d’un dossier vivant, et ce qui doit simplement être relisible en cas de contrôle ou de litige. Chacune appelle un horizon, une forme et un coût différents.

Les confondre produit invariablement la même non-décision : on garde tout, et on garde l’application allumée pour pouvoir le lire. C’est ainsi qu’un système devient immortel — non pas parce qu’il rend un service, mais parce qu’il sert de visionneuse à ses propres données. Le traitement propre consiste à séparer la donnée de l’application qui l’a produite : l’extraire dans une forme documentée et auto-portante, accompagnée de sa signification métier, et non sous la forme d’un déversement brut de tables dont plus personne ne saura interpréter les colonnes dans cinq ans. Une archive dont le sens est perdu n’est pas une archive : c’est un volume de stockage qui rassure.

Un point est régulièrement omis : une obligation de conservation comporte aussi un terme. Passé ce terme, conserver n’est plus la position prudente — c’est un risque que personne n’a instruit, particulièrement lorsque les données concernent des personnes. « On garde tout, on ne sait jamais » n’est pas une politique de rétention.

Le verrou de la responsabilité. Le référentiel désigne bien un propriétaire, mais c’est souvent quelqu’un qui a hérité du système et n’a aucun mandat pour arbitrer sa fin. Ceux qui bénéficieraient de l’extinction — l’exploitation, la sécurité, l’architecture — ne peuvent pas la décider. Celui qui pourrait la décider n’y a aucun intérêt propre. Dans cette configuration, la réponse par défaut à « peut-on l’éteindre ? » sera toujours non, parce que le non est gratuit et le oui est risqué.

Le retrait s’instruit à la mise en service

Le moment le moins coûteux pour décider comment un système s’arrête est celui où il démarre. À la mise en service, les dépendances sont connues, les structures de données sont documentées, l’équipe qui les a conçues est présente, et personne n’y est encore attaché.

Ce qui devrait être écrit à ce moment tient en peu de lignes : la durée de vie attendue ou, à défaut, la date à laquelle la question sera réexaminée ; qui détient la décision de retrait ; dans quelle forme les données seront extraites le jour venu ; et quelles interfaces sont contractuelles — donc supportées et connues — par opposition à celles qui sont seulement tolérées.

La formulation directe est utile en comité : un système mis en service sans réponse documentée à la question « comment cela s’arrête ? » est un système placé sous un engagement implicite de maintenance perpétuelle. Cet engagement n’a été validé par personne, et il sera payé par tout le monde.

Le corollaire concerne les projets de remplacement, et il est plus exigeant qu’il n’y paraît : le retrait de l’ancien système doit figurer dans le périmètre, le budget et les critères de clôture du projet qui le remplace — non comme une phase ultérieure, mais comme la condition qui termine le projet. Un projet de migration qui s’achève lorsque le nouveau système fonctionne n’a pas migré : il a dupliqué, et il laisse derrière lui une facture que personne ne portera. La règle propre est brutale mais saine : le projet est fini quand l’ancien est éteint, pas quand le nouveau est allumé. Elle change le chiffrage et déplace l’arbitrage du sponsor — ce qui est précisément la raison pour laquelle elle est si souvent écartée.

Faire décroître un parc existant

Reste le cas ordinaire : hériter d’un parc constitué, avec ses systèmes résiduels et sans aucune de ces clauses.

La première décision est de ne pas commencer par le plus gros. On commence là où le rapport entre l’effort et la contrainte libérée est le meilleur, et surtout là où l’on apprendra : un premier retrait mené jusqu’au bout établit la méthode et, plus important, démontre à l’organisation que c’est possible. Tant que ce précédent n’existe pas, chaque candidat suivant paraîtra trop risqué.

Ensuite, il faut classer les systèmes résiduels selon la raison pour laquelle ils tournent encore, car chaque raison appelle un traitement différent. S’il subsiste un usage métier réel, c’est une migration fonctionnelle : un projet, à instruire comme tel. Si le système n’est plus qu’un moyen d’accéder à des données, ce n’est pas un problème applicatif mais un problème d’archivage, et la réponse est l’extraction, pas la perpétuation. S’il alimente encore une interface, c’est une substitution de producteur. Et s’il ne subsiste aucun usage identifié mais qu’on le maintient par précaution, alors il ne manque rien d’autre qu’une décision — et quelqu’un pour la prendre.

Ce dernier cas, le plus fréquent, se traite par l’extinction annoncée : publier une date de retrait, notifier les consommateurs identifiés, puis interrompre le service de façon réversible avant de l’arrêter définitivement. Une coupure programmée, annoncée, conduite hors période sensible et avec un plan de reprise, est le seul moyen fiable de découvrir un usage que personne n’a déclaré. Elle fait apparaître les utilisateurs silencieux en quelques heures, là où six mois de sollicitations écrites n’auront produit aucune réponse.

Deux règles complètent le dispositif. La première : le silence vaut accord. Une demande de retrait adressée aux consommateurs identifiés, assortie d’un délai, sans réponse au terme de ce délai, est un accord — faute de quoi le processus reste otage de ceux qui ne répondent pas. La seconde : rendre visible la capacité libérée. Si les économies se dissolvent dans le budget d’exploitation général, personne ne financera le retrait suivant. Rattacher explicitement ce qui est libéré — licences, infrastructure, et surtout temps d’équipe — au prochain retrait est ce qui rend la démarche auto-entretenue.

Les indicateurs suivent la même logique. Le nombre d’applications décommissionnées, seul, ne dit rien. Ce qui informe : combien de systèmes n’ont pas de propriétaire capable d’en décider l’arrêt, combien ne tournent plus que pour donner accès à des données, combien reposent sur un socle technique hors support, et — l’indicateur le plus honnête — combien de systèmes sont sortis du parc cette année, comparé à combien y sont entrés.

Ce que l’architecture doit tenir

Le rôle de l’architecture ne consiste pas à conduire les retraits, mais à rendre possible qu’ils soient décidés.

Cela suppose de tenir la règle de la clause de sortie à chaque mise en service ; de maintenir les informations de propriété et de dépendance à un niveau de fraîcheur qui permette de cadrer un retrait en quelques jours plutôt qu’en quelques mois ; d’arbitrer la file des retraits comme un portefeuille, avec une priorité assumée, plutôt qu’au cas par cas ; et d’exiger de chaque projet de remplacement que l’extinction figure dans son périmètre.

C’est aussi de contredire, chaque fois qu’elle est prononcée, la phrase qui protège les systèmes résiduels : « de toute façon, il ne coûte presque rien ». Aucun système ne coûte rien. Chacun prélève de l’attention, et l’attention est la ressource la plus rare d’une direction des systèmes d’information.

Arrêter est une capacité

La capacité d’une organisation à se transformer se mesure autant à ce qu’elle sait arrêter qu’à ce qu’elle sait lancer. Un parc qui ne fait que croître décrit une organisation qui consacre une part croissante de ses moyens à entretenir des décisions prises par des gens qui sont partis, pour des raisons que plus personne ne peut restituer.

Le décommissionnement n’est ni une opération d’hygiène ni une tâche de fin de projet. C’est le moment où l’organisation récupère une capacité qu’elle avait prêtée sans terme. Et comme toute décision d’architecture, il ne coûte presque rien lorsqu’il est pris au bon moment — à la mise en service, en une clause — et devient un projet lorsqu’il est pris avec dix ans de retard.