Sujets de projet informatique 2A

Sujets 2026-2027

Tip

Anonymia

Tuteur : Maxence Lagalle

Présentation

Quand une administration veut publier un courrier, un compte-rendu ou répondre à une demande citoyenne, elle doit en retirer les données personnelles — souvent désignées par l’acronyme anglais PII (Personally Identifiable Information) : noms, adresses, numéros de téléphone, NIR, IBAN. Cette opération de caviardage est aujourd’hui souvent manuelle. Anonymia est une application web qui automatise ce travail. Elle expose une API REST (construite avec FastAPI) qui ingère un document texte et restitue la liste des PII détectées puis une version anonymisée.

Pour des raisons de souveraineté numérique, le traitement reste en local autant que possible : la donnée sensible ne transite pas par des services externes. La détection combine deux approches complémentaires :

Des expressions régulières pour les éléments à format fixe (NIR, IBAN, e-mails, numéros de téléphone, dates, etc.).
Un grand modèle de langage (LLM), pour les éléments à format libre (noms, lieux, organisations). Le LLM est servi par l’API SSPCloud (API OpenAI-compatible mise à disposition par l’école), ou en repli par un modèle local de taille modérée (par exemple Gemma 4 E4B sur Ollama, exécutable sur un poste étudiant).

Un LLM peut être manipulé par le contenu qu’on lui soumet (« attaque par injection de prompt »). Le projet aborde frontalement ce risque en y consacrant une fonctionnalité dédiée (F5).

L’architecture cible est une architecture en couches (présentation, service, persistance), avec des interfaces définies à deux endroits-clés : les détecteurs de PII et les stratégies d’anonymisation. Ce choix permet d’ajouter un nouveau détecteur ou une nouvelle stratégie sans toucher au reste du code, et de tester la logique métier indépendamment de l’infrastructure.

Fonctionnalités

F1 — Authentification et gestion des utilisateurs. Création de compte, connexion. Mots de passe hashés. Trois rôles : utilisateur (soumet des documents), superviseur (accède à la page de consultation et au tableau de bord), administrateur (gère les comptes : création, modification du rôle, désactivation, suppression). Un compte administrateur initial est créé au démarrage de l’application.
F2 — Détection des données personnelles. Soumission d’un document texte. L’application lance en parallèle une détection par expressions régulières et une détection par LLM, fusionne les résultats et restitue à l’utilisateur la liste annotée des PII détectées (position, type, niveau de confiance, détecteur d’origine). Si le service LLM est indisponible, l’application continue de fonctionner avec les expressions régulières seules.
F3 — Anonymisation. Production d’une version anonymisée du document, selon une stratégie au choix : masquage ([NOM_1]), ou pseudonymisation cohérente (Pierre Dupont → Jean Martin, le même nom recevant toujours le même substitut dans le document).
F4 — Journalisation et consultation. Pour chaque traitement, l’application enregistre des métadonnées : date, utilisateur, hash du document (jamais le contenu brut), nombre et types de PII détectées, détecteurs ayant contribué. Un outil de consultation est mis à disposition des superviseurs et des administrateurs, qui peuvent filtrer par utilisateur ou par période.
F5 — Sécurisation du détecteur LLM. Un LLM peut être manipulé par le contenu qu’on lui soumet : un document peut contenir des instructions cachées (« ignore les consignes précédentes ») visant à détourner son comportement. Cette fonctionnalité durcit le détecteur LLM de F2 par trois mécanismes complémentaires : (1) un prompt système strict qui cadre le rôle du modèle et impose un format de sortie JSON contraint, (2) un pré-filtrage des documents pour détecter les patterns d’injection connus, et (3) une vérification de la sortie du modèle pour s’assurer qu’elle est cohérente avec le document fourni (positions valides, pas d’invention). Un jeu de tests adversariaux fourni par le tuteur sert de validation : le détecteur doit conserver son comportement normal même face à des documents piégés. ### Fonctionnalités optionnelles
FO1 — Détecteur par modèle de NER local. Ajout d’un troisième détecteur basé sur spaCy. Le modèle utilisé (fr_core_news_lg) est un outil de NER (Named Entity Recognition, ou reconnaissance d’entités nommées) : un modèle pré-entraîné qui identifie automatiquement noms de personnes, lieux et organisations dans un texte. Cette FO permet de comparer la qualité d’un détecteur dédié au NER avec celle du LLM généraliste, sans dépendance à un service externe.
FO2 — Anonymisation directe par LLM. Un mode supplémentaire d’anonymisation où le LLM produit en une seule étape le document anonymisé, plutôt que de simplement détecter les positions. L’utilisateur peut alors comparer le résultat avec celui produit par le pipeline classique (détection puis substitution) et apprécier les différences en termes de fluidité, de naturel et de fidélité au document source.
FO3 — Juge d’injection LLM. Ajout d’un second appel LLM jouant le rôle de « juge » : sa seule mission est de décider si le document soumis tente de manipuler le système. Il s’exécute en parallèle de la détection principale et son verdict enrichit les métadonnées de journalisation sans bloquer le pipeline.
FO4 — Console d’exploration. Interface utilisateur interactive complétant l’API par un outil d’analyse adapté aux utilisateurs métier. Permet de soumettre des documents et visualiser les PII détectées (mises en évidence dans le texte source), de comparer côte à côte les résultats des différents détecteurs sur un même document afin d’apprécier leurs forces et faiblesses, et de consulter sous forme graphique les indicateurs d’activité enregistrés en F4 (volumétrie, fréquence des types de PII détectées, et plus généralement tout indicateur que les élèves jugeront utile). Le périmètre exact du visuel est laissé à l’appréciation du groupe.

