Parcours commercial
Catalogue privé, détail produit, panier, devis, commandes et historique.
Projet principal · Réalisation intégrale
JCD Commerce V2
Refondre une application B2B historique en un MVP moderne, structuré, testable et strictement isolé par compte.
Pourquoi ce projet est central
Depuis avril, j’ai réalisé seul le MVP de JCD Commerce V2. Ce projet constitue le cœur du rapport car il mobilise l’ensemble d’un cycle de développement : analyse de l’existant, définition du périmètre, conception de la base de données, architecture serveur et interface, développements backend et frontend, droits, workflow, données de démonstration, tests, documentation, démonstrations et corrections issues des retours.
Partir de l’existant
JCD Commerce V1 est une application historique en PHP natif qui s’est enrichie avec les besoins de l’entreprise. Elle couvre des parcours essentiels, mais sa logique est désormais répartie entre pages, contrôleurs procéduraux, classes métier et scripts de base de données. Cette complexité rend la maintenance plus délicate : comprendre l’effet complet d’une modification demande de parcourir plusieurs couches peu cloisonnées, et chaque évolution peut affecter un comportement existant.
Ces limites concernaient autant la capacité à faire évoluer les règles métier que l’interface et les contrôles d’accès. Continuer à ajouter des fonctionnalités dans la même structure aurait augmenté le coût de maintenance. L’entreprise avait donc besoin d’une architecture plus moderne, plus lisible et testable, capable de préparer les futurs parcours, rôles et besoins commerciaux sans fragiliser l’existant.
J’ai effectué quelques corrections sur la V1, mais elle est surtout devenue la source d’analyse des parcours et des règles à préserver. La conception de la V2 commence à partir de ce constat : la refonte ne consiste pas à reproduire visuellement l’ancienne application, mais à clarifier les responsabilités, formaliser les processus et construire une interface cohérente pour plusieurs rôles.
Périmètre réalisé
Validation
Commandes en attente, acceptation, refus, annulation, duplication et révision.
Administration
Utilisateurs, rôles, autorisations, groupes, adresses et dashboard.
La réalisation comprend aussi l’isolation des données par compte, les seeders, les tests, la documentation et les diagrammes de conception.
La figure 16 positionne ce périmètre dans son environnement immédiat avant l’analyse détaillée des choix techniques.
Cette vue distingue les acteurs du portail, le socle V2 et la reprise de l’existant. J’ai commencé par clarifier ces relations avant de construire le modèle de données et les parcours métier.
Le Gantt détaille ensuite le déroulement du projet d’avril à août. Le socle et les fonctionnalités n’ont pas été développés dans une succession rigide : les tests, le responsive et les retours utilisateurs ont accompagné plusieurs phases de réalisation.
Après l’analyse de la V1 et la définition du MVP, j’ai construit le socle multi-compte puis les parcours du catalogue jusqu’à la validation. Les démonstrations ont commencé avant la fin du développement et ont déclenché plusieurs corrections, notamment sur le mobile et le panier. Les dernières semaines réunissent recette, documentation et transmission.
Socle technologique
Le projet utilise PHP 8.3 dans le conteneur, Laravel 11.54.0, Inertia Laravel 2.0.24, React 18.3.1, l’adaptateur Inertia React 2.3.25, Tailwind CSS 3.4.19, Vite 6.4.3 et MySQL 8.4. Ce socle conserve les règles et les autorisations dans Laravel, tout en offrant une interface React réactive. Inertia évite ici une API séparée qui aurait ajouté des contrats et une authentification supplémentaires sans besoin d’exposition publique.
Cette architecture crée néanmoins un couplage assumé entre le serveur Laravel et les pages React : elle convient au portail privé actuel, mais serait moins adaptée si plusieurs clients indépendants devaient consommer le même backend.
Problématique directrice
Comment moderniser une application de commerce B2B historique, sans perdre ses règles métier, tout en rendant les processus plus compréhensibles et en garantissant que chaque compte n’accède qu’à ses propres données ?