AURA&CO : conception d'une vitrine mode multi-régions sur Medusa

Plateforme

Medusa 2.18

Vitrine

Next.js 15 · React 19

Couche de données

PostgreSQL · Redis · Meilisearch

Régions

Inde (₹) et États-Unis ($)

Site en ligne

Vitrine AURA&CO

Medusa fournit les briques du commerce — produits, variantes, paniers, commandes, inventaire, paiements, régions — sous forme de modules exposés par une API, et s’arrête volontairement là. Ce qu’il ne fournit pas, c’est tout ce qu’un distributeur mode considère comme la boutique : méga-menu à trois niveaux, attributs filtrables, guides des tailles, sections éditoriales en page d’accueil, consultation du stock magasin, avis. AURA&CO est notre référence pour ce besoin précis : un catalogue mode, maison et enfants à cinq rayons, sur deux régions, où chaque fonction métier est un module développé sur mesure, et non un plugin tiers à maintenir.

Pourquoi choisir Medusa pour un distributeur à catalogue large

L’intérêt de Medusa, c’est la maîtrise sans repartir de zéro. Une plateforme SaaS impose un tunnel d’achat fermé et un modèle de données auquel il faut adapter son catalogue. Un framework impose tout à construire. Medusa se situe entre les deux : le cœur commerce est solide, éprouvé et maintenu par d’autres, tandis que tout le spécifique métier devient un module à part entière — avec ses propres tables, migrations et service — traité comme natif par le reste du système.

Cette distinction structure toute l’architecture. Sept modules sur mesure couvrent l’essentiel des besoins d’un distributeur mode de taille moyenne, sans jamais modifier ni forker Medusa lui-même.

Le backend : sept modules pour les besoins métiers

Catalogue : attributs, facettes et guides des tailles

Les produits mode portent des attributs sur lesquels Medusa n’a pas d’avis — coupe, encolure, longueur de manche, longueur du vêtement, matière, motif, occasion, durabilité. Nous les avons modélisés comme un système d’attributs proche de l’EAV de Magento : une définition avec un code technique, un type de saisie et une liste de valeurs, rattachés aux produits et limités à certaines catégories.

Centraliser ces attributs permet à une seule définition d’alimenter trois surfaces différentes. Un indicateur décide si l’attribut s’affiche dans un accordéon sur la fiche produit (et lequel : description, matières ou détails), un autre s’il apparaît comme facette sur les pages catégorie, un troisième s’il entre dans l’index de recherche. Ajouter « Encolure » une seule fois l’affiche partout de façon cohérente, au lieu de le définir trois fois et de perdre la synchronisation.

• Facettes par catégorie : les filtres proposés sur Robes ne sont pas ceux de Linge de lit, car les attributs sont liés aux catégories et non globaux
• Guides des tailles : tableaux de mesures stockés en lignes, rattachés par catégorie, accessibles depuis la fiche produit
• Surcharges par produit : valeurs d’attributs libres pour les cas où une liste fermée ne suffit pas

Contenu et navigation : les éléments modifiables par les marchandiseurs

Deux modules permettent aux équipes de gérer la boutique sans solliciter un développeur pour chaque changement saisonnier. Le module contenu modélise une page comme une liste ordonnée de sections typées : barre d’annonce, carrousel principal, teaser promotionnel, teaser de mise en avant, carrousel de produits, grille de bannières, tuiles de catégories, texte enrichi, bandeau d’arguments, inscription à la newsletter. Chaque section comporte une configuration JSON, une fenêtre de planification optionnelle et une restriction régionale optionnelle : par exemple, une bannière Diwali peut être préparée à l’avance, limitée à l’Inde, et s’affichera puis disparaîtra automatiquement.

Les configurations de section sont en JSON plutôt qu’en colonnes, car dix types de sections partagent très peu de champs. Le compromis — absence de validation au niveau du schéma — est compensé des deux côtés : un formulaire typé par type de section dans l’admin, un rendu typé par section côté vitrine.

