Étude de cas B — Moderniser un historique client sans réécrire le monde
Un produit B2B conserve l'historique client dans une application monolithique. Les équipes support et conformité utilisent des exports CSV produits chaque nuit. Le système est difficile à faire évoluer : les données sont partagées avec un portail client, les droits sont appliqués à plusieurs endroits et une personne est la seule à connaître la procédure de correction. Une nouvelle obligation exige qu'un client puisse obtenir un historique complet et traçable dans un délai court.
La réaction initiale est une réécriture : construire un nouveau service d'historique, migrer toutes les données, puis couper l'ancien système. L'analyse révèle cependant que la difficulté principale n'est pas le framework. Elle est dans le sens des événements, les accès de support, les anomalies historiques et l'exigence d'audit. Une réécriture déplacerait ces inconnues dans un programme de plusieurs mois, tout en laissant le monolithe continuer à évoluer.
Établir la carte de risque
L'équipe commence par trois parcours : consultation par un client, export de conformité et correction support. Elle identifie la source de chaque information, les règles de rétention, les droits nécessaires et les opérations manuelles. Plusieurs surprises apparaissent : certains événements sont écrasés au lieu d'être ajoutés ; l'export contient des colonnes interprétées par un script finance ; une correction support peut modifier l'affichage sans modifier l'audit.
La première décision n'est donc pas d'extraire un service. C'est de créer un contrat d'historique append-only à partir du monolithe, avec une identité d'événement, une date d'effet, une source, une version et les droits de lecture. Les anciennes données restent là où elles sont ; le nouveau contrat commence à recevoir les changements futurs.
| Inconnue dominante | Premier incrément | Signal de décision |
|---|---|---|
| Sens des événements | Publier en parallèle sans consommateurs critiques | Écarts entre audit actuel et projection |
| Droits de consultation | Nouveau portail interne de lecture seule | Tests d'autorisation et audit d'accès |
| Données historiques | Migrer un échantillon par période | Comptes, exceptions et qualité de recherche |
| Export finance | Contrat de sortie versionné | Comparaison des fichiers et consommateurs identifiés |
Créer une trajectoire de transition
Le monolithe continue d'être la source de vérité pour les enregistrements anciens. Une projection d'historique reçoit les nouveaux événements. Les deux sont comparés quotidiennement, non pour exiger une égalité naïve, mais pour classer les écarts : différence attendue de modèle, donnée corrompue, événement manquant, correction manuelle ou bug de projection.
L'équipe migre ensuite les données les plus récentes en petits lots. Chaque lot est idempotent, journalisé et associé à une file d'exceptions. Les anomalies ne sont pas simplement relancées : elles sont qualifiées avec Support et Conformité. Certaines données ne peuvent pas être transformées sans perdre leur valeur d'audit ; elles sont conservées en lecture dans l'ancien format avec une annotation explicite. Cette décision est préférable à une « correction » qui falsifierait l'histoire.
Faire évoluer les usages, pas seulement les données
Le nouveau portail est d'abord utilisé par une petite équipe support. L'objectif n'est pas de démontrer que l'écran existe, mais de vérifier que les personnes peuvent expliquer un dossier et corriger les exceptions sans revenir à l'expert historique. Les feedbacks mettent au jour des besoins de recherche et de libellés que le modèle technique n'avait pas anticipés. Ils sont traités avant d'étendre le portail, car ils conditionnent la capacité opérationnelle réelle.
L'export de conformité reste compatible pendant une période annoncée. Les consommateurs sont identifiés, la nouvelle version est mesurée et un outil de comparaison explique les différences. Lorsque l'usage de l'ancien export tombe à zéro et que les exceptions historiques sont sous un seuil accepté, l'équipe retire la double production. Elle conserve les traces nécessaires à l'audit, mais supprime les jobs et alertes qui ne servent plus.
À retenir
La modernisation réussie n'a pas commencé par un remplacement. Elle a stabilisé un contrat, rendu les données et droits observables, migré par lots réparables et accompagné les personnes qui font vivre le système. La nouvelle capacité est plus importante que la nouveauté de la pile : expliquer et fournir un historique fiable sans dépendre d'un unique monolithe ou expert.