Author: stephanie

Les principaux critères d’évaluation d’une stratégie de trading

Que l’on soit trader discrétionnaire (manuel), ou algo trader voire développeur d’algorithme de trading, il est important de connaître et comprendre les principaux critères d’évaluation d’une stratégie de trading.

Je ne vais pas ici en faire une liste exhaustive, mais me focaliser sur ceux que j’estime être les plus importants. La qualité d’une stratégie se mesure en terme, bien évidemment, de performance, mais aussi de risque pris, et de fréquence (donc de vitesse).

Une stratégie peut être particulièrement performante et peu risquée, mais si elle ne produit que quelques trades par an, on est en droit de se poser des questions sur la pertinence du back test qui a été réalisé.

Quelques définitions…

Profit Factor: Le facteur de profit représente le rapport entre le gain brut et la perte brute de la stratégie sur une période donnée. Ainsi, une stratégie commencera à être gagnante dès que le facteur profit dépassera le seuil de valeur 1. Plus le facteur profit sera élevé, et meilleure sera la performance de notre stratégie. Généralement, on commence à avoir une jolie courbe de progression de notre capital au-delà de 1.20. Au-delà de 2, cela commence à être bien plus confortable.

L’information donnée par le facteur de profit ne permet pas toutefois d’estimer le risque réel associé à la stratégie. Par exemple, si notre stratégie génère 200.000EUR bruts de gains sur 10 ans, avec 150.000EUR de pertes brutes, nous obtenons donc in fine +50.000EUR nets sur 10 ans, ce qui donne un facteur profit de 1.33. La répartition des 150.000 EUR de pertes au long de notre période de test est toutefois très importante. En effet, + ces pertes vont être réparties uniformément tout au long de la période, et + l’évolution de notre capital se fera de manière constante. Imaginons une alternance parfaite entre nos trades gagnants et nos trades perdants, comme par exemple 1 gagnant, suivi de 1 perdant, suivi de 1 gagnant, etc…. Cette répartition homogène va nous permettre de limiter au mieux la “marge de sécurité” de notre capital. Malheureusement, cette répartition idéale entre trades gagnants/trades perdants au file du temps relève du fantasme. Dans la vraie vie, le meilleur des systèmes de trading ne pourra jamais échapper à des séries de trades perdants qui vont ainsi provoquer des baisses plus ou moins importantes du capital d’où la notion de DrawDown.

Drawdown: ainsi le drawdown est un excellent indicateur du risque de notre stratégie. il permet de mesurer “les mouvements de pertes successives”, et est généralement calculé en % du capital. On doit ainsi veiller à ce que le drawdown maximal de notre stratégie ne dépasse pas une certaine valeur que chacun doit se fixer en fonction de son appétence au risque et du capital investi. Risquer 30% de 1000EUR n’est pas la même chose que de risquer 30% sur 100.000EUR. Une valeur qui semble faire consensus dans les algorithmes de trading se situe aux alentours de 20%. Evidemment, plus cette valeur sera faible, et meilleure sera la stratégie. Il ne faut toutefois pas perdre de vue que les résultats du passé ne peuvent en aucun cas garantir les performances à venir. Nous les utilisons faute de mieux, en attendant de savoir prédire l’avenir! Connaître cette valeur maximale de drawdown est toutefois primordiale car cela sert de point de référence pour estimer qu’une série de trades perdants est “normale” ou “anormale” si l’on vient à excéder le drawndown max historique, auquel cas une réévaluation de la stratégie semble nécessaire.

RiskReward / WinRate

Le RiskReward représente le rapport entre la moyenne des trades perdants sur la moyenne des trades gagnants. Si nous avons une stratégie avec un TakeProfit fixe à 100 points et un StopLoss fixe à 50 points, alors notre RiskReward sera aux alentours de 1/2 (aux alentours car dans la vraie vie, il faut retirer les frais et le slippage). Le RiskReward peut être fixe dans le cas où la stratégie utilise des conditions de sortie constantes(TP et SL fixes comme dans notre exemple), ou il peut être un RiskReward moyen sur la période si notre stratégie utilise des conditions de sortie variables (sur trailing stop, ATR, moyennes mobiles ou autre).

Evidemment, plus les gains moyens seront importants vis à vis des pertes moyennes, et meilleure sera notre stratégie car elle sera d’autant plus capable de récupérer de ses pertes. Un rapport de 1 / 2 semble être le minimum requis pour qu’une stratégie soit rentable. Certaines stratégies peuvent proposer des rapports bien plus intéressants, comme 1/5 ou encore 1/10.

Toutefois, plus une stratégie va chercher des gains importants, tout en limitant les pertes moyennes, et plus le taux de trades gagnants en sera impacté négativement.

D’où la notion de WinRate qui représente tout simplement le taux de trades gagnants sur notre période.

Toutes ces notions sont bien évidemment interconnectées les unes aux autres, et il est difficile d’obtenir d’excellents scores à chacune d’entre elles au sein d’une même stratégie.

Stratégies gagnantes avec 30% de trades gagnants

Ce qui me semble être important de comprendre, c’est qu’une stratégie n’a pas besoin d’avoir un WinRate élevé pour être rentable, et il s’agit là d’une erreur fréquemment commise.

Vous pouvez par exemple mettre en oeuvre une stratégie avec + de 95% de trades gagnants, mais qui au final aura un risque élevé d’être perdante, alors qu’à côté de cela, vous pouvez avoir une stratégie avec un WinRate inférieur à 30% mais qui affichera des gains très satisfaisants tout en limitant les risques.

Dans le premier cas, pour assurer un WinRate > 90%, il va être nécessaire de travailler l’entrée avec une extrême précision (d’où un risque élevé de suroptimisation), et probablement de prendre un StopLoss très élevé. Le fait de mettre un StopLoss très grand va avoir plusieurs conséquences sur notre stratégie:

1/ un risque de drawdown important très élevé. il faut toujours prévoir que l’on puisse avoir plusieurs pertes consécutives même si l’historique nous dit le contraire. combien de trades perdants pourrons nous supporter avant d’ être en faillite ou en dépression?

2/ afin de pouvoir supporter plusieurs pertes consécutives, il faut que notre capital de trading soit dimensionné en conséquence, ce qui va bloquer une grande part de notre capital qui ne sera pas utilisé pour le trading la grande majorité du temps => perte d’efficacité

Pour pallier à ces problèmes, on peut aussi considérer que le capital investi peut être perdu à tout moment. Si notre capital est multiplié par 2 tous les 3 mois, on peut effectivement envisager de pouvoir perdre notre mise une fois par an par exemple. Le système restera alors très rentable.

A l’opposé, nous pouvons avoir une stratégie avec un StopLoss très serré, donc un WinRate assez faible, mais des gains attendus qui peuvent être 5 à 10 fois supérieur aux pertes. On dira alors que la stratégie a une bonne capacité à récupérer de ses pertes.

Que privilégier: WinRate ou RiskReward ?

Mon avis sur la question est basé sur mon expérience personnelle et n’engage bien entendu que moi.

Au début de mon apprentissage sur le développement de robots de trading, j’étais focalisée sur le WinRate. J’avais du mal à accepter les pertes et je recherchais un système qui aurait presque toujours raison!

Je suis ingénieur, et issue d’un milieu éducatif et professionnel où il n’y a pas de place à l’approximation. Quand on nous demande de résoudre un problème, on doit le faire de manière précise et juste. Mais cela ne peut pas s’appliquer au monde de la prédiction, et notamment quand il s’agit de marchés financiers.

Ainsi, une approche visant à créer un système de trading rentable à condition d’avoir raison 70% du temps, voire plus, me semble particulièrement risqué.

