Infrastructure de collecte

01 Contexte

L'ambiance d'un lieu (café, bibliothèque, parc) varie au fil des heures et des jours. Ce projet vise à construire une infrastructure qui capte cette ambiance en quasi temps réel via des capteurs et la rendinterrogeable par n'importe quel client (via HTTP).

Le système reçoit deux types de données :

02 Travail à réaliser

Le travail se décompose en six tâches. Elles suivent l'ordre de l'échéancier mais peuvent se chevaucher.

Tâche 1 — Choisir un lieu et planifier la collecte

Choisir un lieu réel (café, parc, bibliothèque, etc.) que l'équipe instrumentera avec un téléphone. Définir comment vous collecterez les données environnementales (méthode automatique, manuelle, ou mixte). Prévoyez au moins 3 sessions de 20 minutes, à des moments différents de la journée ou de la semaine.

Tâche 2 — Concevoir le protocole

Définir l'ensemble des règles qui régissent la communication avec votre système. Ce protocole sera documenté dans le rapport et comprend :

• Ressources et endpoints — quels chemins existent, quelles méthodes, quels corps, quelles réponses
• Conventions — nommage des ressources, format des dates, structure des erreurs, enveloppe de réponse
• Filtrage et consultation — comment un client filtre par lieu, par période, par type
• Authentification — quel mécanisme, quel en-tête, quel flux

Le protocole doit inclure au minimum 3 endpoints sémantiques de consultation au-delà des endpoints de collecte.

Les exemples ci-dessous sont un point de départ.

Endpoints de collecte

Endpoints de gestion

Endpoints sémantiques (minimum 3)

Ces endpoints ne se contentent pas de retourner des données brutes. Ils répondent à des questions concrètes sur l'ambiance d'un lieu. Exemples :

Gestion des lieux

La stratégie de gestion des lieux est à votre discrétion : création explicite via un endpoint dédié, création implicite à la première mesure, ou autre. Documentez votre choix.

Tâche 3 — Implémenter le serveur

Mettre en place un serveur Express connecté à MongoDB Atlas qui implémente tous les endpoints définis dans votre table. Le serveur doit :

• Parser le corps JSON des requêtes
• Valider les données entrantes (champs requis, types)
• Persister les mesures et observations en base
• Retourner les codes de statut appropriés (201, 400, 404, etc.)

Tâche 4 — Mettre en place la collecte

Acheminer les données du capteur (Phyphox) vers le serveur. Le bridge — un script qui interroge le capteur à intervalle régulier et POST les données vers l'API — est l'approche recommandée, mais votre équipe peut proposer une alternative si elle la justifie.

Tâche 5 — Ajouter l'authentification

Protéger les endpoints d'écriture (POST) par une clé API transmise dans l'en-tête x-api-key. Le serveur vérifie que la clé correspond à un device enregistré.

Les requêtes de lecture (GET) restent publiques.

Tâche 6 — Collecter les données

Réaliser au moins 3 sessions de collecte de 20 minutes dans votre lieu, à des moments différents. L'objectif est d'avoir suffisamment de données pour que les endpoints sémantiques retournent des résultats significatifs.

03 Livrables

Implémentation Dépôt Git

Le serveur doit satisfaire les exigences suivantes :

• Express connecté à MongoDB Atlas — connexion fonctionnelle au cluster, variables d'environnement pour les secrets
• Organisation facilitant l'évolution — séparation des routes, des modèles et des middlewares dans des fichiers distincts (pas tout dans un seul index.js)
• Toutes les routes du protocole implémentées — les endpoints de collecte, de gestion, et les 3+ endpoints sémantiques définis dans votre spécification
• Données seed — un script ou un fichier permettant de peupler la base avec des données de démonstration (devices, mesures, observations) pour tester les endpoints de consultation sans effectuer une collecte complète
• Authentification par clé API — middleware qui vérifie x-api-key sur les routes d'écriture, codes 401/403 appropriés
• Mécanisme de collecte fonctionnel — bridge, script, ou autre approche qui achemine les données du capteur vers le serveur. Le choix est justifié dans le rapport

README.md dans le dépôt

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

• Description du projet (2-3 phrases)
• Prérequis (Node, MongoDB, Phyphox)
• Installation et lancement (npm install, .env, npm start)
• Table des endpoints
• Tests (avec Postman)
• Fichier .env.example

Rapport (un par équipe)PDF sur Studium

Le rapport est la spécification de votre protocole : un document qui décrit les règles de communication avec votre système. Il suit la structure suivante :

1. Ressources et endpoints — table complète des endpoints avec méthodes, chemins, corps attendus, réponses et codes de statut. Justifier le découpage en ressources : pourquoi ces regroupements, quelles alternatives ont été envisagées, quelles entités du domaine sont devenues des ressources et lesquelles ne l'ont pas été.
2. Conventions — nommage des ressources, format des horodatages (ISO 8601? Unix?), structure d'erreur (quels champs dans une réponse d'erreur), enveloppe de réponse (tableau nu ou objet avec métadonnées?). Pour chaque convention, expliquer l'intention : quel problème elle résout, quel comportement elle rend prévisible pour le client.
3. Authentification — mécanisme choisi, flux complet (comment un client s'enregistre, obtient une clé, l'utilise), comportement en cas de clé absente ou invalide. Identifier la vulnérabilité de POST /devices non protégé et proposer une solution.
4. Collecte — comment les données vont du capteur au serveur, pourquoi cette approche, à quelle fréquence, quel format pour les batches. Description de la méthode de collecte des données environnementales et du fallback manuel.
5. Agrégation — comment les endpoints sémantiques (/ambiance) calculent leurs réponses à partir des données brutes. Quels seuils, quelle logique de classification, quelle fenêtre temporelle.
6. Limites et évolution — vulnérabilités identifiées, compromis assumés, ce qui changerait avec plus de temps ou d'expérience.

04 Évaluation

05 Échéancier