Ciama : unifier les commandes et les offres e-commerce et marketplace sans perdre leur origine

1. Ciama, un cockpit commerce alimenté par plusieurs familles d’API

Un même compte peut exploiter des boutiques directes et plusieurs écosystèmes marketplace

Ciama est un OMS et un cockpit commerce développé par Dawap. Son domaine de vente distingue les canaux e-commerce, marketplace et B2B, tout en partageant des objets communs pour les commandes, les lignes, les offres, les produits et les données financières.

Pour les flux étudiés ici, six familles de lecteurs sont présentes : Shopify et Wix côté e-commerce ; Amazon, Cdiscount, Fnac Darty et Mirakl côté marketplace. Mirakl représente lui-même plusieurs enseignes, mais le moteur d’intégration reste identifiable par la connexion fournisseur.

Chaque connexion appartient à un compte, cible un fournisseur et peut préciser une version. Un canal de vente conserve ensuite son identifiant, son type, son catalogue, ses dates de dernière collecte et le lien vers ce fournisseur. Cette séparation empêche une vente directe de devenir artificiellement une vente marketplace au moment de la consolidation.

Le projet répond donc à une contrainte de produit précise : faire converger les traitements répétitifs sans gommer les règles propres à chaque API. Le socle Ciama doit pouvoir accueillir un nouveau lecteur sans recopier toute la chaîne d’orchestration.

2. Séparer l’adaptateur, l’orchestration et l’écriture

Trois responsabilités pour faire évoluer une source sans dérégler les autres

Le lecteur fournisseur connaît l’API distante. Il sait reconnaître une connexion compatible, appeler ses endpoints ou ses rapports, parcourir les pages et convertir la réponse vers une collection normalisée de commandes ou d’offres.

L’orchestrateur connaît les règles communes. Il vérifie que la connexion et les identifiants sont exploitables, résout le bon lecteur, puis transmet une demande bornée par le canal et, pour les commandes, par une période.

Le domaine décide enfin de l’écriture. Il cherche l’objet existant dans le bon canal et distribue un message d’ajout ou de mise à jour. Cette étape ne dépend plus du nom Shopify, Wix ou Amazon : elle travaille à partir du contrat normalisé.

Cette architecture a remplacé des parcours séparés par univers en mars 2026. Les écrans e-commerce et marketplace restent distincts pour le travail quotidien, mais la mécanique d’ingestion qui les alimente n’est plus recopiée pour chaque famille de canal.

3. Le risque initial : multiplier les chaînes de collecte avec chaque canal

Des traitements parallèles finissent par diverger même lorsqu’ils servent le même métier

Les premières intégrations distinguaient les collectes e-commerce et marketplace jusque dans leurs commandes techniques, leurs messages et leurs traitements. Cette séparation rendait l’univers visible, mais elle répétait des responsabilités identiques : charger une connexion, trouver un canal, rechercher une commande existante puis choisir entre création et actualisation.

Chaque nouveau connecteur risquait alors d’ajouter sa propre variation à cette mécanique. Une correction apportée au flux marketplace ne protégeait pas automatiquement le flux e-commerce ; un contrôle de connexion pouvait être présent d’un côté et manquer de l’autre.

L’autre extrême aurait consisté à cacher toutes les différences dans un seul lecteur générique. Cette option aurait déplacé la complexité sans la résoudre : pagination, authentification, statuts, rapports différés, variantes et stocks restent propres à chaque fournisseur.

Le chantier a donc ciblé la bonne frontière. Les différences d’API restent dans les adaptateurs ; les règles de sécurité et de persistance communes deviennent un seul parcours.

4. Normaliser ce qui doit réellement être partagé

Une commande commune conserve son identifiant, son canal, sa date, son statut et ses lignes

Chaque lecteur de commandes retourne une collection d’objets normalisés. Une commande porte notamment l’identifiant du canal, son identifiant externe, la date d’achat, le statut, le mode d’expédition, le pays de livraison, le prix TTC, la devise source et ses lignes.

Le contrat accepte aussi les informations client, société, TVA, téléphone et adresses lorsqu’elles existent. Ces champs sont facultatifs : un connecteur ne doit pas fabriquer une donnée simplement parce qu’un autre fournisseur la renvoie.

