Plan de migration – Données statiques vs. dynamiques

(Quatrième partie de la série en six parties « Le guide de la migration »)

Dans la troisième partie, nous avons construit le moteur. Nous avons mis en avant les schémas d'échange comme outil de choix et appliqué la doctrine DAL pour garantir l'intégrité des données.

Nous voici maintenant face au moment décisif de l'ensemble du projet : le week-end de lancement.

Il ne s'agit pas d'un simple week-end de travail. C'est une opération de basculement extrêmement synchronisée de 48 à 72 heures où chaque minute compte. Si vous avez de la chance, elle aura lieu pendant les fêtes de fin d'année, vous offrant ainsi une fenêtre stratégique pour une mise en service sans encombre début janvier.

Mais si vous êtes moins chanceux (ce qui est souvent le cas), c'est un sprint de week-end classique : vous arrêtez l'ancien système le vendredi à 18 h et vous devez avoir l'ERP opérationnel, validé et prêt pour les opérations commerciales le lundi matin.

Si vous tentez d'improviser pendant cette période, vous échouerez. Il vous faut un plan précis, un guide complet, le document de référence absolu qui dicte chaque action. Ce document s'appelle le Plan de Migration de la Transition.

Le plan de migration de la transition : bien plus qu'une simple liste

Le plan de migration n'est pas une simple liste de tâches. Il s'agit d'un planning détaillé qui coordonne les consultants techniques, les utilisateurs métiers, l'équipe infrastructure et les partenaires.

Vous pouvez élaborer ce plan à l'aide de l'outil qui correspond le mieux à l'ADN de votre organisation. Que vous utilisiez Microsoft Project pour la précision d'une méthode en cascade, Notion pour la flexibilité du travail collaboratif, ou simplement un fichier Excel partagé, le principe reste le même.

L'outil est secondaire ; le contenu est obligatoire.

Quel que soit le logiciel choisi, un plan de migration robuste doit comporter au moins ces colonnes pour chaque tâche :

1. ID et description de la tâche : (ex. : « Charger les données de base des articles », « Valider la valeur du stock »).
2. Responsable : la personne désignée. Il doit s’agir d’une personne physique nommément identifiée, jamais d’un service générique.
3. Heure de début et durée : estimation approximative (mais moins c’est approximatif, mieux c’est).
4. Dépendances : « La tâche B ne peut pas démarrer tant que la tâche A n'est pas terminée à 100 %. »
5. Critères de validation : comment savons-nous que cela a fonctionné ? (par exemple, « Le nombre de lignes correspond à l’ancien système »).
6. Date de mise en ligne : indique précisément la date et l'heure de la mise en ligne.
7. Statut : l’état actuel de la tâche (par exemple, « En attente », « En cours », « Terminé ») pour savoir exactement où nous en sommes.
8. Remarques : champ générique permettant d’ajouter des détails spécifiques, des écarts ou des observations rapides au cours du processus.

Règle d'or : si une tâche ne figure pas dans le plan de migration, elle n'est pas effectuée. Pas de solutions de fortune, pas de mises à jour improvisées. La discipline est essentielle.

La stratégie : statique ou dynamique

La plus grosse erreur serait de tenter de tout pendant le week-end de mise en service. C'est matériellement impossible. Pour y parvenir, nous avons divisé les données en deux catégories : statiques et dynamiques.

1. Données statiques

Cela inclut les données de base qui ne changent pas toutes les minutes : articles, nomenclatures, gammes opératoires, clients, fournisseurs, prix.

Notre stratégie consiste à migrer ces données N jours ou semaines avant la mise en production. Nous n'imposons pas de délai strict. Ce délai est défini par le client en fonction du volume de données à charger et de la complexité des contrôles de validation à effectuer.

• Nous chargeons l'ensemble complet dans l'environnement de production.
• Nous le validons tranquillement.
• Nous mettons en place une période de « double maintenance ». Si un utilisateur crée un nouveau client dans l'ancien système pendant ces deux semaines, il doit également le créer manuellement dans l'ERP.
• Le week-end de la mise en service, 80 % des données seront déjà disponibles. Il ne nous restera plus qu'à nous préoccuper des données transactionnelles.

2. Données dynamiques

Il s'agit des données qui évoluent jusqu'à la dernière seconde : soldes de stock, commandes en cours et en-cours de production. Leur migration n'est possible que pendant l'indisponibilité du système

