Le projet en un coup d’œil
Shopify et Wix n’exposent ni la même authentification, ni les mêmes filtres, ni la même pagination, alors que Ciama doit produire les mêmes objets de vente.
Un lecteur commandes et un lecteur offres sont dédiés à chaque fournisseur. Une orchestration provider-first sélectionne automatiquement le client compatible avec la connexion.
Commandes et variantes rejoignent le modèle Ciama avec leur canal, leur identifiant et leur SKU. Les écritures sont ensuite distribuées dans les traitements asynchrones adaptés.
Ajouter deux boutiques à un cockpit ne consiste pas à remplacer le nom de la plateforme dans une URL. Shopify travaille avec une API Admin, des pages liées par un curseur et un filtre financier. Wix utilise des recherches POST, des curseurs placés dans le corps et des structures différentes pour les commandes, les variantes, les stocks et les images.
Ciama devait pourtant obtenir un résultat homogène : une commande rattachée à un canal avec des lignes exploitables, ou une offre identifiée par son SKU avec prix, quantité, activité et origine. Le modèle commun devait faciliter le pilotage sans effacer les règles propres à chaque source.
Dawap a construit quatre lecteurs spécialisés derrière deux contrats partagés : lire des commandes et lire des offres. Une orchestration dite provider-first examine la connexion, choisit le client Shopify ou Wix compatible, collecte les données, puis confie leur ajout ou leur mise à jour aux traitements asynchrones de Ciama.
Cette étude montre la dimension intégration API e-commerce du projet : sélection du fournisseur, contrôle des frontières de compte, pagination, transformation des données et comportement face aux reprises. La fiche cockpit voisine raconte ce que l’utilisateur fait ensuite de ces objets.
1. Ciama, un modèle de vente commun à plusieurs familles de canaux
Marketplace, e-commerce et B2B partagent des fondations sans perdre leur univers
Ciama réunit les canaux, produits, offres, commandes, lignes et faits de vente d’un compte. Le type de canal reste explicite : une boutique e-commerce ne devient pas une marketplace et une commande B2B ne disparaît pas dans une moyenne indifférenciée.
Cette structure donne une cible aux connecteurs. Quelle que soit la plateforme distante, une commande collectée doit fournir son canal, son identifiant, sa date, son statut et ses lignes. Une offre doit fournir au minimum son canal, son SKU, son état de stock, sa quantité, son prix et son activité.
La normalisation ne cherche pas à conserver chaque détail propriétaire. Elle sélectionne les données utiles aux parcours Ciama et garde l’identifiant externe nécessaire pour retrouver la source. Les informations sans équivalent fiable ne sont pas fabriquées.
Le projet accompagne ainsi le cockpit e-commerce Shopify et Wix. La présente fiche traite le raccordement API ; l’autre détaille les recherches Canaux, Commandes et Offres proposées aux équipes.
2. Choisir le lecteur à partir de la connexion, puis normaliser une seule fois
La source reste spécifique ; la décision d’écriture devient commune
Chaque connexion porte un fournisseur, un compte, des informations d’accès et un état d’activation. Le pipeline vérifie cette frontière avant de demander la moindre donnée. Un fournisseur indisponible ou des informations invalides produisent un échec explicite.
L’orchestrateur parcourt ensuite les clients de lecture enregistrés. Chacun déclare s’il supporte la combinaison type e-commerce et identifiant du fournisseur. Shopify sélectionne son lecteur ; Wix sélectionne le sien. Aucun branchement conditionnel dispersé n’est nécessaire dans le cas d’usage.
Le lecteur traduit sa réponse dans une collection d’objets de transfert communs. Le cas d’usage peut alors chercher l’objet existant avec les clés du domaine, sans connaître la forme du JSON d’origine.
Si l’objet n’existe pas, un message d’ajout est distribué. S’il existe, un message de mise à jour prend le relais. Cette séparation garde les appels distants synchrones à la collecte, puis découple la persistance détaillée des objets récupérés.
3. Placer quatre lecteurs derrière deux contrats communs
Commandes et offres constituent les deux intentions stables du pipeline
Shopify possède un lecteur de commandes et un lecteur d’offres. Wix possède les deux mêmes rôles. Chaque classe connaît l’authentification, l’endpoint, les paramètres et la pagination de sa plateforme, mais restitue une collection comprise par le domaine Ciama.
Le contrat commandes demande une connexion et une fenêtre temporelle. Il renvoie des commandes avec leurs lignes. Le contrat offres accepte une connexion, un canal et éventuellement une période, puis renvoie des variantes transformées en offres.
Cette symétrie ne signifie pas que les API deviennent identiques. Le lecteur Shopify peut suivre un lien page_info ; le lecteur Wix lit un curseur dans les métadonnées. Le contrat commun porte le résultat, pas la mécanique du fournisseur.
Ajouter un autre fournisseur e-commerce revient ainsi à fournir les lecteurs compatibles avec ces intentions. Le cas d’usage de collecte peut conserver ses contrôles, ses compteurs et sa décision ajout ou mise à jour.
4. Sélectionner le client compatible avec la connexion
Le type e-commerce et l’identifiant du fournisseur déterminent le lecteur
Chaque lecteur expose une fonction de support. Le client Shopify accepte uniquement un fournisseur de type ecommerce dont l’identifiant vaut shopify. Le client Wix applique la même règle avec wix.
Le service de lecture parcourt les clients enregistrés et retient celui qui reconnaît la connexion. Il n’a pas besoin de connaître leurs classes concrètes ni de reproduire une liste de cas à chaque nouvelle opération.
Cette organisation, finalisée dans la migration provider-first de mars 2026, remplace des flux historiques séparés par famille de canal. La connexion fournisseur devient le point de départ stable pour les marketplaces, les boutiques et certaines intégrations ERP.
La décision reste vérifiable : un fournisseur sans lecteur compatible provoque une erreur au lieu de retourner une collection vide qui pourrait être prise pour une boutique sans vente ou sans catalogue.
5. Refuser la collecte avant l’API lorsque la connexion est incohérente
Activation, informations d’accès, fournisseur et version sont contrôlés en amont
Le cas d’usage commence par exiger l’identifiant de connexion. Pour les commandes, les bornes de période doivent être présentes et ordonnées. Pour les offres, elles peuvent être toutes deux absentes ou toutes deux présentes, jamais à moitié.
La connexion doit exister, être active et porter des informations d’accès considérées comme valides. Le fournisseur associé doit lui aussi exister, être actif et disponible. Une version configurée doit encore être active.
Ces validations empêchent un appel dont l’échec est déjà connu. Elles différencient également une configuration suspendue d’une erreur HTTP réellement renvoyée par Shopify ou Wix.
Le pipeline préserve enfin la limite du compte. La connexion, le canal et les futurs objets doivent appartenir au même espace. Cette contrainte intervient avant la collecte et se retrouve dans les recherches du cockpit.
6. Rattacher chaque collecte à un canal sans choix ambigu
Compte et fournisseur doivent correspondre des deux côtés
Lorsqu’un canal est fourni, il doit exister, appartenir au compte de la connexion et utiliser le même fournisseur. Un identifiant valide dans un autre compte ne peut pas être retenu par accident.
Lorsqu’aucun canal n’est fourni, le cas d’usage cherche les canaux actifs du compte pour ce fournisseur. Une seule correspondance est acceptée. Zéro correspondance signale une configuration incomplète ; plusieurs correspondances exigent un choix explicite.
Cette règle protège particulièrement les environnements multi-boutiques. Deux boutiques Shopify peuvent utiliser le même fournisseur tout en représentant deux ventes, catalogues et identités séparés. La connexion seule ne suffit alors pas à deviner le canal.
Le canal choisi accompagne tous les objets normalisés. Il participe ensuite aux clés de recherche, aux filtres du cockpit et aux faits de reporting. La séparation initiale reste donc visible jusqu’à l’usage métier.
7. Obtenir un jeton Shopify avant chaque lecture
Domaine de boutique, identifiant client et secret forment la configuration attendue
Les lecteurs Shopify normalisent d’abord le domaine de la boutique. Un protocole éventuel est retiré, le slash final disparaît et un nom court peut recevoir le domaine myshopify.com. Cette préparation évite plusieurs formes d’URL pour la même boutique.
La connexion fournit ensuite un identifiant client et un secret. Le lecteur demande un access token au point d’entrée OAuth de la boutique avec le flux client credentials. L’absence de l’un des trois éléments arrête la lecture avec une erreur nommée.
Le jeton obtenu est transmis dans l’en-tête Shopify de l’API Admin. Les lecteurs utilisent la version 2026-01 observée dans la version actuelle du module. Le numéro reste concentré dans les classes Shopify.
Une réponse d’authentification hors plage 2xx ou sans access token est distinguée d’un échec sur les commandes ou les produits. Cette précision raccourcit le diagnostic : l’équipe sait si elle doit examiner les accès ou le contenu de la requête suivante.
8. Collecter les commandes Shopify payées et modifiées dans la fenêtre
Le lecteur retient les ventes utiles avant de construire les lignes Ciama
La requête demande jusqu’à deux cent cinquante commandes, tous statuts confondus, mais avec un statut financier paid. Elle borne updated_at entre le début et la fin transmis, trie les modifications par ordre croissant et limite les champs à ceux nécessaires au mapping.
Une commande annulée est écartée. Ses lignes doivent former un tableau ; chaque ligne doit porter un SKU et une quantité strictement positive. Une commande sans aucune ligne utilisable ne rejoint pas Ciama.
Le statut de fulfillment fulfilled devient shipped. Les autres états deviennent to_ship. Pour chaque ligne, la quantité est répartie entre expédié et à expédier selon ce statut commun.
Le total de ligne correspond au prix multiplié par la quantité, diminué de la remise totale avec un plancher à zéro. La commande conserve aussi total, devise, pays, client, e-mail et adresses lorsqu’ils existent.
9. Transformer chaque variante Shopify publiée en offre Ciama
Produit actif, variante identifiée et stock source composent l’objet
La lecture des produits demande les objets actifs et publiés, jusqu’à deux cent cinquante par page. Elle sélectionne titre, description, statut, dates, type, images et variantes.
Chaque variante possédant un SKU devient une offre. Une variante sans SKU est ignorée, car Ciama ne disposerait pas de clé catalogue fiable pour la rapprocher de son produit et de son canal.
La quantité vient de l’inventaire Shopify avec un plancher à zéro. Le prix taxé, le statut actif, la devise, les identifiants externes du produit et de la variante, le titre, la description nettoyée et l’image complètent le transfert.
L’image de variante est privilégiée lorsqu’elle correspond à une image du produit ; l’image principale sert de repli. Le mapping conserve ainsi une représentation exploitable sans télécharger ni republier le média vers la boutique.
10. Suivre le curseur Shopify sans reconstruire la page suivante
Le lien HTTP fournit page_info pour continuer la collecte
Après chaque réponse, le lecteur examine l’en-tête Link et recherche la relation next. Il extrait page_info puis rappelle le même endpoint avec ce curseur tant qu’une page suivante existe.
À partir de la deuxième page, les bornes et le tri initiaux sont retirés de la requête au profit de page_info, conformément au mode de pagination Shopify. Le curseur transporte la continuité de la sélection.
Le même mécanisme sert aux commandes et aux produits. La limite de deux cent cinquante réduit le nombre d’allers-retours, tandis que la boucle garantit que la première page n’est pas prise pour un snapshot complet.
Une réponse sans collection attendue produit une erreur de format. Le pipeline distingue donc une boutique réellement vide d’un document JSON valide mais incompatible avec le contrat prévu.
11. Lire les commandes Wix approuvées par date de mise à jour
Le statut de paiement est conservé sans devenir le filtre d’entrée
Le lecteur Wix appelle la recherche e-commerce avec une requête POST. Il ajoute les bornes updatedDate et exige le statut APPROVED. La sélection ne filtre pas les commandes sur PAID : ce statut sert ensuite à renseigner l’état payé de l’objet collecté.
Une commande fulfillmentStatus FULFILLED devient shipped ; les autres deviennent to_ship. Le pays peut venir d’une destination de livraison ou, dans le cas du retrait, des informations de pickup.
Seules les lignes qui possèdent des propriétés physiques et un SKU non vide sont transformées. Cette règle écarte les lignes sans identité de produit exploitable par le catalogue Ciama.
La commande garde son numéro, sa date, son statut, ses lignes, son pays, son total et sa devise. Le lecteur ne force pas les structures client ou adresse propres à Shopify dans un objet Wix qui ne les fournit pas de la même manière.
12. Reconstituer une offre Wix malgré plusieurs formes de variante
SKU, quantité, prix, activité et média sont résolus par priorité
Le lecteur interroge le point d’entrée variants/query de Wix Stores avec la clé API et l’identifiant du site. Il recherche les variantes dans plusieurs clés de réponse compatibles : variants, items ou results.
Le SKU peut venir de sku, variantSku ou merchantSku. La quantité est recherchée dans plusieurs emplacements d’inventaire. Le prix privilégie le prix remisé, puis le prix principal et les formes converties disponibles.
L’activité respecte d’abord les booléens active, visible ou hidden. Elle examine ensuite le statut d’inventaire : out_of_stock désactive l’offre ; in_stock ou une quantité positive permet de la garder active selon le contexte.
Nom, description, identifiants produit et variante, catégorie, image et dates suivent la même stratégie de résolution. Cette souplesse absorbe les variantes de structure Wix sans fabriquer de SKU lorsqu’aucune clé fiable n’existe.
13. Parcourir Wix par curseur de cent objets
Les métadonnées commandent la suite de la lecture
Les commandes et les offres Wix utilisent une limite de cent objets. Lorsque metadata.hasNext vaut vrai, le curseur next est repris dans le corps de la requête suivante.
Si le service signale une suite sans fournir de curseur dans la lecture des variantes, le lecteur peut se fonder sur la taille de page pour décider de continuer. Chaque page et le nombre de variantes sans SKU sont journalisés.
Les commandes utilisent les bornes temporelles demandées. Les offres Wix réalisent actuellement un chargement complet : une période transmise est journalisée comme ignorée. Cette différence reste volontairement visible dans le comportement.
Le snapshot complet permet de comparer l’état courant du canal. Il coûte davantage qu’une lecture incrémentale ; c’est pourquoi sa fréquence et son caractère complet doivent rester distincts du cycle plus court des commandes.
14. Ramener les ventes à une commande et des lignes communes
Canal, identifiant et SKU forment les repères stables
Le transfert commande conserve l’identifiant du canal, ses identifiants commerciaux, l’identifiant distant, la date d’achat, le statut, l’état payé et la collection de lignes. Ces champs suffisent au cas d’usage pour décider de la suite.
Chaque ligne conserve SKU, quantité, quantités expédiée et à expédier, montant taxé et statut. Shopify calcule la remise de ligne ; Wix reprend le montant exposé. Le modèle commun accepte cette différence de provenance.
Pays, devise, total et informations client enrichissent l’objet lorsqu’ils existent. Une valeur absente reste absente. La normalisation garantit une forme, pas une complétude artificielle identique entre fournisseurs.
Le type ecommerce reste porté par le canal enregistré dans Ciama. La commande normalisée peut rejoindre des services communs sans apparaître dans les recherches réservées aux marketplaces.
15. Ramener les variantes à une offre catalogue exploitable
Le SKU reste obligatoire là où les champs éditoriaux sont optionnels
Le transfert offre rassemble canal, SKU, état neuf, quantité, prix taxé, activité, mode d’exécution, devise et identifiants externes. Nom, description, média, catégorie et dates complètent la lecture lorsque la source les fournit.
Shopify et Wix indiquent tous deux l’exécution par la plateforme dans le mapping actuel. Cette donnée permet au cockpit de conserver le même champ que les autres canaux, sans lui attribuer une logique marketplace de buy box ou de concurrence.
Le prix est associé à une devise résolue dans le référentiel Ciama, avec l’euro comme repli lorsque la source ne fournit pas une devise connue. La conversion financière reste une étape séparée du connecteur.
Une quantité lue est bornée à un entier cohérent et l’activité reste un signal de la source. Le pipeline n’en déduit pas un stock global disponible sur tous les canaux.
16. Décider entre ajout et mise à jour avec les clés du canal
Une même référence externe peut exister dans deux boutiques sans collision
Pour chaque commande, le cas d’usage recherche l’identifiant distant dans le canal courant. L’absence déclenche un message d’ajout ; la présence déclenche un message de mise à jour. Une reprise glissante actualise donc la vente existante.
Pour chaque offre, la première recherche combine canal, SKU et état de stock. Une seconde recherche par canal et SKU sert de repli. La décision conserve le périmètre de la boutique et évite de confondre deux variantes de canaux différents.
Les réponses du cas d’usage comptent les objets collectés, ajoutés et mis à jour. Ces compteurs décrivent la décision de distribution, pas encore le succès final de chaque message traité ensuite.
Cette nuance garde le monitoring lisible. La collecte peut avoir trouvé cent objets et programmé cent mises à jour ; l’exécution asynchrone de ces mises à jour possède sa propre progression et ses propres erreurs.
17. Désactiver les offres absentes uniquement après un snapshot fiable
Une réponse vide ou partielle ne doit pas effacer le catalogue actif
Lorsqu’une collecte d’offres n’utilise aucune borne, elle peut représenter un snapshot complet du canal. Le pipeline mémorise les identifiants collectés et peut désactiver les offres actives qui ne figurent plus dans cet état.
Trois garde-fous encadrent cette action : la collecte doit être sans période, contenir au moins un objet et déclarer son snapshot complet. Une réponse vide ne devient donc pas automatiquement la preuve que toute la boutique a été vidée.
La protection contre une collecte vide a été renforcée le 8 septembre 2026. Les warnings de source et le caractère complet remontent dans la réponse avant toute désactivation.
Ce choix distingue une synchronisation sûre d’un simple remplacement en masse. L’absence d’une offre devient significative uniquement lorsque le lecteur confirme qu’il a observé un état complet et non un fragment ou une erreur.
18. Distribuer les écritures sans bloquer la collecte distante
Ajout et mise à jour possèdent leurs messages distincts
Après normalisation, le cas d’usage ne persiste pas toute la collection dans la boucle réseau. Il construit une demande d’ajout ou de mise à jour puis l’envoie au messenger des commandes ou des offres.
Chaque message peut garder l’identifiant du journal d’exécution de la collecte. Les traitements descendants restent ainsi rattachés à leur opération parente lorsqu’ils sont observés dans le monitoring.
La séparation absorbe une collection volumineuse sans maintenir la requête fournisseur ouverte pendant chaque écriture. Elle permet également de traiter indépendamment un objet qui échoue alors que les autres sont valides.
Le pipeline n’efface toutefois pas la différence entre « message distribué » et « objet écrit ». Les compteurs de collecte restent des décisions de routage ; le suivi des enfants complète la lecture du résultat.
19. Adapter la fréquence à la nature du flux
Deux heures de reprise pour les commandes, un cycle plus long pour les offres
En production, une commande lance toutes les dix minutes la collecte par connexion fournisseur active. Pour l’e-commerce, chaque passage relit une fenêtre glissante de deux heures afin de reprendre les ventes récemment créées ou modifiées.
Le recouvrement temporel est volontaire : une commande déjà connue sera mise à jour grâce à la clé canal-identifiant, plutôt que créée une seconde fois. Il réduit le risque qu’un retard de source tombe exactement entre deux passages.
Les offres sont collectées toutes les deux heures par connexion. Leur cadence correspond à un catalogue de variantes, prix et stocks qui n’exige pas la même fréquence que l’arrivée des commandes.
Des commandes d’historique peuvent élargir la période. Le pipeline conserve les mêmes lecteurs et décisions, que la collecte vienne du cycle récurrent ou d’une reprise ciblée.
20. Nommer le point de rupture au lieu de retourner un état trompeur
Configuration, authentification, HTTP et format de réponse restent distingués
Une connexion absente, inactive ou invalide produit une erreur différente d’un fournisseur indisponible. Une version inactive et un canal incohérent possèdent eux aussi leur propre résultat de validation.
Les lecteurs Shopify distinguent les informations d’accès manquantes, l’échec HTTP d’authentification, une réponse de jeton invalide, l’échec HTTP de lecture et le document sans collection attendue.
Le lecteur d’offres Wix distingue les informations manquantes, l’échec HTTP et la réponse invalide. Le nombre de variantes écartées faute de SKU est journalisé par page, ainsi que l’ignorance actuelle d’une plage temporelle.
Le cas d’usage offres intercepte enfin un échec du lecteur et le transforme en erreur de collecte provider. L’absence de données ne doit pas masquer un appel cassé, particulièrement lorsque le snapshot pourrait influencer l’activité des offres existantes.
21. Contrôler les lecteurs sans appeler les vraies boutiques
Six fichiers unitaires couvrent la sélection, les mappings et les erreurs principales
Le périmètre e-commerce possède des tests unitaires dédiés au client de connexion Shopify, aux lecteurs commandes et offres Shopify, aux lecteurs commandes et offres Wix, ainsi qu’au puller de commandes Shopify.
Les réponses HTTP sont simulées. Les scénarios vérifient notamment le choix du fournisseur, le mapping d’un produit et de sa variante, la pagination Wix par curseur, l’exclusion d’un SKU vide et l’échec lorsque les informations d’accès manquent.
Trois tests applicatifs supplémentaires ouvrent les recherches e-commerce Canaux, Commandes et Offres. Ils complètent le contrôle du raccordement en vérifiant que les objets normalisés possèdent une destination visible.
Ces tests encadrent les comportements principaux. Les erreurs de format explicites prennent le relais lorsqu’une plateforme renvoie une forme nouvelle qui sort des scénarios déjà contrôlés.
22. Passer des flux historiques à une intégration provider-first
Mars 2026 installe le pipeline ; avril et septembre durcissent le snapshot
Une première intégration Wix des commandes existe dès octobre 2025. Le 12 mars 2026, les flux commandes et offres sont migrés vers une orchestration provider-first qui remplace les collecteurs historiques séparés.
Le 13 mars, Shopify reçoit ses lecteurs et rejoint les collectes e-commerce communes. Les offres acceptent une période optionnelle ; les commandes et variantes peuvent désormais alimenter la même chaîne d’ajout ou de mise à jour.
Les 16 et 17 mars, les recherches e-commerce sont alignées, les actions par canal sont ajoutées et le lecteur d’offres Wix est renforcé. Cette date marque la livraison cohérente du module et de son usage dans le cockpit.
Le 25 avril, un snapshot complet peut désactiver les offres disparues. Le 8 septembre, une collecte vide ne peut plus provoquer cette désactivation. Le projet raconte ainsi une intégration qui continue de protéger ses décisions après la première livraison.
23. Reprendre une commande Shopify et un catalogue Wix sans mélanger les règles
Le même pipeline garde deux comportements de source
Le cycle commandes trouve une connexion Shopify active. Le service choisit le lecteur Shopify, obtient son jeton, demande les ventes payées modifiées sur deux heures et parcourt les pages de deux cent cinquante.
Une commande déjà connue dans ce canal est retrouvée par son identifiant externe. Le pipeline distribue une mise à jour. Une nouvelle vente reçoit un ajout. Les lignes sans SKU restent hors de la collection au lieu de créer des rapprochements approximatifs.
Deux heures plus tard, le cycle offres trouve une connexion Wix. Son lecteur parcourt toutes les variantes par pages de cent, transforme celles qui possèdent un SKU et marque le snapshot comme complet lorsque la lecture l’est réellement.
Le pipeline ajoute ou met à jour les offres du canal Wix. Les identifiants absents ne peuvent désactiver une offre que si la collection est complète et non vide. Shopify et Wix empruntent la même orchestration, mais chacun conserve ses filtres, son curseur et ses garde-fous.
24. Ce que le pipeline rend durablement plus simple
Une nouvelle source se branche sur des intentions et des contrôles déjà établis
Les cas d’usage ne connaissent plus les détails de Shopify ou Wix. Ils valident connexion, fournisseur, version et canal, puis travaillent avec des collections de commandes ou d’offres. La différence de source reste concentrée dans quatre lecteurs.
Les clés canal-identifiant évitent les collisions entre boutiques. La reprise glissante actualise les commandes ; le snapshot complet peut retirer proprement une offre disparue sans réagir à une réponse vide.
Les traitements asynchrones séparent la durée de l’appel distant de l’écriture détaillée. Les compteurs collecté, ajouté, mis à jour et désactivé rendent chaque étape plus lisible dans le suivi d’exécution.
Le résultat n’est pas une uniformisation artificielle. Shopify conserve ses ventes paid et ses liens de pagination ; Wix conserve ses commandes approved et ses curseurs. Ce qui devient commun est la façon de protéger, transformer et distribuer les objets.
25. Les limites fonctionnelles du raccordement actuel
Lecture et normalisation précèdent encore toute synchronisation bidirectionnelle
Le pipeline collecte les commandes et les offres. Il ne publie ni produit, ni prix, ni stock vers Shopify ou Wix. Une diffusion sortante demanderait des règles de priorité, de conflit et de confirmation qui ne font pas partie de ce module.
Le stock de l’offre correspond à la quantité lue dans sa boutique. Il ne représente pas une réservation consolidée entre site direct, marketplace, ERP et entrepôt. Le cockpit doit conserver le canal lorsqu’il affiche cette valeur.
Les offres Wix sont chargées intégralement même lorsqu’une période est fournie. Cette stratégie donne un snapshot complet, mais ne constitue pas une synchronisation incrémentale optimisée.
L’extension à une nouvelle plateforme demandera son propre lecteur de commandes ou d’offres et ses scénarios de mapping. Le socle est prêt à l’accueillir ; le périmètre opérationnel présenté ici reste Shopify et Wix.
26. Relier la mécanique API à ses usages dans Ciama
Le cockpit, les connecteurs et l’historique commencent là où la collecte se termine
Le projet Shopify et Wix dans le cockpit Ciama montre les trois recherches qui exploitent ces objets. Il porte le point de vue utilisateur, tandis que cette fiche explique la mécanique d’intégration.
Le hub de connecteurs Ciama élargit la même architecture provider-first aux marketplaces. Chaque fournisseur possède son lecteur, mais les cas d’usage partagent leurs validations et leur distribution.
L’historique des ventes par canal transforme ensuite les commandes intégrées en faits mensuels et comparaisons. Il dépend de la qualité des identifiants et du type de canal préservés ici.
Notre accompagnement en API e-commerce suit la même démarche : comprendre les conventions de chaque plateforme, définir les objets communs réellement utiles et encadrer la reprise avant de multiplier les connecteurs.
27. Conclusion
Un pipeline commun gagne sa valeur en conservant les différences utiles
Ciama relie Shopify et Wix avec quatre lecteurs spécialisés et deux contrats partagés. La sélection provider-first choisit le bon client, les validations protègent la connexion et le canal, puis les mappings ramènent commandes et variantes vers un modèle exploitable.
La décision ajout ou mise à jour s’appuie sur les clés du canal. Les écritures passent dans des messages séparés, les snapshots complets peuvent désactiver une offre disparue et une réponse vide reste incapable d’effacer le catalogue.
Cette précision est au cœur de notre expertise en intégration API e-commerce : partager l’orchestration sans nier les contrats de chaque fournisseur, afin que de nouvelles boutiques rejoignent Ciama avec des règles lisibles et un diagnostic fiable.
