Le projet en un coup d’œil
Une même référence peut exister dans plusieurs entrepôts, alors qu’une offre marketplace ne doit suivre que les sources choisies pour elle.
Ciama additionne les disponibilités sélectionnées, utilise l’entrepôt par défaut en l’absence de configuration et garde la cible face au stock publié.
L’équipe choisit ses sources, envoie une valeur ponctuelle ou active l’automatisation offre par offre sans modifier silencieusement sa configuration.
Pour un vendeur marketplace, la question n’est pas seulement « combien d’unités avons-nous ? ». Elle devient « quelles unités cette offre précise a-t-elle le droit de diffuser ? ». Une référence peut être présente dans plusieurs entrepôts, portée par plusieurs offres et expédiée selon des organisations différentes. Copier le stock total du produit vers chaque canal ferait perdre cette distinction essentielle.
Ciama possédait déjà les offres marketplace, les produits et les stocks par entrepôt. Le chantier Stock Dispatcher devait les relier au niveau où la décision devient exploitable : une offre expédiée par le vendeur, ses parcelles de stock autorisées, une quantité cible calculée et la quantité actuellement connue sur la marketplace. L’enjeu n’était pas d’inventer une allocation commerciale opaque, mais de rendre la source de chaque nombre lisible.
Dawap a conçu cette brique d’automatisation des commandes et des stocks marketplace comme un cockpit d’action. L’équipe peut filtrer son portefeuille, relier les bons stocks, vérifier la cible, envoyer une valeur ponctuelle et activer l’automatisation uniquement sur les offres qui doivent suivre leurs sources logistiques.
1. Ciama, le produit Dawap dédié aux opérations vendeurs
Réunir la donnée marketplace et la réalité logistique dans une même décision
Ciama Marketplace est développé par Dawap pour réunir les offres, les commandes, le catalogue, les stocks, la concurrence et la rentabilité d’un vendeur multicanal. Cette vision consolidée ne suffit pourtant pas si l’utilisateur ne peut pas agir sur l’offre au bon niveau de précision.
Une offre contient la quantité relue sur son canal. Le produit peut, lui, disposer de plusieurs lignes de stock, chacune associée à un entrepôt et à une référence logistique. Entre les deux, il manquait une règle explicite pour dire quelles lignes alimentent la quantité recommandée de cette offre.
Le Stock Dispatcher répond à ce besoin sans faire croire qu’un stock unique convient partout. Il travaille uniquement sur les offres marketplace actives et expédiées par le vendeur. Les offres dont le fulfilment est porté par la plateforme restent en dehors de ce parcours, car leur disponibilité obéit à un autre fonctionnement.
Cette frontière transforme le module en preuve de conception métier. La logique ne part pas d’un bouton générique « synchroniser tous les stocks » ; elle part du couple offre-produit, de ses sources d’entrepôt et du canal sur lequel la quantité devra réellement être envoyée.
2. Faire émerger la bonne règle avant d’automatiser
Séparer configuration, calcul, envoi et contrôle du résultat
Le premier périmètre livré le 15 avril 2026 a posé la vue opérationnelle et la configuration par offre. Le 21 avril, Dawap a séparé la sauvegarde des parcelles de l’envoi manuel. Enregistrer les sources d’une cible ne devait plus déclencher implicitement un appel externe : une configuration et une diffusion sont deux décisions différentes.
Le 26 avril, le parcours a été consolidé autour d’un service unique pour les envois manuels et automatiques, de connecteurs marketplace explicites, d’un recalcul après variation des stocks et de contrôles plus précis dans l’interface. La date publique correspond à cette livraison cohérente de bout en bout.
La méthode a consisté à protéger chaque transition. Les stocks sélectionnés doivent appartenir au même compte et au produit de l’offre. Une quantité envoyée doit être un entier positif ou nul. L’offre, le canal, le fournisseur technique, ses identifiants et ses accès sont vérifiés avant l’appel à la marketplace.
Enfin, le travail a traité l’après-envoi dès la conception. Le module demande une nouvelle lecture de l’offre lorsque le push a réussi et affiche distinctement le résultat de ces deux étapes. Cette progression évite un faux sentiment de réussite fondé sur le seul départ d’une requête.
3. Avant le Dispatcher : trois stocks sans règle de rapprochement
Le disponible logistique, la cible souhaitée et la valeur du canal racontaient des réalités différentes
Le stock d’un produit peut être réparti sur plusieurs entrepôts. Certaines unités sont destinées à une activité précise, certaines lignes utilisent une référence logistique propre et tous les lieux de stockage ne doivent pas nécessairement alimenter toutes les offres. Additionner aveuglément l’ensemble créerait une cible faussement généreuse.
De son côté, l’offre marketplace conserve la dernière quantité connue sur le canal. Cette valeur peut différer du disponible interne pendant un traitement, après une vente, à la suite d’une actualisation d’entrepôt ou parce que l’offre n’a pas encore été rafraîchie. L’écart n’est pas toujours une erreur, mais il doit être visible pour devenir compréhensible.
Il existait enfin une décision intermédiaire : la quantité que Ciama recommande de diffuser. Sans modèle dédié, cette cible risquait d’être confondue avec le stock global du produit ou avec une saisie manuelle isolée. L’équipe ne pouvait pas répondre simplement à la question « de quelles parcelles vient ce nombre ? ».
Le problème du projet tenait donc moins à la circulation d’un entier qu’à sa filiation. Pour automatiser utilement, Ciama devait conserver le lien entre une offre et ses sources, recalculer la cible lorsque ces sources changent, puis distinguer ce calcul d’un envoi ponctuel volontaire.
4. Donner une règle de disponibilité propre à chaque offre
Choisir les sources autorisées avant de choisir la façon d’envoyer
Le premier objectif était de permettre à l’équipe de sélectionner, parmi les stocks du produit, ceux qui doivent alimenter une offre donnée. Deux offres du même produit peuvent ainsi suivre des ensembles différents si leur organisation logistique le nécessite.
Le deuxième objectif était de rendre le calcul immédiat et prévisible. La quantité cible correspond à la somme des disponibilités liées, avec chaque valeur négative neutralisée lors des recalculs. En l’absence de sélection enregistrée, le stock de l’entrepôt par défaut sert de règle de repli.
Le troisième objectif consistait à rapprocher, dans la même ligne, le stock connu sur la marketplace et la cible calculée par Ciama. L’utilisateur devait pouvoir repérer un écart sans ouvrir successivement la fiche produit, les stocks d’entrepôt et l’offre.
Le dernier objectif était de garder deux niveaux de contrôle : un envoi manuel qui ne change pas la configuration, et un mode automatique activable offre par offre ou sur un ensemble filtré. La commodité d’une action massive ne devait pas effacer la précision de la règle.
5. Transformer un portefeuille d’offres en file de décisions
Afficher d’abord les références sur lesquelles l’action a un sens
L’écran charge uniquement les offres actives de type marketplace qui sont expédiées par le vendeur. Il présente vingt-cinq lignes par page et les trie par défaut selon la quantité vendue sur quatre-vingt-dix jours, de la plus forte à la plus faible. Les références les plus actives arrivent ainsi en premier sans prétendre calculer une priorité économique.
Chaque ligne rassemble le canal, le produit, le mode de fulfilment, l’état de l’offre, son stock marketplace, sa cible Ciama, son prix converti, ses ventes récentes, sa date de mise à jour et l’état du mode automatique. Le rapprochement évite de décider à partir d’une valeur de stock isolée de son contexte.
La recherche peut être affinée par texte, présence de stock, canal, marque, catégorie de premier niveau, tag, état de synchronisation et mode automatique. Les choix de canal, de marque, de catégorie et de tag qui ne produisent aucun résultat dans le périmètre courant sont masqués pour limiter les filtres sans issue.
Les actions groupées activent ou désactivent le mode automatique pour tous les identifiants correspondant à la recherche courante. Le libellé « tous » ne désigne donc pas seulement les vingt-cinq lignes visibles : il suit le périmètre réellement filtré, ce qui rend l’action cohérente avec la sélection préparée par l’utilisateur.
6. Relier l’offre à ses parcelles de stock
Faire de la source logistique une configuration visible et modifiable
La fenêtre de réglage part de l’offre. Elle affiche son image, le logo du canal, son identifiant, le produit, la marque, la catégorie et les tags disponibles. Ces repères réduisent le risque de configurer une référence voisine lorsqu’un catalogue contient de nombreux intitulés proches.
La première colonne liste jusqu’à deux cent cinquante stocks du produit avec leur entrepôt, leur FnSku, leur date de mise à jour et leur quantité disponible. Un bouton indique pour chaque ligne si elle est liée ou non à l’offre. La sélection est donc explicite et repose sur des objets logistiques identifiables.
Lors de l’enregistrement, Ciama refuse une sélection vide et contrôle que chaque stock appartient au compte et au produit de l’offre. Les liens retirés sont supprimés, les nouveaux sont créés et les liens conservés sont actualisés. La configuration reste alignée sur la sélection affichée, sans doublon silencieux.
Une seconde vue agrège les lignes liées par entrepôt. Elle permet de comprendre comment plusieurs parcelles contribuent au total sans perdre leur origine. Ce détail est particulièrement utile lorsqu’un même produit possède plusieurs FnSku ou plusieurs lignes dans un même lieu de stockage.
7. Calculer une cible simple, explicable et recalculable
Une somme de sources choisies, avec une règle de repli maîtrisée
Dès que des parcelles sont configurées, la cible est la somme de leurs quantités disponibles. La valeur est enregistrée à la fois sur la configuration du Dispatcher et sur l’offre afin d’être disponible dans les parcours opérationnels sans reconstruire le calcul à chaque affichage.
Si aucune sélection explicite n’existe encore, Ciama recherche les stocks du produit dans l’entrepôt marqué par défaut. La fenêtre les considère comme implicitement liés et présente leur somme comme cible. Cette règle permet à une nouvelle offre de démarrer avec une source déterministe tout en laissant l’équipe personnaliser ensuite son périmètre.
Le calcul ne tient pas compte de la marge, du classement commercial du canal, des ventes futures ou d’un stock fournisseur supposé. Ce choix est volontaire : la cible traduit une disponibilité logistique autorisée. Les décisions de prix, de rentabilité ou de réassort disposent de leurs propres outils et ne sont pas maquillées en règle de stock.
Lorsqu’une ligne de stock est mise à jour, Ciama recherche les offres impactées. Une offre est concernée si elle utilise explicitement cette parcelle ou, en l’absence de configuration, si la variation touche l’entrepôt par défaut. Sa cible est alors recalculée avec la même règle, ce qui évite une valeur figée après le paramétrage initial.
Référence commune entre l’offre et ses stocks
Sources sélectionnées ou entrepôt par défaut
Somme enregistrée comme recommandation Ciama
Valeur manuelle ou déclenchement automatique
Stock du canal actualisé après le push
8. Autoriser une correction manuelle sans dérégler la règle
Envoyer une valeur ponctuelle tout en préservant les parcelles configurées
L’utilisateur peut ouvrir un envoi manuel directement depuis la colonne du stock marketplace ou depuis les réglages de l’offre. La fenêtre rappelle le stock actuellement connu, la cible recommandée et le canal concerné avant de demander confirmation.
La quantité saisie doit être un entier positif ou nul. Zéro est un cas valide : il permet de couper la disponibilité d’une offre lorsque la situation opérationnelle l’exige. Une valeur négative ou un texte est refusé avant tout contact avec la marketplace.
Cet envoi ponctuel ne remplace pas la sélection des parcelles et ne modifie pas la cible enregistrée. C’est un arbitrage essentiel. Une équipe peut corriger immédiatement le canal, par exemple pendant une vérification physique, sans transformer cette exception en nouvelle règle pour les prochains recalculs.
Le parcours manuel exécute le push puis la relecture de l’offre dans la même action. L’interface affiche deux étapes distinctes — envoi du stock et rafraîchissement — et ne remplace la ligne qu’après un parcours complet. Si le canal accepte le stock mais que la relecture échoue, le message ne prétend pas que tout est terminé.
9. Déclencher l’automatisation sur un changement réel de source
Ne pousser que si le mode est actif et que la cible diffère du canal
Le mode automatique est piloté au niveau de l’offre. Un bouton permet de l’activer ou de le couper ; une action groupée applique le même choix à toutes les offres correspondant aux filtres courants. L’état est conservé dans la configuration du Dispatcher et reflété sur l’offre pour rester cohérent dans les recherches.
L’activation seule n’envoie pas arbitrairement une quantité. Le déclenchement intervient lorsqu’une écriture de stock recalcule la cible d’une offre concernée. Ciama compare alors la quantité marketplace connue et la nouvelle cible. Si elles diffèrent et si le mode Auto est actif, un message d’envoi est placé dans une file dédiée.
Le traitement asynchrone réutilise exactement le même service métier que l’action manuelle. Il vérifie l’offre et le canal, appelle le connecteur compatible, conserve la tentative puis demande une relecture de l’offre. Le mode change l’origine et le rythme de l’action, pas ses règles de sécurité.
Cette mécanique évite les appels inutiles lorsque le stock connu est déjà égal à la cible. Elle évite aussi un planificateur global qui republierait périodiquement toutes les offres sans événement métier. L’automatisation reste attachée à une variation de stock identifiée et aux offres réellement impactées par cette variation.
10. Pousser la même décision dans des APIs différentes
Amazon, Fnac/Darty et Mirakl derrière une réponse métier commune
Sur Amazon Europe, Ciama associe le canal à son identifiant de marketplace, vérifie l’identifiant vendeur et le SKU, puis modifie la quantité de disponibilité du listing. Le connecteur couvre les marchés européens configurés et plusieurs extensions internationales, chacune avec son identifiant exact plutôt qu’un envoi générique.
Pour Fnac/Darty, le parcours s’authentifie avec les informations de la boutique, construit une mise à jour d’offre par SellerSku et récupère l’identifiant de lot retourné. Pour Mirakl, notamment Cultura, il transmet un fichier de stock unitaire et conserve l’identifiant d’import reçu en réponse.
Ces protocoles n’ont ni le même format ni les mêmes réponses. Le service de Ciama les ramène pourtant au même résultat opérationnel : un envoi accepté avec une référence fournisseur, ou un échec explicite avec sa cause. L’écran n’a pas besoin de réinventer une logique pour chaque enseigne.
Un canal dont l’écriture de stock n’est pas implémentée échoue clairement. Cdiscount, par exemple, dispose d’une relecture d’offre mais pas encore d’un push de stock fonctionnel dans ce parcours. Cette asymétrie est affichée dans la documentation du module au lieu de laisser croire qu’un bouton disponible garantit une écriture externe.
11. Relire l’offre après l’envoi
Comparer une requête acceptée avec la valeur réellement renvoyée par le canal
Une marketplace peut accepter une requête avant que la nouvelle quantité soit visible dans sa réponse de lecture. C’est pourquoi le Stock Dispatcher ne s’arrête pas au statut HTTP du push. Après un succès, il demande un rafraîchissement de l’offre par le connecteur de lecture compatible.
Le rafraîchissement met à jour le stock, mais aussi les autres données que le canal renvoie pour l’offre, comme son prix ou son état selon l’intégration. La ligne présentée dans le Dispatcher reflète ainsi la réponse récente de la source externe et pas seulement la quantité que Ciama vient de demander.
Le parcours automatique confie cette relecture à un traitement asynchrone, tandis que l’action manuelle attend son résultat pour informer immédiatement l’utilisateur. Cette différence répond au contexte : préserver la fluidité d’un flux de fond d’un côté, donner une confirmation directement exploitable après un geste humain de l’autre.
L’historique des envois de stock conserve séparément le résultat du push et celui de cette relecture. Le présent projet décide et exécute la quantité ; le projet voisin approfondit la preuve laissée par chaque tentative.
12. Les arbitrages qui rendent le module fiable
Préférer des règles modestes et vérifiables à une intelligence métier inventée
Le premier arbitrage consiste à calculer la cible par offre, même lorsque plusieurs offres pointent vers le même produit. Cette granularité demande davantage de configuration, mais elle respecte la réalité des canaux et permet des sources d’entrepôt différentes.
Le deuxième sépare strictement la configuration et l’envoi. Sauvegarder un lien de stock met à jour la cible, mais ne pousse pas silencieusement la marketplace. À l’inverse, une saisie manuelle pousse une quantité sans réécrire les liens. Chaque bouton garde une conséquence prévisible.
Le troisième conserve une règle par défaut plutôt que d’exiger une configuration exhaustive dès le premier jour. L’entrepôt par défaut alimente la cible tant qu’aucune parcelle n’a été choisie. La migration vers une sélection plus fine peut ainsi se faire offre par offre sans laisser les nouvelles références sans source.
Le quatrième refuse de présenter la cible comme une optimisation par marge, vitesse de vente ou priorité commerciale. Ces données apparaissent dans le cockpit pour éclairer l’utilisateur, mais elles n’entrent pas dans la somme. La transparence de la règle vaut ici davantage qu’une promesse d’optimisation non portée par le produit.
13. Sécuriser le parcours à plusieurs niveaux
Contrôler les règles de calcul, les accès et les effets externes
Les règles de recalcul sont isolées du contrôleur. Les cas avec parcelles configurées, entrepôt par défaut, absence de stock, quantité négative neutralisée, mode automatique actif et stock déjà aligné peuvent être vérifiés sans dépendre de l’interface.
Le parcours d’envoi protège ensuite les frontières du compte. L’offre doit exister, appartenir au bon compte, être une offre marketplace expédiée par le vendeur et conserver un produit. Le fournisseur doit être actif et disponible ; le canal doit fournir les identifiants nécessaires à son connecteur.
Les appels externes prévoient une reprise progressive face aux limitations de débit. Une réponse impossible à traiter ou un fournisseur non compatible produit une erreur explicite. Le traitement automatique journalise son échec au lieu de faire disparaître l’événement dans une file silencieuse.
La livraison a été menée par incréments : interface et configuration, séparation entre sauvegarde et push, recalcul sur les variations de stock, connecteurs réels, automatisation, historique et documentation de compatibilité. Cette progression a permis de durcir le parcours sans confondre vitesse de livraison et activation incontrôlée.
14. Ce qui change pour l’équipe marketplace
Passer d’un stock global supposé à une cible dont la provenance est visible
La personne qui pilote une offre voit désormais trois niveaux complémentaires : la somme des stocks qu’elle a autorisés, la cible que Ciama en déduit et la quantité actuellement connue sur la marketplace. Un écart devient un objet de décision plutôt qu’une incohérence difficile à localiser.
La configuration explique la provenance de la cible. Il devient possible de retirer un entrepôt d’une offre, d’en associer plusieurs ou de revenir à la règle par défaut en comprenant l’effet sur le total. La disponibilité diffusée n’est plus un nombre sans filiation.
Le mode manuel apporte une voie de correction immédiate qui n’abîme pas la règle durable. Le mode automatique, lui, suit les variations des sources choisies et évite d’envoyer lorsque la valeur est déjà alignée. Les deux usages se complètent sans partager des comportements contradictoires.
Enfin, la compatibilité par canal est explicite. L’équipe sait si une marketplace accepte le push, si sa relecture est disponible et quelle étape a échoué. Cette franchise réduit le risque opérationnel bien davantage qu’une interface qui uniformiserait visuellement des capacités techniques encore différentes.
15. Le scénario quotidien qui résume le projet
Ajouter un entrepôt à une offre puis laisser la cible suivre ses variations
Une référence active sur Amazon est stockée dans l’entrepôt principal et dans une zone secondaire. Jusqu’ici, l’offre suivait implicitement l’entrepôt par défaut. L’équipe décide que la zone secondaire peut également alimenter cette offre et ouvre ses réglages depuis la ligne du Dispatcher.
Elle reconnaît le produit, sélectionne la seconde parcelle et vérifie l’agrégat par entrepôt. Ciama enregistre les deux liens puis met à jour la cible avec leur somme. Aucune requête ne part à ce moment-là : l’équipe vient de modifier une règle, pas encore de confirmer une diffusion.
Après contrôle, elle envoie manuellement la quantité recommandée. Le connecteur Amazon reçoit le marché, le vendeur, le SKU et la nouvelle disponibilité, puis Ciama relit l’offre. Le stock connu dans la ligne est actualisé et l’historique conserve les deux résultats.
L’équipe active ensuite le mode automatique sur cette offre. Lorsqu’une des deux parcelles évolue, la cible est recalculée. Si elle diffère du stock marketplace relu, un envoi est placé en file ; si les valeurs sont déjà égales, aucun push inutile n’est créé. Le paramétrage initial devient ainsi une règle opérationnelle durable et observable.
16. Relier la diffusion aux autres décisions de stock
Du disponible multi-entrepôts à l’anticipation du réassort
La fiche stock multi-entrepôts marketplace détaille la consolidation logistique sur laquelle le Dispatcher s’appuie. Elle explique comment les lignes d’entrepôt deviennent comparables avant d’être sélectionnées pour une offre.
Le projet rafraîchissement autonome des offres développe le mécanisme de relecture utilisé après un push. Il permet aussi à l’équipe d’actualiser une offre indépendamment d’un envoi de stock.
Le Replenishment Planner marketplace intervient en amont d’une autre décision : anticiper le moment où les sources risquent de ne plus suffire. Le Dispatcher ne prédit pas le réassort ; il diffuse la cible issue des stocks actuellement autorisés.
La page connecteurs marketplace et ERP replace enfin ces briques dans une architecture plus large, où chaque canal conserve ses particularités derrière des contrats métier communs.
17. Conclusion
Un stock bien automatisé commence par une source que l’on peut expliquer
Stock Dispatcher ne cherche pas à deviner le canal le plus rentable ni à répartir artificiellement les dernières unités. Sa force vient d’une promesse plus concrète : permettre de dire exactement quels stocks alimentent une offre, quelle cible ils produisent et pourquoi un envoi doit — ou non — partir.
En séparant les parcelles, le calcul, l’action manuelle, le déclenchement automatique et la relecture du canal, Ciama donne à chaque étape une conséquence claire. L’équipe garde la main sur la règle tout en bénéficiant d’une automatisation liée aux variations réelles de ses entrepôts.
C’est cette exigence que Dawap applique à l’automatisation des commandes et des stocks marketplace : une disponibilité reliée au terrain, un connecteur adapté au canal, un effet externe contrôlé et une trace exploitable quand l’écart demande une décision.
