Le moment le plus risqué d'une migration ERP n'est pas le jour où vous chargez les données. C'est trois semaines plus tard, quand le comptable clôture le premier mois dans le nouveau système et que la balance générale ne correspond pas à l'ancienne. À ce stade, l'équipe projet est passée à autre chose, le système historique est en lecture seule, et chaque écart inexpliqué érode la confiance dans des chiffres dont chacun a besoin au quotidien.
Nous avons appris à traiter la migration d'abord comme un exercice de réconciliation, et ensuite seulement comme un exercice technique. Déplacer des enregistrements entre bases de données est la partie facile — le framework d'import d'Odoo, complété par un outillage de qualité module, versionné dans Git comme tout ce que nous construisons, s'en charge. La partie difficile est de pouvoir prouver, le jour de la bascule, que ce qui est sorti est égal à ce qui est entré.
Avant toute migration Odoo, nous déroulons donc la même checklist. Et nous ne chargeons aucune donnée de production tant que chacun de ses points n'a pas été validé par écrit. Voici à quoi cela ressemble en pratique.
Cartographie des champs et règles de nettoyage — approuvées avant tout mouvement
Chaque migration commence par un document de cartographie des champs : chaque champ source, sa destination dans Odoo, et la transformation entre les deux. Cela paraît bureaucratique jusqu'à ce que vous tombiez sur les champs qui ne se transposent pas proprement — la colonne en texte libre qui contient en réalité trois choses différentes, les codes de catégorie client dont plus personne ne se rappelle la signification, la configuration fiscale historique qui n'a aucun équivalent dans le nouveau plan comptable. La cartographie fait émerger ces décisions tôt, quand elles sont encore peu coûteuses à prendre.
Le nettoyage est l'endroit où les projets dérapent en silence. Les données historiques ne sont jamais propres : partenaires en double, contacts sans pays, produits aux unités incohérentes. La tentation est de corriger tout cela discrètement pendant le chargement. Nous refusons. Chaque règle de nettoyage — fusionner les doublons selon ces critères, appliquer telle valeur par défaut à ce champ manquant, exclure les enregistrements dans tel état — est consignée par écrit et approuvée par le client avant l'exécution du chargement. Le client est propriétaire de ses données ; nous sommes responsables de la mécanique. Quand une règle modifie des données, le client doit être celui qui l'a décidé, pas celui qui le découvre après coup.
Quelle profondeur d'historique reprendre
Tout reprendre donne un sentiment de sécurité et constitue généralement une erreur. Un historique profond alourdit la base de données, ralentit chaque test à blanc et entraîne des années d'incohérences héritées dans un système qui les rejettera à l'import. Ne rien reprendre est pire. Notre posture par défaut est simple : les éléments ouverts sont repris intégralement — chaque facture ouverte, paiement non lettré, commande en cours, contrat actif et position de stock actuelle — car ce sont les enregistrements sur lesquels les équipes agiront dès le premier jour. L'historique clôturé est repris sous forme de soldes d'ouverture par compte et par partenaire, afin que les livres s'équilibrent sans rejouer chaque écriture depuis la création de l'entreprise. L'historique profond, lui, est archivé : le système historique reste disponible en lecture seule aussi longtemps que le client en a besoin, ou nous exportons le détail vers une archive digne de ce nom. Les données de référence — partenaires actifs, produits, employés — migrent toujours en totalité. La frontière entre le vivant et l'archivé est une décision métier : elle figure donc sur la liste des approbations, à côté des règles de nettoyage.
Tests à blanc, rapport de réconciliation et bascule répétée
Nous ne chargeons jamais les données de production en une seule fois. Les scripts de migration s'exécutent d'abord sur une base de préproduction — généralement plusieurs fois — et chaque test à blanc produit un rapport de réconciliation. Le rapport est binaire, réussi ou échoué, pas une impression. Ce qui doit concorder :
- Le nombre d'enregistrements par modèle — partenaires, produits, factures ouvertes, commandes — source contre destination, chaque exclusion étant justifiée par une règle approuvée.
- Les totaux de contrôle financiers — la balance générale par compte, ainsi que les créances et les dettes par partenaire, concordant avec la source au centime près.
- Le détail des éléments ouverts — chaque facture ouverte et chaque paiement non lettré traçable jusqu'à son enregistrement source.
- Les quantités et la valorisation du stock, partout où l'inventaire fait partie du périmètre.
- Des contrôles ponctuels choisis par le client — une poignée d'enregistrements qu'il connaît intimement, vérifiés à la main.
Un test à blanc qui échoue à la réconciliation n'est pas un revers ; c'est la checklist qui fait son travail. Nous corrigeons la règle ou la cartographie, relançons et comparons à nouveau. Ce n'est que lorsqu'un test à blanc complet se réconcilie proprement que nous planifions la bascule — et la bascule elle-même est répétée. Nous chronométrons l'exécution, scénarisons la séquence et convenons avec le client d'un point de décision go/no-go. Derrière se trouve un plan de retour arrière : le système historique reste intact, les sauvegardes sont testées en restauration plutôt que présumées fiables, et si la réconciliation échoue le soir même, nous revenons en arrière et nous nous regroupons. L'entreprise ouvre le lendemain matin sur l'ancien système, pas dans les limbes entre les deux.
Rien de tout cela n'est spectaculaire, et cela concentre en amont un travail que certains projets préfèrent différer. Mais c'est aussi ce qui nous permet de proposer un prix fixe après le cadrage plutôt qu'un compteur horaire sans fin — la checklist est ce qui rend le périmètre connaissable, et le rapport de réconciliation est ce qui donne au mot terminé son vrai sens. Si vous préparez un passage à Odoo et souhaitez voir où se situent les tests à blanc, le rapport de réconciliation et la répétition de bascule dans un plan de projet complet, notre page de service migration détaille toute la séquence.