Prenez la comptable d'une PME hébergée en Online, qui cherche un lundi matin le menu des relances clients et ne le trouve plus là où il était la semaine précédente. La base vient de passer à une nouvelle version intermédiaire, et l'écran a changé. Rien n'est cassé, mais une matinée y passe, et la procédure interne rédigée au printemps ne correspond plus à ce qu'elle voit. L'article de juin sur les relances en version 19.3 décrivait un déplacement de ce type. Ce n'était pas un accident : c'est le fonctionnement normal d'Odoo Online, et il mérite d'être compris avant de choisir son hébergement.
Le calendrier réel des versions
Odoo publie une version majeure par an. La page de la documentation consacrée au support standard et étendu précise qu'entre deux versions majeures, Odoo publie des versions intermédiaires, dites versions Online ou SaaS, tous les deux à trois mois. Pour la génération actuelle, le tableau de cette page donne :
| Version | Sortie | Disponible en |
|---|---|---|
| Odoo 19.0 (majeure) | septembre 2025 | Online, Odoo.sh, sur site |
| Odoo 19.1 | janvier 2026 | Online uniquement (plus supportée depuis août 2026) |
| Odoo 19.2 | mars 2026 | Online uniquement |
| Odoo 19.3 | mai 2026 | Online uniquement |
| Odoo 19.4 | juillet 2026 | Online uniquement |
Deux informations ressortent de cette page. Les versions intermédiaires n'existent que sur Odoo Online : elles ne sont jamais publiées pour Odoo.sh ni pour une installation sur site. Et elles ne bénéficient pas du support étendu, contrairement aux versions majeures, supportées trois ans en standard.
En Online, la mise à jour n'est pas une option
La documentation de montée de version fixe des règles différentes selon l'hébergement. En Online :
- une base en version majeure (19.0 par exemple) doit être montée de version tous les deux ans ;
- une base en version intermédiaire doit l'être quelques semaines après la sortie de la version suivante.
Odoo désigne ce mécanisme sous le nom de Rolling Release. Quelques semaines avant l'échéance, une notification apparaît dans la base. L'équipe de montée de version d'Odoo réalise un test silencieux ; s'il réussit, le client peut déclencher lui-même la mise à jour, et s'il ne fait rien, la montée de version est déclenchée automatiquement à la date prévue. Le client garde la main sur le moment, jamais sur le principe.
Concrètement, une base qui a basculé en 19.2 suit le rythme des intermédiaires : 19.3, puis 19.4, puis la version majeure suivante, avec à chaque fois quelques semaines pour tester. Ce n'est pas un défaut caché, c'est écrit noir sur blanc. Encore faut-il l'avoir lu avant de signer.
Sur Odoo.sh et sur site, on choisit son moment
Sur Odoo.sh et sur site, les bases ne tournent qu'en versions majeures. La même documentation indique que sur Odoo.sh, après les trois ans de support standard, le client dispose encore de deux ans pour mener la montée de version. Sur site, elle précise qu'on peut rester indéfiniment sur la même version, en le déconseillant. Il faut ajouter que le contrat d'abonnement Enterprise prévoit une majoration annuelle pour les bases restées sur une version qui n'est plus couverte, mécanisme que nous avions détaillé à propos de la majoration de 25 %.
L'écart est donc considérable. En Online, une PME qui suit les intermédiaires change d'interface quatre ou cinq fois par an. Sur Odoo.sh ou sur site, elle change une fois tous les un, deux ou trois ans, au moment qu'elle a choisi, après un projet de test qu'elle a planifié.
Ce que la cadence change dans l'entreprise
La formation et les procédures
Chaque version intermédiaire apporte des déplacements de menus, des renommages et des écrans revus. Pour une équipe de cinq personnes qui utilise la vente et la facturation, c'est supportable. Pour une PME de cinquante utilisateurs avec des procédures écrites, des captures d'écran dans un manuel interne et des saisonniers à former, c'est un coût récurrent que personne n'a budgété.
Les développements spécifiques
La documentation de changement d'hébergement le rappelle : Odoo Online n'accepte pas les applications non standard. Une base Online ne peut donc compter que sur le standard et sur les personnalisations faites avec Studio. C'est une contrainte forte, mais elle a une vertu : rien de spécifique ne casse à chaque version, puisqu'il n'y a pas de code spécifique. Le problème se déplace vers les intégrations externes, qui appellent la base par l'API et doivent suivre le rythme. L'article sur la vraie ligne de partage entre SaaS et hébergé faisait déjà de ce point le critère principal.
Les tests
Odoo recommande, à chaque invitation à monter de version, de demander une base de test migrée et de la tester avant la production : rapports comptables, taxes, flux entre applications, exports, actions automatisées. Avec quatre ou cinq versions par an, cette discipline devient une tâche permanente. Une entreprise qui la saute découvre les changements le lundi matin, comme la comptable de notre exemple.
La sortie
Un dernier effet est moins visible : une base en version intermédiaire ne peut pas être transférée vers Odoo.sh ou sur site avant d'avoir rejoint la version majeure suivante. Suivre les intermédiaires, c'est aussi accepter qu'un changement d'hébergement attende la prochaine version majeure.
Rester en Online sans subir
Si Online vous convient, deux leviers permettent de reprendre un peu la main.
Le premier est contractuel et se joue tôt. Sur le papier, une base Online en version majeure n'est tenue de monter de version que tous les deux ans, alors qu'une base en version intermédiaire doit suivre chaque nouvelle version. Avant d'accepter une première version intermédiaire, demandez à Odoo par écrit si votre base peut rester sur la version majeure, et jusqu'à quand. La documentation ne décrit pas le retour en arrière, et je ne le considérerais pas comme possible.
Le second est organisationnel, et il ne coûte presque rien :
- désignez un référent qui reçoit les notifications de montée de version et en est responsable ;
- demandez systématiquement une base de test migrée dès l'invitation, sans attendre la date limite ;
- tenez une liste courte de contrôles propres à votre activité : une facture, un avoir, une déclaration de TVA, une commande web, une intégration ;
- lisez les notes de version d'Odoo et prévenez les utilisateurs des écrans qui changent, avant la mise en production ;
- déclenchez vous-même la mise à jour, un jour calme, plutôt que de laisser la date limite décider.
Avec cette discipline, la cadence devient une routine de quelques heures par version. Sans elle, chaque version est une surprise.
Mon avis
Je ne fais pas partie de ceux qui considèrent les versions intermédiaires comme un problème. Pour une petite structure qui utilise Odoo en standard, sans intégration lourde, elles sont même un avantage : les nouveautés arrivent vite, les corrections aussi, et la montée de version annuelle, qui reste un vrai projet ailleurs, devient une suite de petits pas.
En revanche, je déconseille Online, ou du moins le rythme des intermédiaires, à trois profils : les entreprises qui dépendent d'intégrations externes critiques, celles qui ont besoin de modules spécifiques, et celles dont les équipes nombreuses travaillent avec des procédures écrites et des formations planifiées. Pour elles, Odoo.sh offre le même éditeur, les mêmes applications Enterprise, et surtout la maîtrise du calendrier.
La bonne question n'est donc pas « Online ou pas », mais « qui, chez nous, s'occupe de chaque nouvelle version, et avec quel temps ? ». Si personne n'est désigné, la base changera quand même, et c'est l'utilisateur qui le découvrira.
Sources
- Documentation Odoo, support standard et étendu (version du 06/08/2026) : Lire la page
- Documentation Odoo 19.0, montée de version (règles par hébergement, publication continue) : Lire la page
- Documentation Odoo 19.0, changer de solution d'hébergement : Lire la page