Décommissionner une application : la checklist (dépendances d'abord)

Un décommissionnement d'application échoue rarement le jour où l'on éteint le serveur. Il échoue trois semaines plus tard, quand la clôture mensuelle trouve un répertoire vide ou qu'un reporting jamais recensé affiche des zéros. Le contrat est résilié, la machine virtuelle supprimée, et les dépendances n'apparaissent qu'à ce moment-là. Cette checklist inverse l'ordre habituel : les dépendances d'abord, les contrats et les serveurs en dernier.

TL;DR

• Les incidents qui suivent un décommissionnement viennent le plus souvent d'une dépendance que personne n'avait listée : un transfert de fichier, un reporting, un batch, un compte de service ou une chaîne de connexion codée en dur.
• Recensez toutes les dépendances entrantes et sortantes avant de fixer une date, puis faites signer la décision par un responsable métier et un responsable informatique nommés.
• Traitez les données comme une phase à part entière : migrer ce qui sert encore, archiver ce que la loi ou le métier impose, supprimer le reste de façon sécurisée et garder la preuve.
• Coupez d'abord de façon réversible, observez sur un cycle métier complet, puis supprimez définitivement et mettez à jour la cartographie.
• Téléchargez la checklist gratuite (PDF, ou XLSX avec un onglet par application) et remplissez-la pour chaque retrait.

Pourquoi les décommissionnements s'enlisent ou cassent quelque chose ?

Un décommissionnement s'enlise parce que personne ne porte la fin de vie de l'application, et il casse quelque chose parce que les dépendances sont découvertes en production plutôt que sur papier. Même racine : la décision se prend au niveau du portefeuille, la connaissance des dépendances est dispersée dans des têtes, des scripts et des tableurs.

L'enlisement est connu de toutes les DSI. Une revue de portefeuille classe une application en « Éliminer » ; deux ans plus tard elle tourne encore : un export trimestriel à reconstruire, un contrat en tacite reconduction, un chef de projet parti. Les coûts continuent de tomber, alors que c'est au retrait que se gagnent les économies d'une démarche de rationalisation du SI.

La casse est pire. La plupart des checklists partent du serveur (sauvegarder, arrêter, effacer) ou du contrat (résilier, récupérer les données), comme si l'on savait déjà ce qui parle à l'application. Dans une PME ou une ETI qui a grandi au fil des projets et des rachats, c'est rarement le cas, et les dépendances qui font mal ne sont documentées nulle part : un fichier déposé chaque nuit dans un partage, un tableur branché sur la base, un script sur un autre serveur qui appelle l'API, un compte de service réutilisé.

Les six phases ci-dessous commencent par les dépendances, parce que toutes les suivantes dépendent de ce que la phase 1 aura trouvé.

Phase 1 : comment recenser toutes les dépendances avant de toucher à quoi que ce soit ?

On recense les dépendances en croisant le documenté (cartographie applicative, dossiers d'interface) et ce que révèlent les systèmes (journaux, ordonnanceurs, configurations), et en interrogeant les utilisateurs. Objectif : la liste de tout ce qui remarquerait la disparition de l'application demain matin.

Trois règles rendent cette phase fiable :

1. Observer, pas seulement lire la documentation. La cartographie dit ce qui a été déclaré ; les journaux disent ce qui se passe. Collectez les journaux d'accès sur une période qui couvre au moins une fin de mois et comparez-les aux flux déclarés : chaque connexion inexpliquée est une dépendance à instruire.
2. Interroger un niveau au-delà. Si l'application B reçoit un fichier de celle que vous retirez, demandez au responsable de B ce qu'il en fait. Chaque voisin direct doit confirmer qu'il a une solution de remplacement.
3. Associer une action à chaque dépendance. Pour chaque ligne : remplacer (par quel système, prêt à quelle date), supprimer (inutilisée, confirmé par qui) ou accepter (le responsable accepte de la perdre). Une dépendance sans action bloque le go/no-go.

Une cartographie applicative à jour couvre déjà les deux premières lignes ; la matrice des responsables d'applications donne les noms à appeler pour le reste. Côté métier, l'analyse d'impact des processus métier sur l'infrastructure montre quelles étapes de processus reposent sur l'application.

Faites-le à la main avec le modèle : téléchargez la checklist de décommissionnement (PDF) ou la version XLSX, un onglet par application. Ou tenez vos applications et vos flux dans un référentiel partagé, pour que le prochain retrait parte d'une cartographie à jour : le plan gratuit d'UrbaHive couvre 1 utilisateur et 25 applications, sans carte bancaire.

Phase 2 : qui porte la décision, et que veut dire « terminé » ?

Un décommissionnement a besoin de deux personnes nommées, pas de deux équipes : un responsable métier qui confirme que le métier peut se passer de l'application, et un responsable informatique qui répond de l'exécution. Ensemble, ils fixent dates et critères de réussite avant toute étape irréversible.

À consigner dans cette phase :

• Responsable métier : en général le directeur de la fonction qui finance ou utilise l'application. Il signe que chaque processus identifié en phase 1 a un remplacement ou une perte acceptée.
• Responsable informatique : le responsable actuel de l'application. Il porte le plan, la bascule et la suppression finale.
• Autres visas si nécessaire : RSSI (identités, secrets, destruction des données), DPO dès qu'il y a des données personnelles, achats ou contrôle de gestion pour les contrats.
• Dates : coupure, fin de la période d'observation, suppression définitive, fins de contrat (phase 4).
• Critères de réussite : par exemple « aucune connexion inexpliquée pendant l'observation », « tous les utilisateurs basculés », « archive validée par la comptabilité ».
• Déclencheur de retour arrière : quel type d'incident pendant l'observation fait redémarrer l'application.

Si personne n'accepte le rôle de responsable métier, c'est un constat : une application orpheline est souvent une bonne candidate au retrait, mais quelqu'un doit accepter le risque résiduel.

Phase 3 : que deviennent les données ?

Chaque jeu de données de l'application finit à l'un de ces quatre endroits : migré vers le système de remplacement, archivé pour des raisons légales ou métier, transmis à un autre responsable, ou supprimé de façon sécurisée. Décidez par catégorie de données, pas pour la base entière, et gardez la trace de chaque décision.

Dans l'ordre :

1. Inventorier les catégories de données : clients, transactions, documents, pièces jointes, journaux. Repérez celles qui contiennent des données personnelles.
2. Obtenir les durées de conservation : le juridique ou le responsable de l'archivage les fixe par catégorie, selon les règles comptables, fiscales, sociales et sectorielles. Exemple : le Code de commerce impose de conserver les documents comptables et pièces justificatives dix ans (article L123-22). Ne devinez pas les autres durées : demandez-les et notez leur fondement dans la checklist. Pour les données personnelles, les référentiels de durées de conservation de la CNIL sont un bon point de départ.
3. Migrer ce que le métier utilise encore vers l'application de remplacement, et faire valider un échantillon par un utilisateur clé après migration.
4. Archiver ce qui doit être conservé dans un format ouvert (CSV, PDF/A, export de base documenté), sur un stockage qui survivra à l'application, avec un responsable nommé. Pour les données personnelles, la doctrine de la CNIL distingue la base active de l'archivage intermédiaire : ce qui n'est gardé que pour une obligation légale n'est plus accessible qu'aux personnes habilitées. Une archive qui a besoin du logiciel retiré pour être lue n'est pas une archive.
5. Traiter les données personnelles : le principe de limitation de la conservation (article 5, paragraphe 1, point e, du RGPD) impose que les données dont vous n'avez plus besoin, et que rien ne vous oblige à garder, ne survivent pas au retrait dans une copie oubliée. Vérifiez aussi les demandes d'effacement en cours (droit à l'effacement, article 17).
6. Supprimer de façon sécurisée le reste, y compris réplicas, copies de recette et exports oubliés dans les partages. Pour un SaaS, exigez une confirmation écrite de l'éditeur ; chez vous, appliquez la politique de sécurité sur l'effacement des supports.

Sauvegardes : décidez si elles expirent d'elles-mêmes (à quelle date) ou doivent être purgées plus tôt.

Phase 4 : quels contrats et quelles licences résilier, et quand ?

Retrouvez chaque contrat lié à l'application, notez préavis et date de renouvellement, et résiliez assez tôt : rater une échéance de quelques jours peut coûter une période complète de plus.

À vérifier :

• Licence ou abonnement : durée, date de renouvellement, préavis, tacite reconduction.
• Maintenance et support : souvent un contrat distinct, parfois avec une autre échéance.
• Hébergement : serveurs dédiés, abonnements cloud et infogérance facturés pour cette seule application.
• Services tiers : middleware, supervision, certificats, noms de domaine utilisés par cette seule application.
• Conditions de sortie anticipée : pénalités, engagements minimaux.
• Clauses de réversibilité et de suppression : ce que l'éditeur doit restituer, dans quel format, et comment il atteste la suppression. Cela renvoie à la phase 3.

Piège classique : le préavis échoit avant la coupure prévue. Résiliez à temps et négociez, si possible, une courte prolongation comme marge.

Phase 5 : comment conduire la bascule ?

Conduisez la bascule comme un changement planifié : un calendrier de communication, un gel, une coupure réversible et un retour arrière testé. Le but : pouvoir annuler la coupure en quelques heures si une dépendance oubliée se manifeste.

Le plan de retour arrière dit ce qui redémarre, qui le fait, en combien de temps, et quelles données saisies entre-temps devront être réconciliées. Testez-le avant le jour J. Le jour J, gardez le serveur, les données et la configuration intacts : la suppression définitive appartient à la phase 6.

Phase 6 : combien de temps attendre avant de supprimer définitivement ?

Gardez l'application coupée mais restaurable pendant au moins un cycle métier complet, puis supprimez-la définitivement, mettez à jour la cartographie et consignez les enseignements. Souvent, cela veut dire couvrir une clôture mensuelle ; si l'application touchait des activités trimestrielles, annuelles ou d'audit, l'observation doit inclure l'échéance concernée, ou une confirmation écrite qu'elle est traitée autrement.

Pendant la période d'observation :

• surveillez les tentatives d'accès : connexions refusées, batchs en échec sur d'autres serveurs, tickets au support ;
• traitez chaque alerte comme une dépendance oubliée en phase 1 : corrigez-la et ajoutez-la à la checklist ;
• gardez le retour arrière possible tant que les critères de réussite de la phase 2 ne sont pas atteints.

Clôture du décommissionnement :

1. Le responsable métier et le responsable informatique confirment que les critères de réussite sont atteints.
2. Suppression définitive des serveurs, comptes, secrets, certificats, entrées DNS et sauvegardes, comme décidé en phase 3.
3. Contrats confirmés comme terminés ; dernière facture contrôlée.
4. Mise à jour de la cartographie : passer l'application au statut retiré, supprimer ses flux, mettre à jour les applications voisines. Une cartographie qui montre encore une application retirée est une cartographie à laquelle on cesse de croire.
5. Un court retour d'expérience : dépendances oubliées, comment elles sont apparues, quoi vérifier plus tôt.

La checklist en un coup d'œil : phase, contrôles, responsable, preuve

Ce tableau est la colonne vertébrale du modèle téléchargeable.

Téléchargez la checklist PDF à imprimer, ou le modèle XLSX avec un onglet par application.

Comment UrbaHive aide à décommissionner ?

UrbaHive garde dans un référentiel partagé l'information dont la phase 1 a besoin. Il ne conduit pas le décommissionnement : le plan, les données et les contrats restent votre affaire.

• Flux : chaque flux a une application source, une cible, un type, une fréquence et un indicateur bidirectionnel. Le diagramme des flux applicatifs, généré à partir de ces fiches, s'exporte en PNG ou PDF pour la fiche de changement.
• Analyse d'impact : depuis une application, l'analyse d'impact affiche les objets directement liés, en amont et en aval, sur cinq couches (technique, applicative, fonctionnelle, métier, personnes) : le serveur qui l'héberge, son programme, les capacités qu'elle porte, les processus métier qui l'utilisent et les personnes responsables. Elle s'arrête à un niveau, ne suit pas les flux d'application à application (lisez-les dans les flux et le diagramme) et ne s'exporte pas : reportez ce que vous trouvez dans la checklist.
• Responsables : une personne responsable par application, plus des contacts complémentaires.
• Statuts et champs personnalisés : chaque organisation définit sa propre typologie de statuts (par exemple « En retrait » et « Retirée »), et des champs personnalisés peuvent porter une date cible, une date de préavis ou un verdict TIME. UrbaHive ne calcule ni score TIME ni coûts.
• Journal d'audit : chaque création, modification et suppression est enregistrée avec les valeurs avant et après : qui a changé le statut, qui a supprimé un flux. Consultable dans l'application, non exportable.
• Agents IA : via le connecteur MCP, un assistant comme Claude ou Cursor peut répondre à « quels flux touchent cette application ? » ou « quels processus l'utilisent ? » et, si vous activez l'écriture, mettre à jour son statut. Aucun outil MCP ne peut supprimer une application, un flux ou un autre objet de la cartographie.

UrbaHive est conçu pour les PME et ETI, de 50 à 5 000 collaborateurs environ, avec une prise en main en quelques heures. Le plan gratuit (1 utilisateur, 25 applications, sans carte bancaire, sans limite de durée) suffit pour cartographier une application et ses voisines. Les données sont hébergées dans l'Union européenne.

Questions fréquentes

Combien de temps doit durer la période d'observation ?

Le temps d'un cycle métier complet servi par l'application, soit en général au moins une clôture mensuelle. Si elle alimentait des traitements trimestriels, annuels ou d'audit, incluez l'échéance ou obtenez une confirmation écrite du responsable métier. C'est le traitement le plus rare qui fixe la durée.

Qui valide un décommissionnement ?

Le responsable métier signe que le métier peut se passer de l'application ; le responsable informatique signe que le retrait technique est terminé. Ajoutez le RSSI, le DPO et les achats quand c'est pertinent. Des personnes nommées, jamais des équipes.

Quelle est la cause d'échec la plus fréquente ?

Une dépendance non recensée : un transfert de fichier, un reporting, un batch ou un compte de service que personne n'avait déclaré et qui casse après la coupure. La deuxième, c'est l'enlisement : une application que tout le monde a décidé d'éliminer et qui continue de tourner parce que personne ne porte sa fin de vie.

Comment trouver les dépendances cachées ?

En comparant le documenté à l'observé : partez de la cartographie, lisez les journaux d'accès sur une fin de mois, vérifiez les ordonnanceurs de tous les serveurs, cherchez le nom d'hôte et les comptes de l'application dans les configurations et le coffre-fort de secrets, et interrogez les utilisateurs clés sur les tâches rares. Une coupure réversible attrape le reste.

Retirer une application avec la cartographie, pas contre elle

Faites-le à la main avec le modèle de checklist, ou laissez UrbaHive tenir à jour vos applications, vos flux et leurs responsables, pour que le prochain retrait parte d'une cartographie fiable. Plan gratuit : 1 utilisateur, 25 applications, sans carte bancaire. Créez votre compte gratuit.