Ciama : deux générations pour réunir marketplace, e-commerce et B2B dans un même OMS

1. Ciama, un cockpit construit autour des opérations réelles du vendeur

Les commandes relient les canaux aux produits, aux clients, aux stocks et à la rentabilité

Ciama est le produit métier développé par Dawap pour piloter un commerce multicanal. Il rassemble des connexions marketplace, e-commerce et ERP dans un environnement on-premise. Le compte, les fournisseurs et les canaux donnent le contexte ; les produits, offres, stocks, commandes et achats fournisseurs donnent la matière des décisions quotidiennes.

La commande occupe une position centrale. Elle prouve qu’une offre a été vendue, indique où et quand l’achat a eu lieu, rattache un client et un pays, puis porte des lignes, des quantités, un statut et des coûts. Elle alimente ensuite la marge, la Buy Box, les besoins de stock, les analyses par canal et les exports.

Le travail consolide le socle OMS entre deux générations de Ciama, bien au-delà d’un module isolé. Des études associées approfondissent ensuite des décisions particulières : calculer la marge d’une commande, exporter une recherche ou rendre les ventes B2B pilotables.

Le cœur du projet reste l’autorité de la donnée. Chaque commande doit être unique dans son canal, rattachée au bon compte et suffisamment riche pour être lue depuis plusieurs métiers. La centralisation vaut parce que ces liens restent cohérents au fil des collectes et des corrections.

2. Unifier par étapes plutôt que forcer toutes les sources dans le même moule

La source garde son lecteur ; le domaine commun reçoit un résultat normalisé

La deuxième génération sert de point de départ concret. Elle sépare les commandes par univers et fait circuler leurs imports dans des transports Messenger dédiés. Les connecteurs marketplace, e-commerce et B2B peuvent avancer indépendamment, mais chaque évolution transversale doit être répercutée dans plusieurs branches du domaine.

La troisième génération inverse cette dépendance. Le cas d’usage CollectOrdersByProvider contrôle d’abord la connexion, le fournisseur, sa version et le canal. Un orchestrateur distribue ensuite la lecture vers le bon univers, puis vers l’implémentation de la source. Le résultat revient sous la forme commune attendue par Order et OrderLine.

L’identité fonctionnelle décide enfin entre ajout et mise à jour. Ciama recherche une commande avec le couple canal-identifiant. Si elle n’existe pas, un message AddOrder est envoyé ; sinon, un message UpdateOrder prend le relais. Les lignes suivent la même logique de persistance et d’agrégation.

Le chantier ne s’arrête pas au modèle. Les écrans historiques sont redirigés vers le nouveau centre de commande, les vues par univers réemploient le même rendu, l’API OMS expose recherche et détail, et les tests couvrent les cas d’usage ainsi que les lecteurs les plus sensibles.

3. Faire entrer la commande dans Ciama par le besoin d’intégration

Le premier domaine structuré apparaît le 16 octobre 2024

La deuxième génération de Ciama existe depuis novembre 2022, mais le domaine marketplace order qui fonde cette étude apparaît le 16 octobre 2024. L’application possède alors déjà ses comptes, ses connexions et son catalogue. La commande devient la prochaine frontière : il faut collecter une vente distante, la conserver et relier ses lignes au reste du cockpit.

Les premières évolutions installent les objets de lecture et d’écriture, puis l’import asynchrone et son suivi. Amazon est décliné par zones, Cdiscount, Fnac et Mirakl reçoivent leurs lecteurs. Le modèle s’enrichit des adresses, des états et des lignes nécessaires à une exploitation locale.

Cette origine explique le nom « centralisation ». Le problème n’est pas d’abord graphique. Il s’agit de transformer plusieurs réponses fournisseurs en objets stables que Ciama peut rechercher, recalculer et rapprocher. L’écran vient après la chaîne qui garantit que la vente est réellement présente.

4. Commencer par trois chaînes adaptées à leurs univers

MarketplaceOrder, EcommerceOrder et BtoBOrder avancent séparément

