Le projet en un coup d’œil
La disponibilité d’un connecteur, les accès d’un compte et les flux autorisés formaient trois décisions différentes qu’il fallait rendre explicites.
Ciama sépare le catalogue global de la configuration propre à chaque compte, puis associe à chaque connexion une liste fermée de fonctions activables.
Les collectes planifiées partent des fonctions actives et revérifient connexion, identifiants et disponibilité avant de distribuer le travail.
Connecter une marketplace ne consiste pas seulement à conserver une clé API. Le même compte peut exploiter plusieurs canaux, une version précise de son ERP, une boutique directe et un entrepôt externe. Pour chaque source, il faut savoir si le connecteur est disponible, si les accès fonctionnent et quelles synchronisations doivent réellement être lancées.
Dawap a structuré dans Ciama un centre de contrôle des providers. Le catalogue décrit les familles et les versions disponibles ; chaque compte possède ensuite ses propres connexions, leur état de validation et leurs fonctions actives. Une synchronisation de commandes peut ainsi être ouverte sans activer automatiquement les offres, les stocks ou les achats.
La bascule vers ce fonctionnement centré sur le provider a été livrée le 12 mars 2026 pour les flux d’offres, puis étendue aux commandes, au catalogue, à l’e-commerce et aux entrepôts. Cette preuve illustre notre travail sur les connecteurs marketplace ERP : faire de la configuration une règle opérationnelle vérifiable, sans prétendre qu’un écran commun efface les différences entre Amazon, Mirakl, Shopify, Odoo ou un logisticien.
1. Ciama, un cockpit alimenté par des systèmes qui ne jouent pas le même rôle
Canaux de vente, référentiels, logistique et entrepôts devaient partager un point d’entrée sans être confondus
Les marketplaces et boutiques fournissent des commandes et des offres. L’ERP alimente le catalogue, les marques, les catégories, les stocks, les fournisseurs, les achats, les devis, les factures et les avoirs. Le PIM et le CRM portent encore d’autres responsabilités.
Une configuration unique du type « intégration active » aurait été trop pauvre. Elle n’aurait pas permis de distinguer un connecteur présent dans le catalogue, un provider momentanément indisponible, des identifiants invalides ou un flux volontairement coupé par le compte.
La difficulté venait aussi des accès. Odoo demande un hôte, une base, un utilisateur et une version ; Amazon s’appuie sur ses identifiants Selling Partner ; Mirakl, Fnac Darty, Cdiscount, Shippingbo, Wix et Shopify ont chacun leur combinaison de paramètres.
Le projet devait donc offrir un parcours cohérent sans inventer un formulaire universel. Le centre de contrôle guide la sélection, mais transmet ensuite les bons paramètres à l’adaptateur capable de comprendre le provider choisi.
2. Modéliser les décisions avant de généraliser l’interface
Un catalogue global, une connexion appartenant au compte et une capacité activable
Le premier arbitrage a consisté à séparer le provider de sa connexion. Amazon Europe ou Odoo existe une seule fois dans le catalogue de Ciama ; l’hôte, la base, les identifiants, le dernier test et l’activation appartiennent à la connexion du compte.
La version forme un niveau supplémentaire. Elle permet notamment d’associer une connexion Odoo à une génération précise et de sélectionner le client compatible, sans dupliquer tout le provider pour chaque évolution du logiciel.
Les fonctions ont ensuite été définies dans un catalogue fermé par famille. Une marketplace peut proposer commandes, offres et fenêtres Buy Box ; un ERP peut exposer onze synchronisations distinctes. Une clé étrangère à la famille est refusée.
Enfin, les traitements planifiés partent de ces fonctions actives. Avant d’envoyer un message, ils revérifient l’état de la connexion, la validité des accès, l’état du provider, sa disponibilité et la famille autorisée pour ce flux.
3. Avant le projet : « connecté » mélangeait plusieurs réalités
Disponibilité commerciale, validité technique et activation métier ne disent pas la même chose
Un connecteur peut être référencé sans être encore disponible. Il peut être disponible mais ne pas avoir d’accès renseignés pour un compte. Ses accès peuvent être présents mais ne plus fonctionner. Enfin, il peut être opérationnel alors qu’aucune synchronisation ne doit tourner.
Réduire ces états à une seule case active aurait créé des ambiguïtés dangereuses. L’équipe n’aurait pas su si une collecte absente venait du catalogue, d’une authentification, d’un choix fonctionnel ou d’une restriction propre au traitement.
Le même problème se posait au moment d’ajouter un provider. Afficher toutes les intégrations dans une longue liste ne disait rien de leur rôle et poussait à comparer des systèmes qui ne fournissent pas les mêmes données.
Le chantier a remplacé cette lecture binaire par une chaîne explicite. Chaque étape répond à une question : le provider est-il proposé, quelle version vise-t-on, le compte peut-il s’y connecter et quelle capacité souhaite-t-il exécuter ?
4. Créer un catalogue global sans y mélanger les secrets des comptes
Identifiant stable, nom, famille, moteur, disponibilité et informations d’affichage
Le provider porte une identité fonctionnelle stable. Son identifiant permet aux adaptateurs de reconnaître Amazon, Odoo, Shopify ou Shippingbo ; son nom et son logo donnent un repère lisible dans l’interface.
Deux états globaux sont conservés. « Actif » décide si le provider participe au catalogue courant. « Disponible » indique si la configuration peut être engagée. Un connecteur annoncé mais non livrable peut donc rester visible sans laisser croire qu’il est activable.
Le moteur optionnel affine la résolution lorsque plusieurs providers partagent une famille. Les compteurs de produits ou de commandes restent des propriétés de présentation du provider, distinctes de la connexion d’un vendeur particulier.
Ce niveau ne contient pas le mot de passe d’un client ni son hôte privé. Il décrit la capacité proposée par Ciama ; les données propres au compte sont enregistrées dans un objet séparé et toujours recherché avec ce compte.
5. Ranger les providers dans sept familles opérationnelles
Marketplace, e-commerce, ERP, CRM, PIM, logistique et entrepôt
L’écran d’ajout propose sept onglets. Cette classification ne sert pas seulement au rangement visuel : elle choisit la route de configuration, le vocabulaire et le catalogue de fonctions qui seront présentés ensuite.
Marketplace et e-commerce partagent certains objets, comme commandes et offres, mais restent deux familles. Cette séparation permet à Ciama de conserver la provenance d’une vente directe et de ne pas l’assimiler à un canal marketplace.
ERP, CRM et PIM représentent des référentiels ou des processus métier différents. Les familles logistique et entrepôt distinguent l’exécution d’une expédition de la connaissance des stocks, mouvements et rapports d’un lieu de stockage.
Un type inconnu ne reçoit aucune fonction par défaut. Cette absence volontaire empêche l’interface d’inventer des capacités génériques lorsqu’un nouveau provider n’a pas encore été cadré.
6. Associer une connexion à la version réellement ciblée
La compatibilité ne se réduit pas au nom de l’ERP
Chaque provider peut posséder plusieurs versions actives, ordonnées dans le catalogue. La connexion conserve la version retenue afin que le test et les lectures futures puissent sélectionner le client adapté.
Le parcours Odoo rend cette décision particulièrement visible. Il présente les versions 19, 18, 17 et 16 disponibles dans cet ordre, avec un repli vers la version la plus récente lorsque le catalogue utilise encore cette désignation.
Si aucun choix n’a été configuré pour un provider, le formulaire propose une valeur « latest ». Ce repli facilite l’affichage mais ne garantit pas qu’un adaptateur existe : le test peut encore répondre que la version n’est pas prise en charge.
Cette distinction évite une promesse trompeuse. Dire « compatible Odoo » sans version ne suffit pas ; la connexion conserve la variante utilisée et le service de test vérifie quel client déclare pouvoir la traiter.
7. Créer une connexion qui appartient au compte
Hôte, base, utilisateur, accès, validation et dates de contrôle réunis au même endroit
La connexion relie un compte, un provider et éventuellement sa version. Elle conserve aussi un nom, un hôte, une base ou identité distante, un utilisateur et les paramètres nécessaires à l’adaptateur.
Deux indicateurs décrivent son état : active ou non, puis identifiants valides ou non. La date du dernier test permet de distinguer une configuration enregistrée d’une connexion effectivement contrôlée à un instant donné.
Le service d’activation recherche d’abord la paire compte-provider. S’il ne la trouve pas, il crée un identifiant unique ; s’il la trouve, il actualise la même connexion avec la version, les accès et le résultat du nouveau test.
Cette règle évite de multiplier silencieusement les connexions actives au même provider pour un compte. Le modèle actuel privilégie une configuration courante par paire, ce qui doit être pris en compte si plusieurs boutiques du même service doivent être gérées demain.
8. N’afficher à l’ajout que les providers actifs de la famille choisie
Une sélection guidée avant la saisie des accès
L’écran reçoit la famille dans l’adresse et la ramène à marketplace si la valeur demandée ne fait pas partie des sept options. Il charge ensuite les providers actifs correspondants, classés par nom.
Chaque carte distingue trois situations : disponible, non disponible et déjà activée. Un provider non disponible reste identifiable mais son bouton de configuration est neutralisé. Une connexion existante ramène vers son parcours d’édition.
Pour l’e-commerce, la version actuelle limite explicitement la configuration à Wix et Shopify. Un autre provider e-commerce actif dans le catalogue n’est donc pas automatiquement activable depuis cet écran.
Les compteurs de l’en-tête indiquent le nombre total, disponible et activé dans la famille affichée. Ils décrivent la sélection courante, pas une mesure de santé de tous les flux du compte.
9. Présenter les bons champs pour chaque protocole
Un parcours commun autour de formulaires qui restent spécifiques
Le catalogue de formulaires résout les champs à partir de la famille, de l’identifiant, du moteur et de la version. Le parcours garde ainsi les mêmes étapes sans demander à Amazon des paramètres Odoo ni à Shopify une base ERP.
Odoo utilise l’hôte, la base, l’utilisateur ou son identifiant, puis un mot de passe ou une clé API. Shippingbo ajoute notamment URL, client, secret, jeton de renouvellement, utilisateur API et identifiant d’application.
Amazon, Cdiscount, Fnac Darty et Mirakl construisent chacun une charge d’accès adaptée. Wix emploie l’identifiant de boutique et la clé API ; Shopify normalise le domaine de boutique et utilise les identifiants de son application.
Les champs marqués obligatoires sont contrôlés avant le test comme avant l’activation. Le message liste ceux qui manquent au lieu d’envoyer une requête distante dont l’échec serait moins compréhensible.
10. Imposer un test avant d’ouvrir l’activation
Une première validation dans le parcours, puis une seconde au moment d’enregistrer
Le bouton de test construit une connexion temporaire en mémoire avec les paramètres saisis. Un service parcourt les adaptateurs connus et confie la vérification au premier qui annonce prendre en charge ce provider et cette version.
Shippingbo, Amazon, Cdiscount, Fnac Darty, Mirakl, Wix et Shopify possèdent des clients dédiés dans cette chaîne. Les clients ERP compatibles sont également parcourus et peuvent retourner réussite, message d’erreur et temps de réponse.
Lorsque le test réussit, la session autorise l’étape d’activation et l’interface peut afficher la latence renvoyée. Un échec retire cette autorisation et restitue le message reçu sans enregistrer la connexion comme valide.
Le garde-fou est doublé : même après le test d’écran, le service d’activation relance la vérification avant de créer ou mettre à jour la connexion. Une autorisation de session ne suffit donc pas à contourner un contrôle distant devenu négatif.
11. Enregistrer uniquement une configuration que le provider accepte encore
Une mise à jour de l’existant plutôt qu’une nouvelle ligne à chaque changement
L’activation exige le compte, le provider, l’hôte, l’identité distante et au moins une forme d’accès reconnue. Elle vérifie ensuite l’existence du provider et résout l’éventuelle version demandée.
Si le nouveau test échoue, le service s’arrête avant l’écriture. S’il réussit, la connexion reçoit l’état actif, la validation des identifiants, la date du test et sa date de mise à jour.
Une configuration existante est actualisée sur place. Cette décision conserve un identifiant de connexion stable pour les capacités, les traitements planifiés et les objets qui la référencent.
Après l’activation, certains providers synchronisent aussi leur représentation en canal. Cette étape reste spécifique : le modèle de connexion n’affirme pas que toute intégration crée automatiquement les mêmes objets métier.
12. Détecter les participations Amazon après authentification
Réutiliser les accès sans confondre les places de marché régionales
Une authentification Amazon réussie permet d’interroger les participations du vendeur. Ciama rapproche les identifiants retournés de son catalogue de providers régionaux et indique ceux qui sont déjà connectés ou encore éligibles.
L’utilisateur peut demander l’activation groupée des providers Amazon détectés. Chaque candidat est néanmoins revérifié : il doit être actif, disponible, appartenir à la bonne famille et ne pas posséder déjà une connexion pour le compte.
Les mêmes paramètres d’accès sont transmis aux régions retenues, mais chacune obtient sa propre connexion et son identifiant de provider. La réussite de l’une ne transforme pas automatiquement toutes les autres en connexions actives.
Le résultat distingue activations, éléments ignorés et échecs. Ce parcours réduit la ressaisie pour un vendeur européen tout en conservant une frontière explicite entre les différents marchés Amazon.
13. Activer les synchronisations séparément
Le connecteur donne accès à des capacités, il ne les déclenche pas toutes par défaut
Une marketplace propose la synchronisation des commandes, des offres et des fenêtres Buy Box. Un site e-commerce propose commandes et offres. Ces clés communes facilitent les traitements qui acceptent les deux familles.
L’ERP possède onze capacités : produits, marques, catégories, tags, fournisseurs, achats fournisseurs, commandes et devis B2B, stocks, factures et avoirs. Elles peuvent être ouvertes indépendamment selon le périmètre du compte.
Le CRM propose clients et opportunités ; le PIM, produits, catégories et tags ; la logistique, préparations et stocks. L’entrepôt possède ses propres stocks, préparations et rapports afin de ne pas mélanger une donnée par lieu avec un stock ERP global.
Chaque état est enregistré pour une paire connexion-fonction unique. Couper les offres ne supprime donc pas les accès au provider et ne désactive pas nécessairement la collecte des commandes.
14. Refuser une capacité étrangère au provider ou au compte
Propriété, liste autorisée et jeton de formulaire vérifiés avant chaque changement
Le point d’entrée recharge la connexion avec son identifiant et le compte connecté. Une connexion inconnue ou appartenant à un autre compte ne peut pas être modifiée depuis ce parcours.
La requête asynchrone doit fournir un jeton CSRF valide, une clé de fonction et l’état demandé. Une charge illisible ou un jeton incorrect reçoit une erreur sans modifier la configuration.
Le service relit ensuite le provider et reconstruit les clés autorisées à partir de sa famille. Une clé inventée, ou valable seulement pour une autre famille, est refusée avant l’écriture.
Activer crée l’état s’il n’existe pas ; désactiver le retire. La réponse renvoie la clé et l’état enregistrés afin que l’interrupteur reflète le résultat du serveur, pas seulement le clic local.
15. Lier Amazon FBA Europe à un entrepôt avant d’activer ses flux
Une contrainte métier ajoutée au changement de fonction
Les capacités d’un provider d’entrepôt ne peuvent pas alimenter un lieu abstrait. Pour Amazon FBA Europe, le premier basculement vérifie donc qu’un entrepôt du compte est relié à la connexion.
Si aucun lien n’existe, l’interface demande de choisir un entrepôt disponible ou d’en créer un avec l’identifiant suggéré. Le serveur revérifie que le lieu choisi appartient bien au compte.
Un entrepôt déjà lié à une autre connexion ne peut pas être réaffecté silencieusement. L’activation est refusée et l’utilisateur doit résoudre cette relation avant de poursuivre.
Cette exception montre pourquoi un hub ne peut pas se contenter d’interrupteurs génériques. Certaines capacités nécessitent une décision métier préalable ; ici, la destination exacte des stocks et rapports FBA.
16. Faire de la fonction active le point de départ des traitements planifiés
La configuration n’est utile que si l’exécution la respecte
Les collectes planifiées de commandes cherchent les états « orders_sync » actifs. Celles des offres cherchent « offers_sync » ; produits, tags, fournisseurs, achats et entrepôts utilisent leurs propres clés.
Pour chaque état, le traitement retrouve la connexion et le provider. Il ignore la branche si la connexion est inactive, si les accès ne sont pas marqués valides, ou si le provider global est inactif ou indisponible.
Les commandes et offres n’acceptent ensuite que les familles marketplace et e-commerce. Cette vérification d’exécution complète le catalogue d’interface et évite qu’une clé techniquement présente déclenche un parcours hors périmètre.
Lorsque toutes les conditions sont réunies, la commande crée une trace de supervision puis distribue un message contenant la connexion, le provider, sa version et la période éventuelle. Le journal des synchronisations Ciama prend alors le relais.
17. Réunir les connexions actives dans une vue de contrôle
Provider, famille, version, hôte et date de mise à jour visibles avant l’action
La page principale charge les connexions actives du compte, puis retire celles dont le provider global n’est plus actif. Elle les classe de la plus récemment mise à jour à la plus ancienne.
Chaque ligne montre le logo, le nom, la famille, l’état, la version, l’hôte et la dernière modification. Deux actions ouvrent la configuration des capacités ou l’édition des accès API.
L’en-tête compte le nombre total de connexions actives ainsi que les familles marketplace et e-commerce. Ces chiffres décrivent la pile configurée ; ils ne remplacent pas la supervision des traitements.
La colonne de dernier succès existe visuellement mais reste vide dans cette version. La fiche ne la présente donc pas comme une mesure disponible : la preuve d’exécution appartient au journal dédié.
18. Assumer ce que le centre de contrôle ne garantit pas encore
Une interface cohérente ne transforme pas tous les providers en adaptateurs interchangeables
Le catalogue de capacités est défini par famille, pas individuellement pour chaque provider. Une fonction peut donc apparaître pour un connecteur alors que son adaptateur métier n’est pas encore implémenté. Les traitements doivent conserver leurs contrôles spécifiques.
Les tests n’ont pas tous la même profondeur. Les clients dédiés peuvent interroger le service distant ; pour un provider marketplace sans adaptateur de test reconnu, le repli actuel valide seulement la présence d’une clé ou d’un couple utilisateur-mot de passe.
Le centre de contrôle ne mesure ni fraîcheur attendue, ni retard, ni dernier résultat fiable. Il ne relance pas une collecte en échec et ne choisit pas automatiquement une fonction à partir du volume de ventes.
Enfin, le modèle courant vise une connexion par compte et provider. La gestion simultanée de plusieurs boutiques du même provider demanderait un cadrage supplémentaire sur leur identité, leurs capacités et leur sélection dans chaque traitement.
19. Ce qui change après la livraison
Une intégration devient une suite de décisions lisibles et contrôlables
L’équipe sait d’abord si le provider fait partie du catalogue actif et s’il est déclaré disponible. Elle peut ensuite retrouver la version et la connexion propres au compte sans chercher ces informations dans chaque collecteur.
Le test préalable transforme une saisie d’accès en décision explicite. Une configuration invalide s’arrête avant l’enregistrement actif ; une modification réussie actualise la même connexion et conserve les références utilisées par les capacités.
Les interrupteurs réduisent le périmètre au besoin réel. Un vendeur peut collecter les commandes sans ouvrir les offres, ou alimenter les produits depuis l’ERP sans lancer immédiatement les achats et factures.
Enfin, les traitements planifiés consomment cette configuration commune. La connexion marketplace ERP n’est plus une information dispersée : elle devient une condition vérifiée avant chaque distribution.
20. Le scénario terrain qui résume le projet
Brancher Amazon et Odoo sans lancer tous les flux en même temps
Un nouveau compte choisit d’abord Amazon dans la famille marketplace. Il renseigne ses paramètres Selling Partner, teste l’authentification et obtient les participations européennes associées à son vendeur.
Il active les régions utiles, puis ouvre seulement la collecte des commandes. Le traitement planifié ignore les offres tant que « offers_sync » reste coupé, même si la connexion Amazon est valide et active.
Le même compte configure ensuite Odoo 19. Le test sélectionne le client ERP compatible avec cette version. Produits, marques, catégories et stocks sont activés ; fournisseurs, achats et factures restent fermés jusqu’au prochain lot.
À chaque planification, Ciama repart des capacités actives et revérifie les connexions. Le compte peut ainsi déployer son périmètre progressivement sans confondre « accès enregistrés » avec « toutes les données synchronisées ».
21. Faire évoluer le socle par tranches vérifiables
Du provider-first aux commandes, boutiques, entrepôts et fenêtres Buy Box
La première bascule a remplacé les anciens déclenchements d’offres par une sélection centrée sur la connexion provider. Le lot a posé la règle qui relie capacité active et traitement distribué.
Les jours suivants ont étendu cette convention à Shopify, aux commandes et aux entrepôts. Les formulaires et adaptateurs ont été consolidés avec leurs paramètres spécifiques au lieu d’élargir un bloc générique difficile à valider.
Le centre de réglages a ensuite été découpé en contrôleurs spécialisés pour isoler recherche, ajout, vue, édition des accès et changement de capacité. La fonction Buy Box a rejoint le même mécanisme en août 2026.
Cette progression explique la valeur actuelle du socle : il peut accueillir de nouvelles capacités à condition de définir leur clé, leur famille, leur adaptateur et leur règle d’exécution, puis de vérifier le parcours complet.
22. Prolonger la connexion jusqu’à la donnée exploitable
Trois preuves pour suivre l’activation, la collecte et le résultat métier
Le projet Shopify et Wix dans le cockpit Ciama montre ce qui se passe après la configuration : les API propres à chaque boutique deviennent commandes, lignes et offres dans un modèle de vente commun.
Le journal des synchronisations suit ensuite chaque traitement distribué avec son état, sa progression, ses volumes et ses sous-exécutions.
La fiche commandes B2B Odoo détaille enfin la transformation d’une connexion ERP versionnée en données commerciales et financières consultables.
Ces trois étapes forment la chaîne de valeur : autoriser précisément le flux, observer son exécution puis rendre son résultat utile au métier. C’est cette continuité que Dawap construit dans ses projets de connecteurs marketplace ERP.
23. Conclusion
Un bon hub ne masque pas les différences : il rend chaque décision explicite
Le projet ne prétend pas qu’Amazon, Odoo, Shopify et un entrepôt FBA parlent le même langage. Il leur donne un cadre commun : une identité de provider, une version éventuelle, une connexion appartenant au compte et des capacités choisies séparément.
Le test avant activation, la validation de propriété, la liste fermée des fonctions et les contrôles répétés au lancement réduisent les états ambigus. L’équipe sait ce qui est configuré, ce qui est autorisé et pourquoi une collecte peut être ignorée.
Pour construire cette chaîne sur vos propres canaux, notre accompagnement Connecteurs marketplace ERP part du système source, des accès, des versions et des flux réellement utiles avant d’industrialiser leur exécution et leur supervision.
