Vue d'ensemble
Dans la banque, il n'y a pas de droit à l'erreur. Un formulaire de connexion qui plante, un token mal géré, une route non protégée — et c'est la confiance de l'utilisateur qui s'effondre. Ce projet consistait à construire un socle applicatif où la sécurité n'est pas une couche ajoutée après coup, mais le fondement même de l'architecture.
Le projet
Développer une application React sécurisée avec authentification complète, profil utilisateur éditable et état global centralisé via Redux.
Le client
Argent Bank, néobanque en ligne. Un contexte où chaque faille technique se traduit directement en perte de confiance — et en perte de clients.
Le problème
Des maquettes statiques sans logique applicative. Pas de session, pas de routes protégées, pas de gestion d'état. Tout était à construire — sur un terrain où la moindre erreur est visible.
L'objectif
Poser une Phase 1 solide, sécurisée et maintenable — suffisamment robuste pour servir de fondation à toutes les fonctionnalités bancaires à venir.
Ce projet ne consistait pas à relier un formulaire à une API. Il fallait construire une logique d'application complète dans un contexte où la fiabilité n'est pas un bonus — c'est un prérequis.
Résultats concrets
Authentification sans faille
Connexion, déconnexion, gestion du token et récupération du profil — un flux complet, testé et fiable dans tous les cas d'usage, y compris les erreurs.
Routes blindées
Les pages sensibles sont inaccessibles sans session valide. Pas de contournement possible, pas d'écran blanc — une redirection propre à chaque fois.
Un état global limpide
Redux Toolkit centralise l'authentification et le profil dans une architecture lisible. Chaque donnée a sa place, chaque flux est traçable.
Un socle prêt pour la Phase 2
L'architecture est conçue pour accueillir les transactions, les comptes multiples et les prochaines fonctionnalités — sans refactoring structurel.
Avant / Après
Le problème
Construire une application bancaire — même limitée à l'authentification — impose un niveau d'exigence que la plupart des projets front ne rencontrent jamais. Ici, chaque détail technique a une conséquence directe sur la confiance de l'utilisateur.
Concrètement, il fallait résoudre quatre défis avec zéro marge d'erreur :
- Une authentification qui ne plante pas. Dans une app bancaire, un formulaire de connexion qui échoue silencieusement ou qui affiche un message cryptique, c'est un utilisateur perdu — et potentiellement un client qui part à la concurrence.
- Des routes réellement protégées. Pas un simple
ifen JavaScript. Une protection structurelle qui redirige proprement, gère l'expiration du token et reste cohérente avec l'état global. - Un état global qui ne ment pas. Dans une app où l'utilisateur voit son profil et ses données sensibles, l'état du store doit refléter la réalité à chaque instant. Un décalage entre le front et le back, même temporaire, crée de la méfiance.
- Un socle extensible. Cette Phase 1 n'est qu'un début. L'architecture devait supporter l'ajout futur de transactions, de comptes multiples et de nouvelles fonctionnalités — sans tout réécrire.
C'est la combinaison de ces exigences qui rend ce projet plus complexe qu'il n'y paraît — et qui sépare un exercice technique d'une vraie construction de produit sécurisé.
Notre approche
Avant d'écrire une ligne de code, nous avons commencé par lire — rigoureusement — le contrat back-end.
Phase 0 — Comprendre le terrain
- Lecture exhaustive de la documentation Swagger : endpoints, contraintes de token, comportements en cas d'échec
- Modélisation des flux critiques : connexion > token > profil > édition > déconnexion
- Identification des cas limites : token expiré, requête échouée, navigation directe sur une route protégée
Architecture — Séparer les responsabilités
- Store Redux structuré en deux slices clairs :
auth(session, token) etuser(profil, édition) - Couche réseau isolée avec gestion centralisée des erreurs et du token
- Composants UI découplés de la logique métier — chaque couche fait une seule chose
Authentification — Fiabilité avant tout
- Formulaire de connexion avec validation et retours d'erreur explicites
- Récupération et stockage sécurisé du token
- Flux de déconnexion qui nettoie proprement l'état et redirige
- Gestion des erreurs réseau avec messages compréhensibles pour l'utilisateur
Routes protégées — Sécurité structurelle
- Guard component qui vérifie la session avant chaque rendu
- Redirection automatique vers le login en l'absence de token valide
- Cohérence garantie entre l'état Redux et la navigation — pas de page fantôme
Profil utilisateur — Premier flux applicatif vivant
- Récupération des informations utilisateur après authentification
- Édition du pseudo avec mise à jour immédiate dans le store et sur l'API
- Retour visuel clair après chaque action (succès, erreur, chargement)
Dans un contexte bancaire, la qualité ne se mesure pas aux features visibles. Elle se mesure à ce qui se passe quand les choses tournent mal : un token expiré, une requête qui échoue, une navigation inattendue. C'est là que la rigueur de l'architecture fait la différence.
Stack technique
- React 18
- React Router 6
- Redux Toolkit
- Wrapper réseau centralisé (Axios/Fetch)
- Vite
- ESLint, Prettier (qualité de code)
- Jest, React Testing Library (tests unitaires et d'intégration)
- MSW (mock API pour les tests)
- Git / GitHub
Le résultat
Le résultat est une Phase 1 qui ne ressemble pas à une Phase 1. Pas de prototype fragile, pas de « on verra plus tard pour la sécurité ». Une application complète, testée et structurée — prête à accueillir les fonctionnalités bancaires suivantes sans remettre en question ses fondations.
- Une authentification complète qui gère les cas normaux et les cas d'erreur
- Des routes protégées qui ne laissent rien passer
- Un profil utilisateur éditable avec feedback immédiat
- Un état global centralisé, typé et debuggable
- Un code testé, documenté et prêt à être repris par une autre équipe
- Une architecture conçue dès le départ pour supporter la Phase 2
L'application ne se contente pas de fonctionner. Elle inspire confiance — et dans la banque, c'est la seule métrique qui compte.
Ce que ce projet révèle
Ce projet démontre une compétence critique : savoir construire un front-end sécurisé dans un contexte où la moindre faille technique se traduit en perte de confiance utilisateur. Authentification, gestion d'état, routes protégées et architecture extensible — le tout avec la rigueur qu'exige un environnement bancaire.
Si vous construisez une application qui gère des données sensibles, qui nécessite une authentification robuste ou qui doit inspirer confiance dès la première interaction — c'est exactement ce niveau de rigueur que nous apportons.