Ciama : du stock ERP hérité au dispatch marketplace contrôlé

1. Ciama, le produit Dawap qui relie disponibilité logistique et exposition commerciale

Le stock doit rester rattaché au compte, au produit, à l’entrepôt, à l’offre et au canal

Ciama accompagne des opérations où un même produit peut exister dans plusieurs lieux de stockage, être vendu sur plusieurs canaux et suivre deux modes de fulfillment. Le stock disponible dans un entrepôt vendeur ne joue pas le même rôle que le stock détenu par une plateforme, et une offre expédiée par Amazon ne doit pas suivre les mêmes règles qu’une offre expédiée par le marchand.

La chaîne commence donc par une identité stable. Un stock appartient à un compte, un produit et un entrepôt. Une offre appartient au même compte, à un canal et, lorsqu’elle est rapprochée, à ce produit. La quantité cible ne devient pertinente qu’une fois ces relations établies.

La difficulté est temporelle autant que structurelle. Un entrepôt évolue après une réception ou une vente ; une marketplace peut accepter une mise à jour avant de la refléter dans sa lecture ; une collecte FBA parcourt plusieurs pays et plusieurs pages. Il faut conserver des dates, des états et des tentatives pour ne pas réduire ces transitions à un simple succès ou échec.

Le projet a ainsi mûri d’un ensemble de commandes spécialisées vers une chaîne plus lisible. Les briques détaillées possèdent leurs propres études — calculer une cible par offre, tracer chaque envoi et historiser le stock FBA. Ici, l’enjeu est leur continuité.

2. Faire progresser le flux sans prétendre que toutes les transitions sont déjà équivalentes

Observer, normaliser, isoler les adaptateurs puis rendre les limites explicites

Le premier choix a été de conserver les quantités dans le temps. Dès janvier 2024, Ciama rattache un relevé horodaté à une offre marketplace. Cette mémoire rend possible une lecture d’évolution et évite que la dernière valeur écrase toute compréhension du passé.

La deuxième étape a branché des sources réelles. Amazon FBA apporte une disponibilité logistique très détaillée ; Odoo a alimenté le stock interne de 1UP dans la première génération. Ces intégrations ont révélé que le vocabulaire de chaque source devait être transformé avant toute utilisation commerciale.

La refonte de 2026 a ensuite séparé quatre responsabilités : collecter depuis un provider, écrire le stock d’entrepôt, calculer la cible d’une offre et pousser cette cible vers le canal. Les contrôles du compte, du produit, du canal et des accès sont effectués au niveau où ils ont du sens.

Enfin, Dawap a choisi de désactiver le lecteur Odoo de stock dans la nouvelle chaîne tant que sa conception n’était pas suffisamment générique. Cette décision évite de laisser tourner un import client-spécifique sous l’apparence d’un connecteur universel. Le parcours FBA et le dispatch sortant continuent, tandis que la frontière ERP reste assumée.

3. Avant la refonte : plusieurs nombres justes, mais aucune vérité unique

ERP, entrepôt et marketplace décrivaient chacun leur propre état

Dans la première génération, Ciama savait déjà manipuler plusieurs facettes du stock. Le stock interne de 1UP pouvait être lu dans Odoo, Amazon FBA exposait ses propres quantités, et chaque offre marketplace pouvait conserver un relevé. Ces informations répondaient à des besoins réels, mais elles étaient portées par des chemins techniques distincts.

La difficulté apparaissait au moment de prendre une décision commerciale. Une quantité Odoo ne dit pas automatiquement quelle part réserver à un canal. Un stock FBA total contient des unités disponibles, entrantes, réservées ou non vendables. Une valeur relue sur l’offre indique ce que la marketplace connaît, pas ce que l’équipe veut désormais publier.

La trajectoire livrée répond à ce problème par une règle précise : construire une cible à partir de stocks d’entrepôt choisis, puis contrôler son envoi. Les arbitrages commerciaux plus avancés restent hors de ce calcul afin que la quantité affichée conserve une origine compréhensible.

4. Commencer par ne plus perdre l’état précédent d’une offre

Un relevé associe quantité, offre et date d’observation

Le 24 janvier 2024, la première brique structurante enregistre des points de stock au niveau de l’offre marketplace. Chaque relevé conserve une quantité et un instant, reliés à l’offre concernée. Cette structure simple apporte une capacité essentielle : comparer une situation actuelle à son histoire.

