Ciama : rendre chaque envoi de stock marketplace vérifiable

1. Ciama, un cockpit conçu pour les opérations vendeurs

Le produit Dawap qui relie décisions métier et APIs marketplace

Ciama Marketplace est développé par Dawap pour réunir les offres, les commandes, le catalogue, le stock, la concurrence et la rentabilité d’un vendeur multicanal. Son rôle n’est pas seulement de consolider des données : il doit aider une équipe à décider puis à exécuter cette décision sans perdre sa trace.

Le Stock Dispatcher rapproche le stock disponible dans les entrepôts liés à une offre et la quantité que Ciama recommande de diffuser. L’utilisateur peut envoyer cette valeur manuellement ; le mode automatique peut aussi déclencher un envoi lorsqu’une mise à jour de stock change la quantité cible d’une offre expédiée par le vendeur.

Cette double origine rend l’historique indispensable. Une correction humaine et une règle automatique n’ont pas le même contexte, mais elles doivent produire la même qualité de preuve : une offre identifiée, un canal connu, une valeur envoyée et un résultat que l’exploitation peut relire.

2. Construire la preuve autour du parcours réel

Enregistrer, envoyer, relire puis rendre le résultat exploitable

Le chantier a été livré par étapes courtes en avril 2026. La première a séparé la sauvegarde de la configuration et l’envoi effectif du stock. Cette distinction évite qu’une modification de parcelle ou de règle soit confondue avec une diffusion vers le canal.

La deuxième étape a créé un point d’entrée unique pour les envois manuels et automatiques. La tentative est enregistrée avant l’appel externe, passe de l’état en attente au succès ou à l’échec, puis reçoit séparément le résultat du rafraîchissement de l’offre. Les deux modes suivent ainsi le même contrat de contrôle.

La troisième étape a rendu ces traces utilisables : historique attaché à l’offre, journal global, filtres, réponse du fournisseur et détail des erreurs. Des tests unitaires, d’intégration et de contrôleur protègent le comportement, tandis qu’une purge planifiée maintient une fenêtre opérationnelle d’un mois.

3. Avant l’historique : une réponse partielle à une question complète

« L’appel a réussi » ne veut pas encore dire « le stock est à jour »

Le stock marketplace met en jeu plusieurs valeurs. Le stock disponible vient des entrepôts liés à l’offre. Ciama en déduit une quantité cible. La marketplace conserve de son côté la quantité publiée. Ces trois nombres peuvent être légitimement différents pendant un traitement, mais l’équipe doit pouvoir expliquer pourquoi.

Sans trace métier, l’investigation commence trop tard. Il faut retrouver l’offre, reconstituer la valeur attendue, chercher l’appel concerné et interpréter des journaux techniques. Si une automatisation et une action manuelle se sont succédé, leur ordre devient lui-même une hypothèse.

La difficulté est plus forte lorsque le canal accepte l’envoi puis tarde à refléter le changement. Un simple statut « succès » masque alors la moitié du parcours. À l’inverse, relancer sans comprendre peut produire une nouvelle tentative et rendre le diagnostic encore moins lisible.

Le projet a donc refusé de réduire la traçabilité à une ligne de log. La preuve devait suivre l’objet métier — l’offre — et raconter chaque transition utile à la personne qui exploite le canal.

4. Un objectif : répondre sans reconstruire le scénario

Donner à l’exploitation les faits nécessaires au premier regard

Pour chaque tentative, l’équipe devait retrouver la date, l’offre, le canal, le fournisseur technique, la quantité demandée, le mode manuel ou automatique et l’origine exacte du déclenchement. Ces informations posent immédiatement le périmètre de l’action.

Le résultat devait ensuite rester décomposé. Le statut du push indique si le connecteur a accepté l’envoi. Le statut de rafraîchissement indique si Ciama a pu relire l’offre après cette étape. La réponse du canal, son identifiant de traitement ou son erreur complètent le diagnostic.

Enfin, cette mémoire devait servir deux lectures. Depuis une offre, elle répond à une anomalie précise. Depuis le journal global, elle permet de filtrer les échecs, de repérer un canal concerné ou de contrôler les actions automatiques récentes.

Le périmètre reste volontairement net : la fiche traite l’historique des envois de stock vers les marketplaces. Les mouvements physiques d’entrepôt disposent d’autres mécanismes et ne sont pas présentés ici comme la même chose.

5. Une tentative devient un objet métier à part entière

Conserver le contexte avant même de contacter la marketplace

Ciama crée la tentative avant l’appel au connecteur. Elle reçoit un identifiant propre et conserve le compte, l’offre, le canal, le fournisseur, l’utilisateur éventuel, la quantité demandée, le mode et la source. Même si l’appel échoue brutalement, le fait qu’il ait été tenté ne disparaît pas.

