Mises à jour Odoo
Une mise à jour Odoo n'est pas un 'cliquez ici'. C'est un projet avec un scope, un budget, un plan de tests et une date de cut-over — et la maturité avec laquelle vous le traitez détermine si l'atterrissage est propre ou si vous cassez votre business pendant deux semaines.
Nous avons fait upgrader des clients de v12 vers v17, v14 vers v18, v16 vers v19. Certaines ont pris deux semaines, d'autres deux mois. La variable n'est pas tant l'écart de version que la quantité de code custom, le nombre de modules OCA en usage et la discipline de l'équipe.
Ce guide est le playbook que nous suivons en interne pour chaque mission d'upgrade. Si vous ne retenez qu'une chose : ne jamais upgrader en prod, ne jamais sauter les cycles de test, et ne jamais laisser l'upgrade devenir 'tant qu'à y être, refaisons aussi…'. La discipline de scope sauve le projet.
Pourquoi upgrader — et pourquoi maintenant
Chaque version majeure d'Odoo est supportée trois ans. Après : plus de correctifs de sécurité, plus de support Enterprise, plus de mises à jour de modules sur l'App Store. Rester sur une version non supportée, c'est accumuler du risque et de la dette — et vous upgradez quand même au final, juste plus tard et plus mal.
Au-delà du support, chaque version majeure apporte de vraies améliorations : meilleure UX, rapports plus rapides, fonctionnalités neuves dans des modules que vous utilisez déjà. Nous avons vu des clients récupérer des heures de travail mensuel juste en passant de v14 à v17 tellement le rapprochement comptable s'est amélioré.
- Chaque version majeure supportée trois ans — rester en arrière = dette de sécurité et de fonctionnalité
- Après la coupure de support : plus de correctifs sécu, plus de support Enterprise, plus de MAJ apps
- Les nouvelles versions apportent UX, perf et fonctionnalités sur des modules déjà utilisés
- Upgrader plus tard = upgrader moins bien — la dette se compose version après version
- Tous les deux ans est une cadence saine pour la plupart des PME
Ce qui change réellement entre versions
Le modèle de données du cœur évolue : champs renommés, modèles éclatés, nouveaux modules introduits, anciens dépréciés. L'outil officiel d'upgrade gère le standard, mais ne peut rien savoir de vos champs, vues, workflows custom. C'est votre responsabilité — et votre coût.
Du code custom écrit pour v14 ne tournera pas nécessairement sur v17. Les signatures de méthodes changent, le comportement ORM change, la couche JS change (adoption OWL). Plus votre empreinte custom est grosse, plus l'upgrade est gros. C'est l'une des raisons pour lesquelles nous poussons les clients à garder la personnalisation légère.
- Les modèles standards évoluent — l'outil Odoo gère ceux-ci
- Champs, vues, workflows custom = votre responsabilité
- Le code Python custom peut nécessiter des réécritures — signatures, comportement ORM
- La couche JS a profondément changé (OWL) — l'ancien QWeb / JS legacy nécessite souvent des MAJ
- Les modules OCA ont besoin de leur propre version upgradée — vérifier la disponibilité par module
Le chantier d'upgrade — trois environnements, deux cycles
Nous travaillons toujours avec au moins trois environnements : une copie de prod (référence figée), un staging d'upgrade (où l'upgrade tourne et est testée), et un UAT final (où les utilisateurs valident). Deux cycles de test minimum — un pour trouver les problèmes, un pour confirmer les corrections.
La cut-over vers la prod est répétée de bout en bout sur le staging. On la chronomètre, on documente chaque étape, on identifie les points de décision de rollback. Le week-end de cut-over réel est alors une opération connue, pas une expérience.
- Trois environnements minimum : copie prod, staging upgrade, UAT
- Deux cycles de test minimum — trouver les problèmes, confirmer les fixes
- Cut-over répétée de bout en bout sur staging, chronométrée et documentée
- Points de décision de rollback définis — à quelle étape on annule
- UAT signée par le métier avant la planification de la cut-over
Code custom, OCA et dépendances qui mordent
Inventoriez tous les modules custom et OCA en usage. Pour chacun, décidez : upgrader (et budgétiser), supprimer (et migrer le cas d'usage vers le standard), ou remplacer (par un autre module). Cette décision pilote 60% du coût d'upgrade.
Les modules OCA sont géniaux jusqu'à l'upgrade. Chaque module a son mainteneur communautaire ; certains sont à jour pour la nouvelle version le jour J, d'autres mettent six mois, certains jamais. Nous vérifions toujours la disponibilité OCA pour la cible avant de chiffrer — les surprises ici ruinent les budgets.
- Inventorier tous les modules custom et OCA — pour chacun, décider upgrade / drop / remplacement
- La réécriture custom = 60% du coût d'upgrade pour les implémentations typiques
- Disponibilité OCA pour la version cible vérifiée avant chiffrage
- Certains modules OCA ne sont jamais upgradés — prévoir remplacement ou refactor
- L'upgrade est un excellent moment pour supprimer les customs inutilisés — soyez impitoyables
Week-end de cut-over et post-go-live
Planifier la cut-over sur une période de faible activité — typiquement un week-end. Verrouiller la prod, lancer l'upgrade finale depuis les dernières données prod, lancer les smoke tests, switcher DNS / utilisateurs, monitorer. La plupart de nos cut-overs tiennent dans une fenêtre vendredi soir – dimanche soir.
La première semaine post-upgrade est intensive. Hyper-care de l'équipe d'implémentation, standups quotidiens avec les key users, triage rapide des incidents. La plupart des incidents sont mineurs (vues, permissions, petits écarts) ; quelques-uns nécessiteront du code. Prévoyez-le.
- Cut-over sur fenêtre de faible activité — typiquement vendredi soir – dimanche soir
- Upgrade finale depuis les dernières données prod, pas depuis un snapshot staging
- Smoke tests scriptés et exécutés avant le retour des utilisateurs lundi
- Hyper-care semaine 1 avec standups quotidiens — 80% des incidents fixés en 5 jours
- Plan de communication aux utilisateurs — quoi de neuf, quoi a changé, où poser des questions
Erreurs d'upgrade qui rendent les projets moches
Voici les erreurs que nous voyons le plus souvent quand les clients tentent l'upgrade sans nous.
- Upgrade 'rapide' en prod sans staging — business cassé, pas de rollback.
- Laisser le scope déraper en redesign — chaque workshop ajoute du travail et la date glisse.
- Ne pas inventorier la disponibilité OCA — découvrir en semaine 3 qu'un module clé n'est pas prêt.
- Pas de cycle UAT — le go-live expose les problèmes à tous les utilisateurs en même temps.
- Oublier les intégrations — le flux EDI, la sync e-commerce, les exports BI doivent tous être testés.
Métriques qui prouvent que l'upgrade s'est bien passée
Nous suivons celles-ci sur les deux semaines post-cut-over. Upgrade saine = chiffres sains.
- Cut-over terminée dans la fenêtre prévue — pas de débordement sur les heures business du lundi.
- Smoke tests passés avant le retour des utilisateurs lundi matin.
- Nombre d'incidents P1/P2 en semaine 1 sous le seuil défini (typiquement <10).
- Toutes les intégrations (EDI, e-commerce, paiement, BI) opérationnelles d'ici mardi.
- Sondage de satisfaction utilisateurs à +2 semaines au-dessus de 75% positif.
Comment nous menons les upgrades Odoo chez Flydoo
Nous démarrons par une discovery : inventaire des modules custom, des dépendances OCA, des intégrations, de la liste des irritants à régler tant qu'on est dedans. De la discovery vient un devis à scope figé — incluant la décision drop / replace / upgrade par module.
Ensuite c'est le playbook standard : staging d'upgrade, deux cycles UAT, répétition de cut-over, week-end de cut-over, hyper-care. Nous ne laissons jamais le scope déraper pendant l'upgrade — les demandes d'amélioration vont sur la prochaine release trimestrielle, pas sur la cut-over.
- Discovery : inventaire custom + OCA + intégrations + irritants
- Devis à scope figé avec décision drop / replace / upgrade par module
- Trois environnements : copie prod, staging upgrade, UAT
- Deux cycles UAT minimum, cut-over répétée de bout en bout
- Hyper-care semaine 1, dérive de scope reportée à la release trimestrielle suivante
Checklist pratique avant de planifier votre upgrade Odoo
À dérouler avec votre IT et le product owner Odoo. La majorité cochée = prêt à planifier.
- Inventaire des modules custom complet avec décisions : upgrade / drop / remplacement
- Disponibilité des modules OCA vérifiée pour la version cible
- Liste des intégrations documentée avec plans de test (EDI, e-commerce, BI, paiement)
- Trois environnements provisionnés : copie prod, staging upgrade, UAT
- Deux cycles UAT planifiés avec les key users
- Week-end de cut-over convenu et communiqué au métier
- Plan de rollback documenté et répété
- Plan d'hyper-care défini : qui, quand, comment escalader
À retenir
- Upgrader tous les deux ans est une cadence saine — rester en arrière compose le risque
- Code custom et OCA = 60% du coût d'upgrade — inventorier impitoyablement
- Trois environnements minimum : copie prod, staging upgrade, UAT
- Cut-over répétée de bout en bout sur staging — ne jamais improviser le week-end réel
- La discipline de scope compte — ne pas laisser l'upgrade devenir un redesign
- L'hyper-care de la semaine 1 attrape et fixe 80% des incidents post-upgrade
Questions fréquentes
Peut-on sauter des versions, par exemple v14 vers v17 directement ?
Oui, l'outil d'upgrade gère les sauts multi-versions. Le risque ne croît pas linéairement avec l'écart — il croît avec la quantité de code custom à porter et l'évolution du paysage OCA. Nous avons fait v12 → v17 d'un coup, et v15 → v16 plus long à cause d'un module manufacturing très customisé. Planifier sur l'empreinte custom, pas juste l'écart de version.
Combien coûte une upgrade Odoo ?
Pour une petite PME en standard avec un ou deux champs custom, quelques milliers d'euros. Pour une moyenne entreprise avec une douzaine de modules custom, dépendances OCA et intégrations, typiquement 15-50 k€. Pour un setup multi-entités complexe avec beaucoup de custom, six chiffres est réaliste. Le moteur de coût est le code custom, pas l'upgrade elle-même.
Doit-on upgrader et ajouter des nouvelles fonctionnalités en même temps ?
Nous le déconseillons fortement. Une upgrade = parité — mêmes processus métier, nouvelle version. Les nouvelles fonctionnalités sont un projet séparé, idéalement après stabilisation de l'upgrade. Les mélanger rend le scope ingérable et le rollback impossible. Laisser deux mois de tassement, puis construire neuf.
Odoo Online (SaaS) est-il upgradé automatiquement ?
Oui — Odoo gère l'upgrade pour les clients SaaS, typiquement une fois par an. Le tradeoff est moins de contrôle sur le timing et sur les modules custom installables. Pour les PME belges, nous recommandons souvent Odoo.sh ou le self-hosting précisément parce qu'ils permettent de contrôler le calendrier et la surface de personnalisation.
Et si l'upgrade expose des problèmes de qualité de données ?
C'est en fait l'un des bénéfices — et l'une des surprises. Les upgrades exposent souvent des écarts de données que la version précédente tolérait. Nous voyons ça en positif : on nettoie pendant la fenêtre d'upgrade et on a une base plus saine derrière. La douleur est réelle mais l'issue est bonne.
Besoin d'aide pour appliquer tout cela à votre contexte ? Parlons-en.