258 lines
14 KiB
Markdown
258 lines
14 KiB
Markdown
# Proposition de sujets pour l'année universitaire 2024-2025
|
||
|
||
## Sujet proposé par Simon Chollet : OCTOPUS - OctoNAS
|
||
|
||
Contact : simon.chollet@ens.psl.eu
|
||
|
||
### Contexte ###
|
||
|
||
Le CEREEP-Ecotron Ile-de-France est une unité d’appui et de recherche (UAR 3194) rattachée aux tutelles : CNRS et ENS, elle est située à
|
||
SAINT-PIERRE-LES-NEMOURS (77). Cette unité est une structure d’accueil et d’accompagnement de la recherche expérimentale en
|
||
écologie. L'unité développe une offre diversifiée de services de recherche en écologie expérimentale et dispose actuellement de huit plateaux
|
||
techniques. Elle coordonne ces différentes plateformes qui permettent de confiner et de manipuler des organismes et des écosystèmes terrestres
|
||
et aquatiques dans des conditions contrôlées et largement instrumentalisées. Les plateformes sont ouvertes aux équipes publiques ou
|
||
privées nationales et internationales sur le principe d'une mise à disposition des équipements, des instruments et des moyens analytiques du
|
||
centre par voie de collaboration ou de prestation.
|
||
|
||
### OCTOPUS ###
|
||
|
||
Pour les plateformes de chambres climatiques (ECOLAB), nous avons le projet de mise en place d'un ensemble de composants logiciels et matériels qui
|
||
permettent de mettre à jour le contrôle-commande-acquisition de ces installations. Cet ensemble permettra d'assurer unitairement le bon
|
||
déroulement d'une expérience dans les chambres climatiques, depuis sa mise en place, son déroulement jusqu'à la livraison des données au chercheur.
|
||
Le projet est nommé "OCTOPUS" : Orignal Control Tools fOr Processing and acqUire Systems. Les différents composants de ce projet permettent de
|
||
gérer :
|
||
* le pilotage des automates ;
|
||
* le contrôle des paramètres d'expérimentation ;
|
||
* l'acquisition des différentes données ;
|
||
* le stockage et l'archivage des données ;
|
||
* la mise à disposition des données aux chercheurs ;
|
||
* le traitement, l'analyse "simple" en ligne des données.
|
||
|
||
Il est développé sur des bases "Open Source".
|
||
|
||
### OctoNAS ###
|
||
|
||
#### Introduction ####
|
||
|
||
L'objectif principal du composant OctoNAS (Orignal Control Tools fOr Network Attached Storage) est de
|
||
mettre en place un système dédié aux expériences pour le stockage et éventuellement le traitement et la
|
||
visualisation des données. Ce composant est de type serveur.
|
||
|
||
#### Fonctionnalités ####
|
||
|
||
Les fonctionnalités principales de ce système sont les suivantes :
|
||
* Stocker les données d'une expérience.
|
||
* Gérer les accès utilisateurs et groupes.
|
||
* Disposer d'une interface Web pour :
|
||
- administrer les droits ;
|
||
- télécharger les données ;
|
||
- naviguer sur les données.
|
||
* Proposer les protocoles : SMB/CIFS, (S)FTP,RSYNC, NFS, SSH.
|
||
* Enregistrer/journaliser les transferts de données.
|
||
* Proposer un cryptage/décryptage de données.
|
||
* Proposer une application cliente pour l'accès distant.
|
||
* Automatiser, pour chaque expérience :
|
||
- la création de l'arborescence ;
|
||
- la génération de la documentation associée aux données ;
|
||
- la génération de programmes permettant la synchronisation des données d'une machine à une autre ;
|
||
- la génération d'une partie du PGD (Plan de Gestion de Données).
|
||
* Dupliquer les données sur d'autres serveurs.
|
||
* Exporter l'ensemble des données d'une expérience.
|
||
* Archiver les données.
|
||
* Exécuter des scripts de traitement et d'analyse de données.
|
||
* Proposer des interfaces de visualisation des données.
|
||
|
||
Le composant pourra être composé de plusieurs logiciels / scripts, chacun ayant une fonctionnalité.
|
||
|
||
#### Technologies ####
|
||
|
||
Les technologies envisagées/proposées sont les
|
||
suivantes :
|
||
|
||
* Serveurs : NAS (OpenMediaVault ?), BDD (MariaDB), Web (Apache), API REST, Représentation graphique (Grafana ?)
|
||
* Langages de programmation : Python, C, JAVA
|
||
* Systèmes : Linux, Docker, RAID
|
||
* Formats : JSON, NetCDF
|
||
|
||
## Sujet proposé par Laura Fontanella : Programmation d'une application mobile en réalité augmentée
|
||
|
||
Contact : laura.fontanella@u-pec.fr
|
||
|
||
Le but du projet c'est de programmer une application mobile en Réalité Augmentée. L'application consistera en un Escape Game AR. On pourra
|
||
utiliser le logiciel de conception de jeux Unity. L'application devra proposer une expérience interactive en implémentant des interactions
|
||
et manipulations d'objets via l'écran et en appliquant des technologies telles que Image Tracking et Raycasting. L'évaluation portera non
|
||
seulement sur la réussite du projet mais aussi et surtout sur l'organisation du code selon les bonnes pratiques de conception et programmation
|
||
orientée objet.
|
||
|
||
À noter : la réalisation du projet nécessite de dispositifs compatibles avec ARCore ou ARToolKit (voir la liste
|
||
ici https://developers.google.com/ar/devices)
|
||
|
||
## Sujets proposés par William Giuseffi
|
||
|
||
Contact : wil.iutsen@gmail.com
|
||
|
||
1. une GED (référencement des documents, recherche, gestion des droits, etc.)
|
||
2. une application de gestion des budgets des projets (qui permet à tous les responsables de rentrer leurs estimations, les modifier,
|
||
comparer des previsions, etc.)
|
||
|
||
Sur chaque appli, il sera possible d'ajouter un module de BI comme apache superset. Utilisation de technologies web et aussi Docker en fonction du temps.
|
||
|
||
Prendre contact avec William Giuseffi pour avoir plus de précisions sur les sujets
|
||
|
||
## Sujet proposé par Luc Hernandez : Plateforme de Correction
|
||
|
||
Contact : luc.hernandez@u-pec.fr
|
||
|
||
### Description ###
|
||
|
||
Ce service doit accompagner les enseignants dans leur correction de
|
||
copies en enregistrant leurs observations (y compris les effets de
|
||
celles-ci sur la note). Le but est de produire à la fin un rapport qui
|
||
peut être présenté à l'étudiant pour l'aider à voir ses erreurs. Tout
|
||
sera fait pour accélérer le travail de correction, notamment en
|
||
réutilisant au maximum les informations déjà saisies (observations,
|
||
barèmes, etc).
|
||
|
||
### Compétences ###
|
||
|
||
+ Une base de données assez complexe sera requise.
|
||
+ La programmation web aura une part importante.
|
||
+ L'ergonomie de l'interface utilisateur sera cruciale.
|
||
|
||
### Prolongements ###
|
||
|
||
Ce service devrait idéalement pouvoir communiquer avec d'autres outils
|
||
pour recevoir les listes d'étudiants et envoyer les notes obtenues.
|
||
L'administration des serveurs web et bd sous forme de conteneur Docker
|
||
ou d'instance virtuelle serait un plus.
|
||
|
||
## Sujet 1 proposé par Félix Legrelle : A la recherche du meilleur kebab
|
||
|
||
Contact : legrelle.f@gmail.com
|
||
|
||
Nous savons que l’un des repas préférés des étudiants est le kebab. Mais aujourd’hui, il est difficile de trouver LE bon kebab de sa région.
|
||
Actuellement, le site leader dans ce domaine (et le seul) est https://www.kebab-frites.com/. Malheureusement, ce site a plusieurs désavantages :
|
||
une charte graphique qui ne met pas assez en avant les restaurants, un manque de données pour les maîtres kebabiers sur les clients, etc.
|
||
|
||
Le but du projet serait donc de concurrencer le leader de la recommandation de kebabs. Pour ce faire, les étudiants devront développer un back
|
||
en ExpressJs + TypeScript et un front en ReactJs + TypeScript. Le site aurait deux vues : une pour les clients qui veulent avoir des recommandations
|
||
de kebabs et une autre pour les maîtres kebabiers afin de faire venir de potentiels clients et avoir des datas.
|
||
Afin d’avoir des données pour le site, les étudiants devront développer un script pour scraper afin de remplir leur base de données.
|
||
|
||
## Sujet 2 proposé par Félix Legrelle : Planificateur de menus
|
||
|
||
Contact : legrelle.f@gmail.com
|
||
|
||
Le projet consiste à développer une application web permettant de générer des menus personnalisés pour une semaine complète.
|
||
L'assistant devra prendre en compte plusieurs critères, comme par exemple le nombre de personnes, les préférences alimentaires, la saison,
|
||
ainsi que les habitudes personnelles (par exemple, certains plats sont préférés pour le midi ou le soir). En fonction de la réalisation
|
||
ou non de la recette, celle-ci sera proposée à nouveau plus ou moins rapidement.
|
||
|
||
Ce projet vise à faciliter la planification des repas en fournissant des suggestions adaptées aux goûts et aux besoins des utilisateurs,
|
||
tout en simplifiant la création de fiches recettes et l'intégration d'une liste de courses via des services externes comme "Bring!" ou
|
||
directement dans l’application. Un système de partage de calendrier ou de recettes devra être réalisé.
|
||
|
||
Pour développer ce projet, les étudiants devront utiliser :
|
||
* Frontend : ReactJs + Typescript
|
||
* Backend : ExpressJs + Typescript
|
||
|
||
|
||
## Sujet proposé par Oleg Loukianov : Site de gestion des stages
|
||
|
||
Contact : oleg.loukianov@u-pec.fr
|
||
|
||
### Principales fonctionnalités ###
|
||
|
||
* partie présentation : modalités, dates etc
|
||
* importation de données depuis delpaa ou autre
|
||
* optimisation de publipostage
|
||
* création d'une interface de communication pour les tuteurs/stagiaires/maitres de stage
|
||
* interface de saisie/visualisation des disponibilités pour les soutenances
|
||
* apprentissage et optimisation de la dépendance entre les critères de notation et la note attribuée
|
||
* export vers scodoc ou autre
|
||
|
||
## Sujet proposé par Maxime Menault : Système de gestion de stockage de lot X-FAB France
|
||
|
||
Contact : Maxime.Menault@xfab.com
|
||
|
||
### Contexte ###
|
||
|
||
Nous possédons actuellement un système vieillissant que nous souhaitons remplacer afin de pouvoir diminuer notre dette technique. Ce système
|
||
permet de contrôler des machines appelées Stockers, et un système de transportation automatisé appelé AeroTrack. Un stocker est une machine de
|
||
stockage, constitué de plusieurs matrices, elle-même constitués de plusieurs étages, eux-mêmes contenant plusieurs emplacements. Les stockers
|
||
permettent de stocker des lots, qui sont les produits de l'entreprise. Ces machines peuvent communiquer avec des systèmes informatiques externes
|
||
via une connexion TCP, et le protocole SECS/GEM HSMS (standard de l'industrie du semiconducteur). Un Stocker s'identifie via un
|
||
"toolid" (Identifiant Machine) sur quatre caractères (ex: "W113"), possède une capacité maximum (ex: 120 lots), un nombre de port
|
||
entrée/sortie (appelés IOPort) (ex : 4), ainsi qu'un nombre de port AMHS (appelés AMHSPort) (ex : 1).
|
||
L'AeroTrack est un système d'AMHS, qui relie physiquement chaque stockers entre eux, via un rail aérien. L'AeroTrack est constitué de plusieurs
|
||
nœuds et de rails, chaque nœuds pouvant relier plusieurs rails et au maximum un stocker par nœud. Les nœuds de l'AeroTrack s'identifient via
|
||
un ID unique (ex : 12345). Un lot est un produit de l'entreprise, il s'agit d'une boite en plastique contenant jusqu'a 25 tranches de silicium
|
||
de 200mm de diamètre, contenant elle même jusqu'à plusieurs milliers de puces. Un lot est identifié par un couple "lotid" sur
|
||
10 caractères (ex: "THWP4370XA") et un "lotseq" sur deux caractères (ex: "01").
|
||
|
||
### Besoins ###
|
||
|
||
Le nouveau système de gestion de stockage de lot doit :
|
||
* Être connecté en permanence à tous les stockers de la ligne de production
|
||
* Communiquer avec ces stockers :
|
||
- Récupérer leurs évènements d'entrées et de sorties de lot (produit de l'entreprise)
|
||
- Envoyer des commandes pour déplacer les lots d'un stocker à un autre via l'AeroTrack
|
||
* Être capable de recevoir une commande d'un système externe (appelé MES, Manufacturing Execution System) de déplacement de
|
||
lot d'un stocker à un autre
|
||
* Pouvoir voir à tout moment la position de chaque lot contenus à l'intérieur des stockers
|
||
* Avoir un schéma de la position géographique de chaque stockers de la ligne de production et des nœuds du système d'AMHS
|
||
* Avoir un historique des mouvements effectués sur les lots
|
||
|
||
### Contraintes ###
|
||
|
||
Uniquement les langages suivants peuvent être utilisés : C / C# / Java / Python / Javascript / Typescript / HTML / CSS / SQL
|
||
|
||
Les données du système doivent être sauvegardés en base de données (MySQL, MariaDB ou MongoDB au choix).
|
||
|
||
Le code doit être livré avec les documentations suivantes : architecture technique, architecture fonctionnelle, cahier des charges
|
||
technique & fonctionnel, manuel d'exploitation.
|
||
|
||
Le code doit pouvoir être exécuté 7j/7-24h/24 (la robustesse du code est obligatoire, ex: pas de fuite mémoire, pas de crash).
|
||
|
||
|
||
## Sujet proposé par Maxime Pierront : Application collaborative pour ergothérapeutes
|
||
|
||
Contact : maxime.pierront@gmail.com
|
||
|
||
### Objectif ###
|
||
|
||
Créer une application collaborative pour les ergothérapeutes, facilitant le partage de bonnes pratiques et d'exercices.
|
||
|
||
### Collaboration ###
|
||
|
||
Travail étroit avec une ergothérapeute pour identifier et répondre aux besoins spécifiques.
|
||
|
||
### Technologies ###
|
||
|
||
* Backend : Développement en Java.
|
||
* Frontend : Utilisation d'un framework web (React, Angular, ou Vue.js).
|
||
* Bases de Données :
|
||
- SQL pour les données structurées.
|
||
- NoSQL pour les données non structurées.
|
||
|
||
## Sujets proposés par Pierre Valarcher
|
||
|
||
Contact : pierre.valarcher@u-pec.fr
|
||
|
||
1. Programmes qui interagissent avec les réseaux sociaux Instagram et X (dans le cadre de l’audit des algorithmes de modération des plateformes
|
||
droit du numérique). Le but consiste à écrire des procédures automatisées : (i) d’envoi de posts (à partir de plusieurs comptes et de plusieurs
|
||
machines) et (ii) de récupération de la « visibilité » des posts. Ce sont les étudiantes et les étudiants de droit qui à heure régulière et jour
|
||
régulier lanceront les écrits depuis leur machine avec un ou deux comptes. La récupération, dans l’idéal, devra être centralisée, mais on peut
|
||
envisager dans un premier temps une récupération locale qu’on fusionnera dans un 2eme temps.
|
||
2. Travail sur les données ( https://transparency.dsa.ec.europa.eu/data-download ). Les plateformes de ventes, RS, … doivent depuis un certain
|
||
temps (Art. 17 du DSA) dire pourquoi des actes sont restreints (comptes et messages) lors de leur utilisation. Art 24 demande que ces informations
|
||
soient envoyées à une BD (DSA Transparency). Les données sont archivées et libre d’accès. Nous aimerions que soient développées des outils de
|
||
visualisation (dans un premier temps) et nous aimerions voir si certaines activités sont liées à des informations particulières (déclenchement de
|
||
guerres, crise, …).
|
||
3. Anonymisation de messages tickets. Une base de données de ticket est mise à notre disposition et nous souhaitons en retirer le maximum
|
||
d’informations (en anonymisant) pour alimenter une IA Générative.
|
||
4. Un projet d’IA pour la sélection à MonMaster ou parcoursup.
|
||
|
||
Les sujets prioritaires sont les 1 et 2. Prendre contact avec Pierre Valarcher pour avoir plus de précisions sur les différents sujets.
|
||
|