Application bancaire React/Redux avec authentification JWT et modélisation Swagger de la phase suivante

Contexte : construire une interface sur des fondations déjà posées

Projet réalisé en formation (parcours JavaScript/React, OpenClassrooms). Mission fictive pour Argent Bank, une nouvelle banque en lancement : développer l'application web qui permet à ses clients de se connecter et de gérer leur profil. Contrairement à d'autres projets où tout est à construire depuis zéro, deux éléments étaient déjà fournis en amont : le design final des trois pages principales (accueil, connexion, profil) sous forme de code HTML et CSS statique, et une API déjà développée côté serveur par une autre équipe, avec sa documentation technique (au format Swagger, un standard qui décrit précisément ce que chaque « endpoint » — chaque point d'entrée — d'une API accepte et renvoie).

Le travail demandé se décomposait en deux volets bien distincts. D'une part, transformer ce HTML statique en une véritable application React fonctionnelle, connectée à l'API existante pour l'authentification et la gestion du profil. D'autre part, un travail entièrement différent : concevoir sur le papier (sans coder) les futurs points d'entrée d'API nécessaires à une fonctionnalité de gestion des transactions bancaires, prévue pour une phase ultérieure du projet — un exercice de conception plutôt que de développement.

Partir d'un habillage déjà fait plutôt que d'une maquette à recréer