Les offres suivent la même philosophie. Le format commun expose les identifiants nécessaires, le stock, le prix, l’état et la condition, tandis que le lecteur garde la responsabilité de convertir les particularités de son API.

Cette normalisation rend les objets comparables après ingestion. Elle ne prétend pas que les sources sont identiques ; elle définit le minimum fiable sur lequel le reste de Ciama peut travailler.

5. Refuser la collecte avant l’appel lorsque la connexion n’est pas exploitable

Activation, validité des accès, disponibilité du fournisseur et version sont vérifiées

Une demande de collecte commence par un identifiant de connexion fournisseur. Une valeur vide ou inconnue arrête le parcours avec une erreur structurée.

La connexion doit être active et ses informations d’accès marquées valides. Le fournisseur associé doit lui aussi être actif et disponible. Pour ce projet, son type doit appartenir aux univers marketplace ou e-commerce.

Lorsqu’une version de fournisseur est liée à la connexion, elle doit exister et rester active. Cette vérification évite d’envoyer une collecte vers un adaptateur dont le contrat a été retiré ou désactivé.

Ces contrôles sont centralisés. Ajouter un lecteur ne dispense donc pas le nouveau canal des règles déjà appliquées aux autres intégrations.

6. Rattacher chaque lecture au bon compte et au bon canal

L’origine commerciale reste une clé de sécurité et de déduplication

Une collecte peut désigner explicitement son canal. Ciama vérifie alors que ce canal existe, appartient au même compte que la connexion et référence le même fournisseur.

Lorsque le canal n’est pas fourni, le service recherche les canaux actifs du compte pour ce fournisseur. Il n’avance que si la correspondance est unique. Zéro canal ou plusieurs candidats produisent une erreur au lieu d’un choix implicite.

Cette règle est importante pour la consolidation. Deux fournisseurs peuvent renvoyer le même identifiant externe ; deux boutiques peuvent aussi générer des suites numériques semblables. L’objet existant est donc recherché par canal et par identifiant, jamais par identifiant seul.

Le type du canal continue d’alimenter les recherches e-commerce ou marketplace. La chaîne est commune, mais l’interface peut toujours isoler l’univers et revenir à la source exacte d’une vente.

7. Choisir le lecteur par capacité plutôt que par embranchement central

Chaque adaptateur déclare les connexions qu’il sait traiter

Le service de lecture parcourt les clients disponibles et sélectionne celui dont la méthode de compatibilité reconnaît la connexion. Shopify et Wix répondent aux connexions e-commerce correspondantes ; Amazon, Cdiscount, Fnac Darty et Mirakl couvrent leurs écosystèmes marketplace.

Le cœur du traitement ne contient donc pas une longue succession de conditions par marque. Un adaptateur implémente le contrat de lecture, déclare son support et rejoint la collection de clients du service.

Si aucun lecteur ne reconnaît la connexion, la collecte échoue explicitement. Le système ne réutilise pas un connecteur proche et ne transforme pas une configuration inconnue en réponse vide.

Cette extension par capacité réduit la zone touchée lorsqu’une API évolue. Le lecteur concerné peut changer sa pagination ou son mapping sans modifier la décision d’ajouter ou de mettre à jour les objets normalisés.

8. Traiter l’ajout et la mise à jour d’une commande séparément

La clé canal-identifiant rend les reprises répétables

La collecte des commandes exige une date de début et une date de fin. La période inversée est refusée avant la lecture, ce qui empêche un adaptateur de recevoir une fenêtre incohérente.

Pour chaque commande normalisée, Ciama cherche une vente portant le même identifiant dans le même canal. Si aucune ligne n’existe, un message d’ajout est préparé. Dans le cas contraire, un message de mise à jour prend le relais.

Une collecte rejouée ne crée donc pas automatiquement un doublon. Elle peut actualiser le statut, les montants ou les lignes à partir de l’état plus récent renvoyé par la source, tout en restant enfermée dans son canal.

