Room Calendars

Introduction

Room Calendars est né après l'arrêt d'un outil SaaS utilisé pour la gestion des salles de réunion. Une partie du suivi avait alors été reprise directement dans Outlook.

Les informations étaient bien disponibles, mais leur consultation devenait vite fastidieuse dès qu'il fallait comparer plusieurs salles sur plusieurs jours. Même pour une vérification simple, il fallait naviguer entre différents calendriers et répéter les mêmes manipulations.

L'accueil avait aussi besoin de retrouver rapidement une salle lorsqu'un visiteur connaissait le nom d'un participant, mais pas l'endroit où se tenait sa réunion.

Le projet devait donc répondre à deux besoins principaux : faciliter la consultation des disponibilités et permettre de retrouver une réunion à partir des informations disponibles.

Concevoir avec les utilisateurs

J'ai travaillé par petites itérations avec le chef de projet et les futurs utilisateurs. Le calendrier a connu plusieurs versions avant d'arriver à une organisation satisfaisante.

La difficulté principale n'était pas d'afficher les réunions, mais de rendre l'ensemble lisible en quelques secondes. Plusieurs salles, plusieurs jours et différentes informations de réunion devaient tenir dans une même interface sans donner une impression de surcharge.

Les principaux écrans ont d'abord été préparés sur Figma. Les maquettes permettaient de tester rapidement l'organisation des informations avant le développement et de rendre les échanges plus concrets.

Les retours utilisateurs ont ensuite guidé plusieurs ajustements sur l'espacement, les regroupements et la hiérarchie visuelle. Sur un outil utilisé régulièrement, quelques secondes perdues ou une information difficile à repérer finissent vite par peser dans l'usage quotidien.

Organiser le développement

Le projet était découpé en tâches suivies avec GitHub Issues. Les sujets les plus importants étaient ensuite séparés en sous-tâches plus faciles à traiter, chacune développée sur sa propre branche avant intégration via Pull Request.

Cette organisation me permettait de garder une vision claire de l'avancement tout en travaillant séparément sur les différents sujets : intégration de Microsoft Graph, recherche, cache, droits utilisateurs ou interactions front-end.

J'ai aussi choisi de traiter tôt la partie que je considérais comme la plus risquée : la récupération et l'organisation des données provenant de Microsoft Graph.

Si cette partie ne permettait pas d'obtenir des données fiables ou des temps de réponse satisfaisants, une grande partie de la solution aurait dû être revue. La valider en premier évitait donc de construire le reste du projet sur une base incertaine.

Prévoir les défaillances

Le cronjob améliore les performances, mais je ne voulais pas que toute l'application repose sur son bon fonctionnement.

Les données disposent donc également d'une durée de validité. Si le cronjob ne s'exécute plus et que le cache arrive à expiration, l'application peut déclencher elle-même une nouvelle synchronisation.

Dans cette situation, le premier utilisateur peut attendre jusqu'à une quarantaine de secondes le temps que les données soient récupérées. Les consultations suivantes retrouvent ensuite un fonctionnement normal jusqu'à la prochaine expiration.

Ce mécanisme permet à l'application de continuer à fonctionner sans intervention manuelle en cas de problème ponctuel sur la tâche planifiée.

Sécurité et droits d'accès

L'authentification repose sur le SSO Microsoft. Les utilisateurs se connectent donc avec leur compte professionnel existant, sans ajouter un second système de mots de passe à maintenir.

Les droits varient selon les besoins. La consultation des disponibilités reste accessible aux utilisateurs concernés, tandis que certaines fonctionnalités, comme la recherche avancée dans les réunions, sont réservées aux profils autorisés.

Les échanges avec Microsoft Graph et le navigateur sont chiffrés. Les tâches automatisées sont également protégées afin d'éviter qu'elles puissent être déclenchées librement.

Les calendriers peuvent contenir des informations sur les participants, les horaires ou l'organisation de certaines réunions. La gestion des accès faisait donc partie du projet dès le départ.

Suivre l'environnement existant

Les salles étaient déjà administrées dans l'environnement Microsoft. J'ai donc préféré utiliser cette source existante plutôt que maintenir une seconde liste directement dans Room Calendars.

Lorsqu'une salle était ajoutée, modifiée ou supprimée côté Microsoft, l'application pouvait récupérer ces changements sans demander une seconde intervention.

Cette organisation réduisait la maintenance et évitait surtout que deux systèmes finissent par contenir des informations différentes.

Ce que je ferais différemment aujourd'hui

Le projet a été développé assez rapidement. Les premières priorités étaient de valider l'intégration avec Microsoft Graph, construire les fonctionnalités principales et faire évoluer l'interface à partir des retours utilisateurs.

Les tests fonctionnels et unitaires n'ont donc pas été intégrés dès les premières versions, et le projet n'a pas disposé d'une véritable base de tests automatisés.

Avec le recul, je mettrais aujourd'hui cette base en place beaucoup plus tôt. Les traitements métier et l'intégration avec Microsoft Graph seraient notamment couverts par des tests automatisés, exécutés par une CI à chaque Pull Request.

J'ajouterais aussi davantage de suivi technique sur les temps de réponse de Microsoft Graph, les synchronisations et les performances de la base de données. Cela permettrait de repérer plus rapidement une dégradation avant qu'elle ait un impact visible sur les utilisateurs.