Rester sur Odoo v12 ou v13 coûte aux entreprises de taille intermédiaire en moyenne 110 000 $ en dépenses cachées sur deux ans. Cela est dû à une majoration de 25 % sur la licence d'entreprise héritée, aux vulnérabilités non prises en charge de Python 3.6 et à l'entretien mensuel continu de code personnalisé obsolète.
Nous comprenons. Mise à niveau d'Odoo se sent lourd. Il y a toujours une saison de pointe, un changement d'équipe ou un cycle budgétaire qui se met en travers. Nous entendons cela de presque tous les clients avec qui nous parlons et qui utilisent encore des versions héritées. Ensuite, nous leur montrons les chiffres réels. La conversation ne prend pas longtemps après cela.
Chez Cudio, nous aidons les entreprises de taille intermédiaire à diagnostiquer ce que le maintien sur v12/v13 leur coûte réellement, à quantifier le chemin de mise à niveau et à exécuter des migrations qui protègent la logique personnalisée là où elle ajoute encore de la valeur. Dans la plupart des cas, le dossier financier pour la mise à niveau se clôt dans un délai de 12 mois.
Ce guide répond aux questions les plus critiques concernant les systèmes Odoo hérités :
- Comment la surtaxe de 25 % sur les anciens produits affecte-t-elle votre facture Odoo Enterprise ?
- Quels sont les coûts de conformité de Python 3.6 et PostgreSQL 10 obsolètes ?
- Quelles fonctionnalités natives de v17/v18 éliminent la dette de code personnalisé ?
- Quel est le calendrier et le coût d'une mise à niveau structurée d'Odoo ?
Montrez-moi ce que la mise à niveau d'Odoo me coûterait réellement
Principaux enseignements
- Rester sur des versions plus anciennes d'Odoo a cessé d'être neutre au début de 2026. Odoo ajoute maintenant un supplément de 25 % aux contrats Enterprise qui ont plus de 3 versions majeures de retard. V12 et v13 se trouvent toutes deux dans cette fenêtre. Chaque renouvellement après mars-avril 2026 entraîne ce coût supplémentaire.
- La pile sous votre système Odoo est un problème plus important que la surtaxe. Python 3.6 a atteint sa fin de vie en octobre 2021, avec plus de 200 vulnérabilités de sécurité. PostgreSQL 10 a perdu son support en novembre 2022. Vos bibliothèques JavaScript sont figées aux versions de 2019. Aucune mise à jour de sécurité régulière ni correction de bogues n'est prévue pour tout cela.
- Pour un déploiement typique de 40 utilisateurs, le coût de maintien dépasse 110 000 $ sur 2 ans. Cela représente 12 000 $ en frais supplémentaires, 72 000 $ en main-d'œuvre spécialisée DevOps et 16 000 $ en corrections de code personnalisé réactives. La mise à niveau d'Odoo vers la dernière version coûte entre 40 000 $ et 90 000 $ en une seule fois. Cela se rentabilise dès la première année.
- Une grande partie de votre développement personnalisé résout des problèmes qu'Odoo a déjà corrigés. La prévision de la demande, la réconciliation automatisée, le P&L multi-entreprises et les flux WMS mobiles sont tous standards dans la nouvelle version. Maintenir des modules personnalisés pour cela est une dette technique que vous payez chaque mois.
Pourquoi « Rester » sur Odoo v12/v13 est maintenant une décision d'affaires coûteuse
Nous voulons être francs avec vous. De nombreuses entreprises restent sur des versions plus anciennes d'Odoo, non pas parce qu'elles ont fait les calculs. Elles restent parce que la mise à niveau d'Odoo semble risquée, et personne ne veut assumer la responsabilité du projet. C'est compréhensible. Le processus de mise à niveau d'Odoo peut mal tourner. Quand cela arrive, c'est visible.
Mais en 2026, rester est le chemin le plus risqué. Retarder les mises à jour était autrefois passif. Maintenant, c'est une décision de coût active. Il y a un coût supplémentaire sur votre facture. Il y a un écart de sécurité documenté. Et la distance entre ce que votre équipe peut faire et ce que les utilisateurs d'Odoo sur les versions actuelles peuvent faire ne cesse de croître.
Odoo v12 est sorti en octobre 2018. La v13 a suivi en octobre 2019. Les deux se situent en dehors de la fenêtre de support de trois versions d'Odoo. Odoo conserve toutes les versions indéfiniment, mais ajoute un supplément de 25 % à tout contrat d'entreprise qui est plus de 3 versions en retard. Au début de 2026, cela couvre la v12 à la v15.
Comment votre facture Odoo changera après 2026 : La nouvelle surcharge de 25 % pour l'héritage

