Ciama : rafraîchir une offre directement depuis sa marketplace

1. Ciama, une lecture commune de plusieurs back-offices vendeurs

Centraliser sans prétendre que la donnée locale ne vieillit jamais

Ciama Marketplace est le cockpit développé par Dawap pour piloter offres, commandes, catalogue, stock et performance sur plusieurs canaux. Il consolide des données hétérogènes afin que l’équipe n’ait pas à reconstruire son activité marketplace écran par écran.

Cette centralisation crée une exigence forte : chaque valeur doit garder une relation claire avec sa source. Une offre Ciama n’est pas une copie sans histoire. Elle appartient à un compte, à un canal, à un fournisseur et à une référence vendeur ; son prix peut être exprimé dans une autre devise et son stock dépend du mode de fulfilment.

Le rafraîchissement unitaire répond à ce besoin de confiance ponctuelle. Il ne remplace pas les collectes planifiées qui alimentent le portefeuille complet. Il donne une réponse ciblée lorsqu’une personne travaille sur une offre ou lorsqu’un autre processus doit vérifier le résultat d’une écriture.

2. Séparer la lecture marketplace de la mise à jour locale

Un contrat commun, puis des règles propres à chaque canal

Le premier lot, livré le 25 avril 2026, a établi le parcours de rafraîchissement, les premiers connecteurs Fnac/Darty et Amazon, l’action sécurisée dans le back-office et les contrôles unitaires, d’intégration et d’interface. L’offre ciblée pouvait déjà être relue sans déclencher un import global.

Le lendemain, le flux a été rendu autonome par rapport au traitement général des offres. Un objet dédié transporte la réponse du canal ; une mise à jour spécialisée ne touche que les champs autorisés. Cdiscount/Octopia et Mirakl/Cultura ont rejoint le même contrat, avec leurs propres protocoles et règles d’extraction.

Cette architecture a ensuite été réutilisée dans le Stock Dispatcher et après les envois de stock. Un même cœur métier répond ainsi à trois interfaces sans dupliquer les validations, la conversion monétaire ou la façon de traiter une réponse incomplète.

3. Avant le projet : choisir entre trop large et trop manuel

Une question sur une offre ne justifie pas toujours une collecte complète

Les collectes planifiées restent indispensables pour maintenir un portefeuille d’offres. Elles parcourent les données d’un fournisseur, appliquent les correspondances et sauvegardent les résultats. Leur coût et leur temporalité sont adaptés à une synchronisation de masse, pas nécessairement à une vérification immédiate.

À l’autre extrême, l’équipe pouvait se connecter au back-office de la marketplace, retrouver l’offre et comparer visuellement les valeurs. Cette méthode répond à la question, mais elle multiplie les interfaces, dépend des droits disponibles sur chaque canal et ne met pas automatiquement Ciama à jour.

Le manque apparaissait surtout après une action. Un stock venait d’être envoyé, une offre semblait inactive ou un prix paraissait ancien : il fallait savoir ce que le canal renvoyait maintenant, sans attendre le prochain cycle et sans lancer une opération disproportionnée.

Le projet a été cadré autour de cette tension. L’objectif n’était pas d’augmenter la fréquence de tous les flux, mais de donner au produit une lecture ciblée, immédiate et réutilisable.

4. Un objectif : réconcilier une offre et seulement cette offre

Revenir à la source sans perturber le reste du catalogue

Le service reçoit deux informations métier : le compte actif et l’offre à contrôler. À partir de cette identité, il retrouve le canal et le fournisseur, vérifie leurs relations, puis demande au connecteur une lecture précise de la référence vendeur.

La réponse doit ramener les éléments qui permettent de travailler : quantité, prix TTC, devise, statut actif, type de fulfilment et, lorsqu’ils existent, identifiant produit marketplace, image et dates du canal. Chaque connecteur construit le même résultat malgré un format externe différent.

