Alignement avec TradingView

Whale‑E reprend, quand c’est possible, les mêmes conventions de calcul et de backtest que TradingView. L’objectif n’est pas de promettre une identité absolue dans tous les cas, mais de conserver un comportement cohérent et déterministe du moteur. A paramètres et contexte équivalents, vous obtenez donc généralement les mêmes signaux, les mêmes trades et les mêmes résultats, sous réserve des limites documentées sur cette page.

Ce que couvre l’alignement avec TradingView#

L’alignement avec TradingView signifie que Whale‑E reproduit les mêmes calculs de stratégie et les mêmes règles principales de backtest lorsque le cadre de test est équivalent.

Cela suppose au minimum le même symbole, le même exchange, le même timeframe, la même période analysée et les mêmes paramètres de stratégie. Si un seul de ces éléments change, les résultats peuvent diverger.

Une partie du bloc [backtest] correspond directement aux paramètres utilisés par TradingView dans la déclaration strategy() et dans les réglages du Strategy Tester. Lors de l’export Pine Script, Whale‑E reporte ces paramètres dans le script généré.

Les paramètres de strategy() qui ne figurent pas dans ce tableau ne sont pas configurables dans Whale‑E et ne sont pas exportés dans le Pine Script généré. Tant que ces paramètres restent à leur valeur par défaut dans TradingView, ils ne remettent pas en cause l’alignement.

Paramètres du backtest propres à Whale‑E#

Certains paramètres n’ont pas d’équivalent direct dans TradingView.

auto_slippage_enabled active un mode de slippage propre à Whale‑E. Dès qu’il est utilisé, l’objectif n’est plus un alignement strict avec TradingView, car TradingView ne propose pas ce mécanisme.

long_size_multiplier et short_size_multiplier ne font pas partie des paramètres natifs de TradingView. En revanche, Whale‑E sait reproduire leur effet dans le Pine Script exporté grâce à la logique générée. Leur utilisation reste donc compatible avec l’alignement.

Le comportement de fin de backtest contrôlé par close_open_position_at_end est détaillé dans la section suivante.

Valorisation des positions ouvertes en fin de backtest#

A la fin d’un backtest, une position peut rester ouverte. Il faut alors choisir jusqu’où cette position est valorisée pour calculer l’état final du portefeuille.

Dans Whale‑E, close_open_position_at_end contrôle cette borne de valorisation. Ce paramètre vaut true par défaut. Il applique la convention de fin de backtest du moteur pour produire un état final borné et comparable d’une exécution à l’autre. Il ne modifie ni les signaux, ni les entrées, ni les sorties produites pendant le backtest. Il agit uniquement sur la valorisation finale des positions, ou des jambes, encore ouvertes à la fin du test.

Lorsque close_open_position_at_end = false, Whale‑E arrête la valorisation à end_date. Les trades exécutés pendant le backtest restent identiques, mais les métriques finales peuvent changer, car les positions encore ouvertes ne sont plus valorisées au-delà de cette date.

Exemple : si votre backtest s’arrête au 31 janvier et qu’un long est encore ouvert à cette date, Whale‑E peut figer l’Open P&L au 31 janvier alors que TradingView continue à le faire varier avec les bougies encore chargées sur le graphique.

TradingView travaille sur un historique borné, mais peut continuer à valoriser une position ouverte jusqu’à la dernière bougie disponible sur le graphique. Whale‑E, dans ce mode, fige explicitement l’état final à end_date. Si des positions restent ouvertes à la fin du test et que close_open_position_at_end = false, Whale‑E et TradingView peuvent donc afficher des métriques finales différentes, alors même que les signaux, les entrées, les sorties et les trades exécutés sont alignés.

La différence porte d’abord sur l’Open P&L. Elle affecte aussi le Total P&L et certaines métriques calculées à partir de l’equity, notamment le max equity drawdown et le max equity run-up. En revanche, les métriques fondées uniquement sur les trades clôturés, comme le Net P&L ou Total trades, ne changent pas.

Dans quels cas un écart peut apparaître#

Un écart entre Whale‑E et TradingView ne signifie pas forcément qu’un des deux moteurs calcule mal. Dans plusieurs cas, la différence vient simplement du cadre de test ou d’une limite propre à Whale‑E ou à TradingView. Whale‑E reste aligné quand c’est possible, mais il ne modifie pas sa sémantique d’exécution uniquement pour contourner une contrainte extérieure au moteur.

Les causes les plus fréquentes sont les suivantes :