Voici un scénario que nous avons vu plus d'une fois. Un utilisateur de 30 Odoo v13 L'entreprise reçoit son renouvellement d'avril 2026. Il y a une nouvelle ligne : une majoration de 25 % pour la version héritée. Personne ne les a avertis. Maintenant, ils paient 6 000 $ de plus par an pour le même système Odoo qu'ils avaient l'année dernière. Pas de nouvelles fonctionnalités. Pas de correctifs de sécurité. Rien.
La règle est simple. Toute instance Enterprise fonctionnant avec plus de 3 versions majeures d'Odoo en retard par rapport à la version actuelle entraîne un supplément lors du renouvellement. Au début de 2026, avec Odoo 18 en cours, cela signifie les versions plus anciennes de v12 à v15. Le coût supplémentaire s'applique à chaque renouvellement jusqu'à ce que vous mettiez à niveau votre système Odoo.
Voici à quoi cela ressemble avec des tailles de contrat courantes :
- Contrat de 24 000 $/an : 6 000 $ de supplément annuel, 18 000 $ sur trois ans de retard dans les mises à niveau
- Contrat de 48 000 $/an : supplément annuel de 12 000 $, 36 000 $ sur trois ans
- Contrat de 72 000 $/an : 18 000 $ de supplément annuel, 54 000 $ sur trois ans
Aucune de ces dépenses n'achète de nouvelles fonctionnalités. C'est un coût de port pour des logiciels obsolètes. Il est facturé par le fournisseur. Et il augmente chaque année. La logique qui faisait que retarder les mises à jour semblait économiser de l'argent a complètement changé.
Une des premières choses que nous faisons chez Cudio est de consulter le contrat d'un client. Nous leur montrons exactement ce que le supplément représente sur leur période de planification. C'est une courte conversation.
Montrez-moi ce que la mise à niveau d'Odoo me coûterait réellement
Pourquoi votre facture de maintenance continue d'augmenter : Dette technique sur v12/v13

Le supplément est facile à voir. Les coûts cachés de l'exploitation de systèmes plus anciens sont plus difficiles à aborder. Ils s'accumulent discrètement jusqu'à ce que quelque chose se casse.
Voici l'ensemble exact sur lequel votre système Odoo dépend aujourd'hui :
Composant | Ce que votre système Odoo exécute | Date de fin de vie | Ce que cela signifie pour vous |
Python | Python 3.6 | Octobre 2021 | Plus de 200 CVE non corrigés. Aucun correctif de sécurité à venir. |
PostgreSQL | PostgreSQL 10 | Novembre 2022 | Aucune correction de bogues ni mise à jour de sécurité depuis plus de 3 ans. |
Bibliothèques JavaScript | paquets npm gelés à des versions de 2019 | Dérive continue | Vulnérabilités XSS connues. Aucun chemin de correctif du fournisseur. |
Cadre JS Odoo | OWL 1.x | Remplacé par OWL 2.x dans v16+ | Les bogues s'accumulent. Pas de corrections en amont de la part d'Odoo. |
Version d'Odoo | v12 (octobre 2018) / v13 (octobre 2019) | En dehors de la fenêtre de 3 versions en 2026 | 25 % de coût supplémentaire à la prochaine renouvellement. Pas de nouveaux correctifs de sécurité. |
Python 3.6 a plus de 200 vulnérabilités de sécurité sans aucun patch en vue. PostgreSQL 10 n'a eu aucune correction de bogues depuis novembre 2022. Ce n'est pas un risque théorique. Ces CVE se trouvent dans des bases de données que les auditeurs de conformité consultent.
Le support technique et le travail DevOps pour un environnement auto-hébergé v12/v13 coûtent entre 2 000 $ et 5 000 $ par mois. À 3 000 $ par mois, cela représente 72 000 $ sur deux ans. Ceci est dette technique vous payez activement chaque mois juste pour maintenir le statu quo sur les anciens systèmes.
La pénalité du module personnalisé 4x