Ciama ne sauvegarde ensuite que le sous-ensemble utile à l’offre locale. Cette étape volontairement spécialisée évite que le rafraîchissement d’une ligne déclenche les effets secondaires d’une collecte ou d’un enrichissement complet.

Le parcours rend donc la fraîcheur pilotable. L’équipe choisit l’offre concernée ; le produit choisit le bon connecteur et applique toujours les mêmes règles de protection.

5. Ce que « autonome » signifie dans ce projet

Un service indépendant, pas un robot qui modifie les offres seul

L’autonomie concerne d’abord l’architecture. Le rafraîchissement possède son propre contrat de lecture et son propre objet de mise à jour. Il ne détourne pas le flux général d’ajout ou de modification d’offres pour produire une simple relecture.

Le service peut être appelé depuis une action utilisateur ou par un traitement qui suit un envoi de stock. Dans les deux cas, il exécute la même validation, contacte la marketplace et réconcilie la réponse selon les mêmes règles.

Il ne calcule pas un prix de vente, ne change pas une règle de marge et ne lance pas un repricing. Il constate ce que le canal expose. Cette frontière protège la compréhension du produit : décider, écrire et relire sont trois responsabilités différentes.

Le projet complète ainsi l’optimisation des offres marketplace sans se substituer aux décisions commerciales qui relèvent de cette démarche.

6. Vérifier le compte, l’offre et le canal avant l’appel

Une action ciblée ne doit jamais élargir le périmètre de données

Le service refuse une demande sans compte ou sans offre. Il vérifie ensuite que l’offre appartient au compte actif, que son canal appartient au même compte et que ce canal est bien de type marketplace. Modifier un identifiant envoyé par l’interface ne suffit donc pas à rafraîchir l’offre d’une autre organisation.

Le fournisseur doit exister, être de type marketplace, actif et disponible. Le canal doit posséder son identifiant de catalogue et ses informations de connexion. Amazon demande en plus l’identifiant vendeur nécessaire à l’appel.

L’action du back-office est envoyée en POST et protégée contre les requêtes détournées. En cas d’échec, l’interface renvoie un message contrôlé plutôt que le détail brut des accès ou de la réponse interne.

Ces contrôles rendent l’action sûre à exposer dans plusieurs écrans. Le raccourci offert à l’utilisateur ne contourne ni l’isolation du compte ni les préconditions du connecteur.

7. Quatre familles de connecteurs derrière une même intention

Absorber les protocoles sans les imposer à l’équipe

Fnac/Darty retrouve l’offre à travers son dialogue vendeur. Amazon Europe interroge le listing pour le SKU et le pays exact. Cdiscount/Octopia recherche l’offre avec la référence vendeur et le canal de vente. Mirakl cible l’offre par son SKU sur Cultura ou sur une autre instance configurée.

Chaque connecteur sait reconnaître les identifiants de canal qu’il prend en charge. Le processeur sélectionne le bon support ; si aucun ne correspond, le rafraîchissement échoue explicitement. Le produit ne transforme jamais une absence d’implémentation en résultat vide.

Les formats sont très différents : XML pour certains échanges Fnac, JSON pour Amazon et Cdiscount, structures Mirakl variables selon les champs disponibles. La couche de connexion extrait pourtant toujours une quantité, un prix, une devise, un statut et les références utiles.

Ce contrat commun permet à l’interface de rester stable lorsqu’un connecteur évolue. Il donne aussi un critère clair pour intégrer un nouveau canal : produire les mêmes faits métier et les mêmes erreurs contrôlées.

8. Mettre à jour les données qui décrivent vraiment l’offre

Stock, prix, statut et métadonnées avec une responsabilité claire

Le prix TTC reçu est conservé dans sa devise source. Ciama calcule également sa valeur convertie en euros afin que les analyses transverses disposent d’une base comparable. Le statut actif est mis à jour à partir de la réponse du canal.

