Quand une entreprise planifie un projet ERP, l'attention se porte presque toujours sur le choix du logiciel et la refonte des processus. La migration des données, elle, est traitée comme une formalité technique qu'on règle dans les dernières semaines. Dans notre expérience, c'est exactement l'inverse qui devrait se passer : c'est souvent le chantier qui détermine si le go-live se passe bien ou si l'entreprise démarre avec un système peu fiable.
Une entreprise qui tourne depuis dix ou quinze ans a généralement accumulé des données dans plusieurs systèmes, des fichiers Excel parallèles, des habitudes de saisie qui ont changé au fil du temps et des clients ou fournisseurs dupliqués sous des noms légèrement différents. Migrer tout cela proprement demande du temps et des décisions métier, pas seulement un script d'import.
Pourquoi ce chantier arrive toujours trop tard dans le planning
La migration est habituellement placée en toute fin de projet, juste avant le go-live, parce qu'elle est perçue comme une tâche purement technique confiée à l'intégrateur. En réalité, elle soulève des questions que seule l'entreprise peut trancher : quel client est le bon quand deux fiches se contredisent, quel historique de commandes vaut la peine d'être repris, quelles anciennes catégories produits n'ont simplement plus de sens aujourd'hui. Traiter ces questions au dernier moment, sous pression de date, conduit presque toujours à des raccourcis qu'on regrette après le démarrage.
Ce qui rend vos données difficiles à migrer
Le problème n'est presque jamais la quantité de données, mais leur qualité et leur cohérence. Les difficultés les plus courantes que nous rencontrons chez nos clients sont assez similaires d'un secteur à l'autre.
- Fiches clients ou fournisseurs dupliquées sous des orthographes ou des identifiants différents
- Historique de stock ou de production incomplet, avec des ruptures de traçabilité
- Formats de données incohérents entre les systèmes sources (dates, devises, unités)
- Règles métier implicites codées dans l'ancien système et jamais documentées ailleurs
Une méthode qui fonctionne, dans notre expérience
Le nettoyage des données doit se faire avant la migration, pas après. Corriger un doublon client dans Odoo une fois que des dizaines de factures y sont déjà rattachées coûte largement plus cher que de le corriger dans le système source. La méthode qui donne généralement les meilleurs résultats suit un ordre précis.
- Auditer la qualité des données sources avant d'écrire la moindre ligne de mapping
- Nettoyer et dédupliquer dans le système d'origine, avec les équipes métier qui connaissent les dossiers
- Migrer un échantillon représentatif d'abord, pas l'ensemble du volume
- Faire valider ce échantillon par les utilisateurs métier eux-mêmes, pas seulement par l'équipe IT
- Ne migrer le volume complet qu'une fois cette validation obtenue
Ce qu'il faut prévoir au budget et au planning
La migration de données mérite sa propre ligne dans le planning, avec un responsable côté client clairement identifié, et pas seulement une case cochée dans le rétroplanning de l'intégrateur. Elle demande généralement plusieurs itérations : une première migration de test, des corrections, une deuxième passe, puis la migration finale juste avant le go-live. Sous-estimer ce temps est l'une des causes les plus fréquentes de report de date de démarrage que nous observons.
Une donnée sale migrée rapidement reste une donnée sale, simplement dans un système plus difficile à corriger.
Si vous préparez un projet ERP et que la question de vos données n'a pas encore été posée sérieusement, c'est le bon moment. Réservez un appel découverte si vous voulez explorer si cela s'applique à votre entreprise.