Supprimer avant de migrer : le gain le moins cher d'un projet data

Quand une DSI décide de migrer son décisionnel, le réflexe est de compter les objets à transposer et de multiplier par un coût unitaire. C'est un calcul qui suppose que tout mérite d'être migré. Dans la pratique, ce n'est jamais le cas.

Pourquoi les flux morts s'accumulent

Personne ne supprime jamais rien, pour une raison rationnelle : le coût d'une suppression erronée est visible et immédiat — un rapport casse, un directeur appelle — tandis que le coût de la conservation est invisible et étalé. L'arbitrage individuel est donc toujours de conserver.

Le résultat s'accumule sur dix ou quinze ans. Des flux alimentent des tables qui alimentent des rapports que plus personne n'ouvre. Des extractions ont été créées pour un projet terminé depuis longtemps. Des doublons existent parce que deux services ont demandé la même chose à six mois d'écart.

Comment identifier ce qui est mort

Ne demandez pas aux équipes. Interrogées, elles répondent par prudence que tout est utile, et elles ont raison de le faire : elles n'ont pas les moyens de vérifier.

La méthode fiable est l'analyse des journaux d'accès sur douze mois glissants. Trois sources suffisent :

1. Les journaux de l'outil de restitution. Quels rapports ont été ouverts, par combien de personnes distinctes, à quelle fréquence.
2. Les journaux de la base. Quelles tables ont été interrogées en dehors des traitements d'alimentation.
3. L'ordonnanceur. Quels jobs sont encore planifiés, lesquels échouent silencieusement depuis des mois sans que personne ne le signale — un excellent indicateur d'absence de consommateur.

Un rapport ouvert zéro fois en douze mois, alimenté par un flux dont aucune table n'est interrogée par ailleurs, est mort. Ce n'est pas une opinion, c'est une observation.

Le protocole de suppression qui rassure

La difficulté n'est pas technique, elle est politique. Personne ne veut signer la suppression.

Un protocole en trois temps lève l'objection :

Étape 1 — la mise en sommeil. Le flux est désactivé mais conservé, avec une alerte qui remonte si quelqu'un cherche à accéder aux tables concernées. Durée : deux à trois mois, incluant une clôture comptable si le domaine est financier.

Étape 2 — la notification. Une liste nominative des flux en sommeil est envoyée aux responsables de domaine, avec un délai d'opposition écrit. L'absence de réponse vaut accord — c'est ce point qui débloque le processus.

Étape 3 — l'archivage puis la suppression. Le code du flux est archivé dans un dépôt dédié, les tables sont exportées une dernière fois, puis tout est supprimé. L'archive rend la décision réversible pendant un an, ce qui suffit à faire accepter la démarche.

Ce que cela change sur le projet

Sur un patrimoine de quelques centaines de jobs, il n'est pas rare d'en écarter un tiers. L'effet est triple : le coût de la migration baisse dans la même proportion, la fenêtre de traitement nocturne se libère, et la nouvelle plateforme démarre sans hériter d'une dette qu'elle traînerait dix ans.

C'est aussi, accessoirement, le seul argument commercial qui consiste à réduire volontairement le montant d'un projet. Un prestataire qui vous propose cette étape vous dit quelque chose sur sa façon de travailler.