JCD Commerce V2 · 06
Architecture et cycle documentaire
Une architecture applicative qui centralise les règles métier, les périmètres d’accès et les transitions entre panier, devis et commande.
Vue d’ensemble
Inertia permet de conserver une partie serveur Laravel classique tout en livrant des pages React, sans construire une API REST séparée pour chaque écran. Les contrôleurs préparent les données et les composants React gèrent l’expérience utilisateur.
Les pages React sont alimentées par Laravel via Inertia. Les autorisations et les règles métier restent ainsi du côté serveur, sans introduire une API séparée pour chaque écran.
Backend Laravel
Les contrôleurs sont organisés par domaine : catalogue, panier, devis, commandes, validation, utilisateurs, groupes d’adresses et dashboard. Les modèles représentent les entités persistantes. Deux composants de support structurent les règles les plus transversales.
| Composant | Responsabilité | Intérêt architectural |
|---|---|---|
OrderWorkflow | Création et transitions des documents, duplication, révision, historique | Évite de disperser les règles dans plusieurs contrôleurs |
WorkspaceContext | Filtrage selon le compte, le rôle et les groupes accessibles | Réduit le risque de fuite entre comptes |
UserRole | Centralisation des rôles applicatifs | Évite les chaînes de caractères incohérentes |
Frontend React et Inertia
Les pages sont regroupées par fonctionnalité : catalogue, panier, devis, commandes, validations, utilisateurs, groupes et tableau de bord. Des composants partagés gèrent les badges de statut, les fenêtres modales, les notifications et les présentations récurrentes des processus. TypeScript documente les structures échangées et signale des incohérences avant l’exécution.
Workflow documentaire
Une même table commandes porte les paniers, devis et commandes grâce à type_commande. L’état du document reste séparé dans statut_commande. Pour modifier un document existant sans l’écraser, un panier de révision référence sa source via source_commande_id.
La représentation met en évidence les deux sorties du panier et le contrôle supplémentaire appliqué lorsqu’une commande nécessite une validation. Les séquences techniques détaillées sont conservées en annexe.
Isolation des données et droits
Chaque utilisateur appartient à un compte. Le catalogue disponible, les documents et les adresses sont filtrés selon ce compte. Les rôles distinguent notamment l’opérateur, l’administrateur d’entreprise et l’utilisateur simple. Le droit can_validate est local à un groupe d’adresses : il ne transforme pas automatiquement l’utilisateur en validateur de tout le compte.
Cette distinction entre rôle global et permission locale est l’un des choix structurants du projet. Elle permet d’adapter l’application à des organisations où la validation dépend d’un établissement ou d’un périmètre précis.
L’isolation ne repose pas uniquement sur les éléments visibles dans l’interface : elle est recalculée dans le contexte serveur et vérifiée par les contrôleurs et les tests Feature.
Hébergement envisagé
L’application a été conçue pour être déployée sur l’infrastructure de JCD Groupe, dans la continuité de l’écosystème existant, tout en s’appuyant sur une architecture plus moderne que celle de la V1 en PHP natif. Le recours à un VPS externe n’est pas l’option prioritaire.
Les modalités opérationnelles précises du déploiement dépendront des choix d’infrastructure et des procédures internes de l’entreprise. Cette orientation ne signifie pas que la V2 est déjà en production.