Votre version est plus ancienne que vous ne le pensez
Odoo publie une version majeure chaque année et n'assure le support que des trois plus récentes. Le calcul est sans pitié : si vous êtes passé en production sur Odoo 15 en 2022, votre système tourne depuis un moment sans support officiel. Odoo 16 est sorti de la fenêtre de support au moment de la sortie de la 19. Odoo 17 est le prochain sur la liste.
« Sans support » ne veut pas dire « cassé ». Votre système traitera encore vos commandes demain matin. Cela signifie en revanche :
- Aucun correctif de sécurité. Les vulnérabilités découvertes dans le cœur restent ouvertes sur votre instance.
- Aucune correction de bug. Tout ce qui casse devient le problème de votre équipe de développement — ou le nôtre.
- Un surcoût « legacy ». Les clients Enterprise sur une version hors support peuvent se voir appliquer une majoration sur leur abonnement, généralement citée à 25 %.
- Un écosystème de modules qui se rétrécit. L'OCA et les éditeurs tiers cessent de rétroporter. Nouveaux prestataires de paiement, règles de facturation électronique, mises à jour de localisation : tout arrive sur les versions actuelles uniquement.
- Un décrochage réglementaire. C'est souvent ce point qui déclenche la décision en Europe. Les obligations de facturation électronique, les formats de déclaration de TVA et les exigences fiscales nationales sont livrés via les mises à jour de localisation — qui ciblent les versions supportées.
Plus l'écart se creuse, plus le saut coûte cher. Passer de 18 à 19 est un projet. Passer de 14 à 19 est une reconstruction avec conservation des données.
Migrer vers 19 maintenant, ou attendre Odoo 20 ?
La question est légitime, puisque Odoo 20 est attendu à l'automne 2026. Notre réponse dépend de votre point de départ :
Vous êtes en 14, 15 ou 16 — passez en 19 maintenant. Vous êtes déjà hors support et chaque mois ajoute du risque. Odoo 19 est en production depuis septembre 2025, la version est stable, l'écosystème de modules a rattrapé son retard, et son support s'étend actuellement jusqu'à septembre 2028 environ. Cela vous offre deux années tranquilles avant de reposer la question.
Vous êtes en 17 — planifiez la migration cette année. Vous êtes en limite de fenêtre de support. Migrer vers 19 vous donne la plus longue marge pour un effort donné.
Vous êtes en 18 — rien d'urgent. Évaluez les apports de la 19 au regard de votre feuille de route, et envisagez de passer directement à la 20 l'année prochaine.
Le réflexe « attendons la toute dernière version » se retourne généralement contre vous. Une version sortie le mois dernier a la couverture de modules tiers la plus faible et le plus d'aspérités. Migrer une version en retrait du tout dernier cri est presque toujours le choix le plus économique et le plus serein.
Deux chemins très différents : Enterprise et Community
C'est là que beaucoup de budgets de migration sont mal évalués. Autant être direct.
Les clients Odoo Enterprise ont accès au service de mise à niveau officiel d'Odoo. Vous soumettez une base de données, la plateforme vous la renvoie convertie vers la version cible, et vous pouvez sauter de n'importe quelle version directement vers la 19 sans passer par les versions intermédiaires. C'est inclus avec un abonnement valide et cela fonctionne bien — pour le code standard.
Odoo Community n'a pas d'équivalent. Il n'existe ni assistant de migration officiel ni procédure en un clic. Vos options réalistes :
- OpenUpgrade — le projet de l'OCA qui fournit les scripts de migration. Il gère les changements de schéma et la transformation des données, mais s'exécute version par version, et le code spécifique demande toujours un travail manuel.
- Des outils de migration tiers — plusieurs éditeurs enchaînent désormais automatiquement les étapes de version.
- Une installation propre avec export/import des données — parfois la réponse pragmatique pour de petites bases avec peu de transactions, mais vous perdez l'historique si l'export n'est pas soigneusement préparé.
Quel que soit le chemin, un point ne change pas : Odoo migre son propre code, pas le vôtre. Vos modules personnalisés restent votre responsabilité.
Ce qui casse réellement
Entre les versions 16 et 19, le cumul des changements se compte en centaines de modifications de modèles, dizaines de renommages, fusions de modules, renommages de champs et changements de contraintes. Concrètement, cela touche quatre domaines :
Les modules personnalisés. APIs dépréciées, méthodes supprimées, vues XML restructurées, règles de sécurité modifiées. Chaque modèle, vue héritée et rapport spécifique doit être revu. C'est presque toujours le poste le plus lourd du budget — et c'est du développement classique, pas quelque chose qu'un script résout.
Les modules tiers et OCA. Avant toute chose, inventoriez chaque module installé et vérifiez l'existence d'une branche 19. Parfois le module a été intégré au cœur d'Odoo : bonne nouvelle. Parfois il est abandonné, et il faut un remplaçant ou une réécriture.
Les intégrations. Boutiques en ligne, prestataires de paiement, scanners d'entrepôt, APIs externes, outils de BI. Tout ce qui dialogue avec Odoo en XML-RPC ou REST doit être testé contre le nouveau schéma — un champ renommé casse une intégration en silence.
Les rapports et documents imprimés. Les templates QWeb dérivent d'une version à l'autre. Factures, bons de livraison et étiquettes doivent être vérifiés page par page, pas supposés fonctionner.
Une migration qui ne fait pas mal
Le processus que nous suivons sur chaque projet de mise à niveau :
1. Audit. Inventaire complet des modules installés, des développements spécifiques, des intégrations et de la volumétrie. C'est de là que vient la vraie estimation — et c'est là qu'on trouve généralement des modules que personne n'a ouverts depuis trois ans. Désinstaller le poids mort est le travail de migration le moins cher qui soit.
2. Migration de test. Restaurez une copie de production sur un serveur de recette et lancez la mise à niveau dessus. La production n'est jamais touchée. Cet essai vous donne la durée réelle de conversion, sur laquelle se construit votre fenêtre d'interruption.
3. Adaptation du code. Les modules personnalisés sont portés en 19, sous contrôle de version, en parallèle du travail sur la base. Les modules tiers sont remplacés ou mis à jour.
4. Tests avec de vraies personnes. Pas seulement « est-ce que ça démarre » — des cycles métier complets. Du devis à l'encaissement. De l'achat au paiement. De l'ordre de fabrication au mouvement de stock. La clôture mensuelle. Mettez le comptable et le responsable d'entrepôt devant l'environnement de test : ils trouveront ce qu'un développeur ne verra jamais.
5. Bascule et accompagnement. Sauvegarde fraîche, migration finale, mise en production sur un créneau planifié — généralement un week-end. Puis un support rapproché les premiers jours, quand les utilisateurs découvrent une interface modifiée et que les petits détails remontent.
Délais et facteurs de coût
Une petite base avec peu de spécifique : typiquement 4 à 8 semaines de bout en bout. Une entreprise de taille moyenne avec beaucoup de développement spécifique, plusieurs intégrations et des années de données transactionnelles : 3 à 6 mois.
La conversion de la base est souvent la partie la plus rapide — une base de moins de 1 Go peut se convertir en quelques minutes. Le coût est déterminé par le volume de personnalisation, le nombre d'intégrations, le nombre de versions à franchir et l'ampleur des tests métier nécessaires. Pas par la taille de vos données.
Les erreurs que nous voyons revenir
- Migrer sans audit. On ne budgète pas ce qu'on n'a pas inventorié.
- Sauter la migration de test. Découvrir que la conversion prend six heures pendant la fenêtre de bascule fait un mauvais samedi.
- Traiter le sujet comme un projet informatique. Une migration est une revue des processus métier. Les utilisateurs doivent voir la nouvelle version avant la mise en production, pas le lundi matin.
- Reconduire du spécifique mort. La moitié du code spécifique d'une vieille instance Odoo résout des problèmes qu'Odoo standard traite désormais nativement. La migration est le bon moment pour le supprimer.
- Aucun plan de retour arrière. Une procédure de restauration testée, pas seulement « on a des sauvegardes ».
Par où commencer
Si vous êtes en 14, 15, 16 ou 17, la première étape utile n'est pas de choisir un outil — c'est de savoir ce que vous avez réellement. Un audit de vos modules, de vos développements spécifiques et de vos intégrations transforme « il faudrait sans doute migrer un jour » en un projet cadré, avec un calendrier et un chiffre.
Nous prenons en charge les migrations Odoo de bout en bout : audit, portage des modules personnalisés, migrations de test, bascule et accompagnement post-démarrage — en Community comme en Enterprise, on-premise comme sur Odoo.sh.
Réservez un échange gratuit et nous vous dirons honnêtement à quoi ressemble votre migration — y compris si la réponse est « attendez un an ».