Lors de la phase d’optimisation, vous pourrez toujours, à condition d’y mettre le temps et les efforts nécessaires, obtenir un système qui affichera 80% de trades gagnants sur votre historique de données. Toutefois, ce WinRate obtenu sur votre période de test et utilisée pour votre optimisation, ne sera qu’au mieux une grossière approximation de votre WinRate réel.

Il est possible de séparer le jeu de données en un jeu pour l’optimisation et un jeu pour l’évaluation. Il s’agit d’une bonne pratique généralement appliquée aux modèles prédictifs. Toutefois, dans le cas des marchés financiers, nous sommes dans ce que l’on appelle des données non stationnaires (contrairement à des données météorologiques par exemple). Cela signifie que nous sommes en permanence en terrain inconnu, et qu’une courbe peut exploser ses anciens records ou chuter, etc… Le WinRate restera toujours à mes yeux une inconnue. Nous pouvons au mieux estimer qu’il se situe entre une valeur “minimale” correspondant à notre stratégie non optimisée, et une valeur maximale correspondant à notre stratégie avec optimisation. La réalité est donc quelque part entre les 2. J’émets ainsi des limites basses/hautes strictes et des limites basses/hautes probables :

WinRate min strict = WinRate avant Optimisation

WinRate max strict = WinRate après optimisation

WinRate min probable = WinRate après optimisation + (WinRate après optimisation – WinRate avant Optimisation) / 2

WinRate max probable = WinRate après optimisation

Le RiskReward quant à lui est une donnée connue avec précision puisque c’est nous qui la fixons. Elle peut être soit fixe (cas où TP et SL sont fixes), auquel cas les seules variations seront dues au slippage notamment. Elle peut être également une moyenne obtenue sur la période de test dans le cas où les critères de sortie dépendent du marché (sorties sur ATR, moyennes mobiles, etc…), et dans ce cas nous ne devrons pas oublier que le RiskReward sera sujet à variation autour de cette moyenne (écart type) et en tenir compte dans l’évaluation de notre stratégie.

Mettons que l’on ait un RiskReward très favorable de 1 /5, c’est à dire que chaque trade gagnant va couvrir 5 trades perdants. Notre stratégie est donc théoriquement à l’équilibre à partir de seulement 20% de trades gagnants.

A partir de ce constat, si nous trouvons une stratégie qui, avant toute optimisation, génère au minimum 20% de trades gagnants avec un Risk Reward de 1/5, alors on peut supposer qu’en y ajoutant de l’optimisation, notre système devrait être gagnant, et au pire, à l’équilibre.

Ce qu’il faut bien retenir, c’est que + le RiskReward est favorable, et + on pourra supporter un taux d’erreur important sur l’estimation du WinRate, ce qui n’est pas négligeable.

Le travail d’optimisation, quand il est réalisé avec expérience et justesse, peut alors agir de manière efficace en vue d’augmenter le WinRate.

Rien de mieux que des exemples:

Stratégie NASDAQ avec 30% de trades gagnants, RiskReward de 1 / 3

Il s’agit ici d’une stratégie sur Nasdaq future, sur croisement macd en 15min et autres critères, avec un tout début d’optimisation (seulement 10 filtres ont été appliqués pour le moment).

La stratégie était légèrement gagnante avant optimisation, optimisation qui vise donc à éviter d’ouvrir une position dans les cas les plus manifestes de mauvais positionnement (basé sur analyse technique).

Le facteur profit est encore assez faible avec 1.27 mais cela n’empêche pas la courbe d’être très favorable notamment dû à la fréquence importante de trades générés.

Stratégie BTCUSD rentable à partir de 20% de trades gagnants, RiskReward de 1/5

Le BTC est particulièrement intéressant à trader en automatique, car il présente régulièrement de belles envolées ou à l’inverse de formidables chutes. Cette stratégie met en œuvre un StopLoss particulièrement serré, à 200points seulement, ce qui induit de nombreux échecs. Les profits quant à eux sont dynamiques, la clôture de position étant opérée sur une bougie M15 inverse dépassant 1% de la bougie précédente. Ce critère simple permet d’obtenir régulièrement des trades avec des profits très élevés. Les profits ne sont pas optimisés sur la plupart des trades, mais cette approche reste dans l’ensemble très favorable et a donc été conservée pour le moment.

Voici les résultats obtenus avant optimisation:

et ceux obtenus après optimisation (après 50 arbres de décision):

On constate que le WinRate historique est monté à 45%, ce qui a fait grimper le facteur profit à 5.29. Selon nos hypothèses, notre WinRate réel devrait donc se situer de manière quasi certaine entre 21% et 45%, et de manière très probable entre 33% et 45%.

Les pertes consécutives peuvent être très nombreuses, avec un maximum de 20, ce qui n’empêche pas la stratégie de s’en remettre assez facilement. Le capital doit donc être suffisant pour supporter ces pertes.

Bilan mars 2024, Hera +20% et nouveaux projets

Hera poursuit ses bonnes performances, avec un très beau +20% et 100% de trades gagnants sur le mois de mars. Pegase par contre ne parvient toujours pas à confirmer ses bonnes performances de simulation et est donc mis de côté pour le moment. Il n’y a jamais d’échec en matière de trading algorithmique, juste des occasions d’apprendre de ses erreurs et de s’améliorer!

Ce qui se concrétise notamment par 2 nouvelles stratégies très prometteuses, sur futures NQ et BTC, je vous dis tout en vidéo!

Bilan février 2024, +4.5%, -4.4%

Sur février, Hera et Pegase sont toujours en phase 2 d’incubation (données temps réel sur compte démo). Il s’agit d’une phase d’observation indispensable et riche d’enseignements, pour se rendre compte en temps réel du comportement de ces robots, notamment concernant la durée des trades, les frais overnight, la précision des entrées, des sorties, le money management. On peut souvent constater des problèmes qui nous avaient échappé durant la phase de développement. C’est notamment le cas nous le verrons plus loin pour Pegase.

C’est également une phase importante pour apprécier leur impact “psychologique”. On parle souvent de l’importance de l’aspect psychologique dans le trading manuel, mais c’est également important dans le trading algorithmique. Il faut arriver à trouver un juste équilibre, éviter les “montagnes russes” qui peuvent provoquer quelques sueurs froides, quitte parfois à sacrifier un peu sur les performances globales. Quand je vois la forme que prennent les equity curve de robots fondés sur des martingale, je n’aimerais pas être en face de l’écran quand le capital se met à plonger, même si je suis sûre à 90% que cela va finir par compenser.

C’est pour cette raison que je préfère privilégier des gains réguliers, avec une gestion des risques contrôlée.

Hera, toujours bon élève avec +4,5%

Un bilan qui peut sembler décevant au vu des +34% qui avaient été atteints le mois passé, mais au regard de l’évolution des cours du Brent sur le mois de février, c’est en mon sens une très bonne performance.

En effet, sur février, le cours du Brent a évolué dans un range très serré entre 80.16$ et 83.24$. Hera étant prévu pour fonctionner en tendance, et sur des rebonds d’inversion de tendance, il n’aime pas beaucoup les range et évite de trader dans ces conditions. C’est aussi ce qui explique le nombre de trades faible sur le mois de février.

Le premier trade perdant que l’on peut observer s’est passé en début de range, quand il n’était pas encore manifeste que les prix allaient latéraliser.

Si il est clairement difficile d’anticiper une latéralisation, cela n’empêche pas d’analyser les choses de plus près à la recherche d’un indice qui aurait pu nous mettre en garde. C’est là que l’analyse technique et les statistiques entrent en scène.

