Contexte

La STS SAM organise un “stage-dating” pour les sections SAM-1 et SIO-1.

Cet évènement se déroule en deux temps :

  • Les étudiant·e·s se présentent brièvement (1’-1’30”) (cf “pitch”) devant un jury de tuteur·ice·s qui à cette occasion sélectionnent sur une application mobile les étudiant·e·s avec qui ils souhaitent avoir un entretien.
  • Deux sessions d’entretiens sont organisées, au cours desquelles chaque tuteur·ice rencontre plusieurs étudiant·e·s, et chaque étudiant·e un·e tuteur·ice. Chaque entretien dure de 7’ à 10’.

Les étudiant·e·s de SIO-2 sont en charge du développement de l’application permettant aux tuteur·ice·s de sélectionner les étudiant·e·s, puis de visualiser le planning des entretiens.

Version 1.0

Contraintes organisationnelles

  • Chaque tuteur·ice peut sélectionner autant d’étudiant·e·s qu’il la·le souhaite.
  • Chaque étudiant·e doit rencontrer deux tuteur·ice·s différents (un à chaque session), qu’il·elle ait été·e sélectionné·e ou non.
  • Dans la mesure du possible, il faut que chaque tuteur·ice puisse voir au moins un et un maximum d’étudiant·e·s de son choix.

Contraintes fonctionnelles

  • L’application doit être conçue pour une utilisation depuis un smartphone, sans installation (application web mobile).
  • La liste des étudiant·e·s et tuteur·ice·s est insérée en base de données par la·le responsable du traitement à partir d’un fichier CSV.

Cas d’utilisation

Phase 1

  • En tant que tuteur·ice ou étudiant·e, je peux m’identifier - sans mot de passe - en indiquant mon nom et mon prénom.
  • En tant qu’étudiant·e, je vois un message d’attente (phase 1 - de sélection - non terminée).
  • En tant que tuteur·ice, je vois la liste des étudiant·e·s ; celles.eux sélectionnés doivent être mis en évidence.
  • En tant que tuteur·ice, je peux sélectionner et dé-sélectionner un ou plusieurs étudiant·e·s.
  • En tant que professeur·e (gestionnaire), je peux visualiser la liste des tuteur·ice·set étudiant·e·s et clôturer la sélection (phase 1) et déclencher la répartition des entretiens (phase 2).

Remarque : dans la pratique, il y aura des imprévus, notamment des absent·e·s le jour de l’évènement, ce qui va poser problème lors de la répartition… Il peut aussi y avoir des tuteur·ice à inscrire… Les cas d’utilisations ont ainsi dû être révisés pour en tenir compte :

  • En tant que tuteur·ice ou étudiant·e, je peux m’inscrire à l’évènement en choisissant mon statut.
  • En tant que professeur·e, je peux supprimer un·e étudiant·e ou tuteur·ice (absent, erreur ou sabotage).

Phase 2

  • En tant qu’étudiant·e, je peux consulter la liste de mes entretiens.
  • En tant que tuteur·ice, je peux consulter la liste des étudiant·e·s qui m’ont été affectés pour les deux sessions.
  • En tant que professeur·e, je peux visualiser le tableau de passage / répartition des entretiens pour les deux sessions pour chaque les tuteur·ice.
  • En tant que professeur·e, je peux clôturer l’événement.

Contraintes techniques

  • L’application doit être développée en PHP avec SGBD MariaDB. L’hébergement est sur un serveur Debian 13 avec Apache-2.4, PHP-8.4 et MariaDB-11.8 ; le serveur de développement est web.sio.local.
  • L’interface utilisateur doit être réalisée en utilisant le cadriciel W3.CSS.
  • Les codes CSS et HTML doivent être valides.

Contraintes légales

  • L’application ne doit pas comporter de traceur.
  • Les mentions légales de l’application doivent être conformes à la LCEN.
  • L’application traite de données nominatives. Il convient de limiter celles-ci à la finalité du traitement (cf RGPD) et d’en informer les utilisateurs et utilisatrices : uniquement les noms et prénoms, à l’exception de toute autre donnée.
  • Ni les étudiant·e·s, ni les professeur·e·s (ni les autres tuteur·ice·s) ne doivent pouvoir prendre connaissance des sélections. Toutes les données doivent être supprimées au plus tard 24 h après l’évènement.

