Choix technologiques

Besoins et critères de décision

Le choix du socle ne devait pas seulement moderniser la V1. Il devait rendre les règles métier et les autorisations plus faciles à localiser, sécuriser les échanges de données, faciliter la reprise du projet par l’équipe et offrir une interface réactive sur ordinateur comme sur mobile. Le portail restant une application privée servie par un seul backend, une architecture distribuée aurait ajouté de la complexité sans répondre à un besoin immédiat.

• Centraliser les règles métier, les autorisations et les accès aux données.
• S’appuyer sur des technologies maîtrisées dans le service.
• Construire une interface interactive, réutilisable et adaptée au mobile.
• Fiabiliser les données échangées entre le serveur et les pages.
• Conserver un déploiement unique et une base reproductible pour les tests.

Des choix adaptés au projet

J’ai retenu Laravel pour structurer le backend autour de contrôleurs, de modèles, de migrations, de règles d’autorisation et de tests. Ce cadre répond directement aux limites observées dans la V1 en PHP natif, où les responsabilités étaient davantage dispersées. Il valorise également l’expérience PHP/Laravel du service, ce qui facilite la relecture et la future reprise du projet. Poursuivre en PHP natif aurait conservé trop de liberté d’organisation pour une refonte dont l’un des objectifs principaux était précisément de mieux encadrer les règles.

Inertia relie ce backend aux pages React sans imposer la création d’une API distincte pour chaque écran. Le besoin concernait un portail web unique, sans client mobile autonome ni service public à exposer. Une API REST séparée aurait donc demandé des contrats d’échange, une authentification et un cycle de maintenance supplémentaires. Le couplage entre Laravel et l’interface est assumé : il simplifie ici le développement et le déploiement, mais serait à réexaminer si plusieurs clients indépendants devaient utiliser le même backend.

React a été choisi pour construire les écrans interactifs du catalogue, du panier, des validations et de l’administration à partir de composants réutilisables. TypeScript complète ce choix en décrivant les données reçues du serveur et en signalant certaines incohérences avant l’exécution. Cette association était mieux adaptée aux nombreux états d’interface du projet qu’une succession de vues serveur enrichies ponctuellement en JavaScript.

Tailwind CSS m’a permis de faire évoluer rapidement la mise en page et le responsive à partir de règles cohérentes, notamment après les retours sur l’usage mobile. Il évite la multiplication de feuilles de style spécifiques, tout en demandant de maintenir des composants partagés pour ne pas répéter les mêmes assemblages de classes. Enfin, MySQL correspond naturellement aux relations fortes entre comptes, utilisateurs, groupes, adresses, références et documents commerciaux. Une base documentaire aurait apporté davantage de souplesse, mais moins de garanties utiles ici sur les relations et l’intégrité des données.

Récapitulatif technique

Le socle final utilise PHP 8.3, Laravel 11.54.0, Inertia Laravel 2.0.24, Inertia React 2.3.25, React 18.3.1, TypeScript 5.9.3, Tailwind CSS 3.4.19, Vite 6.4.3 et MySQL 8.4. Ces versions constituent le récapitulatif technique de la version 1.0 présentée dans ce rapport.

Le socle privilégie la cohérence interne et la centralisation des règles ; son couplage Laravel–Inertia reste un compromis assumé.