Tester et migrer un module Odoo personnalisé vers Odoo 20

Pourquoi tester ses modules avant de passer à Odoo 20 ?

Un module personnalisé s'appuie sur des détails internes d'Odoo : modèles, vues, noms de champs, composants JavaScript. Quand la version majeure change, ces détails peuvent changer aussi. Un module qui s'installe sans erreur peut tout de même afficher une vue cassée ou calculer un mauvais montant.

La démarche ci-dessous est volontairement prudente : une copie de la base, des journaux lus avec attention, des tests automatisés, puis une vérification manuelle.

Étape 1 : comment préparer une copie de la base ?

Ne testez jamais sur la production. Faites une copie de la base de données et de son dossier de fichiers joints (filestore), puis démarrez Odoo 20 dessus sur un serveur de test.

# Copier la base PostgreSQL (aucune connexion active sur la source)
createdb -T prod_db test_odoo20

# Ou passer par une sauvegarde
pg_dump -Fc prod_db > prod_db.dump
createdb test_odoo20
pg_restore -d test_odoo20 prod_db.dump

Étape 2 : que modifier dans le manifeste du module ?

Commencez par le fichier __manifest__.py : la version, les dépendances et les fichiers de données.

{
    "name": "Mon module personnalisé",
    "version": "20.0.1.0.0",
    "category": "Custom",
    "summary": "Adapté pour Odoo 20",
    "depends": ["base", "sale"],
    "data": [
        "security/ir.model.access.csv",
        "views/mon_modele_views.xml",
    ],
    "license": "LGPL-3",
    "installable": True,
}

Vérifiez que chaque module listé dans depends existe toujours dans Odoo 20 sous le même nom. Un module renommé ou fusionné empêchera l'installation avant même d'arriver à votre code.

Étape 3 : comment installer et mettre à jour le module en ligne de commande ?

Deux essais sont utiles : une installation sur une base vide, qui prouve que le module est complet, et une mise à jour sur la copie de la base, qui reproduit votre situation réelle.

# 1. Installation sur une base vide
./odoo-bin -d test_vide -i mon_module --stop-after-init

# 2. Mise à jour sur la copie de production
./odoo-bin -d test_odoo20 -u mon_module --stop-after-init 2>&1 | tee mise_a_jour.log

# 3. Repérer les problèmes dans le journal
grep -nE "ERROR|CRITICAL|WARNING|deprecated" mise_a_jour.log

Lisez chaque ligne WARNING et deprecated : ce sont les messages d'Odoo qui annoncent ce qui cassera bientôt. Corrigez d'abord les ERROR, puis les avertissements.

Étape 4 : comment écrire un test qui protège vos règles métier ?

Un test automatisé vous dit en quelques secondes si une règle métier a changé de comportement après la mise à jour. Voici un modèle simple à adapter à votre module.

from odoo.tests import TransactionCase, tagged


@tagged("post_install", "-at_install")
class TestMonModule(TransactionCase):

    def test_creation_partenaire(self):
        partner = self.env["res.partner"].create({"name": "Client test"})
        self.assertTrue(partner.id)
        self.assertEqual(partner.name, "Client test")

from . import test_mon_module

./odoo-bin -d test_odoo20 -u mon_module --test-enable --test-tags /mon_module --stop-after-init

Étape 5 : que vérifier à la main, écran par écran ?

Les tests automatisés ne voient pas les écrans. Parcourez les vues personnalisées dans le navigateur, avec un compte ordinaire et un compte administrateur.

• Ouvrir chaque vue formulaire, liste et kanban modifiée par votre module
• Tester les boutons, les rapports PDF et les modèles de courriel
• Essayer les droits d'accès avec un utilisateur sans privilège
• Ouvrir la console du navigateur et chercher les erreurs JavaScript
• Refaire un cycle complet : devis, commande, facture, paiement

Comment organiser la bascule vers la production ?

• Faire valider la copie de test par les utilisateurs clés
• Suivre la procédure de mise à niveau documentée par Odoo pour votre hébergement
• Prévoir une sauvegarde complète juste avant la bascule
• Choisir une fenêtre calme, par exemple un week-end hors période de fin de mois
• Garder un plan de retour arrière et une personne joignable après la mise en ligne

Si vos modules ont été écrits il y a plusieurs années, ou par plusieurs équipes, un inventaire préalable évite de mauvaises surprises : quels modules sont réellement utilisés, lesquels peuvent être retirés, lesquels remplacés par une fonction native.

Foire aux questions sur la migration de modules vers Odoo 20