Travail à faire

  • Récupérer le schéma de la base de données ainsi que le script de création des tables fournis : lien DBConcept.

  • Utiliser une IA générative pour créer un jeu d’essai comprenant 24 étudiant·e·s et 6 tuteur·ice·s.

  • Sur papier, dessiner les différents écrans de l’application.

  • Réaliser ensuite la maquette HTML / W3.CSS des écrans avec ou sans l’aide de l’IA générative.

  • Récupérer (cf ressource) les fichiers config.php (à adapter), index.php, action-login.php, action-logout.php, action-plan.php, action-unregister.php et action-init.php.

  • Analyser inc/teacher-vote.php - la page de visualisation des tuteur·ice·s et étudiant·e·s (profil professeur·e), et notamment la portion de code qui ajoute pour chaque personne un bouton de suppression :

    ```html
<form action="unregister.php" method="POST">
    <input type="hidden" name="id" value="identifiant_de_la_personne"/>
    <input type="hidden" name="status" value="statut_de_la_personne"/>
    <button type="submit">X</button><!--extrait simplifié-->
</form>
```

  • Développer :

    • inc/student-vote.php - la page d’attente (profil étudiant·e)
    • inc/tutor-vote.php - la page de visualisation et sélection des étudiant·e·s (profil tuteur·ice) ainsi que le fichier d’action associé vote.php

  • Réfléchir à un algorithme de planification des entretiens tenant compte des votes

    • Faire une simulation de sélection, puis élaborer manuellement le planning ; cf tableau de passage.
    • Suivre les instructions de l’algorithme pour élaborer le planning ; comparer avec la répartition manuelle.

  • Développer - pour chaque profil - les pages de visualisation du planning (inc/*-interview.php).

Liste des fichiers

L’application est organisée en plusieurs fichiers, pour l’affichage ou réaliser des actions.

  • config.php - paramètres de l’application
  • index.php - page d’accueil :
    • si la personne n’est pas connectée, affiche un formulaire pour se connecter
    • sinon redirige vers la page appropriée en fonction du statut et de la phase en cours
  • legal.php - mentions légales
  • action-login.php - connexion / inscription d’un·e étudiant·e ou tuteur·ice
    • si c’est un·e professeur·e, vérifie le mot de passe
    • sinon recherche l’utilisateur·rice parmi les étudiant·e·s et tuteur·ice·s
    • si non trouvé, l’utilisateur·rice est inscrit
    • enregistre les données de session (identifiant, nom, prénom et statut)
  • action-logout.php - déconnexion
  • action-vote.php - ajout / suppression d’un vote (bascule)
  • action-unregister.php - suppression d’un·e étudiant·e ou tuteur·ice
  • action-plan.php - répartition des étudiant·e·s pour les entretiens
  • action-init.php - effacement des données de la base, et pour la version de développement, création d’un jeu d’essai
  • inc/ :
    • student-vote.php
    • student-interview.php
    • teacher-vote.php
    • teacher-interview.php
    • tutor-vote.php
    • tutor-interview.php
    • head.html - entête HTML commun à toutes les pages d’affichage
    • card.php - Nom de la personne connectée et bouton de connexion commun aux pages d’affichage inc/tutor/student/teacher-vote/interview.php

Les pages d’actions redirigent toutes vers la page d’accueil (cf header('Location: index.php');).

Versions suivantes

Version 1.1

Dans cette version, les photos des étudiant·e·s sont ajoutées.

Contrainte technique : les photos doivent être stockées dans la base de données - à adapter (ajout d’un champ TEXT pour stocker les données formatées en base64).

Contrainte qualité : les photos doivent être optimisées pour ne pas dépasser les 32 kio.

Les retours du client font également part du besoin d’afficher le nom des organisations d’accueil. Une possibilité serait de modifier la page de connexion, pour ajouter un troisième champ “Organisation d’accueil” à la place des boutons radios : ce champ serait laissé vierge par les étudiant·e·s, et auto-complété pour un·e tuteur·ice déjà inscrit·e.

Version 1.2

Dans cette version, le Javascript est utilisé - côté client - pour améliorer l’expérience utilisateur lors de la sélection.

Le rechargement automatique de la page une fois par minute est à envisager.

Version 1.3

Dans cette version un·e tuteur·ice doit pouvoir ordonner sa sélection. De plus, pour la répartition, une priorité est donnée à la·le tuteur·ice qui s’est décidé en premier.

Autres version

  • Pour l’installation :
    • script de déploiement et de mise à jour ;
    • interface de paramétrage de la base de données ;
    • interface de personnalisation (logo, proviseur, mentions légales).
  • Gestion des inscriptions :
    • interface d’import les utilisateur·rice·s ;
    • interface d’ajout et modification utilisateur·rice·s.
  • Configuration :
    • interface de modification du mot de passe ;
    • interface pour autoriser / interdire les nouvelles inscriptions ;
    • interface pour définir le nombre de sessions ;
    • interface pour activer / désactiver les données de test.
  • Pour l’ergonomie :
    • ajout d’un canal de communication en arrière plan (websocket ou requête Fetch / AJAX) pour informer les utilisateur·rice·s des changements sans rechargement de la page.