Migration d'Odoo 17 vers Odoo 18 : quels changements, quelles ruptures et comment se préparer

Odoo publie une version majeure chaque année, et chaque mise à niveau apporte de nouvelles fonctionnalités, des améliorations de performances et, inévitablement, des modifications majeures. La migration d'Odoo 17 vers Odoo 18 nécessite une planification minutieuse, surtout si vous exécutez des modules personnalisés ou si vous comptez sur des modules complémentaires communautaires. Ce guide couvre tout ce que vous devez savoir sur la migration Odoo 17 vers 18 : changements clés, pannes potentielles, étapes de préparation et stratégies de test.

Pourquoi passer à Odoo 18 ?

Odoo 18 introduit des améliorations significatives sur la plateforme :

• Nouveaux composants OWL 3 : Composants frontend réécrits avec des performances et une expérience de développement améliorées
• Fonctionnalités basées sur l'IA : Notation prédictive des leads, suggestions intelligentes de rapprochement bancaire et création de contenu assistée par l'IA
• Améliorations des feuilles de calcul : Intégration native de feuilles de calcul avec données Odoo en temps réel, tableaux croisés dynamiques et édition collaborative
• Mises à niveau de fabrication : Planification de la production, portail de sous-traitance et interface pour tablette d'atelier améliorés
• Performances : Chargements de pages 15 à 25 % plus rapides grâce au regroupement d'actifs optimisé et au chargement différé
• Créateur de sites Web : Nouveaux blocs glisser-déposer, options de personnalisation du thème et édition mobile améliorée

Rester sur des versions obsolètes signifie manquer des correctifs de sécurité, perdre l’accès aux mises à jour des modules communautaires et accumuler une dette technique qui rend les migrations futures plus difficiles.

Chronologie : combien de temps prend une migration Odoo ?

| Complexité | Modules personnalisés | Chronologie estimée | |---|---|---| | Standard (pas de code personnalisé) | 0 | 1-2 semaines | | Faible (quelques champs/vues personnalisés) | 1-5 | 2-4 semaines | | Moyen (flux de travail personnalisés) | 5-15 | 4-8 semaines | | Élevé (personnalisations profondes) | 15+ | 8-16 semaines |

Ces délais incluent l'analyse, la migration, les tests et la mise en service. La plus grande variable est la complexité du module personnalisé.

Dernières modifications dans Odoo 18

Modifications du cadre OWL

Odoo 18 poursuit la migration vers OWL 3. Si vos modules personnalisés incluent des composants JavaScript frontend, attendez-vous à ces changements :

Modifications clés du OWL :

• Cycle de vie des composants : willStart et willUpdateProps sont remplacés par les hooks setup() et onWillStart
• Compilation de modèles : les modèles QWeb se compilent désormais en JavaScript optimisé au moment de la construction plutôt qu'à l'exécution.
• Injection de service : Accédez aux services via le modèle this.env.services exclusivement ; les importations directes sont déconseillées
• Regroupement d'actifs : La structure du bundle web.assets_backend a changé ; mettez à jour vos déclarations de patrimoine __manifest__.py

Exemple de migration :

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

Modifications du back-end Python

Modifications du modèle et des champs :

