Le projet en un coup d’œil
Les signaux marché, les fournisseurs et les opérations de vente vivaient dans des outils différents.
Recherche, normalisation, connecteurs et échanges Odoo partageaient le même contexte.
Un produit qualifié pouvait progresser vers l’offre, la commande et l’ERP sans ressaisie structurelle.
Trouver un produit rentable n’est que le début. Il faut encore rapprocher les références fournisseurs, contrôler les informations et les images, estimer les frais, créer une offre, suivre les commandes puis transmettre une donnée cohérente à l’ERP.
Unknowbiz a réuni ces étapes dans une même trajectoire. Les fonctions de sourcing croisaient signaux Amazon, Buy Box, frais, fichiers fournisseurs et recherche d’identifiants ; les connecteurs collectaient offres et commandes ; les échanges Odoo prolongeaient le flux vers les référentiels et opérations internes.
Le projet montre ce qu’apporte un accompagnement marketplace vendeurs lorsque la difficulté se situe entre les outils : une architecture qui conserve le contexte du produit au lieu de le reconstruire à chaque étape.
1. Unknowbiz, une chaîne de commerce guidée par la donnée
Décider quoi vendre, puis exécuter sans perdre l’information
La plateforme couvrait la recherche d’opportunités, l’exploitation de catalogues fournisseurs, la gestion de données produit, les marketplaces et la relation avec Odoo.
Ces responsabilités appartiennent à des moments différents, mais parlent du même objet commercial. Une référence identifiée pendant le sourcing doit rester reconnaissable dans l’offre, la commande, le tarif et le stock.
L’enjeu business résidait donc dans la continuité : transformer des signaux dispersés en décisions, puis en opérations contrôlables.
2. Une construction par capacités autonomes
Faire évoluer le sourcing, les canaux et l’ERP sans les confondre
Le sourcing a été enrichi rapidement autour des catalogues fournisseurs, des données Amazon, des frais, de la Buy Box, des images et d’un index de recherche.
Le cœur de données et l’interface ont structuré marchés, produits, offres, commandes, stocks et entrepôts. Les connecteurs marketplace ont ajouté une collecte asynchrone et des traitements de création ou mise à jour.
Les échanges Odoo ont grandi sur près d’un an, jusqu’aux comptes, transporteurs, catégories, sociétés, clients, tarifs, produits, commandes, taxes et entrepôts. Les corrections successives ont renforcé cette articulation.
3. Quand le sourcing s’arrête avant l’exploitation
Une opportunité repérée peut se perdre dans les transferts
Une donnée intéressante trouvée sur un canal ne suffit pas si elle reste déconnectée du fournisseur, du coût, des frais et de l’identité produit. Les tableurs et ressaisies créent alors des écarts difficiles à repérer.
La rupture se prolonge après la mise en vente : offres et commandes doivent rejoindre l’ERP avec les bons comptes, clients, taxes, prix et produits.
4. Construire une continuité depuis la recherche produit
Un même contexte de la décision jusqu’à l’ERP
Le premier objectif consistait à qualifier les produits avec plusieurs sources et à structurer les fichiers fournisseurs avant toute décision commerciale.
Le second visait à faire circuler les objets validés vers les marketplaces puis Odoo, en conservant des traitements identifiables pour les créations et mises à jour.
5. Cinq blocs qui forment une seule chaîne
Sourcing, données, interface, canaux et ERP
Le sourcing combinait Buy Box, frais, recherches externes, images, fichiers et statistiques produit. Le cœur organisait catalogue, offres, commandes et stocks ; l’interface rendait ces éléments consultables.
La collecte marketplace utilisait une file de messages pour découpler les traitements. Odoo recevait et exposait ensuite les comptes, référentiels, tarifs, clients, commandes et entrepôts nécessaires à l’exploitation.
6. Découpler les traitements longs sans casser la traçabilité
L’asynchrone comme outil de robustesse
Collecter plusieurs boutiques et canaux dans une requête unique aurait rendu le système lent et fragile. La file de messages permettait de traiter les flux en arrière-plan et de distinguer création, mise à jour et collecte.
Les responsabilités restaient séparées : le sourcing évaluait, le cœur organisait, les adaptateurs échangeaient et Odoo portait ses objets de gestion.
7. Faire évoluer les échanges sur des cas réels
Corrections ciblées et environnements de validation
Les nombreux ajustements Odoo ont porté sur les comptes, prix, champs produits et comportements d’échange. Un environnement de validation est explicitement apparu dans cette trajectoire.
Les tests présents sur le sourcing et les couches de données sécurisaient les transformations les plus réutilisées, tandis que les traitements asynchrones limitaient l’impact d’un canal indisponible.
8. Une chaîne plus cohérente entre achat et vente
Moins de ressaisie, davantage de contexte partagé
Un produit pouvait être recherché, enrichi, rapproché d’un fournisseur puis exploité dans les offres et commandes sans changer de logique d’identification à chaque outil.
La connexion avec Odoo prolongeait ce contexte jusqu’aux clients, tarifs, taxes, commandes et entrepôts. Les équipes gagnaient une lecture plus continue de la décision commerciale et de ses conséquences opérationnelles.
9. Relier les outils pour préserver la décision commerciale
La chaîne vaut plus que l’addition de ses composants
Unknowbiz montre qu’un projet marketplace peut commencer bien avant la publication d’une offre. La qualité du sourcing, la normalisation fournisseur et l’identité produit déterminent déjà la fiabilité des opérations futures.
En reliant recherche, données, canaux et Odoo, le produit évitait que chaque passage d’outil efface une partie du contexte nécessaire à la décision.
Dawap construit ce type de continuité dans ses missions d’accompagnement marketplace et d’orchestration des opérations vendeurs.
