Guide avancé de trading par IA : La référence complète des bibliothèques, modèles et frameworks de ML pour quants

Les arbres de décision à gradient boosting (GBDT) — et non les réseaux profonds — sont la famille de modèles par défaut pour chaque tâche tabulaire de classification/régression de ce pipeline : méta-étiquetage, caractéristiques de régime, scoring de facteurs. Une comparaison de 2024 largement citée, portant sur plus de 100 à 300 benchmarks tabulaires, a constaté que les GBDT égalent ou surpassent le deep learning sur données tabulaires avec bien moins de réglages (arXiv:2402.03970). Les données financières tabulaires sont exactement le régime où cela tient le plus fort : faible rapport signal/bruit, caractéristiques mixtes continues/catégorielles/creuses, forte non-stationnarité et petites tailles d'échantillon effectives — des conditions où la flexibilité des réseaux profonds achète surtout de la variance, pas du signal.

Pourquoi les GBDT dominent les données financières tabulaires

• Compromis biais-variance. Avec quelques milliers de lignes effectives (pondérées par l'unicité) et un signal faible et bruité, le faible biais d'un réseau à haute capacité se paie d'un coût en variance que vous ne pouvez pas vous permettre. Des arbres peu profonds à forte régularisation (nombre de feuilles, min-data-in-leaf, bagging) se situent bien mieux sur ce compromis.
• Caractéristiques mixtes et creuses nativement. Les arbres découpent sur les valeurs brutes des caractéristiques — pas de mise à l'échelle, pas de stratégie d'imputation, pas de table d'embeddings pour les catégorielles rarement renseignées (secteur, place, indicateur de proximité d'échéance). L'effort d'ingénierie des caractéristiques va au signal, pas à la tuyauterie de prétraitement.
• Les contraintes monotones encodent directement des a priori financiers. LightGBM/XGBoost/CatBoost prennent tous en charge monotone_constraints : p. ex. forcer P(gain) à être non décroissante en force de tendance et non croissante en volatilité réalisée. Cela régularise vers des modèles sensés au regard du domaine et est indisponible, ou bien plus laborieux, dans un MLP standard.
• Valeurs manquantes et non-stationnarité. Les arbres acheminent nativement les valeurs manquantes (pas d'imputation sujette aux fuites ajustée sur l'ensemble du jeu de données), et des arbres peu profonds fréquemment réentraînés s'adaptent plus vite aux changements de régime qu'un grand réseau qui a besoin de nombreuses époques pour désapprendre des schémas obsolètes.

*Les nombres d'étoiles sont indicatifs, vérifiés mi-2026 — à traiter comme un « ordre de grandeur », pas comme des chiffres exacts.

import lightgbm as lgb
from sklearn.model_selection import train_test_split

# X: one row per primary-strategy signal date. Columns e.g.
#   log_ret_5d, log_ret_20d, realized_vol_20d, atr_14, frac_diff_price,
#   ema_slope, rsi_14, bb_pctb, obv_z, dist_200ma
# y: triple-barrier label from mlfinpy -> 1 = profit barrier hit first, 0 = stop/time first
# w: sample weight from mlfinpy uniqueness/time-decay (NEVER plain 1s -- labels overlap)
X, y, w = features_df[feature_cols], labels_df["tb_label"], labels_df["sample_weight"]

X_train, X_val, y_train, y_val, w_train, w_val = train_test_split(
    X, y, w, test_size=0.2, shuffle=False              # never shuffle time series
)

params = {
    "objective": "binary", "metric": "auc",
    "num_leaves": 31, "learning_rate": 0.03,
    "feature_fraction": 0.7, "bagging_fraction": 0.7, "bagging_freq": 5,
    "min_data_in_leaf": 50,
    # financial priors: e.g. [trend, vol, ...] -> win-prob non-decreasing in trend,
    # non-increasing in realized vol, unconstrained (0) elsewhere
    "monotone_constraints": [1, 0, -1, 0, 0, 1, 0, 0, 0, -1],
    "verbosity": -1,
}
train_set = lgb.Dataset(X_train, label=y_train, weight=w_train)
val_set   = lgb.Dataset(X_val, label=y_val, weight=w_val, reference=train_set)

model = lgb.train(params, train_set, num_boost_round=2000,
                   valid_sets=[val_set], callbacks=[lgb.early_stopping(100)])

meta_label_proba = model.predict(X_new)  # P(this signal hits the profit barrier first)

pip install xgboost
# minimal use: xgboost.XGBClassifier(n_estimators=800, max_depth=4, learning_rate=0.03,
#   subsample=0.7, colsample_bytree=0.7, monotone_constraints="(1,0,-1,0,0,1,0,0,0,-1)")

pip install catboost
# CatBoostClassifier(cat_features=["sector","exchange"], iterations=1500,
#   depth=6, learning_rate=0.03, monotone_constraints="1:1,2:-1")

Ce sont les architectures neuronales à entraîner soi-même de zéro (généralement via neuralforecast, Apache-2.0, qui les implémente toutes), par opposition aux modèles de fondation préentraînés du §3. Chacune d'elles a été benchmarkée jusqu'à son existence sur M4/M3/electricity/traffic/ETT — aucune n'a été conçue face à des séries de rendements financiers, et le verdict honnête par architecture le reflète.