Dans le cas qui nous intéresse, pour ce trade à l’ achat du 5 février à 1h du matin, on peut identifier une divergence au niveau du stochastique (34,5,5) en H1, que l’ont peut visualiser ci-dessous.

Cette divergence à elle seule n’était toutefois pas, statistiquement parlant, un critère suffisant pour justifier le blocage du trade, mais en combinaison avec d’autres informations relatives à la tendance, cela m’a permis de rajouter un arbre supplémentaire et d’améliorer encore la robustesse de Hera.

Regardons maintenant le comportement de Hera si l’on désactive tous ses arbres de décision (optimisation basée sur analyse technique et statistique).

Des résultats qui n’ont plus rien à voir… Les codes entre crochets correspondent aux codes des arbres de décision qui ont été impliqués dans les différents blocages.

Cela permet d’apprécier l’efficacité de ces arbres de décision qui ont permis d’éviter de très lourdes pertes.

La faible fréquence de trades (généralement moins de 5 par mois) n’est pas forcément un problème, car cela permettra de l’associer à d’autres robots sur un même compte (Pegase par exemple), et ainsi de constituer un portefeuille plus diversifié.

Pegase, un démarrage plus compliqué, avec -4.4%

Pour rappel, Pegase est un robot optimisé sur les indices US30, Nasdaq, SP500, Dax40 et JP225. Pour l’instant, les 5 indices sont explorés, sans restriction sur le nombre de trades ouverts simultanément, ceci pour en faciliter le suivi. Il est vraisemblable que le nombre de trades simultanés sera limité par la suite, ce sera un des points à déterminer avant la mise en production finale. Il faut être conscient que les indices présentent entre eux une forte corrélation, donc il est à prévoir qu’il puisse y avoir 5 trades ouverts simultanément, dans la même direction, et tous perdants en même temps… Ce n’est donc pas à négliger. Le fait de conserver les 5 indices reste intéressant car cela devrait permettre de réduire les périodes d’inactivité.

Le bilan sur février est donc assez mitigé. Nous sommes à l’équilibre au niveau des trades, mais les frais overnight nous font passer à -4%.

Bien évidemment, cela amène à une réflexion relative à la durée des trades ouverts, qui dépassent souvent plusieurs journées. Au-delà des frais overnight, cela augmente également les risques de gap défavorables, c’est ce qui s’est produit le 21 février sur USTECH avec un trade qui affichait un profit très acceptable mais a été coupé en négatif le lendemain matin sur gap.

En trading, il existe une notion que l’on a nommé la “triple frontière”. Cela consiste à manager ses trades en considérant une frontière basse (stop loss, trailing stop), une frontière haute (take profit), et une frontière à droite (critère de durée). Un principe intéressant à suivre que j’ai donc décidé d’appliquer à Pegase en imposant une clôture des trades le vendredi soir, ainsi que les soirs en semaine à partir du moment où les trades enregistrent un gain satisfaisant.

2 autres trades perdants imputables à USTECH en début de mois étaient dus à un stop loss trop serré. J’étais en effet partie sur un paramétrage différent sur DE40 et USTECH pour lesquels le StopLoss était 2 fois moindre que pour les autres indices. Si d’un point de vue global cette approche est favorable, j’ai tout de même décidé d’aligner tous les SL à une même valeur pour tous les indices, fixé désormais à 1.2% de variation de l’indice.

Le trade perdant sur JP225 survenu le 27 février, à la vente (contretendance), est survenu dans un contexte de tendance weekly très fortement défavorable, avec des pentes de moyennes mobiles ma4 et ma8 atteignant des sommets historiques. Il a donc été facile de rédiger un nouvel arbre pour éviter d’ouvrir une position en contretendance dans ce cas.

Suite à ces modifications rapides, si l’on rejoue le scénario du mois de février sur ces 5 indices, on obtient un nouveau score de +47% (sans les frais overnight), ce qui montre le potentiel latent de Pegase.

Il reste à voir si cela sera suffisant pour faire monter ses performances les prochains mois !

Bilan Janvier 2024, +34% et +7%

Le temps est venu de faire le bilan de Hera et Pegase pour le premier mois de 2024, qui en sont en phase 2 d’incubation(compte démo sur données en temps réel).

Hera, le bon élève avec +34% …

C’est toujours quelque chose d’émouvant en tant que développeur de voir son “bébé” réaliser des trades aussi parfaits. Des entrées avec un bon timing, des sorties raisonnables. Juste un trade perdant mais qui a été compensé quelques heures plus tard. Bien entendu, il est très vraisemblable que tous les mois ne seront pas de ce niveau, mais savourons cet instant 😀

En 2 mois Hera a donc cumulé 2373EUR de gains, pour un capital initial de 5000EUR, soit pour le moment +47,46%

Le réglage du risque est resté le même, c’est à dire un risque par trade de 6%, ce qui est assez élevé. Pour l’instant, au vu du bon niveau de trades gagnants, je vais conserver ce réglage.

Pegase, un démarrage plus timide, avec +7.86%

Pour son premier mois en phase 2 d’incubation (compte démo, temps réel), Pegase affiche un timide mais très acceptable +7.86%, soit un gain de 393EUR pour un capital de 5000EUR.

Il tourne en simultané sur 5 indices, que sont USTECH (Nasdaq), SP500, DJ30, DE40, et JP225, avec un réglage du risque par trade qui a été fixé pour le moment à 3%. USTECH et DE40 ont un réglage légèrement différent des autres, le SL étant limité à 0.5% alors que pour les autres il est fixé à 1% . Il est donc normal d’avoir + de trades perdants sur USTECH et DE40, mais des gains plus élevés aussi.

On voit de suite que l’historique de trades est moins “propre”. Un bug est apparu sur la gestion du money management multi symboles, ce qui explique les petites pertes qui n’auraient pas dû avoir lieu. Les trades ont été coupés trop tôt. C’est un des inconvénients de Metatrader qui ne permet pas de tester un robot en multi-symboles afin d’implémenter correctement une couche supérieure de money management. Mais j’ai déjà repéré un nouvel outil qui m’apporterait cette fonctionnalité, et bien plus encore. Pour plus tard donc 🙂

Sinon, malgré de nombreux trades perdants, les gains ont pu compenser suffisamment pour conserver une balance positive en fin de mois, ce qui est rassurant. J’avais intentionnellement limité le travail d’optimisation sur Pegase par rapport à Hera, mais je m’aperçois que c’était une erreur. Parmi les trades perdants, certains auraient clairement pu être évités. Je rappelle que ce travail d’optimisation consiste à appliquer les enseignements de l’analyse technique à une étude statistique des différentes configurations de marché (avec de nombreuses précautions permettant de limiter l’over fitting). Je vais donc poursuivre ce travail d’optimisation sur Pegase qui reste pour moi très prometteur.

Développements en cours ….

