Contexte
La plupart des applications de budget imposent la même contrainte : connecter ses comptes bancaires via un agrégateur. C’est efficace, mais cela suppose de confier ses identifiants, alors que l’essentiel des utilisateurs veut simplement savoir ce qu’il lui reste à la fin du mois.
jibu part de l’hypothèse inverse : pas d’agrégation, pas de données bancaires sensibles. On saisit ses revenus, ses charges fixes et ses dépenses, et l’application calcule le reste à vivre en temps réel. Le compromis est assumé : un peu de saisie contre zéro dépendance à un tiers financier.
Le projet est mené seul, du cadrage produit à l’exploitation : conception, design system, base de données, sécurité, facturation, pages marketing et mise en production.
Périmètre fonctionnel
- Reste à vivre calculé en continu à partir des revenus récurrents et des charges fixes.
- Multi-comptes : compte courant, compte joint, néobanques, chacun avec son solde propre.
- Budget partagé : notion de foyer, invitations, droits par membre.
- Abonnements et paiements échelonnés (3×, 4×, 10×) suivis dans le temps.
- Vue calendrier jour par jour, avec reconnaissance automatique des enseignes.
- Import de relevés (PDF, tableurs) pour éviter la ressaisie.
- Espace d’administration : utilisateurs, journal d’audit, retours, communications.
Choix techniques
L’application est un App Router Next.js 16 adossé à Supabase (PostgreSQL, Auth, Storage). Deux décisions structurent le reste :
- Toutes les mutations passent par des Server Actions. Aucune écriture Supabase n’est faite depuis le client, ce qui concentre les contrôles d’accès côté serveur et rend le périmètre auditable.
- Les schémas Zod sont la source de vérité unique. Validation client, validation serveur et types TypeScript dérivent du même schéma, et une règle métier ne peut pas diverger entre les deux couches.
Le reste suit : RLS PostgreSQL sur toutes les tables utilisateur, migrations strictement additives et versionnées (49 à ce jour), MFA et appareils de confiance, Stripe pour la facturation avec gestion des rétrogradations d’offre, et une PWA avec mode hors-ligne.
Conformité et exploitation
Le choix de ne pas agréger les comptes bancaires simplifie radicalement la conformité : aucune donnée de connexion bancaire n’est stockée, aucun agrégateur tiers dans la chaîne. La documentation interne couvre le RGPD et s’aligne sur les pratiques ISO 27001 (journal d’audit, minimisation, export et suppression des données à la demande).
Côté exploitation : branche main protégée, CI GitHub Actions obligatoire avant merge, hooks Git
locaux bloquant les poussées directes, tests Vitest et vérification de non-régression React sur
chaque lot de modifications.
Acquisition
Huit pages d’atterrissage prérendues ciblent les requêtes réelles des utilisateurs (« gérer son budget », « reste à vivre », « suivi des dépenses », « budget en couple », « gérer ses abonnements ») plutôt qu’une page produit unique. Chacune répond à une intention précise et renvoie vers l’inscription.
Livrables clés
- Application web responsive et installable (PWA)
- Base PostgreSQL sous RLS, 49 migrations versionnées
- Authentification e-mail + MFA + appareils de confiance
- Facturation Stripe et parcours de changement d’offre
- Espace d’administration et journal d’audit
- Pages marketing et légales, documentation technique interne