Voici un autre coût caché qui prend les équipes par surprise. Que se passe-t-il avec vos modules personnalisés lorsque vous mettez enfin à jour votre système Odoo ?
Le la nouvelle version fonctionne avec OWL 2.x sur le frontend, un ORM révisé et une nouvelle structure de contrôleur. Vos personnalisations existantes ne se transfèrent pas sans effort. L'écart entre un processus de mise à niveau planifié et un processus précipité est important :
- Refonte planifiée d'un module personnalisé dans un processus structuré : environ 2 000 $ par module
- Correction réactive en cours de mise à niveau sous pression temporelle : environ 8 000 $ par module
- C'est un écart de coût supplémentaire de 4x sur chaque module de votre code source
Les développeurs rapportent entre 40 et 135 heures pour migrer du code personnalisé à travers plusieurs modules. Support d'urgence pour le lancement en production lors d'une mise en production précipitée. le coût de la mise à niveau est de 2 à 3 fois le tarif normal. Cela représente le temps d'arrêt du système plus les coûts d'urgence qui surviennent en même temps.
Une chose de plus à savoir. De nombreux entrepreneurs qui ont construit votre développement personnalisé v12/v13 ne sont plus en affaires. Les modules sans documentation interne nécessitent une pleine archéologie avant que la migration puisse commencer. Ajoutez 20 à 40 heures de découverte pour chaque module non documenté avant qu'une seule ligne ne soit réécrite.
Parle à Cudio de ma pile de modules personnalisés
Risques de sécurité, de conformité et d'intégration sur Odoo v12/v13
Nous parlons à de nombreux utilisateurs d'Odoo v12/v13 qui disent que le système fonctionne bien. Aucun problème. Nous comprenons pourquoi cela semble être le cas. L'instance est opérationnelle. Les commandes sont en cours. Personne n'a signalé de violation.
Mais les risques de sécurité sur une pile v12/v13 ne se manifestent pas. Une passerelle de paiement échoue à la réconciliation sans avertissement. Une conformité l'audit signale votre version de PostgreSQL. Une API d'expédition commence à renvoyer des erreurs, et quelqu'un construit une solution manuelle. Au moment où cela apparaît, c'est déjà coûteux.
Sécurité et conformité

RGPD et Drapeau des auditeurs PCI DSS des systèmes d'exploitation et des piles non corrigés. Les contrôles compensatoires pour un système ERP de production sur des versions plus anciennes non corrigées coûtent entre 10 000 $ et 50 000 $ à mettre en œuvre et à re-certifier à chaque audit. Sur les versions officiellement prises en charge, les clients d'Odoo Enterprise reçoivent automatiquement des correctifs de sécurité et des corrections de bogues. Sur les anciennes versions d'Odoo, vous êtes seul.
Les passerelles de paiement, y compris Stripe, Adyen et PayPal, ne certifient plus les intégrations avec les anciennes versions. Lorsqu'elles mettent à jour leurs API pour la conformité PCI, votre connecteur de version ancienne ne reçoit pas la mise à jour. Le résultat est des échecs d'intégration silencieux qui se manifestent par des écarts de rapprochement.
Dépécations d'API
UPS et FedEx ont commencé abandonner les versions de l'API que les connecteurs d'expédition de v13 appellent. Lorsqu'un point de terminaison obsolète est hors ligne, la solution de repli est la réconciliation manuelle des CSV. Les équipes rapportent 20 à 40 heures par semaine consacrées à ce type de travail manuel, où les échecs d'intégration se sont accumulés.
Nouvelles fonctionnalités dans v17/v18 auxquelles votre équipe n'a pas accès dans les versions antérieures