Lorsque la marketplace renvoie un identifiant produit ou une image exploitable, ces informations peuvent enrichir l’offre. Une valeur d’image vide n’écrase pas la représentation existante. Le rafraîchissement reste attentif à la différence entre absence de donnée et donnée explicitement nouvelle.

La date d’offre renvoyée par le canal contribue au dernier repère de collecte du canal lorsqu’elle est plus récente. Une réponse ancienne ne fait pas reculer artificiellement ce curseur.

Cette mise à jour spécialisée évite les effets de bord d’un traitement plus large. Elle ne recrée pas le produit, ne remappe pas tout le catalogue et n’exécute pas des règles sans rapport avec la question posée.

9. Ne pas écraser le stock quand la plateforme gère le fulfilment

Le même champ externe n’a pas toujours la même responsabilité métier

Pour une offre expédiée par le vendeur, la quantité renvoyée par la marketplace décrit bien le stock vendeur publié. Ciama peut donc l’utiliser pour actualiser l’offre locale et comparer ensuite cette valeur à la quantité cible du Stock Dispatcher.

Pour une offre gérée par la plateforme, la situation change. Le stock externe relève du réseau logistique du canal et la réponse peut ne pas fournir la même quantité exploitable. Le rafraîchissement conserve alors le stock local existant au lieu de le remplacer par zéro ou par une valeur ambiguë.

Les connecteurs Amazon, Cdiscount et Mirakl adaptent eux aussi leurs exigences selon ce contexte. La quantité est obligatoire lorsqu’elle doit réellement mettre à jour un stock vendeur ; elle ne provoque pas le même échec lorsque le fulfilment appartient à la plateforme.

Cet arbitrage montre pourquoi une intégration fiable ne peut pas se limiter à copier des champs. La signification métier décide si une valeur externe doit être appliquée, conservée ou considérée comme insuffisante.

10. Conserver le prix source et produire une lecture comparable

Convertir à la date utile sans perdre la devise marketplace

Le connecteur renvoie le prix TTC et le code de devise exposés par le canal. Si la devise manque, le contrat utilise l’euro comme valeur par défaut prévue. Si une devise annoncée n’existe pas dans les référentiels de Ciama, la mise à jour s’arrête avec une erreur explicite.

Lorsque la devise est connue, le moteur convertit le montant vers l’euro à la date d’offre déterminée par la marketplace. Cette date vient de la dernière mise à jour, de la création ou, en dernier recours, du moment du rafraîchissement.

Ciama conserve ainsi le prix source et le montant converti avec leurs devises respectives. Une analyse multi-pays peut comparer les offres sans effacer ce que le canal a réellement renvoyé.

Le projet ne prétend pas optimiser automatiquement ce prix. Il garantit que les outils de pilotage et d’optimisation des offres travaillent à partir d’une lecture récente et correctement qualifiée.

11. Trois usages, un seul service de rafraîchissement

Liste d’offres, Stock Dispatcher et contrôle après écriture

Dans la liste des offres marketplace, une colonne dédiée permet de rafraîchir une ligne. L’utilisateur confirme l’action, reçoit un succès ou une erreur lisible, puis la page recharge les valeurs de stock, de prix, de statut et de mise à jour.

Le Stock Dispatcher propose la même capacité sans quitter son contexte. La ligne de l’offre est remplacée après succès afin que la quantité marketplace et la cible Ciama puissent être comparées immédiatement.

Après un envoi de stock, le service devient aussi le contrôle de retour. Le parcours manuel peut attendre puis relire l’offre dans la même action ; le parcours automatique confie cette relecture à une file et rattache son résultat à la tentative d’envoi.

Cette réutilisation relie naturellement le projet à l’historique vérifiable des envois de stock. La fiche 077 raconte la preuve complète ; celle-ci explique le moteur de lecture qui permet de confirmer la seconde étape.

12. Tester les règles avant de multiplier les points d’entrée

Domaine, connecteurs, persistance et interface sous contrôle