Les prévisionnistes de séries temporelles préentraînés et zero-shot sont réels et utiles — pour la volatilité, pas la direction du prix. Une étude de juin 2026 construite spécifiquement pour tester cela, « Pretrained Time-Series Foundation Models for Financial Return Forecasting » (Noguer i Alonso et Pereira Franklin, AI Finance Institute), a benchmarké TimeGPT, TimesFM-2.5, Moirai-2.0, Chronos et Chronos-2 face à NBEATS/NHITS/PatchTST/iTransformer/KAN entraînés de zéro sur cinq actions américaines liquides (AAPL, AMZN, GOOG, JPM, META) avec un protocole à origine glissante face à une base de marche aléatoire. Le résultat : sur dix combinaisons actif/tâche, seules deux ont montré une surperformance statistiquement significative de la marche aléatoire — Chronos sur AMZN et Moirai-2.0 sur GOOG — et les auteurs affirment sans détour que « les gains sur la base de marche aléatoire sont faibles et rares », concluant que les TSFM sont « des a priori pratiques utiles qui réduisent les coûts de développement de modèles », mais explicitement « pas des moteurs universels pour une génération d'alpha statistiquement fiable ». Traitez chaque modèle ci-dessous en conséquence : d'excellents moteurs, exécutables sur CPU, pour des entrées de volatilité/prévision de vol vers une couche de dimensionnement ; faibles à égaux à la marche aléatoire pour la direction du prix.

pip install chronos-forecasting torch

import torch
from chronos import BaseChronosPipeline

pipeline = BaseChronosPipeline.from_pretrained(
    "amazon/chronos-bolt-base",     # T5-style encoder-decoder, 205M params, Apache-2.0
    device_map="cpu",               # CPU is fine for daily-bar, small-batch inference
    torch_dtype=torch.bfloat16,
)

# Feed REALIZED VOLATILITY, not raw price -- this is a vol forecaster, not an oracle
context = torch.tensor(realized_vol_20d.values[-512:])

quantiles, mean = pipeline.predict_quantiles(
    context=context,
    prediction_length=10,                   # 10-day-ahead vol forecast
    quantile_levels=[0.1, 0.5, 0.9],
)
vol_forecast_median = quantiles[0, :, 1]    # feed straight into GARCH/vol-target sizing (see §10)

pip install timesfm
# tfm = timesfm.TimesFm(context_len=512, horizon_len=10, backend="cpu")
# tfm.load_from_checkpoint(huggingface_repo_id="google/timesfm-2.0-500m-pytorch")
# point_fc, quantile_fc = tfm.forecast([realized_vol_20d.values], freq=[0])

Le sentiment/TALN financier appartient à la couche de risque (une caractéristique de veto/régime) et non à la couche d'alpha — selon la recherche source du §0, l'avantage du sentiment d'actualités isolé est en grande partie un artefact d'anticipation qui meurt hors échantillon. Voici les trois modèles qui valent vraiment la peine d'être connus.

pip install transformers torch

from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

tok = AutoTokenizer.from_pretrained("ProsusAI/finbert")
model = AutoModelForSequenceClassification.from_pretrained("ProsusAI/finbert")
model.eval()

headlines = ["Company X beats earnings estimates, raises guidance",
             "Regulators open investigation into Company X"]

with torch.no_grad():
    inputs = tok(headlines, return_tensors="pt", padding=True, truncation=True)
    probs = torch.softmax(model(**inputs).logits, dim=-1)

# label order per config.id2label: 0=positive, 1=negative, 2=neutral
labels = ["positive", "negative", "neutral"]
scores = [dict(zip(labels, p.tolist())) for p in probs]
# aggregate to a daily sentiment score; use ONLY as a veto/regime feature, not alpha

