Cultural Trails

Nous sommes partis d'une base Laravel Breeze, qui nous a donné l'authentification, Tailwind et Vue clés en main, puis avons pris la décision qui a tout façonné : Blade, Livewire ou Inertia. Nous avons choisi Inertia. Elle nous a permis de construire une application monopage avec des transitions fluides tout en écrivant le back-end comme une application Laravel normale, sans API REST séparée à concevoir, versionner et maintenir synchronisée.

C'est ce choix qui a permis à une équipe de cinq personnes d'avancer vite. Inertia fait le pont entre le back et le front, si bien qu'un contrôleur renvoie les données directement à une page Vue, et la frontière dont j'avais la charge (les modèles, les requêtes, les règles d'accès) est restée propre et côté serveur tandis que le front-end restait réactif.

Le cœur du back-end est le schéma. Un sentier (parcours) est relié à de nombreux points d'intérêt et un point d'intérêt peut appartenir à de nombreux sentiers, donc la table de jonction entre eux porte l'ordre de la marche. Chaque point d'intérêt possède ses propres guides audio, photos et faits ; chaque sentier appartient à un thème. Au-dessus du contenu se trouve un modèle de quiz (quiz, questions, réponses) pour les arrêts gamifiés.

Vient ensuite la couche d'engagement, celle qui donne le sentiment d'un produit plutôt que d'un catalogue : favoris et historiques de complétion pour les sentiers comme pour les points d'intérêt, accomplissements avec une table pivot utilisateur, avis, et un système de rôles sous l'ensemble. Bien établir ces relations dès le départ, c'est ça l'architecture ; tout le reste se construit dessus.

L'application sert deux publics depuis le même code. Un explorateur parcourt la carte, arpente un sentier, marque des points d'intérêt comme faits, et gagne des accomplissements. Un éditeur (un acteur culturel local) crée et édite des sentiers et des points d'intérêt à l'aide de formulaires guidés, avec ses propres flux de création et de suppression.

Cette séparation est imposée par l'accès basé sur les rôles. Les routes des favoris, du tableau de bord, des accomplissements et de l'édition sont protégées par un middleware de rôle, si bien que la même application expose en toute sécurité une expérience publique et la boîte à outils d'un contributeur sans que l'une déborde sur l'autre.

Les cartes interactives tournent sur MapLibre, et les sentiers eux-mêmes sont de vrais itinéraires, ce qui implique une planification d'itinéraire entre les points d'intérêt. Nous avons utilisé OpenRouteService pour cela via son API publique, en l'appelant depuis le flux d'édition pour planifier un itinéraire au fur et à mesure qu'un sentier était construit. Auto-héberger le moteur était la suite logique, que nous avons signalée pour un vrai déploiement, afin d'échapper aux limites de débit publiques et de lever toute contrainte sur cette planification.