L’état commence à « en attente », puis devient « succès » ou « échec ». En cas de succès, le connecteur peut fournir un identifiant de lot et un extrait de réponse. En cas d’échec, le code et le message restent attachés à la même tentative au lieu d’être perdus dans un flux de logs général.

Le contexte conserve aussi les identifiants nécessaires pour comprendre l’échange : catalogue du canal, identifiant vendeur et référence de l’offre. Cette précision évite de confondre deux offres proches ou deux boutiques d’une même enseigne.

Ce choix structurel est important : la traçabilité n’est pas ajoutée après coup à l’interface. Elle fait partie du service qui envoie réellement le stock et couvre donc les différents points d’entrée.

6. Valider le contexte avant de pousser une quantité

Bloquer tôt ce qui ne peut pas produire un envoi fiable

Le service vérifie d’abord l’offre et refuse une quantité négative. Il contrôle ensuite que l’offre est expédiée par le vendeur, qu’elle appartient à un canal marketplace et qu’elle est reliée à un produit. Une offre gérée en fulfilment par la plateforme ne doit pas emprunter le même chemin.

Le canal doit disposer d’un fournisseur actif, d’un catalogue identifié et des informations de connexion nécessaires. Certains connecteurs exigent aussi un identifiant vendeur. Ces contrôles empêchent de créer un faux succès à partir d’un contexte incomplet.

Une fois ce cadre validé, Ciama enregistre la tentative puis délègue l’appel au connecteur adapté. Le résultat revient sous une forme commune, même si les protocoles de Fnac/Darty, Amazon ou Mirakl diffèrent.

Ce parcours illustre la valeur d’une intégration entre marketplaces et système vendeur : la complexité propre à chaque canal reste dans le connecteur, tandis que l’équipe retrouve une lecture opérationnelle cohérente.

7. Séparer l’acceptation du push et la valeur réellement relue

Deux statuts pour ne jamais annoncer un succès trop tôt

Après un push accepté, Ciama demande un rafraîchissement de l’offre. Cette deuxième étape relit le stock exposé par la marketplace et met à jour l’offre locale. Selon le parcours, elle peut être exécutée immédiatement ou confiée à un traitement asynchrone.

L’historique indique si ce rafraîchissement n’a pas été demandé, s’il est encore en attente, s’il a réussi ou s’il a échoué. Une tentative n’est affichée comme complète que lorsque le push et la relecture sont tous les deux en succès.

Cette séparation change le diagnostic. Un push refusé oriente vers les données d’accès, le format ou la règle du connecteur. Un push accepté suivi d’un rafraîchissement en échec oriente vers la lecture de l’offre. Deux incidents visuellement proches appellent ainsi deux réponses différentes.

L’équipe peut également comparer le stock actuellement connu, la cible calculée et la quantité effectivement demandée. L’écart cesse d’être une impression : il devient une suite de valeurs datées.

8. Faire passer le manuel et l’automatique par la même porte

Une règle commune de validation, d’envoi et de preuve

Depuis le Stock Dispatcher, un utilisateur peut confirmer un envoi manuel. La tentative conserve alors son identité et l’utilisateur qui l’a déclenchée. L’interface présente séparément le push et le rafraîchissement, puis recharge la ligne lorsque le parcours complet a abouti.

En mode automatique, une mise à jour de stock recalcule la quantité cible des offres concernées. Si le mode est actif et que la valeur publiée diffère de cette cible, Ciama déclenche un message dédié. La source automatique est enregistrée sans fabriquer un utilisateur humain.

Les deux chemins réutilisent le même service d’envoi. Cet arbitrage élimine une ancienne voie parallèle qui aurait pu évoluer différemment. Une correction du contrôle fournisseur ou de la traçabilité protège donc à la fois l’action manuelle et l’automatisation.

Le bénéfice dépasse la maintenance technique : lorsqu’une équipe consulte l’historique, les colonnes, les statuts et la logique de complétude restent identiques quelle que soit l’origine de la décision.

9. Deux vues pour deux moments d’exploitation

Comprendre une offre ou surveiller l’ensemble du compte

La première vue s’ouvre depuis une offre. Elle affiche ses tentatives récentes dans l’ordre inversement chronologique. Ce raccourci répond à la question la plus urgente : que s’est-il passé sur cette référence et cette marketplace ?

La seconde vue rassemble les journaux du compte. Une recherche textuelle retrouve une offre, une source, un fournisseur, un lot ou un utilisateur. Des filtres isolent le canal, le mode, le statut du push et celui du rafraîchissement.

Chaque ligne montre la date, l’offre, le canal, la source, les deux statuts, le stock marketplace connu, la cible, la quantité poussée, le fournisseur, le lot, l’utilisateur et le retour de l’API. L’information nécessaire au triage tient dans une seule lecture.

Les traces sont classées par date puis par identifiant pour garder un ordre stable. Une purge quotidienne retire celles qui dépassent un mois : le journal reste un outil de run récent, pas une archive illimitée qui deviendrait lente et difficile à parcourir.

