Avant de brancher une marketplace, il faut décider comment l’application représentera une boutique, une offre, une commande et leurs évolutions. Une mauvaise frontière à ce stade se transforme vite en règles dupliquées et en écrans difficiles à faire évoluer.
Pour Amz-Friends, Dawap a conçu un socle Symfony qui organise comptes, marketplaces, boutiques, produits, offres, commandes, stocks et marges. Cette phase illustre une intégration API menée depuis le domaine métier plutôt que depuis la réponse brute d’un connecteur.
La réalisation pose également les écrans du futur cockpit et les contrats d’échange nécessaires à son administration. L’objectif : disposer d’une base cohérente avant d’étendre la collecte Amazon.
1. Présentation du client
Comprendre le contexte business avant la solution
Amz-Friends avait besoin d’un outil capable de suivre plusieurs boutiques sans confondre le compte propriétaire, la marketplace et le canal de vente.
Les prix et les stocks évoluent indépendamment, tandis qu’une commande doit conserver ses lignes, son état, ses montants et ses informations d’expédition.
Le premier enjeu était donc de modéliser ces relations et de proposer une navigation commune aux opérations essentielles.
2. Méthode projet Dawap
Analyse, priorisation, delivery agile et sécurisation du run
Le domaine a été découpé en ensembles distincts : administration des comptes, classification des marketplaces, boutiques, catalogue, offres, commandes et conditions de stock.
Les objets principaux sont exposables par API, tandis que deux échanges d’administration récupèrent comptes et classifications depuis un service externe authentifié.
Les écrans suivent le même découpage afin que l’interface et le modèle métier parlent le même langage.
3. Partir du métier
Ne pas laisser un connecteur dicter toute l’application
Une API Amazon expose ses propres identifiants et états, mais l’équipe doit raisonner en boutiques, offres, commandes et stocks.
Le socle Amz-Friends crée ce vocabulaire interne avant l’arrivée de flux plus nombreux.
Cette approche limite la dépendance de l’interface à un format externe particulier.
4. Compte, marketplace, boutique
Séparer propriétaire, canal et point de vente
Un compte peut regrouper plusieurs boutiques, chacune rattachée à une marketplace.
La marketplace possède son identifiant, son classement et sa configuration de connexion, tandis que la boutique conserve ses propres paramètres de synchronisation.
Cette hiérarchie permet de filtrer les opérations sans perdre leur contexte commercial.
5. Structurer le catalogue
Identifier le produit dans son canal
Le produit marketplace conserve identifiant, nom, description, URL, images, catégorie, marque et fabricant.
Une contrainte d’unicité associe le produit à son identifiant dans la marketplace concernée.
Des index Elasticsearch par langue et par ASIN préparent une recherche catalogue adaptée au périmètre Amazon.
6. Historiser les offres
Distinguer l’état courant de son évolution
Une offre est rattachée à une boutique et au produit marketplace qu’elle commercialise.
Les relevés de prix et de stock sont conservés dans des historiques séparés.
Cette structure permet de relire une variation sans écraser l’information précédente.
7. Modéliser les commandes
Conserver l’information utile à l’exécution
La commande porte ses références externes, ses montants, son état ainsi que les informations de facturation et d’expédition.
Chaque ligne conserve quantité, prix, référence produit, condition, coût d’achat, marge, transporteur et suivi lorsqu’ils sont disponibles.
Le modèle relie ainsi la transaction commerciale à son offre et à sa boutique.
8. Préparer la synchronisation
Rendre les états d’échange visibles
La boutique possède des intervalles distincts pour les commandes et les offres.
Les dates de début et de dernier appel, les états de traitement et les indicateurs d’activation permettent de représenter le cycle de synchronisation.
Cette conception prépare un pilotage explicite des flux au lieu d’une tâche invisible.
9. Scénario opérateur
Remonter d’une commande jusqu’au canal concerné
Une opératrice ouvre une commande et consulte ses lignes, leurs prix, leurs conditions et leurs informations d’expédition.
Depuis les relations métier, elle identifie la boutique, la marketplace et l’offre concernées.
Le diagnostic reste ainsi ancré dans une chaîne cohérente plutôt que dans plusieurs tableaux sans lien.
10. Exposer les contrats API
Partager les objets sans recréer un format parallèle
Les principales entités sont déclarées comme ressources API afin de rendre le socle consommable par d’autres interfaces.
L’administration récupère comptes et classements marketplace depuis un service externe protégé par jeton.
Les responsabilités sont séparées entre échange distant, persistance locale et restitution dans le cockpit.
11. Une base extensible
Étendre le flux sans refaire le domaine
Les écrans dédiés aux marketplaces, boutiques, offres et commandes donnent déjà la structure de navigation de l’application.
Le modèle couvre Amazon Europe et Amazon US dans sa classification tout en laissant la place à d’autres familles de connecteurs.
Cette base peut ensuite accueillir une intégration Amazon Selling Partner API sans réinventer les objets du cockpit.
12. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Amz-Friends est un projet de fondations : il rend explicites les relations dont dépend un futur cockpit marketplace fiable.
La séparation entre boutique, produit, offre, commande, historique de prix et historique de stock évite de réduire l’activité à un simple catalogue.
Pour prolonger ce type de socle, Dawap intervient sur la connexion aux API marketplace et la création d’API sur mesure.
