Le projet en un coup d’œil
Douze jours après le dernier jalon Wizaplace, une nouvelle application démarre autour des contrats Origami. Elle reprend l’enjeu du frontend tout en élargissant fortement son périmètre.
Les données Origami sont projetées dans Algolia pour la recherche et dans un CMS local pour les slugs, les textes et les combinaisons SEO, sans perdre la source transactionnelle.
Le catalogue, les variantes, le panier, la livraison, LemonWay, l’espace client, les traitements planifiés et 244 scénarios de test forment une application durablement travaillée.
Le 28 mars 2022, Shopetic ouvre une nouvelle génération de son frontend. La précédente, raccordée à Wizaplace, avait posé les premiers principes de séparation entre expérience et moteur marketplace. Avec Origami, l’ambition devient transactionnelle : rechercher une offre, comprendre pourquoi elle est engagée, choisir une variante, construire un panier multivendeur, sélectionner la livraison, payer puis retrouver ses commandes.
Dawap a fait évoluer cette application pendant vingt-sept mois. Le frontend Symfony ne se contente pas d’afficher les réponses d’Origami. Il organise trois responsabilités complémentaires : Origami pour les objets de commerce, Algolia pour la recherche à facettes et un CMS local pour les slugs, les contenus, les images et les combinaisons SEO. Cette composition illustre notre travail de frontend marketplace sur mesure.
La trajectoire montre aussi la vie réelle d’un produit : lancement rapide, montée en richesse, corrections de panier et de livraison, refontes de cache, optimisation mobile, retrait de fonctions devenues inadaptées et dernier correctif d’ajout au panier en juillet 2024. L’histoire repose sur ces transformations observables, sans leur substituer un atelier, un sprint ou un résultat commercial impossible à établir.
1. Shopetic, une expérience marchande structurée par les engagements
Faire dialoguer produit, vendeur, catégorie, marque et Etictos
Shopetic ne classe pas seulement son catalogue par familles de produits. Une offre doit aussi pouvoir être découverte par sa marque, le vendeur qui l’expédie et les critères d’engagement regroupés sous le nom Etictos. Ces axes répondent à des intentions différentes et doivent rester lisibles lorsqu’ils se combinent.
Cette richesse crée une difficulté que le moteur transactionnel ne résout pas seul. Une catégorie peut croiser une marque, un vendeur ou un Etictos ; une marque peut être parcourue par catégorie et engagement ; une fiche produit doit expliquer les raisons associées à ses Etictos sans perdre l’offre, le stock ni les variantes.
La marketplace doit parallèlement assurer les gestes ordinaires du commerce : inscription, panier invité ou connecté, adresses, choix de livraison, coupon, paiement et historique de commandes. Le projet relie donc une promesse éditoriale spécifique à une chaîne transactionnelle concrète.
Enfin, Shopetic doit garder la main sur ce que les moteurs de recherche découvrent. Les objets Origami reçoivent des correspondances locales, des slugs et des contenus. Les pages combinées ne sont produites que lorsqu’elles relient des objets réellement exploitables, afin d’éviter une infinité d’adresses vides.
2. Faire évoluer le produit par vagues fonctionnelles vérifiables
Fondations au printemps 2022, commerce en été, industrialisation puis optimisation continue
La première vague, de fin mars à avril 2022, installe l’architecture, les contrats Origami, Algolia, l’inscription, les correspondances de catégories, marques, vendeurs et Etictos, puis le CMS SEO et les premières commandes de sitemap. L’expérience de découverte possède déjà ses objets propres.
Mai et juin transforment cette base en site marchand. Les produits et leur pagination rejoignent Algolia, les facettes sont mutualisées, les images sont préparées localement, le panier accepte un visiteur non connecté, les adresses et modes de livraison apparaissent, puis le paiement et les commandes vendeurs sont raccordés.
De juillet à octobre 2022, les traitements longs basculent dans RabbitMQ, les adresses par identifiant sont redirigées vers les slugs, les index et sitemaps sont planifiés, le catalogue écarte les produits désactivés et la version mobile de la fiche produit est approfondie. Une API protégée expose aussi plusieurs contenus internes.
L’année 2023 consolide l’exploitation : cache produit refondu, WebP, canoniques et pagination SEO, croisements catégorie-marque-vendeur-Etictos, cartes cadeaux, variantes multiples, filtres mobiles et contenus de réassurance. En 2024, la carte cadeau est arrêtée et le dernier correctif porte sur l’ajout au panier : la trajectoire inclut donc les retraits autant que les ajouts.
3. Douze jours après Wizaplace, repartir sur les contrats Origami
Une nouvelle application plutôt qu’un changement de nom dans l’ancienne
La génération Wizaplace s’arrête le 16 mars 2022. Le 28 mars, une nouvelle base est initialisée pour Origami. Le domaine, les contrats d’authentification et de catalogue, l’infrastructure et les gabarits sont recréés autour du nouveau fournisseur de marketplace.
Cette proximité chronologique ne permet pas d’inventer la raison commerciale du changement. Elle prouve en revanche un passage de relais net : les deux applications ont leurs propres historiques, leurs propres structures et des profondeurs fonctionnelles très différentes.
Le premier frontend avait démontré la recherche, les facettes, les catégories, les marques et les Etictos. Le nouveau projet conserve ces responsabilités d’expérience, puis les développe autour des concepts Origami : produits, variantes, offres, vendeurs, paniers, sous-commandes vendeurs, expéditions et transactions.
L’enjeu n’est donc plus seulement de rendre un catalogue navigable. Shopetic doit posséder une application capable d’absorber les changements du moteur sur la durée, de produire ses propres pages SEO et d’accompagner l’acheteur jusqu’après le paiement.
4. Construire un produit marchand sans recopier tout Origami
Choisir la bonne source pour chaque responsabilité du frontend
Origami reste la source des objets transactionnels. Produits, variantes, offres, vendeurs, paniers, modes de livraison, commandes et paiements sont lus ou modifiés au travers de ses API. Le frontend ne cherche pas à devenir un second moteur marketplace.
La recherche possède toutefois d’autres contraintes : réponse rapide, texte libre, facettes nombreuses et filtres combinés. Algolia reçoit donc une projection du catalogue conçue pour la découverte. L’index peut être reconstruit ou actualisé sans modifier l’objet commercial d’origine.
Le contenu SEO demande encore une autre temporalité. Shopetic conserve localement les correspondances de produits, catégories, marques, vendeurs, labels, matières, critères écoresponsables et slugs. Ces objets éditoriaux enrichissent les pages sans polluer les contrats transactionnels.
Le dernier objectif est la continuité. Chaque couche doit pouvoir être contrôlée, rafraîchie et réparée indépendamment. Une offre qui change dans Origami, un produit absent de l’index ou une page sans contenu ne relèvent pas de la même correction ; l’architecture doit rendre cette différence visible.
5. Faire coopérer Origami, Algolia et le CMS Shopetic
Une source de transaction, une projection de recherche et une mémoire éditoriale
Le navigateur demande une page Symfony. Le contrôleur collecte d’abord les correspondances locales nécessaires au slug et au contenu, interroge Algolia pour les listes ou Origami pour le détail transactionnel, puis transmet au gabarit des objets propres au domaine Shopetic.
Cette composition évite deux écueils. Appeler Origami pour chaque filtre rendrait la découverte trop dépendante d’un contrat transactionnel. Copier toutes les données dans le CMS créerait au contraire une seconde vérité difficile à maintenir. Chaque système reste utilisé pour ce qu’il sait faire.
Les cas d’usage sont séparés des implémentations HTTP, Algolia et Doctrine. Les contrôleurs travaillent avec des requêtes et des présentateurs ; les adaptateurs transforment ensuite les réponses externes. Une règle de catalogue peut ainsi être testée avec une source en mémoire.
L’application atteint 2 312 fichiers PHP et 232 gabarits Twig au terme de la trajectoire. Ces volumes ne sont pas affichés comme une performance. Ils donnent l’échelle d’un produit qui réunit expérience publique, commerce, administration, API, traitements planifiés et supervision.
6. Encapsuler les ressources Origami au lieu de diffuser leur format
Quarante-sept adaptateurs de lecture et d’écriture autour des domaines marchands
La couche d’intégration couvre catalogue, vendeurs, clients, panier, commandes, livraison, paiement, avis, tickets, tableaux de bord et configuration. Chaque ressource dispose d’un contrat ciblé plutôt que d’un client API universel manipulé depuis les pages.
Origami permet d’enrichir certaines réponses avec le paramètre `include`. Une fiche produit peut demander caractéristiques, variantes, attributs, offres, images, catégories et vendeur. Le frontend reçoit ainsi les relations nécessaires sans supposer qu’elles sont toujours présentes par défaut.
Les différences de réponse sont converties dans des entités de lecture. Le panier, par exemple, sépare les sous-paniers vendeurs, leurs lignes, leurs modes de livraison, leurs coupons et leurs adresses. Cette structure conserve la nature marketplace de la commande.
Les appels opérateur utilisent un jeton géré côté serveur. L’authentification publique et l’API interne possèdent des mécanismes distincts : session pour le site, contrôle stateless par jeton pour les routes `/api`. Cette séparation réduit le risque de confondre identité acheteur et droit d’intégration.
7. Projeter le catalogue dans Algolia pour servir la découverte
Texte libre, facettes métier et synchronisations à plusieurs profondeurs
Algolia entre dans le projet dès le 11 avril 2022 et alimente la recherche publique deux jours plus tard. Le document indexé réunit l’identité produit, le vendeur, la marque, les catégories, les Etictos, la variante par défaut, les prix, le stock et les attributs utiles aux filtres.
Le moteur traduit les filtres publics vers les noms de facettes françaises : marques, catégories, Etictos, vendeurs, contenances, tailles, couleurs, matières et dimensions. Les valeurs d’un même groupe peuvent être combinées, tandis que la recherche principale alimente la requête textuelle.
L’actualisation accepte une fenêtre temporelle. La configuration d’exploitation finit par associer trois profondeurs : soixante jours chaque nuit, deux jours toutes les six heures et quatre heures toutes les trente minutes. Les produits désactivés, en attente ou supprimés possèdent leurs propres commandes de retrait.
Cette stratégie reconnaît qu’un index de recherche est une projection, pas la vérité transactionnelle. Un produit retiré dans Origami doit aussi disparaître d’Algolia ; un changement récent doit remonter vite ; une fenêtre profonde répare les événements manqués sans reconstruire tout l’index à chaque passage.
8. Créer une mémoire éditoriale autour des identifiants Origami
Correspondances, slugs, contenus et visibilité gérés localement
Le CMS local commence avec les slugs en avril 2022. Il s’étend ensuite aux correspondances de catégories, marques, vendeurs, Etictos, produits, labels, matières et critères écoresponsables. Chaque objet conserve son identifiant Origami tout en recevant ses informations de présentation.
Une correspondance peut décider si une marque ou une catégorie doit apparaître dans les listes publiques. Elle peut porter une image, une description, des métadonnées et un slug. Le frontend n’a donc pas à déduire automatiquement une page publique de chaque objet technique reçu.
Trente-quatre routes d’administration couvrent la recherche, l’ouverture, la création ou la modification de ces contenus. Elles ne constituent pas un CMS générique vendu séparément : elles donnent à Shopetic les commandes nécessaires pour faire vivre précisément son catalogue.
Le produit peut être actualisé depuis Origami puis rapproché de sa mémoire locale. Cette relation autorise une réindexation Algolia, une régénération d’image ou une reconstruction de page sans perdre le contenu rédigé pour Shopetic.
9. Déployer 29 routes pour croiser quatre axes de découverte
Marque, vendeur, catégorie et Etictos sans dupliquer le moteur de recherche
Le frontend contient vingt-neuf routes consacrées aux listes, fiches et combinaisons de marques, vendeurs, catégories et Etictos. La marque peut être parcourue par catégorie ou par engagement ; le vendeur par catégorie et Etictos ; l’Etictos par vendeur et catégorie.
Chaque combinaison possède une adresse explicite. Une page `/marques/.../categories/...` n’est pas une recherche opaque avec plusieurs paramètres : elle identifie un croisement que le contenu, le fil d’Ariane, le titre et le sitemap peuvent décrire.
Le moteur de recherche reste pourtant commun. Le contrôleur résout les objets locaux, ajoute leurs valeurs aux facettes Algolia et demande les produits correspondants. Cette mutualisation empêche la logique de stock, de pagination et de filtre de diverger entre vingt-neuf parcours.
Le risque d’une telle richesse est de générer des pages sans offre. Le projet ajoute donc des règles de visibilité, des redirections lorsque la combinaison n’a pas de produit et des générateurs qui parcourent les correspondances disponibles. La combinatoire devient contrôlée plutôt qu’automatique.
10. Industrialiser les slugs, canoniques et sitemaps
Cinq générateurs spécialisés pour produits, marques, catégories, Etictos et vendeurs
Le SEO devient une fonction explicite dès avril 2022. Des objets de type et de slug sont administrables, puis cinq commandes construisent les adresses des produits, marques, catégories, Etictos et vendeurs. Les combinaisons pertinentes rejoignent également leurs fichiers sitemap.
La génération produit traite cent correspondances par page. Les commandes des autres univers parcourent leurs objets visibles et leurs croisements autorisés. La production peut ainsi fractionner les fichiers, conserver une version précédente pendant le remplacement et éviter qu’une génération longue rende le sitemap indisponible.
L’été 2023 approfondit la cohérence des canoniques, des titres, des descriptions, des H1 et de la pagination. Les liens précédent et suivant apparaissent sur les catégories ; les paramètres inutiles sont retirés ; les images reçoivent progressivement textes alternatifs et formats WebP.
La page n’attribue aucun gain de trafic à ces travaux. Leur résultat vérifiable est structurel : les objets marketplace possèdent une adresse lisible, les croisements disposent de règles d’indexation et les pages peuvent être régénérées lorsque le catalogue évolue.
11. Faire de la fiche produit le point de rencontre des trois couches
Détail Origami, découverte Algolia et contenu Shopetic réunis dans une même page
La fiche part du slug local, retrouve le produit puis collecte dans Origami ses caractéristiques, variantes, offres, images, catégories et vendeur. Les informations de contenu et de visibilité viennent du CMS ; les suggestions et filtres utilisent la projection Algolia.
L’adresse historique par identifiant possède une redirection vers le slug. Une ressource absente ou désactivée ne doit pas rester affichée parce qu’elle existe encore dans un index. Le contrôle de la source et du mapping protège la cohérence de la page.
Le visiteur retrouve la marque, le vendeur qui expédie, les raisons associées aux Etictos, les images, le prix et les offres. Des produits similaires complètent la découverte. La version mobile reçoit son propre travail de hiérarchie, d’images, d’accès aux variantes et d’ajout au panier.
Les images principales sont progressivement générées en WebP pour les usages de recherche, d’accueil et de panier. Les images du carrousel peuvent être récupérées dans une file dédiée. La page ne dépend donc pas uniquement de la disponibilité immédiate du média distant.
12. Rendre la variante choisie compatible avec le stock et l’offre
Taille, couleur et options multiples doivent conduire au bon identifiant marchand
Dès mai 2022, l’index conserve une variante par défaut, son prix et son stock. La fiche permet ensuite de sélectionner une variante depuis la requête. Le parcours doit relier l’option visible à l’offre exacte utilisée lors de l’ajout au panier.
Les corrections de 2023 traitent les cas où la variante n’existe pas, la navigation mobile vers la variante par défaut et l’affichage de plusieurs options. En septembre, la couleur et les combinaisons multiples reçoivent une présentation spécifique.
La quantité demandée est comparée à celle de l’offre collectée dans Origami. Si elle dépasse le disponible, le panier la ramène au stock annoncé et informe l’acheteur. La protection se situe avant la création ou la mise à jour de la ligne.
Le dernier jalon du 2 juillet 2024 corrige encore l’ajout au panier. Cette date rappelle qu’une variante n’est pas une décoration de fiche : elle traverse produit, offre, stock, formulaire, panier et commande, et reste un point sensible même après deux années d’exploitation.
13. Construire un panier qui conserve la structure multivendeur
Onze routes pour créer, modifier, livrer, réduire et payer
Le panier possède onze routes : affichage, ajout, modification de quantité, suppression, saisie des adresses, choix des transports, validation, paiement, application ou retrait d’un code et gestion de la carte cadeau. Cette surface couvre les gestes transactionnels du frontend.
Un visiteur non connecté peut créer son panier. Son identifiant est conservé en session et le détail alimente le panneau latéral. Lorsqu’un utilisateur est connu, le panier peut recevoir son identifiant client afin de poursuivre le parcours sans repartir de zéro.
Origami renvoie une structure par vendeur. Chaque sous-panier possède ses lignes, son vendeur, ses modes de livraison et ses réductions. Le frontend maintient cette séparation jusqu’à la commande, car les frais et l’expédition ne peuvent pas être calculés comme un panier monovendeur.
Les corrections de juin 2022 puis de 2023 portent sur les sommes affichées, l’association au compte, la quantité disponible, le panneau latéral et les formulations. Le panier est ainsi traité comme un parcours durablement observé, pas comme une page livrée une fois.
14. Passer des adresses au paiement LemonWay sans perdre les vendeurs
Transport par sous-panier, transaction Origami puis confirmation asynchrone du PSP
Après la validation des adresses, chaque sous-panier vendeur reçoit ses propositions de livraison. Le choix met à jour les frais et le total. Les corrections historiques traitent notamment l’absence de prix de transport, l’affichage du franco et le numéro de téléphone requis sur l’adresse.
Au paiement, le frontend recalcule le montant TTC du panier et retranche les montants de cartes cadeaux éventuellement retenus. Si un solde reste dû, il demande à Origami de créer une transaction en euros, avec une adresse de retour navigateur et une adresse de notification serveur pour LemonWay.
La notification confirme ou refuse la transaction. En cas de succès, les sous-commandes vendeurs sont créées avec la transaction correspondante ; un appel d’intégration transmet ensuite les informations nécessaires au traitement opérationnel. Le retour visible vérifie que la commande existe avant de la présenter comme terminée.
Le projet ne revendique pas un taux de paiement ni une absence d’incident. Il prouve la chaîne : panier, livraison, transaction, retour, notification, commandes vendeurs et signal opérationnel. Les nombreux correctifs montrent que chaque frontière a été travaillée dans le temps.
15. Prolonger le parcours dans un espace client et une messagerie
Inscription, commandes, retours, avis et tickets réunis après l’achat
L’inscription apparaît dès le 19 avril 2022 puis s’enrichit des adresses et du téléphone. Le compte local et l’identité client Origami doivent rester cohérents afin que le panier, la commande et l’historique rejoignent le même acheteur.
Neuf routes sous `/mon-espace` couvrent le tableau de bord, la modification du profil, les commandes et leur détail, les messages, les retours et la création d’un avis. Les pages d’authentification et de réinitialisation complètent cette continuité.
Le ticket permet de contacter l’équipe ou un vendeur autour d’un sujet suivi. Les avis possèdent leurs critères et leur création propre. Ces fonctions évitent que la relation après paiement se limite à une page de succès impossible à retrouver.
La profondeur réelle varie selon les fonctions et aucun délai de réponse ou taux de résolution n’est disponible. Le gain démontré tient au raccordement : l’acheteur authentifié retrouve les objets issus de sa commande dans le même produit web.
16. Donner à l’opérateur des outils de contenu et de diagnostic
Administration CMS, supervision et onze routes API protégées
Le back-office réunit les correspondances CMS, les slugs, les contenus clés, les produits et plusieurs écrans de configuration ou de supervision. Trente-quatre routes se concentrent sur la matière éditoriale du catalogue.
Onze routes API exposent en lecture marques, catégories, vendeurs, Etictos, labels, matières, critères écoresponsables, produits et slugs. Une route d’écriture actualise le score d’un produit. La zone `/api` est stateless et protégée par jeton.
La mise à jour d’un score peut déclencher la projection du produit vers Algolia. Une opération éditoriale locale peut donc se propager à la recherche sans attendre le prochain passage planifié, tout en conservant la commande de rattrapage.
Des suivis enregistrent aussi les commandes de synchronisation et l’état du cache produit. L’objectif n’est pas de promettre un observatoire exhaustif : il s’agit de rendre identifiables les traitements qui relient Origami, la mémoire locale, les images et l’index.
17. Faire évoluer le cache avec la maturité du catalogue
Redis, présentateurs dédiés et préchauffage des pages à forte réutilisation
Redis porte le cache applicatif. Les versions finales des présentateurs conservent pendant sept jours les fiches produit, les pages de catégorie, les pages de marque et certaines collections produit. Plusieurs combinaisons plus spécifiques utilisent une durée d’un jour.
Une durée longue ne suffit pas. Le projet ajoute des commandes de préchauffage pour produits, Close listing, marques, catégories et tableau de bord. L’exploitation peut préparer les pages avant leur prochaine visite plutôt que d’attendre la première requête.
Les refontes de mars et juin 2023 montrent que la stratégie a évolué. L’appel du panier est retiré de l’en-tête pour alléger les pages ; le cache produit est reconstruit ; la pagination des listes reçoit une limite de profondeur ; les clés de marque prennent mieux en compte l’adresse.
La page ne transforme pas ces choix en score de performance. Elle montre une boucle d’amélioration : identifier ce qui coûte à chaque affichage, déplacer ou mémoriser la bonne responsabilité, puis ajuster la fraîcheur lorsque les données marchandes l’exigent.
18. Distribuer les images, caches et enrichissements dans sept files
Des consommateurs supervisés et des planifications à plusieurs cadences
Sept transports RabbitMQ sont configurés : trois pour le préchauffage de pages, deux pour les images produit, un pour les Etictos produit et un pour la génération de correspondances produit. Une file d’échec recueille les messages qui ne peuvent pas aboutir.
Les consommateurs tournent sous Supervisor avec une limite de temps, afin d’être relancés sans conserver indéfiniment le même processus. Cette organisation sépare une image défaillante d’une page catégorie ou d’une synchronisation de contenu.
Les tâches planifiées orchestrent aussi Algolia, les retraits d’index, les cinq familles de sitemap et le préchauffage. Les cadences diffèrent : mise à jour récente fréquente, rattrapage plus profond moins souvent, contenu SEO à l’échelle du jour et tableau de bord toutes les deux minutes dans la configuration finale.
L’historique montre enfin que certaines tâches ont été ralenties ou arrêtées, notamment les images et une partie des contenus produit. Une planification n’est pas figée : son coût, sa fraîcheur utile et les capacités du moteur doivent être réévalués pendant l’exploitation.
19. Maintenir 244 scénarios automatisés sur trois niveaux
Règles métier, contrats d’intégration et parcours applicatifs
Cent trente-cinq fichiers contiennent au moins un test actif, pour un total de deux cent quarante-quatre méthodes. Le corpus couvre des tests unitaires, des tests d’intégration et des tests applicatifs de contrôleurs.
Les règles de catalogue, CMS, panier, livraison, client, vendeur, SEO et paiement peuvent être exercées sans toujours lancer le navigateur. Des sources en mémoire isolent les cas d’usage ; les tests d’intégration vérifient plusieurs contrats Origami ; les tests applicatifs contrôlent les routes et les réponses.
La chaîne de construction produit des images distinctes pour PHP et Nginx, puis utilise des configurations de validation et de production. Redis, RabbitMQ, volumes d’images et sitemaps sont déclarés dans ces environnements afin de réduire l’écart avec l’exploitation.
Le nombre de tests décrit l’effort de contrôle, pas un taux de couverture ni un état actuel « zéro défaut ». Le dernier correctif panier de 2024 et les multiples corrections de production rappellent qu’une marketplace reste un système vivant malgré un corpus automatisé conséquent.
20. Lire les 27 mois comme une succession de problèmes résolus
Recherche, commerce, SEO, mobile puis maintien en conditions réelles
Le printemps 2022 construit la profondeur fonctionnelle. L’été transforme les prototypes en parcours raccordés : panier invité, client, livraison, LemonWay, sous-commandes, index planifié, images locales, redirections et sitemaps. Octobre ajoute supervision, purge d’index et seconde génération de catégories.
Le début 2023 absorbe une nouvelle version d’API Origami, corrige les frais de livraison et poursuit l’optimisation mobile. Au printemps, la fiche produit, les multicatégories, les files de correspondance et le cache sont repris. Juin et juillet concentrent un chantier SEO transversal.
Septembre 2023 améliore l’usage des facettes et des variantes sur mobile. Octobre enrichit les explications Shopetic et l’équipe présentée. Novembre réduit la fréquence des traitements CMS et arrête le traitement d’images devenu inadapté à cette cadence.
En février 2024, le mode carte cadeau est arrêté. Le 2 juillet, l’ajout au panier reçoit son dernier correctif. Ces dernières dates donnent une fin honnête à la fiche : elles documentent la maintenance et les choix de retrait, pas un faux lancement unique placé arbitrairement en 2024.
21. Les arbitrages qui empêchent l’architecture de devenir un empilement
Projeter, limiter, retirer et réparer au lieu de tout conserver
Le premier arbitrage est la projection Algolia. La recherche ne sollicite pas Origami à chaque facette, mais elle accepte alors la responsabilité de synchroniser, purger et réparer l’index. Les fenêtres multiples répondent directement à ce compromis.
Le deuxième concerne la combinatoire SEO. Vingt-neuf routes donnent une grande finesse de découverte ; les correspondances, la visibilité, les redirections et les sitemaps doivent empêcher la création de pages vides. Une combinaison possible n’est pas automatiquement une page utile.
Le troisième est le cache. Sept jours conviennent aux pages préchauffées qui changent peu, tandis que prix, stock, panier et paiement restent attachés aux appels transactionnels. Le frontend ne peut pas appliquer la même fraîcheur à une description de marque et à une quantité disponible.
Le quatrième est le retrait. La carte cadeau a été développée jusqu’au paiement mixte, puis désactivée en 2024. Les tâches d’images sont réduites, d’anciens contrôleurs sont nettoyés et certaines routes historiques ne servent plus que de redirection. La maintenance inclut le droit de supprimer.
22. Ce qui change entre mars 2022 et juillet 2024
D’un nouveau contrat API à une marketplace complète dans ses responsabilités essentielles
Au départ, l’application contient les premiers contrats d’authentification et de catalogue Origami. À la fin, Shopetic possède une expérience publique où produits, marques, vendeurs, catégories et engagements se croisent sans exposer les identifiants du moteur.
La découverte devient une fonction autonome : index Algolia, facettes métier, slugs et contenus locaux, vingt-neuf routes spécialisées, cinq générateurs SEO et des règles de retrait pour les références qui ne doivent plus apparaître.
Le commerce relie onze actions panier à la livraison, au paiement LemonWay, aux sous-commandes vendeurs et à l’espace client. La marketplace ne s’arrête plus au catalogue ; elle conserve la structure multivendeur jusqu’à la confirmation et au suivi.
L’exploitation gagne des leviers séparés : trente-quatre routes CMS, onze routes API, sept files, plusieurs cadences de synchronisation et deux cent quarante-quatre scénarios automatisés. Aucun chiffre de vente n’est nécessaire pour constater cette transformation fonctionnelle.
23. Le scénario qui relie engagement, variante et commande
Trouver un produit par Etictos puis conserver la bonne offre jusqu’au paiement
Une acheteuse part d’un Etictos et l’associe à une catégorie. Le frontend résout les deux slugs dans le CMS, confirme leur visibilité puis transmet les facettes correspondantes à Algolia. La page ne montre que les produits indexés pour cette combinaison.
Elle ouvre une fiche. Shopetic retrouve le mapping local, collecte dans Origami les variantes, les offres, les images et le vendeur, puis affiche les raisons liées à l’engagement. Sur mobile, elle choisit une couleur et une seconde option ; le formulaire conserve l’identifiant de l’offre associée.
Lors de l’ajout, la quantité est comparée au stock de cette offre. Le panier de session est créé ou actualisé, puis la ligne rejoint le sous-panier du vendeur. L’adresse et le mode de livraison complètent ce sous-ensemble avant le calcul du total.
Le paiement crée une transaction en euros et redirige vers LemonWay. La notification de succès revient côté serveur ; Origami produit les commandes vendeurs et le frontend les rattache au parcours client. Une recherche éditoriale devient ainsi une opération transactionnelle sans perdre le vendeur ni la variante choisis.
24. Relier les trois projets Shopetic sans les fusionner
Premier frontend, génération Origami, hub opérateur et travail SEO
Le premier frontend Shopetic sur Wizaplace raconte le socle de 31 jours qui précède cette génération. Il explique la recherche, les facettes et la séparation initiale du moteur, sans revendiquer la profondeur transactionnelle acquise ensuite.
Le hub opérateur Shopetic traite un autre problème : intégrer les catalogues vendeurs depuis Shopify ou WooCommerce, les rapprocher d’Origami et surveiller leurs synchronisations. Cette responsabilité n’appartient pas au frontend acheteur.
Le projet d’architecture SEO Shopetic prolonge les choix de slugs, canoniques, sitemaps et performance avec une lecture dédiée à la visibilité. Il ne remplace pas les fonctions SEO déjà construites ici.
Enfin, notre expertise Origami pour opérateurs replace cette réalisation dans une capacité plus large : concevoir l’expérience, encadrer les contrats du maker et organiser la vie des données autour de la marketplace.
25. Une marketplace qui a appris à évoluer sans perdre ses frontières
Origami, Algolia et le CMS restent distincts, mais servent le même parcours
La réussite de Shopetic ne tient pas à un écran isolé. Elle vient de la continuité entre une recherche par engagement, une fiche enrichie, une offre et sa variante, un panier multivendeur, une livraison, une transaction LemonWay et un compte capable de retrouver la commande.
Vingt-sept mois d’évolution montrent aussi la face durable du travail : index réparés, canoniques repris, cache refondu, mobile amélioré, traitements ralentis et carte cadeau arrêtée. Le projet n’est pas figé dans une photographie flatteuse ; il raconte les décisions qui maintiennent un produit exploitable.
Pour construire ce type de continuité, notre accompagnement en frontend marketplace sur mesure, en SEO technique marketplace et en back-office opérateur relie expérience, données et exploitation sans confondre leurs responsabilités.