Les fonctionnalités sont organisées pour permettre une mise en œuvre progressive : une application minimale fonctionnelle peut être livrée avec F1, F2 (regex seules) et F3 dès la phase d’immersion, avant d’ajouter les autres briques. Un retard sur une fonctionnalité ne bloque pas les suivantes. Pour les groupes ayant pris de l’avance sur le périmètre de base, le tuteur pourra proposer des fils rouges d’approfondissement complémentaires (organisation du code, robustesse, tests avancés, etc.).

Conseils / Outils

Python 3.12+
FastAPI en mode asynchrone (async/await, parallélisation des détecteurs avec asyncio.gather)
PostgreSQL avec couche d’accès aux données (DAO) écrite à la main avec psycopg, sans ORM
LLM : Ollama en local (recommandé pour le développement), ou SSPCloud via son API OpenAI-compatible. Aucune API LLM commerciale n’est autorisée sur du contenu réel.
Tests : pytest + pytest-asyncio
Linting : ruff

Sources :

Guide CNIL sur l’anonymisation : https://www.cnil.fr/fr/lanonymisation-des-donnees-un-traitement-cle-pour-lopen-data
OWASP Top 10 for LLM Applications (notamment LLM01 : Prompt Injection) : https://genai.owasp.org/

Projet LaborScope : Analyse interactive du marché du travail mondial (ILOSTAT)

Tuteur : Anas KNEFATI

Présentation

Le projet LaborScope a pour objectif de développer une API dédiée à l’analyse des statistiques mondiales du marché du travail. Deux formules sont possibles au choix : développer uniquement l’API, ou développer l’API accompagnée d’un front (par exemple avec Streamlit ou dash de plotly) qui vient s’y connecter. Cette application s’appuie sur les données ouvertes fournies par l’API ILOSTAT (Organisation Internationale du Travail), accessible via https://rplumber.ilo.org pour l’ensemble des pays et régions du monde (formats CSV, JSON, Excel), qui propose des indicateurs trimestriels tels que : - l’emploi par sexe et profession: https://rshiny.ilo.org/dataexplorer33/?lang=en&segment=indicator&id=EMP_5EMP_SEX_OC2_NB_Q&channel=ilostat - ou la population en âge de travailler par sexe et âge: https://rshiny.ilo.org/dataexplorer91/?lang=en&segment=indicator&id=EMP_5WAP_SEX_AGE_RT_Q&channel=ilostat

L’ambition est de construire un pipeline complet, allant de la récupération périodique des données à leur traitement, leur analyse et leur visualisation graphique. L’outil permettra à l’utilisateur de suivre l’évolution de l’emploi par pays, sexe, tranche d’âge ou catégorie professionnelle, et de comparer les marchés du travail entre différents pays.

Fonctionnalités

