Le projet en un coup d’œil
Commandes, variantes et états de traitement Shopify ou Wix devaient rejoindre Ciama sans être assimilés à des données marketplace.
Chaque source est lue selon son API, puis transformée en canaux, commandes, lignes et offres exploitables par les services partagés de Ciama.
Les équipes recherchent canaux, commandes et offres avec des filtres dédiés, puis ouvrent les mêmes vues de détail et de reporting que dans le cockpit global.
Un vendeur qui exploite des marketplaces et ses propres boutiques ne peut pas laisser les ventes directes hors de son cockpit. Une commande Shopify ou Wix mobilise le même catalogue, les mêmes équipes et souvent la même chaîne logistique. Pourtant, chaque plateforme expose ses propres identifiants, statuts, pages d’API et règles de pagination.
Dawap a intégré ces deux sources à Ciama entre le 13 et le 17 mars 2026. Le projet ne s’est pas limité à afficher un nouveau logo dans un menu : il a relié les connexions fournisseurs, la collecte récurrente, la normalisation des commandes et variantes, les créations ou mises à jour asynchrones, puis trois recherches réservées à l’univers e-commerce.
Cette réalisation prolonge notre accompagnement en automatisation des flux marketplace. La valeur vient de la continuité : le vendeur retrouve ses boutiques directes dans le modèle commun de Ciama, mais peut toujours isoler les canaux e-commerce lorsqu’il doit analyser une commande, une offre ou une connexion.
1. Ciama, un cockpit conçu pour plusieurs univers de vente
Partager les objets utiles sans effacer la nature du canal
Ciama Marketplace est développé par Dawap pour réunir les opérations commerciales d’un compte : canaux, offres, commandes, lignes, produits, reporting et automatisations. Son modèle distingue explicitement marketplace, e-commerce et B2B, ainsi que les vues globales qui les rapprochent.
Cette distinction évite deux impasses. Séparer totalement les boutiques oblige à maintenir plusieurs outils ; mélanger toutes les ventes sans type de canal empêche de filtrer correctement les règles, les indicateurs et les actions. Le champ d’univers permet de partager le socle tout en conservant la bonne lecture.
Une connexion fournisseur lie un compte à Shopify ou Wix, porte ses informations d’accès et active les fonctions de synchronisation. Un canal représente ensuite la boutique dans le domaine des ventes. Commandes et offres restent rattachées à ce canal, ce qui préserve leur origine dans toutes les recherches.
Le projet avait donc un objectif précis : faire entrer les boutiques dans le cockpit, pas simuler une plateforme e-commerce complète. Ciama lit les objets nécessaires au pilotage vendeur et les rapproche du catalogue ; l’administration native de la boutique reste dans Shopify ou Wix.
2. Normaliser le métier, respecter chaque API
Deux lecteurs spécialisés derrière la même orchestration de collecte
Shopify a reçu son chemin complet de collecte le 13 mars 2026. La recherche des commandes e-commerce et les informations de connexion Wix ont été alignées le 16 mars, puis les trois écrans de l’univers ont reçu leur identité visuelle dédiée le 17 mars. Cette dernière date marque la livraison cohérente retenue pour la fiche.
Dawap a conservé un lecteur par fournisseur. Shopify utilise ses ressources commandes et produits ; Wix utilise la recherche e-commerce des commandes et la recherche des variantes. Chaque lecteur transforme ensuite la réponse en objets de collecte communs.
L’orchestrateur choisit le lecteur selon le type et l’identifiant du fournisseur. Avant tout appel, il vérifie la connexion, sa validité, la disponibilité du fournisseur et le canal rattaché. Une connexion sans canal ou avec plusieurs canaux non explicités est arrêtée plutôt qu’associée au hasard.
Les commandes collectées sont recherchées par couple canal-identifiant. Si la vente n’existe pas, Ciama programme son ajout ; si elle existe déjà, il programme sa mise à jour. Cette idempotence permet à la fenêtre glissante de relire une période récente sans créer automatiquement de doublon.
3. Avant le projet : deux boutiques, deux angles morts
Le cockpit voyait les marketplaces, mais pas toute la vente directe
Lorsqu’une boutique reste en dehors du système de pilotage, ses commandes doivent être consultées dans une interface séparée. L’équipe change d’outil pour connaître l’état d’expédition, rechercher une référence ou comprendre la dernière vente d’un produit.
Les offres suivent la même fragmentation. Une variante Shopify et une variante Wix possèdent chacune leurs règles de visibilité, leurs informations de stock, leur prix et leur image. Sans normalisation, aucune recherche commune ne peut les présenter avec les autres offres du compte.
Cette séparation n’est pas seulement inconfortable. Elle complique le reporting par canal, la lecture du volume à expédier et le rapprochement avec le catalogue. Une vente directe peut exister dans la boutique sans alimenter les mêmes faits mensuels que les autres canaux.
L’objectif n’était toutefois pas de fusionner aveuglément les données. Une vente directe ne doit pas être étiquetée marketplace, et une offre e-commerce ne possède pas nécessairement une buy box ou des concurrents comparables. Le modèle commun devait donc garder le type ecommerce partout.
4. Définir ce qui entre réellement dans Ciama
Canaux, commandes, lignes et variantes utiles au pilotage
Le projet couvre deux familles d’objets. Les commandes apportent identifiant, date, statut d’exécution, paiement disponible, devise, total, pays de livraison et lignes vendues. Les variantes apportent SKU, stock, prix, activité, identifiants externes et informations produit disponibles.
Une ligne ne peut rejoindre le modèle que si un SKU exploitable est fourni. Ce repère est nécessaire pour relier la vente ou la variante au catalogue vendeur. Shopify ignore également les quantités nulles ; Wix ne retient que les lignes physiques qui possèdent un SKU.
Les données client ne sont pas utilisées comme un argument marketing du projet. Shopify peut transmettre les informations nécessaires dans les objets normalisés, tandis que Wix alimente ici surtout le contexte commercial et logistique de la commande. La vue publique se concentre sur le pilotage des ventes.
Le chantier ne pousse pas de catalogue ni de stock vers Shopify ou Wix. Il lit les commandes et les offres afin de les exploiter dans Ciama. Cette limite protège la promesse : connecter au cockpit ne signifie pas administrer toute la boutique depuis le cockpit.
5. Une orchestration commune pour ajouter ou actualiser les ventes
Choisir le bon lecteur, valider le canal puis dédupliquer
La collecte commence par une connexion active dont les informations d’accès sont valides. Le fournisseur associé doit lui aussi être actif et disponible. Ces contrôles évitent de lancer un appel externe depuis une configuration volontairement suspendue.
Ciama retrouve ensuite le canal. Lorsqu’un identifiant est fourni, le canal doit appartenir au même compte et au même fournisseur que la connexion. Sans identifiant, une unique correspondance active est exigée ; plusieurs canaux produisent une erreur explicite.
Le service sélectionne alors le lecteur Shopify ou Wix qui déclare prendre en charge la connexion. Aucun lecteur générique ne tente de deviner le format. Si aucune intégration ne correspond, l’exécution échoue avant de transformer une réponse inattendue.
Après lecture, chaque commande est recherchée par son identifiant dans son canal. Les nouvelles ventes partent vers le traitement d’ajout ; les ventes déjà connues partent vers la mise à jour. Le résultat conserve séparément le nombre collecté, le nombre à ajouter et le nombre à mettre à jour.
Compte, fournisseur et informations d’accès validés
Une boutique e-commerce clairement rattachée
API Shopify ou Wix et pagination propre à la source
Commande, lignes ou variante dans le modèle Ciama
Ajout ou mise à jour selon l’identifiant du canal
6. Collecter les commandes Shopify payées par fenêtre de mise à jour
Paginer sans perdre la période ni réintégrer les annulations
Le lecteur Shopify utilise une version explicite de l’API d’administration. Il demande jusqu’à 250 commandes par page, tous statuts d’exécution confondus mais avec un statut financier paid, et borne la recherche par date de dernière mise à jour.
La première page est triée par mise à jour croissante. Les suivantes utilisent le curseur page_info fourni dans l’en-tête de pagination, sans conserver les paramètres incompatibles avec ce curseur. La collecte s’arrête lorsque Shopify ne fournit plus de lien suivant.
Une commande annulée est ignorée. Parmi ses lignes, Ciama garde celles qui possèdent un SKU et une quantité strictement positive. Si aucune ligne ne passe ces contrôles, la commande entière n’est pas intégrée dans ce chemin.
Une commande fulfilled devient shipped ; les autres deviennent to_ship. Le montant d’une ligne est calculé à partir du prix multiplié par la quantité, moins la remise de ligne, avec un minimum de zéro. Le total et la devise de la commande restent également disponibles au niveau de l’en-tête.
7. Transformer les variantes Shopify en offres Ciama
Un SKU par variante et un produit source conservé
Pour les offres, Ciama demande les produits actifs et publiés, jusqu’à 250 par page. Une fenêtre de mise à jour peut être appliquée à la première page ; les pages suivantes poursuivent la pagination par curseur.
Chaque variante devient une offre distincte seulement si son SKU est renseigné. Ciama conserve son identifiant de variante, l’identifiant du produit parent, le prix, la quantité d’inventaire ramenée au minimum à zéro et l’état actif du produit.
L’image de la variante est recherchée parmi les images du produit grâce à son identifiant. En l’absence de correspondance, l’image principale du produit sert de repli. Titre, description nettoyée du HTML et type produit complètent les informations utiles à la recherche.
La devise correspondante est recherchée dans Ciama, avec l’euro comme repli disponible. Cette normalisation rend les montants affichables, sans promettre que le connecteur devine une devise absente ni qu’il modifie le tarif dans Shopify.
8. Lire les commandes Wix approuvées et leur exécution
Une recherche par curseur limitée aux ventes mises à jour
Wix expose ses commandes par une recherche POST. Ciama sélectionne le statut APPROVED et ajoute les bornes de date de mise à jour. Les résultats sont triés du plus récent au plus ancien et parcourus par curseur avec une limite de cent.
Le statut FULFILLED devient shipped ; les autres commandes approuvées deviennent to_ship. Le pays de livraison est recherché d’abord dans la destination d’expédition, puis dans les informations de retrait lorsque la commande utilise un pickup.
Seules les lignes possédant des propriétés physiques et un SKU rejoignent la collection de lignes. Quantité et prix de ligne sont normalisés. Le numéro, la date de création, le total et la devise donnent ensuite l’identité commerciale de la commande.
Le lecteur détecte bien le statut de paiement fourni par Wix, mais ce chemin ne filtre pas actuellement la commande sur ce booléen. La fiche ne prétend donc pas que seules les ventes payées Wix sont intégrées : le filtre structurant observable est le statut APPROVED.
9. Lire les variantes Wix malgré des réponses moins uniformes
Des replis contrôlés pour le SKU, le stock, le prix et les dates
Le lecteur d’offres Wix interroge la ressource de variantes par pages de cent. Il accepte les collections renvoyées sous plusieurs clés documentées par les réponses rencontrées et poursuit tant qu’un curseur suivant est disponible.
Le SKU peut venir de sku, variantSku ou merchantSku. Le stock est recherché dans plusieurs structures d’inventaire, puis vaut zéro si aucune quantité numérique n’existe. Les variantes sans aucun identifiant vendeur sont comptées comme ignorées et ne deviennent pas des offres.
L’état actif combine les indicateurs active, visible, hidden et inventoryStatus. Un statut out_of_stock désactive l’offre ; à défaut d’indicateur explicite, une quantité positive ou un état in_stock permet de la garder active. Le prix utilise d’abord le prix remisé, puis plusieurs replis structurés.
Ce lecteur effectue actuellement un chargement complet des variantes : une période éventuellement demandée est journalisée mais n’est pas appliquée à l’API Wix. La fiche l’assume afin de ne pas présenter une synchronisation incrémentale qui n’existe pas encore sur les offres.
10. Installer une vue dédiée aux canaux e-commerce
Voir activité, validité et volumes avant de lancer une collecte
La recherche Canaux impose le compte connecté et le type ecommerce. Elle est triée par montant de ventes décroissant par défaut et paginée par cinquante. Une recherche textuelle permet d’isoler rapidement une boutique.
Chaque ligne affiche le canal, son état actif, la validité de ses informations d’accès, le nombre de commandes, le nombre d’offres actives avec stock et la date de dernière mise à jour. Ces repères distinguent un canal silencieux d’une connexion manifestement invalide.
Le menu de la ligne permet d’ouvrir la vue transversale du canal, de demander les dernières commandes ou de relancer la collecte des offres. Les actions restent rattachées au canal sélectionné, ce qui évite de déclencher une reprise sur une boutique ambiguë.
Le nombre de canaux actifs affiché dans l’en-tête est calculé sur les résultats présents dans la page courante, tandis que le total utilise la pagination. La fiche ne transforme donc pas ce compteur visuel en inventaire exhaustif lorsque plusieurs pages existent.
11. Rechercher les commandes e-commerce sans perdre leur contexte
Canal, statut, exécution et période dans un même filtre
La vue Commandes impose le compte et le type ecommerce. Elle propose une recherche textuelle, le canal, le statut, le mode FBM ou FBP, l’année et le mois. L’année courante est sélectionnée par défaut afin de ne pas charger involontairement tout l’historique.
Les canaux proposés sont les canaux e-commerce actifs du compte. Les années viennent des commandes réellement présentes ; lorsqu’aucune n’existe encore, l’année courante garde le formulaire utilisable. Le mois n’apparaît que lorsqu’une année est sélectionnée.
La table présente cinquante commandes par défaut, triées par date d’achat décroissante. Elle rapproche le canal, l’identifiant, le statut, le mode d’exécution, le pays de livraison, les montants TTC et HT, la TVA, les coûts disponibles, la marge et la dernière mise à jour.
Les coûts et la marge peuvent être réels ou estimés selon les données disponibles. L’interface conserve leur origine plutôt que d’afficher une précision artificielle. Un clic sur l’identifiant ouvre la vue détaillée de la commande e-commerce.
12. Piloter les offres e-commerce dans leur propre radar
Filtrer catalogue, disponibilité et activité sans mélanger les univers
La vue Offres impose elle aussi le compte et le type ecommerce. Ses filtres couvrent recherche textuelle, activité, exécution par vendeur ou plateforme, présence de stock, canal, marque, catégorie, tag et année optionnelle.
Les marques, catégories et tags viennent du référentiel du compte. Les canaux proposés appartiennent à l’univers e-commerce. Cette construction permet de partir d’un signal catalogue puis de réduire la recherche à une boutique précise.
Les résultats sont paginés par cinquante et triés par quantité vendue sur 360 jours décroissante par défaut. La table montre logo du canal, image, SKU, mode d’exécution, activité, stock, prix converti, signaux de concurrence lorsqu’ils existent, ventes annuelles et mise à jour.
Certains champs communs ont surtout du sens pour une marketplace, par exemple buy box ou concurrents. Sur une offre Shopify ou Wix sans cette donnée, l’interface affiche un état neutre. Le modèle partagé n’invente pas une information propre aux marketplaces.
13. Faire vivre le cockpit avec deux cadences adaptées
Reprendre fréquemment les commandes, moins souvent le catalogue d’offres
En production, la collecte des commandes est déclenchée toutes les dix minutes pour les connexions marketplace et e-commerce actives. Chaque passage reprend une fenêtre glissante de deux heures, ce qui permet de relire les ventes récemment modifiées.
La collecte des offres est lancée toutes les deux heures par connexion fournisseur. Cette cadence correspond à un catalogue et des stocks qui ont besoin d’être rafraîchis sans imposer la fréquence plus forte du flux de commandes.
Avant chaque envoi, les fonctions activées, la connexion, les informations d’accès et la disponibilité du fournisseur sont contrôlées. Une intégration suspendue est ignorée proprement au lieu d’accumuler des traitements voués à échouer.
Les actions manuelles visibles dans la vue Canaux complètent ces cycles. Elles servent à reprendre un canal choisi lorsqu’une équipe vient de corriger sa configuration ou souhaite vérifier une mise à jour, sans modifier la cadence générale.
14. Les arbitrages qui évitent un faux cockpit unifié
Partager le modèle sans promettre une synchronisation bidirectionnelle
Le premier arbitrage est de conserver le type ecommerce. Les objets utilisent les mêmes fondations que les ventes marketplace, mais chaque recherche impose son univers. Une comparaison devient possible sans effacer la source de la vente.
Le deuxième est de lire plutôt que pousser. Ce projet intègre commandes et variantes dans Ciama ; il ne diffuse pas ici de prix, de stock ou de contenu vers les boutiques. Une synchronisation bidirectionnelle demanderait des règles de priorité et de conflit supplémentaires.
Le troisième est de ne pas présenter le stock d’une offre comme un stock global partagé. Shopify et Wix exposent une quantité sur leur variante ; Ciama l’affiche dans le canal correspondant. Aucune réservation automatique entre boutique et marketplace n’est revendiquée.
Le quatrième est d’accepter des limites différentes selon la source. Shopify applique une fenêtre aux offres, Wix réalise actuellement un chargement complet. Ces comportements restent derrière une interface commune, mais la fiche ne prétend pas qu’ils sont techniquement identiques.
15. Sécuriser les frontières avant de consolider les ventes
Compte, connexion, canal, SKU et identifiant comme garde-fous
Toute connexion appartient à un compte. Le canal doit partager ce compte et le même fournisseur, tandis que les recherches du back-office ajoutent systématiquement accountId et channelType. Ces contrôles limitent les données avant même leur présentation.
Le SKU protège le rapprochement des lignes et variantes. Lorsqu’il manque, l’objet concerné est ignoré au lieu d’être associé à un produit approximatif. Le nombre d’éléments écartés peut être journalisé par le lecteur d’offres Wix.
L’identifiant externe et le canal forment la clé de recherche d’une commande déjà connue. Deux boutiques peuvent donc utiliser le même numéro sans être confondues. À l’intérieur d’un même canal, une reprise récente devient une mise à jour plutôt qu’une seconde vente.
Les erreurs d’accès HTTP, réponses invalides, informations d’identification manquantes et fournisseurs non pris en charge produisent des échecs explicites. Cette stratégie permet au monitoring de montrer le vrai point de rupture au lieu de créer des objets partiels silencieusement.
16. Ce qui change après la livraison
Un run e-commerce visible dans le même environnement de décision
L’équipe n’a plus besoin d’ouvrir Shopify et Wix pour dresser la liste croisée des ventes récentes. La recherche Commandes réunit les deux sources, conserve leur canal et propose les mêmes repères de statut, période, exécution et rentabilité.
Le catalogue direct devient lui aussi consultable selon une grille commune. Une personne peut filtrer les offres sans stock, désactivées ou rattachées à une marque, puis ouvrir l’offre détaillée. Les spécificités absentes restent visibles comme telles.
Chaque boutique rejoint l’historique du canal et les vues globales de Ciama. Les ventes directes peuvent donc contribuer au reporting multicanal sans être comptées comme des commandes marketplace. Cette séparation améliore la qualité des comparaisons.
Enfin, le diagnostic devient plus court. La vue Canaux montre immédiatement une connexion invalide, une boutique inactive ou un volume qui ne se renouvelle plus. L’équipe peut relancer la bonne collecte et vérifier ensuite les objets créés ou actualisés.
17. Le scénario de contrôle qui résume le projet
Retrouver une vente directe manquante sans dérégler les marketplaces
Une équipe constate qu’une commande récente apparaît dans Shopify mais pas dans sa recherche e-commerce. Elle commence par la vue Canaux : la boutique est active, mais les informations d’accès sont signalées invalides et sa date de mise à jour ne progresse plus.
Après correction de la connexion, elle relance les dernières commandes sur ce canal. Le lecteur reprend la fenêtre récente, écarte les commandes annulées, conserve les lignes possédant un SKU et programme l’ajout de la vente absente ou la mise à jour de celles déjà connues.
La commande apparaît ensuite dans l’univers e-commerce, avec son statut shipped ou to_ship, son canal, son total et ses lignes. Elle n’est pas mélangée dans la recherche marketplace, car son channelType reste ecommerce.
Si une variante associée manque également, l’équipe déclenche la collecte des offres du même canal. Elle contrôle le SKU et l’état source avant de conclure à une erreur de catalogue. Chaque action reste ciblée sur la boutique concernée.
18. Relier la collecte e-commerce aux autres preuves Ciama
Connecteurs, commandes et reporting gardent chacun leur responsabilité
Le hub de connecteurs vendeur présente l’architecture qui choisit un lecteur par fournisseur et protège les frontières de connexion. Ce projet en constitue l’application directe à Shopify et Wix.
La centralisation des commandes marketplace traite le même problème pour Amazon, Fnac/Darty, Cdiscount ou Mirakl. Les deux projets partagent un modèle, mais les sources et univers restent distincts.
L’historique des ventes par canal prend le relais une fois les ventes intégrées. Il transforme les faits mensuels du canal e-commerce en courbes, comparaisons annuelles et classements catalogue.
Le module e-commerce de Ciama détaille enfin la dimension produit et API de cet univers. Ici, la preuve reste centrée sur le bénéfice vendeur : voir et exploiter les boutiques directes dans le cockpit multicanal.
19. Conclusion
Unifier le pilotage ne signifie pas uniformiser les sources
Ce projet donne à Shopify et Wix une place claire dans Ciama. Les commandes et variantes suivent des lecteurs adaptés à leur API, puis rejoignent des objets communs capables d’alimenter recherches, détails et reporting.
La qualité de l’intégration tient à ses frontières : type e-commerce conservé, connexion et canal validés, SKU obligatoire pour les lignes utiles, déduplication par canal, cadences explicites et aucune promesse de stock partagé ou de diffusion bidirectionnelle qui ne serait pas livrée.
C’est cette discipline que Dawap applique à l’automatisation des flux marketplace : connecter chaque source selon ses règles, normaliser ce qui doit être comparable et laisser les équipes agir depuis un cockpit dont les chiffres restent traçables.