Si vous utilisez v12/v13 depuis quelques années, votre équipe s'est adaptée. Ils ont trouvé des solutions de contournement. Ils savent où se trouvent les lacunes. Cela demande un véritable effort, et nous le respectons.
Le problème est que ces solutions de contournement ont un coût. Ce coût augmente chaque année à mesure que l'écart entre les anciennes versions d'Odoo et la dernière version se creuse.
Voici ce que le la nouvelle version d'Odoo est lancée de la boîte que la plupart des utilisateurs de versions plus anciennes manquent soit ou construisent un développement personnalisé pour obtenir :
Ce dont vous avez besoin | Anciennes versions d'Odoo aujourd'hui | Dernière version d'Odoo (v17/v18) |
Prévision de la demande | Points de réapprovisionnement manuels. Quelqu'un possède une feuille de calcul. | Modèle ML natif. Réduit les ruptures de stock de 20 à 30 %. |
Règles de réapprovisionnement | Min/max de base. Pas de logique de MOQ dynamique. | MOQs dynamiques liés aux délais de livraison et aux ventes. Réduit le stock excédentaire d'environ 15 %. |
Flux de travail de codes-barres | Préparation/emballage manuelle via un scanner de base. | Flux de codes-barres WMS complets via mobile. 50 % d'erreurs de prélèvement en moins. |
État des résultats multi-entreprises | Code personnalisé plus exportations manuelles. | Tableaux de bord natifs en temps réel avec éliminations interentreprises. |
Clôture de fin de mois | Réconciliation manuelle lourde. Prend 5 jours. | Moteur automatisé. Se ferme dans 1 à 2 jours. Amélioration de la performance chaque mois. |
Facturation par abonnement | Aucun module natif. Des applications tierces ou un développement personnalisé sont requis. | Entièrement natif. Tableaux de bord MRR/ARR et flux de renouvellement automatique inclus. |
Accès mobile | Un bureau est seulement pour la plupart des opérations commerciales. | Application Web Progressive complète. Les équipes sur le terrain gèrent tout depuis leur mobile. |
API et EDI | API REST v1. Pas de webhooks natifs. Les échecs d'intégration sont courants. | API REST v2 plus des webhooks basés sur des événements et le support EDI OCA. |
Le moteur de réconciliation à lui seul récupère 40 à 80 heures de temps de l'équipe financière par mois. À 50 $ à 75 $ de l'heure, charges comprises, cela représente 2 000 $ à 6 000 $ par mois en capacité récupérée. Chaque mois. Après une mise à niveau.
Comparaison des coûts : Rester sur v12/v13 vs. Passer à v17/v18

Le tableau ci-dessous concerne une entreprise de 40 utilisateurs sur Odoo v13 Enterprise, auto-hébergée sur site, avec 8 000 à 10 000 lignes de code personnalisé réparties sur 8 à 10 modules, et des coûts DevOps de gamme moyenne.
Poste de coût | Rester sur des versions plus anciennes pendant 2 ans | Mise à niveau d'Odoo vers v17/v18 |
25 % de majoration sur un contrat de 24 000 $/an | 12 000 $ de coût supplémentaire. Aucune nouvelle fonctionnalité. | 0 $ après le lancement. |
DevOps Héritage : Python 3.6 et PostgreSQL 10 | 72 000 $ (24 mois x 3 000 $/mois) | 8 000 $ - 15 000 $/an sur une version moderne et prise en charge |
Réparations de modules personnalisés réactifs à des tarifs d'urgence | 16 000 $ (2 modules) | 4 000 $ dans un processus de mise à niveau planifié |
Remédiation GDPR / PCI DSS sur un système Odoo non corrigé | $10,000-$50,000 si déclenché | 0 $ sur les versions officiellement prises en charge |
Estimation du total sur 2 ans | ~110 000 $ - 150 000 $+ | 40 000 $ - 90 000 $ en une seule fois, réduit chaque année par la suite |
Les rapports de recherche sur la migration de Novobi pour 2025 jusqu'à 8x ROI sur les mises à niveau Odoo prévues par rapport aux solutions réactives. Le coût de mise à niveau de 40 000 $ à 90 000 $ est un investissement stratégique avec une période de retour sur investissement documentée. Pensez-y de cette façon. Le coût de séjour s'accumule tous les deux ans. Chaque mois que vous retardez le processus de mise à niveau, les calculs deviennent plus difficiles.
Obtenez ma répartition des coûts de mise à niveau Odoo gratuite
Comment mettre à niveau de v12/v13 sans perturber votre entreprise

