Wizaplace Explorer : 7 jours pour rendre l’API opérateur Blissports navigable

1. Blissports, une marketplace sportive dont les données traversent plusieurs domaines

Le frontend public et l’explorateur répondent à deux usages complémentaires

Blissports est une marketplace consacrée au sport et à une consommation plus responsable. Son expérience publique assemble catalogue, variantes, offres vendeurs, panier multivendeur, commandes et services après-vente. Cette profondeur fonctionnelle donne de la valeur au produit, mais multiplie aussi les relations à comprendre lorsqu’une donnée paraît incohérente.

Le frontend marketplace Blissports porte la navigation et l’achat côté client. Wizaplace Explorer répond à une autre question : comment examiner les objets opérateur qui alimentent ces parcours sans reconstruire manuellement les appels à chaque diagnostic ?

L’explorateur utilise deux configurations séparées, une de préparation et une de production. La personne connectée choisit la marketplace autorisée dans son compte, puis l’application injecte ce contexte dans chaque passerelle. Les écrans restent ainsi rattachés à une source explicite.

Ce positionnement évite une confusion importante. L’outil n’est ni le site marchand, ni un second moteur marketplace. C’est une surface de lecture qui aide l’équipe à comprendre les données exposées par Wizaplace et leurs relations avant de décider où intervenir.

2. Partir des questions opérateur et les traduire en parcours de lecture

Une façade commune distribue les appels vers onze domaines spécialisés

Le travail commence par les objets que l’équipe doit retrouver : catégories, produits, attributs, vendeurs, commandes, utilisateurs, traitements, modes de transport et expéditions. Chaque famille reçoit une passerelle dédiée au lieu d’être mélangée dans un client HTTP universel.

Les contrôleurs ne choisissent pas librement une URL et un jeton. Ils résolvent d’abord la marketplace depuis le compte de la personne connectée et le slug présent dans la route. Si ce couple ne correspond pas, la ressource n’est pas ouverte. La façade d’échange prépare ensuite l’autorisation attendue par l’API opérateur.

Les listes, recherches et fiches sont organisées pour permettre des rebonds utiles. La fiche produit ne montre pas seulement ses attributs : elle recherche aussi les commandes qui le contiennent. La fiche vendeur remonte ses commandes. Une catégorie ou un attribut PIM peut conduire vers une liste de produits déjà filtrée.

Le choix de rester en lecture seule constitue enfin une décision de conception. Toutes les requêtes distantes observées utilisent GET. L’exploration peut être approfondie sans ajouter dans cette interface un bouton capable de modifier accidentellement une donnée de production.

3. Transformer une collection d’endpoints en outil de compréhension

L’enjeu n’était pas d’obtenir les données, mais de les rendre navigables

Wizaplace expose les ressources nécessaires à l’exploitation d’une marketplace. Pourtant, disposer d’un endpoint produit, d’un endpoint vendeur et d’un endpoint commande ne crée pas automatiquement une vision cohérente. Il faut connaître les paramètres, reconnaître les identifiants et refaire les rapprochements pour chaque investigation.

Wizaplace Explorer part de cette friction. L’application propose des listes, des formulaires de recherche et des fiches de détail dans un vocabulaire stable. Elle conserve les paramètres techniques utiles, mais les place derrière des parcours compréhensibles : chercher un produit, ouvrir sa catégorie, examiner son vendeur ou retrouver les commandes associées.

Le bénéfice attendu est opérationnel : réduire la distance entre une question et la donnée qui permet d’y répondre. Cette promesse reste volontairement précise. L’outil n’automatise pas une correction et ne surveille pas la plateforme en continu ; il accélère l’inspection ponctuelle des ressources que l’équipe doit comprendre.

4. Concentrer la construction sur sept jours

Du socle Symfony aux écrans métier entre le 19 et le 25 mars 2021

Le premier état apparaît le 19 mars 2021. La base Symfony 5.2, l’authentification et le modèle de compte ouvrent la voie aux premiers écrans. Le lendemain, une première version de la branche principale est rassemblée, mais le développement continue sur la branche la plus complète.

