Odoo publie une version majeure chaque année. À l’approche d’Odoo 20, les entreprises cherchent naturellement une liste de nouveautés et une date de migration. La bonne décision ne consiste pourtant pas à migrer dès qu’un numéro de version apparaît. Elle consiste à distinguer les annonces officielles des rumeurs, à mesurer l’intérêt métier des évolutions et à vérifier la compatibilité de la base, des modules spécifiques et des connecteurs. Au 21 septembre 2026, la documentation publique de référence reste celle d’Odoo 19 ; cet article sera donc actualisé lorsque les notes officielles d’Odoo 20 seront disponibles.
Ce qui est confirmé et ce qui doit encore être vérifié
Une capture d’écran, une démonstration ou une annonce isolée ne constitue pas une spécification de production. Les fonctions réellement disponibles peuvent dépendre de l’édition Community ou Enterprise, du pays, de l’hébergement et de la date de déploiement. Avant de promettre une nouveauté à une équipe, il faut vérifier la documentation officielle, les notes de version et le comportement sur une base de test.
Odoo 19 a renforcé les usages liés à l’intelligence artificielle, aux agents, à la recherche en langage naturel et aux automatisations. Il est raisonnable de surveiller la continuité de ces axes, mais pas de présenter une fonction Odoo 20 comme acquise tant qu’elle n’est pas officiellement documentée. Cette distinction protège le projet contre des choix fondés sur une fonction absente, modifiée ou réservée à une autre offre.
- Documentation et notes officielles comme sources prioritaires
- Vérification de l’édition et de l’hébergement concernés
- Test sur une base isolée avant toute décision
- Mise à jour de l’article après publication officielle
Pourquoi préparer la migration avant la sortie
La préparation ne dépend pas de la liste finale des nouveautés. Une entreprise peut déjà inventorier ses applications, ses modules personnalisés, ses connecteurs, ses volumes de données et ses rapports critiques. Cette cartographie montre les composants standards, ceux qui devront être adaptés et ceux qui peuvent être supprimés parce qu’ils ne sont plus utilisés.
Il faut également documenter les scénarios qui ne doivent jamais être interrompus : création d’un devis, confirmation d’une commande, réception, livraison, facturation, clôture comptable ou traitement de la paie. Ces scénarios deviennent la base de la recette. Une migration est réussie lorsque les opérations et les contrôles restent fiables, pas simplement lorsque la nouvelle interface s’ouvre.
- Inventaire des modules et développements
- Liste des API et services externes
- Scénarios critiques documentés
- Responsables métier identifiés pour la recette
Auditer les développements et les intégrations
Les modules spécifiques représentent souvent la partie la plus sensible. Leur code doit être relu pour repérer les dépendances aux vues, modèles, méthodes ou bibliothèques susceptibles d’évoluer. Les personnalisations directes du cœur sont particulièrement risquées, car elles compliquent la comparaison et rendent les corrections difficiles à isoler.
Les connecteurs avec un site eCommerce, une banque, un transporteur, une application mobile ou une plateforme métier doivent être testés dans les deux sens. La recette doit couvrir les erreurs, les doublons et les reprises après interruption. Un échange qui fonctionne sur quelques enregistrements peut échouer à grande échelle si la pagination, les délais ou les limites d’API ne sont pas maîtrisés.
Construire un environnement de test représentatif
Une copie anonymisée ou correctement protégée de la base permet d’évaluer la migration avec des volumes réalistes. L’environnement de test doit reprendre les modules, paramètres et données nécessaires sans envoyer d’e-mails, de paiements ou de messages réels. Les utilisateurs référents exécutent ensuite leurs scénarios et consignent les écarts.
Il faut mesurer la durée des traitements, contrôler les écritures, comparer les stocks et vérifier les documents imprimés. Les tests automatisés sécurisent les règles techniques, mais ils ne remplacent pas la validation fonctionnelle. Un responsable métier peut détecter en quelques minutes une incohérence qui resterait invisible dans un test purement technique.
Choisir le bon moment pour basculer
Migrer immédiatement n’est pas toujours un avantage. Une entreprise en clôture, en inventaire ou dans une période de forte activité peut attendre une fenêtre plus sûre. Le calendrier doit intégrer la stabilisation de la version, la disponibilité des modules indispensables, la correction des tests et la formation aux changements réellement utiles.
Le plan de bascule précise le gel des saisies, la dernière sauvegarde, la migration finale, les contrôles et la possibilité de retour arrière. Après le démarrage, une équipe de support suit les incidents et les demandes d’aide. DevUp Experts peut réaliser un audit de l’environnement Odoo afin de transformer cette préparation en plan de migration chiffré et priorisé.
Relier ces principes à votre projet Odoo
Notre approche de conseil Odoo transforme ces principes en décisions de périmètre et en priorités métier. La méthode d’intégration Odoo encadre ensuite la configuration, les tests et l’adoption, tandis que nos réalisations DevUp Experts montrent comment cette démarche s’adapte à différents contextes opérationnels.
Questions fréquentes
Odoo 20 est-il déjà disponible ?
Au 21 septembre 2026, nous ne présentons comme confirmées que les informations publiées officiellement par Odoo. La disponibilité doit être vérifiée selon l’édition, l’hébergement et le calendrier officiel.
Faut-il migrer dès la sortie d’Odoo 20 ?
Non. La décision dépend de la valeur des évolutions, de la compatibilité des modules et de la période d’activité. Une base de test et une recette complète doivent précéder la bascule.
Que peut-on préparer dès maintenant ?
L’inventaire des modules, la documentation des flux, l’audit du code, la liste des intégrations et les scénarios de recette peuvent être préparés sans attendre les notes finales.