Le processus de mise à niveau d'Odoo de la version v12/v13 à la dernière version représente un saut de cinq à sept versions. Cela est gérable avec une planification soigneuse et un processus structuré. Voici les trois phases :
Phase 1 : Évaluation pré-mise à niveau (Semaines 1-4)
Une évaluation appropriée prévient environ 50 % des dépassements de budget. Elle comprend un inventaire complet des modules personnalisés et des personnalisations existantes, un examen de la structure de la base de données, une migration en bac à sable de vos données en direct à l'aide de scripts de migration officiels, et un audit d'intégration pour tous les systèmes tiers et les applications tierces.
Phase 2 : Développement et Migration (Semaines 5-16)
La migration de code personnalisé se déroule en parallèle avec les mises à jour des connecteurs pour les passerelles de paiement et les API d'expédition. OWL 2.x nécessite la réécriture des bibliothèques JavaScript personnalisées et des vues. Les modèles courants des anciennes versions, tels que api.multi et les types de champs obsolètes, nécessitent des corrections ciblées. C'est également à ce moment que votre partenaire Odoo capture les améliorations de performance et l'optimisation des performances dans la structure de base de données mise à jour.
Phase 3 : Mise en scène, Validation et Transition (Semaines 17-20)
La validation s'effectue sur un environnement de préproduction construit à partir d'une copie en direct de vos données. Les utilisateurs avancés testent chaque flux de travail critique. Une mise à niveau de production propre est réalisée pendant un week-end avec une planification minutieuse. Les opérations multi-entreprises connaissent systématiquement 4 à 8 heures de temps d'arrêt minimal dans ce modèle. Gardez l'environnement de l'ancienne version actif pendant 30 jours après la mise en service. La continuité des affaires et la stabilité à long terme dépendent d'un point de retour en arrière.
Chez Cudio, les clients qui viennent à nous après une rupture de connecteur ou un signalement d'audit font presque toujours face à un projet plus long et plus coûteux que s'ils avaient commencé avec une planification soigneuse six mois plus tôt.
Élaborer mon plan de mise à niveau Odoo
Le dossier de mise à niveau est-il déjà clôturé pour votre système Odoo ?
Parcourez ces questions pour voir si votre propre structure de coûts a déjà pris la décision :
- Votre renouvellement d'entreprise est-il prévu après mars-avril 2026 ? Le coût supplémentaire est-il en cours ou à venir.
- Avez-vous rencontré des échecs de passerelle de paiement ou d'intégration au cours des 6 derniers mois liés à des points de terminaison de versions antérieures ?
- Avez-vous constaté une augmentation de vos coûts DevOps alors que le maintien des anciens systèmes est devenu plus difficile ?
- Maintenez-vous un développement personnalisé qui reproduit des fonctionnalités maintenant présentes dans la dernière version ?
- Votre système Odoo fonctionne-t-il avec Python 3.6 et PostgreSQL 10 dans un contexte où des audits GDPR ou PCI DSS s'appliquent ?
- Les utilisateurs d'Odoo de votre équipe signalent-ils des problèmes de stabilité du système ou des rapports lents ?
Si la plupart de vos réponses sont oui, le coût de rester dépasse déjà le coût de la mise à niveau d'Odoo sur une base annuelle. La question n'est pas de savoir s'il faut mettre à niveau. Il s'agit de planifier une transition en douceur avec un temps d'arrêt minimal du système et une continuité des affaires complète.
Conclusion
Odoo v12 et v13 avaient du sens en 2019. En 2026, utiliser des versions plus anciennes d'Odoo signifie payer une prime de 25 % pour un logiciel obsolète sans mises à jour de sécurité régulières, tout en maintenant un code personnalisé que la nouvelle version a déjà remplacé.
Chez Cudio, nous aidons les entreprises à voir leurs véritables coûts de séjour, à cerner clairement le processus de mise à niveau et à effectuer une migration structurée avec un minimum de temps d'arrêt. Si vous souhaitez savoir à quoi ressemble la mise à niveau de votre système Odoo pour votre configuration spécifique, c'est pour cela que nous sommes ici.
Réservez mon évaluation gratuite de mise à niveau Odoo
FAQ
Ce sont les questions que nous entendons le plus souvent de la part des utilisateurs d'Odoo alors qu'ils réfléchissent à la décision de mise à niveau.
Est-il jamais acceptable de rester sur des versions plus anciennes d'Odoo un peu plus longtemps ?
Rester sur des versions plus anciennes d'Odoo n'est raisonnable que pour de très petites déploiements sans intégrations, avec un code personnalisé minimal et un contrat de faible valeur où le coût supplémentaire de 25 % est négligeable. Une fois que votre système Odoo dépend de passerelles de paiement ou de flux multi-entreprises, le risque opérationnel lié aux échecs d'intégration et aux logiciels obsolètes l'emporte sur le coût de retard des mises à niveau au sein d'un cycle de renouvellement.
Devrais-je mettre à niveau directement vers v17/v18 ou passer par des versions intermédiaires ?
Vous devriez effectuer la mise à niveau directement vers la dernière version d'Odoo en une seule fois en utilisant les scripts de migration officiels. Les sauts incrémentiels à travers les versions plus anciennes ajoutent 20 à 50 % aux heures de migration totales sans ajouter de valeur commerciale, car chaque version intermédiaire d'Odoo nécessite son propre cycle de migration de code et de validation.
Ai-je besoin d'une réimplémentation complète ou puis-je migrer mes personnalisations existantes ?
La plupart des entreprises de taille intermédiaire peuvent migrer les personnalisations existantes par le biais d'une mise à niveau technique structurée plutôt que par une réimplémentation complète. La décision dépend du nombre de vos copies de développement personnalisé qui présentent la dernière version. Si plus de 60 % de vos modules personnalisés répliquent de nouvelles fonctionnalités désormais natives à v17/v18, retirer ce code et procéder à une mise à niveau directe est souvent le chemin le plus rapide et le plus propre.
Mon partenaire Odoo actuel dit que mes personnalisations existantes rendent la mise à niveau trop risquée. Que devrais-je faire ?
Lorsque un partenaire Odoo dit que la mise à niveau est trop risquée, cela signifie généralement qu'il manque d'expérience avec la migration des versions héritées, plutôt que que la mise à niveau soit impossible. Demandez-leur une évaluation formelle avant la mise à niveau avec un inventaire de modules documenté, des estimations par module-heure, et une migration en bac à sable de votre base de données de production pour identifier tout changement réellement perturbateur.
Combien de temps prend généralement le processus de mise à niveau d'Odoo de la version 12/13 ?
Le processus de mise à niveau d'Odoo prend de 4 à 8 semaines pour les petites instances avec moins de 5 modules personnalisés, et de 10 à 16 semaines pour les déploiements standards de marché intermédiaire avec 8 à 15 modules et 3 à 5 intégrations. Commencez la découverte au moins 6 à 9 mois avant votre date de mise en service cible afin que votre calendrier soit guidé par la préparation technique, et non par une date limite de renouvellement de licence.