Le RL est l'élément le plus survendu et le moins fiable de toute cette page pour un moteur de trading central. L'outillage est réellement bon ; le verdict honnête, étayé par le propre concours de benchmark de la communauté RL, est de le cantonner à des sous-problèmes étroits et strictement validés (p. ex. le timing d'exécution) plutôt qu'à un moteur principal ou au niveau du portefeuille.

Les quatre familles d'algorithmes (une ligne chacune)

• PPO (Proximal Policy Optimization) — on-policy, actions discrètes ou continues ; borne l'étape de mise à jour de la politique pour rester proche de l'ancienne, échangeant un peu d'efficacité d'échantillon contre de la stabilité d'entraînement. Le premier choix par défaut dans la plupart des exemples FinRL.
• SAC (Soft Actor-Critic) — off-policy, actions continues seulement ; objectif à entropie maximale (récompense explicitement l'exploration) avec un tampon de rejeu, généralement plus efficace en échantillon que PPO mais plus sensible aux hyperparamètres.
• DQN (Deep Q-Network) — off-policy, actions discrètes seulement ; apprend une fonction valeur-action via un tampon de rejeu et un réseau cible. Nécessite un espace d'action discrétisé (p. ex. acheter/conserver/vendre), ce qui convient mal au dimensionnement continu de position.
• A2C (Advantage Actor-Critic) — on-policy, discret ou continu ; un cousin plus simple et synchrone d'A3C, généralement le plus faible des quatre sur les tâches financières dans les propres benchmarks de FinRL.

Portée pratique, si vous utilisez le RL malgré tout : un sous-problème étroit à récompense naturellement en forme de MDP (p. ex. le timing d'exécution d'ordres au sein d'un ordre parent fixe, le suivi VWAP), évalué avec la même discipline PBO/DSR que tout le reste au §14 — jamais comme moteur principal d'entrée/sortie/dimensionnement.

Qlib est ce qui se rapproche le plus d'une plateforme de recherche IA-quant clé en main en open source — une couche de données, un DSL d'ingénierie de caractéristiques, un zoo de modèles et un harnais de backtest walk-forward/analyse de portefeuille, reliés entre eux via des configurations de workflow YAML. Sous licence MIT (microsoft/qlib), des dizaines de milliers d'étoiles GitHub, MIT depuis son ouverture en septembre 2020, activement mis à jour (v0.9.7, août 2025) et désormais couplé au RD-Agent de Microsoft pour une expérimentation automatisée de boucle de recherche.

Alpha158 vs. Alpha360 — les deux jeux de caractéristiques intégrés

Système de workflow/configuration et zoo de modèles intégré

Les expériences Qlib sont typiquement pilotées par un unique fichier YAML consommé par la CLI qrun, déclarant le gestionnaire de données (Alpha158/360 ou personnalisé), le modèle, le découpage du jeu de données, la stratégie de portefeuille et les paramètres de backtest — cela fait du remplacement de LightGBM par un GRU ou un wrapper TFT un changement de config d'une ligne, pas une réécriture. Le zoo de modèles intégré couvre des approches classiques et profondes : LGBModel (LightGBM), XGBModel, CatBoostModel, MLP, GRU/LSTM/ALSTM (récurrents), Transformer, wrapper TFT, TabNet, HIST, IGMTF, et plusieurs modèles de recherche à graphes/attention (GATs, KRNN, Localformer) — tous entraînés et évalués via le même harnais de workflow avec un rapport partagé de backtest walk-forward/analyse d'IC.

qlib_init:
  provider_uri: "~/.qlib/qlib_data/custom_nse"   # see note below on pointing Qlib at NSE data
  region: in                                       # generic region tag; India isn't a stock Qlib region out of the box

market: &market custom_nse_500
benchmark: &benchmark NIFTY500

data_handler_config: &data_handler_config
  start_time: 2010-01-01
  end_time: 2025-12-31
  fit_start_time: 2010-01-01
  fit_end_time: 2019-12-31
  instruments: *market

task:
  model:
    class: LGBModel
    module_path: qlib.contrib.model.gbdt
    kwargs:
      loss: binary
      num_leaves: 31
      learning_rate: 0.03
      monotone_constraints: [1, 0, -1, 0]
  dataset:
    class: DatasetH
    module_path: qlib.data.dataset
    kwargs:
      handler:
        class: Alpha158
        module_path: qlib.contrib.data.handler
        kwargs: *data_handler_config
      segments:
        train: [2010-01-01, 2019-12-31]
        valid: [2020-01-01, 2021-12-31]
        test:  [2022-01-01, 2025-12-31]

# run with:  qrun this_config.yaml

La boîte à outils d'Advances in Financial Machine Learning de López de Prado signifiait autrefois une licence payante mlfinlab — ce n'est plus le cas. Deux paquets gratuits et sous licence permissive couvrent désormais l'étiquetage de triple barrière, le méta-étiquetage, la différenciation fractionnaire, la pondération d'unicité d'échantillon, la CPCV et la HRP.

pip install mlfinpy

from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol

# causal, EWMA-based daily volatility -- uses data strictly up to t, no leakage
daily_vol = get_daily_vol(close=prices, lookback=50)

vertical_barriers = add_vertical_barrier(
    t_events=signal_dates, close=prices, num_days=10       # time-limit barrier
)

triple_barrier_events = get_events(
    close=prices,
    t_events=signal_dates,             # your primary (Pine) strategy's signal dates
    pt_sl=[2.0, 1.5],                  # profit-take / stop-loss as multiples of daily_vol
    target=daily_vol,
    min_ret=0.0005,
    num_threads=4,
    vertical_barrier_times=vertical_barriers,
)

labels = get_bins(triple_barrier_events, prices)
# labels['bin']    -> 1 = profit barrier hit first, 0 = stop/time barrier hit first
# labels['ret']    -> realized return at the barrier that was hit
# labels['t1']     -> the barrier-touch timestamp (needed for purging downstream)

pip install skfolio

from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
import lightgbm as lgb

meta_label_pipeline = Pipeline([
    ("model", lgb.LGBMClassifier(num_leaves=31, learning_rate=0.03,
                                  min_child_samples=50)),
])

# n_folds=10, n_test_folds=2  ->  C(10,2) = 45 combinatorial train/test paths
# purged_size / embargo_size sized to the max holding horizon (t1 - t0), NOT a flat 1%
cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2,
                            purged_size=10, embargo_size=10)

# returns an empirical DISTRIBUTION of out-of-sample paths, not one score --
# use it to compute PBO and the Deflated Sharpe Ratio, not a single train/test split
oos_paths = cross_val_predict(estimator=meta_label_pipeline, X=X, y=y,
                               cv=cv, sample_weight=w)

Ce que chaque technique vous apporte

• Différenciation fractionnaire (mlfinpy.features.frac_diff / variante FFD à largeur fixe) — trouve l'ordre de différenciation minimal d (souvent 0,2-0,5) qui passe un test de stationnarité ADF tout en conservant une corrélation >0,9 avec la série de niveaux, donnant une entrée stationnaire qui garde de la mémoire — strictement meilleur pour les modèles à arbres/linéaires que les rendements bruts (mémoire nulle) ou le prix brut (non stationnaire).
• Pondération d'unicité d'échantillon — les étiquettes de triple barrière se chevauchent dans le temps (une période de détention de 10 jours signifie que des signaux adjacents partagent des fenêtres d'étiquette), violant l'hypothèse IID sur laquelle repose l'essentiel de la théorie du ML. Pondérez chaque échantillon par son unicité moyenne (inverse du nombre d'étiquettes concurrentes) plus une décroissance temporelle, sinon votre taille d'échantillon effective est une fraction de votre nombre de lignes et chaque test de significativité en aval est surestimé.
• Validation croisée purgée combinatoire (CPCV) — génère de nombreuses combinaisons de chemins train/test (et non un seul chemin walk-forward), purge les lignes d'entraînement dont la fenêtre d'étiquette chevauche le fold de test, et applique un embargo tampon après chaque fold de test. Produit une distribution complète de ratios de Sharpe hors échantillon (alimentant le PBO et le DSR) au lieu d'une estimation ponctuelle — c'est pourquoi elle est structurellement plus fiable que le walk-forward simple.
• HRP (Hierarchical Risk Parity) (skfolio.optimization.HierarchicalRiskParity) — alloue via un clustering hiérarchique de la matrice de corrélation au lieu d'inverser une matrice de covariance bruitée (ce que fait l'optimisation moyenne-variance), la rendant bien plus robuste à l'erreur d'estimation sur un panier d'actions corrélées.

C'est la section où réside le bug de fuite silencieuse le plus courant du gating de régime chez les particuliers — et où montrer le mauvais schéma à côté du bon est plus utile que de le décrire en prose.

from hmmlearn.hmm import GaussianHMM

model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=1000)
model.fit(X_full)                    # fit on the ENTIRE history -- future leaks into the fit
regimes = model.predict(X_full)      # Viterbi = globally-smoothed decode over the whole path
# regimes[t] used information from t+1 ... T. This is look-ahead bias.
# Any backtest of a regime gate built this way is invalid and will not reproduce live.

