Situation retenue et besoin

L’application retenue est l’application web de stage-dating. Elle comprend des éléments de code qui s’exécutent côté serveur (PHP), et côté client et mobile (Javascript).

Dans son état actuel, cette application n’utilise pas de cadriciel.

Premier besoin

Lors de son utilisation, une fonctionnalité essentielle s’est avérée manquante et a nécessité une intervention en direct dans la base de données : la possibilité de revenir à la phase de vote après la planification.

Deuxième besoin

Il serait utile que les tuteur·ice·s puisse visualiser les photos des étudiant·e·s.

Proposition de solution - Premier besoin

Réflexion préliminaire

Il convient de rappeler que c’est l’absence ou la présence d’enregistrements dans la table Participation qui détermine la phase de sélection / vote ou d’entretiens. L’effacement du contenu de cette table permet donc de revenir à la phase de sélection.

Il convient d’identifier les raisons d’un éventuel retour à la phase de sélection. Lors de la première utilisation, nous avons dû la ré‑ouvrir parce qu’au moins un·e tuteur·trice n’avait pas finalisé sa sélection. D’autres solutions que la suppression des enregistrements de la table sont envisageables : par exemple, introduire une variable enregistrés dans un fichier. Cependant, ce type de solution est écarté, car la re‑planification complète est nécessaire afin d’assurer l’équité du traitement des votes.

Modification des données

Ce besoin ne nécessite pas d’adaptation de la base de données.

Il n’y a pas non plus d’impact juridique.

Modification de la vue

Il faut modifier l’écran teacher‑interview (phase d’entretien du gestionnaire) en remplaçant le bouton “Re‑planifier les entretiens” par “Retour à la phase de sélection”.

Modification du contrôleur

Il faut ajouter une structure alternative au contrôleur action-plan :

  • si l’état est la phase de sélection (table Participation vide), alors planifier les entretiens (code actuel) ;
  • sinon, effacer les données de la table Participation.

Adaptation de la documentation

  • Utilisateur : expliquer la fonctionnalité.
  • Développeur : adapter les cas d’utilisation.

Tests

  • Écrire un test d’intégration pour le contrôleur action-plan : requêtes HTTP (avec Curl par exemple) et vérification de l’état de la base de données.
  • Ajout d’un test utilisateur (dans Selenium IDE) pour vérifier le fonctionnement des boutons de changement de phase.

Démarche

  1. Rejouer les tests pour s’assurer du bon fonctionnement de l’application.
  2. Créer une nouvelle branche “featurebackto_selection”.
  3. Modifier le fichier inc/teacher-event.php pour afficher le label approprié en fonction de la phase.
  4. Modifier le fichier action-plan.php.
  5. Relancer les tests pour vérifier l’absence de régression.
  6. Ajouter un nouveau test pour la fonctionnalité.
  7. Adapter la documentation (fichiers Dev.md et README.md) et ajouter une entrée dans ChangeLog.md.
  8. Fusionner la branche et ajouter une étiquette. Dans le cas d’un travail en équipe, il aurait fallu rebaser la branche et faire une requête de fusion.

Proposition de solution - Deuxième besoin

Aspects juridiques

Pour le deuxième besoin, il est convenu que pouvoir voir la photo des étudiant·e·s lors de la phase de sélection et de vote améliorerait l’expérience utilisateur et serait conforme à la finalité du traitement.

Il faut considérer consciencieusement les aspects légaux de l’utilisation de la photo d’identité, donnée à caractère personnel (et qui plus est biométrique).

  • Le consentement des utilisateurs est requis ; il doit être libre (possibilité de refuser), spécifique (par rapport à l’utilisation qui va être faîte de la photo d’identité — limitée à l’événement stage-dating), éclairé et non ambigu.
  • À partir de 16 ans (cf article 8 du RGPD) un·e élève ou étudiant·e peut valablement consentir seul au traitement de ses données personnelles.
  • La politique de confidentialité (cf mentions légales) devra être mise à jour.
  • Des mesures techniques et organisationnelles appropriées doivent être mises en place pour garantir la sécurité des photos d’identité : chiffrement, contrôles d’accès et surveillance.

Concernant le principe de minimisation, l’utilisation de la photo d’identité pourrait poser question, car elle n’est pas indispensable à la finilité du traitement.

