1UP Distribution : de la commande Wix à l’expédition ShippingBo et aux écritures Odoo

1. Présentation du client

Comprendre le contexte business avant la solution

1UP Distribution distribue des produits sur des canaux e-commerce, marketplace et B2B. Dans le système livré, Wix apparaît comme un canal de vente nommé ; ShippingBo porte les objets de commande et d’expédition ; Odoo fournit ou reçoit les données ERP selon le flux concerné.

Cette répartition crée une contrainte simple à énoncer et difficile à exécuter : chaque système reste responsable de son domaine, tandis que le hub conserve les correspondances nécessaires. Le numéro du canal, l’identifiant ShippingBo et l’identifiant Odoo ne sont pas interchangeables ; ils doivent rester reliés à la même commande locale.

Le middleware ne se limite donc pas à transporter du JSON. Il donne une forme commune aux produits, clients, commandes, lignes, expéditions et intégrations, puis conserve les statuts et erreurs utiles à l’exploitation. Cette mémoire intermédiaire est ce qui permet de diagnostiquer un flux sans dépendre de trois interfaces tierces ouvertes côte à côte.

2. Méthode projet Dawap

Analyse, priorisation, delivery agile et sécurisation du run

La chronologie rend la priorisation lisible. En septembre 2025, le travail porte d’abord sur les utilisateurs, le catalogue, la recherche produit et l’envoi vers ShippingBo. Les canaux de vente et la lecture des commandes Wix suivent, puis les retours ShippingBo vers le middleware et les premières mises en production. Ce chemin vertical permet de vérifier une commande de bout en bout avant d’élargir la surface fonctionnelle.

Les mois suivants ajoutent facturation Odoo, synchronisation des expéditions, recherche d’intégrations, tableaux de bord et traitements planifiés. En 2026, le même produit accueille les commandes et préparations B2B, le stock par entrepôt, les achats, les fournisseurs et des diagnostics ciblés. La priorité observable n’est pas un calendrier théorique : chaque lot ferme une rupture précise de la chaîne précédente.

La qualité repose aujourd’hui sur 178 fichiers de test répartis entre niveaux unitaire, intégration et application. La CI construit des images distinctes pour `develop` et `main`, exécute les suites dans l’ordre et vérifie aussi la configuration des consommateurs Messenger. Les stacks sandbox et production séparent leurs images, leurs variables et leurs procédures d’exploitation.

3. ShippingBo exécute, Odoo structure, le hub maintient la continuité

Trois responsabilités distinctes autour d’une même commande

Le produit est organisé autour d’une séparation nette. Les canaux de vente fournissent les commandes. ShippingBo reçoit ou restitue les objets logistiques. Odoo intervient sur le catalogue, le stock, les commandes, les préparations, les factures, les achats et les fournisseurs. Le hub possède les représentations locales et orchestre les passages.

Cette séparation évite de traiter un identifiant externe comme une vérité universelle. Une commande locale conserve son numéro d’origine, son identifiant ShippingBo, son éventuel identifiant Odoo, son canal et ses intégrations. Le diagnostic peut ainsi repartir de n’importe lequel de ces repères.

Dawap a développé ce middleware avec Symfony, Messenger, Doctrine et des clients HTTP dédiés. Le choix d’un produit intermédiaire persistant répond à une contrainte métier : une commande continue d’exister et d’évoluer entre deux appels API ; elle ne peut pas dépendre d’un simple transfert synchrone.

4. Ce qui casse lorsqu’un flux n’a ni mémoire ni frontière claire

Objets manquants, états divergents et corrections trop larges

La solution traite explicitement plusieurs situations qui rendent une intégration coûteuse à exploiter : commande absente d’Odoo, préparation non réservée, quantité expédiée différente, article ShippingBo introuvable, produit bloqué, réponse Wix incomplète ou limitation d’une API. Ce ne sont pas des variantes cosmétiques ; chacune demande une décision différente.

Sans état local, une erreur située après la création ShippingBo oblige à reconstituer le chemin depuis le canal. Sans identifiants corrélés, une expédition ne peut pas être rapprochée de la commande ERP avec certitude. Sans outil de reprise ciblé, une correction risque enfin de rejouer des éléments déjà acceptés.

Le coût opérationnel se situe là : chercher le bon objet, vérifier ce qui a déjà été écrit, puis relancer uniquement ce qui manque. Le hub réduit cette zone d’ombre en conservant les ressources, les statuts, les payloads et les erreurs au niveau de chaque intégration.

Le stock illustre un autre arbitrage concret. ShippingBo refuse un stock négatif ; le pipeline doit donc transformer cette contrainte externe en règle contrôlée au lieu de transmettre aveuglément la valeur Odoo. La fiabilité vient de ces décisions explicites, pas d’une promesse abstraite de synchronisation.

5. Préserver les invariants avant d’automatiser la cadence

Identités, quantités, états et responsabilité de chaque étape

Le premier invariant est l’identité : une ressource déjà connue ne doit pas être recréée comme si elle était nouvelle. Les services distinguent ajout, mise à jour et synchronisation ; les clés d’intégration et les identifiants externes rendent ce choix explicite.

