Odoo v14, v15, v16 : migrer ou payer la majoration de 25% ?

Si vous tournez sur v14, v15 ou v16 et que votre contrat a été renouvelé après juillet 2025, votre facture annuelle vient de grimper de 25%. La question n'est plus « faut-il migrer un jour » mais « quand, comment, et à quel coût par rapport à la taxe ». Voici ce que dit exactement la nouvelle règle, qui paie vraiment, et comment on arbitre chez nos clients PME.

Ce que dit le nouveau contrat Odoo

Le 10 juillet 2025, Odoo a annoncé une refonte de sa politique de support. Avant cette date, le support officiel Odoo Enterprise ne couvrait que les trois dernières versions majeures. Les entreprises devaient donc migrer tous les deux ou trois ans pour continuer à recevoir les patchs de sécurité et l'assistance.

Depuis juillet 2025, toutes les versions d'Odoo Enterprise peuvent bénéficier d'un support étendu, sans limite d'ancienneté. Les correctifs de bugs, les mises à jour de sécurité et l'aide à la migration restent fournis même pour les très anciennes versions. https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html confirme ce nouveau périmètre.

En contrepartie, une majoration de 25% s'applique sur le coût annuel de la licence pour les versions datant de plus de quatre ans, soit trois générations derrière la dernière version publiée. Cette facturation supplémentaire est entrée en vigueur en avril 2026, soit plus de huit mois après l'annonce pour laisser le temps aux clients de planifier leurs arbitrages. C'est ce qui est décrit dans https://www.glo.systems/blog/blog-news-1/heads-up-odoo-enterprise-users-your-license-cost-might-change-from-april-2026-556 publiée dès juillet 2025.

Concrètement, depuis que la v19 est la version actuelle, les installations qui restent sur v16 ou antérieures (v14, v15) sont taxées.

Qui paie, qui ne paie pas

La majoration concerne uniquement les clients Enterprise hébergés en Odoo.sh ou on-premise. Les utilisateurs d'Odoo Online ne sont pas concernés puisque leur instance est mise à jour automatiquement tous les deux mois environ. Côté Odoo.sh, la plateforme étend en parallèle son support officiel aux cinq dernières versions majeures au lieu de trois, une amélioration qui passe un peu sous le radar.

Pour les contrats en cours, deux cas se présentent. Un contrat renouvelé avant le 4 juillet 2025 reste au tarif d'origine jusqu'à son prochain renouvellement : c'est ce que les anglo-saxons appellent une clause grandfathering. Un contrat signé ou renouvelé après cette date intègre directement la nouvelle grille tarifaire et applique la majoration dès que vos versions passent la limite des quatre ans.

Un dernier détail utile : la majoration s'applique au coût utilisateur de la licence Enterprise, pas aux autres postes de votre facture. Votre abonnement Odoo.sh (workers, stockage) n'est pas impacté. De même, vos prestations d'intégrateur ne sont pas concernées, ce qui nous amène au point suivant.

L'arbitrage réel : quand la taxe dépasse le coût d'une migration

Voyons les chiffres sur un cas concret. Prenons une PME française de 20 utilisateurs en plan Custom, représentatif des installations sérieuses. Avec une licence affichée autour de 29,90€/utilisateur/mois en Custom la facture annuelle tourne autour de 6 000 à 8 000 € selon le contrat négocié.

La majoration de 25% représente donc 1 500 à 2 000 € de surtaxe annuelle sur ce profil. Pour une PME plus grande, 50 utilisateurs, la surtaxe peut atteindre 4 000 à 5 000 € par an.

Côté migration, le coût typique d'un passage de v15/v16 vers v18/v19 pour une installation PME avec quelques customs modérés se situe entre 8 000 et 20 000 € selon la complexité et le volume de développements spécifiques à reporter. Le break-even brut s'établit donc entre 4 et 10 ans, ce qui peut sembler long sur le papier.

Mais cette lecture oublie plusieurs éléments. D'abord, la majoration est annuelle : si vous décidez de rester trois ans de plus sur v15 en payant la taxe, vous cumulez 4 500 à 6 000 € de surcoût qui ne produisent rien de nouveau pour votre entreprise. Ensuite, la migration que vous ne faites pas aujourd'hui coûtera plus cher demain, puisque l'écart technologique entre votre version et la version cible s'accroît.

Le piège du support étendu

Le support étendu présente une limitation que beaucoup de clients sous-estiment. Il ne couvre que le code standard Odoo. Tous vos développements spécifiques, vos modules custom, vos intégrations tierces continuent de dépendre de votre intégrateur, avec toute la complexité qui s'accumule sur une version vieillissante.