Le relevé ne résout pas encore la diffusion. Il ne sait pas sélectionner un entrepôt, calculer une cible ou appeler une API distante. En revanche, il empêche la dernière quantité connue d’effacer les variations précédentes et prépare les écrans d’analyse.

Cette distinction entre observation et action restera présente dans la génération suivante. Ciama peut relire une offre sans modifier sa configuration, et demander une nouvelle lecture après un push sans confondre l’acceptation de la requête avec son effet visible.

5. Importer le stock interne de 1UP depuis Odoo

Une première intégration concrète, conçue pour un contexte client précis

La première génération possède une commande dédiée à 1UP Distribution. Elle retrouve le compte, vérifie l’entrepôt cible, authentifie la connexion Odoo, parcourt les produits par lots de cent et lit le champ de stock interne configuré dans cet ERP.

Chaque produit est rapproché par son identifiant externe. S’il ne possède pas encore de ligne de stock pour l’entrepôt, Ciama la crée ; sinon, il actualise la quantité. Lorsque le coût d’achat par défaut est disponible, la valeur de stock est également recalculée, puis le produit agrège ses quantités.

Cette intégration prouve qu’un flux ERP réel a été mis en œuvre. Elle montre aussi sa limite : le compte, le champ Odoo et plusieurs règles logistiques sont spécifiques à 1UP. La conserver telle quelle dans une architecture multi-comptes aurait transformé une réussite client en dépendance difficile à maintenir.

6. Reconnaître ce que la première génération ne généralisait pas

Une commande dédiée ne devient pas un contrat de stock universel

Le flux historique savait récupérer le stock 1UP et alimenter les écrans Ciama. Il ne définissait pas pour autant une interface commune à tous les ERP, ni une règle réutilisable pour affecter plusieurs entrepôts à chaque offre marketplace.

Le calcul de réapprovisionnement existait dans la navigation et dans plusieurs traitements, mais certains services de domaine restaient encore vides ou dépendaient de commandes spécialisées. Présenter cet ensemble comme une synchronisation générique et achevée aurait masqué la dette de conception.

La refonte part de ce constat. Elle conserve la valeur des expériences — identités produit, entrepôts, relevés, FBA, coûts — mais remplace progressivement les chemins directs par des contrats de collecte, des cas d’usage et des adaptateurs séparés.

7. Donner au stock un domaine indépendant de son fournisseur

Collecte, ajout, mise à jour, finalisation et historique deviennent des responsabilités distinctes

La génération actuelle représente un stock par son compte, son entrepôt, son produit et ses identifiants logistiques. Elle sépare la lecture externe, la persistance et la finalisation. Une nouvelle source doit produire un objet normalisé avant que le reste de Ciama n’ait à le comprendre.

Le cas d’usage de collecte valide d’abord la connexion provider : elle doit exister, être active et posséder des accès valides. Le provider doit lui-même être actif, disponible et appartenir à la famille warehouse. La collecte ne commence qu’après ces contrôles.

L’écriture choisit ensuite entre ajout et mise à jour. L’historique conserve des instantanés dédiés, utilisés par les graphiques et l’analyse de tendance. La source distante reste donc à la périphérie ; l’exploitation travaille sur un modèle stable.

8. Collecter Amazon FBA Europe canal par canal

Seuls les canaux actifs du compte participent à la lecture

Le lecteur FBA connaît seize identifiants marketplace Amazon, de la France à l’Inde. Il ne les interroge pas tous aveuglément : pour chaque compte, il recherche les canaux correspondants et ignore ceux qui n’existent pas ou qui sont désactivés.

La collecte appelle les résumés d’inventaire FBA avec le bon marketplaceId, suit la pagination et neutralise les doublons de FNSKU rencontrés entre canaux. Un produit n’est émis qu’une fois dans une exécution, même si plusieurs pays remontent la même référence logistique.

Les appels prennent en charge les limitations de quota et les jetons de pagination devenus invalides. Les messages de suivi indiquent le canal en cours sans exposer les paramètres sensibles. Un échec sur un canal est journalisé sans effacer les éléments déjà collectés sur les autres.

9. Distinguer dix-sept quantités au lieu d’aplatir le FBA

Disponible, entrant, réservé et non vendable gardent leur sens