F1 : Récupération et extraction des données Automatiser la récupération périodique des données via l’API ILOSTAT (au minimum les deux indicateurs fournis, sur plusieurs pays). Extraire et stocker localement les données pour analyse.
F2 : Parsing et stockage des données Implémenter un parser (CSV/JSON) pour extraire les champs jugés essentiels (pays, sexe, tranche d’âge, profession, période, valeur). Stocker les données dans une base de données locale.
F3 : Analyse temporelle de l’emploi Permettre le calcul de l’évolution d’un indicateur donné (ex : emploi par profession) sur une période définie (par exemple : les 8 derniers trimestres) et afficher les résultats sous forme de graphiques.
F4 : Comparaison entre pays Pour la période la plus récente disponible, permettre à l’utilisateur de comparer un indicateur (ex : taux d’activité par sexe et âge) entre plusieurs pays sélectionnés, et d’identifier les pays avec les valeurs les plus hautes/basses.
F5 : Comparaison multi-indicateurs Permettre la comparaison simultanée de l’évolution de plusieurs indicateurs (ex : emploi et population active) sur un même graphique.
F6 : Gestion des utilisateurs et des accès Mettre en place un système d’authentification avec plusieurs niveaux d’accès : • Utilisateurs : consultation des analyses et des visualisations. • Administrateurs : gestion des données (modification, suppression), suivi des activités.

Fonctionnalités optionnelles

FO1 : Fonctionnalité libre Proposez une fonctionnalité originale et pertinente, que vous estimez utile dans le cadre du projet soit en utilisant les mêmes données soit en utilisant d’autre données dans l’API ILOSTAT.
FO2 : Cartographie interactive Permettre à l’utilisateur de visualiser un indicateur sur une carte du monde (choroplèthe), avec un code couleur selon la valeur par pays.
FO3 : Génération automatique de rapports analytiques

Permettre à l’utilisateur de générer automatiquement un rapport d’analyse au format PDF contenant par exemple :

 - les principaux indicateurs sélectionnés ;
 - les graphiques d'évolution sur une période donnée ;
 - les comparaisons entre pays ;
 - un résumé statistique (minimum, maximum, moyenne, évolution sur la période) ;
 - une conclusion synthétique générée automatiquement à partir des données observées.

Outils

Traitement des données : Pandas
Visualisation : Matplotlib, Seaborn, Plotly, GeoPandas/Folium pour FO3
Sécurité : bcrypt, sessions/tokens
Framework front : Streamlit ou Dash (Plotly)

Conseils

Utilise l’IA comme un maître qui t’apprend à pêcher, non comme un pêcheur qui pêche à ta place.

Celui qui demande à l’IA d’expliquer progresse ; celui qui copie sans comprendre régresse. »

Ex-Libris

Tuteur : Elwenn Joubrel

Présentation

Le cinéma a Letterboxd, la musique a Last.fm, mais le livre reste étonnamment mal servi : les lecteurs assidus n’ont guère d’autre choix que Goodreads, propriété d’Amazon. Ex-Libris propose une alternative d’application de suivi de lecture.

En pratique, le projet repose d’abord sur le développement d’une API REST (construite avec FastAPI) exploitant les données de l’API publique Open Library, qui référence plusieurs millions d’ouvrages. Dans un second temps, on pourra développer un client pour crédibiliser l’expérience utilisateur.

L’application permet à ses utilisateurs de retrouver des livres, les ajouter à leur bibliothèque, faire le suivi de leurs lectures, les noter et les critiquer. Le catalogue n’est pas à construire : il existe déjà chez Open Library. Ce que l’application doit apporter, c’est justement ce qu’Open Library ne sait pas : qui a lu quoi, quand, avec quel avis.

Fonctionnalités de base

F1 : Un visiteur peut créer un compte et s’authentifier par mot de passe. L’application ne propose pas de consultation anonyme : toute action suppose un compte
F2 : Un utilisateur peut rechercher des livres et consulter une fiche détaillée : couverture, auteur(s), année de parution, nombre de pages, éditions, etc.
F3 : Un utilisateur peut ajouter un livre à sa bibliothèque avec un statut (à lire, en cours, lu, abandonné), le noter, renseigner ses dates de lecture, et consulter sa bibliothèque avec filtrage
F4 : Un utilisateur peut rédiger une critique sur un livre de sa bibliothèque, la modifier ou la supprimer. Les critiques d’un livre sont consultables par les autres utilisateurs
F5 : Une fonctionnalité plus exigeante, qui demande de concevoir un traitement. Vous avez le choix entre les fonctionnalités suivantes, et pouvez également proposer une fonctionnalité équivalente qui vous plairait plus. Chacune se prête à plusieurs solutions techniques, du SQL bien pensé à l’IA générative : le choix de l’approche et toute la démarche scientifique associée font partie du travail.
- F5A : La consultation des avis d’un livre propose un résumé : traitement statistiques des notes, repérage des ouvrages clivants, synthèse des points émergents, etc.
- F5B : L’utilisateur a accès à une méthode de recommandation de livres basée sur ses propres lectures, ses notes, ses genres de prédilection, ou sur base des lectures d’utilisateurs similaires
- F5C : Normalisation des genres littéraires issus d’Open Library : l’API référence énormément de genres différents qui manquent de cohérence, présentent de nombreux doublons, etc. On pourra imaginer une solution qui restreigne ce périmètre pour faciliter la recherche par genre.

