Cas d'usage — Migration ERP & legacy
Quitter un entrepôt legacy sans éteindre la lumière.
Beaucoup d'applications restent allumées des années après leur remplacement, parce que personne n'ose perdre ce qu'elles contiennent. La question n'est pas technique : c'est une question de continuité et de preuve. Tant que l'organisation ne peut pas démontrer que l'historique est repris et cohérent, elle ne coupe rien.
La situation
Pourquoi l'ancien système reste allumé
Les licences continuent, les compétences s'en vont, et quelques fois par an un contrôle ou un litige oblige à retrouver une information dans un système que plus personne n'exploite au quotidien.
La difficulté ne vient pas de l'extraction des données, mais de tout ce qui l'entoure : savoir ce qui doit être conservé et pour combien de temps, garantir que les rapports en place continuent de fonctionner pendant la reprise, et être capable d'expliquer un écart entre l'ancien et le nouveau. Sans ces trois éléments, la décision d'extinction est indéfiniment reportée.
La méthode
Cinq étapes, un domaine à la fois
La progression est la même à chaque domaine. Ce qui change, c'est la difficulté : on commence par un périmètre à valeur réelle et à complexité maîtrisée.
- 01
Cartographier et prioriser
Inventaire des sources, des rapports et de leurs consommateurs. On identifie les domaines à plus forte valeur métier dont la complexité reste maîtrisable.
- 02
Construire le Raw Vault du domaine
Les sources concernées sont intégrées et historisées telles quelles, sans perturber immédiatement le reporting existant, qui continue de tourner sur l'ancienne chaîne.
- 03
Reconstruire les marts et réconcilier
Les indicateurs sont recalculés depuis le vault et comparés à ceux de l'environnement legacy. Les écarts sont rendus visibles et expliqués, jamais masqués.
- 04
Déplacer les consommateurs progressivement
Rapports et utilisateurs basculent une fois les nouveaux résultats revus et acceptés par le métier. L'ancienne chaîne reste disponible pendant la période convenue.
- 05
Décommissionner et enchaîner
Le domaine legacy n'est arrêté que lorsque la nouvelle chaîne de données est fiable. L'équipe passe alors au domaine suivant, avec la démarche déjà éprouvée.
Ce que vous obtenez
Un historique consultable, une réponse traçable, et un système de moins à maintenir.
Les données reprises restent interrogeables par les sorties construites pour cet usage, sans redémarrer l'application d'origine. Le lignage et la documentation permettent d'expliquer d'où vient une information et comment elle a été transformée.
Une fois la chaîne validée, l'ancien système peut être arrêté, avec la charge d'exploitation et l'exposition au risque qui l'accompagnaient. Le périmètre repris est un choix explicite, arrêté selon les obligations de conservation et les usages réels.
Questions fréquentes
Ce que les équipes nous demandent
Faut-il tout reprendre ?
Non, et c'est la première décision à prendre. Le périmètre est arrêté selon les obligations de conservation et les usages réels, pas par principe de précaution.
Comment démontrer que la reprise est cohérente ?
Par des contrôles de comptage et de cohérence entre le système source et la plateforme, documentés et rejouables. C'est cette preuve qui permet la décision d'extinction.
Peut-on traiter plusieurs applications ?
Oui, l'une après l'autre. Les entités métier communes sont rapprochées par leurs clés métier, ce qui évite de reconstruire un silo par application.
Est-ce lié au remplacement de l'ERP lui-même ?
Les deux se combinent souvent : le nouveau système porte les processus, la plateforme porte l'historique. Ce sont deux chantiers distincts qu'il vaut mieux ne pas confondre.
Étape suivante