from hmmlearn.hmm import GaussianHMM
import numpy as np

regime_at_t = np.full(len(X), np.nan)
model, refit_every, min_train = None, 63, 500     # e.g. refit quarterly

for t in range(min_train, len(X)):
    if model is None or t % refit_every == 0:
        model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        model.fit(X[:t])                          # ONLY data strictly before t

    # forward-algorithm FILTERED posterior using data up to and including t --
    # no smoothing, no future information, no re-fit on data that includes t's label use
    posteriors = model.predict_proba(X[:t + 1])
    regime_at_t[t] = posteriors[-1].argmax()       # today's regime, knowable today

# regime_at_t is safe to merge into the feature frame for both backtest and live use.
# Expect a MUCH smaller, laggier drawdown benefit than the full-sample-smoothed version --
# that gap IS the size of the leakage bug you just closed.

ruptures est l'outil complémentaire quand vous voulez des points de rupture plutôt qu'un état de régime persistant — p. ex. signaler une rupture de régime de volatilité dans une série EWMA pour déclencher un réajustement du HMM, ou comme détecteur alternatif de frontières de régime pour recouper les transitions du HMM. Pelt (recherche exacte à coût linéaire, nombre inconnu de points de rupture, nécessite un paramètre de pénalité) est le choix par défaut ; Binseg échange l'exactitude contre la vitesse sur des séries plus longues ; les méthodes à fenêtre sont les moins coûteuses mais les moins précises sur les ruptures subtiles. Comme le HMM, exécutez-le en fenêtre expansive/glissante pour un usage en direct — l'API standard de ruptures est elle aussi une méthode hors ligne sur série complète par défaut.

Aucun moteur unique n'est adapté à chaque étape. Utilisez un moteur vectorisé pour trier des milliers de combinaisons de paramètres, puis revalidez chaque survivant sur un moteur événementiel avec des exécutions réalistes avant de risquer du capital — confondre les deux étapes (faire confiance à un backtest de moteur vectorisé comme réponse finale) est une erreur courante et coûteuse.

Pourquoi l'architecture de NautilusTrader compte vraiment

La plupart des échecs « excellent backtest, réel décevant » ne sont pas des échecs de modèle — ce sont des bugs d'écart recherche/production : votre moteur de backtest et votre code d'exécution en direct sont deux bases de code distinctes qui dérivent silencieusement l'une de l'autre (une hypothèse de prix d'exécution ici, un bug de timing de bougie décalé d'une unité là), et rien ne les force à rester cohérentes. La conception événementielle à cœur Rust de NautilusTrader exécute le même code de stratégie — les mêmes classes, les mêmes gestionnaires d'événements — en mode backtest, paper et live ; seuls les adaptateurs de données/exécution changent. Ce choix architectural élimine toute une classe de bugs par construction plutôt que par discipline, ce qui en fait le bon outil pour le rôle de « revalidation finale à exécutions réalistes et pont vers la production » plutôt qu'un simple plus.

C'est ici que le « contrôle du drawdown » est réellement implémenté — comme des mathématiques déterministes consommant des prévisions de volatilité et la confiance de méta-étiquette, pas comme une nouvelle tâche de prédiction.