Les tests du domaine couvrent les demandes invalides, l’isolation du compte, les canaux incorrects, les fournisseurs indisponibles, les erreurs de devise, la conversion du prix et l’arbitrage de stock selon le fulfilment. Ils vérifient aussi qu’une réponse correcte produit la mise à jour attendue.

Chaque famille de connecteurs dispose de scénarios propres à son protocole et à ses formats. Les cas de données manquantes sont aussi importants que le chemin nominal : une quantité absente sur une offre vendeur ou un prix illisible doivent arrêter la réconciliation plutôt que sauvegarder une valeur trompeuse.

Les tests d’intégration contrôlent la mise à jour persistée, tandis que les tests du contrôleur protègent la sécurité de l’action et la forme de la réponse. Le service peut ensuite être réutilisé par le Stock Dispatcher sans reconstruire cette couverture ailleurs.

La livraison en deux incréments successifs a d’abord établi le parcours, puis généralisé son autonomie et ses connecteurs. Les évolutions ultérieures du stock ont pu s’appuyer sur cette base déjà testée au lieu de créer une nouvelle lecture marketplace.

13. Ce que Ciama gagne après la livraison

Une donnée fraîche à l’endroit exact où la décision se prend

L’équipe ne relance plus une collecte complète pour lever un doute sur une seule référence. Elle reste dans le cockpit, cible l’offre et obtient la lecture de la marketplace concernée. Les autres offres et leurs traitements ne sont pas perturbés.

Le diagnostic gagne en précision. Une erreur de connexion, une donnée obligatoire absente, un canal non pris en charge ou une devise inconnue produisent des issues distinctes dans le domaine. Le produit peut afficher un message maîtrisé et le support sait quel niveau examiner.

Le contrôle après écriture devient réutilisable. Le Stock Dispatcher ne se contente pas d’envoyer une quantité : il appelle le même mécanisme que l’utilisateur emploie pour relire l’offre. La valeur affichée après l’action provient donc du canal, pas d’une simple hypothèse locale.

Enfin, l’ajout d’une future marketplace suit un cadre stable. Le nouveau connecteur doit retrouver une offre précise, produire le contrat commun et respecter les règles de données manquantes. Cette discipline limite la multiplication de comportements invisibles à mesure que le périmètre grandit.

14. Le scénario qui rend la différence visible

Vérifier une offre sans attendre ni surcharger le portefeuille

Une responsable marketplace vient de corriger un stock sur une offre Cultura. Le canal a accepté l’import, mais la quantité visible dans Ciama n’a pas encore changé. Au lieu de relancer toutes les offres Mirakl, elle demande le rafraîchissement de cette référence.

Le connecteur interroge l’instance Cultura, retrouve l’offre par son SKU vendeur et extrait quantité, prix, devise et statut. Ciama vérifie le compte, normalise la réponse et met à jour la ligne. Si la quantité manque alors que le vendeur assure l’expédition, l’action échoue sans remplacer le stock par zéro.

Le même geste sur une offre Amazon cible le pays exact et tient compte du mode de fulfilment. Sur Cdiscount, le connecteur utilise la référence vendeur et le canal de vente attendu. L’interface reste identique même lorsque l’échange externe change complètement.

La transformation tient dans ce contraste : auparavant, vérifier une offre demandait de choisir entre attente, collecte large et contrôle externe manuel. Après le projet, Ciama dispose d’une lecture unitaire sûre qui peut servir aussi bien l’exploitation humaine que le contrôle d’un processus automatisé.

15. Replacer le rafraîchissement dans le run vendeur

Une brique de contrôle entre connexion, offre et supervision

Les connecteurs marketplace et ERP portent la fiabilité de la lecture. La supervision du run marketplace organise ensuite la façon de détecter, qualifier et reprendre les écarts.

Dans Ciama Marketplace, cette capacité relie les deux : une action très ciblée qui retourne à la source et remet l’offre locale dans un état exploitable, sans masquer les limites du canal.