Blissports × Wizaplace : 17 mois pour bâtir une marketplace sportive responsable

1. Blissports, une marketplace pensée autour du sport et du choix responsable

Faire découvrir un équipement par son usage autant que par sa fiche catalogue

Blissports réunit une offre sportive qui traverse plusieurs familles : équipements, vêtements, chaussures et bien-être. Cette diversité change la navigation. Un pratiquant peut chercher un article par catégorie classique, mais aussi commencer par son sport ou vouloir découvrir une marque avant d’examiner les déclinaisons disponibles.

La proposition de valeur ajoute une deuxième lecture au catalogue. Les produits peuvent être qualifiés selon trois familles de critères : éco-matière, planète préservée et respect de l’humain. Ces informations doivent rester visibles dans les listes, les filtres et les fiches sans transformer la recherche en questionnaire difficile à utiliser.

Le parcours est enfin celui d’une marketplace. Le panier peut regrouper plusieurs groupes de livraison, le moyen de paiement vient de Wizaplace et une validation peut produire plusieurs commandes. L’interface doit rendre ce fonctionnement compréhensible pour l’acheteur tout en conservant les identifiants nécessaires au suivi.

Le travail ne portait donc pas sur une vitrine connectée à un catalogue. Il fallait créer le site marchand public, le compte client et les mécanismes d’exploitation qui permettent aux pages de rester disponibles lorsque les appels au moteur marketplace deviennent nombreux.

2. Prototyper, reconstruire, puis enrichir le produit par étapes

La chronologie réelle révèle les arbitrages sans inventer une méthode de projet

La première génération apparaît le 27 janvier 2021 sur Symfony 4.4. Elle installe les échanges Wizaplace et ouvre déjà des vues de commandes et de retours. Le 5 février, une refonte des échanges API clôt cette phase. Ce prototype donne une première forme aux dépendances majeures du site.

Le 8 février, une nouvelle base Symfony 5.2 est créée. Le cache produit arrive dès le premier jour ; l’authentification, la recherche, les vendeurs sur les fiches et le panier suivent au cours du mois. Ce redémarrage très tôt dans la trajectoire évite de faire porter toute l’ambition produit au prototype initial.

Les mois suivants ajoutent des usages concrets plutôt qu’un grand remplacement final : alternatives responsables, comportements de don, ajustements du panier, filtres, promotions, navigation mobile, routines de cache, configuration de production et données e-commerce pour la mesure des fiches produit.

La progression est lisible dans les versions successives : poser la chaîne transactionnelle, approfondir l’expérience responsable, puis renforcer l’exploitation et la mesure. Ce déroulé suffit à comprendre le pilotage technique du produit sans lui attribuer une méthode ou des rituels qui ne sont pas établis.

3. Valider les échanges essentiels dans une première génération

Dix jours de calendrier pour faire apparaître le parcours marketplace

Le prototype Symfony 4.4 commence le 27 janvier 2021. Il ne se limite pas à une page d’accueil : ses contrôleurs couvrent déjà le catalogue, le panier, les catégories, les produits et plusieurs espaces du compte client. Les commandes et les retours possèdent leurs propres vues dès le premier jour de travail observé.

Cette version installe les briques de connexion à Wizaplace côté opérateur et côté utilisateur. Elle structure aussi l’authentification, les informations du compte, les adresses, les messages, la newsletter et le service après-vente. Le produit complet est ainsi esquissé avant que l’interface ne soit approfondie.

Le 5 février, les échanges API sont refactorisés. Cette étape ferme une séquence courte mais utile : l’équipe connaît désormais les domaines à séparer, les données nécessaires à chaque page et les endroits où une nouvelle architecture devra absorber davantage de règles Blissports.

4. Repartir trois jours plus tard sur Symfony 5.2

Faire du prototype un apprentissage, pas une contrainte permanente

Le nouveau projet démarre le 8 février 2021 avec Symfony 5.2 et PHP 7.4 ou supérieur. Ce choix n’est pas présenté comme une migration progressive : une base neuve est créée, puis les fonctions utiles sont réintroduites et développées dans une structure plus large.