pip install arch

from arch import arch_model
import numpy as np

returns_pct = 100 * log_returns.dropna()      # arch expects % returns for numerical stability
# GJR-GARCH(1,1,1) with Student-t errors -- captures the leverage effect (vol reacts more to
# negative returns than positive ones), which plain GARCH(1,1) misses
am = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t")
res = am.fit(disp="off", last_obs=train_end_date)   # fit only on data up to the current date

fcast = res.forecast(horizon=10, reindex=False)
vol_forecast_daily = np.sqrt(fcast.variance.values[-1]) / 100   # back to decimal daily vol

target_vol_daily = 0.10 / (252 ** 0.5)        # ~10% annualized portfolio vol target
position_scale = target_vol_daily / vol_forecast_daily[0]
position_size = base_size * min(position_scale, max_leverage_cap)   # always cap leverage

from pypfopt import HRPOpt
hrp = HRPOpt(returns=daily_returns_df)   # NOT prices -- pass returns
weights = hrp.optimize()                 # hierarchical-clustering-based, no covariance inversion

import riskfolio as rp
port = rp.Portfolio(returns=daily_returns_df)
port.assets_stats(method_mu="hist", method_cov="hist")
weights = port.optimization(model="Classic", rm="CVaR", obj="MinRisk", rf=0, l=0)

Avant de faire confiance à tout résultat de GBDT ou de modèle de fondation, benchmarkez-le face à la base ennuyeuse. Ces deux bibliothèques couvrent l'extraction automatisée de caractéristiques et les bases de prévision classiques que vous ne devriez jamais sauter.

pip install tsfresh
from tsfresh import extract_relevant_features

# long-format df: columns [id, time, value]; y indexed by id (e.g. triple-barrier label)
features = extract_relevant_features(
    long_format_df, y=labels_by_id, column_id="id", column_sort="time",
    fdr_level=0.01,           # false-discovery-rate control -- do NOT skip this on financial data
)
# re-run the relevance filter INSIDE each CV fold in production, never on the full dataset

pip install statsforecast
from statsforecast import StatsForecast
from statsforecast.models import AutoARIMA, AutoETS

sf = StatsForecast(models=[AutoARIMA(), AutoETS()], freq="D", n_jobs=-1)
sf.fit(train_df)
baseline_forecast = sf.predict(h=10)
# your GBDT / foundation-model forecast must beat THIS, net of cost, or there is no edge

L'outillage MLOps ici ne concerne pas l'échelle — il concerne l'honnêteté. La fonction MLOps la plus déterminante de toute cette stack est la discipline du décompte d'essais pour le Deflated Sharpe Ratio : chaque configuration de backtest que vous avez essayée, suivie, pour toujours, afin que la correction pour tests multiples soit calculée face à votre décompte d'essais réel, pas au sous-ensemble flatteur dont vous vous souvenez.

pip install mlflow
import mlflow

with mlflow.start_run(run_name="lgbm_meta_label_v37"):
    mlflow.log_params(params)                                   # every hyperparameter tried
    mlflow.log_param("cv_scheme", "CombinatorialPurgedCV(10,2)")
    mlflow.log_param("feature_set_hash", feature_set_hash)       # so re-used feature sets don't double count
    mlflow.log_metric("oos_sharpe_median", oos_sharpe_median)    # across the CPCV path distribution
    mlflow.log_metric("pbo", pbo_value)
    mlflow.log_metric("trial_number_in_family", trial_counter)   # THIS feeds the Deflated Sharpe N
    mlflow.lightgbm.log_model(model, "model")

# Query the full run history to compute N for the Deflated Sharpe Ratio -- include prior
# Pine-Script optimization trials too (see §14), not just the ML runs.

Au-delà des hubs de modèles, le Datasets Hub de Hugging Face abrite un ensemble croissant de jeux de données pertinents pour la finance, qui valent la peine d'être connus pour le prototypage et le travail sur le sentiment — traitez-les tous comme des sources de prototypage/de secours, pas comme des données de production sans biais de survie (voir la discipline du Plan de Données dans le rapport de recherche source).

Numerai — un autre jeu, pas une source de données pour votre propre système

Numerai se comprend mieux comme un marché de compétences en modélisation, et non comme un jeu de données à brancher sur votre propre pipeline. Le tournoi principal fournit gratuitement des caractéristiques pré-ingénierées et obfusquées — passées en PCA, z-scorées et découpées dans le temps — pour que vous puissiez modéliser des données financières de classe mondiale sans jamais savoir quelles actions ou quelles dates vous regardez (chaque « ère » hebdomadaire a des ID qui ne se correspondent pas d'une ère à l'autre, par conception). Numerai Signals est le produit complémentaire : vous soumettez des prédictions sur votre propre univers/caractéristiques, en visant des signaux orthogonaux à ce que la pile de modèles existante de Numerai capture déjà. Tous les modèles soumis alimentent un méta-modèle pondéré par le stake qui pilote à son tour le propre hedge fund de Numerai. Cadrez-le comme une optionnalité pour monétiser une compétence de modélisation — évaluée sur une performance pluriannuelle incluant le drawdown, pas comme une voie rapide vers un revenu — et comme un écosystème adjacent intéressant plutôt qu'un composant du pipeline du §14.

