Une intégration multicanale comporte plusieurs contrats : celui de l’ERP, ceux des plateformes de vente et celui de l’application qui doit exploiter leurs données. Les relier exige de décider où vivent les références, les quantités et les états métier.
Pour Pixminds, Dawap a développé NetMinds, une application interne reliée à Sage 100c par l’API REST d’un partenaire technique spécialisé. Les intégrations Amazon et Fnac complétaient ce périmètre pour importer et traiter les données des canaux.
Cette fiche décrit l’architecture et les échanges de cette réalisation historique. Elle montre comment une intégration Sage s’articule à des API marketplace, à un modèle métier indépendant des formats sources et à un premier périmètre d’intégration Amazon FBA clairement borné.
1. Présentation du client
Comprendre le contexte business avant la solution
Le projet NetMinds s’inscrivait dans l’activité marketplace et e-commerce de Pixminds. La DSI, les directions commerciales et la logistique étaient impliquées dans les besoins de l’application.
L’enjeu technique consistait à relier ces usages sans transformer chaque fonctionnalité en développement dépendant d’un seul canal. Les objets communs devaient préserver les informations nécessaires à la gestion et à la traçabilité commerciale.
Sage 100c restait un élément de l’environnement de gestion. La passerelle REST tierce apportait le point d’accès utilisé autour de l’ERP, tandis que Dawap concevait les échanges et l’application métier.
2. Méthode projet Dawap
Analyse, priorisation, delivery agile et sécurisation du run
Le domaine interne distinguait marchés, produits, commandes et lignes de commande. Des services propres aux plateformes géraient leurs échanges et alimentaient ce référentiel.
Cette séparation permettait de rapprocher les identifiants externes et les références internes. Une réponse API devait devenir un objet métier exploitable, sans perdre la plateforme et la transaction d’origine.
Les écrans s’appuyaient sur ce domaine et sur des espaces de canal séparés. Le périmètre combinait traitements de données et actions métier ; certaines fonctions de préparation FBA étaient exploratoires, distinctes des échanges opérationnels confirmés.
3. Trois responsabilités dans l’architecture
ERP, passerelle et application
L’organisation du projet distinguait Sage 100c, l’API REST exposée par le partenaire et NetMinds. La passerelle donnait une interface à l’ERP ; l’application devait connaître les données attendues, leur sens et leurs correspondances.
Dawap prenait en charge la conception métier et l’interconnexion des canaux. Le rôle du partenaire sur l’accès Sage complétait ce travail, sans remplacer les règles propres à l’application.
Ce modèle reste pertinent pour un middleware sur mesure : l’accès technique, la transformation des données et l’orchestration des opérations constituent des responsabilités explicites.
4. Les données échangées avec Sage 100c
Relier gestion et commerce
Le périmètre Sage comprenait articles, clients, tarifs, stocks et préparation de commandes. Les correspondances devaient préserver codes articles, codes clients, taxes, unités, désignations et informations commerciales utiles.
Les traitements articles exploitaient notamment les tarifs de vente, informations fournisseurs, poids, codes-barres et données de conditionnement. La synchronisation du catalogue demande donc davantage qu’un couple référence-désignation.
Les traitements de stock conservaient plusieurs états et des seuils, avec un calcul du disponible à partir du réel, du réservé et du préparé. L’application pouvait utiliser la disponibilité commerciale sans la confondre avec une quantité physique.
5. Un référentiel interne pour les canaux
Rapprocher au lieu de recopier
Le modèle commun séparait commande et lignes. Une ligne pouvait être rattachée à un produit interne ; le marché identifiait son canal. Cette structure facilite la consolidation de commandes issues de sources différentes.
Les références Amazon, Fnac et celles de gestion ne deviennent pas automatiquement interchangeables. Les correspondances appartiennent au contrat de données et doivent permettre de retrouver l’objet d’origine.
Une intégration actuelle doit aussi prévoir ce qu’elle fait d’une référence inconnue : mise en attente, correction ou refus. Ce contrôle complète le principe de référentiel illustré par NetMinds.
6. Amazon MWS : commandes et rapports
Des appels au service utilisés dans les traitements
La réalisation historique utilisait Amazon MWS. Les services appelaient ListOrders et ListOrdersByNextToken pour parcourir les commandes, puis ListOrderItems pour récupérer leurs lignes.
D’autres traitements utilisaient RequestReport et GetReport pour demander et récupérer des rapports, notamment de catalogue et de commandes. La distinction entre demande et récupération est importante pour ce type de traitement différé.
Ces noms décrivent les interfaces utilisées à l’époque. Ils ne constituent pas une recommandation pour une nouvelle intégration Amazon : notre offre actuelle d’intégration API marketplace qualifie les interfaces et accès disponibles aujourd’hui.
7. Fnac : récupérer commandes et offres
Requêtes XML et pagination
Les traitements Fnac construisaient des requêtes XML et les envoyaient en HTTP. Les opérations orders_query et offers_query servaient respectivement à récupérer les commandes et les offres.
Les chargeurs parcouraient les pages de résultats et utilisaient une date de sélection. La récupération n’était donc pas limitée à une réponse unique : elle prévoyait le parcours du jeu de données retourné.
L’information importée alimentait les objets de l’application. La séparation entre client API et gestionnaire métier rendait visibles le transport des données et leur exploitation.
8. Fnac : agir sur stocks et commandes
Des échanges dans les deux sens
L’opération offers_update était utilisée pour mettre à jour la quantité d’une offre. Les services produits raccordaient cet appel aux données traitées dans l’application.
orders_update couvrait des actions d’acceptation et de confirmation d’expédition. Les traitements de suivi ajoutaient transporteur et numéro de colis, puis exploitaient le retour du service pour mettre à jour l’état interne.
Ce lien entre action et état est essentiel : une commande marquée expédiée doit correspondre à une opération identifiée. Dans un nouveau projet, le contrat précise aussi les cas d’échec et les confirmations nécessaires à chaque transition.
9. Le périmètre de préparation Amazon FBA
Distinguer appel disponible et automatisation complète
Le projet comportait des fonctions de consultation, de création et d’annulation d’ordres de préparation via GetFulfillmentOrder, CreateFulfillmentOrder et CancelFulfillmentOrder.
La création utilisait notamment une action de maintien en attente. Des parcours de préparation existaient, mais ils ne sont pas présentés ici comme une automatisation de production complète entre Fnac et FBA.
Cette distinction protège le sens du cas client. L’intégration API et le modèle de commande sont concrets ; une chaîne automatisée complète réclame en plus des règles d’expédition, des confirmations et une vérification de toutes les étapes. La page intégrateur Amazon FBA présente ce cadrage actuel sans attribuer rétroactivement ces capacités au projet historique.
10. Des règles qui dépassent le transport HTTP
Stocks, regroupements et indicateurs
Les traitements Sage préparaient des commandes et leurs regroupements selon les références et données de gestion. Les stocks conservaient réel, réservé et préparé plutôt qu’une quantité unique sans contexte.
Le pilotage multicanal exploitait les ventes et les marges par plateforme. Ces indicateurs utilisent le sens des données commerciales et des coûts ; leur fiabilité dépend donc aussi des règles métier et des rapprochements.
La valeur de l’intégrateur SI se situe à cet endroit : donner aux données un parcours cohérent entre ERP, plateformes et application, puis les rendre utilisables par la DSI et les métiers.
11. Appliquer cette démarche à un environnement actuel
Choisir l’interface selon le produit Sage
Le cas NetMinds utilise Sage 100c et une passerelle REST partenaire. Un projet actuel doit identifier le produit et le déploiement : Sage 100 France, Sage Partner Cloud, X3 ou un autre produit ne partagent pas automatiquement le même accès.
L’architecture peut s’appuyer sur une interface publiée, une passerelle existante ou un adaptateur dédié. Nous vérifions objets accessibles, droits, compatibilité et responsabilités avant de concevoir les appels.
Le guide d’intégration Sage 100 explique ces choix. Les fonctions modernes telles que supervision, rapprochement et reprises doivent être définies pour le nouveau projet, sans les attribuer automatiquement à la réalisation historique.
12. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
NetMinds reliait un ERP Sage 100c, une interface REST partenaire, des API Amazon et Fnac et un référentiel commun de produits et commandes. Ces composants soutenaient une application métier propre à Pixminds.
La complémentarité du partenaire ERP et de Dawap illustre une méthode d’intégration : accéder correctement au logiciel de gestion, comprendre ses données et construire les échanges utiles à l’entreprise.
La présentation métier de NetMinds raconte les usages. Pour relier votre propre ERP à des applications et canaux, notre offre d’intégration Sage au SI permet de cadrer le premier flux et les responsabilités. Pour les stocks, rapports, flux inbound ou commandes MCF actuels, le point d’entrée pertinent reste l’intégration Amazon FBA via SP-API.
