Origine & méthodologie du projet · démarré en avril 2026
Pourquoi j'ai construit Kronos TVM
Un récit honnête des choix techniques, de la méthodologie financière, et des limites assumées. Aucune partie de cette app n'a été générée sans relecture — chaque décision est argumentée et sourcée.
Le déclic
Pourquoi cette app existe
Étudiant en finance, je suis en stage en contrôle de gestion dans une ESN parisienne. Comme beaucoup, mon patrimoine est éclaté : un PEA chez Boursorama, un CTO chez Trade Republic, des Livrets dans deux banques, et une assurance-vie Linxea. Pour avoir une vue d'ensemble, je passais 30 minutes à compiler 5 onglets Excel — désynchronisés en permanence dès qu'un cours bougeait.
J'ai cherché des outils existants. Linxo agrège les comptes bancaires mais ignore le portefeuille de marché. Finary est puissant mais facture l'analyse quantitative (Markowitz, Sharpe) en abonnement annuel. Et tous deux refusent la connexion directe à mon broker européen.
J'ai décidé de construire ce que je voulais utiliser. Pas pour scaler, pas pour le vendre — pour moi. Le résultat se trouve sur cette URL, et tourne sur mon propre portefeuille depuis le début.
Décisions techniques majeures
Avec les compromis assumés
Next.js 14 App Router plutôt que SPA + API séparée
Pourquoi : Server Components + Server Actions = moins de boilerplate API REST, meilleur SEO pour la page /showcase, et un déploiement unique sur Vercel. Le coût : courbe d'apprentissage du nouveau modèle de cache de Next 14.
Compromis : Si l'app explose en complexité backend (jobs lourds, files de tâches), il faudrait extraire une API dédiée.
Supabase plutôt que Firebase ou un backend custom
Pourquoi : Postgres + auth + Realtime + Row-Level Security en un seul service. Free tier généreux (50 000 MAU). SQL standard = aucun lock-in propriétaire si je dois migrer.
Compromis : Limite Realtime à ~100 connexions concurrentes sur le free tier. J'ai dû fiabiliser la reconnexion WebSocket côté client (cf. RealtimeSync.tsx) après plusieurs déconnexions silencieuses sur Safari iOS.
Zustand + persist plutôt que Redux ou React Query
Pourquoi : ~3 KB gzippé, API minimaliste, persist en localStorage natif. Supabase reste la source de vérité — Zustand sert de cache local pour offline + cold-start instantané.
Compromis : Pas de vraie résolution de conflits si l'utilisateur édite sur 2 appareils simultanément. J'ai géré ça en faisant de Supabase la source de vérité (pull on auth, pull on visibilitychange).
Yahoo Finance plutôt qu'une API premium (Alpha Vantage, FMP, IEX)
Pourquoi : Gratuit, sans clé API, couvre les bourses européennes incluant Euronext Paris/Amsterdam (essentiel pour les ETF UCITS). Cache 5 min côté serveur pour éviter le rate-limit.
Compromis : Pas de SLA, pas de support. Depuis le début du projet (avril 2026), j'ai déjà dû patcher la couche d'appel suite à un changement mineur de réponse Yahoo. Un fallback sur une seconde route est en place pour les cas où une URL casse. Pas adapté pour du trading haute fréquence (15 min de délai sur certaines bourses).
Anthropic Claude pour l'assistant, pas OpenAI
Pourquoi : Sur les tâches de raisonnement financier (analyse de portefeuille, recommandations contextuelles), Claude Sonnet 3.5+ produit des réponses mieux structurées et moins hallucinatoires que GPT-4 sur mes tests A/B.
Compromis : Coût/token légèrement supérieur. J'ai limité l'usage de l'IA aux cas où elle apporte vraiment de la valeur (synthèse multi-actifs, explication de concepts), pas pour générer du markdown trivial.
Méthodologie financière
Les formules et leurs sources
Documentation exhaustive disponible
42 formules détaillées (performance, risque, allocation Markowitz, sizing Kelly, indicateurs techniques, planification, ETF, FX) — avec variables, sources académiques et rationale.
Frontière efficiente de Markowitz
Implémentation classique en optimisation quadratique (max Sharpe sous contrainte de somme des poids = 1, poids ≥ 0). Pas de Black-Litterman parce que je n'ai aucune vue prospective fiable à intégrer — Markowitz reste honnête sur ce que je sais (volatilités historiques 1Y, corrélations 52 semaines).
Référence : Markowitz, H. (1952). Portfolio Selection, The Journal of Finance, 7(1).
Critère de Kelly (½ Kelly)
Utilisé pour le sizing recommandé par position :f* = (E[r] − rf) / σ²plafonné à 25% par ligne. La taille fondamentale est dérivée d'une espérance de rendement par classe d'actif (ETF World ≈ 8% nominal, obligations ≈ 3%) — pas du P&L réalisé, pour éviter le biais de momentum.
Référence : Kelly, J.L. (1956). A New Interpretation of Information Rate, Bell System Technical Journal.
Moteur de recommandation
J'ai consciemment évité les signaux brutaux type « ACHETER MAINTENANT » ou « VENDRE TOUT ». Le moteur produit 9 verdicts gradués (CONTINUER_DCA, RENFORCER_PROG, CONSERVER_LT, SURVEILLANCE, REEQUILIBRAGE, LEGERE_REDUCTION, VENTE_PARTIELLE, SORTIE_PROGRESSIVE, SURPONDERATION_RISQUEE) inspirés des recommandations type CGP. C'est volontaire : un outil pré-décision, pas un système de trading.
Risk-free rate (taux sans risque)
OAT 10 ans ≈ 3% utilisé partout (Sharpe, Kelly, primes de risque). Mis à jour manuellement à chaque rebond significatif des taux directeurs BCE. Idéal serait de tirer du flux ECB en temps réel — sur ma roadmap.
Limites assumées
Ce que l'app ne fait pas (encore)
- Pas de connexion bancaire automatique (PSD2 / Powens / Bridge). Les soldes des comptes sont saisis manuellement ou via Telegram. Une intégration Powens demanderait un agrément AISP — incompatible avec un projet perso étudiant.
- Yahoo Finance peut tomber. Si l'API change son schéma, certaines features se figent jusqu'à mon prochain commit. C'est déjà arrivé une fois depuis le démarrage du projet (avril 2026).
- Pas de calcul fiscal exhaustif. Le PFU 30% et les abattements par enveloppe (PEA 5 ans, AV 8 ans) sont simulés, mais pas les cas complexes (déficit reportable, succession, démembrement).
- Données ESG limitées aux ETF couverts par Sustainalytics via Yahoo. Les small/mid caps européennes sont souvent sans score.
- L'assistant IA n'a pas accès aux news en temps réel(Claude API stateless). Les analyses qu'il produit sont basées sur le contexte du portefeuille fourni à chaque appel.
- Pas testé à grande échelle. J'utilise l'app pour mon propre portefeuille (~12 lignes). Le moteur de calcul a été stressé jusqu'à 50 lignes simulées, mais pas au-delà.
Stack & coût mensuel
Le projet tourne à 0 € jusqu'à un certain seuil
Vercel Hobby
0 €
Hébergement + déploiement, fonctions serverless
Supabase Free
0 €
Postgres 500 MB, 50k MAU, Realtime, RLS
OVH .fr
6 €/an
Domaine kronos-tvm.fr
Anthropic API
~2 €/mois
Claude Sonnet, ~50 prompts/jour à usage perso
Yahoo Finance
0 €
Public API, cache local 5 min
Telegram Bot API
0 €
Bot pour notifications + commandes
Total : ~2 €/mois en usage perso. Scaling jusqu'à ~1000 utilisateurs coûterait < 50 €/mois — bonne marge pour un MVP.
Ce que j'aimerais ajouter
Roadmap honnête (priorité décroissante)
- HauteTests Vitest sur
lib/financialCalc.ts,lib/backtest.ts,lib/pnl.ts— la correction des calculs est critique - HauteMonte Carlo + VaR/CVaR (1000 trajectoires sur 5/10 ans)
- MoyenneStress tests historiques (2008, COVID 2020, hausse de taux 2022)
- MoyenneSync taux ECB en temps réel pour
RF - MoyenneModule notes de frais avec OCR (Claude Vision) — pour mon stage ESN
- BasseMulti-utilisateur Telegram via table
telegram_links - BasseMigration
recharts→lightweight-chartssur les pages d'analyse (gain perf ~10×)
Sources & lectures
Ce qui a nourri la méthodologie
- Bogleheads Wiki — Référence anglophone sur l'investissement passif
- Épargnant 3.0 — Edouard Petit — Le livre français de référence sur l'ETF World + DCA
- AMF — Investir en bourse — Cadre réglementaire FR + définitions officielles
- Investopedia — Sharpe Ratio — Formules + interprétation
- Markowitz (1952), Portfolio Selection— Le papier fondateur de l'optimisation de portefeuille
- Kelly (1956), A New Interpretation of Information Rate— Le critère de Kelly originel
- Fama & French (1992), The Cross-Section of Expected Stock Returns— Pour la prochaine itération du moteur de signaux