La réponse de l’orchestrateur expose le nombre d’objets collectés, d’ajouts programmés et de mises à jour programmées. Le résultat technique devient contrôlable sans devoir interpréter uniquement une fin de commande réussie.

9. Identifier une offre avec sa condition de stock

Une référence neuve et une référence reconditionnée ne sont pas nécessairement la même offre

Pour une offre, Ciama cherche d’abord la combinaison canal, identifiant et condition de stock. Ce niveau de précision évite de confondre deux états commerciaux d’une même référence.

Une recherche de repli par canal et identifiant maintient la continuité avec les données plus anciennes qui ne possèdent pas encore la même granularité. Si aucun objet n’est trouvé, l’offre est ajoutée ; sinon, elle est actualisée.

Comme pour les commandes, l’écriture passe par des messages dédiés. La lecture distante peut terminer après avoir distribué les ajouts et mises à jour, sans exécuter toute la persistance dans le même processus.

Le relevé conserve aussi deux informations de qualité : son caractère complet ou incomplet, et les avertissements émis par la source. Elles deviennent décisives avant toute désactivation.

10. Ne désactiver les offres absentes qu’après un relevé complet et non vide

Trois conditions protègent le catalogue d’une fausse disparition

Un relevé complet sans période représente l’état courant du canal. Dans ce seul cas, une offre active absente de la réponse peut être considérée comme disparue de la source et désactivée dans Ciama.

Le traitement applique désormais trois conditions cumulatives : aucune plage historique ne doit être demandée, au moins une offre doit avoir été collectée et la source doit déclarer son relevé complet. Les identifiants présents sont alors exclus de la désactivation.

Une réponse vide ne vaut donc plus catalogue vide. Elle peut signaler une API momentanément muette, un rapport indisponible ou une extraction interrompue ; les offres déjà enregistrées restent actives.

Un relevé partiel se comporte de la même manière. Ses ajouts et mises à jour exploitables peuvent être traités, mais ses absences ne deviennent pas des suppressions. Cette asymétrie protège l’existant tout en conservant les données valides reçues.

11. Découpler la lecture distante des écritures métier

Ajouts et mises à jour rejoignent des files distinctes

Après normalisation, l’orchestrateur distribue une demande d’ajout ou de mise à jour pour chaque commande et chaque offre. Ces messages transportent le canal, l’objet lu et l’identifiant du journal d’exécution lorsqu’il existe.

Le découpage évite qu’une longue série d’écritures garde ouverte la requête du fournisseur. Il permet aussi de suivre séparément ce qui a été lu, ce qui doit être créé et ce qui doit être rafraîchi.

Les files dédiées rendent le traitement plus lisible en cas de reprise. Une erreur sur une offre n’oblige pas à relancer comme un seul bloc toutes les commandes ou toutes les autres sources collectées au même moment.

Cette architecture ne garantit pas qu’une API distante répondra toujours. Elle borne l’effet d’un échec et conserve assez de contexte pour reprendre la bonne connexion et la bonne opération.

12. Adapter la cadence au type de donnée collecté

Commandes récentes toutes les dix minutes, état des offres toutes les deux heures

En production, la commande planifiée des ventes s’exécute toutes les dix minutes. Pour chaque connexion dont la fonction de synchronisation des commandes est active, elle demande les deux dernières heures.

Cette fenêtre recouvrante privilégie la reprise des ventes récentes. La clé canal-identifiant absorbe les relectures : une commande déjà connue part vers la mise à jour plutôt que vers une seconde création.

La collecte des offres s’exécute toutes les deux heures sur les connexions dont la fonction correspondante est active. Elle demande un relevé courant sans bornes de dates, nécessaire pour comparer les identifiants présents à ceux déjà actifs.

Les deux rythmes ne sont pas présentés comme une fréquence universelle. Ils correspondent à la configuration de production actuelle de Ciama et peuvent évoluer avec les volumes, les quotas ou le contrat d’une source.

13. Tracer chaque collecte avec sa connexion et son périmètre

Le journal d’exécution précède l’envoi du message

Avant de distribuer une collecte planifiée, Ciama ouvre un journal d’exécution. Il enregistre le compte, la fonction demandée, le mode planifié, la classe de message et le nom de la commande.