Plus votre version vieillit, plus les dépendances Python externes deviennent obsolètes. Votre intégrateur se retrouve à maintenir des versions de librairies qui ne sont plus supportées par leurs propres éditeurs. Les modules communautaires OCA que vous utilisez peut-être ne sont pas toujours backportés sur les anciennes versions. L'expertise disponible sur le marché se concentre sur les versions récentes, ce qui rend plus difficile de trouver du renfort ou de remplacer un prestataire.

Autrement dit, le 25% que vous payez à Odoo pour garder votre v15 ne couvre pas le coût caché de maintenir tout ce qui entoure cette v15. https://blog.baamtu.com/odoo-2026-la-nouvelle-politique-de-support-et-la-majoration-de-25 rappelle aussi que la dépendance à votre partenaire d'intégration augmente mécaniquement à mesure que votre version s'éloigne du standard actuel.

Ce qu'on recommande par situation

Voici comment nous abordons le sujet avec nos clients selon leur version.

Vous êtes sur v17 ou v18. Vous n'êtes pas concerné par la majoration pour l'instant. V17 le deviendra quand v20 sortira, probablement fin 2026 ou début 2027, puis v18 le deviendra quand v21 arrivera, etc. Vous avez une fenêtre confortable mais il faut anticiper votre prochain cycle de migration dans votre budget à horizon 18-24 mois.

Vous êtes sur v16. La majoration s'applique depuis ce mois-ci. Vous avez le choix, mais la fenêtre raisonnable pour migrer se situe dans les 12 à 18 mois. Au-delà, vous vous retrouverez sur une version end-of-life et avec deux générations de retard sur les nouveautés IA et UX de v18-v19.

Vous êtes sur v14 ou v15. La surtaxe n'est qu'un élément du problème. V14 a atteint sa fin de vie en octobre 2023 et v15 en octobre 2024 côté Community. Même avec le support étendu côté Enterprise, la dette technique s'accumule rapidement, les modules OCA ne sont plus maintenus, et la sécurité dépend de ce que Odoo accepte de backporter. Migrer devient la priorité budgétaire, pas la taxe.

Vos customs représentent plus de 40% de votre périmètre fonctionnel ? Le coût de portage peut justifier de décaler la migration d'un an ou deux en assumant la taxe. Mais ce choix doit s'accompagner d'un vrai plan : on documente les customs à rationaliser, on identifie ceux qu'on peut remplacer par du standard ou de l'OCA, on refait l'audit avant chaque renouvellement. Sans ce travail, vous vous retrouvez au même point dans 3 ans avec encore plus de retard.

Dans tous les cas, la première étape n'est pas de décider tout de suite. C'est de chiffrer précisément votre taxe annuelle réelle et le coût de migration pour votre périmètre. Un audit d'une à deux journées permet d'arrêter une décision sur des chiffres concrets, pas sur des estimations de café.

Côté code Odoo cette semaine

Sur le repo public https://github.com/odoo/odoo, la semaine du 10 au 17 avril 2026 a vu passer plusieurs correctifs qui valent la peine d'être signalés à nos clients sur v19.

Fuite de stock entre sociétés en multi-compagnies

Un correctif important a été poussé sur le module stock : les enregistrements stock.quant peuvent désormais être restreints à la société du produit via une record rule ajoutée au niveau du modèle. Voir le commit https://github.com/odoo/odoo/commit/6385e5fe1da0db25ef1b4ecfc18c37c3f10c5dfb. Le bug sous-jacent permettait, dans un environnement multi-société, qu'un achat réceptionné pour la société A génère un stock.quant visible en liste pour la société B quand elle était active, avant de crasher à l'ouverture. Si vous avez des overrides custom sur le modèle stock.quant ou stock.move.line, il faut vérifier que votre code reste compatible avec cette nouvelle record rule.

Affichage systématique du journal sur les écritures comptables

Petite amélioration UX mais bien concrète sur la saisie comptable. Le commit https://github.com/odoo/odoo/commit/6229a3666 du 16 avril force l'affichage du champ journal_id sur les écritures, même quand un seul journal est théoriquement compatible, dès lors que celui-ci diffère du journal courant. Concrètement, vos équipes compta ne se font plus avoir silencieusement par un journal qui ne correspond pas à leur sélection. La modification touche le module account.

Traduction des notifications mail dans la langue du destinataire

Dans la continuité d'une série de patches sur le support multilingue du composeur de mails, le commit https://github.com/odoo/odoo/commit/371fda3 corrige l'affichage du bouton "Voir le devis" envoyé aux followers d'un document de vente : il est désormais rendu dans la langue du destinataire, plus dans celle de l'expéditeur. Utile pour les clients qui gèrent des contacts dans plusieurs pays, particulièrement en Espagne et en Italie où le bug se manifestait le plus souvent.

Si vous voulez un chiffrage précis de votre surtaxe actuelle et une estimation du coût d'une migration vers v18 ou v19, on peut faire l'audit en une ou deux journées. Contactez nous pour en parler.