Migrer vers Odoo : ce que personne ne vous dit avant de signer

La plupart des articles sur la migration vers Odoo ressemblent à des plaquettes commerciales. Phases du projet bien rangées, calendrier propre, tout se passe bien. Sur le terrain, c'est rarement ça.

On accompagne des migrations régulièrement — depuis des ERP maison, depuis Sage, depuis des usines à Excel, depuis de vieilles versions d'Odoo. Voici ce qu'on a appris à force d'en faire.

La donnée est le vrai problème — pas le logiciel

Avant même de parler d'Odoo, il faut parler de ce qu'on y amène. La reprise de données est systématiquement sous-estimée. Pas parce que les équipes sont négligentes : c'est juste que personne ne sait vraiment dans quel état sont les données tant qu'on ne les a pas regardées de près.

Ce qu'on trouve le plus souvent1 :

Des clients en double, parfois en triple, avec des historiques éparpillés sur les trois enregistrements. Des fournisseurs actifs sans numéro de SIRET, sans adresse complète, parfois sans nom commercial correct. Des articles avec des unités de mesure incohérentes entre modules. Des prix de vente ou des conditions tarifaires qui vivent dans des fichiers Excel parallèles, jamais vraiment synchronisés avec l'ERP d'origine.

Quand on nettoie tout ça, ça prend du temps. Beaucoup plus que prévu. Et si on ne le fait pas avant la migration — si on importe des données sales dans un système propre — on transfère juste les problèmes d'un système à l'autre, avec en prime la désorganisation d'un Go Live.

Ce qu'on recommande : lancer l'audit des données dès la phase de cadrage, avant de signer quoi que ce soit avec un intégrateur. Ça permet de calibrer correctement le budget et le calendrier. Et surtout, ça évite les mauvaises surprises à trois semaines du Go Live.

Un conseil concret sur l'historique : on ne reprend pas tout2. La tentation est forte de vouloir dix ans d'historique de transactions dans le nouveau système. Dans la pratique, ce sont les N, N-1 voire exceptionnellement N-2 qui suffisent pour la majorité des besoins opérationnels et légaux. Reprendre l'historique complet peut facilement doubler la charge de migration sans apporter grand-chose à l'usage quotidien.

Le périmètre qui grossit en cours de route

C'est l'un des facteurs qui fait déraper le plus de projets. Ça a un nom dans les métiers du projet : le scope creep. Et c'est particulièrement fréquent sur les projets Odoo.

Le scénario se répète : on démarre avec un périmètre raisonnable — comptabilité, ventes, achats, stocks. Puis, au fil des ateliers, chaque responsable métier voit ce qu'Odoo peut faire et ajoute ses demandes. Le module RH. La gestion des projets. L'application mobile pour les commerciaux sur le terrain. Une intégration avec la boutique en ligne. Un rapport sur mesure pour la direction.

Chaque demande prise isolément est légitime. Cumulées, elles font gonfler le projet de 40 à 60 % sans que personne n'ait rien décidé explicitement.

La solution n'est pas de tout refuser. C'est de distinguer ce qui est nécessaire pour le Go Live de ce qui peut attendre la phase 2. Odoo est modulaire — c'est précisément son intérêt. On peut démarrer avec l'essentiel, stabiliser, puis étendre. Un démarrage solide sur 4 modules vaut mieux qu'un démarrage chaotique sur 103.

Ce qu'on voit aussi régulièrement : les décisions de périmètre sont prises par les utilisateurs métier dans les ateliers, sans que la direction soit suffisamment impliquée pour arbitrer. Un projet ERP, c'est un projet de direction, pas seulement un projet informatique.

Le piège des personnalisations

Odoo est flexible. C'est une force, et c'est aussi un risque.

Parce qu'Odoo est personnalisable, on peut avoir la tentation de le faire correspondre exactement à l'existant. De recréer dans Odoo les écrans de l'ancien logiciel, les workflows tels qu'ils ont toujours fonctionné, les rapports dans le format habituel. C'est une erreur.

Deux problèmes concrets4 :

D'abord, les personnalisations coûtent cher à maintenir. À chaque mise à jour majeure d'Odoo, les modules spécifiques doivent être adaptés. Si on a 15 développements sur mesure, ce sont 15 éléments qui peuvent casser lors d'une migration de version — et qui représentent autant de coûts récurrents.

