Projet académique clientFullstack / Outils internes

Strassable

Plateforme de planification opérationnelle pour événements sportifs urbains avec synchronisation web-mobile terrain.

Strassable est un outil fullstack construit pour l’Eurométropole de Strasbourg afin de préparer des événements sportifs sur carte, organiser les équipes et équipements de sécurité, générer les supports de planification et synchroniser le terrain vers une application mobile par QR code.

ReactTanStack RouterNestJSPrisma

Vue d’ensemble

Le produit repose sur trois surfaces coordonnées : un éditeur cartographique web pour préparer l’événement, une API NestJS qui centralise les domaines métier et les transferts, et une application mobile utilisable sur le terrain. La partie intéressante n’est pas le CRUD, mais la coordination entre cartographie locale, sessions QR temporaires et stockage mobile SQLite pour travailler malgré des contraintes de connexion.

Clients

3 applications coordonnées

Synchronisation

Sessions de transfert QR

Cartographie

Tuiles locales + recherche

Mode terrain

Stockage mobile hors ligne

Défis techniques

Support hors ligne utile

Équilibrer une logique locale avec les contraintes réelles de routage, de cartographie et de synchronisation.

Frontières entre clients

Garder des contrats explicites entre web, API et mobile alors que chaque client manipule une partie différente du workflow.

UX opérationnelle sur carte dense

Rendre lisibles les parcours, points de sécurité, équipements et plannings sans tomber dans une interface d’administration générique.

Architecture

Architecture de synchronisation opérationnelle

Strassable combine un éditeur cartographique web, des services de carte locaux, des sessions de transfert QR et une application mobile terrain hors ligne.

Opérations

Préparation et supervision d’événements

Éditeur carte

Projets, parcours, équipes, points de sécurité

API transfert

Orchestration métier et endpoints de transfert

App terrain

Client mobile hors ligne pour les équipes

Cartes locales

MBTiles et recherche d’adresse locale

Base projet

Projets, planning, matériel, photos

Pont QR

Session temporaire entre clients

Données terrain

Points traités, photos, retours équipes

La supervision commence dans l’éditeur cartographique web

L’API stocke les projets, équipes, parcours et équipements

Les tuiles et la recherche d’adresse locales gardent la carte exploitable

Les sessions QR encadrent les flux d’import et de retour

L’application mobile travaille sur des données SQLite locales

Les photos et points traités reviennent dans le projet central

Mécaniques visibles

États d’interface et extraits courts montrant l’éditeur web, le transfert QR et l’expérience mobile terrain.

Éditeur web Strassable avec carte et contrôles opérationnels

Éditeur cartographique web

L’interface desktop sert d’espace de préparation : projets, édition de carte, lecture temporelle et supervision restent au même endroit.

Vue timeline desktop Strassable montrant l’avancement opérationnel

Lecture timeline

Un second état web centré sur la lecture temporelle et opérationnelle plutôt que sur l’édition statique de la carte.

Écran mobile pour connecter l’application terrain au logiciel desktop

Appairage par QR code

Le client mobile rejoint une session de transfert temporaire créée depuis l’éditeur web.

Carte mobile terrain affichant les parcours et données du projet

Carte terrain

Après import, le projet peut être consulté dans l’application mobile avec une vue locale adaptée au terrain.

Formulaire mobile de création d’un point de sécurité sur site

Saisie terrain

Le mobile n’est pas seulement en lecture : les équipes peuvent structurer les retours et ajouter des points à sécuriser.

Flux de transfert

Extrait montrant l’import d’un projet depuis le produit desktop vers le client mobile.

Action mobile

Démonstration compacte d’une action terrain : créer et structurer un point depuis le workflow mobile.

Lecture opérationnelle

Extrait desktop centré sur la lecture temporelle d’un plan d’événement préparé.

Analyse

Défis techniques

La difficulté principale venait de la coordination entre clients.

+

Le défi était de garder l’éditeur web, l’API backend et l’application mobile synchronisés sans rendre le système trop couplé. L’API devait porter des domaines projet clairs et exposer des transferts compréhensibles pour l’import comme pour le retour terrain.

Le hors ligne ajoutait une vraie contrainte. La cartographie devait rester utilisable localement, le mobile devait persister les données en SQLite et le parcours utilisateur devait rester cohérent après l’import d’un projet.

L’interface devait aussi rester lisible malgré la densité : parcours, zones, équipes, équipements, points à sécuriser et lecture temporelle cohabitent sur la même surface.

Choix d’architecture

La séparation en trois clients vient du workflow produit.

+

Le produit se découpe naturellement en trois responsabilités : un client de préparation desktop, un backend qui porte les domaines et la synchronisation, et un client mobile centré sur l’exécution terrain.

Côté backend, les modules restent explicites autour des projets, transferts, équipes, points et équipements de sécurité. Côté mobile, Expo SQLite et Drizzle gardent les données importées accessibles sans connexion permanente.

Le transfert QR rend la synchronisation explicite et temporaire, ce qui correspond mieux au cas d’usage qu’une application mobile supposée toujours connectée à la même session.

Limites et compromis

Le projet est solide architecturalement, mais pas parfaitement homogène.

+

Une partie de la documentation historique ne reflète plus exactement l’implémentation actuelle, ce qui ajoute du bruit à la lecture externe du projet.

Le hors ligne est solide pour les tuiles locales, la recherche d’adresse et le stockage mobile, mais certaines logiques de navigation dépendent encore de services externes.

Le projet reste un bon cas portfolio parce qu’il montre une architecture fullstack réelle, une synchronisation multi-clients et des décisions produit sous contraintes.