Du middleware à la connexion native dans Odoo : quand migrer vaut la peine et comment le faire sans arrêter l'activité

Supprimer le middleware vaut la peine quand cette couche conserve un état qu'Odoo devrait détenir : le stock publié, le statut réel de chaque commande, le suivi qui retourne vers le canal. Cela n'en vaut pas la peine quand elle ne fait que transporter : elle reçoit un fichier et le dépose ailleurs sans rien décider. C'est toute la règle. Ce qui suit : quand la réponse honnête est « ne migrez pas » et comment faire le changement sans cesser de traiter les commandes, raconté à partir de notre propre migration vers des connecteurs qui vivent dans Odoo, en production.

Ce que le middleware vous coûte en travail quotidien, pas en argent

L'argument de supprimer une couche, nous l'avons déjà fait avec la facture électronique dans SERES depuis Odoo, et la comparaison de fond se trouve dans Odoo 19 face aux connecteurs avec middleware. Avec les marketplaces et les transporteurs, c'est la même chose multipliée par les commandes du jour : quatre tâches que personne ne budgétise.

La ligne du log mérite une mise en garde : « nous l'avons dans Odoo » ne veut pas dire que c'est écrit. Lors de l'audit de notre connecteur Mirakl, la fonction qui enregistrait chaque appel demandait if not log_model, et l'assistant renvoyait un recordset vide quand tout se passait bien ; dans Odoo, un recordset vide est faux, donc l'enregistrement n'a rien fait dès le premier jour. La preuve était en production : la séquence de cette table était toujours à NULL après des mois de crons. Aujourd'hui la vérification est if log_model is False.

Quand il ne faut pas migrer : les trois cas clairs

1. Plusieurs ERP. Si Odoo gère une société et qu'un autre système en gère une autre, et que les deux vendent sur les mêmes canaux, le middleware est le seul endroit où le stock publié est la somme des deux.
2. Orchestration entre tiers. Si le flux est marketplace → opérateur logistique externe → transporteur et qu'Odoo ne l'apprend qu'à la fin, la couche pilote des systèmes qui ne sont pas les vôtres.
3. Personne pour maintenir Odoo. Un connecteur natif est du code à l'intérieur de votre ERP. Si personne, en interne ou partner de Odoo, ne va faire ce travail, le middleware avec son abonnement est l'option économique.

Le plan de migration sans arrêter l'activité

Quatre étapes et un principe : la connexion native entre en lecture seule et n'écrit pas vers l'extérieur tant qu'elle n'a pas lu pendant plusieurs jours la même chose que le middleware. Nous l'avons appliqué en juin 2026 en remplaçant, sur notre propre production Odoo.sh, un ancien module Amazon par le connecteur qui appelle SP-API depuis Odoo.

1. Inventaire des flux, avec direction

Une ligne par flux : commandes entrantes, stock et prix sortants, suivi sortant, annulations et retours entrants, factures envoyées. Pour chacun, direction, fréquence et déclencheur (cron, webhook ou personne). Une marketplace Mirakl donne entre huit et douze lignes ; un transporteur, trois ou quatre ; une plateforme de signature, deux.

2. Ordre : lecture avant écriture

Le connecteur natif s'installe avec toutes les écritures vers le tiers désactivées : dans le nôtre, un interrupteur global plus un indicateur par compte pour chaque action sortante. Il ne fait que lire les commandes, les statuts et l'inventaire ; le middleware continue d'écrire et personne ne cesse de servir. C'est ici qu'est apparu le premier défaut de la bascule : le nouvel importateur vérifiait si une commande existait en regardant sa propre table, toute neuve et vide, et non les commandes clients que l'ancien système avait déjà créées. Résultat : dix-sept commandes clients dupliquées et confirmées, chacune réservant à nouveau du stock. La correction a consisté à chercher la référence de la marketplace dans sale.order avant de créer quoi que ce soit. La règle : on dédoublonne par rapport à la destination, jamais par rapport à la table intermédiaire du connecteur lui-même.

3. Période en parallèle avec comparaison quotidienne

Une ou deux semaines avec les deux systèmes qui lisent le même canal et, chaque matin, une courte liste : commandes importées par l'un et pas par l'autre, statuts qui ne coïncident pas, SKU non rapprochés. Zéro deux jours de suite, et alors la première écriture.

4. Bascule par canal, et écritures uniquement vers l'avant