Ensuite, certaines personnalisations reproduisent des dysfonctionnements de l'ancien système. On migre vers Odoo pour améliorer les choses, pas pour retrouver les mêmes contraintes sous une nouvelle interface. Quand un utilisateur demande à recréer un workflow, il faut toujours se poser la question : pourquoi ce workflow existe-t-il ? Est-ce qu'il compense une limitation de l'ancien ERP ? Est-ce que le standard Odoo ne ferait pas mieux ?

Ce qu'on fait sur nos projets : on challenge les demandes de personnalisation au cas par cas. Souvent, la fonctionnalité standard d'Odoo fait déjà 90 % du besoin. Les 10 % restants méritent une vraie discussion — pas un développement automatique.

La règle pratique : si une personnalisation est demandée, on se demande d'abord si elle sera encore pertinente dans trois ans, et si elle sera maintenable lors de la prochaine montée de version.

Le calendrier qui ne tient pas

"On veut être en production pour le 1er janvier." On entend ça régulièrement. Ou le 1er septembre, le début de l'exercice comptable, la rentrée.

Ces dates ne sont pas mauvaises en soi — un point de bascule comptable est même souvent conseillé. Mais elles deviennent un problème quand le projet démarre trop tard par rapport à l'échéance.

Pour une PME de 20 à 100 utilisateurs qui migre depuis un ERP concurrent, comptez entre 3 et 6 mois de réalité projet — de la phase d'audit jusqu'au Go Live. Si on démarre en octobre pour un Go Live en janvier, il faut avoir un périmètre réduit et des équipes très disponibles. Si le périmètre est large et les équipes chargées par l'activité, ça ne passera pas5.

Ce qui fait déraper les calendriers en pratique :

La disponibilité des équipes côté client est sous-estimée. Un projet ERP demande une implication réelle des futurs utilisateurs — recette des modules, validation des données reprises, tests end-to-end. Ce temps n'est jamais complètement prévu dans le planning opérationnel. Et quand ça coince sur la disponibilité, c'est toujours le projet qui attend.

Les décisions qui tardent. Sur un projet ERP, il y a des arbitrages à faire : comment on gère tel cas particulier, quelle est la règle de gestion pour tel flux. Ces décisions doivent venir vite. Quand elles prennent plusieurs semaines, le projet accumule des dettes qui se règlent toutes en même temps à l'approche du Go Live.

Les tests insuffisants. Le Go Live n'est pas une validation — c'est une mise en production sur données réelles. La validation doit avoir lieu avant, sur des scénarios complets, avec les vrais utilisateurs. Un outil qui fonctionne en atelier mais que personne n'a testé sur ses vrais cas métier réserve des surprises.

Ce que la version cible change

Un mot sur les migrations de version Odoo — de V16 vers V19 par exemple. C'est un cas fréquent, surtout avec la nouvelle politique de support d'Odoo qui va introduire des surcoûts pour les versions non maintenues6.

Une migration de version n'est pas une migration transparente. Les modules changent, parfois en profondeur. Des fonctionnalités bougent ou disparaissent. Les modules communautaires (OCA) ne sont pas toujours disponibles immédiatement sur la nouvelle version. Et si l'instance d'origine avait des développements spécifiques, ils doivent être réécrits ou adaptés.

Ce qu'il ne faut pas faire : migrer en urgence pour éviter la majoration tarifaire, sans avoir audité l'état technique de l'instance. Une instance Odoo mal tenue — développements en pagaille, modules communautaires non maintenus, données en désordre — c'est une bombe à retardement lors d'une migration de version.

Ce qu'on conseille : traiter la migration de version comme un vrai projet, avec un diagnostic technique préalable. Si l'instance est propre et peu personnalisée, ça peut aller vite. Si elle est complexe, il faut budgéter en conséquence.

Ce qu'on ne peut pas déléguer à l'intégrateur

Dernier point, souvent mal compris : une migration ERP, ça ne se sous-traite pas entièrement.

L'intégrateur configure le logiciel. Il forme les utilisateurs. Il reprend les données. Il gère le projet. Mais il y a des choses qu'il ne peut pas faire à la place du client :