Le volume final reflète le changement d’échelle. La seconde génération réunit 139 fichiers PHP, 71 gabarits Twig et 29 fichiers de tests d’intégration API. Ces nombres ne mesurent pas à eux seuls la qualité, mais ils montrent que le projet dépasse largement un thème visuel posé sur le moteur marketplace.

La décision donne aussi de la place aux besoins qui n’existaient pas encore dans le prototype : cache distribué, messages asynchrones, enrichissement responsable, menus générés, promotions, données e-commerce et routines d’exploitation. Le socle peut évoluer sans enfermer chaque nouvelle règle dans les contrôleurs publics.

5. Séparer l’expérience Blissports des échanges Wizaplace

Vingt et un services organisent les intentions opérateur et utilisateur

La couche opérateur compte seize services d’échange. Ils couvrent notamment le CMS, le panier, les attributs catalogue et PIM, les catégories, les vendeurs, les commandes, les produits, les promotions, les modes de livraison, les traductions, les slugs et les utilisateurs.

Cinq services distincts portent les actions liées à l’utilisateur connecté : panier, favoris, commandes, profil et façade d’accès commune. Cette séparation évite d’employer une capacité opérateur pour une action qui doit respecter l’identité et les droits de l’acheteur.

Les contrôleurs publics demandent une intention métier à ces services au lieu de construire chaque appel distant dans la page. Pour Blissports, cela rend la frontière plus lisible : Wizaplace reste la source transactionnelle ; Symfony compose les écrans, les règles de navigation, le cache et les réponses propres au site.

6. Traduire un catalogue marketplace en univers sportif

Ne pas imposer à l’acheteur la structure technique du moteur

Le catalogue alimente des pages de catégories, de sports, de marques, de promotions et de produits. Chaque porte d’entrée correspond à une intention différente. Le site ne force donc pas tous les visiteurs à commencer par une arborescence générique avant de retrouver leur pratique.

Les attributs Wizaplace sont repris dans une couche métier qui distingue attributs de catalogue, attributs PIM, facettes et variantes. Cette organisation permet d’afficher les informations utiles au bon endroit : filtre dans une recherche, détail dans une fiche ou repère responsable dans une vignette.

Les slugs et les traductions disposent eux aussi de services dédiés. La page publique peut conserver des adresses compréhensibles et des contenus adaptés, tandis que les identifiants distants restent disponibles pour demander le produit, la catégorie ou la marque correspondante au moteur.

7. Entrer dans l’offre par le sport, la marque ou la catégorie

Trois façons de chercher sans dupliquer le catalogue

Une route dédiée sert chaque sport ; une autre sert chaque marque ; les catégories possèdent leur propre parcours. La page d’accueil et les pages intermédiaires peuvent ainsi conduire vers la même offre avec un vocabulaire adapté à la façon dont le visiteur formule son besoin.

Deux commandes génèrent les menus de sports et de marques. Cette préparation évite de reconstruire toute la navigation distante à chaque affichage. Elle donne aussi à l’interface une structure stable, plus facile à parcourir sur ordinateur comme sur mobile.

Les évolutions de juin 2021 montrent ce travail d’usage : alternatives responsables adaptées au mobile et au bureau, bandeau de promotions, glissement dans les composants et ajustements de menus. La navigation n’est pas restée celle du premier écran ; elle a été affinée au fil des parcours réellement développés.

8. Faire des facettes responsables une partie de la recherche

Mélanger critères sportifs classiques et engagements sans perdre la lisibilité

La recherche produit interroge les résultats Wizaplace et affiche une pagination dédiée. Les facettes classiques cohabitent avec des filtres propres à Blissports. Le visiteur peut notamment distinguer les produits responsables et explorer les trois familles de critères utilisées par la marque.

Les facettes responsables ne sont pas ajoutées comme un texte promotionnel au-dessus du catalogue. Elles possèdent des identifiants configurés, des cases de sélection et une place spécifique dans les filtres latéraux et supérieurs. Le choix modifie réellement la requête adressée au catalogue.

Cette intégration transforme le positionnement en outil de découverte. Un engagement devient utile lorsqu’il aide à réduire une liste de produits et à comparer des alternatives, pas seulement lorsqu’il apparaît dans une page institutionnelle éloignée du moment de choix.

9. Adapter la fiche selon la nature responsable du produit