Les jours suivants ajoutent les ressources une à une : catalogue, catégories, attributs, vendeurs, commandes, utilisateurs, jobs et logistique. Les recherches gagnent des filtres, les fiches créent des liens entre domaines et la sélection de marketplace devient un contexte systématique.

Le dernier état observé date du 25 mars. Cette semaine courte explique la nature du résultat : un explorateur fonctionnel et dense, doté d’une chaîne de construction automatisée, mais sans la phase de durcissement que représenteraient une couverture de tests, une supervision ou la finalisation du reporting.

5. Placer le compte au-dessus des utilisateurs et des marketplaces

L’accès à une source dépend du périmètre attribué à la personne connectée

Le modèle local repose sur trois entités : Account, User et Marketplace. Un compte regroupe plusieurs personnes et plusieurs marketplaces. L’utilisateur ne choisit donc pas une cible dans une liste globale ; il navigue parmi les environnements rattachés à son propre compte.

À chaque route métier, le contrôleur confronte le slug demandé aux marketplaces du compte courant. Une cible absente de ce périmètre provoque une réponse introuvable. Cette règle simple évite qu’un changement manuel d’URL suffise à ouvrir une autre configuration.

La séparation est adaptée à un outil multi-utilisateur. Elle prépare la coexistence de plusieurs configurations sans recopier les écrans ou les services. Elle ne remplace pas une matrice de droits détaillée : dans cette génération, la frontière principale se situe au niveau du compte et de la marketplace autorisée.

6. Distinguer préparation et production avant le premier appel

Chaque environnement Blissports conserve sa propre configuration opérateur

Deux marketplaces Blissports sont configurées dans l’application : un environnement de préparation et l’environnement de production. Chacune possède son nom, son URL, son slug et son accès opérateur distinct. La source consultée reste donc visible dans la navigation.

Cette distinction répond à un besoin concret. Une donnée peut exister dans la préparation sans être encore présente en production, ou différer entre les deux. L’équipe peut reproduire le même parcours de lecture sur chaque cible sans modifier le code ni remplacer manuellement une configuration globale.

Dans cette version, l’accès opérateur est rattaché directement à l’entité marketplace. L’organisation centralise la configuration nécessaire aux passerelles ; elle ne constitue pas à elle seule un dispositif complet de gestion et de rotation des secrets.

7. Préparer l’autorisation opérateur dans une façade commune

Les contrôleurs demandent une ressource, la couche d’échange connaît le protocole

La façade OperatorExchange reçoit la marketplace sélectionnée et construit le contexte des appels. L’API Wizaplace attend une autorisation sous la forme d’un jeton opérateur. Cette convention est ajoutée par la couche d’échange plutôt que répétée dans chaque contrôleur.

Les passerelles spécialisées reçoivent le même client HTTP et la même façade. Elles peuvent ainsi se concentrer sur la route, les paramètres de recherche et la forme de résultat attendue. Le produit, la commande ou l’utilisateur n’ont pas à redéfinir le mécanisme d’accès.

La conception réduit le nombre d’endroits où une convention d’authentification peut diverger. Elle ne prétend pas fournir une stratégie de renouvellement automatique : aucune rotation, alerte d’expiration ou négociation OAuth n’est visible dans ce périmètre.

8. Distribuer l’API entre onze passerelles spécialisées

Chaque famille de données garde ses paramètres et son vocabulaire

Onze passerelles couvrent l’API opérateur : produits catalogue, catégories, entreprises vendeuses, commandes, attributs PIM, attributs catalogue, jobs, produits internes, modes de transport, expéditions et utilisateurs. Une façade commune les rend accessibles aux managers métier.

Cette répartition évite un client monolithique rempli de méthodes sans relation. La recherche de commandes connaît ses statuts et ses vendeurs ; la recherche produit connaît ses catégories, entreprises et attributs ; la logistique conserve la différence entre une méthode proposée et une expédition créée.

Toutes les opérations distantes de cette génération sont des lectures. Les passerelles construisent des appels GET avec leurs paramètres, puis renvoient les données utiles aux managers. Le terme de passerelle décrit donc mieux le résultat qu’un SDK généraliste : le périmètre est précis, orienté exploration et lié aux besoins Blissports.

