Le projet en un coup d’œil
1UP devait réunir Odoo, Amazon Europe, Fnac, Cdiscount, Wix, Shopify, Cultura et le B2B dans une même base de produits, offres, commandes et stocks.
Le produit a enchaîné OMS, marge, API, reporting, nouveaux canaux, achats, Buy Box et réassort, tout en remplaçant les premiers flux lorsque leur architecture ne tenait plus.
Marketplace, e-commerce et B2B partagent désormais une fondation commune, tandis que chaque fournisseur, canal et entrepôt conserve son contexte d’exécution.
Une roadmap produit crédible ne se résume pas à une liste de fonctions futures. Elle doit montrer ce qui a réellement changé, pourquoi la structure précédente ne suffisait plus et comment les capacités livrées s’enchaînent. Avec 1UP Distribution, cette histoire commence par un OMS marketplace et devient, en six mois, un cockpit qui relie produits, offres, commandes, stock, marge, achats et reporting.
Le périmètre 1UP réunit vingt-deux contextes de canal : Amazon dans seize pays, Fnac-Darty, Cdiscount, Cultura, Wix, Shopify et le canal B2B relié à Odoo. Deux entrepôts structurent le stock, dont un contexte Amazon FBA Europe. Cette empreinte donne au produit un terrain multicanal précis et des frontières concrètes.
La trajectoire suit les livraisons datées : premier OMS fin octobre 2025, calculs de marge début novembre, ouverture API et achats, élargissement Fnac-Cdiscount en janvier, reporting en février, puis refonte par fournisseur, Buy Box, FBA, réassort et contrôle qualité en mars. Cette continuité illustre le travail d’une agence marketplace vendeurs qui fait évoluer le produit avec le run réel.
1. 1UP Distribution, un périmètre pilote inscrit dans la configuration métier
Des canaux, un ERP, des entrepôts et des utilisateurs nommément rattachés au même compte
1UP Distribution n’apparaît pas comme un exemple abstrait. Le compte est créé dans les données de référence, ses utilisateurs lui sont rattachés, ses canaux portent des identifiants dédiés et son intégration Odoo possède un mapping propre pour les champs historiques du catalogue.
La configuration actuelle compte vingt-deux contextes de canal pour 1UP. Seize correspondent à des pays Amazon, de la France à plusieurs marchés européens et internationaux. Fnac-Darty, Cdiscount et Cultura complètent les marketplaces ; Wix et Shopify représentent l’e-commerce ; Odoo porte le canal B2B.
Le stock est organisé autour de deux entrepôts déclarés pour le compte : un entrepôt général et un entrepôt FBA Europe. Cette séparation suffit à faire apparaître des problèmes concrets de disponibilité, de diffusion et de réassort, car une quantité globale ne raconte pas où se trouve le stock ni sur quel canal il peut être promis.
1UP joue ici le rôle de périmètre pilote au sens concret : ses règles et ses connexions structurent directement des chemins de Ciama. La progression se mesure dans les capacités livrées ; la satisfaction, le temps gagné et l’impact commercial demanderaient une instrumentation et un suivi distincts.
2. Lire la roadmap dans les versions successives du produit
Conserver les ajouts, mais aussi les remplacements et les retraits
La chronologie commence le 26 octobre 2025 avec le MVP OMS. Les jours suivants ajoutent automatiquement offres et produits depuis les commandes, relient les lignes aux références catalogue, collectent le stock FBA Europe, importent produits et stocks depuis l’ERP 1UP et rendent les commandes asynchrones.
Novembre ajoute la marge, le B2B, les faits mensuels, les premiers parcours API et le début des achats fournisseurs. Janvier étend commandes et offres à Fnac et Cdiscount. Février approfondit le reporting par marque, catégorie et tag, puis ajoute objectifs et indicateurs annuels.
Mars ne se contente pas d’empiler. Les collectes de commandes et d’offres basculent vers un modèle piloté par fournisseur ; les anciens chemins sont supprimés. Les traitements se spécialisent par univers, la supervision gagne des relations parent-enfant et les fonctions Buy Box, stock FBA, historique et réassort sont consolidées.
Le 26 avril, une capacité de risque stock devenue inadéquate est retirée du contrôleur de roadmap. Ce retrait compte autant qu’un ajout : une trajectoire saine sait supprimer une promesse qui ne correspond plus au modèle cible. La version publique retient donc les changements vérifiables et signale les pages de roadmap encore génériques ou incomplètes.
3. Avant Ciama : plusieurs flux sans modèle commun de pilotage
Le problème ne venait pas du nombre d’écrans, mais des relations entre les données
Un vendeur présent sur plusieurs marketplaces reçoit des commandes avec leurs propres identifiants, statuts, devises et lignes. L’ERP conserve le catalogue et le stock interne. Amazon FBA ajoute un stock externalisé. Les sites e-commerce et le B2B suivent encore d’autres contrats.
Afficher chaque source dans son propre écran aurait conservé ces silos. Pour calculer une marge par produit, il faut relier une ligne de commande à une offre, puis à une référence catalogue, un prix d’achat, des frais, une devise et parfois un entrepôt. Le cockpit devait donc commencer par un modèle commun.
Le périmètre 1UP rend cette difficulté tangible. Les mêmes produits circulent entre Amazon, Fnac-Darty, Cdiscount, Cultura, Wix, Shopify et Odoo. Une référence peut utiliser un SKU direct ou un alias selon le canal. Une commande marketplace doit revenir au bon produit sans perdre son origine.
La roadmap ne pouvait pas tout résoudre au premier jour. Elle devait d’abord rendre le flux de commandes exploitable, puis utiliser ce socle pour les offres, le stock, la marge et les décisions. Cette dépendance explique l’ordre des livraisons mieux qu’une liste de souhaits.
4. Rendre le périmètre pilote identifiable dans le produit
Un compte et des configurations dédiées plutôt qu’une démonstration anonyme
Le compte 1UP sert de racine aux utilisateurs, canaux et entrepôts. Les recherches et collectes peuvent ainsi sélectionner un contexte de travail sans confondre les données avec celles d’un autre vendeur. Cette relation deviendra ensuite un invariant de l’architecture par fournisseur.
Les vingt-deux canaux déclarés ne sont pas présentés comme vingt-deux intégrations toutes équivalentes ou toutes actives au même niveau. Il s’agit de contextes de vente configurés : seize marchés Amazon, trois autres marketplaces, deux sites e-commerce et un canal B2B Odoo.
Le mapping Odoo 1UP traduit des champs historiques du catalogue en produit Ciama. Il normalise notamment l’identifiant interne, le nom et les valeurs utiles au PIM. Les tests dédiés vérifient ce comportement, y compris l’absence de résultat lorsque l’entrée ne permet pas de construire un produit valide.
Les deux entrepôts fournissent la dimension logistique minimale : stock général et FBA Europe. Ils permettent de rattacher une quantité à un lieu et à un mode de traitement. La suite de la roadmap pourra alors distinguer stock disponible, stock diffusable et stock réellement engagé sur une offre.
5. Transformer une succession de besoins en architecture produit
Chaque vague doit enrichir le modèle sans enfermer le compte pilote
Le premier objectif était de centraliser sans effacer l’origine. Commandes, offres et produits utilisent un vocabulaire commun, mais conservent le canal et le fournisseur qui expliquent leur collecte. Une donnée normalisée doit rester diagnostiquable.
Le deuxième objectif consistait à produire des décisions, pas seulement un entrepôt de données. La marge, les objectifs, la Buy Box, les risques de rupture et le réassort transforment les flux intégrés en priorités exploitables par les équipes.
Le troisième objectif portait sur la capacité de remplacement. Les premiers collecteurs pouvaient valider un usage rapidement, puis être supprimés lorsque le modèle par fournisseur devenait plus cohérent. Une roadmap utile autorise ce type de refonte au lieu de sanctuariser chaque version intermédiaire.
Enfin, 1UP ne devait pas devenir une condition codée partout dans le domaine. Les particularités restent dans les configurations, mappings et connexions concernés. Les cas d’usage communs continuent de travailler par compte, fournisseur, canal, produit et entrepôt.
6. 26 octobre 2025 : lancer le MVP autour des commandes
Une première chaîne OMS qui crée déjà ses relations catalogue
Le premier lot pose l’OMS de Ciama, la configuration de production et le compte 1UP. Amazon fournit le premier terrain marketplace. Les canaux commencent à suivre leur volume de commandes, leurs expéditions et leurs montants taxés ou convertis.
Le flux ne conserve pas seulement une commande brute. Il génère une offre lorsqu’elle manque, puis crée le produit PIM correspondant et relie les deux. Les lignes de commande rejoignent ensuite l’offre et le produit afin que les agrégats commerciaux puissent remonter au catalogue.
Des filtres annuels rendent l’historique consultable. Une commande de chargement complet permet de reconstruire le passé d’un compte plutôt que d’attendre uniquement les nouvelles ventes. Cette capacité est importante pour démarrer un cockpit avec une base analytique déjà exploitable.
Le MVP reste imparfait et les corrections s’enchaînent dès les premières heures. Cette densité n’est pas présentée comme une performance de vélocité. Elle montre plutôt que le modèle a été confronté immédiatement à des données réelles et ajusté avant d’accueillir les couches de marge et de stock.
7. 27 et 28 octobre : relier FBA Europe et l’ERP 1UP
Le catalogue ne peut pas piloter la vente sans origine de stock
Le 27 octobre, une commande charge le stock Amazon FBA Europe et le relie au produit. Le produit commence alors à porter autre chose qu’un historique de vente : il dispose d’une position logistique issue d’un entrepôt distinct.
Le 28 octobre, un flux dédié importe depuis l’ERP les produits et les stocks de 1UP. Les marques absentes sont créées pendant ce passage. Le catalogue Ciama peut donc rapprocher la référence commerciale vue sur les canaux de la référence interne issue d’Odoo.
Les règles de calcul de stock sont corrigées le même jour. Ce point montre un principe de la trajectoire : une donnée collectée n’est pas automatiquement une donnée diffusable. Sa signification doit être testée face au mode de fulfillment, aux quantités et aux liens avec le produit.
La séparation des deux entrepôts évite de sommer aveuglément stock général et FBA. Elle prépare les futures vues par entrepôt, l’historisation et le réassort. Le chantier logistique apparaît ainsi dès la première semaine, bien avant de devenir un module complet.
8. 29 octobre : sortir la collecte longue de la requête utilisateur
Les commandes deviennent un flux distribué et supervisable
La collecte d’historique de commandes passe dans une file asynchrone avec sa configuration Supervisor. Le navigateur ou la commande de déclenchement n’a plus besoin de rester ouvert pendant le traitement de toutes les périodes et de tous les canaux.
Wix rejoint le flux OMS le même jour. Une livraison par défaut est associée au canal et les lignes se relient automatiquement pendant l’intégration. Le modèle commence donc à absorber un canal e-commerce sans créer un second OMS parallèle.
Cette décision ouvre une nouvelle responsabilité : déclarer la file, lancer son consommateur, suivre les erreurs et conserver la parité entre environnements. Les vagues ultérieures renforceront ces garde-fous avec des files spécialisées par fonction et des journaux parent-enfant.
L’asynchrone ne garantit pas à lui seul la réussite. Il protège le temps de réponse et rend le travail reprenable. La qualité dépend encore de l’idempotence des ajouts, de la distinction entre création et mise à jour et de la visibilité sur chaque exécution.
9. 30 octobre au 7 novembre : faire remonter la marge jusqu’au catalogue
De la ligne de commande aux offres, produits, marques et catégories
Le calcul commence au niveau le plus proche de la vente : la ligne de commande. Les coûts d’expédition FBM, les montants taxés et les conversions de devise doivent être rapprochés du prix et du coût avant d’agréger une performance.
La marge totale puis son taux remontent vers l’offre, le produit et la marque. Les calculs lourds passent par des messages asynchrones. Les écrans produit et marque gagnent des graphiques, tandis qu’un outil de reporting permet de lire la marge au-delà de la commande isolée.
Les catégories et les tags rejoignent ensuite la lecture. Le calcul récursif des catégories et la pondération du taux de marge sont corrigés au fil des données. Cette progression évite de comparer directement une petite référence très rentable et un volume important faiblement margé sans rappeler leur poids.
Le gain n’est pas chiffré en euros dans cette fiche. La transformation vérifiable tient au changement de modèle : une vente peut désormais contribuer à des agrégats par canal, offre, produit, marque, catégorie et période, plutôt que rester enfermée dans son document d’origine.
10. 4 novembre : faire entrer les commandes B2B dans le même cockpit
Odoo devient aussi une source de vente, pas seulement de catalogue
Le canal Odoo 1UP porte le catalogue B2B, puis les commandes B2B rejoignent Ciama le 4 novembre. Cette arrivée élargit la fonction du produit : il ne compare plus uniquement des marketplaces et un site, il rapproche aussi la vente aux professionnels.
Les dates année, mois et jour sont ajoutées aux commandes et à leurs lignes pour faciliter les agrégations. Les vues peuvent ainsi comparer des périodes sans recalculer systématiquement chaque découpage depuis une date brute.
Le B2B possède des notions qui ne se réduisent pas à une marketplace : client, revendeur, devis, commande et conditions commerciales. La roadmap conserve donc un univers de vente distinct tout en réutilisant les produits, les offres, les montants et les faits analytiques communs.
Cette décision prépare les évolutions commerciales de mars 2026, lorsque les clients, revendeurs et commandes obtiennent leurs recherches et navigations dédiées. Elle montre aussi pourquoi Ciama dépasse progressivement son intitulé d’OMS marketplace initial.
11. 11 novembre : ouvrir les données et commencer les achats fournisseurs
Les parcours produit deviennent réutilisables hors du back-office
La première vague API expose des recherches et détails sur les produits, marques, offres, commandes et canaux. Les modèles de lecture sont séparés de la présentation web afin qu’un consommateur JSON reçoive un contrat stable plutôt qu’un fragment d’écran.
Cette ouverture oblige à structurer les entrées, la pagination, les descriptions et les erreurs. Elle ne signifie pas que toute l’application est disponible par API. La roadmap avance par parcours identifiés et conserve les limites de chaque ressource.
Le même jalon commence le domaine des achats. Les fournisseurs et leurs commandes vont pouvoir être rapprochés du catalogue et des ventes. Le produit prépare ainsi le passage d’une analyse a posteriori vers une décision d’approvisionnement.
API et achats partagent un principe : une capacité doit être consommable sans connaître l’implémentation de l’écran qui l’a précédée. Cette séparation facilitera ensuite le passage aux fournisseurs configurables et aux commandes de réassort.
12. Novembre et décembre : donner une profondeur historique au pilotage
Marques, catégories, livraisons et entrepôts deviennent des axes d’analyse
Fin novembre, les rapports de croissance par marque et les analyses de livraisons d’entrepôt complètent les premières marges. La longitude des pays rejoint aussi le produit pour préparer des lectures géographiques sans réduire l’activité à une liste de commandes.
Les objets analytiques distinguent la donnée opérationnelle de ses faits mensuels. Cette séparation évite de parcourir toutes les lignes historiques pour chaque carte de dashboard et donne une base plus stable aux comparaisons de périodes.
Décembre affine les vues commande, entrepôt et reporting ainsi que les parcours utilisateurs. La période comporte moins de fonctions nommées que les vagues d’octobre et de mars ; elle est donc présentée comme une consolidation entre deux accélérations.
Le bénéfice observable est architectural : les opérations peuvent être lues par temps, canal, produit, marque, catégorie et entrepôt. Aucun gain de vitesse ou de chiffre d’affaires n’est attribué à 1UP sans mesure avant-après disponible.
13. 28 et 29 janvier : élargir le socle à Fnac et Cdiscount
Les offres et commandes changent de fournisseur sans changer de cockpit
Fnac-Darty et Cdiscount rejoignent d’abord les offres, puis leurs commandes. Cette extension vérifie que le modèle construit autour d’Amazon n’est pas prisonnier de son premier fournisseur.
Le rapport de matrice d’offres apparaît la veille. Il croise les références du catalogue et les canaux pour faire ressortir les produits présents, absents ou incomplets. L’expansion des connecteurs devient ainsi un sujet de couverture, pas seulement de volume collecté.
Chaque fournisseur conserve son contrat propre. Fnac-Darty, Cdiscount et Amazon ne renvoient ni les mêmes formats ni les mêmes notions de fulfillment. Le domaine normalise ce qui peut l’être et garde le fournisseur pour les comportements qui doivent rester spécifiques.
La configuration 1UP compte aujourd’hui ces canaux parmi ses vingt-deux contextes. Ce nombre décrit une empreinte configurée, pas un engagement que chaque flux dispose exactement du même niveau fonctionnel. La page conserve cette nuance dans ses métriques.
14. Février : comparer la performance à un objectif explicite
Le reporting passe du constat à une trajectoire annuelle
Le reporting par marque, catégorie et tag est enrichi le 17 février. Le 21 février, une configuration d’objectifs annuels rejoint le dashboard. Le cockpit peut alors juxtaposer la performance observée et une cible définie pour l’exercice.
Ces objectifs ne sont pas dérivés automatiquement d’une prévision. Ils constituent un paramètre de pilotage. Cette distinction laisse à l’entreprise la responsabilité de la cible tout en donnant à Ciama la responsabilité de mesurer l’écart avec des données comparables.
La même période voit apparaître des travaux sur fulfillment, transport et services augmentés. Tous n’ont pas le même niveau de maturité. La trajectoire publique retient les capacités reliées à un parcours exécutable et évite de transformer chaque expérimentation en résultat acquis.
Le produit change alors de posture. Un OMS répond à « que s’est-il passé ? ». Les objectifs, faits mensuels et répartitions par univers commencent à répondre à « sommes-nous sur la trajectoire attendue ? », tout en laissant la décision finale à l’équipe.
15. 6 au 12 mars : remplacer les collectes historiques par un modèle fournisseur
Une refonte de structure au milieu de la trajectoire
Début mars, les commandes et les offres sont séparées par univers, puis par opérations de collecte, ajout et mise à jour. Les files de messages et les tâches planifiées suivent cette nouvelle découpe. L’objectif est de rendre chaque étape identifiable plutôt que de conserver un traitement monolithique.
Le 12 mars, la migration vers le modèle piloté par fournisseur est achevée pour les commandes et les offres. Les anciens flux marketplace et e-commerce sont supprimés, de même que leurs anciennes collectes planifiées. La roadmap assume donc un remplacement net, pas une double architecture permanente.
Le fournisseur devient le point de sélection du lecteur et de ses capacités. Le compte choisit ses connexions actives, puis le parcours demande la fonction nécessaire : commandes, offres, catalogue, entrepôt ou livraison. Une même marque de connecteur peut ainsi servir plusieurs usages sans être activée globalement.
Pour 1UP, ce changement réduit la dépendance à des conditions dispersées par canal. Les particularités Odoo, Amazon, Fnac-Darty, Cdiscount, Wix ou Shopify restent dans leurs adaptateurs et configurations, tandis que les cas d’usage travaillent sur des contrats communs.
16. 8 au 14 mars : transformer la Buy Box en objet de décision
Prix convertis, vendeurs concurrents, fenêtres et rafraîchissement asynchrone
Le Product Explorer reçoit une lecture Buy Box, puis une collecte par fenêtre. Les prix gagnants sont convertis dans une devise comparable, les vendeurs sont reliés aux observations et le produit marketplace centralise le gagnant courant.
Les vues ajoutent des détails de prix, des fenêtres cliquables et un rafraîchissement asynchrone de la fiche marketplace. Une observation vieillissante peut déclencher une mise à jour plutôt que d’être présentée silencieusement comme actuelle.
Le 14 mars, une file quotidienne et ses cadences de production encadrent la collecte. La liste est optimisée et les actions de rafraîchissement gagnent un retour d’interface. La capacité passe progressivement d’un écran exploratoire à un parcours exploitable.
Aucune promesse de repricing automatique n’est faite ici. Ciama rassemble le gagnant, les prix et les offres actives en stock ; la décision de modifier un prix et ses garde-fous commerciaux restent un autre périmètre.
17. 15 au 18 mars : relier stock FBA, historique et réassort
Une recommandation doit pouvoir revenir à ses ventes et à son entrepôt
La synchronisation FBA bascule vers des rapports et un appariement canal-commande. Elle récupère stocks, fulfillment et données de coûts selon les capacités du fournisseur. Le parcours affiche une progression plutôt que de laisser une longue collecte sans état.
Le stock obtient un historique de snapshots. Une quantité courante peut désormais être comparée à des états antérieurs, ce qui donne du sens aux tendances de rupture et à la vitesse de vente. L’historique reste rattaché à l’entrepôt concerné.
Le Replenishment Planner prépare des propositions depuis les ventes observées et le contexte de stock. Les commandes fournisseurs suivent ensuite leur progression vers la réception. Le cockpit relie ainsi signal de besoin, préparation d’achat et mise à jour logistique.
Cette chaîne n’est pas présentée comme une commande automatique sans contrôle. Les horizons, filtres et quantités apportent une base de décision. La validation et l’exécution fournisseur restent des étapes distinctes dont le statut doit rester visible.
18. Industrialiser la qualité à mesure que le produit s’élargit
Unitaires, intégration, parcours web, frontières et exécution
La densité fonctionnelle de mars s’accompagne d’une campagne de tests. Les cas d’usage du domaine reçoivent des tests unitaires, les persistances et messages des tests d’intégration, et les routes du back-office et de l’API des scénarios applicatifs autonomes.
Des contrôles empêchent le domaine d’importer directement les couches Symfony, Doctrine ou infrastructure. Les migrations sont appliquées sur une base neuve et leur écart avec le mapping est vérifié. Les files déclarées sont comparées aux consommateurs disponibles dans les environnements ciblés.
Ces garde-fous ne prouvent pas qu’aucun défaut n’atteindra jamais le run. Ils réduisent des classes de régression précises : route inaccessible, contrat API cassé, cas d’usage sans refus, migration manquante, message sans worker ou dépendance du domaine vers le framework.
L’industrialisation permet aussi de retirer une capacité. Lorsqu’un module de risque stock ne correspond plus au modèle cible, il peut disparaître de la roadmap et de ses dépendances au lieu d’être maintenu uniquement parce qu’il a déjà existé.
19. Rendre la trajectoire visible sans confondre changelog et promesse
La page produit distingue mal encore certains mois : la fiche corrige cette faiblesse
Ciama possède une page de roadmap accessible depuis le back-office et couverte par un test applicatif. Elle présente les grandes familles de progression : centralisation des opérations, transformation des données en décisions et industrialisation des flux.
Sa version actuelle détaille surtout septembre, octobre, février et mars dans l’interface, tandis que novembre, décembre et janvier comportent encore des blocs d’attente. Une seconde structure narrative couvre octobre à mars, mais génère aussi des mois génériques qui ne correspondent pas à des livraisons documentées une par une.
La présente étude unifie la lecture autour des changements datés et des capacités accessibles. Les périodes qui ne disposent pas encore d’un chapitre détaillé restent hors de la narration principale plutôt que de recevoir un bilan générique.
La prochaine version du changelog devrait posséder un seul référentiel éditorial, marquer clairement « livré », « en cours » et « envisagé », lier chaque chapitre à une capacité accessible et laisser vides les mois sans publication. La roadmap deviendrait alors un véritable contrat de lecture.
20. Passer d’un OMS Amazon à une fondation de commerce multicanal
L’avant-après se lit dans les relations et les parcours disponibles
Au départ, la priorité est de collecter des commandes Amazon et de construire automatiquement les offres et produits associés. Six mois plus tard, le même socle distingue trois univers de vente, plusieurs fournisseurs, deux entrepôts et vingt-deux contextes de canal pour 1UP.
La donnée commerciale ne s’arrête plus à la commande. Les lignes alimentent les marges, les faits mensuels et les lectures par produit, marque, catégorie, tag et canal. Les offres rejoignent les matrices de couverture et la Buy Box. Les stocks rejoignent l’historique et le réassort.
L’architecture a elle aussi changé. Les collectes historiques ont été remplacées par un choix de fournisseur et de capacité. Les travaux longs utilisent des files spécialisées ; les exécutions deviennent supervisables ; les tests couvrent davantage de niveaux et les images sont promues après contrôles.
Ce résultat ne signifie pas que Ciama est terminé ni que chaque contexte 1UP possède toutes les fonctions. Il démontre une base capable d’absorber de nouveaux besoins sans conserver éternellement ses premiers raccourcis.
21. Distinguer empreinte configurée, usage réel et impact
Une livraison datée ne suffit pas à mesurer l’adoption
Cette roadmap est organisée autour des capacités livrées, remplacées ou retirées. Elle ne fixe pas une cadence contractuelle de cycles ni un protocole unique de validation. Une gouvernance client complète devrait relier chaque priorité à son responsable, son statut, son critère de succès et sa date de décision.
Les vingt-deux contextes configurés ne sont pas déclarés tous actifs, synchronisés ou équivalents. Ils couvrent des pays Amazon, d’autres marketplaces, l’e-commerce et le B2B avec des profondeurs différentes. Une connexion déclarée ne vaut pas preuve de volume traité.
La télémétrie actuelle ne construit pas encore de référence avant-après sur le temps gagné, les ruptures évitées, la marge protégée ou le chiffre d’affaires influencé. Le prochain niveau de pilotage devra choisir quelques indicateurs, fixer leur point de départ et suivre leur évolution par fonctionnalité.
Enfin, le changelog intégré doit encore supprimer ses contenus génériques et unifier ses deux structures. La meilleure suite n’est pas d’ajouter davantage de promesses : elle consiste à relier automatiquement chaque version livrée à son statut, sa date, son périmètre et son test de parcours.
22. Relier la trajectoire aux autres projets 1UP
OMS, sourcing et B2B donnent trois lectures complémentaires
Le hub OMS multicanal de 1UP Distribution raconte la centralisation opérationnelle qui précède Ciama et explique pourquoi commandes, offres, stocks et ERP doivent partager un même vocabulaire.
Le projet de sourcing et rapprochement de marge pour 1UP montre l’autre origine de la trajectoire : comparer l’achat fournisseur à la vente marketplace pour décider avant de commander.
Le cockpit des commandes B2B Odoo détaille enfin l’univers commercial apparu en novembre puis renforcé en mars, avec clients, revendeurs, montants facturés et états de commande.
Ensemble, ces projets prolongent l’accompagnement marketplace vendeurs : partir d’un flux exploitable, relier les décisions économiques, puis élargir le cockpit sans perdre les frontières de compte, de fournisseur et de canal.
23. Conclusion
Une roadmap vaut par les changements qu’elle peut montrer et les limites qu’elle accepte
Entre le 26 octobre 2025 et mars 2026, Ciama passe d’un MVP OMS centré sur les commandes à une fondation qui relie trois univers de vente, vingt-deux contextes de canal 1UP, deux entrepôts, la marge, les achats, le reporting, la Buy Box et le réassort.
Cette progression n’est pas une ligne droite. Des calculs sont corrigés, les collectes historiques sont remplacées par un modèle fournisseur, les traitements sont séparés et une capacité devenue inadéquate est retirée. C’est précisément cette faculté de réviser l’architecture qui rend la trajectoire crédible.
Dawap inscrit cette continuité dans son offre d’agence marketplace vendeurs : documenter le livré, distinguer la configuration de l’usage mesuré et transformer chaque nouvelle fonction en parcours maintenable plutôt qu’en promesse de roadmap.
