netYurt

Depuis des décennies, l’organisation gérait un réseau de résidences en pleine croissance avec des programmes distincts, des fichiers Excel et des échanges d’e-mails. Les dossiers des étudiants étaient tenus à un endroit, le suivi des échéances de paiement et des dons à un autre, les opérations de personnel et de congés à un troisième. À mesure que le nombre d’antennes augmentait, le siège recevait à la même question trois réponses différentes de trois sources différentes : « Combien d’étudiants avons-nous sur la période en cours, combien ont des sommes à régler, et dans quelle résidence manque-t-il du personnel ? »

Le premier objectif était de réunir ces données dans une source unique. Nous avons placé la personne au centre : étudiants, personnel, alumni, boursiers, donateurs et locataires ne sont plus des listes séparées, mais les différents rôles d’une même fiche personne. Nous avons traité les entités de la même manière : résidences, antennes, centres éducatifs et fournisseurs ont été définis de façon hiérarchique au sein d’une structure d’entités unique. Une fois ces deux piliers en place, les modules de comptabilité, de bourses, de ressources humaines, de gestion des processus et de communication sont venus s’y ajouter, l’un après l’autre.

Le projet a grandi avec l’organisation au fil des années. Chaque phase a apporté de nouveaux besoins : planification des effectifs normatifs, formulaires d’évaluation, suivi des parts de sacrifice (kurban), accès à Internet dans les résidences, bibliothèque, portail alumni. Plus récemment, tous les écrans de listes et de rapports ont été migrés vers le nouveau socle de tableaux, et deux thèmes au choix ainsi qu’une nouvelle expérience de connexion ont été mis en service. Aujourd’hui, le système fait partie intégrante du fonctionnement quotidien de l’organisation.

• Données dispersées et en double. La même personne figurait dans différentes listes avec des orthographes différentes. Il était impossible de fusionner les listes sans d’abord éliminer les doublons.
• Organisation à plusieurs niveaux. Aux niveaux du siège, de la région, de l’antenne, de la résidence et de l’unité, il fallait des droits et des périmètres de visibilité différents. Un directeur d’antenne devait voir uniquement sa propre antenne, un coordinateur régional plusieurs antennes, et le siège tout.
• Des attentes de reporting différentes pour chaque module. La comptabilité veut une balance, les ressources humaines un pointage, la direction un graphique de tendance. Développer un écran distinct pour chaque rapport n’était pas tenable.
• Obligation d’une transition sans interruption. L’infrastructure a été renouvelée alors que le système était en production. Comme des centaines d’utilisateurs ne pouvaient pas interrompre leur travail, le nouveau socle de tableaux et le nouveau thème d’interface devaient fonctionner en même temps que l’ancienne structure, sur le même code.
• Ordinateurs partagés et sécurité. Dans les résidences, la connexion au système se faisait depuis des ordinateurs partagés. Il fallait assurer en même temps la sécurité des mots de passe et la facilité d’utilisation.

• Un socle unique de personnes et d’entités. Chaque individu a une seule fiche personne ; des rôles tels qu’étudiant, personnel ou boursier se rattachent à cette fiche. Les entités sont tenues sous forme d’arborescence hiérarchique. Les outils de détection des doublons et de fusion des fiches font partie du système.
• Habilitations par rôle et par périmètre. Les droits sont définis page par page à l’aide de rôles, tandis que le champ de visibilité l’est par des définitions de périmètre. Un même rapport n’affiche que les antennes concernées, selon le périmètre de l’utilisateur.
• Un composant de tableau commun et le Studio de rapports. Toutes les listes reposent sur le même composant de tableau : filtres de colonnes, regroupement, calculs de colonnes, export Excel, vue enregistrée. Les utilisateurs habilités transfèrent n’importe quel tableau dans le Studio de rapports et le transforment par glisser-déposer en graphiques, tableaux croisés et tableaux de bord ; ils enregistrent, versionnent et partagent le rapport.
• Deux thèmes, un seul code. L’interface existante a été conservée et un nouveau thème d’interface, avec mode sombre et compatible avec les téléphones, a été ajouté. L’utilisateur choisit le thème qu’il souhaite ; les deux thèmes partagent la même base de code. La transition a ainsi pu se faire sans interruption et par étapes.
• Sécurité de connexion à plusieurs niveaux. Le nouvel écran de connexion est arrivé avec une vérification humaine, un clavier virtuel, un thème clair/sombre et quatre méthodes de vérification en deux étapes (SMS, e-mail, Authenticator, Passkey). Grâce à Passkey, on peut se connecter sans mot de passe avec le verrouillage d’écran de l’appareil (code PIN, etc.).
• Une structure modulaire qui grandit avec l’organisation. Chaque module arrive avec ses propres menus, droits et rapports ; quand un nouveau besoin apparaît, un nouveau module est ajouté sans bousculer la structure existante.