Depuis que je m’intéresse sérieusement à la finance quantitative, je me retrouve systématiquement à faire la même chose : ouvrir un notebook, télécharger des données, les nettoyer, coder une métrique, tracer un graphe — et tout recommencer à la moindre nouvelle question. J’ai fini par me dire que ça n’avait aucun sens. J’ai donc construit Stat Lab, une application web qui centralise dans une seule interface tous les angles d’analyse d’un actif : statistiques de rendements, mesures de risque, analyse fondamentale, détection de régimes, comparaison multi-actifs. Stat Lab n’est pas un projet isolé : c’est la première brique finalisée de QuantLab, une plateforme modulaire que je développe pour regrouper mes outils de recherche quantitative (analyse statistique, backtesting de portefeuille, calibration de modèles stochastiques).

Contexte et vision

L’idée de départ est simple. Quand j’étudie un actif, je veux pouvoir répondre rapidement à plusieurs questions très différentes : est-ce que ses rendements sont normalement distribués ? Quelle est sa VaR à horizon 1 mois ? Son comportement a-t-il changé de régime récemment ? Ses fondamentaux se dégradent-ils ? Toutes ces questions demandent des outils différents mais partagent la même source de données. Plutôt que de multiplier les scripts ad hoc, j’ai préféré investir une fois pour toutes dans une plateforme unifiée.

La connexion avec StockStream

Une plateforme d’analyse ne vaut que ce que valent ses données. Plutôt que de dépendre d’API tierces instables et limitées, j’ai fait le choix de m’appuyer sur StockStream, l’infrastructure de données financières que j’ai développée en amont précisément pour ce genre d’usage. StockStream tourne en continu, historise les données OHLCV, fondamentales et événementielles sur equities, ETFs, crypto et forex, et les expose via une API REST sécurisée. Stat Lab n’a donc qu’un seul point d’entrée : un client async partagé (stockstream_client) qui interroge StockStream et alimente tous les calculs du lab.

Ce découplage m’a fait gagner énormément de temps. StockStream reste mon backend de données, QuantLab est mon environnement de recherche. Quand je commence un nouveau lab, je n’ai plus jamais à me poser la question de la donnée — je sais qu’elle est là, déjà nettoyée, déjà historisée, déjà indexée.

QuantLab — l’architecture globale

QuantLab est une plateforme multi-conteneurs Docker. Chaque lab est un service FastAPI + React indépendant, accessible depuis un hub central qui fait office de reverse proxy nginx. Stat Lab est le premier lab entièrement finalisé de cet écosystème.

Stack technique

Backend

• Python 3.12, FastAPI, Pydantic v2 — API REST asynchrone typée de bout en bout
• NumPy, Pandas, SciPy, Statsmodels — calculs statistiques et économétriques
• httpx async — client non-bloquant vers StockStream
• Architecture en 6 routers (health, data, analysis, research, fundamentals, events) totalisant une trentaine d’endpoints
• Pattern service locator statique (CONTEXT) pour l’injection de dépendances
• Décorateur @auto_handle_errors uniformisé sur toutes les routes pour une gestion d’erreur cohérente

Frontend

• React 18, TypeScript, Vite avec HMR en développement
• Plotly.js pour les visualisations scientifiques interactives : candlesticks, heatmaps, surfaces 3D
• Système éducatif maison (educatif.ts) — plus de 45 fiches pédagogiques liées aux métriques, surfacées au survol via des composants InfoBubble

Infrastructure

• Docker multi-stage (uv → Node → python:slim) pour des images finales minimales
• Nginx en reverse proxy avec résolution DNS différée, ce qui permet au hub de démarrer même lorsque les labs sont offline
• Compose dev overlay pour hot-reload backend (uvicorn --reload) et frontend (Vite HMR)

Les axes d’analyse — dix onglets, dix angles

Identité et prix : comprendre l’actif

L’onglet Profile fournit la fiche signalétique de l’actif : secteur, market cap, équipe dirigeante, ratios-clés (P/E, P/B, ROE, marges). C’est le premier regard porté sur la santé d’une entreprise.

L’onglet Pricing expose l’OHLCV sous forme de candlestick interactif, avec deux indicateurs techniques activables :

• un RSI calculé avec le lissage EMA de Wilder (période 14), encadré par les bandes d’achat/vente 70/30
• un MACD (12/26/9) présentant la ligne MACD, sa ligne de signal et l’histogramme de divergence colorisé

Propriétés statistiques : mesurer le comportement

L’onglet Returns explore les distributions empiriques des rendements (log et simples), produit les statistiques descriptives (moyenne, volatilité annualisée, skew, kurtosis) et teste la normalité des séries.