Le cauchemar du projet en cours : Déménager ou ne pas déménager ?

La migration des travaux en cours (WIP) – les ordres de production à moitié terminés en atelier – représente le défi technique le plus complexe de tout projet ERP.

Prenons l'exemple d'une commande de 100 pièces. L'opération 1 (découpe) est terminée. L'opération 2 (soudage) est réalisée à 50 %. L'opération 3 (peinture) est en attente. Comment migrer ces données vers Infor LN, par exemple ?

Option A : Stratégie « Finir la production » : cesser de passer de nouvelles commandes 2 semaines avant la mise en service. Obliger l’usine à terminer toutes les commandes en cours.

• Avantages : Vous repartez de zéro. Aucune logique de migration complexe.
• Inconvénients : Pas toujours possible pour les entreprises ayant des délais de livraison longs (par exemple, la construction de machines qui prend 6 mois).

Option B : Migration de l’« état des opérations » : Si vous devez migrer les travaux en cours ouverts, vous ne pouvez pas simplement insérer un enregistrement indiquant « 50 % terminé ». Vous devez simuler la réalité au sein de l’ERP.

1. Migrer l'ordre de production dans LN.
2. Réplication de la consommation de matières : la migration d’une transaction est impossible. Vous devez réexécuter la sortie dans LN. Selon votre paramétrage (flux rétroactif ou manuel), vous devez soit signaler l’opération terminée pour déclencher la sortie automatique, soit sortir manuellement la matière pour aligner le solde des en-cours.
3. Migration des heures: Injecter une logique pour comptabiliser les heures de travail déjà effectuées.
4. Résultat : La commande dans LN est au coût et au statut corrects, prête pour la prochaine opération.

Évitez l'option B si possible. Elle nécessite des tests approfondis et entraîne souvent des écarts de coûts. Si l'option A est envisageable, privilégiez-la.

Portée des ordres ouverts : Qu’entend-on par « ordre ouvert » ?

Dans la première partie, nous avons opté pour une rupture nette. Il est désormais impératif de l'appliquer rigoureusement dans le Plan. Lorsque nous parlons de « périmètre ouvert », nous faisons référence aux engagements futurs, et non aux données historiques. Nous ne transférons que les éléments actifs et exploitables.

Cette logique s'applique à tous les contrats, commandes clientset autres engagements en cours. Nous ne transférons pas l'historique ; nous transférons uniquement le solde restant à livrer ou à recevoir.

Enfin, concernant les stocks, la règle est financière : la valeur totale du stock importé doit correspondre à celle du système existant du client. En cas d’écart, il convient d’ analyser l’écart. Il est nécessaire de préciser la nature de la différence afin de déterminer si elle provient d’erreurs d’arrondi ou d’incohérences de coûts spécifiques. La concordance entre le coût de revient et l’évaluation des stocks constitue l’étape la plus délicate du processus de validation.

Le point de non-retour

Dans le plan de migration de basculement, il existe une étape clé définie comme le point de non-retour.

Le comité de pilotage se réunit actuellement. Nous passons en revue le tableau de bord :

• Données statiques : chargées à 100 %.
• Données dynamiques : chargées à 100 %.
• Rapprochement financier : Apparié.
• Problèmes critiques : 0.

Si la réponse est « GO », le système est ouvert aux utilisateurs. Il n'y a pas de retour en arrière possible. Le système existant passe en mode lecture seule. Si la réponse est « NOT GO », un plan de restauration est déclenché. Le système existant est déverrouillé et l'activité reprend sur l'ancien ERP le lundi matin, comme si de rien n'était.

Oser dire « non », voilà ce qui distingue un associé principal d'un prestataire junior. Mieux vaut attendre une semaine que de ruiner l'entreprise pour un an.

Presque là

Les données sont chargées. Les soldes correspondent. Le point de non-retour est franchi. Lundi matin, les utilisateurs se connecteront. Ils découvriront des écrans qu'ils n'ont vus qu'en formation. Ils seront nerveux. Ils commettront certainement des erreurs.

Mais surtout, le système générera des erreurs. Dans la partie suivante, nous verrons comment les interpréter. Nous aborderons le langage des journaux et les bonnes pratiques pour gérer le chaos de la première semaine sans perdre la tête.

Écrit par Andrea Guaccio 

2 avril 2026