9. Relier quarante-et-une routes à vingt contrôleurs

Listes, recherches et détails composent un chemin continu

L’application expose quarante-et-une routes nommées réparties dans vingt contrôleurs. Une première famille gère la connexion, le compte et la sélection de marketplace. Les autres ouvrent les index, formulaires de recherche et fiches de détail des objets Wizaplace.

Le nombre n’est pas une fin en soi. Il traduit surtout la granularité du parcours : une liste de catégories ne répond pas à la même question que l’arbre complet ; une recherche de produit ne remplace pas sa fiche ; la liste des commandes doit conduire vers chaque commande identifiée.

Les liens entre pages évitent de revenir systématiquement au menu. Un objet devient une porte vers son contexte : produit vers commandes, vendeur vers commandes, catégorie vers produits, attribut vers produits. La navigation matérialise les relations de l’API au lieu de présenter onze silos.

10. Ouvrir le catalogue par plusieurs portes d’entrée

Produits, catégories, entreprises et attributs répondent à des questions différentes

Le catalogue ne se résume pas à une table de produits. L’explorateur sépare les produits catalogue des produits internes, les catégories, les entreprises vendeuses, les attributs catalogue et les attributs PIM. Cette distinction reflète les ressources réellement exposées par la plateforme.

Chaque domaine propose le niveau de lecture disponible : une liste ou une recherche, puis une fiche quand l’API fournit un identifiant exploitable. Les paramètres restent visibles afin que l’utilisateur comprenne pourquoi un ensemble de résultats lui est retourné.

Cette organisation aide à isoler la nature d’une anomalie. Un produit peut exister mais manquer d’un attribut, appartenir à une mauvaise catégorie ou être rattaché à un vendeur inattendu. L’outil permet d’examiner ces dimensions sans les aplatir dans un unique tableau.

11. Combiner texte, pagination et filtres dans la recherche produit

Catégories, vendeurs et attributs sont chargés pour construire une requête lisible

La recherche produit accepte une requête textuelle, une page et plusieurs filtres. Avant d’afficher le formulaire, le contrôleur récupère les catégories, les entreprises et les attributs disponibles. L’utilisateur peut ainsi formuler une recherche à partir des objets connus de la marketplace.

La taille de page par défaut est de cinquante résultats. La pagination conserve le contexte de la requête au lieu de transformer chaque page suivante en nouveau diagnostic. Les résultats peuvent également être ouverts dans une vue destinée à l’export.

La recherche présente deux chemins complémentaires. Depuis l’en-tête, l’application tente d’abord d’interpréter la saisie comme un identifiant exact de produit. Si cette lecture n’aboutit pas, elle revient vers une recherche textuelle. Une référence connue mène directement à la fiche ; une intention plus large conserve sa liste.

12. Faire de la fiche produit un point de croisement

Attributs, caractéristiques, déclinaisons et commandes sont rapprochés

La fiche produit présente les informations catalogue, les attributs, les caractéristiques et les déclinaisons renvoyés par Wizaplace. Elle ne réduit pas la ressource à son nom et à son prix : l’objectif est de comprendre la structure qui alimente les parcours publics.

Le contrôleur lance également une recherche de commandes filtrée par identifiant produit. Il calcule le nombre d’éléments retrouvés et leur total, puis les affiche comme contexte. Une question catalogue peut ainsi remonter immédiatement vers son impact transactionnel visible.

Les liens conduisent ensuite vers la commande ou l’utilisateur concerné. Ce rapprochement est l’un des choix les plus utiles de l’explorateur : l’équipe ne reçoit pas seulement une réponse API, elle obtient un chemin de lecture entre l’objet examiné et les autres ressources qui l’emploient.

13. Lire les catégories sous forme de liste, d’arbre et de fiche

La hiérarchie devient consultable sans perdre les produits rattachés

Les catégories disposent de trois représentations. La liste aide à retrouver un identifiant, l’arbre expose la hiérarchie, et la fiche se concentre sur une catégorie particulière. Ces vues répondent à des besoins différents sans dupliquer la logique d’appel.