Le deuxième invariant est la quantité. Produits, stocks, lignes de commande, préparations et expéditions ne peuvent pas être rapprochés sur leur seul libellé. Les références produit, quantités mappées et états logistiques restent contrôlés à chaque frontière.

Le troisième invariant est l’exploitabilité. Un traitement planifié distribue le travail dans une file nommée ; un handler réalise une responsabilité ; un journal conserve le résultat ; des écrans et commandes permettent ensuite de rechercher ou reprendre le périmètre concerné. Cette chaîne rend l’automatisation compatible avec les exceptions réelles.

6. 1UP Distribution : plusieurs canaux, une seule histoire opérationnelle

Catalogue, ventes, logistique, ERP et B2B réunis sans les confondre

Les canaux enregistrés dans le produit portent leur type d’échange, leurs identifiants ERP et logistiques, ainsi que les capacités de synchronisation activées. Wix dispose d’un lecteur dédié qui interroge la recherche de commandes e-commerce et d’une écriture de fulfillment pour restituer l’expédition.

ShippingBo reçoit catalogues, stocks et commandes, puis expose les commandes et expéditions nécessaires au retour. Odoo intervient en lecture et en écriture sur des familles distinctes. Le produit contient aussi les vues B2B qui relient commandes, préparations, expéditions et factures.

Ce périmètre élargi ne transforme pas tous les systèmes en une base unique. Au contraire, les transports Messenger sont nommés par source, cible et ressource. Cette granularité maintient une frontière claire entre ce qui est lu, ce qui est normalisé localement et ce qui est écrit.

7. 357 jours pour passer d’un premier produit à un outil d’exploitation

Une progression lisible dans les chaînes verticales livrées

Le 8 septembre 2025 ouvre le socle. Le produit, les utilisateurs et l’intégration ShippingBo apparaissent d’abord ; la recherche, les variantes, les canaux de vente et le premier pipeline de commandes suivent dans le même mois. Une configuration de production est ajoutée le 26 septembre, au moment où les flux commencent à former une chaîne exploitable.

Octobre et novembre prolongent ce chemin vers les statuts, les expéditions, Odoo, la facturation et les commandes de reprise. L’année 2026 enrichit l’outil avec les flux B2B, les préparations, les achats, les fournisseurs, les stocks d’entrepôt, le monitoring et des contrôles de cohérence plus fins.

Jusqu’au 30 août 2026, le hub a été corrigé et durci après ses premières mises en ligne, notamment sur les payloads Odoo, la réconciliation des expéditions, Amazon Logistics et la chaîne CI. Cette continuité transforme un premier flux fonctionnel en outil d’exploitation plus robuste.

8. Technologies et choix d’architecture cible

Un middleware robuste, observable et orienté production

Le middleware a été développé en Symfony avec une architecture de services orientée intégration : connecteurs API dédiés, couche de mapping métier, journalisation des exécutions et commandes techniques pour les synchronisations planifiées.

L’environnement d’exécution est conteneurisé, avec traitements asynchrones, cache technique et persistance transactionnelle. Cette base sépare les responsabilités, conserve l’état utile entre deux échanges et donne aux reprises un périmètre explicite.

L’intégration couvre ShippingBo API, Odoo ERP API, Wix API et une API REST interne Dawap. Pour les entreprises qui cherchent ce niveau d’industrialisation : Intégration API, API logistique & shipping, API ERP et Création d’API sur mesure.

9. APIs intégrées dans le projet

Panorama des connecteurs réellement mis en production

10. Une commande traverse cinq responsabilités sans perdre son origine

Lire, normaliser, exécuter, restituer et comptabiliser

Pour Wix, le client HTTP appelle l’endpoint de recherche des commandes, vérifie le statut de réponse ainsi que la présence des commandes et de leurs métadonnées, puis transforme les données dans le modèle commun. Seules les commandes correspondant aux règles du canal poursuivent le chemin vers ShippingBo.

Wix (commande)
  -> lecteur Wix + normalisation locale
    -> file ShippingBo d'ajout ou de mise à jour
      -> commande et expédition ShippingBo
        -> middleware + journal d'intégration
          -> fulfillment Wix et écritures Odoo

La restitution vers le canal n’est pas une simple inversion du flux. Le handler d’expédition choisit l’adaptateur à partir du type d’échange ; pour `wix-api`, il crée le fulfillment sur la commande concernée. Odoo reçoit de son côté ses propres objets et règles. Le hub maintient l’unité fonctionnelle tout en respectant deux contrats de sortie différents.

11. Séparer les files, tester les contrats et isoler les environnements

La qualité vient autant des frontières que des scénarios automatisés

Sept fichiers de configuration Messenger déclarent 47 transports nommés. Les lectures Odoo, écritures Odoo, écritures middleware, lectures ShippingBo, écritures ShippingBo et retours vers les canaux sont distribués séparément. Une file bloquée sur le stock n’a donc pas besoin de masquer l’état d’un envoi de commande.