Ciama V2 sépare trois familles. MarketplaceOrder porte les ventes Amazon, Cdiscount, Fnac et Mirakl. EcommerceOrder accueille les boutiques en ligne. BtoBOrder représente les commandes venues de l’ERP. Chacune possède ses entités de lecture, ses contrats, ses services d’ajout ou de mise à jour et sa couche d’accès aux données.

Cette architecture a un avantage initial : chaque univers peut refléter la forme de sa source sans attendre un modèle universel parfait. Les adresses marketplace, les lignes d’une commande e-commerce et les états ERP progressent au rythme des intégrations disponibles.

Elle introduit aussi une dette visible. Rechercher une vente, recalculer un agrégat ou ajouter une règle de compte demande plusieurs implémentations. Le cockpit risque de produire trois expériences similaires sans partager la même autorité. Cette limite prépare directement la décision de la génération suivante.

5. Reconstruire le cœur commande dans la troisième génération

La migration provider-first se concentre en mars 2026

Ciama V3 démarre en octobre 2025. Le nouveau domaine Sales/Order prend sa forme opérationnelle en mars 2026. Les anciens collecteurs marketplace et e-commerce sont remplacés par un flux piloté depuis le fournisseur et sa connexion, tandis que le domaine de persistance devient commun.

La bascule ne supprime pas les trois univers. Elle déplace leur différence vers la bonne couche. Marketplace, e-commerce et B2B conservent des dispatchers et des lecteurs adaptés, mais ne possèdent plus chacun leur définition concurrente d’une commande et d’une ligne.

Les routes historiques sont redirigées vers le nouveau centre, puis l’utilisateur retrouve une vue adaptée au type de canal. Cette stratégie permet de renouveler l’architecture sans casser les repères de navigation ni aplatir les besoins particuliers du métier.

6. Donner à Order et OrderLine une responsabilité commune

La vente devient un objet partagé, ses détails restent reliés

Order porte l’identité, les dates de création, mise à jour et achat, le compte, le canal, le type de canal, le statut, le mode de fulfillment, le client, le pays et les devises. Les adresses brutes peuvent être conservées lorsque la source fournit plus de détails que le modèle courant.

OrderLine rattache chaque ligne à la commande, au compte et au canal. Elle peut aussi rejoindre l’offre, le produit, l’achat fournisseur et l’entrepôt de livraison. SKU vendeur, quantités commandées, expédiées et restantes, statut et prix donnent la matière opérationnelle.

Le modèle ne cherche pas à faire disparaître les données absentes. De nombreux champs sont optionnels, car une source ne fournit pas toujours le même niveau de précision qu’une autre. L’application peut distinguer une valeur inconnue d’un zéro économique et enrichir la ligne lorsque les relations deviennent disponibles.

7. Identifier une commande par son canal et sa référence source

L’unicité fonctionnelle précède la décision d’ajouter ou de mettre à jour

Une référence distante n’est pas supposée unique dans tout l’écosystème. Ciama la recherche avec l’identifiant du canal. Le couple canal-identifiant devient la clé métier qui permet de reconnaître une vente déjà connue lors de la collecte suivante.

Le cas d’usage CollectOrdersByProvider parcourt les résultats reçus. Pour chaque commande, il interroge la couche de données avec ce couple. Une absence déclenche une demande d’ajout ; une présence déclenche une mise à jour. La décision est explicite et testable.

Cette règle évite deux erreurs opposées : dupliquer une commande à chaque import ou fusionner deux ventes qui partagent par hasard une référence sur des canaux différents. Elle donne également un point de rapprochement stable pour l’API et l’interface.

8. Faire de la connexion fournisseur le point de départ

Le flux valide le contexte avant d’interroger une API distante

La collecte reçoit une connexion fournisseur, une fenêtre de dates et éventuellement un canal. Le service vérifie que l’identifiant est présent, que la période est cohérente et que la connexion existe, est active et possède des identifiants déclarés valides.

Le fournisseur doit lui aussi être actif et disponible. Sa version, lorsqu’elle est renseignée, doit être connue et active. Le type accepté appartient à marketplace, e-commerce ou ERP. Ces contrôles arrêtent le flux avant un appel distant impossible à interpréter.