2 nouveaux robots Metatrader, basés aux aussi sur l’algorithme Smart Forest sont dans les tuyaux:

  • Ceres – Robot multi-symboles sur Matières Premières (NGAS, DIESEL, WTI, BRENT, COTTON, COFFEE, COCOA). Il scrute les signaux longs termes, et peut donc passer plusieurs semaines en étant totalement inactif, ce qui peut être assez frustrant. Je l’imagine donc plutôt comme un robot secondaire. Je devrais pouvoir vous le présenter très bientôt.
  • Cresus – Robot multi-symboles sur Cryptos. Les cryptos présentent souvent des courbes de tendance très marquées, de grosses vagues sur lesquelles on n’a qu’une envie: surfer dessus! Cresus met en œuvre une approche assez différente de ce que j’ai réalisé jusqu’à présent. En tant que “chercheuse”, je pense important d’essayer constamment de nouvelles approches. Puis avec l’expérience, on identifie ce qui fonctionne le mieux et on s’améliore. Pour mettre en place un système de trading, plusieurs éléments sont nécessaires: 1/ identifier la configuration de marché (tendance, zone de retournement) pour savoir quel sens (achat ou vente) il faut privilégier. Ce premier niveau se fait préférentiellement dans les échelles de temps supérieures (monthly/weekly/daily). 2/ recherche du bon timing dans les échelles de temps inférieures. Ici on recherche des “signaux d’entrée” 3/ stratégie de sortie adaptée. Donc généralement, on recherche des points d’entrée, c’est à dire que l’on cherche à répondre à la question “Quand dois-je rentrer?” et bien sûr dans quel sens. Sur Cresus, l’étape 1 permettant d’identifier le sens de trade est bien sûr conservée, car je la pense incontournable. Mais ensuite, plutôt que de chercher un signal d’entrée, je rentre sur le marché de manière systématique, en réalisant un trade par bougie H4…. Bien sûr, cela impose de réaliser des trades de petites tailles. Puis le travail d’optimisation permet d’exclure les zones où la probabilité de trades perdants est trop élevée. Donc plutôt que de poser la question “Quand dois-je rentrer?”, je pose la question “Quand ne dois-je pas rentrer?”. Cette approche présente l’avantage de permettre un “scan” global des courbes d’historique, plutôt que de se limiter aux zones qui présentent un signal d’entrée. Travailler sur les cryptos présente toutefois un inconvénient: on dispose d’historiques limités, d’où la nécessité de travailler sur de nombreuses cryptos en parallèle afin que ce travail d’optimisation conserve sa pertinence.

    Cresus sur BTC, “nuage de trades” avec entrée systématique sur bougie H4 dans le sens de la tendance weekly. Ce nuage de trades permet de visualiser rapidement les configurations de marché favorables et celles à risque.

Sur BTC, cette approche systématique est déjà rentable avant tout travail d’optimisation. Toutes les paires de crypto ne sont pas rentables. Ces paires ne sont pas négligées, bien au contraire, car elles sont porteuses de nombreuses informations relatives aux zones à risque.

Equity curve Cresus sur BTC avant optimisation:

Un robot déjà prometteur donc, mais beaucoup de travail à réaliser dessus, j’espère vous le présenter plus officiellement d’ici 3 mois.

Affaire à suivre donc!

  • En parallèle du développement de robots Metatrader optimisés, je travaille également à la recherche d'”alphas” sur futures via TradeStation. Il s’agit ici de rechercher des stratégies qui ne font souvent que quelques lignes, mais qui présentent déjà une courbe de gains favorable. Cette approche est celle qui est le plus souvent appliquée par les traders à ma connaissance, car plus accessible et ne demandant que peu de compétences en développement. Il s’agit de tester des dizaines, parfois des centaines de stratégies, sur de nombreux symboles, échelles de temps, jusqu’à trouver la “pépite” rentable. C’est quelque chose d’assez ludique finalement, que l’on peut pratiquer comme passe temps quand on a besoin de faire quelque chose de différent. J’ai ainsi déjà quelques stratégies en test, prometteuses sur simulation mais qui demandent à être vérifiées en temps réel. Quand j’aurais un peu plus de recul donc, je présenterai les résultats dans les prochains bilans. Ces stratégies seront probablement proposées à la vente si elles s’avèrent gagnantes.

Bilan Décembre 2023

Hera – Brent

Toujours en période d’incubation, Hera fait son premier mois sur des données en temps réel afin de vérifier son comportement.

Un premier bilan très positif puisque nous atteignons les +10%.

Capital de départ: 5000EUR; Risque par trade: 6% (réglage “agressif”)

Le trade à la vente du 15 décembre était tout à fait évitable, puisque nous sommes sur une phase de retracement très marquée en daily, très visible si l’on regarde le stochastique. Il a donc fait l’occasion d’une amélioration pour éviter des trades dans des configurations similaires à l’avenir.

Malgré cette faute évitable, le bilan reste très positif.

Pegase – Indices

Pegase est également basé sur l’algorithme “smart forest” , mais a été “poussé” encore plus loin que Hera puisqu’il a été optimisé sur 5 indices: DE40, NASDAQ, US30, US500, JP225.

L’optimisation sur différents actifs permet d’améliorer la robustesse générale du robot, puisque l’on dispose ainsi, sur la base de 5 indices ayant chacun 10 années d’historique, d’un équivalent de 50 années d’historique de données pour parfaire l’optimisation.

Au-delà de l’effet positif sur la robustesse du robot ainsi créé, l’autre gros avantage est de disposer d’un robot unique utilisable simultanément sur différents actifs. Cela permet notamment de réduire ses risques et de limiter les périodes d’inactivité par une bonne diversification du portefeuille.

Ci-dessous voici le bilan correspondant aux différents indices pour la période de décembre 2023 (résultats obtenus par simulation mais ces données étaient bien absentes de l’échantillon d’apprentissage). Le passage de Pegase en données temps réel sera effectif à partir de janvier 2024.

Capital : 5000EUR; Risque par trade: 5%

IndiceVar (%)Profit NetProfit BrutPertes BrutFacteur ProfitTrades gagnants (%)Nombre de tradesMoyenne Trades Gagnants (EUR)Moyenne Trades Perdants (EUR)
DE40000000000
JP225-0,53%-26,56EUR481,52EUR-508,08EUR0,9560%5160,51EUR-254,04EUR
NASDAQ+14,14%707,43EUR707,43EUR0inf100%3235,81EUR0
DJ30+12,61%630,95EUR630,95EUR0inf100%3210,31EUR0
SP500+5,49%274,50EUR274,50EUR0inf100%2137,25EUR0

Le bilan est là aussi globalement très positif.

L’indice Nikkei présente un bilan négatif sur cette période, mais son bilan est le plus favorable parmi les 5 indices sur la période de 10 années, donc il n’y a pas lieu de s’en inquiéter pour le moment.

La balance dans les montants moyens gains / pertes sur cette période peut sembler défavorable, mais cela n’est pas significatif du comportement global (la sortie de position se fait sur la base d’indicateurs techniques et non pas avec des valeurs fixes).

On peut envisager de faire tourner Pegase conjointement sur ces 5 indices et sur un même compte. En abaissant le niveau de risque à 2%, le bilan global sur cette période serait ainsi de +12,69%.

Bien backtester sa stratégie: l’effet “glissement”

Pour mener à bien le backtest de sa stratégie sous MetaTrader, de nombreuses choses sont à prendre en compte, dont on prend conscience généralement progressivement, après avoir fait des erreurs.

Je vais vous parler ici de ce que j’ai appelé l’effet “glissement”.

Il s’agit d’un effet insidieux dont on peut facilement oublier de tenir compte lors des simulations réalisées.

Généralement, une stratégie d’émission de signaux de trading va tenir compte des positions ouvertes. Cela est indispensable pour ne pas générer un trade par minute… Ainsi donc, on émet un trade, et tant que ce trade est ouvert, la stratégie peut être de ne pas ouvrir d’autre trade dans la même direction, ou dans les 2 directions, ou encore elle peut autoriser un autre trade mais à condition qu’il y ait 2h d’intervalle, etc…, etc… Une grande variété de possibilités, mais ces choix doivent être pris tôt dans la conception de notre robot.