Les 178 tests présents couvrent 90 scénarios unitaires, 12 scénarios d’intégration et 76 scénarios applicatifs. La pipeline de `develop` construit l’image sandbox puis exécute successivement tests unitaires, lint de conteneur et Twig, tests d’intégration, tests applicatifs et contrat d’erreur JSON. `main` reprend la même logique avec les images de production.

Les procédures d’exploitation confirment deux stacks distinctes. La production charge ses secrets depuis un fichier exclu de Git, démarre Docker Compose, vérifie le conteneur cron et lance Supervisor avec l’environnement du conteneur PHP. Cette précision évite qu’un worker Messenger utilise par défaut la mauvaise connexion AMQP.

12. Des synchronisations doublées d’outils de lecture et de reprise

Le run ne s’arrête pas au déclenchement automatique

Le produit expose 62 commandes Symfony. Certaines lancent le cycle courant ; d’autres rejouent une période ou une liste d’identifiants ; d’autres encore diagnostiquent les ressources manquantes, réconcilient les commandes B2B supprimées d’Odoo ou recréent les factures brouillon absentes pour des commandes livrées. Cette distinction protège la production contre les reprises trop larges.

Le back-office complète ces commandes par 73 contrôleurs : recherches de produits, commandes, canaux et intégrations ; vues de détail ; rafraîchissement manuel ; monitoring Odoo ; consultation des logs applicatifs ; préparation d’expéditions B2B en plusieurs étapes. L’équipe peut partir d’un objet métier puis retrouver ses échanges, au lieu de lire uniquement une sortie technique chronologique.

Le même socle relie les besoins de connexion ShippingBo, d’intégration Odoo et d’automatisation des opérations multicanales. Ici, ces expertises ne sont pas trois prestations juxtaposées : elles se rencontrent sur la même commande.

13. Scénario terrain

Une commande Wix qui doit suivre la même chaîne que les marketplaces

Une commande Wix est lue par recherche, avec pagination et contrôle du payload. Le canal est explicitement déclaré avec le type `wix-api` ; le service refuse de lancer le flux ShippingBo si cette condition n’est pas remplie. La commande est ensuite mappée vers le modèle interne avant son envoi asynchrone.

Après l’exécution logistique, l’expédition repasse par le middleware. Le handler choisit Wix comme cible et crée un fulfillment sur la commande d’origine. En parallèle, les écritures vers Odoo suivent leurs propres files et handlers. Si une étape échoue, le journal conserve l’action, la ressource, le statut, les erreurs et le payload utiles au diagnostic.

Ce cas permet de mailler précisément vers l’intégration ShippingBo, l’intégration Odoo, les intégrations API e-commerce et, quand le sujet devient pilotage récurrent, vers l’automatisation commandes et stocks marketplace.

14. Ce que le hub change dans l’exploitation quotidienne

Localiser l’exception, préserver le déjà-fait et choisir la bonne reprise

Avant cette couche intermédiaire, une équipe doit rapprocher les objets à partir des interfaces de chaque outil et décider elle-même où reprendre. Avec le hub, la commande, ses lignes, son canal, ses identifiants externes, son expédition et ses intégrations restent consultables dans une même application.

Le premier gain observable est la précision du diagnostic : distinguer une commande absente d’Odoo d’une facture brouillon manquante, une préparation non réservée d’une expédition déjà transmise, ou une erreur Wix d’une erreur ShippingBo. Le deuxième est la précision de l’action : rafraîchir un canal, rejouer une expédition vers Odoo, resynchroniser une période ou cibler des identifiants.

Le troisième gain est la capacité d’évolution. Les achats, fournisseurs, tags, commandes B2B et préparations ont été ajoutés sans dissoudre les flux historiques dans un traitement unique. Les files et contrats spécialisés donnent un coût d’entrée clair à chaque nouvelle famille métier.

15. Un produit en production qui continue d’être durci

La maintenance fait partie de la preuve, au même titre que le premier go-live

Le passage en production apparaît dès septembre 2025, mais l’histoire ne s’y arrête pas. Les corrections de 2026 portent sur des réalités de run : payloads JSON-2 d’Odoo, quantités mappées dans les expéditions, commandes supprimées, backorders, domaines de production, démarrage des workers et synchronisation Amazon Logistics.

Cette continuité montre la valeur d’un middleware maintenu : les hypothèses du premier lot sont confrontées aux cas rencontrés, puis transformées en validations, diagnostics, tests ou commandes de remédiation. La solution gagne ainsi en précision sans masquer la diversité des systèmes reliés.

Au terme de cette période, 1UP Distribution dispose d’une chaîne où Wix, ShippingBo et Odoo conservent leurs rôles, tandis que le hub porte la continuité, l’historique et les actions d’exploitation. Le résultat n’est pas une absence promise d’incidents ; c’est la capacité concrète de comprendre où le flux s’est arrêté et de reprendre au bon endroit.

Pour explorer des cas proches, voir aussi le projet ShippingBo Faure Le Page et le projet API 1UP Distribution B2B.