Une migration vers Odoo peut sembler être un projet technique. En réalité, c’est souvent un débat sur la discipline opérationnelle : quelles données aident à mieux vendre, acheter, encaisser et livrer, et quelles données ne font qu’ajouter du bruit. Ma thèse est simple : il ne faut pas migrer des années de données inutiles simplement parce qu’elles existent. Plus la copie est “complète”, plus vous risquez d’embarquer des erreurs, des doublons et une dette de processus que le nouveau système ne fera que masquer derrière une interface plus propre.
Le vrai risque n’est pas de perdre des données. C’est de garder les mauvaises.
La scène réelle : quand le tableau de bord ment
Imaginez une PME de 40 personnes, avec plusieurs gammes de produits et une équipe administrative qui navigue entre tableurs et e-mails internes. Sur le tableau de bord, tout semble correct : les commandes avancent, le stock est visible, les clients sont “dans le système”. Mais le vrai travail se joue ailleurs : post-it, messages WhatsApp, fiches en double et documents qu’on “verra plus tard”.
C’est cette friction qu’une migration vers Odoo peut révéler ou masquer. Si l’on regarde seulement le tableau de bord, on voit de l’activité. Si l’on regarde le travail réel, on voit des exceptions. Et ce sont les exceptions qui consomment le plus de temps.
La bonne question n’est pas combien d’enregistrements vous avez, mais combien sont vivants, clos ou morts. Une commande ouverte depuis deux ans n’est pas un actif ; c’est souvent une anomalie qui pollue les rapports, la recherche et les attentes.
Ce qu’il faut nettoyer, archiver et rapprocher
Avant de déplacer quoi que ce soit, il vaut mieux séparer les données en quatre groupes :
- Ce qui doit voyager parce que c’est encore actif et utile au quotidien.
- Ce qui doit être archivé parce que cela a une valeur légale, historique ou de traçabilité, sans devoir gêner le travail courant.
- Ce qui doit être rapproché parce que la donnée existe à deux endroits et ne correspond pas.
- Ce qui peut rester dehors parce qu’il n’aide plus à décider ni à se conformer, même si certains ont l’habitude de le voir.
C’est souvent là qu’apparaît la première erreur inconfortable : traiter l’archive comme une poubelle. Ce n’en est pas une. Archiver, c’est conserver sans gêner. Pour la direction, c’est essentiel, car un système rempli d’enregistrements morts ralentit les recherches, désoriente les équipes et donne une fausse impression de précision.
La documentation d’Odoo rappelle deux points importants ici. D’abord, une mise à jour n’est pas la même chose qu’une migration d’un autre ERP vers Odoo. Ensuite, si vous utilisez des modules personnalisés, leur compatibilité doit être prête avant de finaliser la mise à jour. Odoo recommande aussi de demander d’abord une base de test mise à jour et de la tester sérieusement, car le processus est plus simple quand l’écart de version est faible. (odoo.com)
L’erreur coûteuse : appeler le nettoyage un retard
Beaucoup d’équipes repoussent le nettoyage des données par peur de ralentir le projet. Parfois, cela ralentit en effet. Mais ce retard coûte généralement moins cher que de découvrir plus tard que le nouvel ERP reproduit les mêmes problèmes, simplement avec un écran plus moderne.
La règle pratique est la suivante : si un enregistrement ne peut pas être expliqué en deux phrases, il n’est probablement pas prêt à migrer tel quel. Cela vaut pour les références clients, les statuts de commande, les anciennes conditions tarifaires, les catalogues obsolètes et les adresses que personne n’utilise depuis des années.
Un scénario fréquent : les ventes veulent tout garder “au cas où”, la finance demande de la rigueur et les opérations veulent seulement que le système cesse de bloquer les commandes. Ce conflit ne se résout pas avec plus de champs ni avec la promesse de “nettoyer après”. Il se résout avec des critères visibles :
- Est-ce utilisé dans une décision hebdomadaire ?
- Y a-t-il un responsable clair ?
- Peut-on le valider avec une source fiable ?
- Cela touche-t-il l’encaissement, la livraison ou la conformité ?
Si la réponse est non à trois questions sur quatre, ce n’est pas prêt à être migré comme donnée vivante.
Une expérience réversible avant le grand changement
Il n’est pas nécessaire de lancer un programme énorme pour bien commencer. Un test petit et réversible dit souvent plus que vingt réunions.
L’expérience que je recommande est simple : choisir une seule famille de données, par exemple les clients ou les produits, et construire trois listes avant la migration pilote : actives, à archiver et à revoir manuellement. Ensuite, vérifier quel pourcentage échoue au rapprochement, quels champs manquent et combien de temps l’équipe met pour trancher les doutes.
Cet exercice enseigne quelque chose d’important : il ne s’agit pas de “migrer mieux”, mais d’opérer avec moins d’incertitude. Si le pilote réduit les appels internes, les corrections manuelles et les reprises, vous avez déjà un signal utile. Sinon, le problème n’est pas l’outil ; c’est la qualité de la décision prise avant le départ.
Dans un mini-cas réaliste, une entreprise découvre que 12 % de ses fiches clients sont des doublons. Elle n’a pas besoin d’une grande transformation pour commencer ; elle doit décider qui est propriétaire de chaque fiche et quelle version de la donnée fait foi. Cette décision, plus que le logiciel, remet de l’ordre.
Ce que la direction doit vraiment retenir
Une migration vers Odoo ne devrait pas être jugée sur la propreté apparente du système le premier jour, mais sur le fait que l’équipe cesse de dépendre de contournements pour travailler. Un nouvel ERP ne corrige pas à lui seul une organisation désalignée. En revanche, il oblige à rendre visibles des problèmes qu’on cachait avec l’habitude.
Si l’entreprise profite de la migration pour supprimer les données mortes, archiver avec méthode et tester sur un petit cas d’abord, elle gagne deux fois : moins de risque technique et une meilleure opération dès le départ.
Trois actions réalistes pour cette semaine :
- Passez en revue une table critique et marquez les champs qui n’interviennent dans aucune décision.
- Demandez à l’équipe d’identifier trois types d’enregistrements à archiver plutôt qu’à migrer comme actifs.
- Choisissez un petit jeu de données pour un test de rapprochement et mesurez le temps nécessaire pour résoudre les écarts.
Chez Codefuente, c’est généralement là que la discussion utile commence : décider quelles données méritent de rester vivantes, et lesquelles occupent seulement de la place.