Ce dont il faut bien avoir conscience, c’est que par la suite, à chaque modification de l’algorithme, les cartes vont être remélangées, et il va alors être nécessaire de réévaluer la situation.
Par exemple, si vous avez des critères avec des seuils permettant de quantifier un gradient de moyenne mobile, ou un éloignement à un support clé, votre trade sera peut-être bloqué au moment T1, mais sera autorisé un peu plus tard, quand la situation du marché aura légèrement évolué, disons au moment T2.
Ce nouveau trade au moment T2 n’était pas visible auparavant. Il s’agit donc d’un nouveau trade, qui peut-être gagnant, ou perdant.

Si vous avez opté pour la rédaction manuelle d’arbres de décision, cet état de fait peut-être pris en considération en relançant régulièrement les simulations sur la période complète, ceci plusieurs fois lors de la rédaction d’un arbre de décision, et SURTOUT, entre chaque arbre de décision.

Quelle que soit votre approche dans la conception de votre robot, la clé est donc d’être en mesure de lancer des simulations très régulièrement, à chaque fois que vos modifications ont été en mesure de modifier le paysage de vos trades. Sans cela, vous allez travailler sur la base d’informations erronées et perdre potentiellement des heures de travail.

Pour cela, il faut donc en premier lieu se préoccuper de la rapidité d’exécution des simulations. Une simulation sur 10 années ne devrait pas prendre plus de 30secondes à 1 minute afin de ne pas pénaliser votre travail de développement.

Vous trouverez dans cet autre article des astuces pour accélérer vos simulations si vous en avez besoin.

Une toute autre approche est possible pour répondre à cette problématique.

On peut définir un mode “backtesting” configurable au lancement du robot. Dans ce mode, la stratégie ne limitera plus le nombre de trades émis simultanément, mais imposera une autre règle, par exemple 1 seul trade par bougie H1 ou M30 (fonction de votre stratégie bien sûr). Etant donné que le robot va alors générer plusieurs trades à la fois, il faudra adapter la taille des lots ou le montant du capital afin que tous les trades requis puissent être ouverts.

Il est alors possible d’examiner d’emblée toutes les configurations possibles pour l’entraînement de notre modèle.

Les résultats généraux de la simulation obtenus dans ce mode “backtesting” ne seront bien évidemment pas représentatifs de la réalité. Une fois l’analyse voulue des trades réalisée, il faudra refaire une simulation en mode “normal” afin d’obtenir des chiffres plus réalistes.

Bien sûr ces recommandations sont tout autant valables pour un modèle en machine learning.

Cas pratique: création manuelle d’un arbre de décision

Nous allons voir ici comment créer un arbre de décision manuellement. Je ne vais pas rentrer dans le code Metatrader, car chaque développeur a ses propres habitudes, mais m’intéresser plutôt à la philosophie derrière.

Cet article est un complément à la page dédiée à mon algorithme “Smart Forest” que je vous conseille de lire en premier lieu sinon vous risquez d’être un peu perdu.

Tout d’abord, il est indispensable de savoir générer un fichier .csv contenant les trades émis avec toutes les caractéristiques correspondantes au moment de l’ouverture de la position, ainsi que le bilan final du trade, à savoir si il est gagnant ou pas, et aussi dans quelle mesure. Il peut en effet s’agir d’un trade avec un gain important, ou bien un gain minime. Les décisions que l’on prendra par la suite dépendront de ces informations, car nous serons plus à même de sacrifier un petit trade qu’un gros.

Prenons un exemple récent, le bilan sur novembre de Hera sur le BRENT. Un gain appréciable de 759EUR pour un capital de 5000EUR, mais en y regardant de plus près, sur les 11 trades émis, 4 étaient perdants.

Graphique H4:

Graphique D1:

2 de ces trades perdants ont été émis le 22/11/23, sur une très forte bougie h4 baissière, avec des ouvertures de position visiblement très éloignés de la MM8.h4 (en bleu). En daily, on visualise également très bien le fait que ces trades étaient mal positionnés. Il est probable qu’un humain avisé n’aurait pas ouvert de trades à la vente à ce moment là. Le trade perdant du 30/11 semble correspondre au même schéma en H4, nous pouvons donc espérer écrire un arbre de décision qui engloberait ces 3 trades.

Des contrôles qui fonctionnent généralement bien consistent à mesurer les écarts aux moyennes mobiles, ainsi que leurs gradients, ceci souvent en conjonction avec d’autres observations. Parfois il est nécessaire de tester plusieurs variantes afin de trouver ce qui correspond le mieux.

L’observation permet donc d’émettre les premières hypothèses, puis une simulation sur la période globale de test doit être lancée afin d’identifier tous les trades impactés. Chaque hypothèse doit être testée pour être validée.

Dans ce cas, je remarque qu’en H4, les moyennes mobiles ne sont pas « rangées » dans le bon ordre, et le trade est lancé totalement à l’opposé. La MM50 est représentée en jaune, et la MM26 en vert. On a donc la MM8 > MM50 > MM26, ce qui n’est pas une configuration « propre », illustrant un mouvement récent fort dans le sens de l’achat. L’émission d’un trade à la vente, de surcroît mal positionné par rapport aux moyennes mobiles semble effectivement être un mauvais choix, aux probabilités de succès réduites.


Nous allons dans un premier temps émettre des critères les plus généraux possibles, puis ce sont les résultats de la simulation qui nous permettront d’affiner les choses.

On pourrait ainsi écrire pour la vente (ce sera l’inverse pour les achats):

mm8.h4 > mm50.h4
&& mm50.h4 > mm26.h4
&& Bid() < mm26.h4

Ce premier jet nous permet d’isoler 27 trades sur la période de 10 ans (sans nos trades de novembre), ce qui peut sembler faible mais toutefois suffisant pour pouvoir identifier des critères supplémentaires. On peut ajouter à cela nos 3 trades de novembre 2023 qui correspondent également à ce descriptif.


Cela constituera un arbre de taille assez réduite, mais nous pourrons toujours apprécier dans le futur que des trades ne soient plus émis dans une situation comparable. Hera est un robot déjà bien avancé en terme d’optimisation, donc à ce stade, il est normal que les trades gagnants soient majoritaires.

Pour ne pas perdre trop de trades positifs, nous allons voir si il est possible d’affiner un peu les choses. Même si il ne faut jamais s’obstiner à essayer de trouver une cohérence là où il n’y en a pas!

C’est là que le fichier .csv est indispensable.

Avec l’expérience, on peut identifier rapidement les valeurs caractéristiques extrêmes qui permettent de préciser les choses, le but étant de relier entre eux le plus de trades perdants, en excluant au maximum les trades positifs. La lecture des données conjuguée à la visualisation des trades sur la courbe, rend cette technique particulièrement efficace.

Dans cet exemple, les critères supplémentaires conservés vont être relatifs au positionnement du prix vis à vis de la mm8.mn1, de la mm4.mn1, et des gradients de moyenne mobile mm4.d1 et mm8.w1. Il serait quasiment impossible d’identifier ces informations avec leur seuil sans l’aide d’un reporting adapté.

Dans cet exemple relativement simple, la seule lecture du fichier de reporting s’est avérée suffisante, mais le plus souvent, il est nécessaire de recourir à des patterns graphiques pour parvenir à affiner les choses.

On pourrait ainsi écrire, toujours pour les ventes (les seuils sont ici à titre indicatif, ils doivent être déterminés sur des valeurs normalisées et apparaissent souvent très utiles pour quantifier la force d’une tendance ou l’importance d’un éloignement):

mm8.h4 > mm50.h4
&& mm50.h4 > mm26.h4
&& Bid() < mm26.h4
&& Bid() < mm8.mn1
&& Bid() < mm4.mn1 + 500
&& gradient(mm4.d1) < 5
&& gradient(mm8.w1) < 30

