Le projet en un coup d’œil
Shopetic devait reconstruire sur Origami la lecture du catalogue, le compte client et un tunnel multivendeur sans laisser les formats distants envahir toute l’application.
Dawap a séparé le domaine des appels HTTP, puis réparti la connexion dans 24 adaptateurs et 21 mappers couvrant recherche, collecte et mutations.
Soixante-cinq opérations publiques alimentent les parcours Shopetic. Quatorze mutations client, panier, paiement et commande ajoutent une trace de requête et de réponse.
Une marketplace peut présenter un catalogue élégant et un tunnel rassurant tout en restant fragile à un endroit invisible : la frontière avec son moteur de commerce. Si chaque contrôleur interprète directement une réponse distante, un changement de relation, de pagination ou de statut HTTP se diffuse rapidement dans les pages, les formulaires et les règles métier.
Pour Shopetic, la connexion à Origami ne se limitait pas à afficher des produits. Elle devait traverser la création du client, la gestion des adresses, le panier multivendeur, le choix de livraison, les coupons, le paiement, la création des commandes vendeurs, les avis et les échanges de support. Chacun de ces gestes possède un vocabulaire, des relations et des réponses différents.
Dawap a construit une couche d’adaptation qui place les contrats du domaine Shopetic devant le client HTTP. Vingt-quatre adaptateurs Origami exposent soixante-cinq opérations publiques ; vingt-et-un mappers transforment les réponses en entités et collections internes. Les mutations les plus sensibles ajoutent une trace exploitable de la requête et de la réponse.
Le projet montre ainsi ce que signifie réellement une mission d’intégration API Origami : ne pas seulement appeler des endpoints, mais donner à chaque échange une frontière, une responsabilité et un comportement que le reste de l’application peut comprendre.
1. Shopetic, une marketplace écoresponsable branchée sur un moteur transactionnel
Le catalogue visible et les décisions de commerce devaient rester cohérents malgré plusieurs profondeurs de données
Shopetic rassemble des produits, variantes, offres vendeurs, attributs, catégories, caractéristiques, images et informations de disponibilité. Une fiche produit ne correspond donc pas à une seule ressource distante : elle assemble un graphe dont chaque relation sert une décision d’affichage ou d’achat.
Le tunnel ajoute une autre profondeur. Un panier contient des lignes rattachées à des produits et des vendeurs, puis des adresses, des modes de livraison, des avantages et un client. La création des commandes vendeurs intervient après le paiement et doit conserver le lien avec le panier qui a servi de point de départ.
L’intégration devait également supporter les fonctions qui entourent la vente : authentification, réinitialisation de mot de passe, avis, tickets, messages, tableau de bord, cartes cadeaux et récupération d’utilisateurs. Le périmètre dépasse donc largement un connecteur catalogue.
Ce volet se concentre sur la mécanique API. La réalisation frontend Shopetic sur Origami prolonge l’histoire avec le parcours public, la recherche Algolia, le CMS, le SEO, le cache et la vie du produit sur vingt-sept mois.
2. Faire descendre la complexité distante dans des adaptateurs nommés par le métier
Contrat, requête, mapping et contrôle de résultat forment une chaîne explicite
Chaque famille fonctionnelle possède d’abord des interfaces dans le domaine : rechercher un produit, collecter une catégorie, créer un panier, modifier une adresse ou récupérer une commande. L’application dépend de ces intentions et non d’un tableau JSON construit au fil des contrôleurs.
L’implémentation Origami prépare ensuite l’URL, la méthode, les paramètres, les relations à inclure et les en-têtes. Elle connaît les conventions de la plateforme, tandis que le cas d’usage reste centré sur ce que Shopetic veut obtenir ou modifier.
À la réception, un mapper transforme la structure distante en objet de lecture interne. Les collections, la pagination et les objets imbriqués deviennent ainsi des résultats cohérents avant de rejoindre les presenters ou les écrans.
Pour les créations et mises à jour les plus critiques, la chaîne conserve aussi l’opération, sa méthode, sa cible, son résultat HTTP et le détail de la réponse. Le suivi se concentre sur les mutations client, panier, paiement et commandes vendeurs, là où un diagnostic doit rester possible.
3. Traiter Origami comme une frontière, pas comme un format interne
Les pages Shopetic n’ont pas à connaître la forme brute des réponses distantes
Le risque d’une intégration rapide est de faire remonter les noms de champs, les relations et les codes de réponse jusque dans l’interface. Une modification côté plateforme oblige alors à rechercher la même convention dans plusieurs contrôleurs, commandes et gabarits. Le coût ne vient plus seulement de l’API ; il vient de sa dispersion.
Shopetic place une frontière nette autour d’Origami. Le domaine décrit les objets et les actions attendus. L’infrastructure est la seule couche qui sait comment l’opérateur distant expose un produit, une offre, un panier ou une commande vendeur. La présentation reçoit ensuite un résultat déjà traduit.
Cette séparation est concrète : le domaine contient soixante-treize interfaces de données, dont une partie est implémentée par les vingt-quatre adaptateurs opérateur. Les autres couvrent notamment les données locales, le CMS, Algolia et les mécanismes de suivi. L’application peut donc distinguer chaque source au lieu de les fondre dans un même client générique.
La décision protège aussi le récit fonctionnel. « Ajouter une ligne au panier » reste une action Shopetic, même si l’endpoint, le verbe HTTP ou le corps attendu évoluent. L’intention métier ne devient pas le nom technique choisi par un fournisseur.
4. Faire circuler chaque échange dans quatre responsabilités
Le cas d’usage appelle un contrat, l’adaptateur interroge Origami et le mapper rend un objet métier
Un parcours commence dans l’application par un cas d’usage. Celui-ci formule une lecture ou une écriture à travers une interface du domaine. Il ne construit ni URL, ni jeton, ni paramètre include. Cette première séparation garde les règles du parcours testables sans dépendre d’une session HTTP réelle.
L’adaptateur APIOperator prend ensuite la responsabilité de l’échange. Il récupère la configuration courante, assemble la route, choisit GET, POST, PATCH ou DELETE, transmet les données et reçoit la réponse. Le détail de la plateforme reste concentré dans une classe nommée par le domaine concerné.
Le mapper lit enfin la réponse et construit les entités de lecture. Lorsqu’une recherche renvoie plusieurs résultats, il fabrique aussi la collection et les informations de pagination attendues. Les contrôleurs et les presenters manipulent ainsi le langage Shopetic au lieu de relire partout la même structure externe.
La chaîne peut se résumer ainsi : parcours Shopetic → cas d’usage → contrat du domaine → adaptateur Origami → client HTTP → mapper → entité ou collection Shopetic. Cette succession n’ajoute pas une abstraction décorative ; elle attribue un propriétaire clair à chaque transformation.
5. Centraliser le contexte opérateur avant chaque appel
Une URL de plateforme, un jeton actif et un contexte commun alimentent les adaptateurs
Les adaptateurs ne portent pas chacun leur propre configuration. Un composant commun fournit l’URL de base de la plateforme et charge le jeton opérateur depuis la configuration la plus récente de l’application. Si ce jeton manque, la requête ne poursuit pas silencieusement son chemin.
L’autorisation est transmise sous forme de jeton Bearer. Un en-tête de contexte opérateur accompagne également les appels concernés. Ces conventions sont préparées dans la couche d’infrastructure et ne contaminent pas les objets du catalogue ou du panier.
Cette centralisation évite qu’un changement de jeton impose une modification de vingt-quatre classes ou, pire, que plusieurs versions de la même information coexistent. Elle rend aussi explicite la différence entre la connexion de Shopetic à Origami et la session du visiteur qui navigue sur la marketplace.
Le dispositif décrit un comportement applicatif, pas une certification. Il garantit surtout une source unique de configuration au moment de l’appel. La rotation, la gouvernance et la durée de vie du secret restent des responsabilités d’exploitation à traiter autour de l’application.
6. Répartir 24 adaptateurs dans douze domaines fonctionnels
Une classe par famille de ressources plutôt qu’un client universel difficile à faire évoluer
Le catalogue constitue le groupe le plus profond avec huit adaptateurs : types et valeurs d’attribut, catégories, types et valeurs de caractéristiques, cartes cadeaux, produits et offres produit. Cette granularité suit les objets nécessaires pour reconstruire une fiche et ses variantes.
La commande en rassemble trois pour le panier, les lignes de commande et les commandes vendeurs. Le client en compte deux, dédiés au profil et aux avis. La livraison en compte deux pour les offres et les types de transport ; le support en compte deux pour les tickets et leurs messages.
Les domaines authentification, configuration, contexte opérateur, tableau de bord, finance, vendeur et utilisateur disposent chacun de leur point d’entrée. Au total, douze zones fonctionnelles utilisent vingt-quatre classes APIOperator distinctes.
Cette distribution donne un vocabulaire à la maintenance. Une évolution du panier n’oblige pas à ouvrir un client Origami monolithique où se mêleraient mot de passe, avis et catégories. L’équipe peut suivre le domaine affecté, son mapper et ses tests associés.
7. Exposer 65 opérations publiques sans réduire l’intégration à un CRUD
Search et collect côtoient les gestes transactionnels propres au parcours
Les adaptateurs totalisent soixante-cinq opérations publiques hors construction des objets. Certaines recherchent une ressource selon des critères ; d’autres collectent une ressource connue par son identifiant. Cette distinction évite de traiter une liste paginée comme une fiche complète.
Le catalogue fournit surtout des recherches et des collectes. Le client ajoute la création, la mise à jour complète ou légère, la gestion d’adresse et le rattachement d’un identifiant de session partenaire. Le ticket et son message possèdent leurs propres créations.
Le panier concentre le plus grand nombre de gestes : créer, ajouter une ligne, changer une quantité, rattacher un client, supprimer une ligne, enregistrer les adresses, sélectionner la livraison, ajouter ou retirer un avantage et collecter les options de transport. Chaque geste correspond à une étape visible du tunnel.
La finance crée et collecte des transactions, y compris le chemin qui a servi aux cartes cadeaux. Les commandes vendeurs peuvent être créées puis relues. L’inventaire des opérations révèle ainsi un raccordement transactionnel complet, pas une simple synchronisation nocturne de produits.
8. Transformer 21 familles de réponses avant de les présenter
Chaque mapper protège le domaine d’une structure distante particulière
Vingt-et-un mappers spécialisés reconstruisent les objets Shopetic. Ils couvrent notamment catégories, attributs, caractéristiques, cartes cadeaux, produits, offres, champs personnalisés, clients, avis, paiements, paniers, lignes de commande, commandes vendeurs, vendeurs, livraisons, tickets et messages.
Le produit illustre l’enjeu : son mapping doit conserver les variantes, leurs attributs, les catégories, les offres de vendeurs, les caractéristiques et les images. Une simple copie clé-valeur ne suffirait pas à produire l’objet attendu par le choix de variante ou l’ajout au panier.
Le panier possède son propre mapper parce qu’il agrège une autre forme de graphe : lignes, vendeurs, produits, options, client, adresses, modes de livraison et avantages. Un objet produit imbriqué dans le panier n’est pas interprété sans son contexte transactionnel.
Ce passage systématique par des objets internes crée une place unique pour convertir un type, accepter une relation absente ou construire une collection. Il réduit surtout la tentation de corriger un format directement dans une page, correction rapide qui deviendrait invisible pour les autres parcours.
9. Décomposer le catalogue jusqu’aux attributs et caractéristiques
Les filtres et les variantes reposent sur plusieurs ressources Origami reliées
Une catégorie peut être collectée individuellement, recherchée ou chargée sous forme d’arbre. Les attributs possèdent des types et des valeurs distincts. Les caractéristiques suivent la même séparation. Ces ressources donnent à Shopetic les éléments nécessaires pour classer, filtrer et décrire un produit.
L’adaptateur produit accepte des filtres qui correspondent aux usages de la marketplace : identifiant de produit, date de mise à jour, marque représentée par une valeur de caractéristique, ou encore qualification Etictos. La requête distante reste alignée sur la question posée par le parcours.
Les offres produit sont collectées séparément. Ce choix évite de confondre la fiche de référence avec les conditions proposées par un vendeur. Prix, disponibilité et vendeur gardent ainsi une place propre dans la lecture commerciale.
La carte cadeau constitue aussi un objet de catalogue dans cette génération. Elle peut être recherchée, collectée ou retrouvée par code. Son usage transactionnel arrive plus tard dans le panier et le paiement, mais sa reconnaissance commence par une ressource dédiée plutôt que par une chaîne libre interprétée au dernier moment.
10. Demander le graphe produit utile en une lecture cohérente
Variantes, offres, vendeurs, images et catégories sont inclus selon le parcours
La collecte d’un produit demande explicitement les relations nécessaires à sa présentation : attributs des variantes, catégories, offres, types et valeurs de caractéristiques, vendeur de l’offre, images du produit et images de variantes. L’adaptateur décrit donc la profondeur réellement consommée par Shopetic.
Les offres peuvent elles-mêmes embarquer des informations de variante, leurs attributs et leurs images. Cette précision est essentielle lorsqu’un choix de couleur ou d’option détermine l’offre qui sera ajoutée au panier.
L’usage du paramètre include répond à un compromis. Il évite une succession d’appels pour recomposer une même fiche, mais augmente la densité de la réponse. La liste de relations est donc rattachée à l’adaptateur produit au lieu d’être improvisée par chaque page.
Une fiche peut ainsi recevoir un objet cohérent où la relation entre produit, variante et offre a déjà été reconstruite. L’interface conserve sa responsabilité : présenter et faire choisir. Elle n’a pas à deviner quel identifiant externe relie les trois niveaux.
11. Conserver la pagination et les critères dans les lectures de collection
Search ne renvoie pas seulement une liste, mais le contexte pour continuer à naviguer
Une recherche distante possède une page, une taille et des métadonnées. L’adaptateur transmet les critères compatibles avec Origami puis le mapper construit la collection et les informations de pagination attendues. La présentation sait donc où elle se trouve sans relire les conventions de la réponse brute.
Les méthodes collect répondent à un autre besoin : récupérer un objet identifié avec la profondeur relationnelle adaptée. Cette distinction évite de charger une collection complète lorsqu’un parcours ne demande qu’un vendeur, un ticket ou une option de transport.
La recherche et la collecte sont répétées dans plusieurs domaines parce que la forme des filtres n’est pas universelle. Un produit se filtre par catalogue et date de mise à jour ; une commande, un utilisateur ou un avis portent d’autres critères. Le nom commun ne masque pas ces différences.
Shopetic utilise par ailleurs Algolia pour la découverte publique. L’adaptateur Origami reste néanmoins indispensable pour obtenir la source transactionnelle et les objets complets. La fiche frontend Shopetic détaille cette répartition entre index de recherche et moteur de commerce.
12. Relier le compte client sans mêler session locale et profil distant
Création, mise à jour, adresse et rattachement de session disposent de gestes distincts
Le client peut être créé puis recherché ou collecté. Deux formes de mise à jour existent : une modification complète et une modification légère. L’adresse possède également une opération dédiée. Ces différences empêchent un petit changement de profil d’envoyer par réflexe un document beaucoup plus large.
Une opération supplémentaire rattache au client un identifiant de session partenaire. Elle a notamment servi au parcours Lilo introduit en 2023. Le raccordement ne se réduit donc pas aux champs classiques de civilité et d’adresse ; il sait transmettre un contexte d’affiliation lorsque le parcours le demande.
L’authentification du visiteur reste distincte du jeton opérateur utilisé par les adaptateurs. Shopetic peut rechercher un utilisateur par son adresse électronique et collecter son profil sans confondre les droits du compte marchand avec ceux du connecteur serveur.
Les mutations client appartiennent aux appels suivis par le dispositif de monitoring. Lorsqu’une création ou une modification échoue, l’équipe peut retrouver l’opération et son résultat au lieu de déduire le problème uniquement depuis le formulaire visible.
13. Faire du panier une orchestration explicite de gestes
Créer, enrichir et corriger le panier sans envoyer un état opaque à chaque étape
Le panier possède sa recherche et sa collecte, mais surtout neuf familles de mutations. Une première opération le crée. D’autres ajoutent une ligne, modifient sa quantité ou la suppriment. Le client peut ensuite être rattaché au panier commencé durant une session invitée.
Les adresses sont transmises avant le mode de livraison. Les options disponibles peuvent être collectées pour le panier courant, puis la méthode choisie est enregistrée. Les avantages suivent deux gestes distincts : ajouter un voucher ou le retirer.
Cette décomposition donne un point de diagnostic à chaque étape. Une erreur de quantité ne se confond pas avec un refus de code avantage ; une adresse invalide ne devient pas un échec générique de sauvegarde du panier. L’interface peut réagir au geste qui vient réellement d’être demandé.
Le détail du panier demande un graphe riche : vendeurs et avis, lignes avec leurs produits, catégories, offres, caractéristiques, variantes et images, puis client, adresses, livraisons et avantages. Le mapper rassemble ce contexte afin que le tunnel dispose d’un état cohérent après chaque mutation.
14. Séparer les types de transport des offres applicables
La promesse affichée dépend du panier et du vendeur, pas d’une liste statique
Deux adaptateurs sont consacrés à la livraison. Le premier recherche et collecte les types de transport. Le second recherche et collecte les offres de livraison. Cette séparation conserve la différence entre la nature d’un service et sa proposition dans un contexte donné.
Le panier demande ensuite sa propre collection de méthodes disponibles. La sélection est renvoyée à Origami par une mutation dédiée. Le tunnel ne choisit donc pas un libellé local sans rattachement au calcul du moteur transactionnel.
Dans une marketplace multivendeur, ce point est structurant : les lignes n’appartiennent pas toutes au même vendeur et ne partagent pas nécessairement la même solution logistique. Le modèle de panier doit conserver cette composition avant la commande.
L’évolution de janvier 2023 a notamment accompagné une mise à jour de l’API Origami 2.12 et l’ajout du téléphone aux informations de livraison. Cette correction montre pourquoi la frontière mérite une classe dédiée : un besoin de transport peut évoluer sans réécrire toute la présentation du panier.
15. Créer la transaction puis relire son état avant la commande
Le paiement possède son propre adaptateur et sa propre représentation
L’adaptateur financier expose la création et la collecte d’une transaction de paiement. Une troisième opération a servi au paiement intégral par carte cadeau. Le domaine finance reste ainsi séparé du panier, même si les deux se succèdent dans le tunnel.
La création transmet à Origami les éléments attendus par le parcours, puis le mapper construit l’objet de paiement compris par Shopetic. La redirection vers le prestataire et le retour ne sont pas traités comme une simple propriété arbitraire du panier.
Les créations de transaction font partie des mutations tracées. Méthode, cible, charge utile, statut et réponse peuvent être rapprochés. Cette trace sert à comprendre ce que l’application a réellement envoyé et reçu ; elle ne constitue pas à elle seule une preuve bancaire ou un rapprochement comptable.
Le paiement du frontend Shopetic s’appuie sur LemonWay et déclenche ensuite les commandes vendeurs lorsque le retour réussi est traité. Cette étude reste centrée sur le passage API ; la chronologie complète du tunnel est présentée dans la réalisation marketplace Shopetic.
16. Créer des commandes vendeurs à partir du panier validé
Le multivendeur reste visible après le paiement
La couche Order distingue la ligne de commande, la commande vendeur et le panier. Une ligne peut être recherchée ou collectée. Une commande vendeur peut être créée, recherchée, collectée ou relue depuis le point de vue du client.
Cette structure préserve la nature marketplace du parcours. Le client paie une expérience unifiée, tandis que l’exécution commerciale se répartit entre plusieurs vendeurs. Une commande globale ne doit pas effacer les unités qui devront ensuite être suivies, expédiées ou présentées dans l’espace client.
La création des commandes vendeurs intervient dans la zone de mutations suivies. L’opération reçoit un identifiant externe lorsque celui-ci est disponible, ce qui facilite le rapprochement entre la trace technique et l’objet de commerce concerné.
Une réponse réussie confirme le comportement attendu par l’adaptateur ; elle ne prouve pas encore que chaque événement logistique futur aura abouti. La frontière garde donc une responsabilité précise : demander la création, interpréter la réponse et fournir l’objet obtenu au reste du parcours.
17. Prolonger la vente par les avis, tickets et messages
L’intégration couvre aussi la relation après l’achat
Un adaptateur client permet de créer, collecter et rechercher des avis. Le vendeur peut être collecté ou recherché séparément. Ces deux familles alimentent la confiance et la lecture du contexte vendeur sans être enfouies dans l’objet produit.
Le support possède un adaptateur de ticket et un adaptateur de message. Un ticket peut être créé, collecté ou recherché ; un message peut être créé ou collecté. L’espace client dispose ainsi de primitives distinctes pour ouvrir une conversation puis la poursuivre.
Cette séparation évite de représenter une relation de support comme une simple note libre attachée à une commande. Le ticket possède son identité et le message sa propre chronologie. L’interface peut construire un suivi lisible autour de ces objets.
Le périmètre rappelle qu’une intégration marketplace ne s’arrête pas lorsque le paiement est accepté. Le client doit retrouver ses commandes, donner un avis et échanger sur un problème. Les adaptateurs offrent ces points de passage au même niveau de rigueur que le catalogue ou le panier.
18. Tracer 14 mutations là où une écriture mérite une preuve technique
Client, panier, paiement et commandes vendeurs constituent le périmètre observé
Quatorze interactions créent explicitement une entrée de suivi dans quatre adaptateurs : client, panier, paiement et commande vendeur. Le choix se concentre sur les opérations qui modifient un état ou engagent une étape transactionnelle, plutôt que sur chaque lecture de catalogue.
La trace possède un identifiant, un nom, un type, une URL, une méthode HTTP et une date. Elle peut conserver la charge utile et un identifiant externe. Après la réponse, elle reçoit le statut HTTP et un indicateur de réussite.
Un détail séparé conserve la réponse interprétée. Cette structure permet de consulter le résumé d’une opération puis son contenu lorsque le diagnostic le demande, sans confondre le journal principal et le document retourné.
Le bénéfice est particulièrement concret dans le panier : ajout ou suppression de ligne, rattachement du client, adresse, livraison ou avantage laissent chacun un point d’observation. L’équipe ne dépend pas seulement du message final montré au visiteur pour comprendre l’étape qui a rompu la chaîne.
19. Vérifier le résultat attendu selon le geste exécuté
Une suppression et une mise à jour ne partagent pas nécessairement le même succès HTTP
Les adaptateurs utilisent GET, POST, PATCH et DELETE selon l’intention. Ils ne réduisent pas la réussite à « aucune exception levée ». Plusieurs mutations comparent le statut obtenu au statut attendu pour le geste concerné.
La suppression d’une ligne de panier attend par exemple une réponse sans contenu, tandis que de nombreuses créations ou mises à jour attendent une réponse exploitable. Cette distinction empêche d’interpréter de la même manière deux conventions HTTP différentes.
Le booléen de réussite ajouté au suivi rend ce contrôle consultable avec le statut reçu. La réponse détaillée aide ensuite à comprendre un refus fonctionnel ou une divergence de contrat lorsque le contenu est disponible.
Le comportement n’est pas présenté comme une politique universelle de reprise. Aucun mécanisme générique de retry ou de garantie d’idempotence n’est attribué à toute la couche. L’intérêt prouvé est plus précis : l’adaptateur sait quel résultat il attend et le journalise pour les mutations ciblées.
20. Vérifier les contrats sur trois niveaux de tests
Le domaine Origami compte 80 fichiers unitaires, 56 d’intégration et 28 applicatifs
La suite liée au domaine Origami se répartit entre quatre-vingts fichiers de tests unitaires, cinquante-six fichiers d’intégration et vingt-huit fichiers applicatifs. Ces nombres décrivent les fichiers présents dans chaque niveau, pas un pourcentage de couverture.
Les tests unitaires peuvent contrôler un mapper, une entité ou une règle sans dépendre d’une réponse réelle. Les tests d’intégration vérifient le raccordement entre plusieurs composants, notamment dans le catalogue, la finance, les commandes, les vendeurs et la livraison.
Les tests applicatifs ouvrent des parcours plus larges. Ensemble, les trois niveaux évitent de demander à un seul type de scénario de prouver à la fois une conversion de champ, une requête et un écran complet.
Cette profondeur accompagne la taille du produit, mais elle ne garantit pas que chaque réponse possible d’Origami soit couverte. La valeur tient à l’existence de frontières contrôlables : contrat, adaptateur, mapper et parcours peuvent être vérifiés au niveau où leur responsabilité apparaît.
21. Étendre la connexion au rythme des parcours entre 2022 et 2023
Le catalogue arrive d’abord, puis le tunnel, le support et les enrichissements transactionnels
La couche commence fin mars 2022. En avril, les premiers travaux portent sur les attributs, catégories, caractéristiques, cartes cadeaux, produits et leurs mappings. Cette séquence installe le vocabulaire du catalogue avant de construire le tunnel complet.
En juin 2022 arrivent les types et offres de livraison, l’authentification, le panier, les lignes de commande, le client et les adresses. Le paiement suit à la fin du mois. Début juillet, les tickets, avis et vouchers complètent la relation après et autour de la vente.
L’automne 2022 enrichit les produits, le tableau de bord, les commandes et leur suivi. En janvier 2023, l’intégration s’ajuste à la version 2.12 de l’API, aux informations de transport et aux journaux de transaction. En mai, le parcours Lilo ajoute le rattachement de session au client et à la commande.
Les derniers changements de cette frontière, les 18 et 19 juillet 2023, concernent les cartes cadeaux, les coupons et la recommandation après commande. Cette dernière extension donne sa date à la réalisation présentée ici.
22. Faire évoluer le paiement avec les cartes cadeaux et les coupons
Un cas transversal mobilise catalogue, panier et finance
La carte cadeau illustre la raison d’être des frontières. Elle est d’abord une ressource que le catalogue peut retrouver par code. Elle intervient ensuite dans le résumé du panier, puis dans la création d’une transaction lorsqu’elle couvre tout ou partie du montant.
En juillet 2023, plusieurs changements rapprochés ajoutent l’import, la collecte par code, le travail côté panier et la création d’une transaction spécifique. Le lendemain, l’intégration est ajustée pour les cartes cadeaux et les coupons, puis pour la recommandation qui suit la commande.
Le cas traverse donc plusieurs domaines sans les fusionner. Le catalogue reconnaît la valeur, le panier l’applique à son état et la finance porte la transaction. Chaque responsabilité conserve son adaptateur et ses objets.
Cette fonctionnalité sera retirée du frontend en février 2024. Son arrêt ultérieur n’efface pas la réalisation de 2023 ; il montre qu’une architecture doit aussi permettre de faire évoluer ou de retirer un parcours sans réécrire toutes les autres interactions Origami.
23. Suivre une commande multivendeur depuis une variante jusqu’aux commandes vendeurs
Chaque étape franchit la même frontière avec une intention différente
Un visiteur ouvre une fiche. L’adaptateur produit collecte les variantes, leurs attributs, les offres, les vendeurs et les images. Le mapper reconstruit l’objet Shopetic ; l’interface peut alors présenter la bonne combinaison sans parcourir elle-même la réponse Origami.
Le visiteur choisit une variante et une offre. Le panier est créé ou retrouvé, puis une ligne est ajoutée. La mutation est tracée avec sa méthode, sa cible et son résultat. Le panier relu contient désormais la ligne, le produit, l’offre et le vendeur associés.
Le compte client est rattaché, les adresses sont enregistrées et les offres de livraison disponibles sont collectées. Le choix du transport devient une mutation distincte. Un coupon éventuel suit son propre geste, de sorte qu’un refus ne soit pas confondu avec la livraison.
La transaction de paiement est créée puis collectée. Après son succès, l’application demande les commandes vendeurs issues du panier. Chacune peut ensuite être relue dans l’espace client. Du produit à la commande, le parcours mobilise plusieurs adaptateurs sans laisser leurs contrats techniques se mélanger dans une page unique.
24. Ce que la couche d’intégration change concrètement
La progression se lit dans la maîtrise du parcours et la qualité du diagnostic
Avant cette couche, le nouveau raccordement Origami était un ensemble de contrats à apprivoiser. Après les premières semaines, Shopetic pouvait déjà collecter les structures du catalogue ; en juin 2022, le même socle portait le compte, le panier, la livraison et le paiement.
Les vingt-quatre adaptateurs donnent un emplacement stable aux soixante-cinq opérations. Les vingt-et-un mappers empêchent les réponses brutes de devenir le modèle interne de l’application. Une évolution distante peut ainsi être examinée à la frontière concernée.
La traçabilité ciblée rend les écritures sensibles plus explicables. Lorsqu’une ligne, une adresse, une livraison, une transaction ou une commande vendeur échoue, l’équipe dispose du geste, du statut et de la réponse enregistrés pour instruire le problème.
Les effets directement observables sont fonctionnels : couverture d’un tunnel complet, responsabilités séparées, résultats transformés avant présentation et mutations critiques consultables. Les résultats commerciaux et le temps gagné en support demanderaient une mesure distincte du fonctionnement de la couche API.
25. Les limites qui gardent cette preuve crédible
Une intégration structurée ne devient pas automatiquement une garantie de service
Le suivi explicite concerne quatorze mutations dans quatre adaptateurs. Il ne couvre pas chaque lecture de catalogue, avis, ticket ou livraison. Présenter toute la couche comme intégralement monitorée dépasserait donc le périmètre construit.
Les statuts attendus rendent les résultats lisibles, mais aucun mécanisme universel de retry, de rejeu ou d’idempotence n’est revendiqué pour l’ensemble des soixante-cinq opérations. Ces propriétés doivent être examinées geste par geste lorsque le besoin les exige.
Les fichiers de tests montrent trois niveaux de contrôle, sans fournir un taux de couverture ni une certification face à toutes les versions de l’API. La mise à jour de janvier 2023 rappelle au contraire qu’un contrat distant continue d’évoluer.
Enfin, cette couche n’est ni Algolia, ni le CMS, ni le frontend complet, ni le hub opérateur qui synchronise d’autres écosystèmes vendeurs. Sa valeur tient à une responsabilité volontairement bornée : traduire les échanges Origami nécessaires aux parcours Shopetic.
26. Relier cette frontière aux autres responsabilités Shopetic
Frontend, SEO et hub opérateur prolongent le projet sans se confondre avec lui
La marketplace Shopetic sur Origami montre comment les objets issus de cette intégration alimentent vingt-neuf routes de découverte, onze routes de panier, le CMS, Algolia, le paiement et les traitements d’exploitation.
Le hub opérateur Shopetic porte une autre responsabilité : relier Origami à trois écosystèmes vendeurs. Il travaille sur les synchronisations opérateur, tandis que la présente couche alimente les parcours du site marchand.
Le projet SEO technique Shopetic traite les adresses, contenus et signaux d’indexation de la marketplace. Il dépend de données cohérentes, mais ne remplace ni le moteur transactionnel ni ses adaptateurs.
Pour un besoin comparable, notre accompagnement d’intégrateur Origami commence par cette même clarification : quelles sources font autorité, quelles opérations doivent être exposées au domaine, quelles réponses doivent être transformées et quelles écritures exigent une trace exploitable.
27. Conclusion
Une API marketplace devient fiable lorsqu’elle parle le langage du parcours qui l’utilise
L’intégration Origami de Shopetic ne tient pas dans un client HTTP générique. Elle répartit vingt-quatre adaptateurs dans douze domaines, expose soixante-cinq opérations et confie à vingt-et-un mappers la transformation des réponses. Le catalogue, le client, le panier, la livraison, le paiement et les commandes conservent ainsi leurs responsabilités.
Les quatorze mutations suivies ajoutent un point de contrôle là où le parcours change un état. Elles rendent les créations et mises à jour plus faciles à instruire. Les trois niveaux de tests complètent cette frontière avec des contrôles adaptés à chaque responsabilité.
Cette réalisation constitue une preuve client distincte du frontend Shopetic : elle montre comment bâtir la couture entre une marketplace et Origami. C’est précisément le rôle de notre expertise d’intégration API Origami : transformer des contrats distants en parcours métier lisibles, évolutifs et vérifiables.