Deux présentations pour expliquer ce qui est réellement disponible

Le produit est d’abord examiné à travers ses attributs. Si au moins un indicateur matière, planète ou humain est actif, la fiche utilise la présentation responsable. Dans le cas contraire, elle peut afficher une présentation classique accompagnée d’alternatives plus engagées.

La fiche responsable expose les déclinaisons, les prix, les informations produit et les trois familles de critères. Les descriptions détaillées des labels et leurs médias peuvent venir des attributs catalogue. Le visiteur comprend ainsi pourquoi le produit porte un repère au lieu de recevoir un simple badge non expliqué.

Les vendeurs et les offres restent gérés par le moteur marketplace. L’interface conserve donc la richesse transactionnelle de Wizaplace tout en ajoutant la pédagogie Blissports. Le même écran doit aider à choisir un produit, une variante et une offre avant l’ajout au panier.

10. Structurer trois familles de critères au lieu d’un label opaque

Éco-matière, planète préservée et respect de l’humain deviennent lisibles

Blissports ne traite pas la responsabilité comme une valeur unique. Les attributs distinguent l’éco-matière, la planète et l’humain. Chaque famille possède un indicateur synthétique et peut recevoir des détails plus précis dans la fiche.

Les vignettes de produit détectent ces attributs et affichent les repères correspondants. Les filtres les utilisent également. La même qualification accompagne donc le visiteur depuis le résultat de recherche jusqu’au détail, ce qui limite les contradictions entre promesse de liste et explication finale.

Une routine spécifique peut encore mettre à jour les attributs responsables dans Wizaplace. Cette fonction relie la présentation au catalogue source : l’interface ne maintient pas une seconde vérité isolée uniquement pour produire ses pictogrammes.

11. Suggérer une alternative responsable au bon produit

Respecter d’abord la famille, l’usage et, lorsque possible, le sport

Lorsqu’un produit n’est pas qualifié comme responsable, un service construit une recherche d’alternatives. Il commence par la grande famille du produit : équipements, vêtements, chaussures ou bien-être. Les paramètres changent selon cette catégorie afin de ne pas proposer un article seulement parce qu’il partage un badge.

Pour certaines familles, la recherche ajoute l’usage et le sport lorsque l’attribut est présent de manière exploitable. Les résultats sont ensuite filtrés avec les critères matière, planète, humain et responsable. La recommandation reste ainsi proche de l’intention initiale du visiteur.

Les alternatives sont conservées en cache pendant deux jours puis mélangées avant affichage. Le site évite un appel complet à chaque ouverture de fiche tout en renouvelant l’ordre de présentation. Le bénéfice observable est concret : un produit classique devient une porte vers une option plus engagée et comparable.

12. Couvrir onze actions autour du panier marketplace

Ajouter, modifier, livrer et payer sans exposer la mécanique distante

Le contrôleur panier réunit onze routes nommées : consulter, ajouter un produit, gérer le don, choisir une livraison, appliquer un coupon, modifier une déclinaison, retirer une ligne, vider, renseigner les adresses, choisir le paiement et traiter son retour.

Chaque action récupère l’état du panier Wizaplace avant de demander une modification. Les identifiants de produit, de déclinaison, de groupe de livraison et de paiement restent associés aux objets source. Le frontend ne simule pas un panier local qui pourrait diverger au moment du checkout.

Le parcours peut être désactivé par configuration lorsqu’il ne doit pas accepter d’opérations. Ce garde-fou historique évite d’afficher un tunnel actif alors que la chaîne transactionnelle n’est pas prête. Il montre aussi que l’exploitation a été pensée au-delà du seul chemin nominal.

13. Faire du don une vraie ligne pilotable dans le panier

Mettre à jour ou retirer une déclinaison dédiée selon le choix

Le don possède sa propre action. Le montant choisi est converti en quantité d’une déclinaison dédiée dans le panier Wizaplace. Une valeur nulle retire cette ligne ; une valeur positive met à jour sa quantité. Le don suit ainsi les mêmes garanties transactionnelles que les autres éléments du panier.

Le montant maximal proposé peut s’appuyer sur l’économie réalisée lorsqu’un prix barré dépasse le prix courant. Cette interaction relie promotion et geste volontaire sans modifier le prix du produit acheté. Le client garde la maîtrise de la valeur retenue.

