Le projet en un coup d’œil
Chaque boutique expose ses produits, variantes, prix, stocks et commandes selon ses propres conventions. Origami possède en parallèle ses vendeurs, produits, offres et commandes.
Le hub normalise Shopify, PrestaShop et WooCommerce, associe leurs variantes aux offres Origami et distribue les traitements longs dans des files spécialisées.
Une commande Origami peut être contrôlée, créée dans la boutique du vendeur puis suivie jusqu’au transporteur, sans perdre les écarts ni les erreurs de configuration.
Le 14 décembre 2022, Shopetic ouvre un chantier séparé de son frontend acheteur : construire le poste de contrôle des échanges entre la marketplace Origami et les boutiques de ses vendeurs. Dix jours plus tard, un premier catalogue Shopify est importé. Le 26 décembre, produits Origami, environnement de production, planification et accès sécurisé commencent déjà à former une application opérateur.
Le sujet dépasse vite la simple synchronisation. Un produit Shopify, PrestaShop ou WooCommerce ne possède pas forcément les mêmes identifiants, variantes, prix, taxes, images ou statuts que l’offre publiée dans Origami. Avant de pousser un stock, un prix ou une commande, le hub doit savoir quelle donnée correspond à quelle réalité marchande et expliquer pourquoi une relation manque.
Pendant sept mois, Dawap transforme ce socle en chaîne bidirectionnelle : collecte des catalogues vendeurs, normalisation, rapprochement des offres, import des objets Origami, diffusion du stock et du prix, création des commandes dans la boutique concernée, lecture de leur exécution et remontée du suivi. Cette réalisation incarne notre travail d’intégration du SI opérateur marketplace.
Cette progression distingue ce qui est automatisé, ce qui exige une validation opérateur, ce qui est supervisé et ce qui a été ajouté plus tard pour répondre à une nouvelle règle métier. Le hub devient une application d’exploitation où chaque passage de relais peut être compris et repris.
1. Shopetic, entre moteur marketplace et boutiques vendeurs
Faire circuler catalogue et commandes sans effacer les différences de chaque source
Shopetic dispose déjà d’un frontend transactionnel sur Origami. Mais la vie d’une marketplace ne s’arrête pas au paiement acheteur. Les vendeurs conservent leurs outils e-commerce, leurs références de variantes, leurs règles de taxe et leur propre exécution logistique.
Le catalogue doit donc circuler dans un sens : boutique vendeur vers hub, puis offre correspondante vers Origami. La commande emprunte le sens inverse : Origami vers hub, puis création dans Shopify, PrestaShop ou WooCommerce afin que le vendeur travaille dans son environnement habituel.
Entre ces deux mouvements se trouve le risque principal : une offre sans variante associée, un SKU incohérent, un EAN absent, une TVA impossible à appliquer, un vendeur non configuré ou une commande dont une ligne ne peut pas être recréée. Le hub rend ces états consultables au lieu de les masquer derrière une synchronisation globale.
Shopetic veut aussi suivre la plateforme par vendeur, catégorie, produit, offre et commande. Le même poste de contrôle réunit donc recherche, détail, historique de prix et de stock, statistiques, traitements, erreurs de flux et actions manuelles lorsque l’automatisme ne peut pas décider seul.
2. Construire la boucle complète par responsabilités successives
Catalogue, rapprochement, offres, commandes puis règles métier spécialisées
La première séquence, en décembre 2022, pose les frontières : entités vendeurs et marketplace séparées, contrats Origami, connecteur Shopify, import des produits et variantes, accès authentifié, planification et premières vues de comparaison. L’application devient exploitable avant d’accumuler les connecteurs.
De fin décembre à janvier, le hub ajoute vendeurs, offres, commandes, graphiques, images, PIM, PrestaShop et historique de stock ou de prix. Le rapprochement entre variante vendeur et offre marketplace devient le point central, car il conditionne les écritures suivantes.
Mars et avril élargissent le dispositif : plusieurs vendeurs Shopify, WooCommerce, validation du vendeur avant collecte, commandes dans les deux sens, API protégée, cache, files RabbitMQ, suivi des échanges et vues dédiées aux offres non rapprochées ou périmées. Les scénarios de test progressent en même temps que les contrats externes.
Mai et juin introduisent le calcul puis le crédit des gouttes d’eau Lilo à partir des commandes. En juillet, le mode de secours PrestaShop et la distinction des prix taxés ou non taxés sur WooCommerce montrent une dernière étape importante : la plateforme ne gagne pas seulement des fonctions, elle apprend à gérer les différences et les incidents propres aux vendeurs.
3. D’un exemple d’intégration à un outil de production en douze jours
Le hub prend forme entre le 14 et le 26 décembre 2022
Le premier changement initialise une application Symfony 6 distincte. Dès le lendemain, un cas de lecture interroge un produit Origami au travers d’un contrat. La séparation entre logique métier et appel distant est donc présente avant la première interface opérateur.
Le 23 décembre, le projet gagne ses premières données persistées et l’ajout d’un vendeur. Le 24, le catalogue du vendeur Zajmahal est importé depuis Shopify avec produits, variantes, options et images. Le 25, les variantes sont synchronisées et un back-office authentifié les rend consultables.
Le 26 décembre concentre un changement d’échelle : import des produits Origami, images de production, configuration Docker, Nginx et PHP, chaîne d’intégration, planification des collectes, connexion et rôles. La comparaison entre données vendeur et marketplace apparaît dans la même fenêtre.
Ces douze premiers jours servent à vérifier tôt la boucle la plus risquée : lire deux sources différentes, les conserver séparément et donner à l’opérateur une vue qui permette de commencer leur rapprochement.
4. Faire du hub une mémoire opérationnelle, pas un simple relais
Conserver les états intermédiaires et les décisions qui rendent une synchronisation explicable
Un relais sans mémoire transmettrait les données d’une API à l’autre et perdrait le contexte dès qu’un appel échoue. Shopetic avait besoin de conserver le vendeur, son type d’intégration, chaque produit et variante collectés, l’offre Origami correspondante et l’historique des écritures.
Le hub doit aussi différencier l’absence de donnée d’une décision humaine. Une variante peut être nouvelle, non traitée, rapprochée, laissée sans relation ou explicitement ignorée par l’opérateur. Ces états ne conduisent pas à la même action automatique.
Le troisième objectif porte sur la commande. Avant de la créer chez le vendeur, chaque ligne doit retrouver une offre puis un identifiant de variante valide dans la boutique cible. L’adresse, les montants, la livraison et le statut payé doivent ensuite être traduits selon le connecteur.
Enfin, les traitements doivent pouvoir avancer indépendamment des pages web. Importer une période de produits, rafraîchir les offres, calculer une statistique ou interroger une boutique vendeur ne doit pas immobiliser le poste de contrôle.
5. Garder séparés CRM vendeur, marketplace et PIM
Trois lectures du catalogue pour trois responsabilités différentes
Le domaine CRM enregistre les vendeurs, leurs types d’intégration, leurs collectes, produits, options, variantes et commandes. C’est la photographie de ce que chaque boutique expose, avec ses identifiants et ses conventions propres.
Le domaine marketplace représente Origami : vendeurs, produits, variantes, offres, catégories, attributs, clients, commandes, avis, tickets et taxes. Une offre peut évoluer indépendamment de la variante source tant que leur relation reste connue.
Le PIM fournit une vue supplémentaire des produits et des marques. Son import périodique depuis la marketplace soutient les recherches et regroupements opérateur sans obliger l’interface à recomposer chaque écran depuis les réponses externes.
Cette séparation est importante lors d’un incident. Une valeur correcte chez le vendeur mais ancienne dans Origami n’est pas une erreur de catalogue source. Une offre non rapprochée n’est pas forcément un produit invalide. Le hub permet de localiser la rupture avant de choisir la correction.
6. Parler Shopify, PrestaShop et WooCommerce sans les réduire au même format brut
Trois collecteurs de catalogue et trois chemins de commande
Le connecteur Shopify parcourt les produits par pages de 250 et accepte une date minimale de mise à jour. Il collecte produit, image principale, images secondaires, options et variantes, puis reconstruit un titre de variante et choisit l’image la plus précise disponible.
PrestaShop demande davantage de paramètres : langue, pays, devise, client, statut de commande cible et transporteur par défaut. Le collecteur traite produits standards et combinaisons, résout leurs valeurs d’option, leurs prix, leurs stocks, leur TVA et leurs images.
WooCommerce rejoint le projet au printemps 2023. Son authentification, son client, ses identifiants de variante et son traitement des prix taxés ou non taxés possèdent leurs propres règles. Le dernier correctif de juillet porte précisément sur cette distinction fiscale.
Le hub produit ensuite une variante commune, mais ne supprime pas les données sources. Les représentations Shopify ou PrestaShop restent accessibles pour le diagnostic, tandis que l’opérateur travaille sur des champs comparables : identifiant, SKU, EAN, titre, prix, stock, état, options et date de synchronisation.
7. Transformer chaque catalogue en variantes comparables
Produits, options, images, prix et stock réunis sans perdre l’origine
Une boutique peut porter l’information au niveau du produit, de la variante ou d’une combinaison. Le collecteur reconstitue donc le parent, les options et les valeurs nécessaires avant d’écrire une variante vendeur commune.
Le titre complet combine le produit et, lorsque c’est nécessaire, la variante. L’image de variante remplace l’image par défaut lorsqu’elle existe. Le statut actif dépend des conventions de la plateforme source ; le stock et le prix sont convertis vers des types homogènes.
Chaque collecte accepte une fenêtre temporelle. Une récupération récente limite le volume courant, tandis qu’une reprise plus profonde peut reconstruire les éléments manqués. Le processus enregistre son état afin que l’interface distingue une collecte terminée, en attente ou en erreur.
La normalisation ne décide pas encore qu’une variante correspond à une offre Origami. Elle prépare une base comparable. Cette retenue empêche qu’une ressemblance de titre ou une valeur vide devienne automatiquement une relation marchande irréversible.
8. Ne lancer les collectes automatiques que pour un vendeur prêt
Type d’intégration, URL, jetons et validation opérateur contrôlés avant le flux
Le vendeur porte son type d’intégration et les paramètres propres à sa boutique. Avant un appel Shopify, le hub vérifie une URL valide et la présence du jeton. PrestaShop exige également son URL et sa clé ; WooCommerce demande URL, clé consommateur et secret.
À partir de mars 2023, la collecte automatique tient aussi compte d’un indicateur de validation du vendeur. Un compte en cours de configuration peut être visible dans le CRM sans être immédiatement aspiré par la planification générale.
La fiche vendeur rassemble coordonnées, configuration, produits, variantes, offres Origami et commandes. Des vues spécialisées montrent les variantes actives, désactivées, rapprochées, sans relation, non traitées ou ignorées par l’opérateur.
En juillet, PrestaShop gagne un mode de secours activable par vendeur. Le connecteur principal reste la voie normale, mais l’opérateur peut choisir une stratégie alternative lorsque la réponse standard ne convient pas à une boutique particulière.
9. Importer Origami par familles plutôt que par copie globale
Vendeurs, produits, variantes, offres, catégories et commandes possèdent leurs propres cadences
Le 26 décembre, les produits Origami entrent dans le hub. Les variantes suivent le 27, puis les vendeurs et les offres le 28 et le 29. Les commandes apparaissent à la fin du mois. Chaque famille possède un contrat de recherche, un mapping et une persistance dédiés.
L’import accepte une durée de profondeur. En production, produits et offres récents sont rafraîchis toutes les deux minutes sur cinq heures, tandis qu’un passage complet intervient toutes les six heures. Les vendeurs sont relus toutes les cinq minutes et les commandes récentes chaque minute.
Les objets plus spécialisés — catégories, attributs, clients, avis ou tickets — sont ajoutés ensuite au fil des besoins. Ils enrichissent les écrans et l’API sans transformer chaque collecte en une opération monolithique.
Le jeton opérateur Origami peut être rafraîchi par un traitement dédié. L’authentification du maker reste ainsi une responsabilité technique séparée de l’identité des utilisateurs du back-office et des secrets propres aux boutiques vendeurs.
10. Associer une offre Origami à la bonne variante vendeur
SKU vendeur, EAN et titres forment une hiérarchie de candidats contrôlables
Le rapprochement le plus direct utilise la référence vendeur portée par l’offre et l’identifiant de variante de la boutique. Lorsqu’ils coïncident dans le périmètre du bon vendeur, la relation peut être construite sans ambiguïté.
Le hub recherche aussi l’EAN de la variante marketplace et, selon les données disponibles, la référence fournisseur. Les titres simple et complet servent à produire d’autres candidats. Une similitude textuelle peut alimenter le cache de rapprochement sans être présentée comme une identité certaine.
L’opérateur dispose d’une page dédiée pour une offre sans relation. Il peut comparer les candidats, établir le mapping, le retirer, régénérer le cache ou marquer une variante source comme ignorée. L’automatisme accélère la recherche ; la décision reste visible.
Ce lien devient la clé des flux aval. Il permet de lire le stock et le prix de la bonne variante, puis de convertir une ligne de commande Origami vers l’identifiant attendu par Shopify, PrestaShop ou WooCommerce.
11. Pousser stock, prix et état seulement lorsque les préconditions sont réunies
Trois écritures séparées, disponibles en manuel comme en traitement planifié
Le stock, le prix et l’état actif possèdent chacun leur cas d’usage, leur message et leur gestionnaire. Une modification peut être déclenchée depuis la fiche de l’offre ou sélectionnée par une commande planifiée à partir du flux vendeur.
Le prix ne part pas si le taux de TVA de l’offre manque. Cette règle évite de présenter une valeur TTC comme une simple copie numérique. Le correctif WooCommerce de juillet confirme l’importance de distinguer les conventions fiscales de la boutique source.
La production prévoit un passage toutes les trente minutes pour le stock et le prix. La diffusion automatique de l’état existe mais reste désactivée dans la planification finale. La page publique distingue donc une capacité construite d’une automatisation effectivement programmée.
L’offre conserve aussi un historique de prix et de stock. Les écrans dédiés aux valeurs périmées permettent de repérer une absence de rafraîchissement, sans assimiler automatiquement l’ancienneté à une erreur du vendeur.
12. Recréer la commande marketplace dans la boutique du bon vendeur
Une validation ligne par ligne avant toute écriture externe
Les commandes Origami sont importées avec leur vendeur, leurs lignes, adresses, livraison, montants et état. Le hub refuse d’intégrer une commande déjà rattachée à un identifiant de commande vendeur.
Chaque ligne doit posséder une offre associée, une variante vendeur rapprochée et l’identifiant externe attendu par la boutique. Le vendeur doit lui-même être lié et disposer de la configuration nécessaire : client Shopify, client WooCommerce ou client PrestaShop selon le connecteur.
Une fois ces préconditions réunies, le connecteur construit la commande. Pour Shopify, le payload reprend adresses de livraison et facturation, frais de port, prix total, statut payé, identifiant de variante, quantité et prix unitaire. Les deux autres plateformes suivent leurs contrats propres.
L’intégration peut être demandée manuellement ou sélectionnée par la tâche automatique exécutée chaque minute. Le résultat conserve l’identifiant vendeur ou un message d’erreur de configuration, ce qui permet de reprendre une commande sans perdre son contexte Origami.
13. Relire l’exécution vendeur jusqu’au transporteur
Statut, numéro, société et URL de suivi reviennent dans le hub
Créer la commande dans la boutique n’achève pas la boucle. Toutes les deux minutes, le hub sélectionne les commandes à relire côté vendeur. Le connecteur adapté interroge l’objet distant à partir de l’identifiant conservé lors de l’intégration.
Dans Shopify, le statut d’exécution distingue l’attente d’une commande remplie. Lorsque les informations existent, le premier fulfillment fournit numéro de suivi, transporteur et URL. Les adaptateurs PrestaShop et WooCommerce transforment leurs propres réponses vers le même objet commun.
Le hub met à jour l’état vendeur et les informations de transport sans écraser la commande marketplace. Cette coexistence permet de comparer l’avancement connu dans les deux systèmes et d’isoler un décalage.
Trois webhooks Integromat peuvent signaler qu’une commande est entrée dans le hub, qu’elle a été créée chez le vendeur ou que son statut vendeur a changé. Ils transmettent les identifiants et informations utiles à l’exploitation sans remplacer la mémoire interne.
14. Naviguer du vendeur à l’offre puis à la commande
Des vues de détail reliées plutôt qu’un tableau de bord unique et opaque
Le menu sépare CRM, marketplace, PIM, monitoring, statistiques et configuration. La recherche vendeur mène à une fiche qui rassemble ses paramètres, produits, variantes, processus de collecte, offres Origami et commandes.
Une offre montre le produit et la variante marketplace, son vendeur, le mapping CRM, les valeurs de stock et prix, leurs historiques et les actions d’écriture. Une commande expose ses lignes et les relations nécessaires à sa création dans la boutique.
Des raccourcis relient les ressources plutôt que de recopier leurs informations. L’opérateur peut passer d’un vendeur à ses offres actives, en attente, épuisées, désactivées, rapprochées ou sans relation, puis ouvrir la variante source qui explique la donnée.
Cette navigation répond à une question concrète : où agir ? Modifier la configuration du vendeur, relancer sa collecte, corriger une variante, créer un mapping, rafraîchir Origami ou reprendre une commande sont des responsabilités distinctes.
15. Transformer les exceptions en files de travail opérateur
Filtres, tris, vues spécialisées et export des variantes
Les listes ne se limitent pas à une recherche libre. Vendeur, type d’intégration, état du processus, marque, catégorie, stock, prix, EAN, date de synchronisation et statut de mapping servent à isoler un sous-ensemble exploitable.
Les variantes CRM possèdent notamment des vues rapprochées, sans relation, non traitées et ignorées. Les offres Origami ont leurs écrans sans mapping, stock périmé, prix périmé ou état périmé. Les commandes peuvent être filtrées par vendeur et état.
Une recherche complète de variantes est mise en cache puis régénérée dans une file RabbitMQ. Un export CSV permet de travailler sur le résultat sans perdre les mêmes critères de sélection.
Une anomalie devient ainsi une population nommée, filtrable et reliée à ses objets sources. L’équipe passe d’une impression dispersée entre plusieurs interfaces à une liste d’exceptions qu’elle peut examiner et reprendre.
16. Exposer 30 routes API sans ouvrir le back-office
CRM et marketplace consultables par contrats protégés
Trente contrôleurs API couvrent vendeurs, types d’intégration, processus de collecte, produits, options, variantes, offres, historiques d’offre, produits marketplace, commandes, lignes de commande, catégories et configuration des gouttes d’eau.
Les recherches utilisent pagination, filtres et tris comparables aux écrans. Les vues par identifiant interne ou externe permettent à un outil autorisé de retrouver la ressource exacte. Une route PATCH modifie l’état « ignoré par l’opérateur » d’une variante.
Le firewall `/api` fonctionne sans session et utilise un authentificateur par jeton. Les pages `/app` exigent un rôle utilisateur ; l’administration demande un rôle plus élevé. La documentation API possède son propre point d’entrée.
Cette frontière permet de raccorder des outils d’exploitation sans donner accès à l’interface complète. Les droits restent concentrés dans les règles d’accès de l’application et les échanges machine utilisent leur authentification dédiée.
17. Distribuer le travail dans 13 files spécialisées
Une file par responsabilité plutôt qu’un traitement asynchrone indistinct
Quatre files concernent le CRM : collecte du flux vendeur, lecture des commandes vendeurs, génération de la recherche vendeurs et génération de la recherche complète des variantes. Quatre autres importent produits, commandes, offres et vendeurs depuis Origami.
Trois files diffusent stock, prix et état d’une offre. Une autre régénère les candidats de mapping entre offre et variante CRM. La dernière calcule les champs statistiques des catégories. Une file d’échec Doctrine complète ces transports RabbitMQ.
Chaque file possède son échange et son consommateur supervisé. Les imports volumineux peuvent découper leur pagination en messages, tandis qu’une action manuelle réutilise le même cas d’usage que le traitement planifié.
La séparation facilite le diagnostic : une saturation de collecte vendeur n’a pas à masquer un problème de diffusion de prix. Elle permet aussi d’ajuster les consommateurs par famille sans confondre toutes les opérations dans une seule file.
18. Associer une cadence différente à chaque fraîcheur métier
De la minute au passage complet toutes les six heures
Les nouvelles commandes Origami et leurs acheteurs sont relus chaque minute sur une journée. Les commandes vendeurs sont consultées toutes les deux minutes et les commandes prêtes peuvent être intégrées dans la boutique cible au même rythme court.
Les produits récents couvrant cinq heures sont importés toutes les deux minutes ; les offres sur la même profondeur suivent également toutes les deux minutes. Un passage sans fenêtre relit produits et offres toutes les six heures.
Les vendeurs Origami sont actualisés toutes les cinq minutes, le rapprochement par SKU toutes les cinq minutes, les statistiques de catégories toutes les trente minutes et le PIM toutes les vingt minutes. Les catalogues boutiques sont collectés toutes les trois heures dans la configuration finale.
Ces fréquences forment un plan de travail adapté à la fraîcheur attendue de chaque donnée. Si une file reprend, qu’une API distante devient indisponible ou qu’un vendeur est mal configuré, les états conservés par le hub rendent le retard visible et localisable.
19. Suivre les échanges et les tendances sans confondre mesure et décision
Historique des offres, top vendeurs et catégories reliés aux objets opérationnels
Dès décembre 2022, le tableau de bord présente des tendances annuelles, des offres visibles et des vendeurs. Les fiches d’offre enregistrent l’évolution du stock et du prix ; les statistiques de catégories agrègent ensuite les ventes et les relations utiles.
Une recherche dédiée aux échanges marketplace apparaît en avril 2023. Elle permet de consulter les opérations techniques et leur état sans parcourir les journaux serveur. Les processus vendeurs possèdent eux aussi une liste filtrable.
Les tableaux de bord produit et vendeur fournissent des points d’entrée vers les populations qui demandent une action. Une statistique n’est utile ici que si l’opérateur peut revenir à l’offre, au vendeur, à la catégorie ou à la commande qui l’explique.
Le pilotage reste relié au travail opérationnel : une mesure ramène vers la ressource qui l’explique et vers l’action disponible. Les tendances servent ainsi de point d’entrée vers une offre, un vendeur, une catégorie ou une commande concrète.
20. Maintenir 268 scénarios automatisés autour des contrats et des parcours
245 scénarios d’intégration et 23 scénarios applicatifs actifs
Le corpus final contient 77 fichiers d’intégration actifs et 15 fichiers applicatifs actifs. Ils totalisent 268 méthodes de test : 245 pour les contrats, accès aux données et services, puis 23 pour les contrôleurs et réponses de l’application.
Les tests Origami couvrent notamment recherches et collectes de vendeurs, produits, variantes, offres, commandes, clients, catégories, attributs, avis et tickets. Les connecteurs Shopify et PrestaShop possèdent aussi des scénarios de collecte.
Les écritures d’offre sont vérifiées séparément pour le stock, le prix et l’état. Les imports de produits, offres, vendeurs et commandes contrôlent le mapping des données avant les vues et commandes d’exploitation.
Ce corpus accompagne les frontières les plus fragiles du hub : formats externes, persistance, règles de validation et réponses web. Les parcours peuvent évoluer tout en conservant des contrôles sur leurs contrats essentiels.
21. Transformer une commande en gouttes d’eau Lilo sans créditer deux fois
Une règle d’affiliation ajoutée après le socle catalogue et commandes
À partir de mai 2023, le hub reçoit une responsabilité spécifique à Shopetic : calculer des gouttes d’eau liées aux commandes et les créditer à un utilisateur Lilo. La configuration distingue première commande et commandes suivantes.
Le calcul peut combiner un pourcentage du total payé et un montant fixe par article. Pour un acheteur, les valeurs de plusieurs commandes sont agrégées en part fixe et part supplémentaire avant la préparation du crédit.
Le traitement vérifie que la commande est éligible, que les gouttes n’ont pas déjà été poussées, qu’un identifiant d’affiliation existe, qu’une configuration correspond et que l’utilisateur est connu par l’API Lilo. L’écriture conserve ensuite la date et l’état du crédit.
Les commandes sont recalculées toutes les cinq minutes et les crédits clients prêts sont envoyés toutes les deux heures dans la configuration finale. Cette règle illustre la valeur d’un hub : ajouter un processus transversal sans déplacer la logique dans le frontend acheteur.
22. Lire sept mois comme une suite de boucles refermées
Chaque période complète un trajet de donnée avant d’en ouvrir un autre
Décembre 2022 relie Shopify et Origami au travers des catalogues, offres et premières commandes. Janvier ajoute PrestaShop, le PIM, les historiques et les vues nécessaires pour expliquer les rapprochements.
Mars rend le vendeur administrable et conditionne les collectes automatiques à sa validation. Avril ferme la boucle commande : import Origami, intégration Shopify, PrestaShop ou WooCommerce, lecture du statut vendeur, API, messages, cache et suivi des échanges.
Mai et juin traitent un processus transverse, Lilo, depuis le calcul sur chaque commande jusqu’au crédit agrégé par acheteur. Le projet montre alors qu’il sait porter une règle qui traverse commandes, clients, configuration et API externe.
Juillet se concentre sur les différences réelles entre boutiques : correctif d’un vendeur précis, mode de secours PrestaShop et calcul WooCommerce taxé ou non taxé. Le dernier jalon n’est pas une annonce de lancement, mais une amélioration d’exploitation.
23. Les arbitrages qui évitent une automatisation aveugle
Valider, rapprocher, isoler et reprendre plutôt que pousser à tout prix
Premier arbitrage : conserver les objets vendeur et marketplace séparés. Leur mapping est une relation explicite, supprimable et recalculable. Une mise à jour externe ne réécrit pas silencieusement l’identité de l’autre source.
Deuxième arbitrage : contrôler les préconditions avant la commande. Une ligne sans offre, une offre sans variante CRM ou un vendeur sans identifiant client bloque l’intégration avec un message précis. Le hub préfère une commande visible en attente à une écriture partielle chez le vendeur.
Troisième arbitrage : différencier capacité et planification. La diffusion d’état est construite mais désactivée dans le cron final. Le mapping par similarité alimente une liste de candidats soumise au contrôle de l’opérateur. Le mode de secours reste activable vendeur par vendeur.
Quatrième arbitrage : répartir les cadences. Une commande récente justifie une minute ; un catalogue boutique complet, trois heures ; une reprise profonde Origami, six heures. Le plan privilégie la fraîcheur là où elle change l’action, sans relancer tout le système au même rythme.
24. Ce qui change entre décembre 2022 et juillet 2023
D’une lecture produit Origami à une chaîne multivendeur exploitable
Au départ, l’application sait lire un produit Origami. À la fin, elle conserve les catalogues de trois écosystèmes vendeurs, importe les principales ressources marketplace, rapproche les offres et expose les exceptions dans un cockpit authentifié.
Le stock, le prix et l’état peuvent repartir vers Origami par action ou par traitement. La commande suit le chemin inverse jusqu’à la boutique vendeur, puis son statut, son transporteur et son suivi reviennent dans le hub.
Les tâches longues disposent de 13 files spécialisées et d’une file d’échec. Les cadences couvrent le récent et la reprise profonde. Les 268 scénarios automatisés vérifient les contrats et parcours qui structurent cette circulation.
Le changement opérationnel est immédiat à observer : localiser une rupture, voir les objets concernés et relancer la bonne responsabilité deviennent des actions prises depuis le même poste de contrôle.
25. Une commande Origami destinée à une boutique WooCommerce
Du mapping de variante au retour du numéro de suivi
Un vendeur WooCommerce a été validé avec son URL, ses clés et son identifiant client. Sa collecte périodique normalise produits et variantes dans le CRM. Une offre Origami retrouve la bonne variante grâce à la référence vendeur ; l’opérateur peut contrôler la relation depuis les deux fiches.
Une commande récente entre depuis Origami. Avant toute écriture, le hub vérifie qu’elle n’a pas déjà été intégrée, que chacune de ses lignes possède une offre, que chaque offre conduit à une variante WooCommerce et que le vendeur est correctement configuré.
Le connecteur crée alors une commande payée avec adresses, livraison, quantités, prix et identifiants de variantes. L’identifiant retourné par WooCommerce est conservé. Si l’appel échoue, le message de configuration ou d’intégration reste rattaché à la commande source.
La lecture programmée interroge ensuite WooCommerce. Quand la boutique fournit l’avancement logistique, le hub met à jour état vendeur, transporteur, numéro et URL de suivi, puis peut notifier l’exploitation. Une vente marketplace devient ainsi une opération exécutable dans l’outil quotidien du vendeur.
26. Séparer le cockpit opérateur des deux générations de frontend Shopetic
Trois applications reliées par le métier, distinctes par leur responsabilité
Le premier frontend Shopetic sur Wizaplace raconte les 31 jours qui ont construit une expérience de découverte, avec recherche, facettes, catégories, marques et Etictos. Il ne porte pas cette orchestration vendeur.
Le frontend Shopetic sur Origami suit l’acheteur jusqu’au paiement LemonWay et à son espace client. Il utilise Origami pour le commerce, Algolia pour la découverte et le CMS pour le contenu, mais ne remplace pas le poste de contrôle des boutiques vendeurs.
Le hub commence neuf mois après le frontend Origami. Il travaille derrière l’expérience publique : catalogues sources, mappings, écritures d’offres, commandes vendeurs, expéditions, monitoring et Lilo. Les trois réalisations forment ainsi un système complet tout en conservant chacune sa responsabilité.
Notre expertise Origami pour opérateurs, nos connecteurs vendeurs marketplace et notre accompagnement en back-office opérateur prolongent précisément les responsabilités démontrées ici.
27. Un hub qui rend chaque passage de relais vérifiable
Du catalogue vendeur à Origami, puis de la commande marketplace à l’expédition
Le hub Shopetic transforme trois familles de boutiques en sources exploitables sans nier leurs différences. Produits, variantes, images, options, taxes et identifiants sont normalisés ; les offres restent distinctes et leur rapprochement conserve une décision contrôlable.
La commande démontre la valeur de cette architecture. Elle n’est créée chez le vendeur qu’après vérification de toutes ses relations, puis son exécution logistique revient dans le cockpit. Les files, cadences, vues d’exception et tests donnent à l’équipe les moyens de comprendre ce trajet dans la durée.
Pour construire ce type de chaîne, nos intégrations SI opérateur, nos connecteurs Shopify, PrestaShop et WooCommerce et nos outils de pilotage marketplace relient les systèmes autour des décisions réelles de l’exploitation.
