Une heat map pour réagencer les salles du campus
La cellule de planification du campus s'appuyait sur un calendrier de réservation qui indiquait les salles réservées ainsi que celles qui l'étaient deux fois sur un même créneau. Cet outil ne permettait cependant pas de savoir si la capacité d'une salle était optimisée, ni d'obtenir une vue d'ensemble du bâtiment à un instant donné.
La demande formulée par le service de planification était la suivante : disposer d'un outil de diagnostic qui fonctionne comme une sorte de heat map du bâtiment afin d'identifier les ailes les plus chargées et celles qui l'étaient le moins, et ainsi pouvoir réagencer l'organisation des salles à partir d'une vue globale de l'occupation. L'outil devait afficher l'état de chaque salle à partir d'un export Excel issu du système de gestion de l'école et donner accès aux informations détaillées de chaque réservation. La solution devait être développée sous Unity et livrée sous la forme d'un exécutable peu gourmand, capable de fonctionner sur la plupart des postes du service.
Notre équipe découvrait Unity et le langage C# avec ce projet, ce qui nous a conduits à organiser dès les premières semaines une montée en compétences commune.
D'un export ERP à une salle colorée
Le fonctionnement de SmartView suit le trajet de la donnée. L'export Excel est d'abord converti en CSV, chaque ligne décrivant une réservation avec sa salle, son créneau, sa promotion, son intervenant et le nombre d'étudiants prévus. Dans la maquette, chaque salle est un objet qui porte exactement le nom utilisé dans ce fichier, de sorte que la correspondance entre le bâtiment et les données se fait sans table intermédiaire à maintenir.
Nous calculons ensuite, pour chaque salle et chaque demi-journée, un ratio d'occupation qui rapporte le nombre d'étudiants prévus à la capacité de la salle. Les salles de la maquette sont générées de manière procédurale, indépendamment des données, et leur habillage intervient dans un second temps : chaque objet salle reçoit le ratio de la demi-journée choisie et prend la couleur correspondante, selon des seuils affichés dans la légende, du vert pour une occupation correcte jusqu'au marron pour une salle surchargée, les salles non réservables étant assombries pour rester identifiables. Un curseur permet de parcourir le calendrier demi-journée par demi-journée, et les salles changent de couleur au fil du déplacement, ce qui fait apparaître d'un coup d'œil les zones du bâtiment sous tension.
Au survol d'une salle, une infobulle présente sa photographie, son nom, son occupation et les informations de réservation complètes, notamment le contact de l'assistante pédagogique et celui de l'intervenant, tirés du fichier Excel. Ce choix répond à l'usage visé : la lecture d'une salle occupée de manière non optimale doit pouvoir déboucher directement sur une action auprès des personnes concernées.
Une construction incrémentale et une frise ajoutée en cours de route
Nous avons construit l'outil de manière incrémentale, en partant d'une fonctionnalité minimale que nous étendions ensuite pas à pas. Le premier objectif consistait à savoir modéliser des formes dans Unity, puis à leur faire changer de couleur selon des données figées, avant de lire ces données depuis un fichier CSV et enfin depuis l'export Excel lui-même. Chaque étape reposait ainsi sur une base déjà fonctionnelle, ce qui a permis à toute l'équipe de monter en compétences sur un socle commun.
La maquette a été réalisée à partir d'une étude de l'architecture et des plans du bâtiment. Comme des travaux avaient modifié certains espaces depuis l'établissement de ces plans, nous avons visité les salles et repris cette étude sur place afin que la maquette corresponde au bâtiment tel qu'il est utilisé aujourd'hui.
Nous avons par ailleurs fait le choix de rendre réglables depuis l'interface les index des colonnes lues dans le fichier. L'export évolue en effet côté métier, et ce réglage permet au service d'absorber un changement de format sans attendre une nouvelle version du logiciel, ce qui était indispensable pour un outil destiné à être utilisé en autonomie. Dans la même logique de pérennité, nous avons étudié la possibilité d'importer une nouvelle maquette depuis l'outil afin de le rendre entièrement réutilisable si le bâtiment venait à évoluer. Cette fonctionnalité n'était pas prioritaire et n'a pas pu être réalisée dans les délais, mais son étude a orienté la structure du projet.
Vers les deux tiers du projet, nous avons ajouté une frise chronologique qui représente par des couleurs l'occupation globale du bâtiment au fil du temps. Jusque-là, l'outil répondait à la question de l'état de chaque salle à un instant choisi, alors que la planification avait aussi besoin de repérer les moments de la journée où le bâtiment entier saturait ou restait sous-exploité. Ce changement structurant a fait passer SmartView d'une lecture salle par salle à une lecture du bâtiment dans le temps, plus proche de la heat map attendue par le service.
Sur le plan de l'organisation, nous avons d'abord mis en place la méthode Scrum avant d'évoluer vers une méthode hybride, plus adaptée à une équipe de quatre personnes sur trois mois. Nous avons conservé des cycles hebdomadaires et des points réguliers, et j'ai veillé à attribuer à chacun une tâche liée à sa spécialité ainsi qu'une tâche transversale afin que toute l'équipe progresse sur Unity et C#.
De la maquette 3D complète à la vue éclatée par étage
La première version de la maquette était en trois dimensions complètes et reprenait un modèle existant du bâtiment. Elle s'est révélée peu lisible à l'usage, car les murs porteurs masquaient une partie des salles et obligeaient l'utilisateur à déplacer la caméra pour lire une couleur. Nous avons donc changé de stratégie pour une vue éclatée, étage par étage et vue du dessus, qui offre une lecture immédiate de l'ensemble du bâtiment.
Ce changement a également débloqué l'infobulle. J'avais d'abord tenté de la faire flotter au-dessus des salles dans la maquette en volume, ce qui posait des problèmes d'angle de caméra et de lisibilité. Dans la vue éclatée, j'ai pu mettre en place un panneau qui s'affiche au survol, accompagné d'un contour de surbrillance sur la salle pointée.
Livré et mis en condition réelle par la cellule de planification
La version 1.0 a été livrée puis présentée à notre maître de stage, à l'équipe pédagogique, à la direction du campus et à la cellule de planification, qui l'a mise en condition réelle. L'outil a été bien accueilli, et la vue éclatée par étage a notamment été qualifiée de lisible par ses utilisateurs.
Notre feuille de route prévoyait également un module capable de proposer une meilleure répartition des salles au moyen d'un algorithme glouton. Ce module a été développé en Python par un membre de l'équipe, mais son intégration dans Unity n'a pas pu être finalisée dans les délais impartis, la priorité ayant été donnée au livrable final attendu par le service.