L’onglet Risk est le cœur quantitatif de la plateforme :

• Volatility cone — percentiles historiques sur fenêtres glissantes
• Surface VaR 3D — Value-at-Risk croisée sur le niveau de confiance et l’horizon temporel
• Drawdown analysis — durée, profondeur, underwater curve
• Advanced metrics — exposant de Hurst (persistance ou mean-reversion), Calmar, Omega, Ulcer Index, Kelly optimal, variance ratio

L’onglet Seasonality présente une heatmap jour-de-semaine × mois pour isoler les effets calendaires.

L’onglet Regimes détecte automatiquement les régimes de volatilité (faible / moyenne / haute), ce qui permet de segmenter l’historique en phases de marché distinctes avant toute analyse conditionnelle.

Analyse fondamentale : lire les états financiers

L’onglet Fundamentals revisite l’analyse financière classique avec un prisme quantitatif :

• états financiers complets (Income Statement, Balance Sheet, Cash Flow)
• décomposition DuPont du ROE (marge nette × rotation des actifs × levier financier)
• Altman Z-Score pour évaluer le risque de faillite
• Piotroski F-Score pour scorer la qualité fondamentale sur 9 critères
• analyse de la qualité du Free Cash Flow
• historique des ratios pour détecter les tendances structurelles

L’onglet Events retrace les événements corporate, les dividendes et les changements de metadata historisés par StockStream.

L’onglet Scorecard propose une vue synthétique notée, combinaison pondérée des signaux fondamentaux pour un diagnostic rapide.

Détails techniques

Les indicateurs techniques

Le RSI est calculé avec le lissage EMA de Wilder (période 14), pas avec une moyenne mobile simple — c’est une erreur classique qui conduit à des valeurs décalées dans les premières périodes du calcul. Le MACD suit la convention standard (EMA 12, EMA 26, signal 9) et l’histogramme est calculé séparément pour exposer clairement la divergence entre la ligne et son signal. Toutes les séries sont alignées sur un index temporel commun côté backend : les indicateurs ne peuvent pas « voir » de données futures, ce qui élimine par construction tout lookahead bias.

Les requêtes parallèles

Le backend est entièrement asynchrone (httpx pour parler à StockStream, async/await sur toutes les routes FastAPI). Côté frontend, quand un onglet a besoin simultanément des données OHLCV, du RSI et du MACD, les trois appels partent en parallèle via Promise.all au lieu d’être enchaînés. Sur un onglet complet, ça divise le temps de chargement par trois.

Robustesse et remontée d’erreurs

J’ai séparé explicitement deux types d’erreurs. Les erreurs métier (paramètres invalides, série trop courte pour un calcul…) remontent en HTTP 422 avec un message clair, levées manuellement via ValueError. Les erreurs techniques tombent en 500 et sont loggées côté serveur. Le frontend sait lire ces deux cas et afficher un ErrorCard dédié avec le message utilisateur — plus d’écran blanc ni de stack trace opaque à l’écran.

Les fiches éducatives

Chaque métrique affichée dans l’interface est reliée à une entrée du fichier educatif.ts qui donne sa définition formelle, son interprétation et ses plages de valeurs typiques. Au survol d’un InfoBubble, je retrouve immédiatement la sémantique exacte de la mesure — et n’importe quel visiteur aussi. Au-delà du confort d’usage, ce système m’impose une discipline utile : je ne peux pas intégrer une métrique sans d’abord la formaliser proprement, ce qui m’a forcé à re-travailler plusieurs définitions que je pensais maîtriser.

Ce que j’en retire

Ce projet m’a obligé à croiser deux disciplines que je traite habituellement séparément : l’ingénierie logicielle et la finance quantitative. Côté ingénierie, Stat Lab est le premier projet où j’ai poussé aussi loin l’architecture micro-services (Docker, reverse proxy nginx, client async partagé entre plusieurs services) et où j’ai traité le frontend avec autant de sérieux que le backend. Côté finance, chaque onglet a été l’occasion d’implémenter de zéro — et donc de vraiment comprendre — des outils que je n’avais jusqu’ici manipulés que dans des cours ou des articles : la décomposition DuPont, l’Altman Z-Score, le Piotroski F-Score, l’exposant de Hurst, le Kelly criterion, la surface de VaR… Coder une métrique n’a rien à voir avec la lire dans un manuel ; il faut décider de ses paramètres, gérer les cas dégénérés, l’aligner sur les autres métriques, l’expliquer dans une fiche éducative. Au final je connais infiniment mieux ces outils qu’avant de commencer.