On bascule un canal, pas tous. Et en activant les écritures, seulement celles que déclenche une transition : confirmer l'expédition lors de la validation d'un bon de livraison est sûr, car cela arrive une fois par commande qui part réellement. Ce qui n'est pas sûr, c'est un cron qui parcourt des enregistrements existants et les renvoie. Lors de notre bascule, il restait 534 bons de livraison historiques effectués et marqués « en attente de synchronisation » par l'ancien module ; le cron de relance les a trouvés et a envoyé 28 confirmations d'expédition à Amazon en quatre minutes, avant que nous ne l'éteignions. La leçon : avant d'activer un cron de balayage, réconciliez l'historique restant dans l'état que ce cron recherche.

Les données historiques : ce qu'on migre et ce qu'on laisse en lecture seule

On migre ce qui peut encore changer : commandes ouvertes, le mapping SKU ↔ référence du canal, envois dont le suivi n'est pas encore remonté à la marketplace et retours en cours. On ne migre pas l'historique des appels ni les commandes clôturées : on demande un accès en lecture seule à son panneau pendant le délai de réclamation. Lors de notre bascule, les données métier n'ont pas été touchées : 1 838 commandes clients et 13 236 produits sont restés où ils étaient.

Comment vérifier que la connexion native fonctionne avant la bascule

Avec un vrai build d'Odoo et le sandbox du tiers, pas avec des mocks. Nous l'avons raconté chiffres à l'appui dans les tests étaient au vert et le connecteur ne fonctionnait pas : un connecteur avec 236 tests sur 236 au vert sur Odoo 19, 18 et 17 cachait 32 vrais échecs, et un autre avec 163 sur 163 n'avait jamais écrit une seule ligne de log. Les trois vérifications qui comptent :

• La fenêtre de synchronisation demande ce qui a changé, pas ce qui a été créé. Nous l'avons fait deux fois : le connecteur Mirakl envoyait start_date (création) au lieu de start_update_date, et celui d'AliExpress filtrait par date de création depuis le dernier passage. Dans les deux cas, une commande créée le matin et expédiée l'après-midi ne rentrait plus dans la fenêtre et son statut dans Odoo restait figé.
• Le log contient des lignes. Après la première importation, comptez les enregistrements du modèle de log. Zéro signifie que rien n'est écrit, pas qu'il n'y a pas d'erreurs.
• La trace est dans la fiche. Depuis une commande importée, vous devez pouvoir atteindre la commande client, le bon de livraison et le suivi sans quitter Odoo.

Ce qui reste ensuite : qui maintient le connecteur à la version suivante d'Odoo

C'est la partie que le middleware vous épargnait et qui est désormais la vôtre. Chaque version d'Odoo modifie quelque chose que touche un connecteur : en 19, read_group est marqué comme obsolète dans l'ORM lui-même ; en 18, les vues liste sont passées de <tree> à <list> ; en 17, un ir.cron sans numbercall s'exécute une fois et s'éteint tout seul. Aucun des trois ne provoque d'erreur à l'installation. Nos connecteurs sont publiés pour 19, 18 et 17 à la fois et testés sur de vrais builds de chaque série. Avant de migrer, décidez qui fait ce travail : votre équipe, un partner de Odoo, ou l'auteur du connecteur s'il le publie pour plusieurs versions et le migre dès la sortie de la nouvelle.

Si le connecteur est destiné à votre propre logiciel, dans connecteur Odoo pour votre logiciel nous expliquons comment nous procédons avec des partenaires technologiques ; dans le catalogue figurent ceux qui dialoguent déjà avec Amazon, Mirakl, ManoMano, AliExpress et les transporteurs. Avec plusieurs canaux, l'ordre de bascule dépend du canal qui publie le stock : nous en parlons dans vendre sur plusieurs marketplaces depuis un seul Odoo et stock en temps réel pour les marketplaces.

Checklist de décision

• Le middleware conserve-t-il du stock, des statuts de commande ou du suivi qu'Odoo n'a pas ? S'il ne fait que transporter des fichiers, ne migrez pas.
• Un seul ERP, ou plusieurs qui vendent sur les mêmes canaux ? Odoo apprend-il la commande au début du flux ou à la fin ?
• Qui migre le connecteur vers la version suivante d'Odoo, et quand ?
• Savez-vous combien d'enregistrements historiques restent dans l'état que recherche un cron de relance ?

Si vous voulez que quelqu'un examine votre cas avec ces critères, la façon dont nous travaillons est décrite dans services et solutions.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons à ce sujet