Le projet en un coup d’œil
Le premier parcours structure comptes, canaux, commandes, lignes, offres et produits autour du contexte 1UP Distribution.
E-commerce, B2B, marge, achats, reporting, Buy Box, stock FBA, réassort et supervision rejoignent progressivement le noyau.
Les derniers jalons renforcent les collectes Amazon FBA, les quotas, le renouvellement des jetons et la stabilité des synchronisations.
Ciama naît le 25 octobre 2025 avec une question concrète : comment réunir dans un même produit les opérations commerce qui se dispersent entre marketplaces, boutiques e-commerce, vente B2B, ERP et entrepôts ? Le lendemain, le projet démarre par un MVP volontairement resserré sur l’OMS, la gestion des commandes.
Ce premier périmètre donne une colonne vertébrale au produit. Un compte possède ses utilisateurs, ses canaux et ses entrepôts ; les commandes apportent leurs lignes ; les lignes rejoignent les offres et les produits ; le stock et les ventes peuvent ensuite être lus depuis les mêmes identités. Le cockpit commence par les relations dont toutes les décisions suivantes auront besoin.
La trajectoire ne s’arrête pas à une liste multicanale. En quelques mois, Ciama ajoute la marge, les faits mensuels, les achats fournisseurs, les matrices d’offres, la Buy Box, l’historique de stock Amazon FBA, les propositions de réassort et un journal des traitements. C’est ce passage d’un flux de commandes à un cockpit marketplace exploitable que cette étude de cas raconte.
Le 8 septembre 2026 constitue le dernier état disponible. À cette date, le travail porte encore sur des réalités très opérationnelles : quotas de création des rapports Amazon, renouvellement de jetons entre deux tentatives, collecte FBA lente et préservation de l’état lorsqu’un fournisseur renvoie un résultat vide.
Ciama est donc présenté ici comme un produit en évolution, pas comme une promesse commerciale figée. Sa valeur se lit dans huit domaines clairement séparés, quatre contextes de livraison, des traitements asynchrones contrôlés et des parcours qui reviennent toujours à la donnée métier source.
1. Ciama, le produit commerce construit par Dawap
Capitaliser les besoins multicanaux sans effacer le contexte de chaque organisation
Ciama est une application développée par Dawap pour les opérations commerce. Son périmètre couvre la vente, le catalogue produit, les offres par canal, le stock, les entrepôts, les achats, les fournisseurs, les indicateurs et l’exécution des synchronisations.
Le contexte 1UP Distribution entre dès le lancement du MVP. Un compte, des utilisateurs de référence, vingt-deux contextes de canal et deux entrepôts donnent au produit une première configuration multicanale : Amazon dans plusieurs pays, Fnac-Darty, Cdiscount, Cultura, Wix, Shopify et Odoo B2B.
Ces vingt-deux contextes ne sont pas présentés comme vingt-deux flux identiques ou tous actifs. Ils montrent la variété que le modèle doit savoir représenter : pays, univers de vente, fournisseur technique, identifiants externes, devise, catalogue et entrepôt ne se combinent pas de la même manière sur chaque canal.
Le produit conserve cette singularité derrière une frontière de compte. Utilisateurs, canaux, produits, commandes, stocks, fournisseurs et exécutions restent rattachés à leur organisation, afin que la mutualisation du socle ne devienne pas un mélange des données.
2. Faire avancer le produit par invariants puis par verticales
Établir les identités communes avant d’ajouter analyse, achat et logistique
La première phase construit les invariants : compte, utilisateur, canal, commande, ligne, offre, produit et entrepôt. Les importations initiales font apparaître les produits manquants, rattachent les lignes aux offres et posent le stock FBA Europe ainsi que les stocks ERP.
La deuxième phase enrichit les décisions. La marge commence au niveau de la ligne de commande puis remonte vers l’offre, le produit, la marque, la catégorie et le tag. Des faits mensuels séparent la lecture analytique des objets opérationnels utilisés au quotidien.
La troisième phase ouvre de nouvelles verticales sans défaire le noyau : commandes Wix, ventes B2B Odoo, achats fournisseurs, reporting par marque et entrepôt, offres Fnac et Cdiscount, Buy Box Amazon, historique FBA et préparation du réassort.
La quatrième phase sécurise l’exécution. Les collectes sont organisées par fournisseur et par univers, les files sont rapprochées de leurs consommateurs, les migrations sont rejouées sur une base neuve et les images de production ne sont promues qu’après les contrôles prévus.
3. Commencer par le parcours qui engage toutes les opérations
Le MVP du 26 octobre 2025 prend la commande comme point d’entrée
La commande est le premier objet réellement transversal de Ciama. Elle désigne un canal, un client, des lignes, des montants et un état d’exécution ; elle influence ensuite le stock, l’expédition, la marge, le service client et la lecture de performance.
Le MVP importe l’historique du compte et fait naître les offres puis les produits manquants à partir des lignes. Cette séquence évite de construire d’abord un catalogue théorique qui ne serait pas raccordé aux ventes déjà disponibles.
Le stock Amazon FBA Europe rejoint le produit dès le 27 octobre, puis les produits et stocks Odoo 1UP le lendemain. Les marques absentes peuvent être créées pendant ce flux, ce qui consolide progressivement le référentiel utilisé par les commandes.
Le choix est structurant : partir de la transaction permet d’identifier les données réellement nécessaires. Le produit, l’offre, le canal et l’entrepôt sont immédiatement testés par une commande qui doit pouvoir être recherchée, comprise et agrégée.
4. Isoler chaque organisation avant de mutualiser le produit
Compte, utilisateurs, invitations, rôles et session forment la première frontière
Le domaine Accès porte les comptes, utilisateurs, invitations et mécanismes d’authentification. Les ressources métier se rattachent ensuite au compte actif afin que les mêmes écrans puissent servir plusieurs organisations sans exposer leurs données entre elles.
Les rôles distinguent les niveaux d’intervention et le back-office applique les contrôles avant d’ouvrir ses fonctionnalités. Les invitations ont leur propre cycle, tandis que la session conserve le contexte nécessaire aux recherches et aux actions suivantes.
Cette frontière se prolonge dans les vues. Une recherche de commande, de produit, de stock ou d’exécution part du compte connecté ; un identifiant fourni dans une URL ne suffit pas à consulter une ressource appartenant à un autre périmètre.
La mutualisation reste ainsi technique et fonctionnelle. Les structures communes sont réutilisées, mais les canaux, règles de fournisseur, entrepôts et décisions demeurent ceux du compte qui les porte.
5. Représenter un canal par son univers et son fournisseur
Marketplace, e-commerce et B2B partagent un cadre sans devenir identiques
Ciama distingue trois univers de vente : marketplace, e-commerce et B2B. Cette classification donne une première lecture de la provenance tout en laissant chaque canal conserver son fournisseur, sa version de connexion et ses fonctions activées.
Le modèle de configuration sépare le fournisseur de sa connexion et de ses fonctionnalités. Une organisation peut donc activer les capacités utiles à un compte sans supposer que tous les connecteurs offrent les mêmes commandes, offres, produits ou stocks.
Les pays et devises complètent ce contexte. Amazon France et Amazon Allemagne peuvent partager une famille technique tout en gardant leur pays, leur monnaie, leur identifiant de catalogue et leurs règles fiscales propres.
Cet arbitrage évite deux extrêmes : un connecteur monolithique impossible à adapter et une succession de développements sans socle commun. Le fournisseur porte l’intégration ; le canal porte son usage dans l’organisation.
6. Faire de la commande un dossier explicable
Recherche, détail, client, lignes et canal restent reliés
Le domaine Vente structure commandes, lignes et clients. Une recherche peut retrouver la transaction par ses identifiants et ses critères métier, puis le détail revient aux produits, offres et informations de canal qui expliquent son contenu.
Les lignes ne restent pas de simples libellés importés. Elles sont rapprochées des offres et des produits, ce qui permet ensuite de remonter une vente dans les agrégats du catalogue, de la marque ou de la catégorie.
Les collectes de commandes deviennent asynchrones dès le 29 octobre 2025. Le temps nécessaire à un fournisseur n’immobilise plus la requête web qui a déclenché ou demandé le traitement.
À mesure que de nouveaux canaux rejoignent le produit, ils utilisent ce vocabulaire commun. Les particularités d’Amazon, Wix ou Odoo restent dans leurs adaptateurs, tandis que le cockpit conserve une commande exploitable par les vues transversales.
7. Construire un produit qui garde ses identités externes
Marques, catégories, tags et alias organisent le référentiel
Le PIM de Ciama réunit produits, marques, catégories, tags et identités associées. Un produit peut ainsi conserver sa place dans le catalogue interne tout en étant rapproché des références observées chez plusieurs fournisseurs ou canaux.
Les alias et mappings servent cette continuité. Le flux Odoo propre à 1UP traite les champs historiques dans un adaptateur dédié, testé sur son cas nominal, ses variantes et l’absence de résultat.
Les catégories peuvent porter une hiérarchie et les tags compléter la segmentation. Ces relations deviennent utiles au-delà de la navigation : ventes, marge, couverture d’offres et contrôles de qualité peuvent être agrégés à ces niveaux.
Le gain tient à la stabilité de l’identité produit. Une ligne de commande, un stock d’entrepôt, une offre marketplace et un achat fournisseur peuvent parler du même article sans dépendre d’un seul identifiant externe.
8. Lire chaque produit dans le contexte de ses offres
Canal, vendeur, prix, disponibilité et historique restent comparables
L’offre porte la relation commerciale entre un produit et un canal. Elle conserve ses identifiants, ses prix, son état, sa disponibilité et les éléments nécessaires à la comparer aux autres présences du même produit.
La matrice d’offres ajoutée en janvier 2026 croise les produits avec leurs canaux. Elle rend visibles les présences, absences et écarts sans demander à l’équipe d’ouvrir successivement chaque fiche fournisseur.
Fnac et Cdiscount rejoignent les collectes d’offres puis de commandes à la fin du même mois. Leur ajout étend la couverture multicanale tout en réutilisant les parcours de recherche, de détail et d’agrégation déjà construits.
L’offre reste distincte du produit. Le catalogue décrit ce qui est vendu ; l’offre décrit où, comment et à quelles conditions il est exposé. Cette séparation protège les analyses de prix, de marge et de disponibilité.
9. Faire remonter la marge depuis la ligne vendue
L’agrégat reste relié aux transactions qui le composent
Le calcul de marge commence sur les lignes de commande à la fin octobre 2025. Il s’enrichit ensuite de la répartition des frais d’expédition FBM et des éléments économiques disponibles dans le contexte de vente.
Les résultats remontent vers l’offre, le produit et la marque, puis vers les catégories et tags. Une équipe peut ainsi changer de niveau de lecture sans perdre le lien avec les ventes qui ont produit l’indicateur.
Des faits mensuels structurent les agrégats dans le temps. Ils évitent de recalculer chaque tableau uniquement à partir de l’état courant et séparent les données analytiques des objets opérationnels modifiés au fil des collectes.
Le produit ne promet pas que tous les coûts possibles sont déjà représentés. Il fournit une chaîne de calcul explicable, capable d’accueillir les données disponibles et de faire remonter la contribution selon plusieurs axes.
10. Étendre le cockpit au-delà des marketplaces
Wix, Shopify et Odoo B2B rejoignent les mêmes identités commerce
Wix rejoint le flux OMS dès le 29 octobre 2025. Shopify possède également son contexte de canal, ce qui permet à l’univers e-commerce de cohabiter avec les places de marché dans le même périmètre de compte.
Les commandes B2B Odoo arrivent le 4 novembre. Le canal B2B n’est pas rangé artificiellement dans la marketplace : son univers reste identifiable, mais ses commandes peuvent contribuer à la lecture multicanale du produit.
Cette extension donne du sens aux comparaisons. Une marque ou un produit peut être analysé entre B2B, e-commerce et marketplaces, tandis que chaque source conserve ses identifiants et ses règles d’import.
Ciama devient ainsi un cockpit commerce plutôt qu’un écran réservé à une API particulière. Le socle accueille plusieurs modes de vente et rapproche leurs résultats sans masquer leur provenance.
11. Relier l’amont fournisseur aux ventes et au stock
Fournisseurs, devis, commandes d’achat et réceptions forment un domaine propre
Le domaine Achats commence en novembre 2025. Il représente les fournisseurs, leurs propositions, les commandes d’achat, les lignes attendues et les étapes qui mènent jusqu’à la réception.
L’achat garde son identité au lieu d’être réduit à une valeur de stock future. L’équipe peut distinguer ce qui a été demandé, ce qui est attendu et ce qui est effectivement reçu dans les entrepôts.
L’historique d’achats par fournisseur complète la décision. Un produit à réassortir peut être rapproché des partenaires qui l’ont déjà fourni et des commandes qui racontent la relation précédente.
Cette séparation prépare une continuité complète : la demande vient des ventes et du stock, la proposition de réassort devient décision d’achat, puis la réception modifie la disponibilité réellement exploitable.
12. Donner une origine claire à chaque quantité de stock
Entrepôts, stocks courants et mouvements ne jouent pas le même rôle
Deux entrepôts sont déclarés dans le premier contexte 1UP : un entrepôt par défaut et Amazon FBA Europe. Le produit peut donc distinguer une quantité gérée dans l’ERP d’un stock confié au réseau logistique d’Amazon.
Le domaine Logistique rattache le stock à son entrepôt et à son produit. Les écrans évitent ainsi d’afficher une quantité globale sans expliquer où elle se trouve ni quelle source l’a produite.
Les règles de diffusion peuvent travailler à partir de cette base. Le stock réellement publiable sur un canal ne se confond pas nécessairement avec la somme brute de toutes les unités observées.
Cette distinction protège les arbitrages. Réserver une quantité, préparer un réassort ou analyser une rupture exige de savoir si le stock est interne, chez Amazon ou encore attendu dans une commande fournisseur.
13. Historiser Amazon FBA par instantané plutôt que remplacer le passé
Le stock courant et sa trajectoire deviennent deux informations complémentaires
En mars 2026, la synchronisation FBA évolue vers les rapports fournisseur. Un historique par instantané est ajouté afin de conserver les états successifs au lieu d’écraser la quantité précédente à chaque collecte.
Cette chronologie permet de relire une évolution de disponibilité. Le produit peut distinguer ce qui est en stock aujourd’hui de la manière dont ce niveau s’est construit au fil des rapports reçus.
L’appariement entre canal, rapport et produit reste essentiel. Une donnée FBA n’a de valeur que si elle rejoint le bon compte, le bon contexte Amazon et l’article correspondant dans le PIM.
Les consolidations de septembre traitent les conditions réelles de cette API : rapports lents, quotas de création et renouvellement du jeton entre deux tentatives. L’historique dépend autant de la robustesse de la collecte que de son modèle de stockage.
14. Préparer un réassort à partir de la demande observée
La recommandation précède la décision et la commande fournisseur
Le planificateur rapproche les ventes réelles, les entrepôts et les niveaux de stock pour préparer une proposition de réassort. La demande n’est pas déduite d’un canal générique : elle reste reliée aux produits et aux lieux qui l’ont portée.
La proposition ne déclenche pas automatiquement un achat irréversible. Elle donne à l’équipe une base de décision, avec les quantités et contextes nécessaires pour confirmer, ajuster ou écarter l’action.
Une fois arbitrée, la suite rejoint le domaine Achats et ses commandes fournisseurs. Cette continuité évite qu’un calcul de besoin reste un tableau isolé sans lien avec l’exécution qui doit le concrétiser.
L’arbitrage maintient l’humain au bon endroit. Ciama prépare et explique le besoin ; l’organisation conserve la maîtrise de l’engagement fournisseur et de ses contraintes commerciales.
15. Observer la Buy Box avant d’agir sur le prix
Fenêtres d’analyse, conversion et vendeur gagnant structurent le signal
La lecture Buy Box s’enrichit en mars 2026. Les observations conservent des fenêtres temporelles, des prix convertis et l’identité du vendeur gagnant afin de comparer une offre dans un contexte plus stable qu’un instant unique.
Une collecte quotidienne est planifiée. Elle alimente l’historique nécessaire pour distinguer un événement ponctuel d’une concurrence qui se répète sur le produit.
Le cockpit peut alors montrer qui gagne, à quel prix et sur quelle période. Il ne transforme pas automatiquement ce signal en repricing : la lecture concurrentielle et la décision tarifaire restent deux responsabilités séparées.
Cette prudence protège la marge. Une baisse de prix ne devient pas la réponse par défaut à chaque perte de Buy Box ; l’équipe dispose d’abord du contexte commercial nécessaire pour arbitrer.
16. Transformer la qualité catalogue en liste d’actions
Contrôles produit et couverture canal rendent les écarts visibles
Le produit possède des contrôles sur les informations nécessaires à une fiche exploitable : identité, marque, catégorie, attributs, relations et présence sur les canaux concernés.
Une matrice de qualité rassemble douze contrôles produit dans une même lecture. Elle ne remplace pas le PIM ; elle indique ce qui limite encore l’exploitation commerciale de la donnée déjà présente.
La matrice de couverture complète ce diagnostic en croisant produits, stocks et offres. Un article peut exister, disposer de stock et rester absent d’un canal actif : cet écart devient une action identifiable.
Le cockpit relie ainsi qualité et diffusion. Corriger une donnée n’est pas un objectif abstrait ; l’équipe sait quel produit, quel contrôle et quel canal sont concernés par la prochaine intervention.
17. Donner un cycle de vie aux collectes instrumentées
File, progression, résultat et métriques restent consultables
Le journal d’exécution représente six états : en attente, en cours, succès, vide, avertissement et échec. Une collecte peut donc se terminer sans erreur tout en signalant qu’aucune donnée n’a été reçue.
La progression est bornée de zéro à cent, la durée est calculée entre début et fin et les métriques numériques peuvent être incrémentées pendant le traitement. Les compteurs visibles distinguent notamment éléments collectés, ajoutés, mis à jour et erreurs.
Les exécutions parentes agrègent leurs enfants. Un échec dans une branche domine le résultat final, tandis que la progression tient compte des enfants terminés et de la fraction déjà parcourue par ceux qui restent actifs.
La recherche est limitée au compte et propose texte libre, mode, univers, statut et fonction. Le détail reste une vue de compréhension : il ne prétend ni relancer ni acquitter un traitement depuis l’écran.
18. Sortir les collectes longues du temps de la requête web
Vingt-trois files explicites sont rapprochées de leurs consommateurs
Les commandes, offres, catalogues, stocks et autres collectes utilisent Symfony Messenger lorsque leur durée ou leur dépendance fournisseur les rend incompatibles avec une réponse web immédiate.
Vingt-trois files explicites sont vérifiées dans les configurations sandbox et production. Le contrôle les compare aux consommateurs disponibles afin qu’une route de message ne reste pas définie sans processus capable de la traiter.
La production possède soixante définitions Supervisor, dont neuf collectes Odoo restent volontairement manuelles. La configuration distingue ainsi les traitements démarrés automatiquement de ceux qui exigent une décision d’exploitation.
Cette architecture protège l’interface et clarifie le run. La demande entre dans une file, un consommateur prend le travail, le journal peut suivre son cycle et l’utilisateur revient ensuite au résultat métier.
19. Faire partager le même domaine à l’API et au back-office
Ressources, recherches et actions utilisent les responsabilités communes
Ciama expose des parcours API pour plusieurs ressources commerce, notamment produits, marques, offres, commandes et canaux. Leur ouverture commence dès novembre 2025 et progresse avec le reste du produit.
Le back-office fournit les recherches et détails nécessaires aux équipes. Il traverse les mêmes domaines d’accès, vente, catalogue, achat, logistique et monitoring sans recopier leurs règles dans chaque gabarit d’interface.
Les contrôleurs restent nombreux parce que les actions sont spécialisées. Une recherche, une consultation, une activation de fonction ou une opération de reprise n’ont pas la même responsabilité ni les mêmes exigences de sécurité.
Cette séparation facilite l’évolution. Une nouvelle source peut être ajoutée dans son adaptateur ; une nouvelle vue s’appuie sur les lectures existantes ; le domaine conserve les invariants partagés entre interface et intégration.
20. Déployer le produit dans quatre contextes explicites
Local, sandbox, production et démonstration gardent leurs différences
Ciama versionne quatre contextes d’exécution. Le local sert le développement, la sandbox les vérifications intégrées, la production le runtime principal et la démonstration une configuration adaptée aux présentations.
La production réunit PHP, Nginx, MySQL, Redis, RabbitMQ et cron. Le web et la planification réutilisent la même image PHP, mais s’exécutent dans des rôles distincts afin que leurs responsabilités restent lisibles.
Les données MySQL, Redis, téléversements et exports possèdent des volumes. Cette persistance ne vaut pas promesse de sauvegarde ou de haute disponibilité ; elle empêche simplement les données concernées de dépendre du cycle de vie éphémère du conteneur.
Le projet Ciama : socle on-premise en images Docker testées détaille cette infrastructure. Ici, elle apparaît comme la condition qui permet aux huit domaines du cockpit de vivre dans un environnement reproductible.
21. Conditionner la promotion de l’image PHP aux contrôles
Tests, migrations, architecture et schéma précèdent le tag publié
La chaîne construit d’abord une image PHP intermédiaire. Les contrôles statiques et la suite PHP l’utilisent avant que le tag destiné à la production soit promu dans le registre.
La base de test est recréée puis migrée. Le statut des migrations est vérifié et le schéma doit produire zéro SQL résiduel, ce qui détecte une divergence entre les entités courantes et l’état attendu de la base.
Un contrôle architectural interdit au domaine de dépendre directement de l’infrastructure et du framework, à l’exception bornée de l’identifiant UUID utilisé par le modèle. La frontière devient une règle exécutable, pas une convention oubliée.
Au 8 septembre 2026, quatre cent quatre-vingt-dix-sept fichiers de test couvrent plusieurs niveaux. Ce nombre n’est pas un taux de couverture ; il montre l’étendue des comportements et contrôles spécialisés qui accompagnent le produit.
22. Consolider les limites des fournisseurs en septembre 2026
Résultat vide, quotas, lenteur et jetons expirés deviennent des cas traités
Les derniers changements disponibles concernent les conditions réelles des API. Une collecte d’offres qui ne reçoit aucun résultat conserve correctement l’état existant au lieu d’effacer implicitement une situation encore valide.
La création de rapports Amazon respecte le quota prévu. Les tentatives sur l’historique FBA acceptent aussi qu’un rapport soit lent, ce qui évite de confondre délai fournisseur et échec définitif.
Le jeton d’accès peut être renouvelé entre deux tentatives de lecture. Cette correction traite une frontière temporelle concrète : l’autorisation valable au départ ne l’est pas nécessairement lorsque le rapport devient enfin disponible.
La journalisation FBA est enfin refermée lorsqu’une erreur fournisseur survient. Le cockpit conserve ainsi un résultat terminal au lieu de laisser une exécution paraître active après la fin réelle du traitement.
23. Résumer six arbitrages qui structurent Ciama
Les choix restent visibles du modèle jusqu’au déploiement
Premier arbitrage : partir des commandes et de leurs relations avant de multiplier les tableaux. Deuxième arbitrage : isoler le compte tout en mutualisant le socle produit.
Troisième arbitrage : distinguer produit, offre, stock et canal afin que leurs identités puissent évoluer indépendamment. Quatrième arbitrage : faire remonter les agrégats depuis les lignes sources plutôt que stocker des indicateurs sans explication.
Cinquième arbitrage : préparer les décisions sensibles, comme le réassort ou le prix, sans déclencher automatiquement l’engagement final. Sixième arbitrage : séparer requête web, file, consommateur et journal pour les traitements longs.
Ces choix donnent une cohérence à l’ensemble. Les huit domaines ne sont pas huit produits juxtaposés : ils représentent les responsabilités successives d’un même cycle commerce multicanal.
24. Rendre les gains observables dans la structure du produit
Continuité, explicabilité, extension et reprise opérationnelle
Le premier gain est la continuité. Une commande rejoint ses lignes, offres et produits ; le produit rejoint sa marque, ses catégories, ses stocks, ses fournisseurs et ses indicateurs ; chaque objet garde le compte et le canal qui lui donnent son contexte.
Le deuxième gain est l’explicabilité. La marge revient aux ventes, la couverture revient aux couples produit-canal, le stock revient à l’entrepôt et l’exécution revient à sa fonction, ses enfants et ses compteurs.
Le troisième gain est l’extension maîtrisée. Marketplace, e-commerce et B2B utilisent le même cadre sans perdre leurs fournisseurs, devises, pays ni règles d’import. Une nouvelle verticale complète le modèle au lieu de recommencer une application.
Le quatrième gain est la capacité de reprise. Un résultat vide, un quota, un jeton expiré ou une branche échouée possède un traitement et une trace plus précis qu’une synchronisation opaque lancée depuis un bouton.
25. Suivre un produit de la vente au réassort
Un seul scénario traverse les huit domaines du cockpit
Une commande Amazon est collectée pour un compte et son canal. Sa ligne est rapprochée d’une offre puis du produit correspondant ; le client, les montants et l’état de la transaction restent disponibles dans le dossier de vente.
Le produit rejoint sa marque, sa catégorie et ses tags. La ligne contribue aux faits mensuels et à la marge agrégée, tandis que l’offre peut être comparée aux autres canaux et aux observations de Buy Box.
Le stock courant et l’historique FBA montrent la disponibilité dans l’entrepôt Amazon. Les ventes observées alimentent une proposition de réassort, que l’équipe peut arbitrer avant de créer ou compléter une commande fournisseur.
Pendant ce temps, les collectes passent par leurs files et consommateurs. Le journal montre leur statut, leur progression et leurs compteurs ; si une erreur fournisseur survient, l’exécution se ferme avec un résultat qui permet de comprendre la prochaine intervention.
26. Continuer à faire évoluer Ciama sans perdre ses frontières
Le dernier état montre un produit vivant et des responsabilités déjà solides
La trajectoire disponible se termine le 8 septembre 2026 sur des consolidations Amazon FBA et offres. Elle ne clôt pas le produit : elle montre au contraire que les adaptateurs et règles d’exécution continuent d’absorber les contraintes rencontrées sur les flux.
Les prochains développements peuvent s’appuyer sur des invariants désormais explicites : frontière de compte, fournisseur configurable, trois univers de vente, identité produit, faits analytiques, entrepôts, achats, messages et journal d’exécution.
La trajectoire Ciama × 1UP Distribution raconte plus précisément les six premiers mois fonctionnels. Le socle on-premise détaille, lui, les conditions de livraison et d’exploitation.
Cette page relie les deux : le passage du MVP OMS à un cockpit commerce complet. Il prouve qu’un produit métier peut élargir son périmètre rapidement à condition de préserver les identités, les frontières et la chaîne de qualité qui rendent chaque nouvelle capacité exploitable.
27. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Entre le 26 octobre 2025 et le 8 septembre 2026, Ciama change de nature. Le MVP sait d’abord relire des commandes et construire les produits, offres et stocks qui les expliquent. Le cockpit réunit ensuite marge, e-commerce, B2B, achats, FBA, réassort, Buy Box, qualité catalogue et supervision.
La force du projet ne vient pas seulement de cette largeur fonctionnelle. Elle tient aux séparations qui rendent le produit compréhensible : huit domaines, une frontière de compte, des fournisseurs configurables, des traitements asynchrones, quatre environnements et une promotion conditionnée par les tests.
Pour une équipe commerce confrontée aux mêmes dispersions entre ERP, marketplaces, boutiques et entrepôts, Ciama Marketplace apporte cette base : un cockpit où la décision reste reliée à la commande, au produit, au stock et à l’exécution qui lui donnent son sens.