Une évolution de juin 2021 retire aussi le don lorsqu’un article est supprimé dans le cas prévu par le parcours. Cette cohérence compte : une contribution ne doit pas rester seule dans un panier dont l’achat principal a disparu à la suite d’une action utilisateur.

14. Gérer livraison, déclinaisons et coupon dans le même état de panier

Chaque modification revient au calcul Wizaplace avant la validation

Un panier marketplace peut contenir plusieurs groupes de livraison liés aux vendeurs. Blissports transmet au moteur le transporteur choisi pour le groupe concerné, puis réaffiche l’état retourné. Le choix logistique reste donc rattaché à la bonne partie du panier.

Le visiteur peut modifier la quantité d’une déclinaison, retirer une ligne ou vider le panier. Les paramètres obligatoires sont contrôlés avant l’appel. Un coupon possède également son action dédiée afin que la promotion soit recalculée par la source transactionnelle.

Cette organisation réduit une catégorie classique d’erreur : afficher un total calculé dans le navigateur, puis découvrir une valeur différente après validation. Ici, produit, quantité, promotion et livraison sont renvoyés à Wizaplace, qui conserve l’autorité sur l’état utilisé pour commander.

15. Conduire le panier jusqu’au retour de paiement

Adresses, moyens disponibles et commandes finales restent reliés

Le checkout exige un utilisateur connecté. La première étape charge son profil Wizaplace et recueille les adresses de livraison et de facturation. Le client peut reprendre la même adresse ou renseigner deux ensembles distincts avant de passer au paiement.

La page suivante demande au panier les moyens de paiement disponibles. Elle vérifie plusieurs informations indispensables du profil, puis transmet le moyen choisi au checkout utilisateur Wizaplace avec une URL de retour absolue. Aucun prestataire de paiement particulier n’est attribué au projet lorsque la configuration disponible ne le démontre pas.

Le retour conserve temporairement les identifiants des commandes produites et vérifie leur état. Ce détail est essentiel en marketplace : une validation de panier peut générer plusieurs commandes liées aux vendeurs. L’écran final peut les regrouper sans perdre leur identité individuelle.

16. Prolonger l’achat dans un espace client complet

Profil, adresses, commandes, retours, SAV et messages partagent la même identité

L’espace client ne s’arrête pas à une page de profil. Il comprend le tableau de bord, la mise à jour des informations personnelles, les adresses de facturation et de livraison, l’abonnement à la newsletter et les messages.

Les commandes possèdent une liste et une vue détaillée. Des espaces séparés préparent le suivi des retours et du service après-vente. Cette continuité évite de construire une belle découverte de catalogue qui abandonnerait l’acheteur dès que le paiement est terminé.

Les appels utilisateur sont isolés des échanges opérateur. Le compte connecté récupère son panier, ses favoris et ses commandes avec son propre contexte d’accès. Le bénéfice n’est pas seulement architectural : une personne retrouve les mêmes objets avant, pendant et après la transaction.

17. Réunir pages, bannières, promotions et catalogue

Faire vivre la marketplace sans coder chaque prise de parole

Le frontend consomme le CMS Wizaplace pour les pages, les menus et les bannières de la page d’accueil ou des catégories. Les équipes peuvent ainsi faire évoluer une partie des contenus sans transformer chaque opération commerciale en modification du socle Symfony.

Les promotions disposent d’un service et d’une page de recherche. Une routine dédiée peut mettre à jour l’état promotionnel des produits. Les prix barrés, économies et bandeaux restent reliés aux données du catalogue plutôt qu’à une décoration ajoutée indépendamment.

La newsletter complète cet ensemble avec une inscription publique, une confirmation, un écran d’erreur et une gestion dans le compte. La plateforme associe ainsi contenu éditorial, animation commerciale et relation client au lieu de traiter ces dimensions comme trois sites séparés.

18. Installer Redis entre les pages et les appels les plus coûteux

Préparer les données qui n’ont pas besoin d’être reconstruites à chaque visite

Le cache applicatif Symfony utilise Redis. Les gestionnaires de la page d’accueil, des catégories, des attributs et des produits peuvent y conserver les réponses préparées. Une requête visiteur n’a donc pas à rejouer systématiquement toute la composition distante.

