Consommation et visualisation

01 Contexte

Au terme de la phase 1, vous disposez d'une API qui collecte, persiste et expose l'ambiance (interprétée) d'un lieu. La phase 2 vise à construire l'application cliente qui consomme votre API et la rend compréhensible pour une personne ou entité publique.

Vous devez construire une interface réactive de consommation et de visualisation, qui authentifie les actions protégées et qui reste lisible dans tous ses états (chargement, erreur, vide). Les lectures (consulter l'ambiance) sont publiques ; les écritures (soumettre une observation) demandent une authentification.

02 Travail à réaliser

Tâche 1 : Collecter de nouvelles données

À l'aide du mécanisme de collecte de la phase 1, recueillir de nouvelles données : au moins 12 nouvelles mesures, réparties sur3 lieux différents. La reprise du lieu de la phase 1 est permise comme l'un des trois. Ces données alimentent les visualisations et rendent l'application réaliste.

Tâche 2 : Application cliente, accès public

Construire la partie publique de l'application cliente. L'interface doit rendre le portrait lisible d'un coup d'œil en utilisant un badge de classification (calme, modéré, animé), un graphe d'historique et les créneaux calmes.

Il faut construire une couche client qui isole les appels à votre API. Tout le travail de classification et d'interprétation doit être fait côté serveur. L'espace public du client est responsable de l'affichage et de l'interrogation des données. Toutefois, les réponses de l'API doivent être descriptives pour rester compréhensible sans documentation externe.

La visualisation comprend au minimum deux représentations complémentaires :

• Une vue carte respectant les spécifications minimales suivantes :
  • les lieux positionnés sur une carte à partir de leurs coordonnées
  • chaque marqueur portant la classification d'ambiance courante renvoyée par l'API
  • un clic sur un lieu qui mène à son portrait d'ambiance
  • La carte reste lisible quand un lieu n'a pas de mesure récente
  Le seuil de fraîcheur (au-delà duquel une mesure n'est plus « récente ») est choisi par l'équipe et justifié dans le rapport.
• Une vue détaillée d'un lieu respectant les spécifications minimales suivantes :
  • le badge de classification fourni par l'API
  • le graphe d'historique et les créneaux calmes tels que votre API les exposent, avec leurs échelles

Tâche 3 : Actions protégées et espace compte

L'application permet à un usager de se créer un compte et s'authentifier. L'interface reflète l'état connecté ou déconnecté et affiche ou masque les actions selon ce qui est permis.
Elle présente un moyen de soumettre une observation (une fois authentifié) et permet de gérer ses lieux, c'est-à-dire les lieux où il a effectué des écoutes, et ses lieux favoris.

Tâche 4 : Infrastructure, mise à jour

La phase 2 fait apparaître des besoins que l'infrastructure de la phase 1 ne couvrait pas forcément. Mettre l'API à jour pour les satisfaire, sans casser ce qui existait :

• Coordonnées des lieux. Le modèle de lieu porte une latitude et une longitude, exposées par l'API, pour situer les marqueurs sur la carte.
• Auteur des observations. Chaque observation est associée à l'usager qui l'a soumise, pour le récapitulatif des contributions et la notion de « ses lieux ». L'API permet de retrouver les observations d'un usager.
• Classification exposée. Le portrait d'ambiance renvoyé par l'API porte sa classification (calme, modéré, animé) et ses échelles, pour que le client l'affiche sans la recalculer.

03 Gestion de projet

Le travail se fait en équipe et doit se piloter comme un projet, pas seulement se coder.

• Tickets avec attributions. Le travail est découpé en tickets sur GitHub Issues, chacun attribué à un membre. L'avancement se suit par ces tickets : ce qui est à faire, en cours, terminé. Chaque membre porte des tickets identifiables.
• Au moins trois commits par semaine pour chaque membre, avec un message de commit pertinent qui mentionne le type d'action (ajout, modification, correction, refactoring...), les éléments visés et l'intention. Par exemple « ajout : vue carte, marqueurs colorés selon la classification ».
• Vérification de la compréhension, en labo, en semaine 2 ou 3. Une courte rencontre où chaque membre explique sa partie et la place dans l'ensemble : les endpoints consommés, le rôle de sa portion d'interface, les choix faits. L'objectif est de confirmer que le projet est compris par toute l'équipe.

04 Bonus

Deux extensions sont valorisées au-delà du socle et peuvent ajouter chacune jusqu'à 5 % à la note du livrable.

1. Backend en TypeScript: Porter le serveur de la phase 1 en TypeScript. Typer le modèle, la couche d'accès aux données et les routes, pour que le contrat entre le client et le serveur soit vérifié à la compilation.
2. Temps réel: Pousser les mises à jour d'ambiance vers le client (SSE ou WebSocket) plutôt que de les faire interroger, pour que l'affichage suive l'état sans rechargement.

05 Livrables

Implémentation Dépôt Git

L'application cliente (React) doit satisfaire les exigences suivantes :

• Consommation de l'API : une couche client qui isole les appels vers l'API
• Visualisation de l'ambiance : une vue carte (lieux situés, classification par marqueur, accès au portrait) et une vue détaillée (classification, historique, créneaux calmes), lisible et fondée sur les réponses de l'API
• Soumission d'observations : un formulaire qui envoie une observation, en respectant les valeurs attendues
• Authentification et espace compte : connexion, envoi du justificatif sur les écritures, état connecté reflété dans l'interface, lectures publiques, et un espace compte (identité, déconnexion, actions protégées, récapitulatif des contributions)
• Gestion des états : chargement, erreur et vide traités explicitement
• Organisation facilitant l'évolution : composants distincts, couche client séparée de l'interface

README.md dans le dépôt

Document technique pour un développeur qui veut relancer le projet :

• Description du projet (2-3 phrases)
• Prérequis (Node, l'API de la phase 1 en marche)
• Installation et lancement (npm install, npm run dev)
• Configuration : l'URL de l'API de la phase 1, avec un .env.example
• Comment se connecter et tester les actions protégées

Rapport (un par équipe)PDF sur Studium

Le rapport décrit la conception de l'interface et les choix faits. Il suit la structure suivante :

1. Conception de l'interface : les blocs, les vues, la méthodologie suivie, du layout à l'assemblage.
2. Consommation de l'API : la couche client, les endpoints utilisés, la gestion des erreurs et des cas limites.
3. Visualisation : les représentations choisies, comment les seuils et les unités rendent le portrait lisible, la justification du seuil de fraîcheur de la carte (au-delà duquel une mesure n'est plus récente), ce qui a été écarté.
4. Authentification et espace compte : le flux côté client, les actions protégées, la conservation du justificatif, la façon dont l'état se reflète dans l'interface, et l'extension du modèle qui lie une observation à son auteur (pour le récapitulatif des contributions et la notion de « ses lieux »).
5. Mise à jour de l'infrastructure : ce qui a été ajouté ou changé dans le modèle et les endpoints de la phase 1 (coordonnées, auteur des observations, classification exposée), et comment la collecte et les lectures existantes ont été préservées.
6. Réactivité et utilisabilité : les états gérés, la transparence, les heuristiques retenues.
7. Limites et évolution : compromis assumés, ce qui changerait avec plus de temps, et le cas échéant les bonus réalisés.

06 Évaluation

07 Échéancier