Quand une entreprise planifie son passage à un ERP, la discussion tourne presque toujours autour des mêmes sujets : quels modules activer, comment configurer les workflows, à quoi ressembleront les écrans pour les équipes. La migration des données, elle, est généralement traitée comme une formalité technique qu'on réglera « à la fin ». C'est dans notre expérience l'erreur la plus fréquente, et celle qui coûte le plus cher en délais.
En pratique, les données d'une PME construction, industrielle ou de services n'ont presque jamais vécu dans un seul système propre. Elles sont réparties entre des fichiers Excel constitués au fil des années, un ancien logiciel comptable, des carnets de commandes tenus par différentes personnes avec des conventions différentes. Migrer ces données vers Odoo n'est pas un simple transfert : c'est un exercice de mise en ordre qui touche directement la fiabilité du nouveau système dès le premier jour.
Ce qu'on sous-estime concrètement
L'import technique — le moment où les données passent effectivement dans Odoo — est généralement la partie la plus rapide du travail. Ce qui prend du temps, c'est tout ce qui se passe avant : identifier les doublons, décider quelle version d'une fiche client fait foi, harmoniser des unités de mesure incohérentes, retrouver les références produits qui ont changé trois fois en dix ans. Les entreprises qui budgètent uniquement le temps d'import technique se retrouvent presque toujours avec un dérapage de calendrier au moment où ce travail de fond apparaît.
Le nettoyage commence avant le projet, pas pendant
Le bon réflexe est de traiter l'audit des données comme une étape à part entière, avant même de configurer le nouveau système. Cela demande d'impliquer les équipes qui utilisent ces données au quotidien — elles seules savent souvent pourquoi telle fiche client existe en double, ou pourquoi tel article a deux codes différents selon le dépôt.
- Fiches clients et fournisseurs dupliquées ou obsolètes
- Références produits incohérentes entre sites ou chantiers
- Unités de mesure et conversions non standardisées
- Historique comptable partiel ou réparti sur plusieurs outils
- Stocks théoriques qui ne correspondent plus à la réalité terrain
Migrer tout l'historique, ou repartir sur des soldes d'ouverture ?
Une question revient systématiquement : faut-il importer des années d'historique de transactions, ou démarrer avec des soldes d'ouverture propres et garder l'ancien système en consultation ? Dans la plupart des cas, la seconde option est la plus raisonnable. Elle réduit fortement le volume de nettoyage nécessaire et limite le risque d'importer des erreurs anciennes dans le nouveau système. L'historique détaillé reste accessible à titre de référence, sans polluer la base de données active.
Tester la migration avant le go-live, pas après
Une migration ne se joue pas en un seul passage la veille du go-live. Elle se teste, généralement à plusieurs reprises, dans un environnement de préproduction : import à blanc, vérification que les totaux comptables se recoupent avec l'ancien système, contrôle des stocks, validation par les équipes métier elles-mêmes. C'est ce cycle de test qui permet de repérer les incohérences pendant qu'il est encore simple de les corriger, plutôt que le lundi du go-live devant des utilisateurs qui découvrent des chiffres faux.
Si votre projet ERP approche et que la question des données n'a pas encore été posée sérieusement, c'est le bon moment de le faire. Réservez un appel découverte pour en discuter.