Le stock FBA normalisé conserve la quantité expédiable et la quantité totale. Il détaille ensuite l’entrant global, en préparation, expédié et en réception. Cette séparation montre ce qui est déjà vendable et ce qui se rapproche seulement de la disponibilité.

La partie réservée distingue le total, les commandes clients en attente, les transferts entre sites et le traitement dans les centres Amazon. La partie non vendable sépare le total, les dommages client, entrepôt, distributeur ou transporteur, les unités défectueuses et les produits expirés.

Au total, dix-sept quantités sont conservées avec la date d’actualisation et le nom du produit. Ce niveau de détail empêche une quantité entrante ou endommagée d’être confondue avec le stock immédiatement diffusable.

10. Combiner collecte fréquente et reprise complète

Une exécution toutes les vingt minutes, puis un passage complet quotidien

La collecte courante des stocks d’entrepôt est planifiée toutes les vingt minutes. Elle sert à rapprocher régulièrement la lecture Ciama des mouvements observés chez le provider sans attendre une opération manuelle.

Une seconde commande lance une collecte complète chaque jour à six heures. Cette cadence apporte un point de reprise plus large et limite la dépendance à la seule succession de fenêtres courtes.

Les commandes filtrent les connexions réellement actives pour la fonction concernée. Elles n’envoient pas de travail à un provider désactivé ou à des accès invalides. La planification réutilise ainsi le même centre de contrôle que les autres flux Ciama.

11. Faire de la cible une propriété explicite de l’offre

Le stock global du produit ne doit pas être diffusé automatiquement partout

Une fois le stock présent dans Ciama, l’équipe choisit les lignes d’entrepôt qui alimentent une offre précise. La configuration relie l’offre à une ou plusieurs parcelles de stock appartenant au même compte et au même produit.

Deux offres d’un produit peuvent donc suivre des ensembles différents. Le modèle ne prétend pas qu’une quantité physique unique doit être répliquée sur tous les canaux. Il conserve la décision au niveau où elle s’applique réellement.

Le module porte uniquement sur les offres marketplace actives et expédiées par le vendeur. Les offres dont le fulfillment est géré par la plateforme restent hors de ce circuit, car leur disponibilité suit le stock détenu par cette plateforme.

12. Calculer une cible dont la provenance reste compréhensible

Somme des stocks choisis, entrepôt par défaut ou zéro

Lorsque des stocks sont explicitement liés à l’offre, Ciama additionne leurs quantités après avoir ramené toute valeur négative à zéro. Le résultat devient la cible enregistrée sur la configuration et sur l’offre.

En l’absence de sélection, le calcul recherche l’entrepôt déclaré par défaut pour le compte et le stock du produit dans cet entrepôt. Si cette donnée n’existe pas, la cible vaut zéro. Il n’extrapole pas une disponibilité depuis les ventes ou depuis un autre emplacement.

Cette règle est plus sobre qu’un moteur prédictif, mais elle est explicable. L’utilisateur peut ouvrir la configuration et retrouver les lignes à l’origine du nombre. L’étude Stock Dispatcher détaille cette décision offre par offre.

13. Séparer la configuration, l’envoi ponctuel et le mode automatique

Trois actions différentes ne doivent pas se déclencher silencieusement

Enregistrer les stocks liés modifie la cible mais n’appelle pas la marketplace. Cette séparation, renforcée en avril 2026, permet de préparer une règle sans déclencher immédiatement une opération distante.

L’envoi manuel accepte une quantité positive ou nulle saisie pour l’offre. Il utilise la même chaîne de validation et le même adaptateur que l’automatisation, mais ne réécrit pas les parcelles choisies. Une correction ponctuelle ne change donc pas la règle durable.

Le mode automatique peut être activé offre par offre ou sur un ensemble filtré. Lorsqu’un stock source change, Ciama retrouve les offres impactées, recalcule leur cible et envoie un message seulement si le mode est actif et si la quantité publiée diffère de la nouvelle cible.

14. Refuser l’envoi avant l’appel distant si le contexte est incomplet

Offre, fulfillment, produit, canal, provider et accès sont tous vérifiés

Le dispatch exige un identifiant d’offre et une cible positive ou nulle. Il vérifie ensuite l’utilisateur lorsqu’il est fourni, l’existence de l’offre, son mode fulfilled by seller, son canal marketplace et son rattachement produit.