Les durées restent adaptées au type de donnée. Les alternatives responsables, par exemple, expirent après deux jours. D’autres éléments sont rafraîchis par des commandes planifiées. L’objectif n’est pas de figer le catalogue, mais de choisir qui déclenche l’actualisation et à quel rythme.

Cette couche apporte un gain observable même sans mesure de temps publiée : le rendu d’une page peut lire un résultat déjà construit et l’indisponibilité momentanée d’une opération de préparation ne force pas tous les visiteurs à supporter le même travail simultanément.

19. Répartir neuf traitements de cache et d’enrichissement

Messenger découple les lots lourds des requêtes publiques

Neuf messages possèdent leur traitement associé. Ils couvrent l’accueil, les produits, les alternatives responsables, les catégories, leurs facettes, les attributs catalogue, leurs variantes et deux mises à jour de produits liées aux critères responsables et aux promotions.

Chaque famille est routée vers une file dédiée. Une file d’échec reçoit les messages qui ne peuvent pas aboutir, et les stratégies prévoient un délai avant nouvelle tentative. Un incident sur l’enrichissement d’un produit n’a donc pas besoin de bloquer la construction de toute la page demandée par un visiteur.

Cette organisation relie performance et exploitation. Le site public consomme des données préparées ; les workers réalisent le travail distribué ; les files donnent un endroit précis où observer et reprendre un traitement. C’est une capacité plus concrète qu’une promesse générale de montée en charge.

20. Donner un rythme différent à chaque donnée

De cinq minutes à une journée selon la fonction

En production, l’accueil est préparé toutes les cinq minutes pendant la plage active. Les catégories suivent toutes les quinze minutes. Les attributs PIM et catalogue ainsi que les menus de sports et de marques sont rafraîchis toutes les vingt minutes.

Les produits et le sitemap possèdent une routine horaire. L’enrichissement des attributs responsables intervient toutes les quatre heures sur la plage configurée, tandis que la mise à jour des promotions est déclenchée chaque matin. Ces cadences correspondent à des coûts et à des besoins de fraîcheur différents.

La fiche ne transforme pas ces fréquences en garantie de disponibilité ou de performance. Elles prouvent cependant une exploitation organisée : le contenu public, la navigation, le catalogue et les enrichissements ne dépendent pas d’une personne qui relancerait manuellement les mêmes commandes.

21. Tester les contrats Wizaplace dans vingt-neuf fichiers dédiés

CMS, catalogue, vendeurs, livraison et compte utilisateur sont contrôlés séparément

La seconde génération contient vingt-neuf fichiers de tests. Ils ciblent les échanges Wizaplace plutôt que la seule présence d’une page. Les scénarios couvrent notamment les bannières et menus CMS, les catégories, les vendeurs, les listes de diffusion, les commandes, les produits, les promotions et la livraison.

Les fonctions utilisateur possèdent aussi leurs contrôles : créer, mettre à jour ou supprimer une adresse, récupérer le profil, gérer les favoris, vérifier une inscription à une liste et consulter une commande ou son historique.

Ce périmètre ne justifie pas un pourcentage de couverture inventé. Il montre en revanche où l’équipe a placé ses garde-fous : sur les contrats qui alimentent les pages et les actions marchandes. Une évolution d’API peut être rapprochée d’un scénario précis au lieu d’être découverte uniquement par un acheteur.

22. Faire vivre les workers, les caches et le site en production

Docker, cron et Supervisor forment la continuité d’exploitation

Le produit possède des configurations d’images, de serveur web et de PHP pour ses environnements. Les réglages de production apparaissent dans la trajectoire fin 2021, puis Supervisor est ajouté en décembre pour maintenir les consommateurs Messenger.

Les groupes de workers ne sont pas tous dimensionnés de la même façon. Les produits et leurs alternatives disposent de davantage de processus que l’accueil ou la mise à jour quotidienne des promotions. Cette différence traduit le volume relatif des objets à préparer.

Les consommateurs ont une limite de temps et sont relancés automatiquement. Les routines planifiées, Redis et les files de messages ne restent donc pas des choix de développement isolés : l’infrastructure prévoit les processus qui les exécutent après la mise en ligne.

