Implémenter Odoo 19 sans rien refaire : quoi décider avant, dans quel ordre, quoi ne pas migrer et où ça coince par rapport à la 17 et à la 18

Des apps installées avant d'avoir décidé où vit la base de données. Une boutique connectée avant de nettoyer le catalogue. Des années de factures importées que personne n'ouvrira. Ce sont les erreurs d'ordre qui obligent à refaire le plus de travail, et Odoo 19 ne les change pas. Ce qu'il ajoute, en revanche, par rapport à la 17 et à la 18, ce sont des pièges qui ne figurent pas dans les guides des nouveautés.

Ce qui se décide avant de toucher à quoi que ce soit

Certaines décisions sont peu coûteuses au début et chères à défaire. Où il est hébergé : dans le plan standard d'Odoo Online, on n'installe pas de modules avec du code Python propre ; si vous allez avoir besoin d'un connecteur, l'hébergement a donc déjà décidé pour vous. Community ou Enterprise. En Espagne, quel système émet la facture légale : si la caisse ou la boutique facture déjà, Odoo ne doit pas facturer une seconde fois la même vente, et avec VeriFactu chaque facture émise laisse un enregistrement chaîné qui ne se défait pas. Et une question métier : quels processus doivent fonctionner dès le premier jour.

L'ordre réel d'un projet

1. Société avec le pays, la devise et les données fiscales corrects.
2. Plan comptable, taxes et positions fiscales.
3. Données de base : contacts, produits, variantes, listes de prix et fournisseurs.
4. Processus : vente, achat, entrepôt, facturation et encaissement, configurés et testés un par un.
5. Intégrations : boutique, marketplaces, transporteurs et banque.
6. Un cycle complet sur une copie avec des données réelles : commande, bon de livraison, étiquette, facture, encaissement et retour.
7. Soldes d'ouverture et stock à la date de coupure, puis démarrage.

La première étape semble triviale et ne l'est pas. Odoo choisit le plan comptable selon le pays de la société lors de l'installation de la Comptabilité : avec un pays erroné, c'est un plan générique qui s'installe, et le changer ensuite se heurte à des comptes qui existent déjà. La devise ne peut plus être modifiée dès qu'il y a une écriture.

Données de base : c'est ici que le projet se gagne ou se perd

Un SKU par produit, sans doublons. Des variantes sous forme d'attributs, pas des produits séparés avec la couleur dans le nom. Poids et dimensions renseignés : sans eux, pas d'étiquette de transporteur. Des contacts sans doublons et avec leur numéro de TVA. Et un responsable pour chaque bloc de données. Mieux vaut réussir du premier coup, car un produit avec des mouvements de stock ne se supprime plus, il s'archive seulement. Modèle et détail dans préparer les données de base avant de migrer.

Ce qu'il ne faut PAS migrer

La tentation est de tout reprendre, et cela n'en vaut presque jamais la peine. Dans Odoo entrent des soldes, pas l'historique : factures en attente d'encaissement et de paiement, bilan d'ouverture à la date de coupure et stock par emplacement à cette même date. Tout le reste reste dehors :

• Factures et commandes d'exercices clôturés : on les consulte dans l'ancien système ou dans un export que l'on continue de conserver.
• Anciens mouvements de stock : on importe la quantité par emplacement, pas le parcours de chaque unité.
• Produits et clients sans activité : la coupure est fixée par le métier, pas par le technicien.
• Champs que personne ne remplit et automatismes qui contournaient les limites de l'ancien logiciel. Les migrer, c'est migrer le problème.

S'il y a de l'ecommerce, la boutique vient après le catalogue

Dans une implémentation d'Odoo pour l'ecommerce, la première décision est de savoir si la boutique sera Odoo Website ou restera à l'extérieur. Avec Odoo Website, il n'y a rien à synchroniser, car la commande web est une commande client (quand c'est adapté et quand ça ne l'est pas). Si la boutique est sur Shopify ou WooCommerce, ou si vous vendez sur des marketplaces, Odoo est le stock maître et le SKU la clé commune. C'est pourquoi les intégrations viennent à la fin : un connecteur activé sur un catalogue sale répand le désordre sur tous les canaux.

Nos connecteurs publiés (Shopify, Amazon, Mirakl, Temu et le reste du catalogue) fonctionnent sur Odoo 17, 18 et 19, et la plupart aussi sur Odoo 20 (chaque fiche indique ses versions).

Les pièges d'Odoo 19 par rapport à la 17 et à la 18

Pour qui l'utilise, Odoo 19 ressemble beaucoup à la 18. Ce qui coince se trouve en dessous, dans les modules tiers. Qu'une fiche indique « compatible avec la 19 » ne garantit pas qu'il s'installe : la 19 a déplacé la catégorie des groupes d'accès vers un nouveau modèle, res.groups.privilege, et un module porté à la hâte échoue avec Invalid field 'category_id' in 'res.groups' (pourquoi il compile sans s'installer).

Le pire ne donne aucune erreur : dans la 19, _sql_constraints est ignoré avec un avertissement dans le log. Le module s'installe, les tests passent et la contrainte d'unicité qui empêchait d'importer deux fois la même commande n'est pas dans la base de données. Et la note de frais (hr.expense.sheet) de la 17 et de la 18 n'existe pas dans la 19 : un circuit d'approbation construit dessus est à refaire. Liste complète dans maintenir le même module sur Odoo 19, 18 et 17.

Quand vous n'avez pas besoin d'un intégrateur

Si vous utilisez Odoo Online, que vos processus tiennent dans le standard et qu'il n'y a ni boutique, ni marketplaces, ni transporteurs à connecter, vous n'avez pas besoin d'ingénierie : la configuration standard vous mène jusqu'au démarrage. Nous appeler a du sens quand il y a des canaux de vente, des intégrations, des modules sur mesure ou une migration avec des données à nettoyer ; c'est ce que nous faisons dans l'implémentation d'Odoo 17, 18 et 19.

Questions fréquentes

Liens utiles chez FlexigoTech