D'ordinaire, un projet front-end part d'une maquette graphique (une image, un fichier Figma) qu'il faut transformer en code. Ici, la situation était différente et plus proche d'un contexte professionnel réel : le HTML et le CSS des pages existaient déjà, prêts à l'emploi. Le travail a donc consisté à découper ce code figé en éléments réutilisables et dynamiques propres à React (des « composants » : l'en-tête du site, le pied de page, chaque page) plutôt qu'à créer visuellement quoi que ce soit — un exercice qui ressemble davantage à de la reprise de code existant qu'à de l'intégration classique. Les liens classiques du HTML ont par exemple été remplacés par l'équivalent React Router, pour permettre la navigation entre les pages sans recharger entièrement le site à chaque clic. Seul un petit bloc, absent du HTML fourni (l'édition du profil), a nécessité l'ajout de quelques règles de style supplémentaires, ajoutées à la toute fin du fichier CSS existant plutôt que de tout réorganiser.

Un endroit unique pour stocker les données de l'application

Redux est une bibliothèque qui centralise toutes les données importantes d'une application dans un seul endroit (le « store »), plutôt que de les éparpiller dans chaque composant. L'intérêt : n'importe quel composant de l'application peut aller lire ou modifier ces données de façon prévisible, sans avoir à se les transmettre laborieusement de composant en composant. Ce store a été positionné au tout début de l'application (dans le fichier racine index.js), rendant les données disponibles partout ailleurs dans le site.

Un complément a été nécessaire : par défaut, Redux ne sait gérer que des changements instantanés (« l'utilisateur a cliqué, on met à jour tout de suite »), pas des opérations qui prennent du temps comme une requête envoyée à un serveur distant. Un outil complémentaire (redux-thunk) a donc été ajouté spécifiquement pour permettre à Redux d'attendre la réponse d'un appel réseau avant de mettre à jour les données, sans bloquer le reste de l'application pendant ce temps d'attente.

Comment fonctionne la connexion, étape par étape

Quand la personne tape son identifiant et son mot de passe, chaque caractère saisi met à jour l'état du formulaire en temps réel. Au clic sur le bouton de connexion, l'application envoie ces identifiants au serveur et attend sa réponse. Deux issues possibles : si les identifiants sont incorrects, un message d'erreur s'affiche sous le formulaire ; s'ils sont corrects, le serveur renvoie un « token » — une sorte de laissez-passer numérique temporaire qui prouve, pour les requêtes suivantes, que la personne est bien authentifiée, sans avoir à retaper son mot de passe à chaque fois.

Une fois ce token obtenu, l'application ne redirige pas immédiatement vers la page de profil : elle déclenche automatiquement une seconde requête vers le serveur, cette fois pour récupérer les vraies informations du client (nom, prénom...), en présentant le token comme preuve d'identité. Ce n'est qu'une fois ces informations effectivement reçues que la redirection vers la page de profil a lieu — pour être certain que la page de profil ne s'affiche jamais à moitié vide, en attente de données.

Empêcher l'accès au profil sans être connecté

La page de profil ne doit être accessible qu'aux personnes connectées. Plutôt que de simplement masquer un bouton ou un lien vers cette page, la protection agit directement au niveau de l'adresse (l'URL) elle-même : si quelqu'un tape ou colle directement l'adresse de la page de profil dans son navigateur sans être connecté, il tombe automatiquement sur le formulaire de connexion à la place — impossible de contourner la protection en devinant ou en tapant l'URL directement.

À la déconnexion, l'application ne se contente pas de cacher les informations affichées à l'écran : elle efface complètement les données stockées (le token, le nom, le prénom) pour repartir sur une base neutre, comme si personne ne s'était jamais connecté.

Modifier son profil avec un aperçu immédiat

Le nom et le prénom peuvent être modifiés directement sur la page de profil. Particularité pratique : le prénom affiché en haut de la page se met à jour instantanément pendant la saisie, avant même que la modification soit sauvegardée — un aperçu en direct plutôt qu'une simple case à remplir sans retour visuel. Au clic sur « Enregistrer », l'application envoie les nouvelles valeurs au serveur avec le token de la personne connectée, puis met à jour uniquement le nom et le prénom dans ses données internes une fois la confirmation reçue, sans avoir besoin de recharger l'intégralité du profil pour ça.

Une organisation du code pensée pour durer

La logique Redux a été répartie dans trois fichiers distincts avec des rôles bien séparés : la liste des types d'actions possibles (« l'utilisateur se connecte », « le profil est mis à jour »...), les fonctions qui construisent ces actions, et la fonction qui décide comment les données doivent changer en réponse à chaque action. Cette séparation, plus longue à mettre en place au départ, facilite grandement la lecture et la maintenance du code par la suite — un choix pensé en anticipant une évolution possible : si la fonctionnalité de gestion des comptes bancaires (voir plus bas) venait un jour à être développée, l'approche envisagée serait d'ajouter un second bloc de logique dédié aux comptes, combiné au premier plutôt que de tout mélanger dans un seul fichier devenu illisible.

Concevoir une API sans la coder : la modélisation Swagger

Le second livrable du projet était entièrement différent : pas une ligne de code d'application, mais un document de conception. Il s'agissait d'imaginer et de décrire précisément, à partir de maquettes fournies, les points d'entrée qu'une future API devrait proposer pour permettre à un client de consulter ses comptes et ses transactions bancaires — sans jamais développer cette fonctionnalité elle-même, seulement la spécifier suffisamment clairement pour qu'une autre équipe puisse la construire ensuite sans ambiguïté.

Cinq points d'entrée ont été modélisés : lister l'ensemble des comptes d'un client, consulter le détail d'un compte précis, lister les transactions du mois pour un compte donné, consulter le détail d'une transaction précise, et enfin modifier la catégorie ou ajouter une note personnelle sur une transaction. Chacun de ces points d'entrée précise sa méthode technique d'appel, les informations qu'il attend en entrée, et les différentes réponses possibles selon les cas (succès, erreur, données introuvables).

Un choix technique assumé et défendu à l'oral face au jury : les points de consultation ont été spécifiés selon une méthode de lecture simple (GET) plutôt que d'envoi de données (POST), utilisée par certains points d'entrée déjà existants sur l'API — jugée plus conforme aux usages habituels du web pour une simple lecture d'information, sans conséquence sur les données stockées. De la même façon, la modification d'une transaction a été prévue via une méthode de mise à jour partielle (PATCH) plutôt que de remplacement complet (PUT), puisque seules deux informations sur l'ensemble des données d'une transaction sont réellement modifiables (la catégorie et la note) — inutile de prévoir le renvoi de la totalité des informations d'une transaction pour n'en changer que deux.

Note

Une page d'erreur (affichée quand l'adresse tapée ne correspond à aucune page du site) a été ajoutée alors qu'elle n'était pas explicitement exigée par le brief — jugée indispensable pour qu'une adresse mal tapée reste distinguable d'un vrai dysfonctionnement de l'application plutôt que de renvoyer une page blanche silencieuse.