Le contexte conserve également l’identifiant de connexion et de fournisseur, son identifiant lisible, sa version et la fenêtre temporelle lorsqu’il s’agit des commandes. L’exécution démarre dans un état en attente avec une progression nulle.

Le message reçoit l’identifiant de ce journal. Les traitements suivants peuvent ainsi rattacher leurs compteurs et leur résultat à la demande initiale plutôt que produire une trace anonyme dans les logs techniques.

La supervision ne remplace pas la donnée métier. Elle explique quelle connexion a été appelée, pour quelle fonction et dans quelle période lorsque le volume collecté ou mis à jour doit être contrôlé.

14. Traiter les rapports Amazon comme des relevés potentiellement partiels

Seller, FBA et génération différée ne doivent pas produire une suppression silencieuse

Les offres Amazon rapprochent un rapport de listings Seller et FBA avec un rapport de stock FBA. Ces documents peuvent ne pas être disponibles au même moment, être trop anciens ou échouer pendant leur lecture.

Le lecteur marque désormais le relevé incomplet lorsqu’un rapport nécessaire manque ou lorsqu’une conversion d’offre échoue. Il ajoute un avertissement distinct pour le listing, l’inventaire FBA ou la conversion concernée.

Le rapport suivant est demandé en préparation d’une future collecte. Les réponses de limitation Amazon sont reprises avec une temporisation croissante, bornée, qui tient aussi compte de l’en-tête Retry-After lorsqu’il est présent.

Le 9 septembre 2026, cette information de complétude a été propagée jusqu’au domaine des offres. Ciama peut donc conserver les offres absentes d’un relevé incomplet au lieu de confondre une indisponibilité du rapport avec une disparition commerciale.

15. Tester les frontières où une collecte devient dangereuse

Connexions invalides, mauvais canal, doublon et relevé incomplet sont couverts

Les suites unitaires des collectes vérifient les champs requis, les périodes inversées, les connexions absentes ou inactives, les fournisseurs non disponibles, les versions inactives et les canaux qui n’appartiennent pas au bon compte.

Les scénarios d’écriture distinguent une nouvelle commande ou offre de son actualisation. Ils contrôlent les compteurs retournés et l’appel du bon message, sans confondre l’objet d’un autre canal.

Les tests d’offres couvrent explicitement la sécurité du relevé : aucune désactivation après une réponse vide, après une extraction incomplète ou pendant une lecture bornée par dates. La désactivation n’est attendue que pour un état courant complet et non vide.

Des tests d’intégration reprennent les mêmes chemins avec la couche de données et le conteneur applicatif. Les commandes de production et les handlers de messages possèdent également leurs contrôles de branchement.

16. Faire évoluer le socle en plusieurs jalons vérifiables

Du premier flux Wix au durcissement des relevés Amazon

Le flux de commandes Wix a fourni le premier jalon e-commerce le 29 octobre 2025. Une correction sur les offres Wix sans frais a suivi le 1er novembre, signe que la normalisation devait accepter les absences légitimes de la source.

Les commandes et les offres ont été séparées par univers et par messages d’ajout ou de mise à jour le 6 mars 2026. Le 12 mars, la migration pilotée par le fournisseur a remplacé les anciens parcours dupliqués. Shopify a rejoint les collectes le lendemain.

En avril, l’état courant des offres a gagné la désactivation des références réellement absentes. Cette capacité a ensuite été déplacée et durcie pour que sa conséquence la plus sensible reste réservée aux relevés fiables.

Les 8 et 9 septembre, une réponse vide puis un relevé Amazon partiel ont été explicitement neutralisés comme sources de désactivation. La réalisation publiée correspond à cet état récent, avec ses garde-fous et ses tests associés.

17. Ce qui change après l’unification des flux

Moins de duplication technique, plus de contrôle sur l’origine et les reprises

Une nouvelle famille d’API peut se concentrer sur la lecture et la conversion de sa réponse. Les validations de connexion, la résolution du canal, la recherche de l’existant et la distribution des écritures restent partagées.

Une commande relue dans la fenêtre récente rejoint la mise à jour de son canal au lieu de créer un doublon. Les équipes peuvent conserver une fréquence courte sans supposer que chaque lecture ne renverra que des ventes inédites.