• le symbole, l’exchange, le timeframe ou la période analysée ne sont pas exactement les mêmes
• le mode « Deep Backtesting » de TradingView suit ses propres règles de fenêtrage et peut produire des écarts avec Whale‑E
• TradingView ne charge pas toujours autant d’historique que Whale‑E ; la quantité d’historique disponible dépend notamment du type de compte TradingView, alors que Whale‑E peut exploiter l’intégralité de l’historique fourni par l’exchange
• avec le Bar Magnifier, TradingView limite la quantité de données intrabar exploitables sur le timeframe inférieur, contrairement à Whale‑E
• les valeurs de prix utilisées par TradingView peuvent différer légèrement de celles fournies par l’exchange utilisé par Whale‑E
• les contraintes de marché, notamment mincontract et mintick, peuvent être différentes entre TradingView et Whale‑E ; la section suivante détaille ce point
• le mode de slippage automatique de Whale‑E, activé avec auto_slippage_enabled, n’a pas d’équivalent dans TradingView
• les ratios de Sharpe et de Sortino ne cherchent pas à reproduire TradingView ; Whale‑E les calcule à partir des rendements de l’equity du portefeuille, observés à chaque clôture du timeframe natif du backtest, puis les annualise pour comparer des tests exécutés sur des timeframes différents
• le Buy‑and‑Hold peut différer entre TradingView et Whale‑E, car Whale‑E le calcule sur la période de backtest définie, et non sur l’ensemble de l’historique chargé par le graphique.

Désalignement possible sur mincontract et mintick#

Un désalignement peut apparaître lorsque Whale‑E et TradingView n’utilisent pas les mêmes contraintes de marché, en particulier mincontract et mintick. Par défaut, Whale‑E reprend les valeurs fournies par l’exchange. TradingView peut, pour certains symboles, appliquer des valeurs différentes.

Ce décalage change la quantité réellement exécutable. Il peut ensuite modifier l’entrée ou la sortie de certaines positions, provoquer des margin calls partiels différents et décaler toute la suite du PnL ainsi que la séquence des trades.

Sur OKX:BTCUSDT, par exemple, Whale‑E utilise mincontract = 0.00000001, qui correspond à la valeur de l’exchange, alors que TradingView utilise mincontract = 0.000001. L’arrondi de quantité ne se fait donc pas au même niveau, et cet écart initial peut suffire à décaler tout le backtest.

Quand vous exécutez dans TradingView un script Pine exporté par Whale‑E, un libellé orange peut apparaître en haut à droite du graphique. Whale‑E exporte les paramètres de marché utilisés pendant le backtest, à savoir mincontract, mintick et pointvalue. Si TradingView applique d’autres valeurs pour le même symbole, ce libellé signale un risque de désalignement.

Dans ce cas, Whale‑E permet de forcer les paramètres du symbole avec [[symbol_override]] :

[[symbol_override]]
symbol      = "OKX:BTCUSDT"
mincontract = 0.000001

Sans override, Whale‑E conserve les paramètres de l’exchange. Avec [[symbol_override]], il applique les valeurs que vous définissez. Cela permet, sur les symboles concernés, de reproduire les contraintes de marché utilisées par TradingView.

Sur les marchés crypto spot, le décalage vient surtout de mincontract et parfois de mintick. pointvalue vaut généralement 1 et intervient beaucoup plus rarement.

Ecart de calcul des ratios de Sharpe et de Sortino avec TradingView#

Dans Whale‑E, ces deux ratios servent d’abord à comparer et à classer des résultats d’optimisation. Ils sont calculés à partir des rendements de l’equity du portefeuille, observés à chaque clôture du timeframe natif du backtest.

Whale‑E annualise ensuite ces ratios afin de comparer de manière cohérente des stratégies exécutées sur des timeframes différents. TradingView applique sa propre méthode de calcul, notamment à partir de rendements mensuels. Un écart sur ces deux métriques est donc normal, même lorsque les trades et le PnL sont alignés.

Pour la spécification détaillée, voir Métriques.

Ecart de calcul du Buy‑and‑Hold avec TradingView#

TradingView et Whale‑E ne mesurent pas le Buy‑and‑Hold sur la même fenêtre.

TradingView calcule le Buy‑and‑Hold depuis l’achat du premier trade de la stratégie jusqu’à la dernière bougie disponible sur le graphique, tandis que Whale‑E le calcule du début à la fin de la période de backtest sélectionnée.

Whale‑E travaille sur une fenêtre strictement délimitée. TradingView, hors mode « Deep Backtesting », s’appuie sur les bougies effectivement chargées par le graphique. Le mode « Deep Backtesting » suit d’autres règles et Whale‑E n’est pas aligné avec lui.

Pour ce calcul, Whale‑E compare uniquement le prix de début et le prix de fin de sa propre fenêtre de référence. Les frais, le slippage, les arrondis d’exécution et le floor de quantité n’entrent pas dans ce calcul.

Le pourcentage correspond à la variation relative du prix entre ces deux bornes. La valeur en montant est ensuite dérivée de ce ratio à partir du capital initial. Whale‑E reste donc cohérent avec une lecture benchmark du Buy‑and‑Hold, tout en conservant sa propre fenêtre de backtest.