Odoo 20 est publiée depuis quelques jours, et les premières demandes de bases de test migrées arrivent. C'est la bonne réaction, à condition de savoir quoi faire de la base une fois reçue. Une base de test ne vaut que par les contrôles qu'on y fait, et par les personnes qui les font. Le conseil d'exploitation de cette semaine décrit la procédure de test d'une montée de version, telle qu'Odoo la documente, pour chaque mode d'hébergement. Avant cela, voici trois correctifs publiés entre le vendredi 25 septembre et le jeudi 1er octobre : deux dans le dépôt public odoo/odoo, dont un sur la toute nouvelle branche 20.0, et un dans le dépôt odoo/enterprise.
Trois correctifs de la semaine
Caisse française : la bonne unité sur l'ancien prix
Avec la localisation française, le Point de Vente affiche, quand un vendeur modifie le prix d'une ligne, l'ancien prix sous le nouveau, sur l'écran et sur le ticket. Pour un produit vendu au kilo dont le prix était changé, le nouveau prix s'affichait bien « / kg », mais l'ancien prix restait libellé « / Unités », une valeur écrite en dur. Le correctif du 1er octobre en 19.0, dans le module l10n_fr_pos_cert, reprend l'unité du produit. Pour un commerce de détail qui vend au poids, c'est un ticket plus lisible et plus juste.
Import CSV de relevés : plus de lignes importées en boucle
L'import de relevés bancaires au format CSV, dans l'application Comptabilité, accepte un fichier trié du plus récent au plus ancien : il inverse alors l'ordre des lignes avant de les traiter. Il permet aussi de sauter les premières lignes du fichier. Le défaut venait de l'ordre de ces deux opérations, puisque les lignes étaient sautées avant l'inversion. Le message du commit décrit la conséquence pour un fichier trié par date décroissante et importé par lots : les dernières lignes étaient importées encore et encore. Le correctif du 1er octobre, dans le module account_bank_statement_import_csv de l'Enterprise, saute les lignes après l'inversion.
Si vous importez des relevés CSV exportés de votre banque dans l'ordre décroissant, contrôlez le solde de fin de vos derniers relevés et cherchez les lignes en double avant la prochaine clôture.
Odoo 20 affiche le SIRET et le SIREN par défaut
Sur la branche 20.0, un changement du 1er octobre affiche par défaut les champs SIRET et SIREN pour les sociétés françaises, même lorsqu'ils sont vides. C'est un détail d'interface, mais il tombe bien : avec la facturation électronique, ces identifiants comptent. Des champs visibles et vides sont une invitation à les compléter avant le premier envoi.
Tester sa montée de version vers Odoo 20
Avant d'appliquer ces conseils : testez chaque manipulation sur une copie de votre base ou sur un serveur de test, jamais directement en production. Ces conseils sont rédigés sans connaître votre configuration et peuvent ne pas s'appliquer tels quels chez vous. Nexelans ne peut pas être tenue responsable des conséquences d'une manipulation faite sans ces précautions.
Ce conseil ne dit pas quand migrer ; il dit comment tester une fois la décision prise. La procédure s'appuie sur la documentation de montée de version d'Odoo.
Obtenir la base de test
En Online, ouvrez le gestionnaire de bases, sélectionnez la base, puis l'option de montée de version. Choisissez la version cible, l'adresse email qui recevra le lien, et laissez l'objectif sur « Test », réglé par défaut pour une première demande. Le lien vers la base migrée arrive par email ; elle est aussi accessible depuis le gestionnaire de bases.
Sur Odoo.sh, la montée de version se lance depuis le projet, sur une branche de staging. La dernière sauvegarde quotidienne de la production est envoyée à la plateforme de montée de version. La base migrée revient sur la branche dans un mode particulier : à chaque commit poussé, Odoo.sh restaure la base migrée et met à jour tous les modules spécifiques. C'est ce qui permet de corriger vos développements sur une copie propre, autant de fois que nécessaire. Le journal de la montée de version se trouve dans ~/logs/upgrade.log. Attention : les modules spécifiques doivent déjà être adaptés à la version cible pour que la montée de version aboutisse.
Sur site, la demande peut se faire depuis le serveur avec la commande documentée :
python <(curl -s https://upgrade.odoo.com/upgrade) test -d <votre_base> -t 20.0
La documentation signale trois prérequis : l'utilisateur système doit avoir accès à la base PostgreSQL, quelques commandes système doivent être présentes, et le serveur doit pouvoir joindre la plateforme d'Odoo sur le port 443 et sur une plage de ports élevés, ce qui demande parfois une exception dans le pare-feu. Autre point important : la base est envoyée sans son filestore. Avant de restaurer la base migrée, il faut fusionner le dossier filestore reçu avec celui de la production, faute de quoi les pièces jointes manqueront pendant les tests.
Lire le rapport de montée de version
Quand la montée de version réussit, Odoo joint à l'email un rapport, également publié dans Discuss pour les administrateurs. Il liste les changements introduits par la nouvelle version qui touchent votre base. Lisez-le avant de tester : il dit où regarder en priorité.
Tester ce qui compte
La base de test est neutralisée : actions planifiées désactivées, serveurs d'emails sortants remplacés par un faux serveur, moyens de paiement et transporteurs en mode test, synchronisation bancaire coupée. Vous pouvez donc tester sans risque pour vos clients. La liste de contrôle de base proposée par Odoo couvre les vues, les rapports imprimés, le site web, la création et la modification d'enregistrements, les modèles d'emails, les traductions, les filtres de recherche et les exports.
Je conseille d'y ajouter un parcours complet propre à votre activité, comme le suggère la documentation : acheter un produit, le réceptionner, le vendre, le livrer, facturer, émettre un avoir, puis contrôler les rapports comptables, les taxes et les comptes bancaires. Ce test doit être fait par les utilisateurs qui font ce travail chaque jour, pas seulement par l'intégrateur : ce sont eux qui verront qu'un écran a changé ou qu'un champ manque.
Pour Odoo 20 en particulier, testez en priorité ce que les notes de version annoncent comme modifié : les statuts de paiement renommés, la règle qui impose que toute écriture sur un compte bancaire provienne d'une transaction bancaire, et le circuit des notes de frais, désormais transformées en factures fournisseurs en brouillon.
Recommencer autant de fois que nécessaire
La documentation le précise : on peut demander plusieurs bases de test. Si un problème apparaît, signalez-le au support d'Odoo, rubrique dédiée aux tests de montée de version, corrigez ce qui relève de vos modules, puis redemandez une base. Ne passez en production qu'après un test complet sans anomalie bloquante, et après une sauvegarde vérifiée de la production, comme le rappelle l'article sur la sauvegarde d'une base Odoo.
Sources
- odoo/odoo, commit 9f2617b (01/10/2026), unité de l'ancien prix en caisse française : Voir le commit
- odoo/enterprise, commit 5ca1f81 (01/10/2026, branche 19.0), ordre des opérations dans l'import CSV de relevés
- odoo/odoo, commit f9d7b0e (01/10/2026, branche 20.0), SIRET et SIREN affichés par défaut : Voir le commit
- Documentation Odoo 20.0, montée de version (base de test, rapport, tests) : Lire la page
- Odoo, notes de version d'Odoo 20 : Lire la page
- Service de montée de version d'Odoo : upgrade.odoo.com