Ces nouveaux critères permettent d’identifier désormais les trades suivants (auxquels il faut toujours rajouter nos 3 trades perdants de novembre – s’agissant de jeux de données différents, historique tickstory vs historique récent metatrader, il n’est pas possible de les avoir sur un même graphique. La « fusion » des données doit se faire manuellement).

Nous avons conservé ainsi 10 trades (+ 3 trades de novembre), dont seulement 3 gagnants, qui seront désormais exclus par cet arbre de décision.

Les trades sur novembre suite à validation de cet arbre de décision sont ainsi plus « propres » qu’initialement. Il ne reste plus qu’un trade négatif, le 21/11 à 12h00, qu’il serait difficile de sécuriser. Un exemple de trade perdant « par malchance » sur lequel baser un arbre de décision ne semble pas être une bonne idée. S’acharner à vouloir exclure des trades perdants qui sont en toute objectivité bien placés nous ferait tomber dans l’écueil de l’over fitting.

Notre arbre de décision est ainsi achevé, d’une manière assez simple, puisqu’il n’a pas été nécessaire de lui associer des branches.

Quelques mots concernant les branches. Une branche est l’équivalent d’un « sauf si…. », et permet d’exclure d’un arbre de décision un ensemble de trades correspondant à une situation précise. Une branche, qui sera un ensemble de conditions favorables, va donc permettre l’exclusion de trades gagnants d’un arbre de décision.

Stratégies de trading: le grand débat

En matière de conception de robot de trading, on pourrait identifier 2 approches principales qui semblent être en opposition.

La première tend à rechercher un “alpha” optimum, c’est à dire un ensemble de quelques critères (généralement moins de 10), qui permettraient de générer des trades globalement favorables et qui ainsi se suffiraient à eux-mêmes. Dans cette approche, on voit d’un mauvais œil toute tentative d’optimisation qui ferait prendre systématiquement un risque trop grand d’over-fitting (suroptimisation de la phase d’entraînement avec dégradation des performances lors du passage en réel).
Cette approche pourrait être comparée à la recherche d’une aiguille dans une botte de foin. Une recherche souvent longue avant d’aboutir à une formule suffisamment robuste pour garantir des revenus quelles que soient les conditions de marché. Cette quête du Graal, toutefois, si elle se concrétise, permet par la suite de mettre en œuvre un robot d’une simplicité déconcertante…
Cette approche requiert beaucoup de patience, et de curiosité. Il faut également savoir qu’un alpha peut être non rentable sur un actif donné, mais générer des profits réguliers sur un autre pourtant proche. Une systématisation des tests sur des dizaines, voire des centaines d’actifs peut donc s’avérer être une stratégie payante.

“Amateurs develop individual strategies, believing that there is such a thing as a magical formula for riches. In contrast, professionals develop methods to mass-produce strategies. The money is not in making a car, it is in making a car factory.
Think like a business. Your goal is to run a research lab like a factory, where true discoveries are not born out of inspiration, but out of methodic hard work. That was the philosophy of physicist Ernest Lawrence, the founder of the first U.S. National Laboratory”

Marcos Lopez de Prado – Advances en Financial Machine Learning

La deuxième approche tend à considérer qu’il est inutile de chercher à modéliser par un moyen simple un problème aussi complexe que des données financières. A problème complexe, solution complexe. Il s’agit donc ici de chercher une stratégie brute acceptable, c’est à dire générant suffisamment de signaux gagnants (et perdants), sans forcément se préoccuper dans un premier temps de savoir si cette stratégie brute est gagnante ou pas. Bien entendu, plus la performance initiale est bonne, et moins il y aura de travail par la suite.
Il ne s’agit alors plus de creuser indéfiniment à la recherche d’un diamant déjà taillé, mais plutôt de partir d’un diamant brut et de le tailler soi-même (ce qui implique d’apprendre à tailler un diamant!).
Le travail d’optimisation qui va alors s’en suivre va chercher à soustraire des trades générés le plus possible de trades perdants, ce qui va permettre d’augmenter le WinRate. En langage de machine learning, on part d’une stratégie brute avec une précision moyenne à faible, mais avec un bon recall, puis on cherche à améliorer la précision sans détériorer le facteur recall (en d’autres termes, on veut abaisser le nombre de faux positifs, tout en maintenant élevé le nombre de vrais positifs).
Bien entendu, les modèles de machine learning/deep learning rentrent dans cette catégorie.

Over-fitting vs under-fitting


Si dans la première approche décrite précédemment, le risque d’over-fitting est nul (puisqu’il n’y a pas eu d’étape d’optimisation poussée), le risque d’under-fitting est quant à lui élevé. En somme, une telle stratégie va très probablement émettre des trades dans des configurations de marché que tout analyste technique aurait pu qualifier à l’avance de très probablement défavorable. Des pertes évitables auront donc lieu régulièrement, ce qui peut s’avérer assez frustrant.

Dans la deuxième approche, l’optimisation va quant à elle faire effectivement prendre le risque d’over-fitting, problème qu’il est important de prendre très au sérieux. A mes débuts, j’étais capable de produire des résultats de simulation quasi linéaires, avec 90% de trades gagnants, des performances incroyables, et pourtant, lors du passage sur des données en temps réel, c’était la désillusion la plus totale. Cela signifie-t-il qu’il faille éviter totalement toute phase d’optimisation? Je ne le pense pas. Il est par contre nécessaire d’essayer de comprendre l’over-fitting, afin de le limiter au maximum.

Des données en quantité suffisante

Le premier conseil est de disposer de données en quantité suffisante. On peut généralement trouver gratuitement des historiques sur 10 ans pour les indices, forex, matières premières. Bien plus si vous vous intéressez aux actions. Avec le recul, un historique de 10 ans me semble insuffisant. Vous pouvez essayer de vous procurer des historiques plus anciens, ce qui sera probablement payant. Vous pouvez également, et c’est également une bonne pratique, optimiser votre robot sur la base des données de plusieurs actifs proches. Plusieurs paires de devises si vous êtes sur le forex, ou plusieurs indices si vous êtes sur les indices.
A titre d’exemple mon dernier robot Pegase est optimisé/testé sur 5 indices : DowJones, Dax, SP500, Nasdaq, JP225. Un dernier indice, le CAC40 est utilisé pour la validation/évaluation des performances.
Donc plus on a de données, mieux c’est.
Bien entendu, il faudra prendre soin de normaliser nos données afin de pouvoir comparer plusieurs actifs entre eux.

Ne pas trop descendre dans les échelles de temps

Mon deuxième conseil est de rester le plus général possible lors de l’écriture d’un critère, ce qui implique notamment de ne pas descendre dans les échelles de temps. Avec l’expérience, on s’aperçoit que la description d’une configuration de marché sur la base des graphes MN1, W1 et D1 suffit le plus souvent. Plus on descend, et plus on rentre dans une description très spécifique qui aura peu de chances de se reproduire un jour. Et plus on descend, plus le “bruit” occupera une place importante par rapport à l’information véritable.

Faire varier les seuils

L’objectif de l’optimisation est d’arriver à décrire des configurations de marché qui se reproduisent régulièrement dans le temps, avec des résultats comparables à chaque fois. Cette capacité à identifier les “features” les plus appropriées et à écrire les bons critères se développe bien entendu avec l’expérience.
Une bonne pratique consiste toutefois à faire varier les seuils que l’on peut être amené à utiliser. Par exemple, si l’on veut quantifier la force d’un gradient de moyenne mobile, ou bien l’éloignement du prix par rapport à une bande de bollinger ou à une moyenne mobile, on peut être amené à utiliser une valeur seuil. On va ainsi s’apercevoir par exemple que si notre gradient de moyenne mobile est supérieur à X, et le prix est inférieur à Y par rapport à cette moyenne mobile, il devient dangereux de vendre car nous constatons une majorité de trades perdants. Mais que se passe-t-il si nous faisons varier X et Y de quelques points? Si la proportion de trades perdants reste très majoritaire, alors nous pourrons peut-être en conclure que ces critères se suffisent à eux-mêmes. Par contre si nous voyons apparaître des trades gagnants intéressants, alors nous allons peut-être en conclure que l’ajout de nouveaux critères, tels que le stochastique ou autre, est nécessaire.