Comment un utilisateur avancé raccorde chaque bibliothèque ci-dessus en un seul pipeline, de bout en bout. Ingestion des données → caractéristiques Qlib/tsfresh → différenciation fractionnaire (mlfinpy) → modèle de méta-étiquette LightGBM validé par validation croisée purgée combinatoire imbriquée (skfolio) → garde-fou de régime causal hmmlearn → dimensionnement ciblé en vol basé sur GARCH (arch) → backtest NautilusTrader → journalisation MLflow → webhook PickMyTrade pour l'exécution.

"""
Reference pipeline skeleton: data ingestion -> PickMyTrade execution.
Every preprocessing step is fit INSIDE the CPCV training fold only -- never on
the full dataset. Illustrative structure; wire in your own data store / config.
"""
import numpy as np
import pandas as pd
import lightgbm as lgb
import mlflow
import requests
from hmmlearn.hmm import GaussianHMM
from arch import arch_model
from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol
from mlfinpy.features import frac_diff_ffd
from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
from qlib.contrib.data.handler import Alpha158
from tsfresh import extract_relevant_features
from nautilus_trader.backtest.engine import BacktestEngine
from nautilus_trader.trading.strategy import Strategy


# 1. DATA INGESTION -- point-in-time, survivorship-bias-free universe only
def load_point_in_time_universe(as_of_date, min_adv_usd=2_500_000):
    """Never filter by TODAY's liquidity -- that imports survivorship bias."""
    raw = data_store.query_asof(as_of_date=as_of_date)          # Parquet/DuckDB store
    return raw[raw["adv_20d_asof"] > min_adv_usd]


# 2. FEATURES -- Qlib Alpha158 for technicals, tsfresh + mlfinpy for the rest
def build_features(prices: pd.DataFrame) -> pd.DataFrame:
    alpha158 = Alpha158(instruments=prices["symbol"].unique().tolist(),
                         start_time=prices.index.min(), end_time=prices.index.max())
    tech_features = alpha158.fetch()

    tsfresh_features = extract_relevant_features(
        prices.reset_index(), y=None, column_id="symbol", column_sort="date", fdr_level=0.01,
    )

    d = find_min_ffd_order(prices["close"], adf_pvalue=0.05, min_corr=0.9)   # search d in [0.1, 1.0]
    frac_diff_price = frac_diff_ffd(prices["close"], d=d, threshold=1e-4)    # stationary, RETAINS memory

    return tech_features.join(tsfresh_features, how="inner").assign(frac_diff_price=frac_diff_price)


# 3. LABELS -- causal EWMA vol -> ATR-scaled triple barrier (mlfinpy)
def label_events(prices: pd.Series, signal_dates: pd.DatetimeIndex) -> pd.DataFrame:
    daily_vol = get_daily_vol(close=prices, lookback=50)
    vertical_barriers = add_vertical_barrier(t_events=signal_dates, close=prices, num_days=10)
    events = get_events(close=prices, t_events=signal_dates, pt_sl=[2.0, 1.5], target=daily_vol,
                         min_ret=0.0005, num_threads=4, vertical_barrier_times=vertical_barriers)
    return get_bins(events, prices)          # -> bin (0/1), ret, t1 (needed for purging)


# 4. META-LABEL MODEL -- LightGBM inside nested Combinatorial Purged CV
def train_meta_label_model(X: pd.DataFrame, y: pd.Series, w: pd.Series, trial_counter: int):
    pipeline = Pipeline([("model", lgb.LGBMClassifier(
        num_leaves=31, learning_rate=0.03, min_child_samples=50,
        monotone_constraints=MONO_CONSTRAINTS))])

    cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2, purged_size=10, embargo_size=10)
    oos_paths = cross_val_predict(estimator=pipeline, X=X, y=y, cv=cv, sample_weight=w)

    pbo = compute_pbo(oos_paths)
    dsr = compute_deflated_sharpe(oos_paths, n_trials=get_trial_count_from_mlflow() + trial_counter)
    if pbo > 0.50 or dsr.p_value > 0.05:
        raise ValueError(f"Model rejected: PBO={pbo:.2f}, DSR p={dsr.p_value:.3f}")

    final_model = pipeline.fit(X, y, model__sample_weight=w)
    return final_model, pbo, dsr


# 5. REGIME GATE -- causal, walk-forward, FILTERED (never smoothed) HMM posterior
def causal_regime_state(vol_return_features: np.ndarray, t: int, model_cache: dict,
                         refit_every: int = 63, min_train: int = 500) -> int:
    if t < min_train:
        return 1  # default "calm" until enough history exists
    if t % refit_every == 0 or "model" not in model_cache:
        hmm = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        hmm.fit(vol_return_features[:t])                       # only data strictly before t
        model_cache["model"] = hmm
    posteriors = model_cache["model"].predict_proba(vol_return_features[: t + 1])
    return int(posteriors[-1].argmax())                        # filtered state at t, no look-ahead


# 6. VOL-TARGETED SIZING -- GJR-GARCH forecast -> fractional-Kelly-scaled size
def size_position(returns_pct: pd.Series, meta_label_confidence: float, regime_state: int,
                   target_vol_annual: float = 0.10, kelly_fraction: float = 0.5,
                   max_leverage: float = 1.5) -> float:
    if regime_state == 0:                                       # 0 = "stormy" -- stand aside
        return 0.0
    res = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t").fit(disp="off")
    vol_fc = np.sqrt(res.forecast(horizon=1, reindex=False).variance.values[-1, 0]) / 100
    vol_scale = (target_vol_annual / (252 ** 0.5)) / vol_fc
    kelly_scale = kelly_fraction * max(2 * meta_label_confidence - 1, 0)   # confidence -> edge proxy
    return float(np.clip(vol_scale * kelly_scale, 0, max_leverage))