Le module navigation gère le méga-menu sous forme d’un arbre à trois niveaux : département principal, en-tête de colonne, lien. Les liens pointent vers une catégorie ou une URL brute, chaque nœud peut être marqué pour s’afficher dans la couleur d’accent, et le panneau d’image promotionnelle à droite de chaque menu fait partie des mêmes données : image, titre et appel à l’action.

Liste d’envies, avis et stock magasin réel

Les modules restants répondent chacun à un problème qui paraît mineur jusqu’à sa mise en œuvre.

• Liste d’envies : fonctionne pour les invités via un jeton anonyme, puis fusionne avec la liste du client à la connexion. Sans cette fusion, tout ce qui a été enregistré avant l’inscription est perdu au moment précis où l’acheteur s’engage.
• Avis : associés au produit et non à la variante, pour éviter que cinq avis ne se dispersent sur cinq tailles. Les nouveaux avis arrivent en attente et ne sont publiés qu’après validation par un modérateur ; le badge « acheteur vérifié » est contrôlé lors de la soumission sur l’historique de commande et enregistré, de sorte qu’un remboursement ultérieur ne puisse le modifier.
• Localisateur de magasins : chaque magasin est lié à un emplacement de stock Medusa, donc la fonction « disponible en magasin » lit les mêmes niveaux d’inventaire que ceux réservés lors du passage en caisse, et non une seconde table de stock qui dériverait.

Les index de la base de données confirment le fonctionnement du code : les avis sont indexés sur le chemin critique de la vitrine (avis approuvés pour un produit), sur la file de modération, et via un index unique partiel qui autorise un avis par client et par produit, tout en laissant les invités libres — car ils n’ont pas d’identité sur laquelle contraindre.

La vitrine : structure et routage

La vitrine utilise Next.js 15 avec l’App Router, en rendu serveur par défaut. Chaque route est imbriquée sous un segment pays, ce qui permet de déterminer la région, la devise et les moyens de paiement disponibles à partir de l’URL, et non d’un cookie qu’un robot d’indexation ne posera jamais — /in/ pour les prix en roupies, /us/ pour les dollars, les deux pleinement indexables.

Les URLs de catégories sont volontairement plates : /ladies-dresses.html, et non /categories/ladies-dresses. Une route générique les résout après les routes nommées, donc /cart et /account restent prioritaires. Les produits ne figurent que dans les catégories feuilles, donc lister un département agrège tout son sous-arbre — l’arbre est reconstruit à partir de la liste plate des catégories, car l’API ne renseigne les relations enfants qu’à un niveau de profondeur.

• Accueil : sections composées en administration, ordonnées et planifiées
• Listes de départements et de catégories : 36 par page, facettées, avec tuiles de sous-catégories et texte SEO
• Pages produit : sélection de variante et de taille, guide des tailles, accordéons d’attributs, notes et avis, disponibilité en magasin, « autres articles achetés », récemment consultés
• Recherche : page de résultats complète et saisie semi-automatique dans l’en-tête
• Favoris, magasins et pages CMS : localisateur de magasins, liste d’envies et contenus éditoriaux
• Panier, tunnel de commande en trois étapes et comptes : adresses, historique de commandes, détail et transfert de commande entre comptes

Le contenu est mis en cache et servi statiquement, puis invalidé par tag : un abonné côté backend notifie la vitrine lorsqu’un administrateur enregistre, et les tags concernés sont supprimés. Sans ce mécanisme, un marchandiseur enregistre une bannière et la page continue d’afficher l’ancienne version — ce qui lui donne l’impression que « sa modification n’a eu aucun effet ».

Recherche, facettage et merchandising