La migration provider-first clarifie ainsi la responsabilité. La connexion dit avec quelle source dialoguer ; le canal dit dans quel univers commercial ranger la commande. Le domaine Order reçoit ensuite une donnée normalisée sans porter les règles d’authentification propres à Amazon, Wix ou Odoo.

9. Brancher sept sources réellement implémentées

Quatre marketplaces, deux plateformes e-commerce et un ERP

Le versant marketplace comprend Amazon Europe, Cdiscount, Fnac Darty et Mirakl. Chaque lecteur transforme la réponse de son écosystème vers la collection commune. Amazon conserve en plus ses particularités régionales et son mapping de statuts.

Le versant e-commerce comprend Shopify et Wix. Leurs clients de lecture et leurs pullers alimentent le même cas d’usage de collecte, sans demander un second domaine de persistance. Le versant B2B utilise Odoo 19 et ses appels JSON-2 pour lire ventes et lignes ERP.

Sept sources actives ne signifient pas sept comportements identiques. Chaque implémentation garde ses paramètres, sa pagination et ses conversions. Le contrat commun porte le résultat attendu, pas une illusion d’uniformité des APIs distantes.

10. Refuser les contextes ambigus avant la collecte

Compte, fournisseur, version et canal doivent raconter la même connexion

Lorsqu’un canal est fourni, Ciama contrôle son existence, son compte et son fournisseur. Un canal d’un autre compte ou relié à une autre source n’est pas accepté. La commande ne peut donc pas être importée dans un contexte choisi uniquement par un identifiant reçu en entrée.

Lorsqu’aucun canal n’est précisé, le service recherche les canaux actifs du compte pour ce fournisseur. Une absence est une erreur ; plusieurs correspondances sont également refusées. Le système préfère demander une décision plutôt que d’envoyer la vente vers une destination arbitraire.

Cette validation donne de la valeur au modèle commun. Centraliser n’est sûr que si chaque objet conserve son propriétaire et son origine. Le contrôle intervient avant l’appel et avant l’écriture, ce qui réduit les corrections nécessaires après import.

11. Découper l’historique selon le type de canal

Une journée pour le B2B, trente jours pour marketplace et e-commerce

La reprise d’historique construit des fenêtres temporelles plutôt qu’une requête démesurée. Par défaut, les canaux B2B sont découpés par journée. Marketplace et e-commerce utilisent des segments de trente jours. Le pas peut être remplacé explicitement lorsque la source l’exige.

Pour le B2B, les segments sont traités du plus récent vers le plus ancien. Les autres univers conservent l’ordre chronologique. Cette nuance répond au besoin de rendre rapidement visibles les ventes ERP les plus actuelles tout en conservant une reconstruction ordonnée ailleurs.

Chaque fenêtre devient un message enfant rattaché à une exécution parente. L’équipe peut connaître le groupe, le canal, la période et la commande à l’origine du travail. Une reprise longue n’est plus une seule opération opaque.

12. Séparer collecte, ajout et mise à jour dans la file de traitements

Trois messages et trois handlers distribuent la charge

CollectOrdersByProviderMessage lance une lecture pour une connexion et une fenêtre données. Le handler appelle le cas d’usage qui valide le contexte, sélectionne le lecteur et reçoit la collection normalisée. Il ne persiste pas tout dans une boucle synchrone liée à une page.

Chaque résultat produit ensuite AddOrderMessage ou UpdateOrderMessage selon l’identité canal-référence. Les handlers spécialisés exécutent leurs règles et mettent à jour les journaux d’exécution associés. La collecte et la transformation en base peuvent ainsi progresser séparément.

La commande planifiée parcourt les connexions dont la fonction orders_sync est active. Elle ignore les accès inactifs ou invalides, puis collecte une fenêtre glissante de deux heures pour les fournisseurs marketplace et e-commerce. Le B2B possède ses commandes d’historique adaptées à l’ERP.

13. Normaliser les statuts sans perdre la valeur source

Le cockpit travaille avec un vocabulaire commun

