Migration des données vers un nouvel outil métier : les pièges que personne n'anticipe
Dans la majorité des projets d'outil sur mesure en PME, la migration des données est planifiée en deux jours à la fin du projet et en prend souvent quinze. Ce retard n'est pas technique : c'est une erreur de méthode prévisible, et entièrement évitable si elle est traitée dès le cadrage.
Donatien Lefranc
Fondateur & Président, Leando
La phase qu'on planifie en dernier et qui bloque tout le reste
Un projet d'outil sur mesure se découpe généralement en quatre temps : cadrage, développement, recette, déploiement. La migration des données arrive en note de bas de page du déploiement, présentée comme une opération technique de quelques heures. Les équipes l'apprennent à leurs dépens : quand la migration commence, les vraies questions surgissent. Où est la donnée de référence ? Qui a la version à jour de ce fichier client ? Quelle date retenir pour les contrats actifs ?
Ces questions ne sont pas techniques. Ce sont des décisions métier que personne n'a encore prises. Elles ne peuvent pas se régler en urgence, la veille du démarrage, pendant que les équipes attendent de pouvoir utiliser le nouveau système.
La migration des données expose les incohérences que l'ancienne organisation avait appris à vivre avec. Des clients enregistrés deux fois sous des noms légèrement différents. Des produits dont le code a changé sans que toutes les références soient mises à jour. Des contrats dont la date de fin n'a jamais été renseignée parce que tout le monde savait. Un nouvel outil ne peut pas absorber ces incohérences : il les révèle et les bloque.
Ce que la donnée existante cache dans la plupart des PME
La multiplicité des sources de vérité
Dans la plupart des PME, la donnée ne vit pas dans un seul endroit. Elle est distribuée entre un ERP vieillissant, des fichiers Excel que chaque service maintient à sa façon, des boîtes mail qui servent de base de connaissance informelle, et parfois un logiciel de facturation dont les données sont partiellement alignées avec le reste. Chaque source est perçue comme la référence par ceux qui l'utilisent au quotidien.
Un bureau d'étude offshore de 45 personnes en Bretagne en offrait un exemple représentatif : l'ERP interne coexistait avec des dizaines d'Excel personnels, des échanges Teams, et un outil de facturation séparé. Aucun de ces systèmes ne parlait aux autres.Pour migrer vers un outil unifié, il aurait fallu décider quelle source avait la bonne version de chaque donnée, affaire par affaire. Ce travail avait été sous-estimé de plusieurs semaines dans le planning initial.
« On a travaillé assez vite sur leurs objets métier, sur le modèle de données et sur les règles métier implicites de manière à comprendre vraiment les différents tenants et aboutissants d'un point de vue organisationnel, stratégique et technique. »
Les règles implicites que le format ne peut pas absorber
L'autre difficulté cachée dans une migration : les règles de gestion que les équipes appliquent sans les avoir jamais formalisées. Un champ « statut » peut avoir cinq valeurs possibles dans l'ancien ERP, dont deux ne s'utilisent plus depuis deux ans mais dont personne n'a effacé les données. Un champ « priorité » peut avoir une signification différente selon l'équipe qui l'a rempli. Un code produit peut correspondre à deux références différentes selon les périodes.
Migrer ces données sans les nettoyer, c'est transférer les ambiguïtés dans le nouveau système. Les équipes se retrouvent avec un outil neuf qui contient les mêmes problèmes que l'ancien, augmentés d'une couche de confusion liée au changement de format. Pour aller plus loin sur les décisions de modèle de données qui conditionnent la qualité d'une migration, l'article sur les décisions de modèle de données que l'IA ne peut pas prendre à votre place développe ce point en détail.
Comment préparer une migration qui ne retarde pas le démarrage
La migration des données se prépare avant le premier développement, pas après. Trois actions concrètes permettent de transformer une phase à risque en étape maîtrisée.
Première action : identifier les données indispensables au démarrage.Tout ce dont l'équipe a besoin le lendemain de la bascule pour faire son travail normalement. Dans la majorité des cas, ce périmètre est bien plus restreint que l'historique complet. Les contrats actifs, les clients en cours, le stock vivant. L'historique des cinq dernières années peut attendre une deuxième phase, voire rester dans l'ancien système en lecture seule.
Deuxième action : cartographier les sources pour chaque type de donnée.Pour chaque entité métier (client, produit, contrat, facture), identifier où est la version de référence. Si plusieurs sources coexistent, décider laquelle prime. Cette décision est organisationnelle. Elle ne peut pas être déléguée à l'équipe technique. Elle engage la direction ou les responsables métier concernés.
Troisième action : tester la migration sur un sous-ensemble représentatif avant la bascule complète. Prendre deux cents enregistrements qui couvrent les cas typiques et les cas particuliers connus, les importer, vérifier que les données sont lisibles et que les règles métier s'appliquent correctement. Cette étape révèle les problèmes quand il est encore temps de les corriger sans décaler la mise en production.
Sur la stratégie de migration progressive qui permet de ne pas tout basculer en une fois, l'article sur migrer un système legacy sans big bang décrit la méthode appliquée sur des projets à forts enjeux de continuité.
Ce que ça change quand la migration est cadrée dès le départ
Sur un projet de modernisation SI pour un fournisseur d'énergie ETI en France, la migration depuis un legacy PHP vers un nouveau système posait exactement ces défis : des scénarios non documentés dans le métier de l'énergie (soutirage, injection, règles Enedis) qui ne tenaient pas dans un modèle de données standard. Le temps passé à cartographier ces règles implicites en amont a évité plusieurs mois d'allers-retours en développement.
La migration s'est faite de façon progressive : le nouveau système a pris en charge le périmètre commercial en tension, tandis que le legacy continuait à opérer sur les autres processus. Cette stratégie a permis de démarrer sans tout migrer en une fois, de valider le modèle de données sur un périmètre réduit, et d'élargir progressivement au fur et à mesure de la stabilisation.
Si vous êtes en phase de cadrage d'un projet d'outil sur mesure, posez cette question dès le démarrage : quelle est notre stratégie de migration des données, et combien de temps avons-nous prévu pour l'étape de nettoyage ? Si la réponse est « quelques heures à la fin », reprenez le planning avant de signer. Sur la méthode pour sortir progressivement d'une dépendance aux fichiers Excel, sortir du piège Excel sans tout casser donne un cadre applicable à partir de cette semaine.
Questions fréquentes
Pour une PME de 30 à 100 personnes avec un ou deux logiciels sources dont les données sont propres, comptez deux à six semaines. Si les données sont dispersées dans plusieurs fichiers Excel sans structure commune, ajoutez deux à quatre semaines de nettoyage avant tout transfert. Cette durée doit être intégrée dans le planning dès le cadrage, pas découverte à la fin du projet.
Votre projet d'outil sur mesure a une stratégie de migration ?
Un échange d'une heure permet d'identifier les risques de migration avant que le projet démarre. C'est souvent là que se cache le vrai décalage de planning.
Prendre un premier rendez-vous