Fonctionnalités optionnelles

FO1 : Dimension sociale - un utilisateur peut s’abonner à d’autres lecteurs, parcourir leur profil et leur bibliothèque, et suivre leur activité (ajouts, lectures terminées, notes, critiques) dans un fil chronologique
FO2 : Développement d’un frontend. Interface complétant l’API par un véritable outil de lecture : recherche interactive, affichage des couvertures, rendu du fil d’activité, etc. Le frontend ne contient aucune logique métier et n’accède jamais à la base : il consomme exclusivement votre API.
FO3 : Statistiques de lecture - livres lus par mois, total de pages, note moyenne, répartition par genre ou par auteur, objectif de lecture annuel et suivi de la progression
FO4 : Création de listes thématiques nommées (« Lectures d’été », « Meilleure SF »), publiques ou privées, avec ordonnancement des livres
…
FOX : Vous pouvez évidemment laisser libre cours à votre imagination et implémenter les fonctionnalités qui vous intéressent (« j’aime » sur les critiques, export CSV, défis de lecture entre amis, etc.)

Conseils / Outils …

Langage : Python
Outil de versionnage : Git
Base de données : PostgreSQL
Backend API : FastAPI
Frontend (Attention, l’accompagnement sera limité selon le framework choisi) : en Python (streamlit, tkinter, reflex, etc.) ou HTML/JS/CSS (React, Vue, etc.) selon votre appétence
Tests : pytest
Linting : ruff

🚄 Concurrent SNCF

Tuteur / Tutrice : Kévin LEROY

Présentation

Contexte : Vous êtes développeur pour une toute nouvelle société de transport ferroviaire qui exploite le réseau SNCF.

Objectif : Vous devez mettre en place une solution permettant au service commercial de votre entreprise de proposer des trajets en train à ses clients. Les webmasters de votre entreprise prennent en charge le développement de l’interface utilisateur, il vous reste uniquement à charge le développement d’une API.