La recherche utilise un ensemble de statuts opérationnels : pending, to_ship, partially_shipped, shipped, cancelled, refunded, refused et unknown. L’écran principal met en avant les états qui structurent le traitement courant, tandis que l’API accepte le vocabulaire plus complet.

Les lecteurs traduisent les statuts de leur source vers ce langage. Amazon possède un mapper testé dédié. Une valeur inattendue ne doit pas être forcée dans un état rassurant : unknown reste disponible pour signaler qu’une correspondance manque.

La normalisation permet de filtrer plusieurs canaux avec le même critère. Elle ne supprime pas la nécessité de maintenir les mappers lorsque les fournisseurs évoluent. Le durcissement Amazon du 9 septembre 2026 rappelle que cette frontière reste vivante.

14. Relier la vente aux produits, offres, stocks et achats

OrderLine devient la charnière des décisions aval

Chaque ligne conserve le SKU vendeur, les quantités et son statut. Lorsqu’ils sont identifiés, l’offre et le produit local créent un passage vers le catalogue. L’entrepôt de livraison et la ligne d’achat fournisseur prolongent la chaîne vers le stock et l’approvisionnement.

La quantité commandée est séparée de la quantité expédiée et de celle qui reste à traiter. Cette lecture évite de réduire toute la commande à un statut global lorsque ses lignes ne progressent pas au même rythme.

Les pages produit, marque, catégorie, tag, offre, canal et entrepôt peuvent à leur tour afficher les lignes concernées. La centralisation fonctionne dans les deux sens : partir de la commande vers son contexte, ou partir d’un objet métier vers les ventes qui l’impliquent.

15. Appliquer le compte comme frontière de recherche et d’écriture

Une commande n’existe jamais hors du contexte de son organisation

Order et OrderLine sont rattachés à Account. La recherche du back-office ajoute systématiquement l’identifiant du compte connecté. Les canaux proposés appartiennent au même périmètre et les validations de collecte confrontent connexion et canal à cette frontière.

Les index de base couvrent notamment compte-date d’achat, compte-date de mise à jour, compte-canal-date et compte-type de canal-date. Ils reflètent les questions fréquentes du cockpit sans obliger à parcourir toutes les organisations.

L’export crée lui aussi un rapport attaché au compte courant. Cette continuité évite qu’une fonction secondaire contourne la règle appliquée par l’écran principal. La centralisation reste multi-compte, mais chaque lecture conserve son périmètre.

16. Chercher par référence, canal, statut et période

Une vue commune remplace les listes parallèles

Le centre de recherche accepte une référence partielle, un canal, un type de canal, un statut, une année et un mois. Les facettes actives restent visibles et peuvent être retirées. La page affiche cinquante résultats par défaut, triés par date d’achat décroissante.

La recherche sait aller plus loin pour les usages API et export : client, commercial, périodes de création ou mise à jour, fourchettes de prix et de marge, pays, devise, identifiant exact et mode de fulfillment. Les tris couvrent dates, prix, marge, frais, statut et référence.

L’écran ne prétend pas exposer chaque filtre avancé en permanence. Il garde les critères les plus utiles au quotidien et laisse l’API ou l’export porter les recherches plus spécialisées. Cette séparation évite de transformer le cockpit en formulaire illisible.

17. Conserver valeur source, conversion et origine des coûts

La centralisation prépare la lecture économique sans confondre connu et estimé

La commande stocke le prix taxé source, sa devise et plusieurs montants convertis. Elle peut agréger TVA, commissions de canal, frais de livraison et coûts d’achat. Chaque famille distingue la valeur réelle de son estimation et conserve l’origine utilisée pour le calcul.

Les lignes portent leur propre prix, taux de TVA, frais et référence de calcul. Un objet OrderLineFinance sépare les détails financiers persistés du reste de la ligne. Les blocages de marge ou d’estimation peuvent être conservés au lieu de produire silencieusement un zéro.

La logique exacte de calcul est approfondie dans le projet marge réelle ou estimée par vente. Pour l’OMS, le gain structurant est que toutes les commandes partagent désormais les emplacements nécessaires à cette lecture.

