Oyko
Application fintech de gestion de finances personnelles — agrégation bancaire Open Banking, backend Spring Boot et chiffrement AES-256. En cours de développement.
- Next.js
- React
- TypeScript
- Spring Boot
- Java
- Spring Security
- PostgreSQL
- AES-256
- Open Banking
- PSD2
- Tailwind CSS

Projet en cours de développement — Oyko est un projet personnel de montée en compétence Java/Spring Boot, né après la piscine Java intensive à EPITA. L'objectif est de consolider l'apprentissage sur un cas concret et ambitieux.
Contexte
Oyko est né d'une frustration simple : les apps de finances existantes sont soit trop basiques (un tableur glorifié), soit des usines à gaz bancaires qui demandent 15 minutes pour savoir combien on a dépensé au restaurant ce mois-ci.
L'objectif : une app claire, rapide, qui connecte mes comptes bancaires et me donne une vision complète de mes finances — dépenses, budgets, patrimoine — sans bruit.
C'est aussi un terrain d'apprentissage concret pour mettre en pratique Java et Spring Boot après la piscine intensive EPITA.
Ce que fait Oyko (implémenté)
Dashboard
Le tableau de bord affiche l'essentiel en un coup d'œil :
- Solde global : agrégé de tous les comptes connectés, mis à jour en temps réel.
- Revenus et dépenses : courbe d'évolution avec comparaison mois précédent.
- Transactions récentes : liste des dernières opérations avec catégorisation automatique.
- Objectifs : suivi des objectifs d'épargne avec barre de progression.
Agrégation bancaire Open Banking
Connexion sécurisée via GoCardless (conforme DSP2/PSD2), compatible avec 350+ établissements européens. Les transactions sont importées automatiquement, catégorisées par un moteur de règles, et réconciliées avec les budgets en cours.
Budgets et alertes
Système d'enveloppes budgétaires par catégorie avec alertes configurables :
- Alerte à 80% du budget atteint
- Notification en temps réel quand un budget est dépassé
- Historique et tendances sur 6 mois
En cours de développement
- Suivi patrimonial : vue consolidée de l'ensemble du patrimoine (comptes courants, livrets, assurance-vie, investissements) avec calcul de la valeur nette.
- Catégorisation ML : remplacement du moteur de règles par un modèle de classification pour améliorer la précision de la catégorisation automatique.

Le backend Spring Boot
C'est sur Oyko que je construis mon premier vrai backend en Java / Spring Boot. Pas un tutoriel, pas un CRUD basique — une API complète qui gère de l'argent, avec tout ce que ça implique en termes de sécurité et de fiabilité.
Ce projet fait suite à la piscine Java intensive à EPITA (plusieurs semaines en immersion full-time : POO avancée, design patterns, collections, concurrence, tests unitaires). Oyko est le prolongement naturel de cet apprentissage sur un cas réel.
Architecture
L'API suit une architecture hexagonale :
oyko-api/
├── adapter/ → Controllers REST, configurations Spring
├── application/ → Use cases, DTOs, ports (interfaces)
├── domain/ → Entités, value objects, règles métier
└── infrastructure/ → Spring Data JPA, repos, services externes, crypto
Chaque couche ne dépend que de la couche en dessous. Le domaine ne connaît ni Spring Data, ni HTTP, ni aucun détail technique. Les use cases orchestrent la logique métier sans savoir comment les données sont stockées.
Spring Data JPA & PostgreSQL
La persistance est gérée par Spring Data JPA avec PostgreSQL :
- Migrations Flyway : schéma versionné, chaque changement est une migration tracée dans Git.
- Repositories : interfaces Spring Data avec query methods et projections JPQL pour ne charger que les colonnes nécessaires.
- Transactions : les opérations multi-entités (création de budget + allocation initiale) sont gérées par
@Transactionalpour garantir la cohérence.
Sécurité & chiffrement
Les données financières, c'est ce qu'il y a de plus sensible. Le chiffrement est au cœur de l'architecture :
- AES-256 : toutes les données bancaires sensibles (IBAN, soldes, montants de transactions) sont chiffrées au repos avec AES-256-GCM. La clé est dérivée via PBKDF2 avec un salt unique par utilisateur.
- Spring Security + JWT : tokens Bearer avec expiration courte (15 min), refresh tokens en base avec rotation à chaque usage.
- Hashing des mots de passe : bcrypt avec cost factor adaptatif.
- Rate limiting : protection contre le brute force sur les endpoints d'authentification (Bucket4j).
Endpoints principaux
POST /api/auth/register → Inscription avec validation email
POST /api/auth/login → Login, retourne JWT + refresh token
GET /api/accounts → Liste des comptes bancaires (déchiffrés)
GET /api/transactions → Transactions paginées avec filtres
POST /api/budgets → Créer un budget avec catégorie et seuil
GET /api/budgets/{id}/status → Statut du budget (consommé/restant/alerte)
POST /api/sync/trigger → Déclencher une synchronisation bancaire
Validation & error handling
- Jakarta Bean Validation : chaque DTO d'entrée est validé avec des contraintes (@NotNull, @Positive, @Pattern pour IBAN, etc.).
- @ControllerAdvice : handler global qui intercepte les exceptions, log le détail en interne, et retourne une réponse propre au client sans leak d'informations.
- Problem Details (RFC 7807) : format standard pour les erreurs HTTP, avec type, title, status et detail.
Stack technique
| Couche | Technologies |
|---|---|
| Frontend | Next.js, React, TypeScript, Tailwind CSS |
| Backend | Java 21, Spring Boot 3, Spring Security |
| ORM | Spring Data JPA, Hibernate |
| Base de données | PostgreSQL |
| Migrations | Flyway |
| Sécurité | AES-256-GCM, JWT, bcrypt, PBKDF2 |
| Open Banking | GoCardless (DSP2/PSD2) |
| Déploiement | Vercel (frontend) |
Ce que j'apprends
Oyko me fait passer de "je sais faire du React" à "je comprends ce qui se passe de l'autre côté de l'API". Quelques prises de conscience en cours de route :
- L'architecture hexagonale, c'est pas du over-engineering — c'est ce qui permet de changer de base de données ou de provider bancaire sans toucher à la logique métier. Sur un projet perso ça paraît overkill. En vrai, ça simplifie énormément les tests et l'évolution.
- Le chiffrement, c'est un métier — j'ai passé plus de temps à comprendre AES-256, les modes de chiffrement (CBC vs GCM), la dérivation de clés et le key management que sur tout le reste du backend combiné. Et c'est normal.
- Spring Boot, c'est un écosystème — la courbe d'apprentissage est raide mais la puissance de Spring Security, Spring Data et l'injection de dépendances rend le code backend beaucoup plus structuré que ce que je faisais avant.