Stratégie de migration : la décision qui n'est pas la bascule

Demandez à un programme quelle est sa stratégie de migration et on vous répondra big bang, ou par lots, ou en continu. C’est une stratégie de bascule. Elle répond à la question de savoir quand l’ancien système s’arrête et quand le nouveau démarre, et c’est une vraie question.

Elle ne répond pas à une autre question, qui détermine la forme des données avec lesquelles vous vivrez ensuite.

Cette question doit être posée avant de construire les règles. Elle est pourtant souvent tranchée implicitement, par un développeur sous contrainte de temps plutôt qu’en atelier : reprend-on le modèle de données source dans la cible, ou reconstruit-on la donnée pour le modèle cible ? Elle se tranche champ par champ, en silence, et le jour où quelqu’un la nomme, la réponse est déjà à moitié implémentée.

La bascule peut tenir dans une fenêtre courte ou organiser des mois de coexistence. Le choix du modèle, lui, se retrouve dans les usages et la maintenance pendant la vie du système. Les deux décisions méritent d’être explicites.

Les deux réponses, énoncées honnêtement

Reprendre la structure. Reproduire dans la cible l’organisation de la source, d’aussi près que la cible le permet. Des champs personnalisés là où la source en avait, les mêmes listes de codes, la même granularité. La cible est paramétrée pour accepter ce que vous avez déjà.

Reconstruire pour la cible. Prendre le modèle natif de la cible comme donné, et y remodeler la donnée source. Les codes sont remis aux standards de la cible, la granularité change là où les modèles diffèrent, et tout ce dont la cible n’a pas le concept doit aller quelque part ou disparaître.

En pratique, on combine souvent les deux. Le problème apparaît lorsque le mélange arrive par accident.

Reprendre la structure : ce que vous économisez et ce que vous héritez

L’attrait est réel et ne mérite pas d’être balayé. Les utilisateurs reconnaissent davantage leurs données. Certains états et repères peuvent être conservés, ce qui réduit une partie de la formation et des transformations. Ce gain se vérifie toutefois dans la cible : conserver un code source ne garantit ni le fonctionnement d’un état ni l’équivalence du processus. Les adaptations nécessaires peuvent absorber l’économie initiale.

Ce dont vous héritez est moins visible sur le moment :

• Les contournements viennent avec la donnée. Le champ utilisé pour autre chose que son nom, le code statut dont le sens a changé en 2016, le plan de numérotation qui a manqué de chiffres en 2019. Vous ne migrez pas des données, vous migrez vingt ans de compromis accumulés, et ils deviennent le point de départ du nouveau système.
• Les adaptations ont une facture. Lorsqu’une forme personnalisée empêche une fonction standard de fonctionner, il faut adapter le modèle ou la fonction. Les extensions retenues demandent de la maintenance et des vérifications lors des montées de version ; leur coût dépend aussi des mécanismes d’extension supportés par la cible.
• La décision devient coûteuse à revoir. Reconstruire plus tard peut demander une seconde migration sur un système en production, avec davantage de données et de dépendances. Ce n’est pas irréversible, mais ce coût doit être comparé à celui d’une reconstruction pendant le projet.

Reconstruire : le coût est réel et il arrive tôt

Reconstruire rapproche la donnée du modèle prévu par l’éditeur. Cela peut faciliter l’usage des fonctions standard et limiter certaines adaptations. Le paramétrage, les interfaces, la formation et les tests de montée de version restent à prévoir.

Une part importante de la facture arrive pendant le projet, sur des chantiers que le plan doit rendre visibles :

• Le volume d’arbitrage peut monter fortement. Les codes sans équivalent, changements de granularité, fusions ou divisions de concepts demandent des règles validées par le métier. Les cas que ces règles ne tranchent pas alimentent la file d’arbitrage à planifier, qui peut déplacer la date.
• Les utilisateurs perdent leurs repères. Une donnée qui paraît étrangère génère de la résistance pendant la recette, c’est-à-dire exactement au moment où vous avez besoin d’un métier impliqué et coopératif.
• L’historique devient plus difficile. Remodeler la donnée courante est faisable. Remodeler dix ans d’historique vers un modèle qui n’a jamais été conçu pour lui n’en vaut souvent pas la peine, ce qui pousse vers un archivage, décision distincte que l’on préfère généralement ne pas prendre.

L’hybride, et pourquoi il tourne mal