# 7. BACKTEST -- NautilusTrader (same strategy class runs backtest AND live)
class MetaLabelStrategy(Strategy):
    def __init__(self, model, hmm_cache, config):
        super().__init__(config)
        self.model, self.hmm_cache = model, hmm_cache

    def on_bar(self, bar):
        feats = self.build_live_features(bar)                   # same code path as build_features()
        confidence = self.model.predict_proba(feats)[:, 1][0]
        regime = causal_regime_state(self.vol_history, self.clock.timestamp_ns, self.hmm_cache)
        size = size_position(self.returns_pct_history, confidence, regime)
        if confidence > 0.55 and size > 0:
            self.submit_bracket_order(side="BUY", size=size, sl_atr_mult=1.5, tp_atr_mult=2.0)


def run_backtest(historical_bars, final_model, strat_config):
    engine = BacktestEngine()
    engine.add_data(historical_bars)
    engine.add_strategy(MetaLabelStrategy(model=final_model, hmm_cache={}, config=strat_config))
    return engine.run()      # the SAME strategy object later promotes to paper/live -- adapters swap only


# 8. MLFLOW LOGGING -- every trial, forever (feeds the Deflated Sharpe trial count)
def log_run(params, pbo, dsr, backtest_results, final_model, trial_counter):
    with mlflow.start_run(run_name=f"pipeline_v{trial_counter}"):
        mlflow.log_params(params)
        mlflow.log_metric("pbo", pbo)
        mlflow.log_metric("dsr_p_value", dsr.p_value)
        mlflow.log_metric("backtest_sharpe", backtest_results.sharpe_ratio)
        mlflow.log_metric("backtest_max_dd", backtest_results.max_drawdown)
        mlflow.log_metric("trial_number_in_family", trial_counter)
        mlflow.lightgbm.log_model(final_model, "meta_label_model")


# 9. EXECUTION -- PickMyTrade webhook JSON (paper first, then tiny live)
def send_to_pickmytrade(symbol, side, qty, sl_price, tp_price, webhook_url, secret):
    payload = {
        "secret": secret, "symbol": symbol, "action": side,     # "buy" / "sell"
        "quantity": qty, "stopLoss": sl_price, "takeProfit": tp_price, "orderType": "market",
    }
    resp = requests.post(webhook_url, json=payload, timeout=5)
    resp.raise_for_status()
    return resp.json()

Claude Fable est le modèle de pointe d'Anthropic (id de modèle claude-fable-5), disponible via l'app Claude et Claude Code. Sur une stack aussi profonde, sa valeur n'est pas « écris-moi un bot de trading » — c'est le milieu ingrat et sujet aux erreurs : réussir l'arithmétique des folds de CPCV, écrire une boucle de décodage HMM causale (pas fuyante) du premier coup, câbler un gestionnaire de données Qlib pour un marché non livré en standard, et lire un pipeline multi-étapes de bout en bout pour trouver l'unique fuite qui, sinon, ne referait surface que comme un écart réel/backtest des mois plus tard.

Là où il gagne sa place sur la stack spécifique de cette page :

• Logique des folds de CPCV — dériver les tailles de purge/embargo à partir de l'horizon de votre étiquette et du lookback de caractéristique le plus lent (§7), au lieu de les deviner et de le découvrir via un Sharpe de backtest gonflé.
• Inférence de régime causale — écrire la boucle walk-forward à posterior filtrée au lieu de l'appel fuyant à decode()/Viterbi sur échantillon complet montré comme exemple « faux » au §8.
• Configuration Qlib — générer et adapter le YAML de workflow Alpha158/Alpha360 à un gestionnaire de données personnalisé pour une région que Qlib ne livre pas, comme l'exemple NSE au §6.
• Revue de fuites sur tout le pipeline — lire le squelette du §14 étape par étape pour un bug d'ajustement hors du fold avant qu'il ne touche du capital.
• Conversion Pine Script → Python — porter la logique d'entrée d'une stratégie TradingView dans la fonction de signal primaire qui alimente le modèle de méta-étiquetage.
• Colle d'exécution — rédiger le code du payload de webhook/de la clé d'idempotence couvert au §14.6, et la journalisation MLflow qui garde honnête votre décompte d'essais du Deflated Sharpe (§12).

Des prompts prêts à adapter pour chacun de ces cas — spécifiques à la stack de cette page, pas des demandes génériques de « construis-moi un bot » :

Review this skfolio CombinatorialPurgedCV setup [paste code]: 10 folds, 2 test folds, on triple-barrier-labeled
signals where barriers can resolve up to 10 trading days after the signal (get_events num_days=10). Check whether
purged_size and embargo_size are large enough to cover that full label-resolution window plus my slowest feature's
lookback. Flag any fold where a training sample's resolution window overlaps a test sample's, explain the leak, and
give me corrected purge/embargo values with the reasoning shown.