23. Faire évoluer Blissports pendant dix-sept mois

Du 27 janvier 2021 au 15 juin 2022, le produit change par besoins successifs

Janvier et février 2021 posent les deux générations, l’authentification, la recherche, les vendeurs sur les produits et le panier pour visiteurs ou membres. Le socle transactionnel arrive donc avant les raffinements éditoriaux et responsables.

Au printemps et à l’été 2021, le travail se concentre sur l’expérience réelle : don, totaux du panier, promotions, absence de stock, retour au panier après connexion, alternatives responsables, composants mobiles, curseurs et navigation. Des routines d’import et de cache accompagnent la croissance du catalogue.

La fin 2021 renforce la production et les workers. En janvier 2022, les fiches produit reçoivent les données e-commerce destinées au gestionnaire de balises. Le dernier lot enregistré le 15 juin 2022 clôt une trajectoire de 504 jours entre le premier prototype et la dernière évolution disponible.

24. Suivre un pratiquant de la recherche au service après-vente

Un scénario complet révèle la valeur des connexions invisibles

Une personne commence par son sport, ouvre une catégorie et active un filtre responsable. Elle compare les vignettes, choisit un produit, examine ses critères matière, planète ou humain, puis sélectionne une déclinaison proposée par le catalogue Wizaplace.

Si le produit n’est pas qualifié, la fiche peut lui présenter une alternative de même famille et du même usage. Elle ajoute son choix au panier, modifie la quantité, sélectionne la livraison du groupe vendeur, applique éventuellement un coupon et choisit le montant du don.

Après connexion, elle confirme ses adresses, retient l’un des moyens de paiement disponibles et revient sur le site avec les identifiants des commandes créées. Son espace lui permet ensuite de consulter le détail, les messages, les retours et le SAV. Le frontend tient le fil sans remplacer le moteur transactionnel.

25. Passer d’un prototype connecté à un produit exploitable

Les gains se voient dans les capacités et la cohérence du parcours

Avant la seconde génération, le projet dispose d’une première connexion et d’écrans essentiels. Après dix-sept mois, Blissports possède une expérience complète qui organise la découverte, le choix responsable, la transaction et l’après-vente autour du même compte et du même catalogue.

La marque gagne une expression fonctionnelle de son positionnement. Les critères responsables agissent dans les filtres, les vignettes, les fiches et les recommandations. Le don devient une action de panier. Le sport et la marque deviennent de vraies portes d’entrée, pas seulement des mots ajoutés aux contenus.

L’exploitation gagne elle aussi en structure. Les données coûteuses sont préparées dans Redis, neuf traitements passent par des files dédiées, des routines rafraîchissent chaque famille au bon rythme et les échanges sensibles possèdent des tests ciblés. Le site peut évoluer sans remettre tout son fonctionnement dans une seule requête web.

Aucun taux de conversion, gain de vitesse ou revenu supplémentaire n’est attribué au projet faute de mesure consolidée disponible. La transformation démontrée reste néanmoins forte : un moteur marketplace générique est devenu un produit marchand Blissports, avec ses parcours, ses règles responsables et son exploitation.

26. Distinguer le périmètre livré des résultats non mesurés

La précision renforce la preuve au lieu de diminuer le projet

Wizaplace porte le catalogue, le panier, les moyens de paiement et les commandes. Le projet Blissports construit l’expérience qui les utilise ; il ne développe pas un nouveau moteur marketplace ni un prestataire de paiement indépendant.

Le frontend s’appuie sur les moyens de paiement proposés par le panier Wizaplace et revient ensuite contrôler les commandes produites. Cette frontière permet de raconter exactement la chaîne livrée sans lui attribuer un prestataire ou une mécanique financière supplémentaire.

Les vingt-neuf fichiers de tests prouvent un contrôle ciblé des échanges API, pas une couverture totale du produit. Les routines prouvent des cadences configurées, pas un engagement de service chiffré. Cette frontière permet à chaque détail publié de rester défendable.

Pour découvrir une autre façon de construire une expérience marchande connectée, le projet Shopetic × Wizaplace montre comment un frontend marketplace a été livré en trente et un jours sur un contexte différent.