BTCUSDT.BINANCE Perp 4H Suivi de tendance long uniquement fondé sur le déséquilibre des flux d’achat/vente des takers (3 paramètres, confluence flux d’ordres + tendance, signal agrégé à partir des ticks uniquement)

Stratégie de suivi de tendance long-only sur actif unique sur le perp BTCUSDT.BINANCE en utilisant des barres de 4H, avec le signal directionnel piloté par AGGREGATED TAKER ORDER FLOW (à partir des données supplémentaires trade_ticks) plutôt que par des indicateurs dérivés du prix (qui ont été testés de manière exhaustive et échouent largement empiriquement selon le journal d'abandon de cette session). Il s'agit d'une classe de mécanisme véritablement NEW pour le portefeuille de la factory — chaque stratégie antérieure que j'ai examinée utilise des signaux dérivés de OHLCV (niveaux de prix, moyennes mobiles, rendements, volatilité, ratios). Le déséquilibre taker-buy/taker-sell est INFORMATIONALLY DISTINCT du prix : il mesure WHO prend la liquidité (acheteurs agressifs vs vendeurs agressifs), ce que la littérature académique sur la microstructure (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) a établi comme prédictif là où le prix seul ne l'est pas. Mécanisme : à chaque clôture de barre de 4H, agréger les ticks de trade de la barre en taker_buy_volume vs taker_sell_volume, calculer le déséquilibre = (achat - vente) / (achat + vente). LONG lorsque le déséquilibre sur 4H > +0.05 (taker buying soutenu) AND prix > 100-bar SMA (confluence de tendance — le flux doit être en accord avec la tendance). Sortir lorsque le déséquilibre bascule en négatif OR le prix passe sous SMA. Les signaux de flux d'ordres ont un profil statistique fondamentalement différent de celui des signaux de momentum sur prix qui ont échoué : ils observent directement AGENT BEHAVIOR (quel côté est prêt à payer le spread) plutôt que INFERRING le comportement de l'agent à partir du prix (qui est la conséquence retardée du comportement). Seulement 3 paramètres (bien en dessous du plafond de 5 paramètres). Fréquence de trading : ~40-80 trades/an sur 6+ années de données de ticks de trade Binance → 240-480 trades au total → 16-32 OOS trades par fenêtre walk-forward, confortablement au-dessus du plancher de 5 trades. Il s'agit également d'un INFRASTRUCTURE TEST critique : si les données trade_ticks se chargent correctement dans le pipeline de la factory (le data_specification.md les liste sous catalog_data_types et le flag subscribe_trade_ticks existe), cela ouvre une toute nouvelle classe de mécanisme pour la recherche future. Si elles ne se chargent pas (similaire au manque de funding rate HL qui a bloqué les stratégies 9), l'échec lui-même est informatif et fait émerger un ticket d'infrastructure qui mérite d'être déposé.

Les retours exigeaient un DIAGNOSTIC, pas une nouvelle supposition sur le schéma. J’ai interrogé directement data/supplementary/metrics/BTCUSDT/*.parquet : 334,643 lignes, colonne taker_long_short_vol_ratio, horodatage en ms ; lignes par an : 2023=12,096 / 2024=16,990 / 2025=14,688, et le mois EVERY 2023-01..2025-12 compte >= 288 lignes (continu, simplement clairsemé par rapport aux données denses à 5 minutes 2020-2022). La condition (3) « les lignes n’existent pas -> ouvrir un ticket » est donc fausse, tout comme la prémisse de la condition (2) selon laquelle le schéma du chargeur serait incompatible (mon chargeur lit déjà exactement cette colonne et cette clé d’horodatage). La véritable cause racine se trouvait en aval, dans mon propre code : la limite de péremption de 24h de _taker_imbalance. J’ai validé hors ligne sur le véritable entrepôt Parquet en parcourant des barres synthétiques de 4H sur 2023-2025 : la limite de 24h ne marque que 24.9% des barres avec un signal de preneur (après les filtres imbalance>0.05 et price>SMA, cela tombe à l’exposition observée d’environ 2.79%), tandis qu’une limite de 14 jours en marque 95.3% — chaque fenêtre de walk-forward de 3 pourra donc contenir des transactions. La fonction _taker_imbalance reporte déjà le ratio le plus proche antérieur ou égal lorsque la fenêtre glissante de 4h est vide ; seule la limite le rejetait. La correction consiste donc en un seul paramètre (max_lag_hours=336), sans changement de ZERO au signal, à l’entrée/sortie ou au dimensionnement, ni solution de repli fondée sur les prix (NO). Le mécanisme de flux d’ordres reste intact et peut enfin être testé sur toute la période du backtest. Remarque pour l’analyste : la couverture des preneurs de 2023-2025 est réellement plus faible que celle de 2020-2022 (environ 12% de la densité à 5 minutes), donc le signal reporté est plus grossier durant ces années ; reconstituer des métriques denses à 5 minutes pour 2023-2025 améliorerait la fidélité, mais la série est assez continue d’un mois à l’autre pour valider le walk-forward dès maintenant.

Échec du Sharpe corrigé, avec une probabilité de surajustement extrême lors de la tentative 1. DSR=0.3175 (contre le seuil de 0.95), is_significant=FALSE, le Sharpe optimisé 1.9615 BELOW le seuil de chance correspondant au maximum attendu sur 225 essais, soit 2.3078, et — de façon décisive — PBO=0.8664 (probabilité de 87% que la sélection des paramètres soit surajustée). Selon le cadre, un DSR faible combiné à un PBO très élevé justifie l’abandon. Le walk-forward le confirme : is_overfitted=TRUE, avec une moyenne de IS 3.91 qui s’effondre à une moyenne de OOS 0.962, et OOS fenêtres [2.76, 1.32, -1.19] (dont une négative). Le probabilistic_sharpe élevé (0.9964) est le piège classique PSR-contre-DSR — il ignore la sélection sur 225 essais que PBO/DSR pénalisent. Les vrais points positifs (0 seuils de sensibilité, sharpe_ci_low +0.4252 positif, ratio de holdout véritablement validé de 1.213) mesurent la stabilité locale et une fenêtre prospective favorable, pas la significativité, et ne peuvent pas l’emporter sur un 87% PBO avec un Sharpe sélectionné inférieur au seuil de chance. Ne pas itérer (tentative 1 sur 2, déjà à l’itération 3) : la sensibilité est déjà nette, avec 0 seuils, donc le balayage a entièrement exploré la région stable, mais OOS s’effondre toujours et PBO est 0.87 — le surajustement vient du SELECTION du walk-forward sur 225 essais, pas d’un seuil corrigeable ; avec seulement 3 paramètres fondamentaux, un deuxième balayage meilleur parmi -225 retrouverait les mêmes configurations surajustées. Ne pas revise_hypothesis : le déséquilibre du flux des preneurs est un mécanisme testé pour la première fois, sans stratégie sœur promue bloquée sur une cible morte ; rien ne prouve qu’il faille le réorienter vers un nouvel instrument. Mise en garde supplémentaire (cause racine non confirmée) : le signal de « flux d’ordres » est dérivé de la série clairsemée de métriques taker_long_short_vol_ratio, avec report en avant des valeurs jusqu’à 14 jours plutôt qu’à partir des transactions brutes. Durant les périodes clairsemées de 2023-2025, il peut donc s’agir d’un instantané unique reporté jusqu’à deux semaines — se dégradant en un indicateur retardé, peu informatif, et fragilisant l’hypothèse selon laquelle il est « informationnellement distinct du prix » ; combinés au suivi de tendance BTC long uniquement dans un échantillon de 6 ans fortement haussier (alpha de base 0.02, benchmark_correlation 0.30), ces facteurs signifient qu’une grande part du rendement peut être du bêta. FAILURE PATTERN : un mécanisme de flux d’ordres véritablement novateur, au profil exceptionnellement net (0 seuils de sensibilité, Sharpe positif proche de zéro (CI), holdout validé), peut malgré tout être un surajustement du meilleur résultat parmi -225 essais — ici, PBO 0.8664 avec DSR 0.32 et un Sharpe optimisé (1.96) inférieur au seuil de chance de 2.31, auxquels s’ajoute un walk-forward is_overfitted avec une fenêtre négative de OOS, sont décisifs. Une grille de sensibilité nette et une seule fenêtre de holdout favorable ne NOT sauvent pas une optimisation dont la sélection est 87% probablement surajustée ; la nouveauté et la stabilité locale ne sont pas des preuves de significativité statistique.

Ne pas optimiser NOT — le signal de flux des takers présente une lacune structurelle dans les données 2023-2025 (les transactions n’existent que dans 2020-2022 et 2026 ; annual_returns ignore 2023/2024/2025 ; exposure_pct 2.79%), de sorte qu’un walk-forward sur 3 fenêtres s’exécuterait sur une fenêtre entière sans données et que l’avantage du flux d’ordres ne peut pas être validé. La modification du chargeur tolérant au schéma de l’itération 2 n’a NOT comblé la lacune ; l’étape suivante est donc un diagnostic, pas une nouvelle hypothèse sur le schéma : (1) Interroger directement le catalogue/le magasin supplémentaire et confirmer si les lignes de volume d’achat/vente des takers `metrics` (ou taker_long_short_vol_ratio) PHYSICALLY EXIST pour BTCUSDT 2023-01 à 2025-12. Afficher le nombre de lignes et les noms réels des colonnes/clés d’horodatage pour un échantillon 2024. (2) Si les lignes existent sous un autre schéma encore (nom de colonne ou de clé d’horodatage que votre chargeur ne reconnaît toujours pas), étendre `_row_ratio`/`_row_ts`/`_load_taker_flow` pour les lire et relancer ; confirmer que exposure_pct augmente et que les transactions remplissent 2023-2025. (3) Si les lignes n’existent NOT (la série de takers des métriques n’a jamais été collectée/rétroalimentée pour ces années), il s’agit d’un problème d’infrastructure/de collecte de données, exactement comme le prévoyait l’hypothèse — le code de la stratégie ne peut pas y remédier ; il faut donc créer un ticket de collecte de données pour les métriques de flux des takers sur plusieurs années et DO NOT soumettre cette stratégie à l’optimisation avant que les données couvrent toute la période du backtest. L’optimisation ne vaut la peine qu’une fois que la série de flux des takers couvre 2020-2026 de façon continue ; le mécanisme est prometteur, mais actuellement impossible à tester.