7. Chapitre 6 - Conclusion et étapes suivantes

7.1. Ce qui a été construit

Ce document a porté vers des technologies actuelles le cœur fonctionnel et l’authentification de l’application [RdvMedecins] du document original de 2014 :

• un serveur [NestJS] complet (livré avec ce document, installé et testé au chapitre 2 mais dont le code n’est pas étudié ici), exposant les 11 mêmes routes métier JSON que le serveur Spring 4 original, sur le même port (8080), toutes désormais protégées par un jeton JWT ;
• une couche d’authentification ([@nestjs/passport] + [@nestjs/jwt]) : connexion par login/mot de passe (POST /login), jeton signé présenté à chaque requête suivante, et contrôle d’accès par rôle ([@Roles]('ADMIN') + [RolesGuard]) sur les deux routes qui modifient des données ;
• un client [Flutter] (widgets [Material], package [provider]) offrant les mêmes fonctionnalités que le client AngularJS 1.x original - choix d'un médecin et d'un jour, consultation de l'agenda, réservation et annulation d'un rendez-vous - complété d'un écran de connexion, d'une session persistée ([shared_preferences]), d'une interface adaptée au rôle de l'utilisateur connecté (boutons de réservation masqués pour un rôle USER), et du passage français/anglais de l'interface ([TranslationsService], réimplémenté sans bibliothèque tierce).

La base de données n’a pas changé dans son cœur (mêmes tables [medecins/clients/creneaux/rv], mêmes contraintes), à l’ajout près de la table [users] ; l’architecture générale en couches non plus - seuls les outils qui la mettent en œuvre ont été renouvelés.

Deux différences assumées avec l’authentification du document original, mises en œuvre par le serveur livré (cf. chapitre 2) : un jeton JWT plutôt que l’entête HTTP Basic envoyé à chaque requête, et une seule colonne [role] par utilisateur plutôt qu’une relation plusieurs-à-plusieurs sur trois tables. Une troisième différence, fonctionnelle celle-ci, a été choisie délibérément pour ce portage : le rôle USER peut désormais consulter les agendas (en lecture seule), alors qu’il ne servait dans l’original qu’à illustrer un refus d’accès total.

7.2. Ce qui reste hors périmètre ou à porter

Le document original couvrait, au-delà de ce qui précède, deux sujets supplémentaires - l’un désormais traité, l’autre délibérément laissé de côté, le troisième reporté à une étape ultérieure :

7.2.1. L’internationalisation français/anglais - traitée dans ce document

Le document original proposait de basculer l'interface entre le français et l'anglais, à l'aide de la bibliothèque [angular-translate]. Ce portage reprend cette fonctionnalité avec [TranslationsService] (cf. chapitre 4), écrit pour ce document plutôt que délégué à un plugin tiers : les dictionnaires fr.json/en.json, embarqués dans l'application (et non plus servis par un serveur web), sont chargés via [rootBundle.loadString(...)]. Comme [angular-translate] et [vue-i18n] avant lui, [TranslationsService] permet de changer de langue à la volée, sans recharger l'application - un comportement fidèle à celui du document original.

7.2.2. Le mode « debug » du client - délibérément hors périmètre

Le document original incluait un mode d'affichage technique, activable depuis l'interface, qui donnait accès au modèle brut (le $scope AngularJS 1.x) de la vue courante - un dispositif utile en 2014, quand les outils de développement disponibles pour inspecter une application AngularJS restaient limités. Ce portage ne le reconstruit pas : les outils de développement [Flutter] actuels ([Flutter] DevTools, utilisables sur les 3 cibles - mobile, bureau, web) offrent aujourd'hui, en dehors de l'application elle-même, une inspection bien plus complète de l'arbre de widgets, de leur état et de leurs propriétés, que ne le ferait un panneau de débogage maison réintégré dans l'interface. Ajouter un tel panneau reviendrait à dupliquer, moins bien, un outil déjà fourni par l'écosystème - ce choix est donc définitif, et non une simple remise à plus tard.

7.2.3. Un délai réseau artificiel - reporté

Le document original permettait de régler un délai artificiel avant chaque réponse du serveur, pour observer le comportement de l’interface sur un réseau lent (indicateurs de chargement, désactivation temporaire des boutons…). Cette fonctionnalité n’a pas encore d’équivalent dans ce portage.

7.3. Un mot sur la méthode suivie dans ce document

Ce document a été écrit en s'appuyant systématiquement sur le code réellement exécuté : chaque route du serveur a été testée (y compris les scénarios d'authentification : connexion réussie/échouée, accès sans jeton, accès avec le mauvais rôle) ; le client [Flutter] (chapitre 4), lui, a été relu et vérifié ligne à ligne plutôt que capturé à l'écran - l'environnement qui a produit ce document n'a pas accès à un poste capable d'exécuter et de photographier [Flutter] (mobile, bureau ou web), contrairement aux clients web précédents de ce cours, pilotables directement dans un navigateur [Chromium] automatisé.

7.4. Pour aller plus loin dès maintenant

En attendant les étapes suivantes de ce portage, le serveur et le client livrés avec ce document constituent une base directement utilisable pour expérimenter par soi-même :

• ajouter un nouveau médecin ou un nouveau patient (actuellement, cela se fait uniquement en modifiant le script SQL - une route /ajouterMedecin, protégée elle aussi par [@Roles]('ADMIN'), pourrait être un premier exercice) ;
• ajouter un troisième rôle, ou un utilisateur cumulant plusieurs rôles - l’occasion de mesurer ce que coûterait, très concrètement, l’abandon de la simplification à une seule colonne [role] (cf. chapitre 2) ;
• modifier la présentation du client (couleurs, mise en page) sans toucher au serveur - une bonne façon de vérifier que le découpage en couches du client fonctionne comme annoncé ;
• relire le README de chaque dossier du serveur et du client livrés : chacun explique, dans son contexte, le rôle des fichiers qu’il contient.