Le provider du canal doit exister, appartenir à la famille marketplace, être actif et disponible. Le canal doit fournir son identifiant catalogue et ses accès. Amazon exige en plus l’identifiant vendeur nécessaire à l’appel Listings Items.

Ces contrôles empêchent une quantité valide d’être envoyée dans un contexte invalide. Ils transforment les erreurs de configuration en réponses métier identifiables, plutôt qu’en appels distants dont l’échec serait plus difficile à diagnostiquer.

15. Adapter le push aux contrats réels de trois familles marketplace

Un même cas d’usage, trois protocoles et trois formes de preuve

Amazon utilise l’API Listings Items. Ciama obtient un jeton, résout le marketplaceId parmi seize canaux, puis remplace l’attribut fulfillment availability de l’offre. Les réponses 200 ou 202 sont contrôlées et les éventuelles issues de sévérité ERROR interrompent le succès.

Fnac/Darty utilise un échange XML. Le connecteur authentifie le vendeur, construit un offers_update avec le SellerSku et la quantité, puis exige un identifiant de lot dans la réponse. Mirakl envoie pour sa part un fichier CSV vers l’API d’import de stock et conserve l’import_id retourné.

Cette couverture correspond à trois familles de push actives : Amazon, Fnac/Darty et Mirakl, notamment Cultura ou Back Market lorsque l’hôte est configuré. Cdiscount peut être relu dans l’interface, mais son push réel n’est pas compté parmi les intégrations actives.

16. Relire l’offre après le push au lieu de s’arrêter à l’acceptation

Le départ de la requête et son effet visible restent deux étapes distinctes

Après un envoi accepté, Ciama peut demander immédiatement ou de manière asynchrone une nouvelle lecture de l’offre. Cette relecture utilise les connecteurs de refresh Amazon, Fnac/Darty, Cdiscount et Mirakl selon le canal.

Le résultat de l’envoi et celui du rafraîchissement sont suivis séparément. Si la marketplace accepte la quantité mais que la relecture échoue, le cockpit affiche le push comme réussi et le contrôle comme incomplet. Il n’efface pas la première réussite, mais ne conclut pas non plus que la valeur est déjà visible.

Cette nuance est essentielle dans un système distribué. Elle permet à l’équipe de savoir si elle doit retenter l’envoi ou simplement reprendre la vérification. Le connecteur conserve ainsi une preuve plus utile qu’un message générique « synchronisation terminée ».

17. Conserver une tentative pour chaque valeur envoyée

Quantité demandée, mode, provider, lot distant et relecture restent reliés

Avant l’appel, Ciama crée une tentative au statut pending. Elle porte le compte, l’offre, le canal, le provider, l’utilisateur éventuel, la quantité demandée, le mode manuel ou automatique, la source de l’action et le contexte utile.

Après le traitement, la tentative passe à success ou failed. Elle peut conserver l’identifiant de lot du provider, un extrait de réponse ou les informations d’erreur. Des champs séparés indiquent si le rafraîchissement a été demandé, s’il a réussi et quand il a été traité.

L’historique global remonte jusqu’à 250 tentatives récentes et peut être filtré par canal, mode, statut ou relecture. Une offre ouvre ses vingt dernières tentatives. La fiche historique des actions stock approfondit cette traçabilité.

18. Organiser le portefeuille comme une file de décisions stock

Recherche, canal, marque, catégorie, tag, écart et mode automatique structurent le tri

Le Stock Dispatcher affiche vingt-cinq offres par page, limitées aux offres actives, marketplace et expédiées par le vendeur. Le tri initial privilégie les quantités vendues sur quatre-vingt-dix jours afin de placer les références les plus actives en tête.

L’équipe peut rechercher une référence puis filtrer par présence de stock, canal, marque, catégorie de niveau un et tag. Deux filtres opérationnels isolent les offres synchronisées ou en écart et celles dont le mode automatique est actif.

Les choix de filtres sont eux-mêmes réduits aux dimensions qui possèdent des résultats dans le contexte courant. Le cockpit évite ainsi les listes de canaux ou de marques sans correspondance et garde l’utilisateur concentré sur les offres réellement actionnables.

19. Faire passer une variation d’entrepôt jusqu’à une offre Amazon

Un scénario relie la source logistique, la cible et le contrôle distant

Une ligne de stock sélectionnée pour une offre vendeur change de quantité. Ciama retrouve les offres directement configurées avec cette ligne ; si elle appartient à l’entrepôt par défaut, il inclut aussi les offres actives du produit qui utilisent la règle de repli.