La liste et la recherche utilisent le même appel sur un index Meilisearch. Les fiches produits sont générées directement à partir des documents retournés, donc une page de 36 produits ne nécessite qu’une requête, et les comptes de facettes arrivent avec les résultats sans second passage d’agrégation. Les prix pour les deux devises, le stock par taille, le regroupement par couleur, les labels et les notes sont tous présents dans le document ; le tri par note fonctionne car les produits sans avis sont indexés à zéro et tombent naturellement en bas, sans filtrage supplémentaire.

Le rail de recommandations est l’élément sur lequel nous sommes les plus exigeants. « Autres articles achetés » est calculé à partir de l’historique réel des commandes : on identifie les commandes contenant ce produit, on compte les autres articles présents, puis on classe par fréquence. Si l’historique est insuffisant, la liste est complétée par la même catégorie, et l’API précise la provenance de chaque article, ce qui permet à la vitrine d’indiquer honnêtement la source, sans revendiquer des données d’achat inexistantes. Présenter les nouveautés de catégorie comme des recommandations est une tromperie dans l’intitulé.

Performance : ce que l’architecture apporte

Pages rendues côté serveur, une seule requête de recherche par liste, optimisation des images en périphérie du framework et absence de cascade de requêtes côté client : l’ensemble produit un résultat mesurable. Mesuré sur la page d’accueil avec Google PageSpeed Insights :

Un Cumulative Layout Shift nul sur une page d’accueil mode axée image n’est pas dû au hasard : chaque emplacement média réserve ses dimensions avant l’arrivée de l’image. Un Total Blocking Time de 40 ms sur un Android milieu de gamme bridé est le résultat du rendu côté serveur : il reste très peu de JavaScript à exécuter, car la page n’est pas arrivée comme une coquille vide à hydrater. Cette rigueur est la même que nous appliquons dans les prestations d’optimisation de la vitesse sur chaque plateforme.

Ce que l’équipe d’administration obtient réellement

Des modules personnalisés n’apportent que peu de valeur si leur utilisation impose de passer par SQL. Chaque module dispose d’une interface d’administration intégrée directement au tableau de bord de Medusa, et non d’un outil secondaire ajouté : gestion des attributs et des guides des tailles avec sélection des facettes par catégorie, éditeur de pages pour composer et planifier l’accueil ou les pages d’atterrissage, arborescence de navigation ordonnée par glisser-déposer, file de modération des avis, gestion du magasin.

Les pages produit et catégorie intègrent des widgets sur place — valeurs d’attributs sur le produit, configuration du contenu et des facettes sur la catégorie — pour que le travail se fasse là où le merchandiser intervient déjà. C’est le critère concret d’une architecture composable : l’équipe achat modifie la boutique sans ouvrir de ticket, et l’équipe technique ne bloque pas la mise en ligne d’une bannière.

Les compromis à nommer

Le composable a un coût. Vous assumez la maintenance des modules développés, leurs migrations et leur évolution. Redis devient indispensable dès que l’on dépasse un processus unique : cache, bus d’événements et moteur de workflows reposent dessus, car les valeurs en mémoire perdent silencieusement les événements dès que serveur et worker sont séparés. La recherche constitue un second système à maintenir et réindexer. Le classement des achats croisés est calculé en mémoire sur un échantillon limité de commandes récentes — un choix adapté à ce volume de catalogue, mais qui ne convient plus à dix fois l’échelle, où il faut pré-calculer à la validation de commande.

Ce n’est pas un argument contre cette pile technique. C’est la raison pour laquelle nous chiffrons chaque mission headless commerce en intégrant le coût opérationnel dès le départ.

Vous envisagez Medusa pour votre catalogue ?

Si vous hésitez entre une architecture composable et le maintien sur une solution SaaS, la vraie question n’est pas la plateforme, mais de savoir quelles parties de votre logique métier sont réellement spécifiques et lesquelles relèvent du standard. Échangez avec notre équipe technique : nous revenons vers vous sous un jour ouvré avec une estimation claire du périmètre, du séquencement et du coût.