Playbook de migration de données Odoo
La migration de données est le moment où la plupart des projets Odoo perdent du budget en silence. Pas parce que la tâche technique est dure — elle ne l'est pas — mais parce que personne ne porte les décisions de qualité de données, qui finissent prises par un stagiaire avec un tableur la veille du go-live à 23h.
Nous avons migré des données vers Odoo pour des retailers, industriels, sociétés de services et distributeurs. Le playbook est à peu près le même chaque fois : poser les cibles, nettoyer en amont, migrer par vagues, valider durement. Les équipes qui le suivent mettent en production sereinement ; les équipes qui improvisent passent le premier mois post-go-live à corriger des données au lieu de faire tourner leur business.
Ce guide est la version que nous remettons à nos clients au jour 1 du chantier migration. Lisez-le avant d'exporter quoi que ce soit de votre legacy. Surtout si votre legacy est un dossier Excel — d'expérience ce sont les projets qui dérapent le plus vite.
Décider ce qui migre et ce qui ne migre pas — avant de toucher à un outil
La meilleure décision dans une migration est ce qu'on NE migre PAS. Vieux clients qui n'ont pas commandé depuis trois ans ? Archive, pas migration. Produits arrêtés depuis cinq ans mais toujours dans le catalogue ? Idem. Factures ouvertes de 2019 que le juridique a passées en perte ? Ne pas migrer, documenter.
Moins de données dans Odoo signifie reportings plus rapides, dashboards plus propres, utilisateurs plus heureux et un coût de migration nettement plus bas. Nous avons vu des bases ERP rétrécir de 60% pendant la migration sans perte de valeur — avec un gain de performance mesurable derrière.
- Décider ce qui migre et ce qui ne migre pas — première et principale décision
- Archiver vieux clients, produits, transactions — ne pas les déplacer
- Transactions ouvertes seulement — l'historique fermé peut rester en legacy ou en datawarehouse
- Moins de données = Odoo plus rapide, dashboards propres, utilisateurs heureux
- Documenter la coupe — auditeurs et finance demanderont en année 1
Données maîtres d'abord, transactions ensuite
Toujours migrer dans cet ordre : plan comptable, partenaires (clients, fournisseurs, contacts), produits, puis soldes d'ouverture et transactions ouvertes. Chaque couche dépend de la précédente. Sauter une étape donne des factures pointant vers des clients inexistants ou des mouvements de stock avec des produits fantômes.
Nous testons chaque couche indépendamment avant d'empiler la suivante. Partenaires chargent et valident ? Puis produits. Produits valident ? Puis soldes AR/AP. La discipline paye à chaque fois car les erreurs sont isolées à la couche où elles surviennent.
- Ordre : plan comptable → partenaires → produits → soldes d'ouverture → transactions ouvertes
- Tester chaque couche indépendamment avant la suivante
- Partenaires = clients, fournisseurs, contacts — séparer les imports
- Produits = variantes, unités de mesure, BoM — modéliser avec soin
- Soldes d'ouverture réconciliés à la balance legacy au centime près
Le nettoyage se fait en amont, pas dans Odoo
Ne pas importer des données sales et les nettoyer dans Odoo. Nettoyer dans le tableur ou la base de staging, puis importer la version propre. Nettoyer dans Odoo = nettoyer des données vivantes, donc risque opérationnel, problèmes d'audit et travail bien plus lent.
Construire une zone de staging qui reflète le schéma cible Odoo. Toute la déduplication, la normalisation des adresses, le mapping et la validation s'y font. L'import vers Odoo doit être ennuyeux : CSVs bien structurés vers modèles bien définis, avec une piste d'audit de ce qui a été chargé quand.
- Nettoyer en amont en staging, jamais en live dans Odoo
- Schéma de staging miroir du schéma cible Odoo — mêmes champs, mêmes types
- Dédupliquer les partenaires, normaliser les adresses, valider les TVA avant import
- Mapping des champs documenté dans un tableur partagé et validé
- Piste d'audit : ce qui a été chargé, quand, par qui, avec quel fichier
Migrer par vagues — jamais big-bang
Nous menons toujours au moins trois vagues : une première pour découvrir la vraie forme des données, une deuxième pour valider l'ensemble nettoyé, et une cut-over finale vers la prod. Beaucoup de projets en demandent quatre ou cinq. Chaque vague produit un script d'import éprouvé et des données éprouvées.
La cut-over est répétée sur une copie de prod en staging, idéalement deux fois. Nous la chronométrons, documentons chaque étape, prévoyons un plan de rollback. L'objectif : la nuit du go-live, plus rien n'est fait pour la première fois.
- Trois à cinq vagues — jamais une seule tentative big-bang
- Vague 1 = découverte, vagues 2-3 = nettoyage, vague finale = cut-over
- Cut-over répétée au moins deux fois sur copie staging, chronométrée et documentée
- Plan de rollback défini et testé — que se passe-t-il si la cut-over échoue à mi-chemin
- Chaque vague produit un script d'import éprouvé pour la suivante
Validation qui attrape réellement les problèmes
Compteurs et totaux — nombre de partenaires, de produits, total AR, total AP, valeur stock — doivent réconcilier au legacy au centime ou à l'unité près. Sinon, quelque chose ne va pas, et on le découvre maintenant, pas au reporting du troisième mois.
Au-delà des totaux, nous échantillonnons toujours 50 enregistrements de chaque type et les déroulons de bout en bout avec un expert métier. Client Acme — adresse correcte, conditions de paiement, règles de TVA, liste de prix ? Le sampling attrape ce que les totaux ratent.
- Réconcilier compteurs et totaux au centime / à l'unité contre le legacy
- Échantillonner 50 enregistrements par type, dérouler de bout en bout avec un expert métier
- Lancer balance et valorisation stock dans les deux systèmes au jour 1 du go-live
- Valider les TVA contre les registres officiels (VIES) pour les partenaires UE
- Sign-off de finance, sales, supply chain avant de déclarer la migration terminée
Erreurs de migration qui coûtent le plus cher
Voici les erreurs qui ruinent les migrations chez les clients qui ne nous ont pas engagés en amont.
- Tout migrer parce que personne n'a osé décider la coupe — base ballonnée dès le jour 1.
- Nettoyer les données dans Odoo après import — risque opérationnel, problèmes d'audit, travail lent.
- Migration big-bang unique — pas de répétition, pas de rollback, panique la nuit du go-live.
- Pas de réconciliation contre les totaux legacy — les problèmes sortent au reporting du troisième mois.
- Experts métier non impliqués dans la validation par échantillon — la migration technique passe, le métier utilise du n'importe quoi.
Métriques qui prouvent que la migration a réussi
Voici les chiffres que nous demandons à go-live + 30 jours. Ils montrent si la donnée est fiable.
- Balance dans Odoo identique à la balance legacy au centime près à la cut-over.
- Valorisation stock dans Odoo identique à la valorisation legacy à l'unité près à la cut-over.
- Zéro problème bloquant lié à la donnée en semaine 1.
- Échantillon de 50 partenaires, 50 produits, 50 transactions validés bout en bout par les experts.
- Taille de base 30-60% inférieure au legacy — preuve que les décisions de coupe ont fonctionné.
Comment nous menons les migrations chez Flydoo
Nous démarrons chaque migration par un 'data day' — sales, supply chain, finance, IT en salle pendant une demi-journée pour décider ce qui migre et ce qui ne migre pas. Sortie : un document de scope écrit signé par les responsables de chaque fonction. Ce scope est le contrat du chantier.
Ensuite, c'est de la discipline : zone de staging, document de mapping, plan de vagues, répétition, cut-over, validation. Rien de spectaculaire. Ce qui sépare une migration douce d'une migration douloureuse n'est pas l'outillage — c'est la volonté de faire le travail ennuyeux dans le bon ordre.
- Data day — scope écrit signé par les responsables de chaque fonction
- Zone de staging miroir du schéma cible Odoo, tout le nettoyage s'y fait
- Trois à cinq vagues — découverte, nettoyage, cut-over
- Cut-over répétée deux fois sur copie staging, chronométrée et documentée
- Validation par les experts métier avant de déclarer terminé — sans exception
Checklist pratique pour une migration qui ne plombera pas le go-live
À dérouler avec votre chef de projet et la finance. La majorité cochée = migration saine.
- Décision de coupe documentée — ce qui migre, ce qui ne migre pas, signée par les responsables
- Zone de staging construite, miroir du schéma Odoo
- Mapping des champs documenté dans un tableur partagé et validé
- Trois vagues ou plus planifiées et calendrierées
- Cut-over répétée au moins deux fois sur copie staging de prod
- Plan de rollback défini et testé
- Requêtes de réconciliation (balance, valeur stock, AR/AP) prêtes et lancées dans les deux systèmes
- Experts métier disponibles pour la validation par échantillon en semaine 1
À retenir
- La décision la plus importante est ce qui ne migre PAS — à prendre tôt, par écrit
- L'ordre compte : plan comptable → partenaires → produits → soldes d'ouverture → transactions ouvertes
- Nettoyer en amont en staging, jamais en live dans Odoo après import
- Migrer par vagues — découverte, nettoyage, cut-over — jamais en big-bang
- Réconcilier les totaux au centime près et faire valider des échantillons par les experts métier
- Une base 30-60% plus petite que le legacy est un signe sain, pas un échec
Questions fréquentes
Combien de temps prend une migration de données Odoo ?
Pour une PME avec un ERP unique, des données legacy correctes et une décision de coupe claire, nous prévoyons 4-8 semaines de migration en parallèle de la configuration. Pour un groupe multi-entités avec plusieurs legacy et de la donnée sale, 3-6 mois. Le facteur qui pilote n'est pas le volume — c'est la qualité des données et le nombre de décisions à prendre.
Faut-il migrer l'historique transactionnel ou seulement les transactions ouvertes ?
Les ouvertes, presque toujours. L'historique fermé (factures payées, commandes terminées, anciens mouvements de stock) peut rester en legacy ou en datawarehouse pour référence. Migrer l'historique fermé ballonne la base, ralentit les rapports et ajoute du risque pour très peu de valeur. Les auditeurs s'intéressent à la balance à la cut-over, pas aux lignes de 2018.
Peut-on migrer depuis un autre ERP automatiquement ?
Des outils existent — l'import Odoo, des modules OCA, de l'ETL custom — mais 'automatique' est le mauvais mot. Le travail est dans le mapping, le nettoyage et les décisions, pas dans le déplacement d'octets. Nous utilisons des scripts Python pour les transformations répétables et l'assistant d'import Odoo pour le chargement final, mais le travail amont reste du jugement manuel.
Et si le legacy est vraiment un bazar (par exemple des Excel partagés) ?
Alors le projet de migration devient d'abord un projet qualité de données. Nous avons aidé des clients à reconstituer un référentiel partenaires depuis des PDF de factures, à dédupliquer 40 000 contacts en 12 000 vrais clients, à reconstruire un catalogue produits depuis des tarifs fournisseurs. C'est lent mais c'est le socle — on ne migre pas autour d'une donnée mauvaise.
Qui doit porter la migration côté client ?
Un lead client dédié — souvent le futur product owner Odoo — appuyé par des experts métier de la finance, sales et supply chain. L'équipe technique de migration (nous, ou votre IT) reçoit ses instructions d'eux. Les migrations menées par l'IT seul, sans porteur métier, sont celles qui produisent une donnée techniquement propre que personne ne croit.
Besoin d'aide pour appliquer tout cela à votre contexte ? Parlons-en.