BANKING

Le Contexte et le Problème

Maîtriser le développement full-stack dans sa globalité — de l'authentification à la production, en passant par la gestion des états complexes et l'infrastructure — nécessite de se confronter à un projet concret avec de vraies contraintes. Les tutoriels simplifiés ont leurs limites : ils n'abordent jamais les cas tordus, les failles de sécurité subtiles ou la friction réelle du déploiement.

Ce simulateur bancaire avait une ambition précise : couvrir le spectre complet du développement professionnel. Architecture client-serveur découplée, authentification robuste par cookies HttpOnly, virements entre comptes avec validations métier strictes, et déploiement self-hosted sur VPS avec tout ce que ça implique en termes d'infrastructure et de CI/CD.

Architecture et Choix Techniques

Le frontend est construit avec Angular et TypeScript, dans une architecture orientée composants stricts avec gestion d'état centralisée via services et RxJS. Le choix d'Angular pour un projet solo était délibéré : pratiquer un framework opinioné et enterprise-ready, loin des projets React habituels.

Le backend Spring Boot expose une API REST dont la sécurité est gérée au niveau des filtres HTTP. Les montants monétaires sont traités comme BigDecimal côté Java et sérialisés en string côté TypeScript — une décision architecturale critique pour éviter les pertes de précision liées aux flottants IEEE 754.

L'infrastructure repose sur Docker Compose pour l'orchestration des services (frontend, API, PostgreSQL), Caddy pour la terminaison HTTPS automatique avec Let's Encrypt, et GitHub Actions pour le pipeline CI/CD avec gate de tests : les tests automatisés doivent passer sur dev avant que le build et le déploiement ne s'exécutent sur main via rsync/SSH.

Défis Techniques et Solutions

Le défi le plus complexe a été la gestion des cookies cross-subdomain. L'authentification repose sur un cookie HttpOnly (JWT) partagé entre app.banking.mdiasgomes.com et api.banking.mdiasgomes.com — deux sous-domaines distincts.

• —Configuration SameSite=None, Secure et domain partagé côté Spring Security
• —Activation de allowCredentials = true dans la config CORS, ce qui interdit le wildcard * pour les origines
• —Gestion de trois environnements avec des origines autorisées explicites (dev local, staging, prod)

Le pipeline CI/CD a demandé une attention particulière à l'ordre des étapes : tester avant de construire, construire avant de déployer, et garantir que les secrets (clés SSH, variables d'environnement de production) ne transitent jamais en clair dans les logs GitHub Actions.

La précision monétaire méritait une attention spéciale : en Java, 0.1 + 0.2 n'est pas 0.3. Traiter les montants comme BigDecimal côté backend et comme string côté frontend n'est pas qu'un détail de typage — c'est la différence entre une application financière fiable et une bombe à retardement.

Conclusion et Apprentissages

Ce projet a été une école accélérée sur les réalités de la production. La différence entre "ça marche en local" et "ça marche en prod" tient souvent à des détails d'infrastructure : headers HTTP mal configurés, timing de démarrage des services Docker, certificats TLS.

La prise de recul la plus marquante : les décisions d'ingénierie invisibles pour l'utilisateur — précision numérique, stratégie d'authentification, séquence de déploiement — sont souvent les plus critiques. Ce sont elles qui distinguent un développeur junior d'un développeur senior.