Pour conclure, je dirai que le choix entre les 2 approches vous appartient, mais que les 2 peuvent donner de bons résultats, à condition d’avoir bien conscience des notions d’over-fitting/under-fitting.

Si le machine learning a le vent en poupe ces dernières années concernant la prédiction de données financières et que de nombreuses recherches sont menées dans ce domaine, les solutions simples et toutes faîtes ne sont pas aussi évidentes. Ce n’est pas parce que vous allez mettre en œuvre un algorithme Random Forest rapidement sur votre jeu de données, avec quelques features prises au hasard, que vous pouvez espérer rapidement de bons résultats sans vous soucier de ce que fait l’algorithme.

Passer du temps à analyser les marchés, écrire des critères à la main pour voir concrètement ce que cela donne, et au fil du temps identifier des patterns qui fonctionnent est une première étape qui me semble indispensable.
Pour alimenter votre algorithme de machine learning avec les bonnes informations, encore faut-il savoir quelles sont ces “bonnes informations”.

Dans un prochain article j’introduirais mon algorithme “Smart Forest“, en référence à l’algorithme “Random Forest” de machine learning. Nous y verrons comment on peut écrire des arbres de décision manuellement, et quels avantages/inconvénients cette approche peut avoir par rapport à son cousin Random Forest.

Générer un fichier de reporting de vos trades sur Metatrader

Comme le dit souvent un de mes youtubeurs préférés, il est important de “comprendre ce qu’il se passe” (merci Tibo!).

Un leitmotiv à se répéter en boucle tous les matins…

Si vous en êtes arrivé au point où vous avez un robot qui applique votre stratégie, si vous regardez sur la courbe l’historique des signaux, vous verrez invariablement des trades qui ont été ouverts à des moments où ils n’avaient objectivement que très peu de chance de réussite.
Il faut parfois changer d’échelle de temps pour s’en rendre compte. Un trade peut sembler pertinent en M15, puis qu’en on passe en H4 ou D1, on va s’apercevoir qu’on est bien en dehors des bandes de Bollinger, avec des signes évidents de retracement en cours au niveau du macd ou du stochastique.

Ainsi, pour arriver à “comprendre ce qu’il se passe”, la première chose est d’aller contrôler les différentes échelles de temps, surtout les échelles de temps supérieures (MN1, D1, H4).

Le fait d’observer un trade en particulier, pris isolément des autres trades générés par votre robot, n’a toutefois que peu d’importance. Ce qui nous intéresse, c’est la probabilité de succès ou d’échec d’un trade dans une configuration de marché donnée.

Pour connaître cette probabilité, il est indispensable de savoir générer un listing des trades émis, avec pour chacun d’eux la valeur de nos indicateurs préférés, les points gagnés ou perdus, ainsi que toutes les informations dont on peut avoir besoin. Notre ami Excel ou tout autre tableur de votre choix vous aidera alors à tirer toutes les conclusions dont vous avez besoin.

Cette possibilité de générer des fichiers de reporting est l’un des gros avantages de Metatrader sur les autres plateformes TradingView ou ProRealTime.

En MQL, la génération de fichiers est très simple.
On commence par la génération de l’entête au niveau du OnInit(), dont voici un exemple ci-dessous:

m_handle_file_trade = FileOpen(“Analyse\Pegase_Trade.csv”, FILE_WRITE|FILE_CSV);
FileWrite(m_handle_file_trade,
“Début “,
“Fin”,
“Symbol”,
“Volume”,
“Commentaire”,
“Position Type”,
“Swap (EUR)”,
“Profit (EUR)”,
“Profit (Pts)”,
“Points max (Pts)”,
“Points max (%)”,
“Pertes max (Pts)”,
“Pertes max (%)”,
“Signal de sortie”,
// mn1
“Dist. upper(buy)/lower(sell).mn1”,
“Dist. ma4.mn1”,
“Dist. ma8.mn1”,
“Pente ma4.mn1”,
“Pente ma8.mn1”,
“Delta sto.mn1”,
… etc …
);

Le fichier sera généré dans un répertoire du type:

C:\Users\smelo\AppData\Roaming\MetaQuotes\Tester\D0E8209F77C8CF37AD8BF550E51FF075\Agent-127.0.0.1-3000\MQL5\Files\Analyse

Ce répertoire est vidé à chaque lancement d’une nouvelle simulation, donc si il disparaît, c’est normal. Si ce mode de fonctionnement ne vous convient pas, vous pouvez utiliser l’option “FILE_COMMON”, ainsi vos fichiers seront créés dans un répertoire permanent.

L’écriture des données spécifiques à chaque trade émis doit se faire au moment de la clôture du dit trade si l’on veut savoir notamment si ce trade est gagnant ou pas…

Comme on souhaite récupérer les informations de marché au moment de l’ouverture du trade, cela signifie donc que l’on doit stocker ces informations dès l’ouverture du trade, pour être en mesure de les restituer plus tard.

Ainsi, au niveau des fonctions permettant l’ouverture d’un trade achat/vente, on va venir mettre à jour un tableau conservé en sessions, avec toutes les données nous intéressant.

void OpenBuy(string commentary)
{
double price, volume;
price = m_symbol.Ask();
// Calcul du volume
volume = dblLotsRisk( p_stop_loss );
if(m_trade.Buy(volume, m_symbol.Name(), m_symbol.Ask(), 0, 0, commentary))
{
// mn1
m_data_infos[0] = MathRound((m_bollinger_upper_mn1[0] – m_symbol.Ask())/m_bollinger_upper_mn1[0]10000); m_data_infos[1] = MathRound((buffer_ma4_mn1[0] – m_symbol.Ask())/buffer_ma4_mn1[0]10000);
m_data_infos[2] = MathRound((buffer_ma8_mn1[0] – m_symbol.Ask())/buffer_ma8_mn1[0]10000); m_data_infos[3] = MathRound(((buffer_ma4_mn1[0] – buffer_ma4_mn1[1])/buffer_ma4_mn1[1])10000)/10;
m_data_infos[4] = MathRound(((buffer_ma8_mn1[0] – buffer_ma8_mn1[1])/buffer_ma8_mn1[1])10000)/10; m_data_infos[5] = MathRound((sto_main_mn1[0] – sto_signal_mn1[0])10)/10;
… etc …
}
}

Il ne reste plus qu’à voir la mise à jour du fichier au moment de la clôture du trade.

Pour cela il est nécessaire de pouvoir exécuter une fonction à chaque fois qu’un trade se ferme, ce qui va s’avérer impossible si notre trade est fermé automatiquement par StopLoss ou TakeProfit. On doit donc pouvoir “hacker” ce fonctionnement, du moins pour les simulations.

Il y a probablement plusieurs façons de procéder, peut-être plus élégantes que celle que je vous propose ici, le principal est que cela fonctionne.

J’ai l’habitude de rajouter un paramètre de lancement “Désactiver stop loss (pour data report)”, variable “p_desactiver_stoploss”. Quand ce paramètre est activé, les stop loss/take profit ne sont pas définis au niveau des trades ouverts.