Depuis la fiche, l’explorateur recherche les produits filtrés sur la catégorie sélectionnée. L’utilisateur peut vérifier non seulement la définition du nœud, mais aussi les éléments qui apparaissent réellement sous ce rattachement.

Cette relation est utile lorsqu’une navigation publique semble incomplète. L’équipe peut déterminer si la catégorie existe, où elle se situe et quels produits lui sont associés avant d’accuser le frontend ou de modifier une règle d’affichage.

14. Rattacher chaque entreprise vendeuse à ses commandes

La fiche société dépasse l’identité administrative isolée

La passerelle CatalogCompany fournit la liste et le détail des entreprises. La fiche affiche les informations renvoyées par la plateforme, puis utilise l’identifiant de la société pour rechercher ses commandes.

Ce rebond rend le vendeur immédiatement lisible dans son activité. Une équipe peut vérifier qu’une entreprise est bien reconnue, puis observer les commandes qui lui sont associées sans reformuler une seconde requête depuis zéro.

L’outil n’effectue aucune validation juridique et ne modifie pas le statut du vendeur. Il rassemble les lectures utiles à un diagnostic. Les décisions d’onboarding, de conformité ou de suspension restent hors de cette interface et doivent être prises dans les outils responsables de ces processus.

15. Séparer attributs catalogue et attributs PIM

Deux vocabulaires proches ne sont pas fusionnés artificiellement

Wizaplace Explorer distingue les attributs du catalogue et ceux du PIM. Chacun possède sa liste et sa fiche. Cette séparation évite de faire croire qu’un champ visible dans une source possède automatiquement le même identifiant, la même variante ou la même portée dans l’autre.

La fiche d’un attribut PIM permet de sélectionner une variante lorsqu’elle existe, puis propose un lien vers une recherche de produits équivalente. L’utilisateur passe ainsi de la définition du champ aux produits qui le portent.

Cette continuité rend le diagnostic plus concret. Au lieu de conclure qu’un attribut existe parce que sa définition est présente, l’équipe peut observer son usage dans le catalogue. L’outil ne corrige pas les valeurs manquantes ; il aide à localiser la rupture entre structure et contenu.

16. Explorer les commandes avec leurs filtres métier

Statut, vendeur, produit et pagination structurent la lecture

La liste des commandes accepte une page, un statut, des identifiants d’entreprise et d’autres filtres transmis à l’API. Les usages venus des fiches produit ou vendeur réemploient ce même mécanisme plutôt que de créer une requête parallèle.

Chaque commande possède une fiche. L’application charge également les motifs de retour disponibles afin de présenter le vocabulaire utilisé par la plateforme dans la suite du parcours. Cette lecture donne du contexte sans déclencher elle-même une demande de retour.

Le choix de n’exposer aucune mutation est particulièrement important ici. L’explorateur peut ouvrir une commande de production et ses relations, mais il ne change pas son statut. La consultation détaillée ne devient pas accidentellement une opération transactionnelle.

17. Retrouver un utilisateur et son identifiant de panier

Le profil client rejoint le contexte transactionnel disponible

La passerelle utilisateur propose une liste et une fiche de profil. L’écran détail permet également de récupérer l’identifiant de panier associé lorsque la plateforme le fournit. Le compte client peut ainsi être rapproché d’un objet utilisé dans le parcours d’achat.

Cette relation répond à une question fréquente lors d’un diagnostic : le problème vient-il du profil, du panier ou du lien entre les deux ? L’outil ne résout pas automatiquement l’écart, mais il place les identifiants nécessaires dans un même chemin de navigation.

Aucun mot de passe ni moyen de paiement n’est manipulé par ces vues. L’exploration porte sur les ressources renvoyées par l’API opérateur. La présence d’un profil dans l’outil ne lui donne pas pour autant un rôle de gestionnaire complet de l’identité client.

18. Suivre les traitements exposés par Wizaplace

La liste conserve les paramètres de fenêtre et de pagination

Les jobs disposent d’un écran de liste alimenté par des paramètres de début et de limite. L’objectif est d’inspecter les traitements connus de l’API, notamment lorsque la disponibilité d’une donnée dépend d’un travail asynchrone de la plateforme.

