Modules Odoo à la migration : on remplace par le natif, on rachète ou on migre?
Quand on parle de migration Odoo, on pense souvent aux données. Mais le vrai enjeu, c'est presque toujours les modules. Une instance Odoo mûre contient rarement que du standard : on y trouve des développements sur mesure, des modules achetés sur le Odoo Marketplace, et d'anciennes personnalisations dont on ne sait plus toujours si elles servent encore.
La bonne nouvelle, c'est qu'Odoo évolue vite. Une partie de ce que vous aviez fait développer n'a peut-être plus besoin d'exister. Voici comment e3k analyse chaque module et le classe dans l'un de trois cas.
En bref, avant de migrer un module Odoo personnalisé, e3k l'analyse pour déterminer s'il tombe dans l'un de ces 3 cas :
1. le besoin est devenu natif → on abandonne le custom.
2. un module communautaire le couvre → on rachète et installe la version compatible.
3. le développement reste unique et pertinent → on le migre techniquement (adaptation du code, des vues, scripts de migration des données, tests avant bascule en production).
Pourquoi vos modules sont-ils le vrai enjeu d'une migration?
Les données, quand elles sont propres, se transposent relativement bien d'une version à l'autre. Les modules, eux, demandent une vraie analyse. Chaque développement sur mesure est du code qui doit être adapté à la nouvelle version - et chaque module non standard est un élément qui peut se comporter différemment après la migration.
C'est pourquoi, avant toute migration, on ouvre un budget d'analyse : un développeur passe en revue chacun de vos modules pour déterminer dans quel cas il tombe. Cette étape évite de « traîner de vieilles choses » d'une version à l'autre et vous fait souvent économiser du temps de développement.
Cas 1 - Votre besoin est désormais couvert par le natif
C'est le meilleur scénario, et il est plus fréquent qu'on ne le croit.
Odoo ajoute des fonctionnalités à chaque version. Ce que vous aviez fait développer sur mesure il y a quelques années fait peut-être maintenant partie du standard. On a par exemple déjà vu des clients avec de lourdes personnalisations sur la facturation et les abonnements découvrir, entre deux versions, que l'essentiel de leur développement était devenu natif — au point de pouvoir retirer complètement les gros morceaux de code sur mesure.
Le gain est double : vous profitez d'une fonctionnalité maintenue par Odoo (donc plus robuste et mieux intégrée), et vous avez moins de code à faire migrer à chaque version future. Chaque personnalisation retirée, c'est une migration future allégée. Dans ce cas, l'action d'e3k est simple : on abandonne le custom et on vous bascule sur le natif, après avoir validé avec vous que la fonction standard couvre bien votre besoin.
Cas 2 - Un module communautaire fait le travail
Deuxième cas : la fonctionnalité n'est pas native, mais un module communautaire existe pour la couvrir — soit un module acheté sur le Odoo Marketplace, soit un module de la communauté OCA.
Ici, l'action est légère. On rachète la version compatible avec la nouvelle version d'Odoo, on l'installe et on la teste. Les modules communautaires sont généralement peu coûteux et l'installation ne prend souvent que quelques minutes par module. C'est surtout du temps d'achat et de vérification.
Le point de vigilance : il faut s'assurer qu'une version compatible du module existe bel et bien sur la version cible. Ce n'est pas toujours immédiat après la sortie d'une nouvelle version d'Odoo — certains modules communautaires mettent un peu de temps à être mis à jour. On vérifie ce point pendant l'analyse pour éviter les mauvaises surprises.
Cas 3 - Il faut migrer le développement sur mesure
Troisième cas : le module correspond à un besoin spécifique, toujours pertinent, et sans équivalent natif ou communautaire. Il faut alors le migrer, c'est-à-dire adapter (ou parfois réécrire) le code pour la nouvelle version.
Quand il s'agit de modules développés par e3k, c'est nous qui faisons le transfert — on connaît le code, donc la migration est maîtrisée : adaptation aux changements d'API, correction des vues XML, et écriture des scripts de migration (upgrade scripts) nécessaires pour préserver vos données. Pour les modules développés ailleurs, on évalue l'effort pendant l'analyse.
C'est aussi l'occasion de faire du ménage : retirer les reliquats, épurer le code inutile, et éviter de transporter dans la nouvelle version des choses qui ne servent plus. Avant de migrer un développement, on se pose toujours la question : sera-t-il encore pertinent dans trois ans, et sera-t-il maintenable lors de la prochaine montée de version?
Comment on tranche : le tableau de décision
Voici comment on classe chaque module.
| Type de module | Question à se poser | Action e3k | Effort / risque |
|---|---|---|---|
| Personnalisation devenue native | La fonction existe-t-elle maintenant en standard? | On abandonne le custom, on bascule sur le natif | Faible — allège la maintenance |
| Module communautaire / Marketplace | Une version compatible existe-t-elle? | On rachète et on installe la version à jour | Faible — surtout du temps d'installation |
| Développement sur mesure encore utile | Est-il toujours pertinent dans 3 ans? | On migre (ou on réécrit) le module | Variable — évalué à l'analyse |
Une fois qu'on a confirmé qu'un module doit être migré (Cas 3), voici concrètement comment se déroule la migration d'un module sur mesure :
- Inventaire du module : on relève les modèles, champs personnalisés, vues, règles d'accès et dépendances du module, pour mesurer précisément l'ampleur du travail.
- Mise à jour du code vers la nouvelle version : on adapte le module à l'API de la version cible (méthodes, champs et vues qui ont changé entre les deux versions d'Odoo).
- Adaptation des vues : les vues XML sont souvent la source la plus fréquente d'erreurs après une montée de version — on les corrige une à une.
- Scripts de migration des données : quand une donnée doit être conservée ou transformée (ex. un champ renommé), on écrit un script de migration dédié pour ne rien perdre au passage.
- Tests sur une copie de vos données réelles : le module doit non seulement s'installer, mais fonctionner correctement avec votre historique de données.
- Bascule en production, une fois la validation complète effectuée.
C'est un travail d'ingénierie précis, et c'est justement pour éviter de le faire « pour rien » qu'on commence toujours par se poser la question du Cas 1 et du Cas 2.
Les quick wins si vous restez temporairement sur votre version
Il arrive qu'un client ne soit pas encore prêt à migrer. Dans ce cas, on peut souvent régler un besoin ponctuel par un petit développement ciblé - un « quick win » qui vous rend le service voulu sans attendre la migration complète. Par exemple, ajouter à votre boutique en ligne la possibilité pour certains visiteurs de voir les produits en catalogue seulement, sans connexion. Ce sont de petites additions, faciles et rapides, qui vous permettent de patienter confortablement jusqu'à la migration.
Cela dit, ces fonctionnalités sont souvent déjà natives dans les versions récentes - raison de plus pour comparer avant de développer.
Une migration réussie ne consiste pas à tout transporter tel quel dans la nouvelle version. Elle consiste à trier : garder ce qui a de la valeur, adopter le natif quand il existe, s'appuyer sur le communautaire quand c'est pertinent, et abandonner ce qui ne sert plus. C'est ce tri qui rend vos migrations futures plus simples et votre ERP plus performant.
Vos questions. Nos réponses
Voici quelques questions fréquentes sur les modules Odoo et la migration.
Ça dépend de chaque module. Si la fonctionnalité est devenue native, mieux vaut abandonner le custom. Si elle est spécifique et toujours utile, on la migre. L'analyse de l'existant permet de trancher cas par cas.
On rachète la version compatible avec la nouvelle version d'Odoo et on l'installe. C'est généralement rapide et peu coûteux. Le point à vérifier est la disponibilité d'une version à jour sur la version cible.
Parce que chaque développement sur mesure est du code à maintenir et à migrer à chaque version. Si le natif fait désormais le travail, retirer le custom allège vos migrations futures et rend votre système plus robuste.
On peut parfois régler un besoin précis par un petit développement ciblé (« quick win ») en attendant. Mais on vérifie d'abord si la fonctionnalité n'est pas déjà offerte en standard dans une version plus récente.