API utilisée (pour récupérer les gares existantes et les temps de trajet en train) : API SNCF (https://numerique.sncf.com/startup/api/)

Fonctionnalités de base

👤 F1 : Gestion des comptes utilisateur
Un utilisateur peut créer un compte avec un nom d’utilisateur et un mot de passe.
Trois niveaux d’habilitation sont possibles : CLIENT, COLLABORATEUR et ADMIN.
Un compte ADMIN peut gérer (augmenter ou diminuer) le niveau d’habilitation des comptes utilisateurs.
Il ne peut pas modifier le niveau d’habilitation des autres comptes ADMIN.

🛤️ F2 : Gestion des lignes d’exploitation
Un compte COLLABORATEUR peut créer une ligne d’exploitation entre une gare de départ et une gare de terminus. Les gares sont déjà existantes et doivent être récupérées à partir de l’API SNCF. Une aide à la saisie (par autocomplétion) des gares permet de s’assurer que la gare saisie existe réellement.
Un compte COLLABORATEUR peut modifier une ligne d’exploitation.
Un compte COLLABORATEUR peut supprimer une ligne d’exploitation.

🚆 F3 : Gestion des trajets proposés
Un compte COLLABORATEUR peut planifier des trajets sur une ligne d’exploitation (date et heure de départ, nombre de places et tarif). Il faut vérifier que le trajet entre la gare de départ et le terminus est possible en train. Le temps de trajet doit être calculé automatiquement à partir de l’API SNCF.
Un compte COLLABORATEUR peut modifier un trajet planifié.
Un compte COLLABORATEUR peut supprimer un trajet planifié.

🔍 F4 : Recherche d’un trajet
Un compte CLIENT peut rechercher les trajets proposés à partir d’une gare de départ et d’une gare d’arrivée. Une aide à la saisie (par autocomplétion) des gares permet d’aider le client à trouver le nom des gares.
Le client doit pouvoir visualiser, au minimum, la gare de départ, la gare d’arrivée, la date et l’heure de départ, le temps de trajet.

✨ F5 : Positionnement commercial
Cette fonctionnalité est laissée libre : vous devez proposer une fonctionnalité qui permet de vous différencier du réseau commercial de la SNCF. Quelques exemples : - Nombre de places restantes : possibilité pour un compte CLIENT de visualiser le nombre de places restantes dans le train lors de la recherche d’un trajet (si vous avez réalisé la FO1) ; - Tarification transparente : possibilité pour un compte CLIENT de visualiser la répartition de la tarification (coût d’exploitation, marge réalisée, etc) lors de la recherche d’un trajet ;

Fonctionnalités optionnelles

FO1 : Réservation de trajet
Un compte CLIENT peut réserver un trajet.
Un compte CLIENT peut visualiser ses réservations (passées et à venir).
Un compte CLIENT peut annuler une réservation.

FO2 : Classes de voyage
Un train dispose de 2 classes de voyage (CLASSIQUE, PREMIUM) avec des tarifications différentes.
Un compte CLIENT doit pouvoir choisir sa classe de voyage lors de la réservation d’un trajet.

Conseils / Outils

Pas de contraintes supplémentaires par rapport à celles évoquées lors de la présentation du projet. Une interface n’est pas obligatoire, le swagger de l’API peut suffir. Vous êtes l’expert technique, le choix des outils est donc volontairement laissé libre et à étudier pendant la phase de cadrage.

Quelques conseils :

Tenir compte des succès / échecs de votre projet Python de 1A ;
Une application développée proprement et dans le respect des bonnes pratiques est toujours préférable à un nombre de fonctionnalités (préférez la qualité, quite à laisser de côté une des fonctionnalités) ;
Les fonctionnalités présentées ci-dessus sont classées par ordre d’importance métier dans l’application ;
Si vous souhaitez utiliser une interface pour valoriser vos travaux concernant l’API, vous pouvez la vibe-coder ;

🌐 API SNCF

Demande de token gratuit : https://numerique.sncf.com/startup/api/token-developpeur/
Documentation : https://doc.navitia.io/#getting-started

API de calcul des degrés jours unifiés (DJU)

Tuteur / Tutrice : Thierry Mathé

Présentation

Avec les besoins de chauffage et de climatisation, une partie des consommations d’énergie est liée aux variations de températures. Il s’agit essentiellement des consommations du secteur résidentiel et du secteur tertiaire. Cette sensibilité aux températures complique l’interprétation des évolutions de consommation car il n’est pas évident de faire la part entre les évolutions dues aux variations de températures de celles dues à d’autres facteurs conjoncturels ou structurels comme des changements d’habitudes de consommation, le remplacement d’équipements énergivores, la conversion vers d’autres énergies … Le degré jour unifié ou DJU est l’outil de référence permettant d’avoir un estimateur de la rigueur du climat et de calculer des consommations corrigées des variations climatiques (CVC). Les consommations CVC ont pour but de gommer les variations de consommation dues aux variations climatiques et de n’observer que les variations dues aux autres facteurs. Le projet consiste en la création d’une API permettant de calculer les DJU en un point précis repéré par ses coordonnées GPS ou sur des zones géographiques définies par des ensembles de communes.

Fonctionnalités

F0 : Création des bases de données à partir des relevés de température des stations de Météo France et du référentiel des communes disponibles sur data.gouv.fr
F1 : Calcul des DJU localisés sur une période et une périodicité donnée. Par exemple calcul des DJU mensuels du 1er janvier 2010 au 31 décembre 2025.
F2 : Intégrer les zonages Département, Région pour tous les utilisateurs
F3 : Calcul des DJU sur un territoire avec une granularité, une période et une périodicité données. Par exemple calculer les DJU annuels des départements d’Ile-de-France du 1er janvier.
F4 : Permettre à un utilisateur authentifié de créer et de conserver ses propres zonages constitués d’ensemble de commune.

Fonctionnalités optionnelles

FO1 : Conserver les résultats des calculs effectués
FO2 : Mise en forme des résultats sous différents formats
FO3 : Importer des zonages à partir de fichiers csv, json, …

Conseils / Outils

Voici un fichier décrivant plus en détail les DJU, les méthodes de calculs et leur utilisation: https://docs.google.com/document/d/14XQ9Mqt-VBvTAiacye8CqF7oBWEEg-Or/edit?usp=drive_link&ouid=112052176997696043897&rtpof=true&sd=true

CleanOps

Tuteur / Tutrice : Adrien Lacaille

Présentation

Dans l’ingénierie logicielle, la qualité d’une application ne se limite plus à l’absence de bugs. Elle doit aussi garantir la sécurité de ses dépendances et sa sobriété énergétique. CleanOps sera une api REST qui agit comme une plateforme d’audit automatique lors de la soumissions de code Python et de ses fichiers de dépendances.

Fonctionnalités

F1 : Signature cryptographique Chaque soumission de code doit être signée numériquement (HMAC) pour vérifier son intégrité et sa provenance avant tout traitement.
F2 : Audit de sécurité des dépendances Parsing des fichiers de dépendances, interrogation de l’api OSV pour remonter les CVE associées et identifier les licences logicielles à risque juridique.
F3 : Analyse éco-énergétique du code source Parsing de l’AST Python pour identifier les anti-patterns énergivores (boucles récursives ou imbriquées). Estimation de la complexité algorithmique, calcul d’une consommation théorique en kWh et conversion en émission gCO2e selon une machine type.
F4 : Génération du SBOM Export automatique de l’inventaire complet des composants logiciels du projet audité au format standart.
F5 : Journalisation, historique et Quality Gate Enregistrement des audits (métadata), Définition d’une Quality Gate permettant de délivrer ou refuser un certificat d’attestation si le niveau de vulnérabilité ou l’empreinte carbone est trop élevé.

Fonctionnalités optionnelles

FO1 : Intégration native CI/CD Authentification transparente sans mot de passe réservée aux pipelines CI/CD via jetons OIDC. Ajout d’un webhook publiant automatiquement un commentaire de synthèse sous les MR.
FO2 : Isolation applicative et Sandboxing du parser Sécurisation de l’API contre la soumission de code malveillant, exécution des parsers dans des sous-processus restreints (timeouts, allocations mémoire limitées) et protection contre le DDOS.
FO3 : Assistant de refactorisation Soumission des extraits de code problématiques à un LLM pour générer une version refactorisée éco-responsable. Mise en place d’un mécanisme de protection du LLM (Prompt injection defense) pour éviter que des commentaires malveillants cachés dans le code soumis ne détourne le comportement du modèle.
FO4 : Interface graphique Interface visuelle permettant de visualiser la structure du projet, le graphe des dépendances, la répartition des vulnérabilités et l’empreinte en gCO2e.

Projet VeloScope

Tuteur : André Rivière

Présentation

Les vélos en libre-service sont disponibles en temps réel dans de nombreuses villes. Pourtant, une simple carte des stations ne permet pas vraiment de répondre à des questions utiles : À quelle heure vais-je réellement trouver un vélo ? Quelles stations sont souvent pleines ? Quels trajets sont les plus fiables ? Est-ce qu’une station est régulièrement vide le matin mais pleine le soir ? Le projet VeloScope consiste à développer une API permettant de collecter, historiser et analyser les données de vélos en libre-service d’une ville. L’application récupère périodiquement les informations d’une API de vélos en libre-service compatible avec le standard GBFS : stations, nombre de vélos disponibles, nombre de places libres, vélos électriques, etc. Contrairement à une simple application de consultation, VeloScope doit construire son propre historique afin de permettre des analyses temporelles et de produire des indicateurs de fiabilité des stations.

Fonctionnalités

F1 : Gestion des utilisateurs Un utilisateur peut :
- créer un compte ;
- se connecter ;
- consulter les données et statistiques ;
- gérer ses stations favorites. Un compte ADMIN peut gérer les utilisateurs.
F2 : Collecte des données L’application doit interroger régulièrement l’API GBFS choisie et récupérer les informations des stations. Pour chaque relevé, on stockera notamment :
- station ;
- date et heure ;
- nombre de vélos disponibles ;
- nombre de places disponibles ;
- nombre de vélos électriques ;
- état de la station. Les données récupérées doivent être historisées en base PostgreSQL. L’application ne doit pas simplement remplacer les valeurs précédentes : elle doit permettre de reconstruire l’état du réseau à différents instants.
F3 : Consultation d’une station L’utilisateur peut rechercher une station et consulter :
- son état actuel ;
- son nombre de vélos disponibles ;
- sa capacité ;
- son taux de remplissage ;
- l’évolution de sa disponibilité sur une période donnée. L’utilisateur doit notamment pouvoir choisir une période :
- dernières 24 heures ;
- 7 derniers jours ;
- 30 derniers jours.
F4 : Score de fiabilité des stations C’est la fonctionnalité métier principale. Pour chaque station, l’application calcule un score de fiabilité. Par exemple, une station est considérée comme :
- vide lorsqu’il n’y a plus de vélo disponible ;
- saturée lorsqu’il ne reste plus de place ;
- fonctionnelle dans les autres cas. À partir de l’historique, l’application calcule notamment :
- pourcentage du temps passé vide ;
- pourcentage du temps passé saturé ;
- durée moyenne des épisodes de saturation ;
- durée moyenne des épisodes de pénurie ;
- évolution du score au cours du temps. Le score global est défini par les étudiants à partir d’une formule documentée.
F5 : Recommandation de station Lorsqu’un utilisateur demande : « Je veux prendre un vélo à proximité » l’API doit être capable de lui proposer plusieurs stations pertinentes. La recommandation doit prendre en compte plusieurs critères, par exemple :
- distance ;
- nombre de vélos actuellement disponibles ;
- fiabilité historique de la station ;
- disponibilité de vélos électriques ;
- tendance récente de la station. Deux stations à distance équivalente ne doivent donc pas nécessairement être classées de la même manière. La formule de classement devra être justifiée et testée.

Fonctionnalités optionnelles

FO1 : Prévision de disponibilité À partir de l’historique, tenter d’estimer la probabilité qu’une station soit vide ou saturée dans les prochaines heures. Il est possible de commencer avec un modèle statistique très simple avant d’utiliser une approche plus avancée.
FO2 : Heatmap du réseau Proposer une visualisation géographique permettant d’identifier :
- les zones où les stations sont souvent saturées ;
- les zones où les stations sont souvent vides ;
- les stations les plus fiables. Une carte interactive peut être proposée.
FO3 : Détection d’anomalies Détecter automatiquement les comportements inhabituels :
- station qui ne transmet plus de données ;
- variation impossible du nombre de vélos ;
- station bloquée dans le même état pendant une longue période ;
- apparition/disparition inhabituelle de vélos. L’API doit pouvoir signaler ces anomalies.
FO4 : Assistant de trajet L’utilisateur renseigne : station de départ + station d’arrivée et l’application propose plusieurs stratégies : rapide, fiable, vélo électrique, ou risque minimal. Chaque stratégie utilise une fonction de coût différente.
FO5 : Défi entre utilisateurs Les utilisateurs peuvent comparer leurs habitudes :
- nombre de trajets ;
- distance parcourue ;
- stations utilisées ;
- nombre de trajets réalisés avec un vélo électrique ;
- régularité d’utilisation. Des badges peuvent être attribués.

API externe

L’API externe n’est pas imposée. Les étudiants doivent identifier une ville proposant des données GBFS ouvertes, étudier sa documentation et intégrer son API. L’intérêt pédagogique est justement de devoir :

comprendre une API inconnue ;
identifier les données pertinentes ;
gérer ses évolutions ou erreurs ;
construire une couche d’abstraction afin que l’application ne dépende pas directement d’une ville particulière.

Contraintes techniques

Python
FastAPI
PostgreSQL
accès SQL explicite ou couche DAO
pytest
ruff
Git

Ensai Cinéma Club

Tutor: Clément Valot

Abstract

The Ensai Cinéma Club has gotten a sizeable budget increase for 2027 and plans on acquiring the Cinéville Bruz.

You have been tasked with prototyping the backend application in charge of handling the accounting and ticketing for the theater.

Features

F1: As an administrator, I can prepare the schedule of movie screenings
F2: As a customer, I can book a screening for an upcoming movie
F3: As an administrator, I can see accounting details for a given period

Optional Features

FO1: As a customer, I can rate and give my opinion on movies I have seen ⭐
FO2: Integrate with an external payment system (e.g. Stripe) ⭐⭐
FO3: Under the hypothesis that the Ensai Cinéma Club is in capacity to buy the Pathé Rennes by 2028, extend the application to accomodate for different theater locations. You must document, before implementation, the full impact analysis for the change ⭐⭐⭐

Specifications

Stack:

Programming language: Python
package/project manager: PDM (template provided)
Database: PostgreSQL
Dev tool suite provided with the template, to extend at your personal preference

You will benchmark and choose the most suitable API to retrieve movies information from:

imdb
TheMovieDB
OMDB (Open Movie Database)

NEO-Watch

Tutor: Olivier Ricciardi

Overview

Eeeh no, this project is not about smartwatches. I have a nobler objective to assign to you: save the world. Time may be running out. So, ready? Go!

Near-Earth Objects (NEOs) are asteroids or comets (Small Solar System Bodies, to put it poetically) whose calculable trajectories may bring them close to Earth’s orbit. But how close? Who really wants to end up like the dinosaurs or in a Lars von Trier movie? No one, right? Therefore, I am certain you will have no objection to creating an application that can monitor the NEOs catalogued by NASA, by querying, through a judiciously chosen API, the data that this agency makes available to everyone.

Basic features

More specifically, this application should include the following features

F1 : Manage users and access. Access to the application will be secured. There will be two types of users. Regular users, who will have to create an account (login + password) to be able to connect to the application, use its features and their personal space (see below), and administrators, special users who will be able to manage other users’ accounts, view the connection history, and choose to update NEO-Watch’s data using NASA’s API.
F2 : Provide users with a dashboard. The user will have a dashboard, presenting for example the next NEOs passing close to Earth, the number of potentially dangerous NEOs among the upcoming approaches, the NEO closest to Earth over a given period, and all sorts of information that you consider relevant. This dashboard will be somewhat personalized, notably by displaying the user’s favorite NEOs (see F5), etc.
F3 : Browse NEOs. The user will be able to search for one or more NEOs, according to criteria such as its name, identifier, dimensions, date of its next passage, etc. For each NEO viewed, you will display all characteristics that seem relevant. Sorting according to different criteria will be offered, as well as an export of the results in a format of your choice.
F4 : Create a NEO. The user who observes it will be able to add a NEO to the API’s database. Care must be taken to ensure that created NEOs are not overwritten during successive updates of this database with data from NASA’s API.
F5 : Manage a favorites list. The user will be able to add or remove NEOs from a viewable favorites list. For each NEO on this list, a history of its distance from Earth will in particular be kept, and may be used to produce exportable graphs.
F6 : Create alerts. The user will be able to define alerts, centered on NEOs or not, such as: « Notify me when an asteroid more than 100 meters in size passes within 5 million kilometers of Earth ». If the application detects such events, a notification will be sent to the user when they log in.

Optional features

FO1 : Compare several NEOs. The user will be able to select several asteroids and compare their characteristics (size, speed, distance from Earth, passage date, danger level, etc.). This comparison may be presented as a table or an exportable graph.
FO2 : Keep search history. Each user will be able to view their search history for the last 30 days. In addition, administrators will be able to view the histories of users of their choice. Each search will therefore result in a record containing, at a minimum, the author, timestamp and asteroid concerned.
FO3 : Build some statistics. The user will be able to access statistics such as the number of asteroids observed per month, size distribution, evolution in the number of approaches, average distance from Earth, proportion of objects classified as potentially dangerous, etc. The statistics must be relevant and justified.
FO4 : Suggest an interesting NEO. The application will recommend to the user a selection of NEOs that could be particularly interesting to observe, based on explicit criteria of interest, which could, for example, combine size, distance, speed, rarity of passage, potentially dangerous nature, etc.
FO5 : Communicate. The application will allow users and administrators to communicate by email. The former may, for example, report a bug to the latter, or inform them of a connection problem. The latter may notify them of the deletion of their account, regularly send them their statistics, etc.
FO6 : Propose modifying a NEO. Why not, right? The user, an amateur astronomer, will be able to propose modifying certain data relating to a NEO. The administrator will be notified of the proposed modifications (and the process will stop there, alas, since there is no question of modifying NASA’s data via the API that it so graciously makes available to us!)
FO7 : Automatically reload the data. For those interested in the concept of batch processing, you can develop an automatic reloading of the API database from the data made available by NASA’s API. This reloading would replace the administrator’s manual action.
FO8 : Make people dream a little. Since everything is not just anxiety and destruction, and since the sky has always made people dream, the application will allow the user to export the picture of the day, which NASA provides via a dedicated API.

Advice / Tools

Tools:

Language : Python
Version control tool : Git
Database : PostgreSQL
Backend API : FastAPI
Frontend : in python (streamlit, tkinter, reflex, etc.) or HTML/JS/CSS (React, Vue, etc.)
Tests : pytest