Tradovate : seulement ~300 barres chargées au démarrage de l'indicateur

Vous ajoutez un indicateur personnalisé à un graphique Tradovate et, au lieu de traiter tout votre historique, il ne voit que quelques centaines de barres. Consignez le nombre de barres depuis l'indicateur et vous le constaterez : environ 300 barres sur un contrat comme ES ou MES, un peu plus peut-être sur un autre, loin des milliers que vous attendiez. Tout ce qui demande une rétrospective plus profonde, une longue moyenne mobile, une ancre de session, une fenêtre glissante, est soit faux, soit vide jusqu'à ce que vous fassiez défiler manuellement le graphique pour récupérer davantage de données. Le plus frustrant, c'est que les données sont disponibles. Le graphique ne les a simplement jamais demandées avant que votre indicateur ne commence à calculer. Tout se règle dans les paramètres du graphique de Tradovate, et la mise en place prend environ deux minutes, une seule fois.

Ce que signifie réellement « barres limitées au démarrage de l'indicateur »

Il n'y a pas de fenêtre d'erreur pour celui-ci. Rien ne devient rouge. Le symptôme est plus discret et plus facile à manquer : votre indicateur se dessine, mais il calcule sur une fraction de l'historique que vous croyez avoir. Si vous affichez la longueur de la série de barres au chargement de l'indicateur, le nombre obtenu est faible, souvent autour de 300, parfois plus proche de 1000 sur un autre contrat, et il est incohérent d'un symbole à l'autre alors que la disponibilité des données est la même.

Voici le mécanisme. Lorsque vous ouvrez un nouvel onglet de graphique, Tradovate règle Minimum Number of Bars to Load sur sa valeur par défaut de 100. C'est le plancher de l'historique que le graphique récupère avant l'affichage. Votre indicateur s'initialise sur ce que le graphique a chargé à cet instant. Si le graphique n'a préchargé qu'une mince tranche, l'indicateur se met en route sur cette mince tranche, point final. Il ne va pas en chercher davantage de lui-même. Les barres supplémentaires n'arrivent que lorsque vous faites physiquement défiler le graphique vers la gauche, et à ce moment-là l'indicateur a déjà effectué son calcul initial sur trop peu de données.

C'est pourquoi cela touche le plus durement les indicateurs personnalisés et à longue rétrospective. Une étude courte qui n'a besoin que de 20 ou 30 barres en arrière paraîtra correcte sur 300. Mais une moyenne sur 200 périodes, un VWAP ancré au début de la session, ou tout calcul de fenêtre statistique glissante sur un grand échantillon, manque de données. Il ne renvoie rien sur la plage initiale ou renvoie une valeur erronée qui se corrige plus tard, lorsque vous faites défiler le graphique et que les vraies barres arrivent.

Principales causes d'un nombre de barres limité au démarrage

1. Minimum Bars to Load reste à la valeur par défaut de 100

C'est la racine de tout le problème. Chaque nouvel onglet de graphique s'ouvre avec Minimum Number of Bars to Load à 100. Cette valeur par défaut détermine la quantité d'historique que le graphique demande d'emblée, et l'indicateur ne peut utiliser que ce qui a été demandé. Si vous ne l'avez jamais augmentée, votre indicateur travaille sur cette fenêtre réduite plus le petit supplément que le graphique ajoute, ce qui explique que vous vous retrouviez avec quelques centaines de barres au lieu de quelques milliers.

2. L'indicateur calcule avant que vous ne fassiez défiler le graphique pour plus d'historique

Faire défiler le graphique vers l'arrière charge des barres plus anciennes, mais cela se produit après l'initialisation de l'indicateur. Le calcul initial est figé sur l'historique qui existait au moment du chargement. Le défilement manuel force un nouveau calcul sur l'ensemble plus complet, ce qui explique que les valeurs se corrigent soudainement, mais c'est un pansement qu'il faudrait répéter à chaque fois, et il est inutile pour tout ce qui est automatisé ou sans surveillance.

3. Le paramètre augmenté ne persiste pas d'un onglet à l'autre