Les recherches e-commerce et marketplace continuent de montrer des univers distincts, car le type et l’identifiant du canal traversent toute la chaîne. La consolidation permet une exploitation commune sans rendre la source opaque.

Pour les offres, le résultat le plus concret est défensif : une absence n’a de conséquence que dans un relevé courant, complet et non vide. Une panne, un quota ou un rapport différé ne transforme plus automatiquement le catalogue connu en liste d’offres inactives.

Enfin, les compteurs et journaux d’exécution donnent une prise opérationnelle sur chaque collecte. Le diagnostic peut partir de la connexion et de la période exactes avant de descendre vers les objets ajoutés ou actualisés.

18. Le parcours d’une collecte multicanale dans Ciama

Deux sources différentes, une orchestration commune, des origines préservées

À dix minutes d’intervalle, le planificateur rencontre une connexion Shopify et une connexion Amazon dont la synchronisation des commandes est active. Il ouvre deux journaux puis distribue deux demandes couvrant les deux dernières heures.

Le service valide chaque connexion, son fournisseur, sa version et son canal. Le lecteur Shopify appelle la boutique ; le lecteur Amazon utilise son propre parcours. Tous deux retournent des commandes normalisées avec leurs identifiants, dates, statuts, devises et lignes disponibles.

Une commande déjà présente dans le canal Shopify part vers sa mise à jour. Une vente Amazon absente du canal Amazon part vers l’ajout. Un identifiant numérique identique entre les deux sources ne crée aucune collision, car le canal participe à la recherche.

Plus tard, la collecte d’offres Amazon récupère les listings Seller mais ne dispose pas d’un rapport FBA exploitable. Les offres converties peuvent être actualisées, le relevé porte un avertissement et reste incomplet. Aucune offre absente n’est désactivée.

La chaîne a consolidé ce qui devait l’être — validation, normalisation, écriture et suivi — tout en conservant les différences qui protègent la donnée : lecteur, connexion, canal, univers et complétude de la source.

19. Les limites qui maintiennent une consolidation honnête

Le socle orchestre les flux ; il ne remplace ni la disponibilité des API ni le jugement métier

Une connexion invalide, un fournisseur indisponible ou une version inactive arrête la collecte. Ciama ne possède pas de donnée plus récente tant que la source ne peut pas être relue correctement.

La normalisation conserve les champs reçus, mais elle ne rend pas obligatoires les informations qu’une API ne fournit pas. Un client, une adresse, une commission ou une devise absente reste une donnée manquante à traiter comme telle.

Les cadences de dix minutes et deux heures décrivent la planification actuelle. Elles ne garantissent pas le même délai de visibilité lorsque le fournisseur impose une pagination lente, prépare un rapport différé ou limite les appels.

Cette réalisation ne synchronise pas automatiquement un stock unique entre tous les canaux et ne décide pas où vendre une unité disponible. Elle fournit les commandes et offres fiables sur lesquelles les briques de stock, de marge et de pilotage peuvent ensuite travailler.

20. Relier l’ingestion aux autres preuves du cockpit

Connecter, consolider, analyser puis agir sont quatre responsabilités distinctes

L’intégration de Shopify et Wix dans Ciama détaille les règles propres aux deux boutiques : authentification, commandes, variantes, statuts et interfaces e-commerce. Le socle transverse prend ensuite en charge leur passage vers le modèle partagé avec les marketplaces.

La centralisation des commandes marketplace approfondit la construction de l’OMS vendeur. Elle expose l’objet commande, tandis que cette orchestration explique comment chaque fournisseur l’alimente.

Le dashboard de ventes multicanal exploite ensuite les ventes normalisées pour comparer B2B, marketplaces et e-commerce. Sa responsabilité commence après la collecte : période, objectifs, ventilations et chemins vers le détail.

Enfin, le suivi de chaque synchronisation rend les journaux, messages et compteurs lisibles pendant l’exploitation. L’ensemble trace un parcours complet, de l’intégration API e-commerce ou marketplace jusqu’à la décision dans le cockpit.