Concrètement, ce seront les étudiant·e·s qui pourront librement choisir d’ajouter ou non leur photo d’identité. Leur interface leur exposera les aspects juridiques, et ils auront la possibilité de la supprimer.

Ensuite, les photos devraient être chiffrées dans la base de données ou sur le disque dur (algorithme AES).

Seuls l’étudiant·e, les tuteur·rice·s et la personne gestionnaire doivent y avoir accès. Un journal des accès sera conservé.

Impact de la fonctionnalité

Un problème de taille se pose : les utilisateur·rice·s de l’application ne sont pas authentifiés, mais seulement identifiés. Toute personne connaissant le nom d’un·e tuteur·rice a potentiellement accès aux photos d’identités !

La mise en place d’un système d’authentification serait donc obligatoire.

Solutions techniques

Les photos peuvent être enregistrée en base de données ou dans des fichiers. Dans ce dernier cas, il faut un mécanisme permettant d’associer la photo à l’enregistrement en base de données, par exemple ‘nom_prenom.jpg’ (s’il n’y a pas d’homonymes).

C’est la solution base de donnée qui est retenue. Il faut pour cela ajouter un champ de type BLOB (données binaires) à la table Student ; un script de migration (ALTER TABLE) serait alors mis en place.

Les photos pourraient être téléversées par la personne gestionnaire de l’évènement, ou prise en direct par les étudiant·e·s au moyen de la caméra intégrée à leur ordiphone. C’est cette dernière approche qui est retenue.

Il est important de contrôler la taille des photos afin qu’elle ne dépasse pas 10 kio. Cette opération sera réalisée côté client (en Javascript).

Modification de la vue

Il faut modifier l’écran teacher‑vote (phase de sélection du gestionnaire) pour qu’il puisse vérifier les photos des étudiant·e·s.

Il faut modifier l’écran student‑vote, pour que les étudiant·e·s puissent prendre, visualiser ou supprimer leur photo d’identité (et fournir les explications permettant un consentement éclairé).

Il faut modifier les écrans tutor-interview et tutor-interview pour que les tuteur·rice·s puissent visualiser les photos des candidat·e·s (étudiant·e·s).

Modification du contrôleur

Il faut ajouter un contrôleur action-face_id permettant l’ajout et la suppression des photos d’identités.

Adaptation de la documentation

  • Mention légales à adapter.
  • Utilisateur : expliquer la fonctionnalité.
  • Administrateur : il faut mettre à jour le schéma de la base de données et les instructions SQL.
  • Développeur : adapter les cas d’utilisation :
    • En tant qu’étudiant·e, je peux ajouter ou supprimer ma photo “d’identité”.

Tests

  • Écrire un test d’intégration pour le contrôleur action-face_id : requêtes HTTP (avec Curl par exemple) et vérification de l’état de la base de données.
  • Ajout d’un test utilisateur (dans Selenium IDE) pour vérifier le fonctionnement des boutons de changement de phase.

Démarche

Ces étapes sont exposées lors du premier entretien, mais réalisées lors de la deuxième phase.

  1. Rejouer les tests pour s’assurer du bon fonctionnement de l’application.
  2. Créer une nouvelle branche “featurefaceid”.
  3. Adaptation de la base de données (script sql/000_ini.sql pour l’existant et sql/001/face_id.sql pour l’ALTER TABLE).
  4. Programmation :
    • Modifier le fichier inc/student-vote.php pour une zone d’affichage de la photo (ainsi que les mentions explicatives).
    • Ajouter un fichier face-id.js avec le code Javascript pour gérer la prise de photo (via la Webcam).
    • Créer le fichier action-face_id.php pour afficher le label approprié en fonction de la phase.
    • Adapter les mentions légales dans legal.php.
  5. Relancer les tests pour vérifier l’absence de régression.
  6. Ajouter un nouveau test pour la fonctionnalité.
  7. Adapter la documentation (fichiers Dev.md, Install.md\README.md) et ajouter une entrée dansChangeLog.md`.
  8. Fusionner la branche et ajouter une étiquette. Dans le cas d’un travail en équipe, il aurait fallu rebaser la branche et faire une requête de fusion.