La vue ne se transforme pas en ordonnanceur. Elle ne lance, n’annule et ne rejoue aucun job. Cette limite cohérente avec le reste du produit préserve la fonction de l’explorateur : montrer un état distant sans introduire de commande opérationnelle.

Le simple accès à cette ressource aide néanmoins à distinguer deux situations. Une donnée absente peut venir d’un objet mal configuré ou d’un traitement encore en cours. L’utilisateur dispose d’un indice supplémentaire avant de choisir le bon outil d’intervention.

19. Ne pas confondre modes de transport et expéditions

Deux passerelles conservent les étapes distinctes de la logistique

La passerelle Shipping expose les modes de transport et leur détail. La passerelle Shipment liste les expéditions. Les noms sont proches, mais les objets ne racontent pas la même étape : l’un décrit une possibilité de livraison, l’autre une exécution liée aux commandes.

Cette séparation protège la lecture métier. Une méthode disponible ne prouve pas qu’une expédition a été créée ; une expédition ne suffit pas à expliquer toutes les options qui existaient lors du choix. Chaque écran conserve donc sa source et son identité.

L’explorateur ne suit pas un colis sur une carte et ne dialogue pas directement avec un transporteur. Il restitue les ressources logistiques rendues disponibles par Wizaplace. Les intégrations plus larges relèvent des flux SI d’une marketplace opérateur.

20. Préparer Redis sans masquer la fraîcheur réellement demandée

Une capacité de cache existe, mais les écrans forcent la lecture courante

Les managers disposent d’un cache Redis et construisent des clés qui incluent la marketplace, l’identifiant ou les paramètres de recherche. La durée prévue est d’une heure. Cette architecture aurait permis d’éviter des appels répétés pour une même lecture.

Dans les contrôleurs de cette génération, le paramètre d’invalidation est toutefois activé lors des consultations. Les écrans demandent donc un rafraîchissement plutôt que de s’appuyer systématiquement sur la valeur mémorisée. Il serait trompeur d’attribuer au cache un gain de performance généralisé.

Le compromis favorise la donnée courante pendant l’exploration, au prix d’appels supplémentaires à l’API. Redis reste une capacité prête à être utilisée plus finement, mais son efficacité devrait être mesurée et son invalidation décidée par usage avant d’en faire une promesse de production.

21. Reconnaître un reporting amorcé, mais non finalisé

Quatre commandes existent sans constituer un tableau de bord exploitable

Quatre commandes portent sur les catégories, les entreprises, les utilisateurs et les produits. Elles parcourent notamment des pages de commandes et préparent des fichiers JSON. L’intention de rapprocher les ressources pour produire des rapports est donc visible.

Cette piste n’est pourtant pas achevée dans l’état livré. Le rapport produit s’interrompt avant l’accumulation finale et certains chiffres du tableau de bord proviennent encore du thème d’interface. Ils ne peuvent pas être présentés comme des indicateurs Blissports mesurés.

La fiche assume cette frontière. Wizaplace Explorer est une preuve solide de navigation et de rapprochement en lecture ; il n’est pas une preuve de pilotage KPI finalisé. Un reporting fiable demanderait de terminer les collecteurs, qualifier les métriques et retirer tous les exemples de démonstration.

22. Faire de la lecture seule un garde-fou fonctionnel

Aucun appel distant observé ne modifie l’état Wizaplace

Les onze passerelles utilisent GET. Aucun formulaire ne transforme la consultation d’un produit, d’une commande ou d’un utilisateur en POST, PATCH ou DELETE vers Wizaplace. L’application peut donc être explorée sans disposer d’une fonction de modification distante.

Ce choix est adapté à la mission : comprendre avant d’agir. Il réduit le risque qu’une recherche effectuée dans le mauvais environnement entraîne une modification. La séparation préparation-production reste importante, mais elle ne porte pas seule la sécurité du parcours.

La contrepartie est claire. Une anomalie identifiée doit être corrigée ailleurs, dans le back-office responsable ou dans le code du flux concerné. L’explorateur accélère le diagnostic ; il ne prétend pas fermer le cycle complet de remédiation.