Le calcul additionne les stocks autorisés et obtient une nouvelle cible. Si l’automatisation est active et si la valeur connue sur l’offre diffère, un message demande le dispatch. Le service vérifie le canal Amazon, les accès, l’identifiant vendeur et le SellerSku avant tout appel.

L’API Amazon reçoit la nouvelle fulfillment availability. Ciama crée une tentative, conserve la réponse, puis déclenche la relecture de l’offre. L’équipe peut enfin comparer la cible et la quantité revenue du canal, ou ouvrir l’historique si la seconde étape n’a pas abouti.

Le même scénario change de protocole pour Fnac/Darty ou Mirakl, mais pas de logique métier. Cette stabilité est le gain principal de la refonte : les règles de décision restent dans Ciama et les particularités réseau restent dans les adaptateurs.

20. Mesurer les gains dans la structure du travail, sans inventer de KPI

Moins de décisions implicites et une reprise localisée

Le premier gain observable est la filiation de la quantité. La cible n’est plus confondue avec le stock produit ou avec la dernière valeur marketplace : elle renvoie à des stocks sélectionnés ou à un entrepôt par défaut clairement identifiable.

Le deuxième gain est la mutualisation. Manuel et automatique partagent le même service de dispatch ; Amazon, Fnac/Darty et Mirakl respectent le même contrat de sortie. Une nouvelle règle de validation ou de traçabilité n’a pas à être reconstruite dans chaque bouton.

Le troisième gain est la précision de la reprise. Une équipe distingue une configuration invalide, un push refusé, un lot accepté ou une relecture échouée. Elle peut agir sur l’étape concernée au lieu de relancer à l’aveugle toute la chaîne.

Aucun taux de survente évitée ni temps économisé n’est attribué au projet sans mesure terrain disponible. La preuve repose sur des transformations vérifiables : dix-sept quantités FBA préservées, trois familles de push, deux modes d’envoi et une tentative détaillée par action.

21. Protéger le chemin critique avec onze fichiers de tests ciblés

Calcul, orchestration, adaptateurs et interface sont exercés séparément

Deux fichiers testent le recalcul de cible en unitaire et en intégration ; deux autres couvrent le dispatch marketplace au même niveau. Les adaptateurs Amazon, Fnac/Darty et Mirakl possèdent chacun leur fichier, tout comme le comportement prévu pour un provider non implémenté.

Le périmètre comprend également le contrôleur applicatif du Stock Dispatcher, la mise à jour de stock depuis la recherche d’offres et la purge des anciennes tentatives. Au total, onze fichiers correspondent à ce cœur fonctionnel.

La collecte d’entrepôt possède ses propres tests sur le cas d’usage, les commandes planifiées et le lecteur Amazon FBA. Ils renforcent la chaîne amont, mais ne sont pas ajoutés au chiffre de onze afin de garder une métrique stable centrée sur le calcul et le dispatch.

22. Laisser visible ce qui reste à reconstruire côté ERP

La maturité d’une intégration se juge aussi à ses fonctions désactivées

Le lecteur générique de stock d’entrepôt accepte aujourd’hui Amazon FBA Europe. Le chemin prévu pour l’entrepôt interne 1UP retourne explicitement que la synchronisation Odoo est désactivée, et la planification de production rappelle que cette récupération attend une nouvelle conception.

La synchronisation actuelle du catalogue 1UP avec Odoo 19 récupère produits, catégories, marques, prix, coûts, dimensions et dates, mais pas le stock. Elle ne doit donc pas être présentée comme le remplacement silencieux de l’ancien import de quantité.

La prochaine étape cohérente consiste à construire un adaptateur ERP de stock compatible avec le domaine Warehouse/Stock, puis à le faire passer par les mêmes contrôles de connexion, d’identité produit, de finalisation et d’historique. Ce chantier pourra rétablir la continuité ERP-marketplace sans réintroduire une commande liée à un seul client.

En attendant, le périmètre utile reste solide : le FBA alimente des stocks détaillés, les stocks Ciama peuvent construire une cible par offre et trois familles de connecteurs savent pousser cette cible. Pour étendre ce socle à un ERP ou un WMS, Dawap cadre les connecteurs marketplace et ERP et leur exploitation dans Ciama Marketplace.