Here is my hmmlearn regime-detection code [paste code]. Confirm it only calls predict_proba on data up to and
including index t when producing the label used AT time t, and that it never calls hmm.decode() or reads a Viterbi
path computed over the full series. If it's using the full-sample smoothed posterior, rewrite it as a walk-forward
loop that refits every N bars on strictly past data and returns the filtered (not smoothed) posterior at each step,
matching the causal pattern, not the leaky one.

I want Microsoft Qlib's Alpha158 handler running on NSE (India) equities, not one of Qlib's built-in regions.
Here's my current workflow YAML [paste config]. Write a custom data handler/provider that points Alpha158's feature
computation at my own point-in-time OHLCV store instead of Qlib's default region data, keeping the Alpha158 feature
set intact. Explain specifically what breaks -- calendar, instrument universe, trading-day alignment -- if I just
change the region tag without supplying compatible replacements.

Here is my end-to-end pipeline: data ingestion, feature engineering, triple-barrier labeling, LightGBM meta-label
training inside CombinatorialPurgedCV, HMM regime gate, GARCH-based sizing, and NautilusTrader backtest [paste code].
Walk it stage by stage and flag every point where a transform -- scaler, feature selector, frac-diff order search, HMM
fit -- is fit on data outside the current CV training fold, or a feature could see information unavailable at signal
time. Rank findings by how much each would inflate the backtest Sharpe if left uncorrected.

Here is my TradingView Pine Script strategy [paste script]. Convert its entry logic into a Python function that
takes a pandas DataFrame of OHLCV bars and returns a boolean signal series, matching the Pine version bar-for-bar on
identical historical data. This becomes the primary-model signal feeding my meta-labeling filter, so flag anything --
security() calls with lookahead, use of the current bar's close before it closes -- that would make the two versions
diverge.

Write a Python function that takes a meta-label confidence score, ATR-based stop/target multiples, and a
position size from my vol-targeted sizing calc, and builds the JSON payload for a PickMyTrade webhook POST -- symbol,
side, quantity, stopLoss, takeProfit. Add a deterministic idempotency key (hash of symbol + signal timestamp + bar
index) as a payload field, and wrap the POST in retry-with-backoff logic that treats a timeout as "unknown, reconcile
before retrying" rather than blindly resubmitting.

La même décision construire vs. acheter que prend toute équipe systèmes, appliquée au dernier saut du pipeline du §14 : vos rares heures d'ingénierie vont-elles à la tuyauterie de routage d'ordres, ou aux couches de modèle qui sont réellement les vôtres ? Cette section plaide pour traiter l'exécution en direct comme une dépendance achetée à interface étroite — et montre à quoi ressemble l'interface côté pipeline.

Où cela se situe dans le pipeline du §14

Le pipeline de référence se termine à « journalisation MLflow → webhook PickMyTrade pour l'exécution » parce que c'est la frontière de confiance naturelle. Votre modèle émet un signal → une alerte TradingView se déclenche, ou — puisqu'une configuration avancée peut contourner TradingView entièrement — votre propre service Python construit et POST le JSON directement vers le endpoint webhook de PickMyTrade → PickMyTrade prend en charge le placement des brackets OCO, la traduction d'ordres spécifique au courtier, le fan-out multi-comptes et la boucle de reconnexion/réessai face à la place vers laquelle vous acheminez. Cette division du travail signifie que votre service n'a qu'à être fiable jusqu'à « envoyer un seul POST HTTP idempotent » — il n'a jamais à maintenir une connexion à état, sur plusieurs semaines, à l'API de session d'un courtier, à rafraîchir des tokens d'authentification selon un planning, ni à réconcilier l'état des ordres après une partition réseau. Toute cette catégorie de problème quitte votre assiette.

{
  "idempotencyKey": "SIG-MES-2026-07-03T14:32:00Z-000481",
  "symbol": "MES",
  "side": "buy",
  "quantity": 2,
  "orderType": "market",
  "stopLoss": 5320.25,
  "takeProfit": 5364.75,
  "meta": {
    "metaLabelConfidence": 0.62,
    "atr14": 14.8,
    "slAtrMult": 1.5,
    "tpAtrMult": 2.0,
    "regimeState": 1
  }
}

Délibérément générique — ce n'est pas un schéma PickMyTrade vérifié (voir l'appel fonctionnel send_to_pickmytrade() au §14 pour les noms de champs déjà utilisés dans le pipeline de référence de cette page). quantity provient directement du calcul de dimensionnement ciblé sur la volatilité des §11/§14 ; stopLoss/takeProfit correspondent à l'entrée ± ATR × les multiples de barrière déjà validés dans le labeling en triple barrière (§7) ; idempotencyKey — absent de l'exemple minimal du §14 — est ce qui transforme une livraison de webhook « au moins une fois » en un ordre « effectivement une seule fois ».

Une table de correspondance unique pour « j'ai besoin de… → utilisez ceci → parce que… ».

Chaque outil et modèle abordé sur cette page, avec sa licence et un indicateur clair. Sûr = permissif, sans restriction notable pour un usage commercial ou de trading en réel. Prudence = utilisable, mais lisez les conditions (obligations de copyleft, clauses de code disponible mais restreint, ou préoccupation liée à l'état de maintenance plutôt qu'à la licence). Restreint = un véritable obstacle pour un système commercial ou en réel sans restriction, en l'absence d'un accord distinct.

↑ Retour en haut