Un site vitrine pour une PME industrielle, construit là où le vrai travail est étroit et mérite d'être bien fait : charger vite, dire clairement ce que fait l'entreprise, et transformer une visite en contact qualifié — sans traîner un CMS pour du contenu qui change quelques fois par an.
Le problème et les contraintes
La tentation, sur un site pareil, est de dégainer un système de gestion de contenu par réflexe. Mais une PME avec quatre pages stables paie ce choix deux fois : une fois à l'installation et à l'hébergement, puis à chaque mise à jour du CMS pour du contenu que personne n'édite. La contrainte était un site qu'un développeur modifie en quelques minutes et qui n'a aucune pièce mobile à entretenir entre deux changements.
Approche
- Un seul contrôleur associant une action par page (accueil, à propos, services, contact) plus une action POST dédiée au formulaire — la table de routage se lit comme le plan du site.
- Un layout Blade partagé portant l'en-tête, le pied de page et le pipeline d'assets, pour qu'un gabarit de page ne contienne que ce qui distingue cette page.
- Validation côté serveur sur chaque champ soumis, avec
phoneetcompanyexplicitement facultatifs et un plafond de 2 000 caractères sur le message — les règles vivent là où on ne peut pas les contourner en désactivant JavaScript. - Vite pour le bundling des assets, ce qui rend le build CSS/JS identique à n'importe quel projet Laravel moderne plutôt que des balises de script gérées à la main.
Compromis faits
Decision
Des gabarits Blade plutôt qu'un CMS : aucune surface d'administration à sécuriser, aucune mise à jour d'extension, aucune dépendance à une base pour du contenu qui change quelques fois par an — en acceptant en échange qu'un développeur soit nécessaire pour les modifications, ce qui pour ce client coûte moins cher que l'alternative.
Decision
Les règles de validation dans le contrôleur plutôt qu'une classe FormRequest : à un seul formulaire, les extraire ajoute un fichier sans ajouter de clarté. À trois formulaires je les sortirais — le seuil, c'est la répétition, pas le principe.
Résultats
Quatre pages partageant un layout unique, avec un formulaire de contact qui rejette les saisies invalides côté serveur et confirme clairement en cas de succès. Le raccordement de l'envoi reste le point ouvert : la validation et le chemin de confirmation sont faits, le transport mail est en attente des paramètres SMTP du client.
Ce que je referais différemment
Terminer le transport mail en premier — le formulaire valide et confirme aujourd'hui sans expédier de message, exactement le genre d'écart qui paraît correct en test et fait perdre une vraie demande en production. Je limiterais aussi le débit de la route POST : un formulaire public sans throttle est une invitation ouverte au spam, et Laravel le fournit gratuitement avec un middleware.