Odoo 19 vs connecteurs avec middleware : quand intégrer directement dans Odoo

Un connecteur natif dans Odoo 19 est pertinent quand Odoo commande le stock, les commandes, les expéditions et les factures : chaque statut n'existe qu'une seule fois, sur la fiche où travaille l'équipe. Un middleware est pertinent quand il suffit de transporter des données sans prendre de décisions opérationnelles, ou quand personne ne va maintenir de code dans Odoo. Connecter une API une fois n'a jamais été le problème : le problème, c'est de garder la maîtrise des commandes, du stock, des erreurs et de la traçabilité quand l'activité grandit.

La vraie différence n'est pas dans l'API

L'API d'Amazon, de Mirakl ou d'un transporteur est la même, quel que soit celui qui l'appelle. Ce qui change, c'est qui conserve le résultat et où la personne qui prépare la commande le voit : la différence est là, pas dans l'API.

Si Odoo doit réserver le stock, préparer les commandes, générer les bons de livraison, créer les étiquettes et renvoyer le suivi au canal, l'intégration native garde la traçabilité là où travaille l'équipe. Avec une couche intermédiaire, chaque étape existe en double et les deux copies ne concordent que si quelqu'un vérifie.

Quand choisir un connecteur natif dans Odoo

C'est pertinent quand Odoo est le système maître du produit, du stock, des commandes, de la logistique et de la facturation. Et aussi quand vous avez besoin de règles propres : multi-entrepôt, validations avant expédition, nouvelles tentatives, journal des appels par commande et erreurs visibles par l'utilisateur sur son écran.

Dans nos connecteurs de marketplace, l'enregistrement de chaque appel est un modèle Odoo avec la méthode, l'endpoint, les paramètres, le corps envoyé, le code et le corps de la réponse, la tentative et la durée en millisecondes, avec purge configurable. Il se filtre comme n'importe quelle liste Odoo, sans dépendre d'un tableau de bord externe.

Quand un middleware peut convenir

Si vous ne déplacez que des données simples entre deux systèmes, sans décisions opérationnelles complexes, un middleware peut accélérer le démarrage. C'est aussi le cas si plusieurs ERP vendent sur les mêmes canaux et que le stock publié doit être la somme. Et surtout si personne, ni en interne ni un partner de Odoo, ne va maintenir de code dans l'ERP.

Le risque apparaît quand l'équipe consulte trois tableaux de bord pour savoir si une commande est vendue, réservée, expédiée ou en échec : ce jour-là, le middleware a cessé de transporter et a commencé à conserver l'état.

Ce que coûte un middleware au quotidien

Le calcul qui compte n'est pas l'abonnement mensuel : ce sont les tâches qui apparaissent dès qu'il y a une couche intermédiaire et que personne ne budgète. Il y en a quatre.

1. Le double maître. Le produit est créé dans Odoo puis, en plus, mappé dans le middleware : SKU, catégorie du canal, attributs obligatoires. Chaque création, chaque changement d'EAN et chaque nouvelle variante représentent deux modifications. Avec un connecteur natif, le mapping vers le canal est un champ de plus du produit dans Odoo.
2. La réconciliation des statuts. Une commande de marketplace a trois vérités : celle du canal, celle du middleware et celle d'Odoo. Quand elles ne coïncident pas (une commande annulée sur le canal qui, dans Odoo, réserve toujours du stock), quelqu'un le découvre à la main. Avec le connecteur dans Odoo, il n'y en a plus que deux, et le statut distant est conservé tel que l'API le renvoie, à côté de la commande client, avec l'heure de la dernière synchronisation.
3. Qui consulte le journal. L'erreur d'un appel vit dans le tableau de bord du fournisseur, avec son utilisateur et sa rétention. Celui qui voit la commande bloquée dans Odoo n'a généralement pas accès à ce tableau de bord. Si le journal est un modèle Odoo, il est visible par celui qui a le problème, sur le même écran.
4. La montée de version. Quand Odoo passe de 18 à 19, le middleware promet que son côté ne change pas. Celui qui change, c'est le côté Odoo : le module passerelle du fournisseur, les champs qu'il lit et les webhooks qu'il attend. Cette migration, vous la faites quand même, au rythme du fournisseur et non au vôtre ; nous publions pour 19, 18 et 17 en même temps, comme nous l'expliquons dans maintenir un module sur trois versions.

Si vous payez déjà une couche intermédiaire et que vous soupçonnez qu'elle est superflue, le plan de bascule canal par canal se trouve dans du middleware à la connexion native dans Odoo, raconté à partir de notre propre migration d'Amazon en production.