10. Un historique commun malgré des APIs différentes

Fnac/Darty, Amazon Europe et Mirakl derrière le même contrat

Fnac/Darty utilise son dialogue d’offres, Amazon Europe met à jour la disponibilité du listing pour le pays exact et Mirakl transmet un import de stock associé à l’offre. Les formats, identifiants et réponses diffèrent, mais la tentative exposée à l’utilisateur conserve la même structure.

Le connecteur Mirakl couvre notamment Cultura et accepte une adresse propre à un futur canal compatible. Amazon vérifie l’identifiant vendeur, le SKU et le marché visé. Fnac/Darty renvoie son résultat dans le même objet de réponse métier.

Lorsqu’un canal n’est pas encore pris en charge pour l’écriture du stock, Ciama échoue explicitement au lieu de simuler un envoi. Cette limite est préférable à un bouton qui semblerait fonctionner sans modifier la marketplace.

Les réponses de limitation de débit sont traitées avec des reprises progressives sur le parcours concerné. Si les tentatives sont épuisées, l’erreur reste visible dans l’historique et peut être distinguée d’une mauvaise donnée d’offre.

11. Sécuriser le parcours avant et après la livraison

Tests ciblés, traitements asynchrones et entretien des données

Les règles du service sont couvertes au niveau unitaire : demande incomplète, quantité invalide, offre absente, canal incorrect, fournisseur indisponible, succès du push, échec et déclenchement du rafraîchissement. Les doubles de connecteurs permettent de vérifier la chronologie sans appeler une marketplace réelle à chaque test.

Les contrôles d’intégration vérifient la persistance de la tentative et le passage entre les couches métier et infrastructure. Les tests applicatifs couvrent les écrans du Stock Dispatcher, notamment l’accès au journal et l’historique d’une offre.

Les envois automatiques et les rafraîchissements différés utilisent des files dédiées. Une indisponibilité temporaire du canal ne bloque donc pas tout l’écran de pilotage, tandis que l’état de la tentative reste disponible pour la reprise.

La commande de purge est enregistrée dans la planification de production et possède ses propres contrôles. Ce détail protège la valeur du journal dans le temps : conserver assez d’information pour diagnostiquer, sans laisser une table opérationnelle croître sans limite.

12. Ce que le produit gagne après la mise en ligne

Une automatisation explicable plutôt qu’un enchaînement opaque

Une personne qui constate un écart ne repart plus d’une recherche technique générale. Elle ouvre l’offre, vérifie la dernière quantité demandée et voit immédiatement si le problème se situe avant l’appel, pendant le push ou lors de la relecture.

Les actions manuelles ne sont plus confondues avec les décisions automatiques. L’utilisateur, la source et le mode donnent le contexte nécessaire pour expliquer une correction, confirmer une règle normale ou repérer une succession d’envois inattendue.

Le support dispose d’éléments utiles pour qualifier un incident : canal, référence, heure, statut, lot fournisseur et message d’erreur. Cette base réduit les échanges exploratoires et aide à adresser le problème au bon niveau.

Enfin, l’automatisation devient plus sûre à étendre. Un nouveau connecteur doit produire le même résultat métier et laisser la même preuve. La croissance du périmètre marketplace ne se paie donc pas par autant de méthodes de diagnostic différentes.

13. Le scénario qui résume la transformation

D’un écart inexpliqué à une décision de reprise précise

Une offre affiche moins de stock que la quantité recommandée par Ciama. L’équipe ouvre son historique et voit qu’une tentative automatique a bien été créée. Le push est en succès, mais la relecture de l’offre a échoué : la règle de calcul n’est donc pas la première suspecte.

Le message associé permet de qualifier le problème côté lecture du canal. L’équipe peut attendre une reprise, rafraîchir l’offre ou corriger la connexion selon la cause, sans renvoyer immédiatement une quantité qui a peut-être déjà été acceptée.

Dans un autre cas, le push lui-même est en échec. Le journal montre le canal, l’identifiant concerné et la réponse reçue. L’incident est traité au niveau du connecteur, tandis que les autres offres continuent leur parcours.

C’est cette précision qui donne sa valeur au projet : Ciama ne promet pas que toutes les APIs répondront toujours. Il donne à l’équipe les moyens de savoir ce qui a été tenté, ce qui est confirmé et ce qui demande encore une action.

14. Relier la trace aux autres décisions de stock

Du calcul de la cible à la supervision du run

Le projet Stock Dispatcher marketplace explique comment les entrepôts liés à une offre alimentent la quantité cible. La présente fiche commence exactement au moment où cette décision doit quitter Ciama.

Le rafraîchissement autonome des offres approfondit la seconde moitié du parcours : relire prix, stock, statut et date de mise à jour sans relancer une collecte globale.

La page supervision du run marketplace replace enfin cette trace dans une organisation plus large : détecter, qualifier, reprendre et vérifier les traitements qui comptent pour le vendeur.