Voici ce que cela donne au niveau de la fonction de fermeture des trades pour la gestion des stop loss:

if (PositionGetDouble(POSITION_SL) == 0 && !p_desactiver_stoploss)
{
m_trade.PositionModify(ticket,
MathRound(PositionGetDouble(POSITION_PRICE_OPEN) – p_stop_loss * m_symbolPointVal),
PositionGetDouble(POSITION_TP)
);
}
// Stop loss automatique au cas où la mise à jour du SL ait échoué
if (points_en_cours < -1 * p_stop_loss)
{
if (PositionClose(ticket, “SL”))
UpdateReporting(currentTrade, “SL”);
}

Il reste à créer la fonction de mise à jour du fichier de reporting:

void UpdateReporting(STrade &closeTrade, string exitSignal)
{
double points_en_cours;
if (PositionGetInteger(POSITION_TYPE) == POSITION_TYPE_BUY)
points_en_cours = m_symbol.Ask() – PositionGetDouble(POSITION_PRICE_OPEN);
else
points_en_cours = PositionGetDouble(POSITION_PRICE_OPEN) – m_symbol.Bid();
FileWrite(m_handle_file_trade,
datetime(PositionGetInteger(POSITION_TIME)),
TimeCurrent(),
Symbol(),
PositionGetDouble(POSITION_VOLUME),
PositionGetString(POSITION_COMMENT),
PositionGetInteger(POSITION_TYPE),
PositionGetDouble(POSITION_SWAP),
PositionGetDouble(POSITION_PROFIT),
points_en_cours,
closeTrade.points_max,
closeTrade.points_max / rates_d1[0].open * 100,
closeTrade.pertes_max,
closeTrade.pertes_max / rates_d1[0].open * 100,
exitSignal,
DoubleToString(m_data_infos[0]),
DoubleToString(m_data_infos[1]),
DoubleToString(m_data_infos[2]),
DoubleToString(m_data_infos[3]),
DoubleToString(m_data_infos[4]),
DoubleToString(m_data_infos[5]),
…. etc …
);
}

Ce n’est bien entendu qu’un exemple, à vous de constituer ce reporting avec les informations dont vous avez besoin, vos indicateurs préférés, etc…

Pour ma part j’aime bien avoir un aperçu des points max/pertes max durant la vie de chaque trade, car cela permet de voir les optimisations à apporter au niveau de la stratégie de sortie.

J’utilise aussi des commentaires à l’ouverture du trade mais aussi à la fermeture afin d’identifier les éléments déclencheurs d’une ouverture et d’une fermeture dans le cas de stratégies avancées.

Je pense avoir dit ici le principal.

Cet outil assez simple est particulièrement puissant et incontournable. Je l’utilise systématiquement pour être en mesure d’identifier les différentes configurations de marché, notamment celles qu’il vaut mieux éviter.

Avec l’habitude, on arrive parfois à lire le marché juste sur la base de ces données et sans même regarder la courbe, même si l’aspect graphique s’avère indispensable dans de nombreuses situations. Cela permet de détecter rapidement la présence d'”outliers” sur certains indicateurs, c’est à dire des valeurs inhabituelles permettant de comprendre que nous sommes dans une situation de marché particulière.

C’est cette complémentarité entre “datas” et “lecture d’un graphe” qui donne toute sa puissance à cette méthode. Cela permet d’apprendre au fil de l’expérience les configurations qui fonctionnent, et celles qui fonctionnent beaucoup moins. On découvre aussi que rien n’est aussi simple qu’il n’y paraît. Une configuration de marché peut nous sembler particulièrement dangereuse en analysant un cas particulier, mais en regardant de manière globale, sur un historique de 10 ans, et sur plusieurs actifs, on peut se rendre compte que c’est beaucoup plus subtil que cela, et que finalement, cela se passe plutôt bien dans la plupart des cas. C’est là où l’analyse des données collectées va nous aider à comprendre ce qui différentie un cas “qui marche”, d’un cas “qui ne marche pas”. Ce sera peut-être en regardant les gradients de moyennes mobiles, les distances à ces moyennes mobiles, ou d’autres indicateurs.

J’espère que cela vous aura été utile.

Optimiser la vitesse des simulations sous Metatrader

Nous allons voir maintenant comment booster radicalement la vitesse d’exécution de nos simulations via le testeur de stratégie de Metatrader.

Ce point est particulièrement crucial car pour mener à bien l’optimisation d’un robot de trading, on va être amené à lancer un grand nombre de simulations quotidiennement, ce qui n’est pas possible si chaque simulation prend plusieurs minutes, ou pire plusieurs heures.

Quand on débute sur Metatrader, puisqu’on manque d’éléments de comparaison, on peut trouver normal que cela dure plusieurs minutes, et s’y habituer.

Pour vous donner un ordre d’idée, je suis amenée à lancer plus d’une centaine de simulations sur plus de 10 ans chacune, par jour…. Chacune de ces simulations prend une trentaine de secondes. C’est donc une action que je peux exécuter très régulièrement afin de tester de nouveaux critères.

Cette vitesse d’exécution est un élément clé de la réussite de votre projet de développement d’un robot de trading.

Voyons maintenant comment optimiser ce processus:

Au niveau de la fenêtre de lancement de votre simulation, les paramètres clés sont les suivants:

  • Modélisation: “Prix d’ouverture uniquement”.
    Dans ce mode, le code ne sera exécuté qu’une fois par bougie et non pas à chaque tick, ce qui va réduire le temps d’exécution de manière considérable. Bien entendu, ce mode va entraîner une approximation des résultats obtenus, mais si votre stratégie est basée sur des échelles de temps en h1, h4, ou d1, cette approximation devient tout à fait acceptable. C’est un des autres grands intérêts de bannir les signaux sur les toutes petites échelles de temps. Vous avez toujours la possibilité, de temps à autre, de lancer une simulation sur chaque tick, mais plutôt en soirée pour que cela tourne tranquillement pendant la nuit…
  • Optimisation: décocher “mode visuel avec l’affichage des graphiques (…)”. Cette option est également très gourmande et devient inutile notamment si l’on génère des fichiers .csv avec l’historique enrichi de nos trades, point qui fera l’objet d’un autre article.

Un autre point important afin d’optimiser vos simulations se situe au niveau du code, notamment de votre façon de coder. Quand à mes débuts je cherchais comment accélérer mes scripts sur les forums de discussion, j’ai surtout vu des échanges concernant l’optimisation des indicateurs, mais selon ma propre expérience, l’impact est dérisoire par rapport aux conseils ci-dessus.

Toutefois, si vous êtes développeur, vous aurez probablement envie d’écrire un programme en utilisant à fond les concepts “orientés objets”, en créant de jolies classes que vous allez séparer dans des fichiers. Je vous déconseille vraiment de faire ainsi, car cela va ralentir considérablement l’exécution de vos scripts. Mieux vaut créer quelques fonctions que vous mettrez dans votre fichier principal et ne pas chercher à aller plus loin.
Donc, restez le plus simple possible dans vos scripts.

D’autres éléments peuvent venir ralentir vos scripts de manière importante.
Par exemple, le fait d’utiliser des bougies Heikin Ashi est extrêmement pénalisant.

Concernant vos indicateurs, personnellement j’en utilise un nombre assez important (4 moyennes mobiles, macd, rsi, bollinger, atr, sur toutes les échelles de temps entre MN1 et H1), et cela ne pose aucun problème. Je n’ai aucun scrupule à en rajouter quand j’en ai besoin.

Comme dit plus haut, si vous suivez ces conseils, une simulation sur 10 ans ne devrait pas excéder 30 secondes.