23. Construire et publier deux images applicatives

La chaîne de livraison prépare PHP et Nginx avec un périmètre qualité explicite

La configuration de livraison utilise Docker-in-Docker pour construire deux images : l’une pour PHP, l’autre pour Nginx. Les étapes compilent puis publient les artefacts attendus par l’environnement d’hébergement. Des configurations locales et de pipeline accompagnent l’application.

La chaîne a produit un état réussi sur la version livrée. Elle prouve que le projet pouvait être assemblé et distribué selon cette procédure. Elle ne contient cependant pas d’étape de tests automatisés ; son succès valide la construction des images, pas la totalité des comportements métier.

Le projet ne contient aucun fichier de test applicatif identifié. La qualité repose ici sur la séparation des responsabilités et la vérification manuelle des parcours, mais pas sur une couverture mesurée. Ce manque fait partie des premiers travaux à prévoir avant une évolution transactionnelle.

24. Partir d’un produit et remonter jusqu’à son contexte de vente

Un scénario concret traverse recherche, catalogue, vendeur et commandes

Une référence produit est signalée comme incohérente sur le site Blissports. L’opérateur choisit d’abord l’environnement concerné. Il saisit la référence dans la recherche globale : l’explorateur tente l’identifiant exact, puis revient vers la recherche textuelle si nécessaire.

La fiche obtenue expose les attributs, caractéristiques et déclinaisons. Un lien permet d’ouvrir la catégorie pour vérifier le rattachement et ses autres produits. L’entreprise vendeuse peut être consultée séparément afin de confirmer l’identité associée à l’offre.

La même fiche recherche enfin les commandes contenant le produit et en résume le nombre et le total visibles. L’opérateur peut ouvrir une commande puis l’utilisateur concerné. En quelques écrans, il rassemble le contexte nécessaire pour décider si l’écart vient du catalogue, du vendeur ou du parcours transactionnel, sans modifier la production.

25. Raccourcir le chemin entre une question et son contexte

La transformation est visible dans les parcours, sans extrapoler de performance commerciale

Avant l’explorateur, l’API expose chaque ressource avec son propre contrat. Comprendre une relation exige de préparer plusieurs appels et de reporter les identifiants d’une réponse vers la suivante. Le savoir nécessaire reste concentré chez les personnes capables de manipuler directement l’API.

Après cette semaine de construction, quarante-et-une routes donnent accès à onze familles de données derrière une sélection de marketplace commune. Les fiches produit, catégorie, vendeur, commande et utilisateur créent les passages qui correspondent aux investigations les plus utiles.

Le gain démontrable est cette continuité de lecture : un produit peut conduire à ses commandes, une entreprise à son activité, un attribut à ses produits. Aucun chiffre de temps économisé, de chiffre d’affaires ou de disponibilité n’a été conservé ; la valeur est donc décrite par les capacités réellement observables, pas par une estimation habillée en résultat.

26. Savoir exactement ce qu’il faudrait durcir ensuite

Tests, secrets, erreurs et reporting forment la suite logique

La première priorité serait une couverture de tests sur la résolution compte-marketplace, les paramètres des onze passerelles et les rebonds entre objets. L’absence de tests automatisés rend toute extension plus risquée, surtout si l’outil devait un jour dépasser la lecture seule.

La deuxième concerne l’exploitation : gestion externe des accès opérateur, timeouts explicites, journalisation structurée, traitement homogène des erreurs et politique de cache mesurée. Ces capacités ne doivent pas être supposées parce qu’un client HTTP et Redis existent dans l’architecture.

La troisième serait de terminer ou retirer les amorces de reporting afin qu’aucune donnée de démonstration ne puisse être confondue avec une mesure métier. Ces limites ne diminuent pas la cohérence du produit livré : elles tracent la frontière exacte entre un explorateur de données réussi et un cockpit opérateur complet.

Pour prolonger ce type de travail, Dawap peut cadrer une API marketplace sur mesure, relier les intégrations SI opérateur ou intervenir comme intégrateur Wizaplace en séparant clairement exploration, action et supervision.