Community Platform

Architecture

Community Platform est une application Laravel 10 unique (PHP 8, MySQL) qui sert des pages Blade rendues côté serveur, déployée d'un seul tenant. L'authentification est par session ; l'autorisation repose sur un modèle de rôles maison stocké en colonne JSON sur l'utilisateur, vérifié par middleware, avec quatre rôles plateforme (admin, communication, membre, autre) distincts du profil fonctionnel du membre, qui est ce qui régit l'accès aux véhicules. La logique métier qui n'a pas sa place dans les contrôleurs vit dans des services dédiés (repas du dimanche, anniversaires, notifications, QR codes). Le planning des véhicules tient sa grille à jour via une petite API de polling auto-hébergée, ce sur quoi la production tourne ; une couche de broadcasting Laravel Echo et Pusher est câblée pour l'instantané et peut être activée sans toucher aux pages, et chaque appel de broadcast est encapsulé pour qu'un échec temps réel ne casse jamais la réservation sous-jacente. Les tâches récurrentes passent par le planificateur Laravel : trois commandes de maintenance (générer les prochains repas, fermer les inscriptions, purger les anciennes notifications) plus un worker de file d'attente sur base de données que le planificateur relance chaque minute, ce qui évite d'avoir un processus worker permanent sur le serveur. L'email sortant passe par un wrapper qui capture chaque échec d'envoi, l'enregistre dans une table dédiée, et laisse la requête aboutir.

Défis d’ingénierie

• Deux membres qui réservent la même voiture à la même seconde. Vérifier la disponibilité puis insérer une réservation, c'est une situation de course. J'ai encapsulé la réservation dans une transaction avec un verrou de ligne sur le véhicule et ajouté un index unique en base sur le créneau actif : la seconde écriture est rejetée par la base elle-même et l'utilisateur reçoit un message clair "vient d'être pris" au lieu d'un chevauchement silencieux.
• Le planning clignotait à chaque rafraîchissement. La grille était rechargée et re-rendue sur un minuteur, ce qui la faisait clignoter. J'ai centralisé la récupération des données dans une source unique qui met la grille à jour sur place, pour qu'une nouvelle réservation apparaisse sans redessiner toute la table.
• Tenir la grille à jour sans dépendre d'un service temps réel. Pusher ajoute une dépendance externe qui n'est pas garantie sur place : la production fait donc tourner le planning sur une API de polling auto-hébergée ; la couche Echo/Pusher reste dans le code, activable au besoin, et chaque appel de broadcast est encapsulé pour qu'un échec temps réel ne casse jamais la réservation sous-jacente.
• Des tâches qui dépendent de la mémoire de quelqu'un. Ouvrir les prochains repas et fermer les inscriptions étaient manuels. Les passer en commandes artisan planifiées, et faire tourner la file d'attente depuis le planificateur, a rendu la partie récurrente de l'application autonome.

Décisions techniques

• Colonne de rôles JSON maison plutôt qu'un package de permissions complet. La communauté a un jeu de rôles réduit et stable. Une colonne roles en JSON sur l'utilisateur avec une vérification par middleware suffit, sans le poids de schéma et de requêtes d'une librairie de permissions générale, et garde les rôles plateforme bien séparés du profil fonctionnel qui pilote l'accès aux véhicules.
• Blade rendu côté serveur plutôt qu'un front-end séparé. Un seul développeur, une seule cible de déploiement, un public qui a surtout besoin de formulaires et de listes. Blade avec un peu de JavaScript sur le planning se livre plus vite et s'héberge et se transmet bien plus simplement qu'une API plus une application monopage.
• Polling en production plutôt qu'un service temps réel hébergé. Le planning doit refléter les réservations des autres en quelques secondes, pas en millisecondes. Un endpoint de polling auto-hébergé y suffit, sans compte tiers, sans coût supplémentaire et sans rien qui puisse tomber ; le chemin Echo/Pusher reste prêt pour le jour où l'instantané vaudra la dépendance.
• File d'attente en base et worker piloté par le planificateur plutôt qu'un service de file dédié. L'email part de façon asynchrone pour qu'un serveur SMTP lent ne bloque jamais un membre, mais lancer le worker depuis le planificateur évite d'ajouter un processus supervisé (ou une dépendance Redis) sur un serveur modeste.