Le projet en un coup d’œil
Le catalogue et ses objets existaient côté Wizaplace. Shopetic devait encore maîtriser les pages publiques, la navigation et la manière de présenter son offre engagée.
Le frontend traduit les contrats Wizaplace en objets métier, compose les parcours catalogue et absorbe les appels répétés grâce à Redis et à des traitements asynchrones.
Onze routes publiques, sept vues opérateur et trente-cinq tests actifs valident une première architecture qui sépare l’expérience Shopetic du fournisseur de marketplace.
En février 2022, Shopetic disposait d’un moteur Wizaplace pour porter les objets marketplace, mais l’expérience visible devait devenir un produit à part entière. Une marketplace écoresponsable ne se raconte pas avec une simple grille de références : elle doit rendre les catégories compréhensibles, donner une place réelle aux marques et aux labels, puis conduire le visiteur jusqu’à une fiche produit cohérente.
Dawap a construit cette première génération comme une couche autonome sous Symfony. Le navigateur dialogue avec des parcours Shopetic ; le serveur interroge les API opérateur, transforme leurs réponses et protège l’affichage des variations de contrat. Cette séparation constitue le cœur de notre approche du frontend marketplace sur mesure.
L’histoire est courte et dense : démarrage le 14 février, domaine et premiers tests à partir du 25, catalogue filtrable et cache dès la fin du mois, pages de catégories, marques et labels début mars, puis promotions et comptes utilisateurs jusqu’au 16 mars. Le résultat est un socle vérifiable ; il ne dépend ni d’un témoignage inaccessible ni d’un gain commercial inventé.
1. Shopetic, une marketplace où la découverte fait partie de la promesse
Faire émerger produits, marques et engagements depuis une même source Wizaplace
Shopetic organise une offre autour d’une consommation plus responsable. Cette orientation apparaît dans les parcours prévus dès la première version : une charte d’engagement, une présentation de la plateforme, des marques et une famille de labels appelée « Etictos » accompagnent les catégories et les produits.
Le moteur marketplace reste responsable du catalogue, des catégories, des attributs, des devises, des commandes et d’autres objets opérateur. Le frontend doit cependant décider comment un visiteur cherche, filtre et ouvre ces informations. Il devient donc le lieu où la donnée technique acquiert une hiérarchie éditoriale et marchande.
Le défi ne consiste pas à copier toutes les fonctions du moteur. Il faut choisir un premier parcours cohérent, maintenir une identité stable entre les pages et éviter que chaque variation d’API se diffuse jusque dans les gabarits. Les fonctions réellement accessibles au public se concentrent alors sur la découverte du catalogue.
Cette première génération précède le frontend Origami et le hub d’exploitation Shopetic. Les trois projets répondent à des responsabilités différentes : expérience d’achat, évolution du moteur marketplace, puis synchronisation des catalogues vendeurs. Les confondre effacerait précisément les décisions prises à chaque étape.
2. Livrer verticalement, de la réponse API jusqu’à la page
Un mois de progression datée autour du catalogue et de ses dépendances
Le 25 février, le travail commence par les contrats métier et un premier test d’intégration sur les devises. Les jours suivants ajoutent les traductions, le menu, les attributs et leurs valeurs. Cette progression prépare les éléments nécessaires au catalogue avant de multiplier les écrans.
Le 28 février, la recherche produit, les facettes et une première stratégie de cache apparaissent ensemble. Le 1er mars, le thème public et l’ordre des parcours prennent forme. Les catégories, les marques, les Etictos et les fiches produit rejoignent ensuite la navigation entre le 2 et le 4 mars.
Les derniers jalons étendent le domaine aux promotions et aux utilisateurs. Ils montrent la direction marchande visée, tandis que les routes publiques disponibles restent centrées sur le catalogue. La fiche distingue ces fondations internes des fonctions effectivement présentées aux visiteurs.
Le 16 mars 2022 marque le dernier jalon de cette génération Wizaplace. Douze jours plus tard commence la génération Origami. La chronologie permet ainsi de raconter un passage de relais technologique sans attribuer à Shopetic des arbitrages, des ateliers ou des résultats qui ne sont pas documentés.
3. Avant le frontend : le moteur ne suffit pas à raconter Shopetic
Des objets marketplace disponibles, mais aucune expérience indépendante pour les relier
Wizaplace expose les produits, catégories, attributs, contenus et objets opérateur utiles à la plateforme. Ces données forment le moteur du service, pas encore la manière dont un visiteur comprend l’offre. Sans couche dédiée, l’identité Shopetic resterait contrainte par la présentation fournie avec la solution.
Le catalogue pose immédiatement plusieurs questions d’expérience. Comment faire cohabiter une recherche textuelle et des filtres ? Comment conserver le contexte d’une catégorie ? Comment offrir une entrée par marque ou par engagement ? Comment produire une adresse lisible pour une fiche produit dont la source principale reste externe ?
Une réponse purement graphique aurait déplacé le problème. Si les gabarits lisaient directement les structures JSON de l’API, la moindre différence de pagination, de nommage ou de sous-objet fragiliserait plusieurs pages. Le projet devait donc créer une vraie frontière avant de composer les écrans.
Le point de départ est celui d’un produit à construire, pas d’une refonte mesurée sur une plateforme précédente. La transformation observable va d’une intégration API explorée par cas d’usage à un parcours catalogue accessible depuis onze routes publiques.
4. Donner au frontend quatre responsabilités claires
Traduire, composer, accélérer et préparer les évolutions
La première responsabilité consiste à traduire les réponses Wizaplace en objets maîtrisés par Shopetic. Un produit, une facette ou une catégorie ne traverse pas directement toute l’application sous la forme reçue. Un adaptateur contrôle les champs attendus et construit l’objet utilisé par le cas métier.
La deuxième consiste à composer les parcours. Recherche, catégories, marques et Etictos réutilisent la même logique catalogue tout en imposant un filtre de départ différent. Cette unité évite de maintenir quatre moteurs de liste qui finiraient par diverger.
La troisième porte sur le temps de réponse et la dépendance à l’API. Les recherches, produits, catégories et attributs peuvent être conservés vingt-quatre heures dans Redis. Des traitements distincts préparent aussi les pages du catalogue et les images sans monopoliser une requête visiteur.
Enfin, l’architecture doit pouvoir évoluer sans emprisonner Shopetic dans le premier fournisseur. Les cas métier dépendent d’interfaces, tandis que les appels HTTP et la transformation des réponses restent dans une couche séparée. Cette décision prendra tout son sens lors de la génération Origami.
5. Du 14 février au 16 mars : un catalogue construit par couches
Chaque jalon apporte une dépendance nécessaire au parcours suivant
Le projet est initialisé le 14 février 2022. À partir du 25, le domaine s’organise et les premières intégrations vérifient les appels de devise. Le 26, trois tests d’intégration sont déjà présents ; le 28, traductions, menus, attributs et recherche catalogue donnent une première épaisseur fonctionnelle.
Le 1er mars relie la recherche à ses facettes et pose le thème public. La commande rejoint aussi les cas explorés côté opérateur. Le 2 mars ajoute la première chaîne de déploiement, la vue catégorie, le menu et les bannières issues du CMS.
Le 3 mars concentre la navigation catalogue : listes et fiches de marques, listes et fiches Etictos, recherche par catégorie, Redis en environnement de validation, mise en cache des catégories et préparation locale des images. La fiche produit est consolidée le lendemain avec son adaptateur dédié.
Du 8 au 16 mars, le modèle s’étend aux promotions de catalogue, de panier et de marketplace, puis aux utilisateurs et à leurs objets associés. Ces briques ne sont pas toutes transformées en tunnel d’achat public dans cette version. Elles documentent la progression au-delà du premier parcours de découverte.
6. Séparer la décision métier de l’appel HTTP
Cas d’usage, contrats, adaptateurs et présentateurs plutôt qu’un contrôleur monolithique
Chaque parcours part d’une requête propre au domaine : rechercher des produits, collecter une catégorie, ouvrir une valeur d’attribut ou obtenir une fiche produit. Le cas d’usage valide les entrées, appelle un contrat de lecture puis présente une réponse indépendante de Symfony.
Les contrôleurs se limitent à traduire la requête web en paramètres métier et à choisir le gabarit. Pour une catégorie, ils chargent d’abord l’objet correspondant au slug, vérifient son existence, puis relancent la recherche produit avec la catégorie comme facette imposée.
Les appels Wizaplace vivent dans des adaptateurs HTTP. Ils ajoutent le jeton opérateur côté serveur, composent la pagination et les filtres, puis passent les réponses dans quatorze adaptateurs de données. Les gabarits ne portent donc ni le secret d’accès ni la logique de décodage.
Cette organisation paraît plus exigeante pour un premier mois. Elle répond pourtant à un risque concret : catalogue, CMS et opérations ne suivent pas tous le même modèle de pagination. Isoler leurs contrats empêche une irrégularité d’un point d’entrée de contaminer le reste du frontend.
7. Encadrer les différences entre les API Wizaplace
Onze adaptateurs de lecture pour ne pas traiter tous les objets comme un catalogue
La couche d’intégration couvre notamment produit, catégorie, attribut, valeur d’attribut, devise, commande, attribut PIM, menu et bannière. Chaque famille possède son contrat de lecture et sa transformation, car les champs et les règles de pagination diffèrent.
L’adresse du service et le jeton opérateur sont lus depuis la configuration serveur. Le navigateur demande une page Shopetic ; seul le backend dialogue avec Wizaplace. Cette frontière réduit l’exposition du secret et centralise la façon d’appeler le moteur.
La recherche produit assemble une requête à partir du texte, des facettes, du numéro de page et d’une limite. Avant de fabriquer la clé de cache, les filtres sont triés. Deux sélections identiques arrivées dans un ordre différent retrouvent ainsi la même entrée plutôt que de créer des doublons inutiles.
Pour ouvrir un produit, le frontend résout d’abord le slug auprès du service SEO, vérifie que sa nature est bien « product », récupère son identifiant puis collecte le détail. Cette étape interdit de supposer qu’une adresse lisible contient directement la clé interne du catalogue.
8. Faire de la recherche le centre du premier parcours marchand
Cinquante produits, une requête libre, une page et une collection de filtres
Le parcours `/produits/recherche` demande cinquante résultats par page au moteur. La réponse contient les produits, le numéro de page, le nombre total de résultats, le nombre de pages, la taille de page et la collection de facettes renvoyée par Wizaplace.
Une recherche libre alimente le filtre `query`. Les facettes sélectionnées sont regroupées par nom, puis transmises au même cas d’usage. Cette construction permet au catalogue général, à une catégorie, à une marque ou à un label de partager le même moteur de résultats.
Chaque carte s’appuie sur l’identifiant, le nom, le slug, la disponibilité, les prix, les évaluations et l’image principale lorsque ces valeurs existent. Le lien vers la fiche est construit avec le slug, ce qui garde une adresse compréhensible au lieu d’exposer un identifiant technique.
La première version conserve aussi des éléments de thème encore génériques dans certaines zones. Le cœur livré n’est donc pas présenté comme un tunnel marchand achevé. La preuve tient à la circulation réelle de la requête, des filtres, des produits et de leur navigation.
9. Transformer les facettes API en navigation compréhensible
Valeurs textuelles et plages numériques gardent leur nature propre
Wizaplace renvoie des facettes textuelles ou numériques. Le frontend ne les réduit pas à une liste uniforme : une facette textuelle devient une collection de valeurs avec identifiant, libellé, nombre de résultats et position éventuelle ; une facette numérique conserve ses bornes.
Dans la colonne de filtre, chaque valeur textuelle est accompagnée de son volume de produits. La sélection renvoie le nom de la facette et l’identifiant choisi. L’utilisateur peut donc comprendre l’effet probable du filtre avant de relancer la recherche.
Les pages spécialisées imposent leur propre facette sans perdre celles choisies ensuite par le visiteur. Une page de marque fixe la valeur de l’attribut marque ; une page Etictos fixe celle de l’attribut d’engagement ; une catégorie fixe l’identifiant de catégorie.
Ce mécanisme constitue une décision de conception importante. La marque, le label et la catégorie restent des pages éditoriales identifiables, mais leur liste produit repose sur une seule logique. Une correction du catalogue profite à tous ces parcours.
10. Donner aux objets du moteur une adresse Shopetic
Résoudre le slug, contrôler le type puis injecter les métadonnées disponibles
La fiche produit ne se contente pas d’un identifiant numérique dans l’URL. Son slug est recherché dans le service SEO Wizaplace. Si aucune correspondance n’existe ou si la réponse désigne un autre type d’objet, le frontend s’arrête proprement au lieu d’ouvrir une ressource incohérente.
Les catégories et valeurs d’attribut suivent la même intention : une route lisible reçoit un slug, le traduit en objet puis renvoie une page introuvable lorsque la ressource n’existe pas. Le visiteur et le moteur de recherche partagent ainsi une adresse stable à l’échelle du frontend.
Les gabarits de fiche produit, catégorie et marque reprennent les titres et descriptions SEO fournis par leurs objets. La couche publique peut donc exploiter les contenus du moteur sans recopier manuellement la même métadonnée dans une seconde base.
Cette fondation ne signifie pas que toute la stratégie SEO était achevée. Pagination, contenus génériques du thème et contrôle complet du maillage restaient à approfondir. Elle établit néanmoins la relation essentielle entre slug, type d’objet, page et métadonnée.
11. Ouvrir trois chemins de découverte autour du même catalogue
Catégories, marques et Etictos expriment trois intentions différentes
La catégorie répond à une intention de besoin. Le frontend collecte son identité depuis le slug, affiche sa page puis ajoute son identifiant aux filtres de recherche. Les autres facettes restent disponibles pour affiner le résultat sans quitter cet univers.
La marque répond à une intention de confiance ou de préférence. Sa page utilise une valeur d’attribut dédiée, récupère ses métadonnées SEO et applique cette valeur à la recherche produit. Une liste générale permet aussi de découvrir les marques avant d’en ouvrir une.
L’Etictos répond à la promesse spécifique de Shopetic. Ce parcours utilise lui aussi une valeur d’attribut, mais il donne au visiteur une entrée par label ou engagement plutôt que par fabricant. L’architecture commune ne gomme donc pas le sens éditorial de la page.
Ces trois portes évitent de réduire une marketplace engagée à son moteur de recherche. Elles organisent le même stock de données selon le besoin, la provenance de marque ou le critère d’engagement. C’est là que le frontend commence à porter la proposition de valeur de Shopetic.
12. Assembler une fiche produit depuis plusieurs sous-objets
Identité, SEO, images et détails présentés après résolution du slug
Après résolution de l’adresse, l’adaptateur produit transforme la réponse détaillée en un objet de fiche. Le nom, les informations SEO et l’identifiant alimentent l’en-tête ; les images peuvent être parcourues séparément ; le gabarit n’a pas à connaître la structure JSON d’origine.
L’image principale utilise des variantes locales de deux cents et cinq cents pixels. Les images complémentaires restent reliées à l’objet. Cette approche prépare une diffusion plus prévisible que l’appel direct à une image distante à chaque affichage.
Le lien entre liste et détail est bidirectionnel dans la conception : la carte produit fabrique l’adresse depuis le slug, puis la fiche repart du slug pour confirmer l’objet chez Wizaplace. Une adresse invalide ne peut donc pas être interprétée comme un identifiant arbitraire.
Certains blocs visuels et actions de commerce du thème restaient encore génériques dans cette première génération. La fiche prouve la collecte et la composition du produit ; elle ne revendique pas un panier, un paiement ou une gestion de compte entièrement finalisés côté public.
13. Réduire la dépendance immédiate au moteur avec Redis
Une durée de vingt-quatre heures pour les lectures catalogue répétées
Produit, recherche, catégorie et attribut disposent de règles de cache fixées à vingt-quatre heures. Les clés distinguent le type d’objet et son identité. Pour une recherche, elles incorporent la requête normalisée après tri des filtres.
Redis sert aussi de stockage de session. Le projet évite ainsi de mélanger le cache métier et une variable locale à un seul processus PHP. Plusieurs requêtes peuvent retrouver une lecture déjà préparée dans le même environnement.
La durée longue correspond à un premier arbitrage : privilégier la stabilité et limiter les appels répétés pendant que les parcours catalogue se structurent. Elle ne résout pas encore la question d’une invalidation fine lorsqu’un prix, une disponibilité ou un contenu change côté moteur.
Cette limite est importante pour lire le résultat avec justesse. Le cache améliore l’autonomie du frontend et amortit la latence d’une API externe ; il demande ensuite une politique de fraîcheur adaptée à chaque donnée marchande. La génération suivante approfondira ce sujet.
14. Préparer catalogue et images hors de la requête visiteur
Trois files spécialisées et une file d’échec
Symfony Messenger sépare trois traitements : téléchargement d’image produit, préchauffage des pages de recherche et préchauffage des fiches produit. Chaque type possède son échange et sa file RabbitMQ, avec une file supplémentaire pour recueillir les échecs.
La commande de préchauffage commence par connaître le nombre de pages du catalogue. Elle envoie ensuite un message pour chaque page afin que les résultats soient préparés indépendamment. Un traitement lent n’oblige pas l’utilisateur qui a déclenché la commande à attendre toute la série.
Le téléchargement d’images suit la même philosophie. Une commande parcourt les produits et confie chaque récupération à un message dédié. Le frontend peut alors servir des variantes locales nommées selon l’identifiant du produit, plutôt que répéter la même transformation distante.
Une file ne garantit ni disponibilité ni reprise automatique parfaite. Elle crée un cadre où chaque tâche peut réussir ou échouer séparément et où l’erreur possède une destination explicite. Pour cette première génération, c’est déjà un changement net par rapport à un traitement unique dans la page web.
15. Observer ce que les visiteurs demandent au catalogue
Mémoriser la requête, sa page d’origine et la famille d’appareil
Lorsqu’un visiteur saisit un texte, le frontend crée un événement de recherche avec un identifiant unique, la requête et l’adresse depuis laquelle elle a été envoyée. Cette donnée donne une base pour repérer les mots demandés au catalogue.
Le dispositif classe également l’appareil : smartphone, tablette, ordinateur et plusieurs familles plus spécifiques peuvent être distingués. Il ne collecte pas ici un profil commercial complet ; il rattache simplement la recherche à un contexte d’affichage.
Cette instrumentation prépare une question utile à l’opérateur : les visiteurs cherchent-ils des produits, des marques ou des engagements qui restent difficiles à trouver ? Le projet ne fournit pas encore de tableau d’analyse ni de résultat chiffré, mais il crée l’événement nécessaire pour le construire.
La mesure est enregistrée avant l’appel catalogue. Elle conserve donc aussi les requêtes qui renvoient peu ou pas de résultats, sous réserve que l’appel suivant aboutisse. Ces recherches sans réponse peuvent devenir une source de travail éditorial ou de qualité catalogue.
16. Vérifier les objets Wizaplace depuis sept vues opérateur
Devises, attributs, catégories, produits et commandes accessibles derrière authentification
En parallèle du parcours public, un espace protégé donne accès à sept routes opérateur : recherche de devises, liste et détail des attributs, recherche de produits, liste et détail des catégories, puis recherche de commandes. Un tableau de bord sert de point d’entrée.
Ces vues ne constituent pas encore un back-office complet de marketplace. Elles permettent surtout de vérifier ce que renvoient les contrats du moteur et de parcourir les objets nécessaires au frontend sans passer par un outil d’appel API séparé.
L’authentification repose sur un fournisseur d’utilisateurs distant. Les routes sous `/app` exigent un rôle utilisateur, tandis que les pages publiques restent accessibles anonymement. Le jeton opérateur utilisé pour les lectures API reste dans la configuration serveur.
Cette coexistence sert la mise au point : une catégorie ou un attribut peut être observé côté opérateur, puis contrôlé dans son usage public. Elle prépare aussi le hub opérateur Shopetic, qui prendra ensuite en charge des synchronisations bien plus larges.
17. Tester les règles métier avant de multiplier les écrans
Vingt-et-un fichiers unitaires, neuf fichiers d’intégration actifs et trente-cinq scénarios
Le corpus contient trente fichiers avec au moins un test actif : vingt-et-un consacrés aux cas métier et neuf aux appels d’intégration. Ils regroupent trente-cinq méthodes de test exécutables. Un dixième fichier d’intégration, consacré aux promotions panier, reste désactivé et n’est pas compté comme couverture active.
Les tests unitaires isolent les cas d’usage avec des implémentations en mémoire. Ils contrôlent notamment recherche et collecte d’attributs, devises, commandes, promotions, utilisateurs, cartes, adresses et paniers. La règle métier peut ainsi être vérifiée sans dépendre d’une API disponible.
Les tests d’intégration confrontent plusieurs mêmes cas aux contrats réels : devises, menus, bannières, attributs, valeurs d’attribut, commandes et attributs PIM. Ils ne constituent pas une garantie globale sur tout Wizaplace, mais ils vérifient les premiers échanges essentiels.
La chaîne de livraison construit séparément les images PHP et Nginx pour les branches principales. Le projet possède aussi des configurations locales et de validation avec Redis, RabbitMQ et base de données. La qualité repose donc sur un environnement reproductible autant que sur les contrôles métier.
18. Les décisions qui ont donné sa valeur à cette première génération
Assumer un périmètre étroit pour rendre le changement de moteur possible
Le premier arbitrage est de ne pas faire du thème le cœur du produit. Même si plusieurs composants visuels restaient génériques, les règles de recherche, les facettes, les slugs et les adaptateurs vivaient déjà hors des gabarits. Le travail utile pouvait donc survivre à une refonte graphique.
Le deuxième est de concentrer le public sur la découverte. Catégories, marques, Etictos, recherche et produit forment un ensemble cohérent. Promotions, utilisateurs, paniers et commandes progressent dans le domaine sans être présentés comme un tunnel complet tant que les routes publiques correspondantes ne sont pas abouties.
Le troisième est de traiter la performance comme une architecture, pas comme un chiffre isolé. Cache Redis, clés normalisées, images locales et messages asynchrones réduisent les dépendances synchrones. Aucun temps de chargement moyen n’est inventé pour transformer ces mécanismes en résultat de production.
Le quatrième est de préserver une sortie. Les cas d’usage ne connaissent pas le client HTTP Wizaplace. Lorsqu’Origami devient le moteur de la génération suivante, l’expérience peut être reconstruite autour d’autres contrats sans abandonner le principe de séparation.
19. Ce que le mois de réalisation a concrètement transformé
D’une série de points d’entrée API à un catalogue navigable et testable
Au début de la période, le projet ne contient qu’une initialisation. À la fin, un visiteur peut entrer par une recherche, une catégorie, une marque ou un Etictos, filtrer le catalogue, ouvrir un produit par son slug et retrouver des métadonnées issues de la source marketplace.
L’équipe dispose d’une frontière stable entre Wizaplace et les pages. Onze adaptateurs de lecture et quatorze transformations de données absorbent les différences de contrat. Une évolution du moteur se traite dans cette couche avant d’affecter l’expérience visible.
Les lectures répétées ne repartent plus nécessairement vers l’API. Redis conserve les principaux objets vingt-quatre heures, tandis que trois files déplacent préchauffage et images hors du parcours immédiat. Le bénéfice observable est organisationnel et technique : moins d’opérations couplées dans une seule requête.
Enfin, l’opérateur peut confronter plusieurs objets aux pages publiques et les cas métier possèdent trente-cinq scénarios actifs. Le projet gagne ainsi une base de diagnostic et de régression avant la prochaine génération. Les gains commerciaux, eux, demanderaient des mesures qui ne font pas partie de cette archive.
20. Ce que la première génération laissait encore ouvert
Fraîcheur, finition marchande et exploitation devaient poursuivre leur maturation
Le cache de vingt-quatre heures est simple et efficace pour démarrer, mais aucune invalidation fine par événement n’est visible dans ce périmètre. Un changement de prix ou de disponibilité peut donc demander une régénération ou attendre l’expiration selon le parcours.
La pagination reçue du moteur est bien représentée dans le domaine, tandis que l’interface publique conserve encore une pagination visuelle statique dans certains gabarits. De même, plusieurs libellés et cartes issus du thème démontrent que la finition éditoriale et transactionnelle n’était pas terminée.
Le domaine contient des fondations pour panier, promotions, commandes, utilisateurs et expédition, mais les onze routes publiques ne forment pas encore un cycle d’achat complet. Cette fiche les présente comme une trajectoire technique, jamais comme des fonctions marchandes toutes accessibles en production.
Enfin, aucune base avant-après ne relie cette version à un taux de conversion, un revenu, un volume de visiteurs ou un gain de temps opérateur. La valeur démontrée reste celle du socle livré : parcours, contrats, cache, traitements, instrumentation et tests.
21. Le scénario qui résume le frontend Wizaplace
Partir d’un engagement, filtrer l’offre puis ouvrir un produit sans exposer le moteur
Un visiteur souhaite découvrir les produits associés à un Etictos. Il ouvre la page du label depuis une adresse lisible. Le frontend résout la valeur d’attribut correspondante et refuse la page si ce slug ne désigne aucun objet valide.
La page lance ensuite la recherche commune avec le filtre Etictos déjà imposé. Wizaplace renvoie les produits et les autres facettes disponibles. Le visiteur ajoute un critère ; le frontend trie les filtres, construit la requête et peut retrouver une réponse déjà présente dans Redis.
Chaque carte conduit vers une adresse produit construite avec son slug. À l’ouverture, le service SEO confirme qu’il s’agit bien d’un produit, puis le détail est transformé en objet Shopetic. Le titre, les métadonnées et les images sont présentés sans transmettre le jeton opérateur au navigateur.
En parallèle, la requête textuelle éventuelle est enregistrée avec son origine et la famille d’appareil. L’opérateur peut contrôler les catégories ou attributs dans l’espace protégé. Une seule interaction relie ainsi identité de marque, contrat API, cache, SEO et capacité de diagnostic.
22. Le 28 mars, Shopetic ouvre une génération raccordée à Origami
Conserver l’expérience comme produit tout en changeant le moteur marketplace
Le dernier jalon de la génération Wizaplace date du 16 mars 2022. Le projet frontend Shopetic avec Origami commence le 28 mars. Il ne s’agit pas du même projet renommé : une nouvelle base prend en charge les contrats et les contraintes du nouveau moteur.
La génération suivante poursuivra bien plus longtemps la mise en œuvre : catalogue enrichi, variantes, SEO, contenus et exploitation quotidienne. La présente fiche reste celle du premier socle, construit sur Wizaplace et arrêté au moment où l’architecture avait déjà prouvé ses principes essentiels.
Le hub opérateur Shopetic complète ensuite l’histoire côté vendeurs et synchronisations. Le projet d’architecture SEO Shopetic traite pour sa part les enjeux de visibilité qui dépassent la construction de ce premier frontend.
Ces pages forment un maillage chronologique utile : construire l’expérience, changer de moteur, industrialiser les flux puis travailler la visibilité. Chacune répond à un problème distinct et conserve ses propres preuves au lieu de transformer Shopetic en un projet unique aux contours indémontrables.
23. Un premier frontend qui rend Shopetic maître de son parcours catalogue
La preuve tient dans les frontières construites, pas dans un indicateur inventé
En trente-et-un jours, Dawap a relié les objets Wizaplace à onze routes publiques, organisé la découverte autour des catégories, marques et Etictos, puis protégé les lectures répétées avec Redis et trois files spécialisées. Le catalogue devient un produit Shopetic plutôt qu’un simple reflet du moteur marketplace.
Cette première génération reste volontairement décrite avec ses limites : thème encore partiellement générique, tunnel d’achat incomplet et absence de mesure commerciale avant-après. Sa valeur n’en est pas moindre. Elle montre des décisions techniques précises, une progression datée et un passage cohérent vers la génération Origami.
Pour une marketplace qui doit reprendre la main sur son expérience sans réécrire son moteur, notre accompagnement en développement frontend marketplace et notre expertise Wizaplace opérateur relient contrats API, parcours, performance et capacité d’évolution.