Où se perd la traçabilité

Le point exact, c'est le bon de livraison. Dans Odoo, le bon de livraison (stock.picking) hérite de mail.thread et son statut est suivi, de sorte que chaque passage à « fait » est consigné avec la date et l'utilisateur. Avec le module de livraison, le numéro de suivi du transporteur est un champ du bon de livraison lui-même (carrier_tracking_ref). Tout cela est fourni en standard.

Ce qu'Odoo ne sait pas en standard, c'est si ce suivi est bien arrivé sur la marketplace. Avec un middleware, la chaîne commande → bon de livraison → suivi → confirmation au canal se coupe en deux : les deux premiers maillons dans Odoo, les deux derniers dans le tableau de bord du fournisseur. Le chatter du bon de livraison indique « fait », et la preuve que l'acheteur a vu son numéro se trouve dans un autre système.

Un connecteur natif referme la chaîne au même endroit. Dans notre connecteur Mirakl, valider le bon de livraison déclenche l'envoi du suivi si l'instance l'a activé, et le résultat est écrit dans le chatter : une note si l'envoi a eu lieu, une autre avec l'erreur s'il a échoué, et une autre encore si le bon de livraison n'avait pas de numéro de suivi et que rien n'a été envoyé. Les appels vers Mirakl passent par la passerelle de FlexigoTech Cloud, qui ne conserve ni n'enregistre ce qu'ils contiennent : ce qui s'est passé pour chaque envoi reste donc dans votre Odoo.

Natif n'est pas magique non plus : 32 défauts avec des tests au vert

La partie inconfortable est la nôtre : « natif » signifie que le code vit dans Odoo, pas qu'il fonctionne. Nous avons audité un connecteur de marketplace maison avant de le mettre entre les mains d'un vendeur réel. La suite affichait 236 sur 236 au vert, sur de vrais builds Odoo.sh en 19, 18 et 17. En dessous, il y avait 32 défauts réels : 20 de contrat avec l'API et 12 de version d'Odoo.

Ceux de contrat étaient des paramètres que l'API exigeait et qui n'étaient pas envoyés, et des champs de réponse lus sous le mauvais nom, qui renvoient None sans rien lever. Quatre ne sont apparus qu'en appelant l'API : l'en-tête de pagination arrivait en relatif et, à partir de la page un, aucune commande n'était importée ; un 403 pour quota ne venait pas dans le format documenté et était lu comme un manque de permissions, ce qui arrêtait toute la synchronisation. Ceux de version venaient d'Odoo lui-même : une action planifiée qui, en 17, s'exécute une fois et s'éteint toute seule, un champ de groupes dont le nom change à partir de la 19, une vue liste que la 17 rejette. La moitié ne donnait pas d'erreur : elle donnait du silence.

Le cas complet (y compris un second connecteur à 163 sur 163 au vert qui n'avait jamais écrit une seule ligne de journal) est dans les tests étaient au vert et le connecteur ne fonctionnait pas. La conclusion pour qui compare : demandez au connecteur natif la même chose qu'au middleware. Qu'il soit réellement installé sur votre version, et pas seulement qu'il compile ; qu'il ait été confronté à la spécification du fournisseur et non à ses propres mocks ; et qu'il ait fait au moins un appel réel par famille d'endpoints. Si vous en héritez d'un autre, la liste se trouve dans auditer un connecteur Odoo hérité.

Checklist de décision

• Où le stock est-il réservé, et combien de systèmes conservent une copie du disponible ?
• Qui crée le bon de livraison et l'étiquette ?
• Où voit-on l'erreur quand une API échoue, et est-ce la même personne qui voit la commande qui la voit ?
• Le suivi revient-il automatiquement au canal, et est-il consigné sur le bon de livraison qu'il est revenu ?
• Pouvez-vous relancer sans dupliquer commandes ou expéditions ?
• Qui migre le connecteur à la sortie de la prochaine version d'Odoo, et dans quel délai ?
• A-t-il été réellement installé sur votre version et testé contre le sandbox du fournisseur ?

L'ordre dans lequel on connecte plusieurs canaux dépend de celui qui publie le stock : nous le traitons dans vendre sur plusieurs marketplaces depuis un seul Odoo. Les connecteurs qui parlent déjà avec Amazon, Mirakl, ManoMano, AliExpress et les transporteurs figurent dans le catalogue et dans intégrations et automatisation Odoo ; si c'est pour votre propre logiciel, voyez connecteur Odoo pour votre logiciel.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons sur ce sujet