Projet 1: Conception d'une application React pour les Avis et alertes de Montréal.
Contexte et objectifs
La section Avis et alertes présente les avis émis par la Ville de Montréal. Ces communications signalent des renseignements importants à la population (avis d'ébullition d'eau, travaux, fermeture de piscine, etc.) et peuvent avoir un impact direct sur la vie quotidienne.
L'objectif global de ce projet (réparti sur 3 phases) est de transformer ce site en application web progressive (PWA), consultable hors connexion et capable de notifier les citoyens lors d'une nouvelle alerte.
- Phase 1 (ce projet) : construction de l'interface interactive en React avec données fictives.
- Phase 2 : intégration de l'API de la Ville, enrichissement des filtres, transformation en PWA (installable et hors-ligne).
- Phase 3 : ajout d'un backend Express, de notifications push et optimisation.
Ce découpage influence vos décisions dès la phase 1 : découplez la couche de données de la couche de présentation. Idéalement, vos composants ne connaissent pas la source des données — ils consomment simplement un module de service, qui sera remplacé par un appel à une vraie API au projet 2.
Compétences visées
- Décomposer une interface en une arborescence de composants React.
- Gérer l'état local et le flux de données entre composants.
- Mettre en place du routage côté client.
- Implémenter une recherche et des filtres réactifs.
- Adapter une interface à des écrans de tailles variées.
- Organiser un projet frontend et le livrer via Git/GitHub.
Mandat
Vous devez créer une application React reproduisant fidèlement la structure de la page ci-dessus. L'application comportera deux pages principales :
- Page d'accueil : liste des alertes avec recherche et filtres.
- Page de détail : contenu complet d'une alerte sélectionnée.
Pages et fonctionnalités
En-tête (partagé)
- Logo de la Ville et lien Mon Compte (inactif — un clic peut afficher un simple message).
- Présent sur les deux pages principales.
- L'en-tête n'a pas besoin d'être collante (pas de
position: stickyrequis).
Page d'accueil
- Recherche : filtre la liste en fonction du titre de l'alerte.
- Correspondance partielle (sous-chaîne), insensible à la casse et aux accents.
- Mise à jour en temps réel pendant la saisie.
- Filtres (arrondissement, date, sujet) :
- Une seule valeur sélectionnée par filtre.
- Plusieurs filtres peuvent être actifs simultanément (combinaison « ET »).
- Filtre de date : deux champs
<input type="date">(date de début et date de fin, tous deux optionnels). - Un moyen de réinitialiser les filtres doit être accessible.
- Liste des alertes : pagination optionnelle. Choisissez l'une des approches :
- Afficher toutes les alertes sur une seule page, OU
- Un bouton « Charger plus » en fin de liste.
- S'abonner aux alertes : le lien M'abonner affiche un message indiquant que la fonctionnalité n'est pas encore disponible.
Page de détail
- Affiche le contenu complet de l'alerte sélectionnée (titre, arrondissement, date, sujet, description longue).
-
Doit être accessible via une URL dédiée (p. ex.
/alertes/:id) pour qu'on puisse y accéder directement, partager le lien ou rafraîchir la page. - Un lien/bouton permet de revenir à la page d'accueil.
Responsive design
- L'interface doit être lisible et fonctionnelle sur mobile (largeur minimale visée : 360 px).
- Au moins un point de rupture (breakpoint) distinct entre la version mobile et la version bureau.
États de chargement (optionnel, recommandé)
Même avec des données fictives, vous pouvez simuler un chargement asynchrone (voir découplage des données). Si vous le faites, affichez un indicateur visuel pendant le chargement. Cette pratique vous facilitera grandement la transition vers la vraie API au projet 2.
Contraintes techniques
- Cadriciel : React 18+ initialisé avec Vite.
- Routage :
react-router-dom(v6+). - Langage : JavaScript ou TypeScript (au choix).
- CSS : libre (CSS modules, CSS vanilla, Tailwind, styled-components...). Évitez de tout écrire dans un seul fichier global.
- État :
useState/useContextnatifs suffisent ; aucune bibliothèque externe (Redux, Zustand) n'est requise ni attendue. - Organisation : un composant = un fichier. Séparez les composants réutilisables (UI) des composants de page.
- Découplage des données : les données fictives doivent être
isolées dans un module dédié (p. ex.
src/services/alertes.js) exposant des fonctions asynchrones.
Exemple :
Vos composants consomment ces fonctions via// src/services/alertes.js const MOCK = [/* ... vos alertes ... */]; export async function getAlertes() { await new Promise(r => setTimeout(r, 200)); // simule la latence réseau return MOCK; } export async function getAlerteById(id) { const alertes = await getAlertes(); return alertes.find(a => a.id === id); }useEffect+useState, exactement comme ils le feraient avec une vraie API au projet 2.
Modèle de données
Fournissez un jeu d'au moins 20 alertes fictives réparties sur au moins 5 arrondissements et 3 sujets différents. Chaque alerte doit respecter au minimum le schéma suivant :
{
id: string, // identifiant unique
titre: string,
arrondissement: string, // ex: "Ahuntsic-Cartierville"
sujet: string, // ex: "Eau", "Travaux", "Loisirs"
dateEmission: string, // format ISO: "2026-04-15"
resume: string, // 1-2 phrases, affiché dans la liste
description: string // contenu complet, affiché en page de détail
} Vous pouvez ajouter des champs supplémentaires si cela vous est utile (statut, date d'expiration, etc.).
Remise
- Dépôt GitHub public (ou privé avec enseignant collaborateur).
-
README.mdincluant :- Nom(s) de l'étudiant·e(s).
- Instructions d'installation et de démarrage.
- Choix techniques principaux et justification sommaire.
- Lien du dépôt remis sur Léa avant la date limite : dimanche 6 avril 23 h 59.
- Pénalité de 10 % par jour de retard jusqu'au 8 avril. Au-delà, note de 0.
- Évaluation orale en classe le mardi 8 avril (≈ 10 min par étudiant·e) : présentation de l'application et questions sur le code et les décisions d'architecture.
Évaluation
Ce projet compte pour 30 % de la note finale, réparti comme suit :
| Critère | Pondération |
|---|---|
| Décomposition en composants (cohérence, réutilisabilité, responsabilités) | 20 % |
| Respect des spécifications fonctionnelles (pages, recherche, filtres, routage) | 25 % |
| Fidélité de l'interface utilisateur à la maquette | 15 % |
| Adaptation aux petits écrans (responsive) | 10 % |
| Qualité du code et respect des bonnes pratiques (nommage, structure, absence de code mort) | 15 % |
| Maîtrise du code (évaluation orale) | 15 % |