18. Garder la position Buy Box au moment de l’achat

Oui, non, partiel ou inconnu deviennent des états distincts

Order conserve un état synthétique de Buy Box au moment de l’achat. OrderLine peut indiquer si l’offre concernée la détenait. La valeur ne décrit donc pas seulement la situation actuelle du catalogue : elle rattache un signal concurrentiel au moment commercial.

Une commande peut être yes, no, partial ou unknown selon ses lignes et les données disponibles. L’état partiel évite d’aplatir une commande multiligne où toutes les offres n’occupaient pas la même position.

Les vues par univers proposent un onglet Buy Box lorsque ce signal a du sens. Le B2B et l’e-commerce conservent leurs routes pour réemployer le rendu commun, mais l’absence de donnée n’est pas maquillée en victoire ou en perte.

19. Adapter la fiche au canal sans dupliquer la commande

Overview, rentabilité et Buy Box partagent un même rendu

La route générique ouvre la commande, puis OrderUniverseRedirector choisit le parcours marketplace, e-commerce ou B2B selon le type du canal. Les contrôleurs spécialisés préparent les trois vues : overview, profit et Buy Box report.

UniverseOrderViewRenderer rassemble la construction du résultat afin que les douze routes spécialisées ne dérivent pas chacune leur propre version du modèle. La présentation peut changer d’entrée sans créer trois persistances concurrentes.

La fiche affiche la référence, le canal, le statut, le fulfillment, les dates et les lignes. Elle crée des liens vers l’offre et le produit lorsqu’ils existent. La rentabilité et la Buy Box utilisent les mêmes objets au lieu d’être recomposées depuis un export séparé.

20. Exposer le même OMS par trois endpoints de lecture

Recherche commande, détail et recherche de lignes

L’API OMS propose GET /oms/orders, GET /oms/orders/{id} et une recherche de lignes. Les presenters transforment le domaine commun en objets de lecture dédiés ; le back-office et les consommateurs API ne dépendent pas directement des entités Doctrine.

La recherche commande documente pagination, dates, identifiant, statut, canal, client, fulfillment, prix, marge, pays, devise et tri. Elle valide les bornes numériques et refuse par exemple une valeur maximale inférieure au minimum demandé.

La route détail garde le compte de l’utilisateur comme contexte. Ces endpoints ne prouvent pas une API de modification de commande : ils offrent une lecture stable du socle centralisé, utile pour construire d’autres interfaces ou contrôles.

21. Transformer une recherche en rapport asynchrone

Les filtres deviennent un travail suivi plutôt qu’un téléchargement bloquant

Depuis la recherche, l’utilisateur choisit CSV ou Excel. Le contrôleur ne génère pas le fichier dans la requête web : il crée un rapport au statut queued, attaché au compte, puis envoie un message avec les filtres autorisés.

Référence, statut, canal, périodes, fulfillment, prix, marge, pays, devise et ordre peuvent accompagner la demande. Page et limite sont retirées afin que le rapport porte sur l’ensemble de la sélection plutôt que sur le seul écran courant.

La page conserve l’identifiant du rapport lors du retour. Ce comportement est détaillé dans l’étude exporter une recherche sans bloquer le cockpit. Il prolonge ici la même autorité de filtre que la centralisation.

22. Faire de l’historique un ensemble d’exécutions reliées

Une opération parente organise les fenêtres enfants

La reprise d’historique démarre un journal parent avec le compte, le canal, la période, le mode et un identifiant de groupe. Chaque fenêtre crée ensuite son propre journal enfant avant l’envoi du message de collecte.

Cette structure permet de distinguer l’intention globale des unités effectivement distribuées. Une période longue peut être suivie segment par segment sans perdre le lien avec la demande initiale. Le nombre de messages envoyés est retourné au déclencheur.

Pour le B2B, seules les connexions ERP actives, valides et autorisées pour la fonction btob_orders_sync sont retenues. Marketplace et e-commerce utilisent le fournisseur du canal. L’historique respecte donc les mêmes frontières que la collecte courante.

23. Couvrir le cœur OMS avec vingt-et-un fichiers de tests ciblés

