Les montées de version Odoo

La société Odoo SA qui édite le logiciel Odoo (https://odoo.com) sort une nouvelle version par an, à l’automne lors des Odoo Experience (grand show à l’Américaine, notamment pour présenter la nouvelle version).

Malheureusement, la mise à jour d’une instance Odoo vers une version plus récente ne se résume pas à cliquer sur un bouton “Mettre à jour” ! Nous expliquons dans cet article pourquoi ces montées de version sont complexes techniquement, quand et comment les réaliser.

Terminologie

Dans cet article “Odoo SA” désigne l’éditeur du logiciel et “Odoo” le logiciel en lui-même.

Versions majeures / correctifs

Comme évoqué au-dessus, Odoo SA sort une nouvelle version tous les ans, il s’agit des versions majeures. La version 19.0 sera dévoilée en septembre 2025, elle fait suite à la version 18.0 de l’automne 2024. À partir du moment où la version est dévoilée les nouvelles instances déployées par Odoo SA utilisent cette version.

Ces versions majeures sont donc utilisées dès leur sortie et nécessitent d’être stables et maintenues / corrigées quand un problème est découvert. (Note pour la suite : on considère qu’une version majeure est une version déployée, la version future en cours de développement n’est pas encore une version majeure).

Le code source d’Odoo évolue tous les jours. Il faut distinguer dans ces évolutions :

• les correctifs qui corrigent des failles de sécurité ou des erreurs relevées par les utilisateurs, les tests automatisés ou l’analyse des journaux (logs) du logiciel
• les améliorations des modules existants / ajouts de nouvelles fonctionnalités qui permettent d’enrichir le logiciel et/ou de répondre à de nouveaux besoins / contraintes réglementaires (par exemple la facturation électronique en France)

Pour assurer la stabilité du logiciel, Odoo SA applique des règles pour ces modifications du code : il n’est pas autorisé d’introduire des modifications structurelles dans une version majeure. Les correctifs ne doivent donc pas impacter le modèle de données.

Par ailleurs, Odoo SA ne maintient que les 3 dernières versions majeures, donc les problèmes ne sont analysés et corrigés que sur ces 3 dernières versions.

La plupart des améliorations ou reprises en profondeur du code (qui modifient la plupart du temps le modèle de données) sont donc réalisées uniquement sur la future version en cours de développement et seront disponibles pour les nouvelles instances dès la sortie de cette version.

Une nouvelle version majeure s’accompagne souvent de modifications de l’interface. Des menus ou actions peuvent être ajoutés, modifiés, déplacés ou même supprimés, ce qui peut déstabiliser les utilisateurs habitués à une version inférieure.

Mettre à jour – de quoi on parle ?

Avec les explications ci-dessus, on comprend qu’il faut distinguer 2 types de mise à jour :

• la mise à jour mineure, au sein d’une version majeure, pour profiter des correctifs, et notamment des correctifs de sécurité
• la mise à jour majeure, vers une nouvelle version majeure qui nécessite de transformer les données existantes pour les rendre compatibles avec le modèle de données de la version majeure cible : on parle alors de migration.

Si la première est la plupart du temps indolore et transparente pour les utilisateurs, la migration est beaucoup plus complexe techniquement et nécessite souvent un accompagnement des utilisateurs pour leur expliquer ce qui a changé, notamment sur l’interface. Une migration représente donc un coût non négligeable, pour migrer les données et accompagner les utilisateurs à s’approprier la nouvelle version.

Pourquoi migrer ?

Chaque version majeure vient avec son lot de nouveautés et d’améliorations. Celles-ci peuvent intéresser les utilisateurs Odoo, mais justifient rarement une migration.

Cependant il arrive qu’une nouvelle réglementation impose une mise à jour, tout en entrainant des modifications profondes du logiciel, et donc nécessite une migration. C’est le cas par exemple la facturation électronique ou l’obligation de certification des caisses en France.

Par ailleurs, dans certains contextes, les gains de performance sur les temps de réponse à certaines requêtes apportés par les dernières versions d’Odoo peuvent également peser en faveur d’une migration.

La politique d’Odoo SA de ne maintenir que les 3 dernières versions majeures pousse le plus souvent les utilisateurs à migrer pour pouvoir continuer à bénéficier des correctifs et notamment des correctifs de sécurité.

Cela est d’autant plus vrai pour les instances utilisant des fonctionnalités exposées au grand public sur Internet (site web, boutique en ligne, blog, e-learning, etc.) pour qui les correctifs de sécurité sont souvent indispensables.

Il est à noter ici que l’OCA (Odoo Community Association) maintient une copie du code Odoo (OCB : https://github.com/OCA/OCB), ce qui permet aux développeurs et intégrateurs de cette communauté de réaliser des correctifs sur des versions qui ne sont plus maintenues par Odoo SA. (Ces mêmes personnes peuvent aussi apporter des correctifs sur les versions maintenues par Odoo SA, mais dans ce cas les correctifs sont envoyés à Odoo SA directement pour être intégrés dans le code source d’Odoo)

Comment migrer ?

Plusieurs manières de migrer ses données vers une nouvelle version sont détaillées ci-dessous. Il convient de distinguer entre la migration de données provenant du code d’Odoo lui-même et la migration de données provenant de code spécifique.

Code Odoo

Le code Odoo est lui-même à séparer en 2 : le code de la version Communautaire, sous licence LGPL, librement disponible et le code des modules complémentaires de la version Entreprise sous licence propriétaire Odoo (OPL), accessible uniquement aux utilisateurs payant une licence Entreprise.

Licence entreprise

Pour les utilisateurs payant une licence Entreprise, Odoo inclut dans les coûts de licence les migrations du code Odoo. Il faut pour cela utiliser un service en ligne de Odoo où vous envoyez votre base de données et Odoo vous renvoie une base migrée compatible avec la version cible.

Pour cela, pour chaque modification structurelle du code Odoo dans la version en cours de développement, les développeurs Odoo développent aussi les scripts de migration correspondants. Ces scripts ne sont cependant pas disponibles librement (et, à ma connaissance, pas même en s’acquittant de la licence Entreprise) et seul le service de migration est proposé par Odoo aux utilisateurs de la version Entreprise.

Ces scripts ne couvrent par contre que les modules faisant partie du coeur d’Odoo et développés par Odoo SA (modules de la version Communautaire + ceux de la version Entreprise). Tous les autres modules sont désactivés pendant la migration réalisée par Odoo SA et il revient aux utilisateurs (ou à leurs développeurs / intégrateurs) de migrer les données de ces modules tiers si utilisés.

OpenUpgrade

Afin de pouvoir migrer les instances Odoo des utilisateurs de la version Communautaire d’Odoo, l’OCA (Odoo Community Association) développe un projet nommé OpenUpgrade (https://github.com/OCA/OpenUpgrade) sous licence libre (AGPL-3). Ce projet contient les scripts pour migrer toutes les données issues de chacun des modules de la version communautaire Odoo entre chaque version.

OpenUpgrade est crucial pour rendre la version communautaire viable. Sans cela, les utilisateurs seraient bloqués sur une version, sans autre choix que de payer une licence Entreprise ou de réimporter leurs données manuellement sur une nouvelle version vierge.

Développer les scripts de migration pour OpenUpgrade est une tâche ardue qui nécessite une grande expertise et plusieurs étapes :

1. L’analyse des changements dans le code Odoo de chaque module entre 2 versions majeures (la première étape de cette analyse permettant de lister les changements structurels est en grande partie automatisée)
2. L’analyse des différences fonctionnelles entre les 2 versions majeures pour chaque module : en effet, connaître les modifications dans le code ne suffit souvent pas à comprendre comment les champs sont utilisés. Cette étape nécessite une connaissance très fine du fonctionnement d’Odoo pour chaque module et chaque version, afin de déterminer comment transformer les données existantes vers la nouvelle version, pour ne pas perdre de données tout en conservant le plus possible le sens qu’avaient les données sur la version précédente.
3. La rédaction des scripts de migration en eux-mêmes et la publication de ces scripts pour relecture par la communauté
4. La relecture et la validation des scripts de migration de chaque module par les pairs de la communauté

Si la rédaction de ces scripts n’est pas accessible à un grand nombre de personnes, la communauté peut aider à faire vivre ce projet par d’autres leviers :

• en testant les migrations et en faisant remonter les erreurs
• en finançant l’association OCA pour conserver la priorité et les ressources clés sur ce projet OpenUpgrade

L’utilisation de ces scripts OpenUpgrade pour migrer reste aussi assez complexe même si plus accessible que leur développement, et nécessite la plupart du temps de faire appel à un intégrateur habitué. Néanmoins, de plus en plus d’efforts sont faits pour rendre plus accessible l’utilisation d’OpenUpgrade :

• la documentation du projet a été reprise en intégralité pour intégrer notamment plus d’exemples (https://oca.github.io/OpenUpgrade/)
• de nombreuses interventions expliquant comment l’utiliser ont été filmées et sont disponibles en ligne (dans les vidéos des précédents rassemblements de la communauté OCA, les OCA days)
• des projets complémentaires permettent d’intégrer OpenUpgrade dans un processus plus complet de migration (par exemple Odoo OpenUpgrade Wizard : https://gitlab.com/odoo-openupgrade-wizard/odoo-openupgrade-wizard)
• des formations à l’utilisation d’OpenUpgrade commencent à être proposées (notamment le premier jour des OCA days 2025)

Import/Export

La dernière option pour migrer consiste à exporter les données de l’ancienne version, installer une nouvelle version vierge et réimporter tout ou partie des données de l’ancienne version sur la nouvelle.

Avant d’importer les données, il convient de s’assurer que le format est compatible avec la nouvelle version d’Odoo et de faire les ajustements nécessaires.

Cette méthode peut s’avérer fastidieuse si l’on souhaite récupérer l’intégralité des données (devis/commandes, factures, messages dans l’historique des objets, pièces jointes, etc.)

Cette méthode peut néanmoins être pertinente dans certains contextes, notamment quand les utilisateurs souhaitent repartir d’une base propre en gardant les données historiques sur l’ancienne version (qui n’est alors plus utilisée que pour consulter cet historique).

Code spécifique

Pour le code non inclus dans le coeur d’Odoo, développé par des tiers, il est nécessaire de se rapprocher des développeurs pour obtenir le code correspondant pour la nouvelle version ainsi que les scripts de migration vers cette nouvelle version. Cela peut représenter des coûts importants en fonction de la quantité et de la complexité du code à migrer.

À noter de nouveau ici que les modules développés par l’OCA sont le plus souvent portés sur les nouvelles versions par la communauté (en fonction des besoins / du bon vouloir des développeurs de la communauté) et incluent les scripts de migration.

Les choix du Filament

Nous ne poussons pas nos clients à migrer sans réel besoin ou enjeu de leur côté car nous sommes conscients que cela représente un coût important et impose de changer des habitudes d’utilisation de l’outil. Nous privilégions la maintenance sur un temps long des versions déployées, rendue possible grâce au projet OCB.

Cependant, quand nous décidons avec un client qu’une migration est nécessaire, il est primordial pour nous de disposer d’une solution fiable de migration d’Odoo. Le Filament ne travaillant qu’avec la version Communautaire d’Odoo, seul OpenUpgrade répond à ce besoin. C’est pourquoi nous avons besoin que ce projet perdure et faisons tout notre possible en ce sens :

• nous sponsorisons l’OCA depuis 2018
• nous testons les scripts OpenUpgrade et nous les utilisons régulièrement pour migrer d’abord notre propre instance Odoo puis nos clients qui nous en font la demande
• nous remontons les problèmes trouvés pendant les migrations au projet OpenUpgrade
• nous revoyons les scripts proposés par d’autres
• nous développons quelques scripts que nous proposons à la communauté pour validation

Évidemment, nous migrons aussi les modules spécifiques que nous avons développés pour nos clients.

Enfin, nous profitons toujours de cette phase de migration pour re-questionner les besoins et l’utilisation des modules déployés, car c’est souvent le bon moment pour faire le ménage dans les fonctionnalités qui ne sont pas ou plus utilisées afin de réduire le temps passé (et donc le coût) sur la migration et la maintenance du code sur le long terme.