netYurt : nouveau socle de tableaux et Studio de rapports sans arrêter le système

Un lundi matin, le directeur d'une résidence étudiante se connecte au système. Les écrans qu'il connaît sont toujours à leur place ; mais il a désormais un choix : s'il le souhaite, il peut passer à la nouvelle interface, dotée d'un mode sombre et adaptée au téléphone. La même semaine, un coordinateur du bureau régional transforme par glisser-déposer, en tableau de bord, la liste d'occupation des résidences qu'il consulte chaque jour, et la partage avec son équipe.

Ces deux situations sont le résultat du renouvellement d'un système utilisé chaque jour depuis des années, réalisé sans que les utilisateurs aient à interrompre leur travail. Cet article raconte la récente refonte de l'infrastructure de netYurt.

Le projet en bref

netYurt est un système de gestion d'entreprise que nous avons développé pour un organisme éducatif de longue tradition, qui exploite des centaines de résidences étudiantes, d'antennes et de centres éducatifs. Les fiches des personnes et des entités, la comptabilité, les bourses et les dons, les ressources humaines, la gestion des processus et la communication de masse sont gérés dans plus de 15 modules principaux, au sein d'un seul système web adapté au téléphone. Le projet a grandi avec l'organisme au fil des ans ; de la planification des effectifs normatifs à la bibliothèque, du portail alumni à l'accès Internet des résidences, de nouveaux besoins se sont ajoutés à chaque période. Les actualités, les pages, les appels d'offres et les contenus de présentation des résidences, ainsi que le portail alumni, sont eux aussi gérés depuis le même panneau.

Quand chaque module réclame son propre rapport

La comptabilité veut une balance générale, les ressources humaines un état de pointage, la direction un graphique de tendance. Développer un écran distinct pour chaque rapport devenait intenable à mesure que le nombre de modules augmentait. De plus, lorsque les filtres, l'export et l'affichage de chaque liste fonctionnaient différemment, l'utilisateur devait apprendre chaque écran séparément.

La première étape de la solution a été un composant de tableau commun. Nous avons migré tous les écrans de listes et de rapports vers ce nouveau socle : filtres par colonne, regroupement, calculs sur colonnes, pagination, export Excel et CSV en un clic et vues enregistrées fonctionnent de la même façon dans chaque liste. Lorsque l'utilisateur a appris un écran, il a appris tout le système.

De petits choix d'interface servent le même but. Lorsqu'un en-tête de colonne est glissé dans la zone située au-dessus du tableau, la liste est regroupée selon cette colonne ; le choix des colonnes, les filtres et les calculs sur colonnes s'ouvrent depuis un panneau latéral. L'utilisateur commence sa journée sur la console, qui rassemble les raccourcis vers ses écrans habituels, les groupes de travail associés et le tableau de tâches Kanban.

Chaque tableau devient un tableau de bord

Le véritable gain du socle commun est apparu à la deuxième étape. Un utilisateur habilité envoie n'importe quel tableau, avec son filtre du moment, dans le Studio de rapports ; en faisant glisser et déposer les colonnes, il crée des graphiques en colonnes, en barres, en courbes, en aires ou en secteurs, des tableaux croisés dynamiques, des indicateurs KPI et des jauges. Le rapport, conçu pour l'écran ou en mise en page A4 horizontale, est enregistré, versionné, et partagé par rôle, par personne ou par entité. Il est aussi possible de construire un rapport à partir de sources de données prêtes à l'emploi, non liées à un tableau. Le droit d'envoyer un tableau dans le Studio est réservé aux utilisateurs habilités ; comme dans le reste du système, c'est le rôle qui détermine l'accès à la page, et le périmètre de l'utilisateur qui détermine ce qu'il voit.

Il n'est ainsi plus nécessaire de développer un écran distinct pour chaque nouveau besoin de rapport. L'unité qui réclame la balance, l'état de pointage ou le graphique de tendance répond à son besoin sur le même socle, avec le tableau de bord qu'elle construit elle-même. Le tableau de bord de direction de la gestion des processus affiche lui aussi d'un seul coup d'œil le nombre de demandes, la tendance mensuelle, la répartition par statut et les unités les plus actives.

Deux thèmes, un seul code : laisser l'utilisateur choisir le moment du passage

La vraie contrainte tenait au calendrier. L'infrastructure était renouvelée pendant que le système tournait en production, et des centaines d'utilisateurs ne pouvaient pas interrompre leur travail. Le nouveau socle de tableaux et le nouveau thème d'interface devaient donc fonctionner en même temps que l'ancienne structure, sur le même code. Ce renouvellement était le dernier maillon de notre approche, qui consiste à construire le système en quatre couches depuis le début : d'abord la colonne vertébrale des données et le modèle d'habilitations, puis les modules opérationnels, ensuite la couche de rapports et, en dernier, la nouvelle interface.

Nous avons conservé l'interface existante et ajouté à côté un nouveau thème, doté d'un mode sombre et adapté au téléphone. L'utilisateur choisit le thème qu'il souhaite ; les deux thèmes utilisent la même base de code. Aucun module n'a été réécrit : seule la couche de thème a changé. Sur téléphone, le menu se réduit, les panneaux s'empilent, les tableaux défilent horizontalement ; les rapports peuvent aussi être ouverts sur le terrain, et aucune installation en dehors du navigateur n'est nécessaire. La transition s'est ainsi déroulée sans interruption et par étapes ; les utilisateurs ont pu passer à la nouvelle interface à leur propre rythme.

La nouvelle expérience de connexion est arrivée à la même période. En pensant aux ordinateurs partagés dans les résidences, nous avons ajouté une vérification humaine et un clavier virtuel contre les enregistreurs de frappe. Quatre méthodes sont proposées pour la vérification en deux étapes : SMS, e-mail, Authenticator et Passkey ; avec Passkey, la connexion se fait sans mot de passe, grâce au verrouillage d'écran de l'appareil (code PIN, etc.). Chaque méthode peut être activée ou désactivée séparément, et plusieurs peuvent rester actives en même temps ; l'utilisateur qui perd son téléphone peut se connecter avec une autre méthode. Pour les opérations réservées aux utilisateurs habilités, un verrouillage des enregistrements et une trace des modifications sont également conservés.

Ce que nous avons appris sur le terrain

• N'écrivez pas le rapport, écrivez le socle du rapport. Le tableau commun et le Studio de rapports ont brisé le cycle qui consistait à développer un écran pour chaque nouveau besoin.
• Sur un système en production, pas de révolution : un changement de couche. Changer la couche de thème plutôt que réécrire les modules a limité le risque du renouvellement.
• Laissez l'utilisateur piloter la transition. Avec l'ancienne et la nouvelle interface côte à côte, personne n'a été forcé de découvrir un matin un écran inconnu.
• Concevez la sécurité en fonction de l'environnement. Dans des résidences où des ordinateurs sont partagés, le clavier virtuel et la connexion sans mot de passe ne sont pas un confort, mais une nécessité.

Quand on renouvelle un système utilisé depuis des années, la plus grande réussite est que l'utilisateur puisse passer à un meilleur outil sans interrompre son travail.

Pouvez-vous renouveler votre système sans l'arrêter ?

Si vous agrandissez depuis des années un système en ajoutant de nouveaux écrans à chaque demande de rapport, ou si vous repoussez le besoin de renouvellement par crainte que « tout le monde doive arrêter de travailler », nous pouvons planifier avec vous une transformation progressive. Vous pouvez consulter la page du projet netYurt ou nous contacter.