Connaître les processus métier mieux que les équipes qui les vivent. Décider des arbitrages quand plusieurs options sont possibles. Valider que les données reprises sont correctes. S'assurer que les utilisateurs adoptent vraiment l'outil après le Go Live.

L'adoption est peut-être le facteur le plus sous-estimé. Un ERP bien configuré mais mal adopté n'améliore rien. Les utilisateurs qui contournent le système, qui continuent leurs Excel en parallèle, qui utilisent Odoo comme presse-papier sans exploiter ses automatisations — c'est de l'argent investi pour rien.

La formation ne suffit pas. Il faut identifier des référents internes par service, des personnes qui comprennent l'outil et peuvent répondre aux questions de leurs collègues au quotidien. Il faut aussi un plan pour les premières semaines post Go Live, quand les questions s'accumulent et que les équipes ont besoin d'un appui rapide3.

En résumé

Les migrations réussies qu'on a faites ont presque toujours un point commun : la direction est impliquée dès le départ et reste impliquée tout au long. Les équipes métier ont du temps dédié. Le périmètre est défini et tenu. Les données sont auditées et nettoyées avant d'être migrées.

Les migrations qui ont déraillé ont elles aussi un point commun : le projet a été traité comme un projet informatique plutôt qu'un projet d'entreprise.

Si vous préparez une migration vers Odoo ou une montée de version, contactez-nous. Un cadrage sérieux en amont est la meilleure assurance contre les mauvaises surprises.

Footnotes

1. "La reprise de données, étape clé d'un projet ERP" — KREATYS, novembre 2025. Présentation des catégories de données à reprendre, des défis liés aux différences entre systèmes, et de l'importance d'un audit de qualité des données avant toute migration. <a href="https://integrateur-odoo.kreatys.com/integrateur-odoo/migration-reprise-de-vos-donnees-erp/" target="_blank" rel="noopener noreferrer">Lire l'article</a> ↩

2. "Migration vers Odoo : ne pas reprendre tout l'historique" — INOVTEAM, novembre 2025. Retours sur 47 projets de migration Odoo au Maroc, avec l'observation que reprendre seulement N-2 ou N-3 génère en moyenne 38 % d'économies sur le coût de migration, sans impact sur les besoins opérationnels courants. <a href="https://inovteam.ma/odoo-maroc-2026-guide-complet" target="_blank" rel="noopener noreferrer">Lire l'article</a> ↩

3. "Pourquoi les implémentations ERP échouent" — DigitalTechno, janvier 2025. Analyse des causes d'échec les plus fréquentes sur les projets ERP : périmètre non maîtrisé, disponibilité insuffisante des équipes, et absence d'accompagnement post Go Live pour l'adoption. <a href="https://www.digitaltechno.net/en_US/blog/our-blog-1/comment-une-implementation-de-l-erp-odoo-peut-elle-echouer-85" target="_blank" rel="noopener noreferrer">Lire l'article</a> ↩ ↩2

4. "Développement spécifique dans Odoo : coûts cachés et alternatives" — Podcast Orbeet / Explore Odoo. Retours d'experts sur les risques des personnalisations excessives : coûts de maintenance à chaque montée de version, instabilité, et cas où le standard Odoo répond mieux aux besoins que le développement sur mesure. <a href="https://creators.spotify.com/pod/profile/orbeet/episodes/Odoo---Tout-savoir-sur-la-migration-e2u3eh0" target="_blank" rel="noopener noreferrer">Écouter l'épisode</a> ↩

5. "Migration ERP Odoo : guide complet et conseils d'experts" — Drakkar, juillet 2025. Présentation des points de vigilance sur les calendriers de migration : durée réelle de projet, risques liés à la version d'Odoo, et importance de la phase de test avant Go Live. <a href="https://www.drakkar.io/blog/migration-odoo" target="_blank" rel="noopener noreferrer">Lire l'article</a> ↩

6. "Préparer la migration avant la nouvelle politique de support 2026" — BAAMTU, décembre 2025. Présentation de la majoration tarifaire prévue pour les versions Odoo non maintenues à partir de 2026, et des étapes d'un diagnostic avant migration de version. <a href="https://blog.baamtu.com/odoo-enterprise-reussir-migration-2026/" target="_blank" rel="noopener noreferrer">Lire l'article</a> ↩