ARCHITECTURE
Arrêter un ancien système de données après une migration se prépare dès le cadrage : une date d'arrêt, un responsable désigné et l'inventaire des usages résiduels. L'arrêt avance ensuite par paliers : passage en lecture seule, redirection des utilisateurs, suspension test des traitements, retrait des accès, archivage des données à conserver, résiliation des contrats, puis suppression.
La bascule vers la nouvelle plateforme a eu lieu et la recette est signée. Pourtant, l'ancien entrepôt de données tourne encore : ses traitements nocturnes s'exécutent, ses licences sont renouvelées et quelques équipes continuent de s'y connecter. Personne n'a décidé de le garder. Personne n'a décidé de l'arrêter non plus.
Cette situation est l'une des plus fréquentes à l'issue d'une migration de données. Elle résulte rarement d'un oubli : elle découle d'une série de précautions légitimes, chacune raisonnable lorsqu'on la considère isolément. Mises bout à bout, ces précautions maintiennent en fonctionnement un système dont plus personne n'a la charge.
L'arrêt d'un ancien système est souvent perçu comme une formalité technique, à traiter une fois la migration terminée. La réalité est inverse. Le décommissionnement est un projet à part entière, avec ses décisions, ses risques et ses interlocuteurs : la direction juridique pour la conservation des données, les achats pour les contrats, les métiers pour les usages résiduels, la sécurité pour les accès.
Tant que l'ancien système n'est pas arrêté, la migration n'a produit qu'une partie de ses bénéfices : les coûts de deux environnements s'additionnent et la nouvelle plateforme ne devient jamais tout à fait la référence. Réussir l'arrêt demande de le préparer bien avant la bascule, puis de le conduire étape par étape.
Arrêter un ancien système de données ne se résume pas à éteindre un serveur. L'opération porte sur l'ensemble de ce qui entoure le système : les données qu'il contient, les traitements qu'il exécute, les rapports qu'il produit, les personnes qui y ont accès et les contrats qui le font fonctionner. Chacun de ces éléments demande une décision distincte, prise par la bonne personne.
Le décommissionnement d'un système de données consiste à le retirer du service de façon contrôlée, en garantissant que rien d'utile ne disparaît avec lui. Les données qui doivent être conservées sont archivées, les usages encore actifs sont transférés, les accès sont fermés et les coûts associés s'arrêtent. Un système décommissionné ne produit plus rien, ne coûte plus rien et ne peut plus être modifié par personne.
Cette définition exclut le système mis en veille, dont les serveurs tournent toujours au cas où, comme le système dont les accès ont été coupés sans archivage ni résiliation : ce dernier ne sert plus à personne, mais il continue de coûter et de détenir des données qui ne sont plus gouvernées.
Le coût d'un ancien système maintenu après la migration est d'abord financier : licences, hébergement, support de l'éditeur et temps des équipes d'exploitation. Prévu pendant la double exécution, ce cumul devient une dépense sans contrepartie après la bascule.
Le coût le plus lourd se situe pourtant ailleurs. Un ancien système encore accessible reste une source de chiffres concurrente de la nouvelle plateforme. Des utilisateurs y extraient des données, les retravaillent dans un tableur et les présentent en réunion, alors que la nouvelle plateforme affiche d'autres valeurs. Deux systèmes qui produisent deux chiffres différents suffisent à ruiner la confiance construite pendant la recette.
S'y ajoute un risque de sécurité. Un système qui n'est plus suivi ne reçoit plus toujours les correctifs, ses comptes ne sont plus revus et les données personnelles qu'il contient échappent aux règles appliquées sur la nouvelle plateforme.
👉 À lire aussi : Migrer ses données vers le cloud : par quoi commencer et que laisser en place ?
Les anciens systèmes de données ne restent pas en service par négligence, mais parce que leur arrêt soulève des questions auxquelles personne n'a préparé de réponse. Quatre causes reviennent presque toujours.
La première cause est la crainte qu'une information présente dans l'ancien système fasse défaut un jour. Un historique antérieur à la période migrée, un champ qui n'a pas été repris, une table que personne n'a su interpréter : tant que le système tourne, ces données restent accessibles en théorie. L'arrêter revient à accepter de ne plus pouvoir les consulter comme avant.
Cette crainte est fondée, mais garder tout le système en fonctionnement constitue une mauvaise réponse. La bonne réponse est une décision explicite, prise donnée par donnée : migrer, archiver ou supprimer.
La deuxième cause tient aux usages que l'inventaire initial n'a pas repérés. Un export mensuel déposé sur un partage réseau pour un prestataire externe, une requête lancée chaque trimestre par le contrôle interne, un fichier tableur connecté directement à une table de l'entrepôt : ces usages ne figurent dans aucune documentation, et ils apparaissent souvent au moment où l'on parle d'arrêter le système.
Ces usages cachés relèvent souvent de la dette analytique accumulée au fil des années : des extractions et des rapports créés pour un besoin ponctuel, puis maintenus par habitude. Leur existence ne justifie pas de garder l'ancien système. Elle impose en revanche de les identifier avant l'arrêt et de décider, pour chacun, s'il doit être reproduit sur la nouvelle plateforme ou abandonné.
La troisième cause est l'absence de date. Beaucoup de plans de migration détaillent le calendrier de bascule, puis citent l'arrêt de l'ancien système comme une étape finale, sans échéance. Sans date, il n'y a ni urgence, ni arbitrage, ni budget dédié.
Une date d'arrêt change la nature des discussions : les utilisateurs doivent signaler leurs usages avant l'échéance, les équipes techniques planifient l'archivage et les achats anticipent les préavis de résiliation. Sans échéance écrite, chaque demande de report est acceptée par défaut, puisque rien ne s'y oppose.
La quatrième cause est l'absence de responsable. L'équipe de migration est réaffectée après la bascule, l'exploitation fait tourner ce qu'on lui a confié et les métiers considèrent que la question est technique. Personne n'a reçu le mandat d'arrêter le système, ni l'autorité nécessaire pour refuser une demande de prolongation.
Cette absence pèse d'autant plus que l'arrêt touche plusieurs directions : propriétaires métier, achats, protection des données. Sans pilote identifié, aucune de ces décisions n'est provoquée, et l'ancien système reste en place faute d'arbitrage.
L'arrêt d'un ancien système se prépare au moment où la migration est cadrée, et non après la bascule. Les trois décisions qui conditionnent sa réussite (une date, un responsable, un inventaire des usages résiduels) sont plus faciles à prendre au démarrage du projet, quand il dispose d'un budget et que l'attention de la direction est encore mobilisée.
La date d'arrêt de l'ancien système doit figurer dans le plan de migration au même titre que la date de bascule. Elle se fixe en tenant compte de la durée de double exécution prévue, des échéances contractuelles (fin de licence, fin du contrat d'hébergement, préavis de résiliation) et des périodes sensibles pour les métiers, comme une clôture annuelle.
Cette date n'a pas besoin d'être définitive dès le cadrage, mais elle doit être écrite, partagée et suivie en comité de pilotage. Tout report fait l'objet d'une décision explicite, avec une raison et une nouvelle échéance. Une date d'arrêt qui glisse sans décision est le premier signe d'un ancien système qui va durer.
Le responsable du décommissionnement porte l'arrêt de bout en bout : il tient le calendrier, collecte les décisions, instruit les demandes de prolongation et vérifie que chaque étape est réalisée. Ce rôle peut être confié au chef de projet de migration, à condition que sa mission ne s'arrête pas à la bascule, ou à un responsable de l'exploitation doté d'un mandat clair.
Le responsable du décommissionnement s'appuie sur les propriétaires métier des données, qui valident ce qui doit être archivé ou supprimé, et sur les équipes techniques, qui exécutent les opérations. La distinction entre les rôles de gouvernance (propriétaire, gestionnaire et gardien des données) offre un cadre utile pour attribuer chaque décision à la bonne personne.
L'inventaire des usages résiduels recense tout ce qui dépend encore de l'ancien système à l'approche de la bascule. Il complète l'inventaire réalisé au début de la migration, qui portait sur les usages à transférer, en se concentrant sur ce qui risque d'avoir été oublié.
Plusieurs sources permettent de reconstituer ces usages résiduels, et elles se complètent :
Chaque usage identifié reçoit ensuite une décision : transféré sur la nouvelle plateforme, remplacé par un autre moyen ou abandonné avec l'accord de son utilisateur. Un usage résiduel sans décision suffit à bloquer l'arrêt, car il devient l'argument de chaque demande de report.
Le décommissionnement d'un système de données se conduit par paliers successifs. Chaque palier réduit ce que l'ancien système permet de faire, tout en laissant la possibilité de revenir en arrière tant que l'étape suivante n'a pas été franchie. Cette progressivité limite le risque : une erreur de recensement est détectée pendant un palier réversible, et non après la suppression.
Quatre paliers structurent cette réduction progressive. Le système passe d'abord en lecture seule, puis ses accès sont retirés, ses données utiles sont archivées et il est enfin arrêté. À chaque palier, une part de l'ancien système disparaît, jusqu'à ce qu'il ne reste plus que l'archive.
Ces quatre paliers se déclinent en sept étapes opérationnelles, qui s'enchaînent dans un ordre précis. Les trois premières préparent le retrait des accès, les quatre suivantes conduisent à l'arrêt définitif.
Le gel en lecture seule est la première étape de l'arrêt. À partir de la date de gel, plus aucune donnée n'est saisie, modifiée ou chargée dans l'ancien système. Les utilisateurs peuvent encore consulter les informations, mais toute production de nouvelles données a lieu sur la nouvelle plateforme.
Ce gel supprime le risque de divergence entre les deux environnements et fait apparaître les usages oubliés : un utilisateur qui ne peut plus enregistrer une opération se manifeste immédiatement. Le gel rend visibles les dépendances non recensées à un stade où il est encore simple de les traiter.
La redirection des utilisateurs consiste à remplacer, pour chaque usage, le point d'accès à l'ancien système par son équivalent sur la nouvelle plateforme. Les liens vers les anciens rapports renvoient vers les nouveaux tableaux de bord, les connexions des fichiers tableurs pointent vers la nouvelle source et les exports automatiques sont reconstruits à partir de celle-ci.
La redirection est aussi l'occasion de ne pas tout reproduire : un rapport que personne n'a consulté depuis des mois n'a pas besoin d'équivalent. Les directions qui ont constaté que multiplier les tableaux de bord nuit au pilotage trouvent là un moment favorable pour réduire leur nombre.
La suspension test des traitements vérifie qu'aucun traitement de l'ancien système n'est encore indispensable. Les tâches planifiées (chargements, calculs, exports) sont désactivées sans être supprimées, pendant une période définie à l'avance. Si un utilisateur ou une application réclame un résultat, le traitement peut être réactivé rapidement et l'usage correspondant est traité.
La durée de la suspension dépend du rythme des usages. Quelques semaines suffisent pour des traitements quotidiens ou hebdomadaires. Une suspension de cette durée ne détecte pas, en revanche, un traitement qui ne sert qu'à la clôture annuelle. Pour les traitements à périodicité longue, l'inventaire et les entretiens avec les métiers restent la seule protection fiable.
Le retrait des accès intervient une fois que les usages ont été redirigés et que la suspension test n'a révélé aucun besoin non couvert. Les comptes utilisateurs sont désactivés, les connexions applicatives sont fermées, et seule l'équipe chargée de l'archivage conserve un accès technique, limité et tracé.
Ce retrait relève de la sécurité des données autant que de la conduite du projet. Un système dont les comptes restent ouverts sans être revus constitue une porte d'entrée vers des données que plus personne ne surveille. Retirer les accès avant d'archiver garantit que chaque accès restant pendant l'opération est connu et justifié.
L'archivage extrait de l'ancien système les données qui doivent être conservées, sous une forme qui reste lisible sans lui. Il porte sur les données soumises à une obligation légale de conservation, sur les historiques utiles à l'activité et, le cas échéant, sur les éléments nécessaires pour justifier les chiffres produits par le passé.
L'archive est vérifiée avant toute étape suivante : volumes extraits comparés aux volumes d'origine, lecture d'un échantillon par un utilisateur métier, test de restitution d'une donnée précise. Une archive jamais relue n'offre aucune garantie le jour où une donnée est réclamée.
La résiliation des contrats et des licences met fin aux coûts de l'ancien système. Elle concerne les licences logicielles, les contrats de support et de maintenance, l'hébergement, et parfois des services annexes comme la sauvegarde externalisée ou la supervision. Chaque contrat a ses propres conditions : durée d'engagement, préavis, date anniversaire.
La date d'arrêt doit donc être connue des achats très tôt. Le calendrier de l'arrêt se construit à partir des échéances contractuelles, et non l'inverse.
La suppression est la dernière étape, et la seule irréversible. Elle porte sur les serveurs ou les instances et sur les bases de données, mais aussi sur toutes les copies qui en dérivent : sauvegardes, environnements de recette et de développement, extractions stockées sur des partages réseau. Une copie oubliée reste une copie de données personnelles ou sensibles, soumise aux mêmes obligations que l'original.
La suppression intervient après validation écrite des propriétaires métier et, pour les données personnelles, après avis du délégué à la protection des données. Elle est consignée dans un procès-verbal qui liste ce qui a été supprimé, ce qui a été archivé, à quelle date et sous quelle autorité. Ce document répond par avance aux questions d'un audit futur.
Chaque type d'élément de l'ancien système appelle une décision différente au moment de l'arrêt, avec un point de vigilance qui lui est propre. Les données de référence, les historiques, les traitements, les rapports et exports, les accès utilisateurs ainsi que les contrats et licences ne se traitent pas de la même manière.
| Élément | Décision à l'arrêt | Point de vigilance |
|---|---|---|
| Données de référence | Migrées sur la nouvelle plateforme si elles servent encore, sinon archivées avec leurs codes et leurs définitions. | Des codes ou des statuts anciens, absents de la nouvelle plateforme, rendent les historiques illisibles s'ils ne sont pas archivés avec eux. |
| Historiques | Archivés dans un format ouvert, avec une durée de conservation fixée pour chaque catégorie de données. | Les données personnelles ne se conservent pas par précaution : chaque durée repose sur une obligation ou une finalité identifiée. |
| Traitements | Suspendus à titre de test, puis reproduits sur la nouvelle plateforme s'ils sont réclamés, supprimés dans le cas contraire. | Un traitement annuel, utilisé seulement lors d'une clôture, échappe à une suspension de quelques semaines. |
| Rapports et exports | Redirigés vers leur équivalent sur la nouvelle plateforme, ou abandonnés avec l'accord de leurs destinataires. | Les exports envoyés à des partenaires externes figurent rarement dans l'inventaire et doivent être recherchés. |
| Accès utilisateurs | Retirés une fois les usages redirigés, à l'exception d'un accès technique limité et tracé pour l'archivage. | Les comptes de service et les connexions applicatives se ferment aussi, pas seulement les comptes nominatifs. |
| Contrats et licences | Résiliés selon un calendrier construit à partir des échéances et des préavis de chaque contrat. | Un préavis manqué entraîne le renouvellement d'un contrat pour une période entière. |
L'archivage des données conditionne la possibilité d'arrêter l'ancien système. Tant que l'organisation ne sait pas ce qu'elle doit garder, sous quelle forme et pendant combien de temps, elle garde tout, et elle le garde dans l'ancien système. Répondre à ces trois questions, puis organiser la consultation de l'archive, lève le principal obstacle à l'arrêt.
Les données à conserver après l'arrêt d'un système se répartissent en trois catégories, qui n'obéissent pas aux mêmes logiques :
Les données qui n'entrent dans aucune de ces catégories ont vocation à être supprimées. Archiver sans trier revient à déplacer le problème de l'ancien système vers un nouveau stockage, sans le résoudre.
La forme de l'archive doit garantir que les données restent lisibles sans l'ancien système ni son logiciel. Un export dans le format propriétaire d'un éditeur dont la licence va être résiliée ne remplit pas cette condition. Les formats ouverts et documentés (fichiers à plat, formats tabulaires standard, bases de données ouvertes) sont préférables, parce qu'ils resteront lisibles quand les outils actuels auront disparu.
Les données seules ne suffisent pas à constituer une archive exploitable. L'archive doit aussi contenir les métadonnées qui permettent de comprendre les données : description des tables et des champs, signification des codes, règles de calcul, période couverte, date d'extraction. Une table de factures archivée sans le dictionnaire de ses codes de statut est conservée sur le plan technique, mais inutilisable en pratique.
Le support de stockage de l'archive se choisit en fonction d'une fréquence de consultation généralement faible. L'archive bénéficie en revanche des mêmes protections que les données courantes : chiffrement, contrôle des accès, journalisation des consultations.
La durée de conservation des données archivées n'est pas uniforme. Elle dépend de la nature de chaque donnée et des textes qui s'y appliquent : obligations comptables et fiscales, droit du travail pour les données de paie, réglementations sectorielles dans la banque, l'assurance ou la santé, délais de prescription applicables aux contrats. Une même archive contient donc souvent des données soumises à des durées différentes.
Le RGPD ajoute un principe transversal pour les données personnelles : elles ne peuvent pas être conservées plus longtemps que nécessaire au regard de la finalité pour laquelle elles ont été collectées. Archiver des données personnelles par simple précaution, sans finalité ni obligation identifiée, est contraire à ce principe. La question rejoint celle, plus large, des conditions pour rester conforme au RGPD dans l'ensemble des usages de données de l'entreprise.
La méthode la plus sûre consiste à établir, avec la direction juridique et le délégué à la protection des données, une durée de conservation par catégorie de données archivées, en citant le texte qui la fonde. Chaque catégorie reçoit une date de fin de conservation, à l'issue de laquelle ses données sont supprimées de l'archive. Sans cette date, l'archive devient à son tour un stock de données sans fin de vie.
La consultation de l'archive doit rester possible, mais exceptionnelle : contrôle fiscal, audit, litige ou analyse historique ponctuelle. Cette rareté justifie une procédure encadrée plutôt qu'un accès permanent.
La procédure de consultation de l'archive précise plusieurs points, à définir avant l'arrêt du système :
Une archive que personne ne sait consulter pousse les utilisateurs à réclamer le maintien de l'ancien système. La procédure de consultation fait partie des conditions de l'arrêt, au même titre que l'archive elle-même.
L'arrêt d'un ancien système de données se joue autant auprès des utilisateurs que sur les serveurs. Certains utilisateurs travaillent avec le même outil depuis des années, en connaissent tous les écrans et ont construit autour de lui leurs propres fichiers et habitudes de travail. Leur retirer cet outil sans accompagnement produit des contournements, des demandes de report et une défiance durable envers la nouvelle plateforme.
L'annonce de l'arrêt intervient dès que la date est fixée, puis elle est rappelée à chaque palier : avant le gel en lecture seule, avant le retrait des accès, avant la suppression. Chaque message précise ce qui change pour l'utilisateur, à quelle date et vers qui se tourner en cas de difficulté. Un utilisateur qui découvre l'arrêt le jour où son accès est coupé le vit comme une décision imposée.
Les messages gagnent à être relayés par les responsables métier. Un directeur commercial qui annonce à ses équipes que le nouveau tableau de bord devient la seule référence obtient une adhésion qu'aucune note technique n'obtiendra.
La formation des utilisateurs porte sur les équivalents concrets de leurs usages : où trouver le chiffre qu'ils consultaient chaque lundi, comment refaire l'export qu'ils envoyaient chaque mois. Une formation générale à la nouvelle plateforme ne répond pas à ces questions précises.
Lorsque la migration a corrigé une règle de calcul ancienne, l'utilisateur doit savoir pourquoi le nouveau chiffre diffère de l'ancien et qui a validé la correction. Un écart expliqué renforce la confiance dans la nouvelle plateforme, alors qu'un écart découvert par l'utilisateur seul la détruit.
Les demandes de prolongation de l'ancien système sont inévitables à l'approche de l'arrêt. Certaines sont fondées : un usage réel a été oublié, ou la nouvelle plateforme ne couvre pas encore un besoin. D'autres traduisent une simple réticence au changement. Le responsable du décommissionnement les instruit une par une, avec une règle simple : toute demande précise l'usage concerné, son utilisateur et la date à laquelle l'équivalent sera disponible.
Une prolongation accordée porte sur un usage précis, pour une durée limitée, et non sur l'ensemble du système, dont l'arrêt se poursuit selon le calendrier prévu.
Certains signaux indiquent qu'un ancien système de données reste en service bien après la fin de son utilité. Ils sont faciles à repérer pour qui les cherche, et chacun justifie de reprendre le sujet en comité de pilotage :
Chacun de ces signaux appelle la même réponse : reprendre les trois décisions du cadrage, à savoir une date ferme, un responsable mandaté et une liste complète des usages résiduels, chacun assorti d'une décision. La même logique s'applique à tout dispositif qui continue de fonctionner sans justification, et savoir quand arrêter un cas d'usage relève du même arbitrage entre coût, valeur et risque.
Une migration de données se juge souvent à la qualité de sa bascule. Elle devrait aussi se juger à la disparition du système qu'elle remplace, faute de quoi l'organisation paie deux environnements et laisse une partie de ses données hors de toute gouvernance.
L'arrêt ne demande pas de méthode sophistiquée. Il demande des décisions prises tôt et tenues dans la durée : une date inscrite dans le plan de migration, un responsable doté d'un mandat, un inventaire des usages résiduels, une archive testée et une procédure pour la consulter. Ces décisions coûtent peu au moment du cadrage, alors que leur absence se paie chaque mois après la bascule.
Pour un ancien système déjà maintenu au-delà de la bascule, la démarche reste la même : fixer une date, désigner un responsable, recenser ce qui dépend encore du système, puis franchir les paliers dans l'ordre, de la lecture seule jusqu'à la suppression.
L'arrêt d'un ancien système de données se prépare dès le cadrage de la migration, avec une date, un responsable et un inventaire des usages résiduels. Il se conduit ensuite par paliers successifs, du gel en lecture seule jusqu'à la suppression.
Le décommissionnement désigne l'ensemble des opérations qui retirent un système du service de façon définitive et documentée. Il garantit que rien d'utile ne disparaît avec le système et que ses coûts s'arrêtent.
Les anciens systèmes survivent rarement par oubli. Ils restent en service parce que leur arrêt soulève des questions auxquelles personne n'a préparé de réponse.
L'archive ne reprend pas tout le contenu de l'ancien système. Elle conserve les données qui répondent à une obligation, à un besoin d'activité ou à un besoin de preuve, et le reste est supprimé.
Il n'existe pas de durée unique. La durée de conservation dépend de la nature de chaque donnée et des textes qui s'y appliquent, et elle se fixe catégorie par catégorie avec la direction juridique et le délégué à la protection des données.
L'archive doit rester lisible sans l'ancien système ni son logiciel. Les formats ouverts et documentés sont donc préférables aux exports dans le format propriétaire d'un éditeur dont la licence va être résiliée.
Plusieurs signaux montrent qu'un ancien système reste en service au-delà de son utilité. Chacun justifie de reprendre le sujet en comité de pilotage.
L'arrêt doit être confié à un responsable du décommissionnement désigné dès le cadrage, dont la mission ne s'arrête pas à la bascule. Il ne décide pas seul et provoque les décisions des bons interlocuteurs.
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)