Beaucoup de gens trouvent ce paramètre, l'augmentent une fois et pensent que c'est réglé, puis le problème revient sur le graphique suivant. C'est parce que Tradovate applique la valeur par défaut à chaque nouvel onglet. Modifiez la valeur sur un graphique et elle tient pour ce graphique, mais ouvrez un nouvel onglet et vous voilà de retour à 100. Sans modèle enregistré pour reporter la valeur, la correction s'évapore dès que vous construisez une nouvelle disposition.

4. Le nombre de barres varie selon le symbole et l'unité de temps

La quantité d'historique renvoyée au démarrage n'est pas identique d'un contrat ou d'un intervalle à l'autre. Un symbole peut donner à votre indicateur environ 300 barres tandis qu'un autre en fournit nettement plus sur la même disposition. Cette incohérence rend le bogue si déroutant : on dirait que l'indicateur est cassé sur un instrument et correct sur un autre, alors qu'il s'agit du même comportement de chargement superficiel qui s'exprime différemment selon le symbole.

5. Les études à longue rétrospective ont besoin de plus de marge que les courtes

Un chargement superficiel ne devient un problème visible que lorsque la rétrospective de l'indicateur dépasse les barres disponibles. Une étude sur 20 périodes avec 300 barres est correcte. Une étude sur 200 périodes, ou une qui construit un grand échantillon glissant, a besoin de beaucoup plus d'historique derrière la première barre visible pour être juste dès le départ. Plus votre calcul remonte loin, plus vous devez relever le minimum.

Comment corriger un nombre de barres limité au démarrage : pas à pas

Corriger les causes 1 et 2 : augmenter Minimum Number of Bars to Load

Corriger la cause 3 : l'intégrer dans un modèle de base pour qu'elle persiste

Comme chaque nouvel onglet revient à la valeur par défaut, la solution durable est un modèle. C'est l'étape qui règle réellement le problème pour de bon.

Corriger les causes 4 et 5 : dimensionner la marge sur votre rétrospective la plus longue

Ne réglez pas le minimum sur le nombre exact de barres dont votre indicateur a besoin, donnez-lui une marge. Si votre étude la plus longue est une moyenne sur 200 périodes, ne réglez pas 200. Réglez une valeur plusieurs fois supérieure afin que le calcul soit entièrement échauffé avant la première barre qui vous intéresse vraiment. Lorsque vous exécutez plusieurs indicateurs ou plusieurs unités de temps à partir d'un même modèle, dimensionnez la marge pour le plus gourmand, et rapprochez-vous du plafond de 9999 si vos études remontent loin.

La version en une ligne : augmentez Minimum Number of Bars to Load, enregistrez-le comme modèle et appliquez ce modèle avant d'ajouter l'indicateur. Si vous omettez l'une de ces trois étapes, le démarrage à ~300 barres revient.

Tableau de dépannage

Sortez le graphique de la boucle d'exécution avec PickMyTrade

Précharger un historique profond corrige ce que le graphique Tradovate vous affiche, mais si vos entrées dépendent d'un indicateur calculant correctement dès le chargement d'un graphique, un démarrage à historique réduit peut quand même vous coûter une exécution. La réponse la plus propre consiste à ne plus exécuter à partir de l'affichage. PickMyTrade permet à votre stratégie de vivre là où elle dispose de l'historique complet, et déclenche l'ordre pour vous :

• Entrées pilotées par signaux, les ordres partent de la logique de vos alertes TradingView, calculée sur l'historique complet des barres de TradingView, et non sur ce qu'un graphique Tradovate fraîchement ouvert a préchargé par hasard.
• Contexte d'indicateur stable, votre EMA, VWAP ou étude personnalisée se calcule une seule fois sur l'ensemble complet, de sorte qu'un démarrage démuni ne produit jamais un déclencheur mal synchronisé.
• Validation de la quantité et du symbole, les ordres mal formés ou portant sur le mauvais contrat sont bloqués avant même d'être envoyés.
• Synchronisation multi-comptes, le même ordre validé est répliqué simultanément sur tous les comptes connectés, vous n'avez donc pas à reconstruire les graphiques compte par compte.