Le projet en un coup d’œil
Chaque écosystème avait ses formats, ses états et son propre rythme d’évolution.
Catalogue, offres, commandes et logistique partageaient un modèle stable.
Un nouveau connecteur pouvait rejoindre la plateforme sans redessiner tout le produit.
Ajouter des canaux de vente un par un paraît simple jusqu’au moment où chacun transporte sa propre définition du produit, de l’offre, de la commande et de l’expédition. Sans architecture commune, chaque intégration finit par dupliquer les règles et rendre les évolutions risquées.
Jetsella a répondu à ce problème par une plateforme modulaire. Un cœur de données organisait marchés, produits, offres, commandes, stocks, colis et entrepôts ; des modules spécialisés prenaient en charge Amazon, Fnac, Cdiscount, eBay, Mirakl et plusieurs solutions e-commerce.
Le projet illustre une intégration API marketplace conçue comme un produit durable : l’objectif n’était pas d’accumuler des connexions, mais de préserver un modèle opérationnel cohérent à mesure que la couverture grandissait.
1. Jetsella, une plateforme pensée pour le commerce distribué
Un même produit derrière des canaux profondément différents
Jetsella devait accueillir des marketplaces généralistes, des environnements Mirakl et des solutions comme Shopify, PrestaShop ou Magento. Ces canaux ne partageaient ni les mêmes contrats techniques ni les mêmes possibilités fonctionnelles.
La plateforme devait pourtant offrir aux équipes une expérience stable pour suivre les objets essentiels : produit, offre, commande, stock, colis, entrepôt et utilisateur.
Ce double impératif — respecter les différences externes tout en unifiant l’usage interne — a déterminé toute l’architecture du projet.
2. Un développement réparti entre cœur, interface et connecteurs
Faire avancer chaque brique sans bloquer les autres
Le cœur de données, son SDK PHP et l’interface ont évolué comme des composants distincts. Les premières étapes ont posé marchés et marketplaces, puis commandes, produits, stocks et indicateurs.
Les connecteurs ont ensuite rejoint ce socle par familles : Amazon, Fnac, Cdiscount, Mirakl et d’autres canaux. Cette organisation permettait de traiter une contrainte spécifique sans figer toute la plateforme.
Des tests de contrôleurs et une intégration continue couvraient le cœur et l’interface. La livraison gagnait ainsi une vérification commune malgré la pluralité des modules.
3. Le risque d’une collection de connecteurs isolés
Quand chaque nouvelle API augmente la dette
Une intégration construite seule transporte souvent son propre modèle de données et ses propres règles. À mesure que les canaux s’ajoutent, une même commande peut être représentée de plusieurs façons et les corrections se répètent.
Pour les équipes, cette fragmentation se traduit par des contrôles différents selon le canal, une visibilité inégale et davantage de dépendance à la connaissance technique de chaque connecteur.
4. Créer une extension maîtrisée du périmètre
Ajouter des canaux sans multiplier les produits
Jetsella devait définir un langage commun pour les objets structurants, puis laisser chaque adaptateur convertir les données externes vers ce langage.
L’interface devait rester stable au-dessus de cette architecture afin que l’ajout d’une marketplace enrichisse la couverture sans imposer un nouvel outil aux utilisateurs.
5. Un noyau catalogue, vente et logistique
Une donnée commune du produit jusqu’au colis
Le cœur rassemblait marchés, marketplaces, produits, offres, commandes et lignes de commande, transporteurs, expéditions, pays, stocks et entrepôts. Un SDK PHP donnait aux modules une manière homogène de dialoguer avec lui.
L’interface proposait des écrans pour les marchés, offres, commandes, produits, colis et entrepôts. Elle rendait visibles les mêmes objets, quel que soit le canal qui les avait alimentés.
6. Assumer une architecture distribuée
Davantage de modules, mais des responsabilités nettes
Séparer les connecteurs augmente le nombre de composants à maintenir. Ce coût était assumé pour éviter qu’une évolution d’Amazon, de Mirakl ou de Shopify ne propage ses contraintes au reste de la plateforme.
Le SDK et le modèle partagé constituaient la frontière : les modules restaient spécialisés, tandis que le cœur protégeait la cohérence nécessaire à l’exploitation.
7. Tester le cœur et l’expérience commune
Sécuriser les contrats les plus réutilisés
Les contrôleurs du cœur et de l’interface disposaient de tests, complétés par des pipelines d’intégration. Cette couverture visait les points où une régression aurait affecté plusieurs canaux à la fois.
Les modules pouvaient ensuite évoluer de façon ciblée, avec une responsabilité clairement attribuée à chaque intégration.
8. Une plateforme capable de grandir par canal
La modularité au service de la continuité
Jetsella a rendu possible une couverture large sans transformer l’interface en juxtaposition de consoles. Les équipes pouvaient retrouver les mêmes familles de données et les mêmes parcours opérationnels.
La séparation entre cœur et adaptateurs réduisait aussi le coût d’un changement externe : l’ajustement restait localisé, tandis que le reste du produit conservait sa stabilité.
9. Une architecture qui transforme les connecteurs en plateforme
La cohérence métier reste le produit principal
Jetsella montre que la réussite d’un projet multicanal ne dépend pas seulement du nombre d’API branchées. Elle dépend surtout de la frontière posée entre les spécificités externes et le modèle utilisé au quotidien.
Le cœur partagé, le SDK, l’interface et les adaptateurs formaient une trajectoire d’extension lisible. Chaque nouveau canal apportait une capacité, sans imposer sa logique à tous les autres.
Dawap applique aujourd’hui cette même exigence aux projets d’API et connecteurs marketplace qui doivent rester exploitables dans la durée.