En pratique, beaucoup de programmes atterrissent quelque part au milieu : modèle standard là où c’est facile, structure source là où c’est coûteux. C’est une position légitime. Un risque fréquent est la manière dont elle se construit.

Elle est rarement décidée. Elle est accumulée.

Champ par champ, sous la pression du planning, celui qui écrit la règle cet après-midi-là prend l’option la moins chère. Six mois plus tard, le modèle est un patchwork que personne n’a conçu, où deux objets semblables suivent des logiques différentes parce qu’ils ont été construits des semaines différentes par des personnes différentes. Le programme peut alors cumuler des adaptations de montée de version et des états à reprendre, sans avoir choisi les bénéfices qu’il attendait de chaque approche.

Le remède est de rendre le partage explicite et écrit. Par exemple, pour un périmètre où ces choix ont été validés :

Les données de référence suivent le modèle cible. Les transactions ouvertes préservent les informations nécessaires à la continuité, avec des références, unités et statuts compatibles avec la cible. L’historique retenu pour l’archive reste consultable hors du système opérationnel. Toute dérogation demande une décision nommée.

Ce cadrage doit être complété par les mappings et les critères d’acceptation de chaque famille. Il ne permet pas de charger des transactions dans une structure source incompatible avec les référentiels cibles. Écrit ainsi, il donne au développeur à 18 h une règle et un responsable auxquels se référer.

Ce que l’audit tranche

Si cette décision ne peut pas être confirmée au lancement, c’est qu’il manque des faits. L’audit de données fournit trois mesures pour comparer les options :

• Quelle part de la source est déjà compatible avec le standard. Si 80 % de votre référentiel articles se projette proprement sur le modèle cible, l’effort de transformation se concentre sur les 20 % restants. Cela aide à le chiffrer ; les interfaces, les tests et les cas rares restent à évaluer.
• Combien d’arbitrages chaque option génère. Comparez les deux files de décisions : reconstruire peut en ajouter, mais conserver les particularités source peut aussi demander des arbitrages. Divisez le nombre de décisions par la capacité hebdomadaire totale convenue avec le métier pour obtenir une durée en semaines. Vérifiez ensuite la répartition par responsable, les dépendances et les disponibilités : la moyenne ne résorbe pas une file bloquée chez un seul décideur.
• Quelle part de la structure source sert réellement. Un champ personnalisé vide à 97 % est un indice à examiner, pas une preuve d’inutilité. Les 3 % renseignés peuvent porter un cas rare indispensable. Vérifiez les usages conditionnels, les états, les interfaces et l’historique avant de décider de le conserver, de l’archiver ou de l’abandonner.

Un programme qui s’engage sur une stratégie avant l’audit s’engage sur des hypothèses concernant ces trois points. C’est ainsi qu’un hybride s’accumule au lieu de se choisir.

Le modèle de données et la bascule se décident ensemble

Le calendrier de bascule ne suffit pas à choisir le modèle de données. Le modèle ne suffit pas non plus à choisir la bascule.

Une longue file d’arbitrages peut allonger la préparation. Une bascule par lots n’aide que si les domaines peuvent fonctionner séparément pendant la transition. À l’inverse, la disponibilité exigée, les dépendances et la capacité de coexistence contraignent les choix de données. AWS fonde aussi le choix de bascule sur les exigences métier et les contraintes techniques, pas seulement sur la durée de chargement.

L’audit permet de confronter ces contraintes, puis d’ajuster les deux décisions avant d’engager la date. La comparaison des approches et des conditions de coexistence est dans le guide de la migration de données ERP.

La question à mettre sur la table

Avant qu’aucune date ne soit engagée, une question, répondue par écrit, par famille de données :

Cette donnée entre-t-elle dans la cible à la forme de la cible, ou à la nôtre ? Si c’est à la nôtre, combien cela nous coûte-t-il en développements spécifiques, et qui a accepté ce coût ?

C’est la seconde moitié qui en fait une décision plutôt qu’une préférence. Reprendre la structure source est souvent le bon choix, et il n’est défendable que lorsque quelqu’un a chiffré les développements qu’il implique et accepté de les payer pendant toute la vie du système.

Répondre « on verra pendant le build » n’est pas une stratégie. C’est un hybride en train de s’accumuler.

Ces mesures éclairent une décision qui reste métier et technique. Les produire est l’objet d’un audit de préparation, mené avant que la stratégie soit arrêtée plutôt qu’après.