• fields.Monetary nécessite désormais que currency_field soit explicitement déclaré (la valeur par défaut n'est plus currency_id)
• Le décorateur @api.multi a été entièrement supprimé (obsolète depuis la v13, mais certains modules communautaires l'utilisaient toujours)
• Changement de comportement sudo() : sudo() sans arguments utilise désormais explicitement le SUPERUSER plutôt que l'utilisateur OdooBOT
• search_count() accepte désormais un paramètre facultatif limit pour l'optimisation des performances

Méthodes obsolètes de mise à jour :

| Obsolète (v17) | Remplacement (v18) | |---|---| | fields.Many2one.search() | fields.Many2one avec l'attribut domain | | _register_hook() | _post_init_hook dans le manifeste | | SQL direct dans les modèles | self.env.cr.execute() avec un paramétrage approprié | | Champ website.published | website.is_published (renommé) |

Modifications de la vue et du modèle

• Vue Formulaire : Le wrapper sheet est désormais obligatoire pour toutes les vues de formulaire (auparavant facultatif)
• Vue en liste : La balise tree est officiellement renommée en list (l'alias rétrocompatible fonctionne toujours mais déclenche des avertissements de dépréciation)
• Vue Kanban : QWeb t-esc est désormais la valeur par défaut ; t-raw nécessite un consentement explicite pour la sécurité
• Rapport QWeb : Moteur de rendu PDF mis à jour ; tester tous les rapports imprimés pour les modifications de mise en page

Modifications du schéma de base de données

Odoo 18 inclut des changements structurels dans les tables principales :

• sale.order.line gagne de nouveaux champs pour la gestion des abonnements
• account.move.line inclut de nouvelles colonnes liées au rapprochement
• Table stock.quant restructurée pour des performances améliorées avec des inventaires importants
• Tables mail.message et mail.activity optimisées avec de nouveaux index

Ces modifications de schéma sont gérées par les scripts de migration intégrés d'Odoo pour les modules standard, mais les modules personnalisés faisant référence à ces tables nécessitent des mises à jour manuelles.

Liste de contrôle de préparation avant la migration

1. Auditez votre installation actuelle

Documentez tout avant de commencer :

• [ ] Liste tous les modules installés (officiels, communautaires et personnalisés)
• [ ] Enregistrer la version actuelle d'Odoo et le niveau du correctif
• [ ] Documenter tous les développements personnalisés (champs, modèles, vues, rapports, actions planifiées)
• [ ] Répertorier toutes les intégrations externes (passerelles de paiement, transporteurs maritimes, API tierces)
• [ ] Exporter la configuration actuelle des droits d'accès et des règles d'enregistrement
• [ ] Sauvegarder complètement la base de données de production et le magasin de fichiers

2. Vérifiez la compatibilité du module communautaire

Pour chaque module communautaire (OCA ou tiers) :

• Vérifiez si une version compatible Odoo 18 existe sur GitHub ou sur la boutique Odoo Apps
• Si aucune version compatible n'existe, décidez si vous souhaitez porter le module vous-même, trouver une alternative ou supprimer la fonctionnalité
• Contacter les responsables du module pour ETA sur les ports v18

3. Préparer les ports de modules personnalisés

Pour chaque module personnalisé, évaluez l'effort de migration :

Faible effort (1 à 3 jours par module) :

• Modules avec uniquement de nouveaux champs et des vues simples
• Aucun composant JavaScript/OWL
• Aucun remplacement des méthodes de base modifiées

Effort moyen (3-10 jours par module) :

• Modules avec composants OWL nécessitant des mises à jour
• Remplacements de méthodes de base obsolètes ou modifiées
• Rapports personnalisés nécessitant des mises à jour QWeb

Effort élevé (plus de 10 jours par module) :

• Intégration profonde avec les modules de base modifiés (comptabilité, inventaire, site Web)
• Applications frontales OWL complexes
• Modules utilisant largement des API obsolètes ou supprimées

Travailler avec des spécialistes de la migration Odoo expérimentés réduit considérablement le temps et les risques liés au portage de modules personnalisés.

Étapes d'exécution de la migration

Étape 1 : Configurer l'environnement de migration

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

Créez un environnement isolé avec :

• Une nouvelle installation du serveur Odoo 18
• Une copie de votre base de données de production
• Tous les modules personnalisés portés vers la v18

Étape 2 : Exécutez la mise à niveau de la base de données

Pour Odoo Enterprise : Utilisez le service de mise à niveau officiel d'Odoo sur upgrade.odoo.com. Téléchargez votre base de données et Odoo SA exécute les scripts de migration pour tous les modules standards.

Pour la communauté Odoo : Utilisez le projet openupgrade d'OCA. OpenUpgrade fournit des scripts de migration gérés par la communauté pour les modules standard :

1. Installez OpenUpgrade pour la version cible
2. Exécutez la migration sur votre base de données de test
3. Consultez le journal de migration pour détecter les erreurs et les avertissements.
4. Résolvez tous les problèmes et réexécutez jusqu'à ce qu'il soit propre

Étape 3 : Porter des modules personnalisés

Pour chaque module personnalisé :

1. Mettez à jour la version __manifest__.py vers 18.0.x.x.x
2. Correction du code Python (API obsolètes, signatures de méthodes modifiées)
3. Mettez à jour les composants JavaScript/OWL vers les modèles v3
4. Correction des vues XML (arborescence à liste, wrapper de feuille, modifications de modèle)
5. Exécutez la suite de tests du module et corrigez les échecs
6. Testez manuellement dans l'environnement de test

Étape 4 : Vérification des données

Après la migration, vérifiez l'intégrité des données :

• Comptabilité : Comparez les totaux de la balance de vérification entre la v17 et la v18. Ils doivent correspondre exactement.
• Inventaire : Vérifiez les quantités en stock pour un échantillon de produits de grande valeur.
• Ventes/Achats : Confirmez correctement les commandes ouvertes et leurs statuts reportés.
• Contacts : Vérifiez que les enregistrements des clients et des fournisseurs sont intacts, y compris les adresses et les coordonnées bancaires.
• Pièces jointes : Vérifiez que les documents, les images et les pièces jointes sont accessibles.

Stratégie de test

Niveau 1 : Tests automatisés

Exécutez la suite de tests complète pour chaque module installé. Corrigez tous les échecs avant de continuer.

Niveau 2 : Tests fonctionnels

Testez les workflows métier de bout en bout :

• Créer un devis, le confirmer, livrer des marchandises, créer une facture, enregistrer le paiement
• Traiter un bon de commande via le reçu et la facture fournisseur
• Exécuter un ordre de fabrication de la nomenclature au produit fini
• Effectuer un cycle complet de rapprochement bancaire
• Générer et vérifier les rapports financiers clés

Niveau 3 : Tests d'acceptation des utilisateurs (UAT)

Demandez aux utilisateurs réels de chaque service d'effectuer leurs tâches quotidiennes dans l'environnement de test pendant 5 à 10 jours ouvrables. Suivez les problèmes dans une feuille de calcul partagée ou un outil de gestion de projet.

Niveau 4 : tests de performances

Comparez les temps de chargement des pages, la vitesse de génération des rapports et les performances de recherche entre la version 17 et la version 18 avec des volumes de données de niveau production.

Stratégie de mise en ligne

Approche recommandée : migration le week-end

1. Vendredi soir : Effectuez une sauvegarde finale de la production. Gelez toutes les transactions.
2. Samedi : Exécutez la mise à niveau sur la base de données de production. Portez toutes les données de dernière minute.
3. Dimanche : Vérification complète des données et tests de fumée. Déployer sur des serveurs de production.
4. Lundi matin : Passez en direct. Surveillez de près pendant les 48 premières heures.

Préparez un plan de restauration : gardez la sauvegarde de la base de données v17 et la configuration du serveur disponibles afin de pouvoir revenir en arrière en quelques heures si des problèmes critiques surviennent.

Questions fréquemment posées

Q : Puis-je ignorer les versions et migrer directement d'Odoo 16 vers Odoo 18 ? Oui, mais c'est plus complexe. Chaque version possède ses propres scripts de migration, et le fait de sauter des versions aggrave les modifications. Le service de mise à niveau d'Odoo gère les sauts multi-versions, mais le portage de modules personnalisés nécessite de traiter les modifications importantes de chaque version ignorée. Prévoyez 50 à 100 % de temps en plus pour les migrations multiversions.

Q : Mes rapports personnalisés seront-ils interrompus pendant la migration ? Potentiellement. Les modèles de rapport QWeb changent fréquemment entre les versions en raison des structures de données mises à jour et des améliorations du moteur de rendu. Testez chaque rapport imprimé (factures, bons de livraison, bons de commande) après la migration et ajustez les modèles si nécessaire.

Q : Dois-je migrer ou repartir à zéro ? Migrez si vous disposez de plusieurs années de données historiques, de configurations complexes et d'utilisateurs formés. Repartez à zéro si votre installation actuelle est fortement personnalisée et irréparable, présente des problèmes importants de qualité des données ou si vos processus métier ont tellement changé qu'une reconfiguration serait plus rapide. La plupart des entreprises choisissent la migration pour préserver leur historique opérationnel. Consultez un partenaire conseil Odoo pour évaluer quelle approche correspond à votre situation.

Assistance à la migration professionnelle

La migration entre les versions d'Odoo est un projet technique qui bénéficie de mains expérimentées. Les services de migration Odoo d'ECOSIRE couvrent l'ensemble du processus : audit pré-migration, portage de modules personnalisés, migration de données, tests et support de mise en ligne.

Contactez notre équipe pour une évaluation de la migration et une estimation du calendrier en fonction de votre installation Odoo spécifique. Nous analyserons vos modules, vos personnalisations et la complexité de vos données pour fournir une portée et un budget précis.