Comment fonctionne ce calculateur
Une mise à niveau Odoo n\'est pas une migration de données : le modèle reste le même, mais chaque version intermédiaire entre votre version source et votre version cible apporte ses propres changements cassants. De Odoo 12 à 13, c\'est la refonte de la comptabilité ; de Odoo 14 à 15, c\'est le passage à OWL 2 ; de Odoo 15 à 16, c\'est l\'API JavaScript moderne ; de Odoo 16 à 17, c\'est le nouveau client web. Chaque saut de version doit être absorbé par votre code sur mesure et vos modules OCA, un par un.
Le calculateur traduit cette réalité en une formule simple : 50 heures de base, plus 40 heures par saut de version. Un saut Odoo 16 vers 17 démarre donc à environ 90 heures ; un saut Odoo 8 vers 19 démarre à 490 heures. Cette base est ensuite multipliée par quatre leviers : le nombre de modules sur mesure à refactorer, l'usage de modules OCA, la taille de la base de données et votre tolérance au temps d'arrêt. Le résultat est converti en USD au taux horaire mixte de 175 $/h, qui reflète une équipe d'upgrade typique : développeur Python senior, ingénieur DevOps Odoo et QA fonctionnel.
La bande basse est à 80 % du point médian (modules propres, code bien testé, équipe interne disponible), la bande haute à 130 % (refactor profond, modules OCA abandonnés à reprendre, cutover quasi sans temps d'arrêt avec blue-green). Comme pour notre calculateur d'implémentation, on modélise une marge haute de 30 % plutôt que 20 %, parce que c'est sur la borne haute que la plupart des projets atterrissent.
Les vrais inducteurs de coûts d'une mise à niveau
Sur plus de 80 mises à niveau exécutées par Octura, on a vu un constat se répéter : la difficulté n'est presque jamais le code de base d'Odoo. La difficulté, c'est tout ce que vous avez ajouté autour. Voici les quatre leviers qui font bouger la facture.
Delta de version : la dette cumulée des sauts ignorés
Plus vous avez attendu, plus la dette est grosse. Une mise à niveau d'une version à la suivante (n vers n+1) absorbe un seul jeu de changements cassants. Sauter trois versions (n vers n+3) absorbe trois jeux empilés, parce qu'il faut rejouer chaque migration intermédiaire, soit module par module avec OpenUpgrade, soit en bloc avec un script unique qui contient les patchs de toutes les versions intermédiaires. La deuxième approche est plus rapide mais elle écrase l'historique de votre code dans un seul commit géant, ce qui rend les régressions plus difficiles à isoler par la suite.
Modules sur mesure : le coût refactor par module
Chaque module sur mesure doit être audité contre la version cible : nouveaux ORM hooks, déprécations d'API, changements de vue, refactor de tests. Un module simple (10 modèles, peu de vues, pas de logique JS) prend 8 à 15 heures par saut de version pour être porté. Un module complexe (héritages multiples, héritages JS dans les vues, surcharges de méthodes critiques) prend 30 à 60 heures par saut. Les multiplicateurs du calculateur (0,6x pour 0 modules, jusqu'à 2,4x pour plus de 10 modules) reflètent à la fois ce coût par module et le coût de coordination quand plusieurs modules personnalisés se touchent.
Modules OCA : la maintenance que personne n'a chiffrée
Les modules OCA sont gratuits, ils ne sont pas sans coût. Pour chaque mise à niveau, chaque module OCA installé doit être vérifié : la branche de la version cible existe-t-elle, est-elle maintenue, est-elle compatible avec les autres modules OCA que vous avez installés, fonctionne-t-elle avec vos personnalisations ? Quand un module OCA n'a pas été porté vers votre version cible, il y a trois choix : attendre que la communauté le fasse (peut être long), le porter vous-même (et le maintenir ensuite), ou le retirer et reconstruire la fonctionnalité dans un module à vous. Le multiplicateur OCA grimpe à 1,6x pour les déploiements lourds parce que ces décisions doivent être prises module par module.
Taille de la base de données : la fenêtre cutover
Le script de migration Odoo doit charger chaque enregistrement, le réécrire dans le nouveau schéma et l'écrire à nouveau. Sur une base de 5 Go, ça prend une heure. Sur une base de 500 Go, ça prend une nuit. Sur 500 Go ou plus, on bascule en mode incrémental avec staging, où le script tourne d'abord sur une copie de la production pendant des jours, puis seuls les delta du dernier jour sont rejoués lors de la fenêtre de cutover. Le multiplicateur monte à 2,0x pour le bucket « très grande » parce que ce mode incrémental demande son propre pipeline et sa propre supervision.
Tolérance au temps d'arrêt : le coût du zéro-downtime
Une mise à niveau week-end avec 24 heures d'arrêt est de loin la moins chère, parce qu'on bascule à froid : on stoppe la production, on tourne le script de migration sur les données live, on teste, on remet en route. Une fenêtre de 4 à 12 heures (overnight) demande un dry-run plus rigoureux, parce qu'il n'y a pas de marge si quelque chose dérape. Une fenêtre quasi nulle (sous 2 heures) demande une bascule blue-green : on monte la nouvelle version en parallèle, on synchronise les écritures via réplication ou logs, on bascule le routeur d'un coup. Le multiplicateur 1,7x couvre l'infra additionnelle (deux environnements de production) et les rounds supplémentaires de QA sur le mécanisme de bascule.
Scénarios de mise à niveau typiques
Quatre projets anonymisés tirés de l'archive Octura 2024 à 2026, avec les fourchettes et les durées réelles.
Scénario 1 : Odoo 16 vers 17, équipe interne dev, 7 à 10 k$
Une PME tech qui tourne sur Odoo 16 depuis un an, équipe Python interne, 2 petits modules sur mesure, pas d'OCA. DB de 3 Go, week-end OK. Le saut de version est petit (16 vers 17), les multiplicateurs sont au plancher. Total facturé : 8 200 $ pour le support et la validation ; le client a porté les 2 modules lui-même. Durée : 3 semaines, dont 2 en attente côté client.
Scénario 2 : Odoo 13 vers 17, distributeur, 28 à 42 k$
Un distributeur multi-entrepôts au Vermont, Odoo 13 depuis 4 ans, 6 modules sur mesure (workflow approbations, intégration Shopify maison, rapports BI), 8 modules OCA (account_financial_report, web_responsive, etc.). DB de 18 Go, fenêtre overnight acceptée. Quatre sauts de version cumulés, dont la refonte comptable 13 vers 14. Total facturé : 34 600 $, sur 9 semaines. Hypercare : 2 semaines incluses.
Scénario 3 : Odoo 10 vers 18, manufacturier, 55 à 80 k$
Un manufacturier en Beauce, Odoo 10 depuis 7 ans, 8 modules sur mesure dont un module MRP étendu critique, 12 modules OCA. DB de 80 Go. Fenêtre overnight. Huit sauts de version cumulés. La complexité venait du module MRP : 240 heures pour le porter à travers 8 versions, parce que les hooks ORM utilisés en v10 n'existaient plus en v18 et ont dû être réécrits via la nouvelle API d'héritage de modèle. Total facturé : 67 400 $, sur 14 semaines. Hypercare étendue : 4 semaines.
Scénario 4 : Odoo 8 vers 19, e-commerce zéro-downtime, 90 à 140 k$
Un retailer en ligne, Odoo 8 depuis 11 ans, 11 modules sur mesure (panier custom, intégration paiements maison, moteur de promotions, etc.), 14 modules OCA. DB de 320 Go. Tolérance quasi nulle (sous 2 heures), parce que la boutique vend 24/7. Onze sauts de version, cutover blue-green obligatoire. On a monté Odoo 19 en parallèle pendant deux mois, synchronisé via réplication WAL et un bus d'événements maison, puis basculé le routeur HTTP en 18 minutes un mardi à 3 h du matin. Total facturé : 112 800 $, sur 18 semaines. Équipe : 4 personnes en pointe.
Ce que ce calculateur ne couvre pas
Si vous migrez depuis QuickBooks, NetSuite, SAP ou tout autre système non-Odoo, utilisez le calculateur de coût de migration Odoo. Le profil de coûts est très différent : l\'écart de modèle de données entre votre système et celui d\'Odoo devient le levier principal, pas le delta de version.
Nouvelles fonctionnalités. Si vous voulez profiter de la mise à niveau pour activer de nouveaux modules Odoo ou refondre des workflows, ce travail est de l\'implémentation, pas de l\'upgrade. Utilisez le calculateur de coût d\'implémentation pour ce delta.
Abonnement licence Odoo. Vous payez Odoo S.A. directement, par utilisateur et par mois. La mise à niveau de version n'impacte pas votre facture licence sauf si vous changez aussi de plan.
Hébergement. Une bascule vers Odoo.sh ou un changement d'instance auto-hébergée n'est pas un coût d'upgrade, c'est un coût d'infrastructure facturé séparément.
Formation à la nouvelle interface. Un saut majeur (v15 vers v17 par exemple) introduit un nouveau client web ; on inclut une heure de formation rapide par rôle pendant l'hypercare. La formation approfondie est facturée séparément.
Les étapes après votre estimation
L'étape suivante, c'est un appel d'audit de mise à niveau de 30 minutes avec un de nos ingénieurs Odoo seniors. On regarde votre liste de modules sur mesure, votre liste OCA, votre DB, et on vous renvoie un SOW sous 48 heures avec le plan de bascule, les jalons et le prix fixe.
Réserver un audit de mise à niveau gratuit →