Domaine, orchestration, messages et lecteurs sensibles sont contrôlés

Cinq tests d’intégration ciblent l’ajout, la collecte, la mise à jour, la normalisation des coûts et une régression de statistiques mensuelles. Les tests unitaires couvrent les mêmes cas d’usage, le calcul de TVA, les commandes d’historique et de collecte planifiée.

Les handlers AddOrder, UpdateOrder et CollectOrdersByProvider possèdent leurs contrôles. Amazon Europe, Shopify, Wix, Odoo 19 et le mapper de statuts Amazon disposent également de fichiers dédiés. Au total, vingt-et-un fichiers correspondent au périmètre cœur retenu dans cette étude.

Les tests applicatifs complètent cette base sur l’API OMS, les recherches par univers et les vues associées, mais ils ne sont pas inclus dans la métrique de vingt-et-un. Le nombre mesure des fichiers ciblés, pas un pourcentage de couverture ni une absence garantie de défaut.

24. Importer une vente Amazon puis la relire dans tout le cockpit

Un scénario traverse connexion, collecte, identité, lignes et vues métier

La fonction orders_sync d’une connexion Amazon active déclenche une collecte sur les deux dernières heures. Ciama valide le compte, le fournisseur, ses accès et sa version, puis retrouve le canal marketplace correspondant. Le lecteur Amazon Europe interroge la zone configurée et mappe les statuts vers le vocabulaire commun.

Chaque vente est recherchée par canal et référence. Une nouvelle commande part vers AddOrder ; une commande déjà connue vers UpdateOrder. Ses lignes rejoignent produits et offres lorsqu’un rapprochement existe, puis les quantités, devises et coûts alimentent les agrégats.

L’utilisateur retrouve ensuite la vente depuis la recherche commune, filtrée sur Amazon et to_ship. La fiche overview montre ses lignes et le fulfillment ; l’onglet profit distingue les coûts connus des estimations ; l’onglet Buy Box garde la position au moment de l’achat. Le même objet peut enfin être exporté ou interrogé par l’API OMS.

25. Passer de trois vérités techniques à une autorité commerciale

La transformation se lit dans l’architecture et dans les usages

Avant la refonte, marketplace, e-commerce et B2B possèdent chacun leurs entités, services et files. Une évolution commune risque d’être implémentée trois fois ou d’avancer différemment selon l’univers. Les vues se ressemblent sans nécessairement partager le même modèle.

Après la migration, les sept sources convergent vers Order et OrderLine. L’identité, le compte, la recherche, les coûts, les exports et l’API s’appuient sur un même socle. Les différences nécessaires restent dans les lecteurs et dans le choix de la vue par type de canal.

Cette unification rend les commandes traversables depuis le canal, le produit, l’offre, le client, l’entrepôt ou l’achat fournisseur. Elle ne fournit pas un chiffre artificiel de temps gagné ; elle supprime une duplication observable et ouvre des usages qui dépendaient auparavant de plusieurs chaînes.

26. Maintenir une frontière nette entre actif et restant à étendre

Un nouveau fournisseur exige son propre contrat de lecture

Le périmètre opérationnel s’arrête aux sept sources nommées. Étendre l’OMS à un nouveau fournisseur demanderait son client de lecture, son mapping de statuts, ses règles de pagination et ses tests ; le contrat commun ne rend pas cette intégration automatique.

Les imports dépendent toujours des contrats externes et de leurs évolutions. Les correctifs Amazon sur les zones et la robustesse des synchronisations, jusqu’au 9 septembre 2026, montrent que les mappers, paramètres et fenêtres doivent rester activement maintenus.

Le modèle financier comporte volontairement des valeurs optionnelles et des motifs de blocage. Une commande centralisée n’est pas automatiquement une commande dont tous les coûts sont connus. La qualité du cockpit dépend du rapprochement produit-offre-stock et des sources disponibles au moment du calcul.

Pour un vendeur confronté à cette complexité, Dawap peut cadrer l’OMS marketplace, construire les connecteurs ERP et marketplace et relier les décisions au cockpit Ciama Marketplace.