Modules JavaScript custom : le coût réel d'une migration Odoo 19

Quand une PME décide de passer sa base Odoo en version 19, le devis de migration cache presque toujours le même angle mort : le code JavaScript des modules sur mesure. Le backend Python fait peur parce qu'il touche les données, alors on l'inspecte. Le frontend, lui, passe pour de la décoration. C'est une erreur d'estimation qui se paie en jours-hommes une fois le projet lancé.

Le cadre OWL n'est pas nouveau, mais il devient obligatoire

Odoo a construit son client web autour d'OWL (Odoo Web Library), son propre cadre de composants. La bascule vers OWL 2 a commencé avec Odoo 16, qui embarquait encore un adaptateur de compatibilité. Cet adaptateur laissait vivre les anciens widgets écrits à la mode « legacy », le temps de migrer tranquillement ¹.

Le problème, c'est que le sursis a une fin. Les retours de terrain sur le parcours 16 vers 17 vers 18 vers 19 convergent : l'essentiel de la douleur se concentre sur le saut de la 16 à la 17, là où le cadre historique cède la place aux composants OWL 2 ¹. Une entreprise qui saute directement de la 15 ou de la 16 à la 19 encaisse toute cette dette d'un coup, sans le filet de l'adaptateur.

Bonne nouvelle au passage : l'API du registre, elle, reste stable entre les versions 16 et 19. Ce qui change, ce n'est pas la façon d'enregistrer un composant, c'est ce que vous enregistrez, à savoir un composant OWL 2 avec ses propriétés statiques plutôt qu'un ancien widget ¹.

Ce que le changelog d'OWL 2 impose vraiment

Le détail des ruptures est public. Le changelog officiel d'OWL 2.0 liste des changements qui touchent directement le code custom ² :

• Les méthodes de cycle de vie déclarées sur la classe du composant, comme mounted() ou willStart(), disparaissent. Il faut appeler leurs équivalents en tant que hooks, onMounted() ou onWillStart(), à l'intérieur de la fonction setup().
• Un composant ne peut plus être instancié et monté à la main. L'accès direct au DOM racine via la propriété el est supprimé, au profit des références de template.
• La méthode shouldUpdate n'existe plus. Le système de réactivité suit désormais les dépendances automatiquement.
• Dans les templates, t-on refuse les expressions en ligne du type state.value = state.value + 1 et exige une fonction. Chaque t-foreach réclame un t-key explicite.
• Le Store, le Router, le Context, l'enregistrement global de composants, l'utilitaire debounce et le système de transitions ont été retirés.

Autrement dit, un widget qui manipulait le DOM directement, gérait son propre montage et s'appuyait sur un store OWL 1 doit être réécrit, pas ajusté.

Les deux pièges qui reviennent le plus

Au-delà du cycle de vie, deux habitudes cassent silencieusement. La première concerne les appels au serveur. L'ancien this.rpc() a disparu du modèle de composant ; les opérations sur les modèles passent par le service ORM, récupéré avec useService("orm") dans le setup() ³. Tout un module qui enchaînait les this.rpc() doit voir ses appels redirigés vers ce service.

La seconde concerne les dates. Odoo a abandonné moment.js au profit de Luxon. Le piège classique se cache dans les formats : en Luxon, yyyy désigne l'année calendaire tandis que YYYY désigne l'année ISO à la semaine ³. Un format recopié tel quel depuis un ancien module peut produire un décalage d'un an sur quelques jours à cheval sur le changement d'année, sans lever la moindre erreur.

Ce que ça donne côté cycle de vie en 19

Une fois la migration faite, la structure d'un composant OWL en Odoo 19 est cohérente. Tous les hooks se déclarent dans setup() : onWillStart() accepte une fonction asynchrone et suspend le rendu jusqu'à la résolution de la promesse, onMounted() sert de point d'entrée pour manipuler le DOM ou brancher une bibliothèque tierce, onPatched() gère ce qui doit se rejouer après un nouveau rendu, onWillUnmount() nettoie avant le retrait ⁴. La logique devient plus lisible qu'avec l'ancien enchevêtrement de méthodes de classe, à condition d'accepter le coût de la réécriture.

Pour chiffrer un chantier, le bon réflexe consiste à compter les widgets custom qui touchent le DOM ou le RPC, pas les lignes de Python. C'est là que le budget part.

Notre lecture

Nous voyons passer beaucoup de devis de migration qui séparent mal le risque backend du risque frontend. Le backend est visible, donc surestimé ; le JavaScript custom est invisible, donc sous-estimé. Or les ruptures OWL sont documentées et prévisibles, ce qui veut dire qu'elles sont chiffrables avant de commencer, à condition de faire l'inventaire des composants sur mesure. Notre conseil de praticien : demandez un audit ligne à ligne du dossier static/src de vos modules avant de valider un planning. Une migration vers Odoo 19 qui ne mentionne pas OWL dans son estimation n'a pas regardé la moitié du travail. Pour le versant données, nous avions détaillé les changements ORM qui touchent vos modules dans un précédent article.

Sources

• OWL v2.0.0 CHANGELOG (dépôt officiel odoo/owl) : https://github.com/odoo/owl/blob/v2.0.0/CHANGELOG.md
• Odoo Migration Decoded 16 → 17 → 18 → 19, Frontend Revolution (Osama Alhalabi) : https://medium.com/@eng.osama1998/odoo-migration-decoded-16-17-18-19-frontend-revolution-owl-services-modern-js-part-2-2d17b0d37ebd
• Services et JavaScript Reference, documentation Odoo 19.0 : https://www.odoo.com/documentation/19.0/developer/reference/frontend/services.html
• Hooks, documentation Odoo 19.0 : https://www.odoo.com/documentation/19.0/developer/reference/frontend/hooks.html