Odoo master, fin mai 2026 : trois commits qui parlent vraiment

Je passe une partie de mes semaines dans le code d'Odoo. Pas la doc marketing, le code. Et la branche master raconte souvent mieux la direction du produit que les pages de release notes.

Cette semaine, j'ai pris le dépôt public et j'ai lu les commits de fin mai 2026. Voici ce qui mérite qu'on s'arrête, vu d'un intégrateur qui devra vivre avec ces changements en production.

Un avertissement d'abord. Tout ce qui suit vient de master, donc de ce qui deviendra une version 19.x. Ce n'est pas du code stabilisé que vous trouverez tel quel dans votre instance V18 aujourd'hui. Je le précise parce que la confusion entre versions Odoo coûte des heures de support à tout le monde.

La validation de stock qui ne rame plus

Le commit le plus parlant de la semaine touche stock. Il s'attaque à _free_reservation, la mécanique qui libère et réaffecte les réservations quand on valide des quants.

Les chiffres du benchmark sont dans le message de commit, mesurés sur une base client réelle de 400 000 lignes de mouvement réparties sur 800 transferts. Sur 1 000 lignes, on passe de 10,5 s à 2,2 s. Sur 5 000 lignes, de 121 s à 8,5 s. Et sur 50 000 lignes, le temps tombe de 887 s à 56 s.¹ Quand votre client valide un inventaire de fin d'exercice et que l'écran tourne pendant un quart d'heure, ce genre de correctif change la vie.

Le détail technique est instructif. La lenteur venait de trois sources distinctes. Des mises à jour redondantes de location_dest_id même quand l'emplacement ne bougeait pas. Une boucle en O(N²) dans _check_entire_pack. Et des cache miss qui déclenchaient des requêtes SQL inutiles alors que les données étaient déjà chargées. Rien d'exotique là-dedans. C'est de l'algorithmique propre appliquée à un point chaud.

La leçon vaut pour vos propres modules. Avant d'accuser PostgreSQL, profilez votre boucle Python. Le coût caché s'y trouve presque toujours.

Les retours clients passent en self-service

Deuxième commit notable, du côté sale_stock. Odoo ajoute un flux de retour spontané accessible depuis le portail.²

Concrètement, une nouvelle option « Allow Spontaneous Returns » apparaît dans les réglages d'inventaire, avec un délai de validité paramétrable. Quand une commande contient une livraison sortante terminée et qu'on est encore dans la fenêtre autorisée, le client voit un bouton de retour sur son portail. Il sélectionne ses produits puis choisit un motif. Il télécharge ensuite une étiquette avec code-barres. Le vendeur scanne le code, et le picking de retour se génère tout seul.

C'est le genre de fonction que beaucoup d'intégrateurs facturaient en spécifique. La voir arriver en standard, c'est autant de développement custom qui disparaît. Tant mieux. Notre métier, c'est de résoudre de vrais problèmes métier. Recoder dix fois la même logistique inverse n'en fait pas partie.

Un bémol quand même. Le motif de retour s'appuie sur un nouveau modèle return.reason dont les valeurs par défaut sont en anglais. Si vous déployez chez un client francophone exigeant, prévoyez la traduction et l'adaptation des libellés dès la recette.

Le cœur de l'ORM bouge en silence

Le troisième commit n'intéressera que les développeurs de modules. Il compte malgré tout. Il relie la signalisation des caches au cycle de vie de la transaction.³

Avant, l'invalidation du cache et du registre reposait sur des appels et des drapeaux gérés à la main. Maintenant la logique vit dans l'objet Transaction. Créer le premier Environment d'un curseur déclenche la vérification. Un cr.commit() signale les changements et réinitialise la transaction. Un cr.rollback() réinitialise sans signaler.

Pourquoi ça vous concerne. Si vous avez du code qui manipulait directement registry_invalidated ou qui appelait des invalidations de cache à la main, ce code est à vérifier. Dans la foulée, clear_all_caches a été retiré du même chantier ORM.⁴ En clair, certains réflexes hérités de la V16 vont casser silencieusement à la prochaine migration majeure. Repérez-les maintenant. Pas le jour de la bascule.

Owl 3 partout, et ça va vous toucher

En filigrane de toute la semaine, une migration massive vers Owl 3 dans web et mail. Des dizaines de commits remplacent useState par des proxys et migrent t-ref vers les signaux. La bibliothèque Owl passe à sa dernière version dans le même mouvement.

Je ne vais pas lister chaque commit, ce serait fastidieux et l'ensemble reste en plein chantier. Le signal est clair quand même. Si vous maintenez des composants OWL custom dans vos modules front, votre dette de migration grossit chaque semaine. Mieux vaut l'anticiper que la subir.

C'est aussi la confirmation qu'Odoo investit lourdement dans son framework front maison. On peut le regretter ou l'apprécier. Je préfère personnellement un framework cohérent et documenté à un assemblage de dépendances tierces qui pourrissent au fil des ans.

Côté code Odoo cette semaine

Trois commits retenus sur la fenêtre du 28 mai au 5 juin 2026, branche master. Activité dense, surtout sur account, web et mail. À noter aussi : addons/l10n_fr n'a reçu aucun commit sur cette fenêtre, donc rien de neuf côté localisation française cette semaine-là.

• Stock plus rapide. [PERF] stock: speedup _free_reservation divise par cinq à seize le temps de validation des quants selon le volume. Voir le commit
• Retours portail. [IMP] sale_stock: add return flow ouvre les demandes de retour en self-service avec étiquette et motif. Voir le commit
• ORM, signalisation transactionnelle. [IMP] orm: link signaling to transaction lifecycle déplace l'invalidation des caches dans l'objet Transaction. Voir le commit

Lire le dépôt comme ça, chaque semaine, fait partie de notre manière de travailler chez Nexelans. On conçoit nos modules avec l'IA, on les implémente avec Sudokeys, et on garde un œil sur ce que le cœur d'Odoo prépare. Si vous voulez en discuter pour votre instance, écrivez-nous. Et si la trésorerie sous Odoo 19 vous tient éveillé, notre module Cash Flow Pro existe pour ça.

Sources

• Commit b15aed64 — stock perf
• Commit 5f490ffc — sale_stock return flow
• Commit 9fca3bea — ORM transaction signaling
• Commit 0fc45d78 — ORM remove clear_all_caches