Author: stephanie

Le Money Management ou les incontournables parachutes de secours

Optimiser un robot c’est bien, mais croire que la couche d’optimisation sera suffisante et ainsi négliger la couche de money management, c’est un peu comme sauter en parachute, sans parachute de secours… C’est vrai que cela peut bien se passer la plupart du temps, mais est-ce une raison pour négliger la sécurité?

Nous allons voir ici à travers quelques exemples comment mettre en œuvre des couches supplémentaires, indépendantes de la couche d’optimisation, et dont le but ne sera pas d’augmenter les performances mais de réduire les risques pour tous les cas où l’optimisation aura failli à sa mission. Ces couches supplémentaires auront d’ailleurs souvent pour effet de réduire les gains théoriques. Il s’agit de l’éternelle rivalité entre performance et robustesse, 2 notions fondamentales dans tout système complexe.

Il s’agit ici d’observer le comportement de son robot, et principalement les situations où cela se passe mal. Le premier réflexe sera de revoir sa couche d’optimisation, et c’est important de le faire bien évidemment, mais il faut aussi prendre le temps d’analyser ces défaillances et de se demander comment on aurait pu gérer cela différemment, pour que les pertes subies soient réduites. Se poser ces questions et y trouver des réponses est fondamental car il y aura toujours dans l’avenir des situations qui ne seront pas traitées correctement par la couche d’optimisation.

Pour que l’on puisse rentrer dans le vif du sujet, je vais vous donner quelques cas concrets que j’ai mis en œuvre sur mon dernier robot Cassiopée EURUSD dont je vous parlerai plus en détail dans un prochain article.

Pour bien comprendre le contexte de ce robot, il est important de préciser que ce robot a une moyenne de 10 trades quotidiens, et un SL = 15 x TP, avec un % de trades gagnants dépassant les 95%. Les pertes sur SL sont donc redoutées, d’autant plus que le robot autorise plusieurs trades simultanés… Sur le papier, on pourrait se dire qu’une telle approche est trop risquée, mais comme je suis d’un naturel curieux, et au vu des performances très intéressantes que l’on peut espérer d’un tel robot, j’ai choisi de relever le défi. Et cela passe ici, inévitablement, par une réflexion très poussée sur tous les moyens que l’on peut mettre en œuvre pour éviter de se retrouver dans la situation fâcheuse de 5 trades simultanés qui courent vers leur SL….
Les parachutes de secours que je vais vous présenter ci-dessous sont donc adaptés à ce contexte particulier.

  1. Couples SL/TP phase optimisation et production différents
    L’une des premières bonnes pratiques en matière d’optimisation, à mon sens, est d’appliquer lors de la phase d’optimisation des valeurs à nos TP et SL plus restrictifs que ceux que l’on souhaitent appliquer en production. Cette bonne pratique n’est pas du money management à proprement parlé, mais je considère qu’il s’agit là du premier “parachute de secours”, que l’on doit prévoir au tout début de notre phase de développement.
    Si l’on reprend l’exemple de Cassiopée:
    – phase d’optimisation: TP = 1.5 et SL = 5
    – phase production: TP= 1 et SL = 15
    Cela va permettre, lors de la phase d’optimisation, de se concentrer sur les trades les plus intéressants, en excluant les trades perdants, et les trades gagnants de justesse. En pratique, le fait de multiplier le SL par 3 en production va permettre d’augmenter significativement le % de trades gagnants.
    On se retrouve toutefois avec un rapport de 15 entre le SL et le TP, ce qui va demander la mise en œuvre d’un money management bien réfléchi, c’est ce que nous allons voir par la suite.
  2. Augmentation de la taille de position suite à une perte
    Ce rapport de 15 entre TP et SL signifie qu’après une perte sur SL, 15 trades gagnants seront nécessaires pour récupérer. Toutefois, n’oublions pas que l’une des caractéristiques de ce robot est le % de trades gagnants très élevé, et c’est ce que nous allons mettre à profit ici par une méthode très simple: la multiplication par 2 de la taille de position pour les trades consécutifs à une perte. Ce ne sont alors plus que 8 trades gagnants qui seront nécessaires, et non plus 15. Dans la plupart des cas, cette technique sera profitable, mais il y a toujours un risque qu’une autre perte sur SL survienne alors que les tailles ont été augmentées. Ce risque doit donc être bien pris en compte lors du calibrage du robot, car on doit toujours appliquer la règle d’or: le dimensionnement d’un robot (détermination des tailles de position) doit se faire par rapport aux risques pris et non par rapport aux gains espérés!
    Pour ne pas rentrer dans le danger que représentent les martingales, ce palier x2 n’est appliqué qu’une seule fois.
  3. Clôture de trades perdants avant le SL si dépassement de l’objectif de gain journalier atteint.
    Cette approche est intéressante dans le cas de robots ayant des SL très importants par rapport au TP comme c’est le cas dans notre exemple. Les trades “foireux” vont ainsi traîner généralement plusieurs jours avant d’aller taper le SL ou de revenir sur le TP, ce qui laisse le temps d’intervenir dessus de multiples manières. Dans le cas d’un robot qui autorise plusieurs trades simultanés, la présence de ces trades foireux pendant une période de temps pouvant être assez longue ne va pas empêcher le robot de continuer à cumuler des gains. Un paramètre a ainsi été ajouté, permettant de définir le % de gains journaliers visé, que nous fixerons ici à 2%. On peut donc considérer que tous les gains cumulés au-delà de cet objectif sur les 10 derniers jours par exemple, représentent un pactole que l’on est libre d’utiliser à notre guise, notamment pour venir clôturer des trades “foireux” et ainsi abaisser le risque global régulièrement. Par exemple, on peut considérer qu’un trade dont les pertes dépassent le SL de 5 que l’on s’était fixé en phase d’optimisation représente un danger potentiel. Il est donc préférable de le clôturer si cela ne vient pas compromettre notre objectif de gains journaliers.

On observe ici l’illustration du comportement induit par les 2 méthodes précédentes, à savoir l’augmentation de la taille de position suite à une perte, et la clôture de trades “foireux” avant qu’ils n’aillent atteindre le SL qui leur a été assigné.

4. Augmentation du delta entre trades au-delà de 3 trades ouverts
Comme nous sommes dans le cas d’un robot autorisant de nombreux trades simultanés, la notion de delta de prix minimale entre trades a été ajoutée afin de ne pas ouvrir plusieurs trades sur un même niveau de prix, ce qui n’aurait pas de sens. Le problème rencontré fréquemment se situe lors des retournements de tendance, car le système peut alors ouvrir plusieurs trades en contre tendance, ce qui aura pour effet une augmentation du niveau de risque pas toujours très agréable à vivre. Pour limiter ces trades contre tendance de manière simple, on peut alors décider qu’au delà de 3 trades ouverts dans une direction donnée, le delta de prix minimal imposé sera multiplié par 3.

5. Détermination des niveaux de risque
Il s’agit ici d’une pratique un peu plus complexe à mettre en œuvre mais également très efficace.
La phase d’optimisation consiste à écrire des “arbres de décision“, chaque arbre contenant des “branches“.
Pour faire simple, un arbre correspond à une configuration de marché définie de manière assez générale. Par exemple, on va vouloir étudier les zones de marché où notre stochastique hebdomadaire a atteint la zone des 80/20, tout en présentant des signes de retracement et un placement pas très favorable par rapport à une moyenne mobile donnée.
Si l’on regarde une telle configuration sur un historique de données de 10 ans, on va obtenir un lot de trades dont certains seront perdants, et d’autres gagnants. L’optimisation de cet arbre peut alors commencer par la rédaction des “branches” qui vont permettre de définir des exceptions pour lesquelles les trades seront majoritairement gagnants. Les branches permettent donc de définir les situations d’exception pour lesquelles l’arbre ne sera pas appliqué.
La rédaction de ces branches passe inévitablement par l’observation des données passées, avec l’espoir qu’elles seront également pertinentes pour les données à venir.
C’est là que se situe le danger, car il y a une multitude de manières d’écrire une branche, en privilégiant tel ou tel critère, telle ou telle échelle de temps, etc… et surtout on va baser nos choix sur les trades à notre disposition, donc les trades passés. L’apparition de nouveaux trades peut potentiellement remettre en question les choix qui auront été faits. Ainsi, une branche peut se montrer défaillante si elle autorise le passage de trades perdants alors qu’ils auraient pu être bloqués si la branche avait été écrite différemment.
Ce risque de défaillance des branches sera toujours présent, malgré tout le soin que l’on pourra apporter à leur écriture.
Pour en réduire les effets potentiels, l’idée est donc d’évaluer le risque que représente chaque arbre avant que l’optimisation ne lui soit appliquée, c’est à dire avant la rédaction des branches, et d’appliquer des règles de trading différentes en fonction de ce niveau de risque.
Pour Cassiopée, j’ai ainsi défini 3 niveaux de risque:
– 1: risque faible: on applique les règles de trading normales
– 2: risque modéré: on abaisse les tailles de position de 25% par rapport à la normale
– 3: risque élevé: on abaisse les tailles de position de 25% par rapport à la normale, on n’applique pas de x2 suite à une perte, et on limite le nombre de trades à 1 par tranche de 12h
Reste maintenant à déterminer ces niveaux de risque pour chacun de nos arbres.

Ci dessus voici le type de fichiers qui peut nous aider dans cette tâche. Il représente les données statistiques collectées sur les 210662 trades de notre jeu de simulation, en fonction de chacun de nos arbres de décision.
Chaque arbre est codifié et peut être étudié de manière indépendante.
Par exemple, si un trade passe par l’arbre “JB05H2”, il aura environ 57% de chance d’être perdant (avant application des branches), ce qui est énorme. Nous sommes donc clairement dans une zone à haut risque, et devons rester très vigilant si jamais une branche de cet arbre venait à autoriser un trade. On va donc lui affecter un niveau de risque de 3.

Pour conclure ..

Pour terminer cet article, je voudrais revenir sur l’importance de distinguer les différentes phases de développement d’un robot de trading, que sont la phase d’optimisation visant à augmenter les performances, et la phase d’observation permettant l’élaboration des règles de money management adaptées à notre stratégie, et dont le but est d’augmenter la robustesse finale du robot (souvent en sacrifiant un peu de la performance théorique).
Les règles présentées ici ne sont que des exemples, d’autres parades peuvent être trouvées et mises en œuvre selon la stratégie adoptée par le robot, il s’agit de faire preuve de créativité, et de prendre le temps d’observer notre robot, et tout particulièrement les moments où les choses tournent mal.

On n’y reviendra jamais assez, mais c’est aussi pour toutes ces raisons qu’une phase d’observation/ajustement de plusieurs mois est nécessaire pour valider le comportement d’un robot et évaluer notamment sa robustesse en situation réelle (données temps réel sur compte démo).

Optimisation manuelle – IA – BILAN

Cela fait longtemps que je n’ai pas écris pour partager l’avancée de mes recherches, beaucoup de travail en parallèle en plus de mes robots, acquisition d’un grand terrain pour en faire une forêt comestible, et bien sûr tout le quotidien à gérer. Trouver le temps pour l’écriture n’est pas simple dans ce contexte, mais je pense qu’un bilan s’impose.

A l’heure de l’IA, j’ai moi même suivi une formation intensive de 9 mois en machine learning (python) afin d’y voir plus clair et d’être en mesure d’évaluer les apports de ces technologies dans le domaine du trading algorithmique.

Dans tout processus de décision, il est important de prendre en considération tous les éléments: techniques, financiers, contextuels, temps de formation/d’apprentissage/montée en compétence, affinité personnelle, etc…

Il est évident qu’un hedge fund avec des moyens financiers énormes et toute une équipe d’ingénieurs/analystes de haut niveau n’aura pas les mêmes contraintes qu’une mère de famille travaillant seule depuis chez elle 🙂 Les 2 pourront donc très probablement être amenés à faire des choix différents pour la résolution d’un même problème, sans que cela signifie que l’un des deux ait forcément tort.

L’objectif que je me suis fixé il y a quelques années était donc de développer une méthode et des outils simples, impliquant peu de ressources informatiques, s’appuyant sur des logiciels/plateformes gratuits, et permettant de développer assez rapidement des robots de trading performants. Une méthode accessible au plus grand nombre donc, ce que l’IA ne permet pas à mon avis.

L’idée était de remplacer les algorithmes de machine Learning et la puissance de calcul qu’ils nécessitent par de l’intelligence humaine et du bon sens.

Pour illustrer mon propos, je citerai l’exemple donné par un expert en IA (dont j’ai oublié le nom et je m’en excuse), qui précisait que pour entraîner un algorithme à la reconnaissance de chats, il fallait lui fournir des centaines de milliers d’images. A contrario, sa filleule de 4 ans avait développé cette capacité en quelques instants quand on lui avait montré une seule photo de chat…

J’ajouterai à cela la problématique des biais sur les données qui n’est pas à prendre à la légère. Par exemple, si l’on souhaite qu’un algorithme apprenne à faire la différence entre un chien et un loup, on va lui montrer évidemment des photos de chien et de loups que l’on va étiqueter “chien” ou “loup”. Mais si tous nos chiens portent un collier ou sont couchés sur un canapé, l’algorithme prendra cela comme étant une caractéristique déterminante alors que cela n’est pas le cas. Un humain le comprend d’emblée intuitivement, alors que l’algorithme n’en sait rien. En matière de trading, il est important de comprendre comment ces algorithmes de machine learning fonctionnent, pour ne pas se faire duper et leur prêter une intelligence qu’ils n’ont pas forcément. Il n’y a qu’en comprenant leur fonctionnement, leurs points forts et leurs faiblesses, que l’on peut espérer en tirer le meilleur parti. Mais si on ne leur mâche pas correctement le travail, il est clair que le résultat ne sera pas à la hauteur de nos efforts et de nos espérances.

Un autre point important concerne les jeux de données à leur fournir. Est-ce que 10 années suffisent? j’en doute. Hors en pratique il est difficile d’avoir accès à des jeux de données précis et gratuits qui soient supérieurs à 10 ans. On peut envisager de fusionner plusieurs jeux de données, par exemple en prenant plusieurs actifs différents mais proches en émettant l’hypothèse qu’ils réagissent de manière identique. On peut aussi prendre des jeux de données d’un même actif mais de brokers différents, ou en modifiant les heures. Des parades sont possibles, mais seraient elles suffisantes? Question très difficile à répondre car cela nécessite de faire de nombreux essais, et donc beaucoup de temps de R&D.

L’autre point crucial lié aux biais est qu’il ne faut pas oublier que des trades peuvent être perdants tout en étant bien positionnés et parfaitement exécutés (on n’est jamais à l’abri d’un mouvement brutal instantané avant que le cours ne revienne à la normale). Ces trades perdants par manque de chance ne devraient pas être pris en considération par les algorithmes. De même que les trades gagnants “par chance”.

Mon propos n’est pas de dire que l’IA n’est pas adapté au trading, car ce n’est pas du tout ce que je pense, mais plutôt de dire que c’est loin d’être une solution abordable et facile d’utilisation comme quelques influenceurs aiment à le laisser croire. Les pièges sont nombreux et il faut avoir les moyens humains, financiers, et temporels pour espérer les solutionner.

Suroptimisation/Sous-optimisation

Par peur de la suroptimisation, beaucoup ont renoncé à l’idée d’optimiser leur algorithme, et recherchent donc un “alpha”, c’est à dire un signal le plus simple possible (certains se fixent des limites sur le nombre de critères à 4 ou 5), qui seraient globalement gagnant. Par peur de la suroptimisation, ils sont alors dans de la sous-optimisation. Est-ce mieux? j’en doute. Cette quête d’une formule magique simple pouvant résoudre un problème d’une telle complexité me semble comparable à la recherche d’une aiguille dans une botte de foin. Je ne dis pas que c’est impossible, je n’aurais pas cette prétention, mais je suis sûre que c’est une tâche très complexe, chronophage et aux résultats très aléatoires. C’est pour cette raison que j’ai préféré me concentrer sur la recherche d’une méthodologie qui une fois au point, pourrait permettre de manière certaine d’obtenir un robot prometteur en un laps de temps déterminé. “Prometteur” dans le sens “digne ‘intérêt”.

La suroptimisation est un réel problème, car il faut bien comprendre que l’on peut très facilement développer un algorithme avec un facteur de profit énorme, testé sur 10 ans, et pourtant, une fois sur des données temps réel, donnera des résultats catastrophiques. Et je sais de quoi je parle 😀

Si vous souhaitez acquérir un robot de trading, demandez toujours à avoir des historiques temps réel ou bien une période d’essai. Les résultats d’une simulation n’ont aucune valeur malheureusement.

Malgré ces risques de suroptimisation, je suis restée convaincue que l’optimisation était une voie prometteuse. C’est juste qu’il faut prendre le temps, apprendre de ses erreurs, et tenter de comprendre comment écrire des critères à la fois efficaces et robustes.

Il faut par exemple bien comprendre ce qu’est la notion de “bruit” en trading. On pourrait dire que le bruit correspond aux mouvements spontanés qui apparaissent sur les petites échelles de temps et qui sont très difficiles à prédire car quasiment erratiques. Au-dessus de ce bruit, on va trouver des tendances plus faciles à identifier et donc à suivre. On va identifier aussi des patterns reproductibles, l’analyse technique pouvant être très précieuse à ce niveau. On peut comprendre intuitivement qu’écrire des critères qui sont situés dans la zone de bruit peut-être très dangereux. De la même manière, il faut être en mesure d’estimer la largeur moyenne de la bande de bruit afin de pouvoir positionner notre SL au-delà, avec une marge de sécurité. Sinon on peut être certain que même la meilleure optimisation ne pourra pas empêcher les déclenchements intempestifs et inappropriés du SL. Donc si l’on cherche à optimiser un robot de trading => il faut impérativement se mettre hors de la zone de bruit.

Pour parler un peu plus concrètement, avec les années d’expérience désormais derrière moi, et sans compter les nombreuses années qui vont suivre!, j’arrive désormais à produire 1 robot par mois, en travaillant dessus partiellement les soirs et week-end. Je travaille sur un PC ce qu’il y a de plus normal, avec des logiciels gratuits ou presque (metatrader, et Excell). Sur ma dernière génération de robots, j’ai pu augmenter le nombre de trades d’étude de manière très significative puisque je pars d’un nombre de trades dépassant les 60000 (j’étais au préalable plutôt en dessous de 10000). Sur cette base de trades, je recherche les patterns à haut risque afin de les exclure. J’écris ainsi manuellement des “arbres de décision” qui me permettent d’exclure progressivement des configurations de marché, et sur ces 60000 trades, je vais finalement en garder 10000 environ, ce qui va représenter tout de même 1000 trades par année environ, ce qui reste très intéressant. Ces 10000 trades restants correspondent donc aux configuration de marché qui, statistiquement parlant, pour les TP/SL déterminés, ont la plus forte probabilité de succès.

Avec l’expérience, cette méthode vous permet de coder votre robot avec une bonne série Netflix en tâche de fond 🙂

Autre point intéressant, le signal d’entrée n’a plus vraiment d’importance. Au contraire, on cherche à avoir un grand nombre de trades afin de “scanner” le marché de la façon la plus précise possible. Tout signal d’entrée applique une restriction drastique du nombre de trades et nous fait rentrer dans l’étude d’un cas particulier. Et comme dit plus haut, moins il y a de trades à analyser, moins robustes seront nos arbres de décision.

Théoriquement, on pourrait se passer complètement de signal d’entrée, et je pense que je vais progressivement tendre vers cela d’ailleurs. La seule difficulté est humaine: comment arriver à analyser, humainement, des centaines de milliers de trades? Il y a bien évidemment un seuil au-delà duquel il devient indispensable d’avoir recourt à des algorithmes d’analyse pour mâcher le travail, des algorithmes qui arriveraient à prendre le meilleur de l’humain et le meilleur de l’IA pour les faire travailler ensemble. Réflexion en cours!

Mais je pense que jusqu’à 200.000 trades, l’analyse peut encore se faire sur Excell, à condition d’avoir quelques années d’expérience derrière soi.

Sur la base de mon expérience passée, je dirais qu’il faut écrire généralement une centaine d’arbres de décision pour arriver à faire un tour assez complet des différentes situations de marché. Mais rien n’empêche d’aller au-delà. Ces critères vont bien entendu utiliser plusieurs échelles de temps, et principalement les plus élevées: monthly, weekly, dayly, h12, parfois h4/h2/h1 si requis mais modérément car on rentre progressivement dans la zone de bruit. Ces critères vont souvent rechercher les valeurs de certains indicateurs combinés avec le positionnement . Par exemple, à la vente, le RSI weekly a atteint la limite des 30, la mm 2 en dayly est défavorable et indique un retournement et de plus le cours est situé en dessous de la mm2. On peut regarder des croisements de moyenne mobile, de stochastique, de macd, des pentes de mm très défavorables, etc…. tout est envisageable, à condition de rester en dehors de la zone de bruit, de penser à normaliser ses mesures, et de rester le plus généraliste possible. Le fait de disposer d’un grand nombre de trades va permettre d’en “sacrifier” beaucoup, de rester généraliste, et donc de limiter la suroptimisation.

L’autre question qui fâche est : “comment savoir si un algorithme de trading est rentable ou non?“. Pendant mes longues études ainsi que durant ma vie professionnelle en tant qu’ingénieur, j’ai toujours appris que : “ça marche” ou “ça ne marche pas”. Quand vous développez une application, vous vous rendez très vite compte si cela fonctionne ou non, surtout si une magnifique erreur 500 apparaît sur votre navigateur. C’est clair, rapide et sans discussion possible.

Mais en trading… c’est une toute autre histoire. Bienvenu dans le monde merveilleux de la probabilité! Ce robot est-il rentable? Probablement 😀 Au mieux pourra-t-on dire qu’il a été rentable les 6 derniers mois mais comme les performances passées ne présument en rien des performances à venir… on est bien avancé là.. J’ai ainsi eu des cas de robots avec des performances incroyables en temps réel pendant plusieurs mois, puis les performances s’inversent et ne remontent pas. Ou inversement, des robots qui ont eu des départs décourageants, puis se sont mis à performer. Il est très difficile d’y voir clair dans ces conditions.

De plus, quand on lance une simulation sur 10 ans, cela prend quelques secondes ou minutes, donc on peut avoir une vision globale instantanément. Mais dans la vraie vie, 10 ans, cela prend 10 ans…

Une question primordiale à se poser est donc: “quelle est la durée minimale d’exécution en temps réel qui va me permettre d’évaluer les performances d’un robot?”. 6 mois, 1 an, 2 ans? Vous le comprenez maintenant, parmi les qualités indispensables d’un algo-trader, on trouvera la patience et la persévérance! Pour ma part, je considère désormais qu’il faille un minimum de 1 année. Bien sûr, sur les nombreux robots “prometteurs” tous ne valideront pas leurs performances sur la durée. D’où l’intérêt d’avoir une méthodologie efficace permettant de développer des robots régulièrement. Méthodologie qui s’améliorera toujours au fil du temps. On augmente ainsi nos chances d’obtenir LE robot ultime, celui dont les performances sont régulières dans le temps et dans lequel vous avez suffisamment confiance pour lui confier de gros capitaux.

Se lancer dans l’algo trading et espérer aboutir à des résultats concrets en quelques mois peut être source de grandes désillusions, surtout si vous partez sans formation/accompagnement adapté qui vous ferait gagner certainement plusieurs années. Si on m’avait appris dès le départ tout ce que je sais maintenant par la force de l’expérience, j’estime que j’aurais gagné 3 années d’efforts…

Quelques mots maintenant pour dire où j’en suis de mes recherches.

Je dois avoir une bonne dizaine de robots que je suis de près et qui me semblent prometteurs, avec des résultats encourageants depuis plusieurs mois. Nasdaq, DJ30, Gold, BTCUSD, plusieurs paires Forex. Désormais, la grande majorité des robots sortis sont prometteurs, ce qui représente une réelle avancée par rapport à il y a 1 an et me conforte dans le fait que je suis dans la bonne direction. Par “prometteur” j’entends que les performances obtenues sur les premiers mois sont assez proches des performances sur période d’optimisation. Mais pour l’instant le cap des 1 an n’a pas encore été franchi. Prudence et patience sont de mise comme toujours!

A titre d’exemple, ci-dessus les résultats obtenus pour les 2 premières semaines d’exécution du dernier né “Phoenix_XAUUSD”, avec un beau score de 12% conforme aux résultats de simulation. La stratégie utilisée consiste à prendre un SL 10 fois supérieur au TP. Le % de trades gagnants doit normalement dépasser les 90%, ce qui rend cohérent le doublement de la taille des positions pour les trades consécutifs à une perte. Ainsi, bien que l’on ait un SL 10 fois supérieur au TP, seuls 5 trades sont nécessaires pour récupérer une perte. Stratégie qui fonctionne très bien dans la majorité des situations, mais bien évidemment, il reste possible que 2 pertes voire plus s’enchaînent. Il faut toujours garder à l’esprit que ces situations peuvent se produire et donc rester modeste sur le choix des tailles de positions initiales. Toujours dimensionner ses trades par rapport au risque pris et non aux gains espérés même si c’est très tentant! La fréquence des trades obtenue ici (en moyenne 3 trades/jour) permet d’augmenter les performances mais aussi de se rendre compte plus rapidement des performances réelles du robot. Si l’on s’attend à + de 90% de trades gagnants et qu’il enchaîne les pertes, c’est à coup sûr que quelque chose ne va pas et il ne sera pas nécessaire d’attendre 6 mois pour s’en rendre compte. Mais comme toujours, 2 semaines de résultats ne veulent pas dire grand chose. Un robot qui monte vite peut descendre bien plus vite encore, il ne faut jamais l’oublier. D’où l’importance de prendre son temps avant de passer sur de l’argent réel.

Ayant désormais un nombre important de robots en test et sous étroite surveillance, parmi lesquels j’ai espoir de voir émerger quelques champions (il est important de rêver !), je vais maintenant me pencher beaucoup plus sérieusement sur les modes d’exécution via Metatrader, car je me suis laissée un peu débordée par mes élans créateurs… Faire tourner en temps réel autant de robots n’est pas aussi simple qu’il n’y paraît car de toute évidence, Metatrader gère très mal cela… (beaucoup de trades ne sont pas pris lorsque plusieurs robots tournent sur un même Metatrader ), et l’espace disque requis est devenu important. Bref, ce point sera ma priorité pour la rentrée 2025, date à laquelle j’aurais sûrement plus de temps à consacrer au trading.

J’essaierai d’être plus régulière dans la mise à jour de ce blog. J’espère aussi pouvoir proposer des formations/accompagnements pour transmettre tout ce que j’ai appris. Je crois fermement en la richesse des échanges, et aux bénéfices réciproques!

A très bientôt j’espère!

Stéphanie

Stop Loss or not Stop Loss?

La question mérite sérieusement d’être posée.
Le choix des Take Profit et des Stop Loss fait partie des facteurs déterminants d’une stratégie de trading, leur choix doit ainsi se faire très tôt dans le travail de réflexion. Ce sont eux qui permettent de définir si un trade sera gagnant ou perdant, et de combien.

De leur choix va découler de nombreuses autres mesures, telles que le % de trades gagnants, le ratio gains/pertes, et donc la rentabilité ou non de la stratégie.

Certaines stratégies vont rechercher des gains importants par trade, en limitant les pertes au maximum, et en contre-partie vont accepter un % de trades gagnants faible.

D’autres vont autoriser des Stop Loss élevés par rapport au TP de manière à favoriser au contraire un % de trades gagnants élevé.

D’autres encore vont carrément ne pas mettre de Stop Loss, à charge du trader de choisir au cas par cas quand il faut couper un trade perdant ou quand on prend le risque de le laisser filer. Mieux vaut ne pas être trop anxieux dans ces cas…

En matière de trading algorithmique, le choix est particulièrement crucial.
Rien de plus rageant que de perdre une série de trades, qui nous fait remettre en question tout notre travail de recherche, puis se rendre compte que sans Stop Loss, ces pertes se transformaient en de magnifiques gains…

Ces derniers mois m’ont ainsi amenée à une réflexion poussée sur la notion de Stop Loss, qui parfois nous fait perdre tant de trades qui auraient été gagnants, tout en nous rassurant en imposant une limite.

Toutes les simulations que j’ai pu réaliser avec différentes stratégies, et sur différents actifs, sur plusieurs années, menaient toutes à la faillite du compte quand il n’y avait aucun StopLoss configuré. Son importance n’est donc pas à négliger.

Bien entendu, on peut tout à fait considérer qu’une faillite tous les 6 mois est un risque acceptable dès lors que l’on double son capital chaque mois. Encore faut-il que les tendances ne s’inversent pas.

Un bon compromis me semble donc de définir un Stop Loss élevé par rapport au Take Profit, ce qui permet généralement d’atteindre facilement un % de trades gagnants > 90%.

Il reste ensuite à trouver le moyen de gérer les pertes au mieux, ce qui peut se faire de différentes manières:

  • optimisation des points d’entrée: éviter les zones de trading à haut risque est la première des mesures à prendre pour limiter les trades perdants
  • utilisation d’une martingale LEGERE (il ne s’agit pas d’aggraver les choses de manière démesurée), afin de recouvrir les pertes plus rapidement. L’idée est donc d’augmenter le risque (taille des positions) sur une courte période consécutive à la perte avant de revenir à un niveau de risque normal.
  • utilisation d’un stop loss “global” dans le cas où plusieurs trades simultanés sont autorisés. Le Stop Loss ne va alors plus s’appliquer à chaque trade individuellement mais à l’ensemble des trades. La conséquence en est une diminution très nette du risque encouru.

Ces différentes mesures ne sont qu’un exemple de ce qu’il est possible de faire afin d’améliorer les performances d’un robot sans pour autant augmenter le risque de manière démesurée.

J’ai commencé à travailler sur une nouvelle gamme de robots, la gamme “Morpheus”, inspirée de ces réflexions avec des résultats très encourageants que je vous laisse découvrir ici !

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.

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.

Stratégie de trading: Stop Loss, Take Profit et taille des positions

Lors de l’élaboration de votre stratégie de trading, une fois le timeframe de référence de vos signaux choisi , vous devez spécifier la valeur de votre Stop Loss, de votre Take Profit ainsi que la taille de vos positions.

Ces 3 valeurs sont des valeurs particulièrement interconnectées. Leur choix définitif sera probablement fixé après de nombreux essais, et pourront varier au fil des optimisations réalisées. En effet, plus votre % de trades gagnants va augmenter, et plus vous allez peut-être vous autoriser à augmenter votre stop loss. On peut qualifier ces informations d'”hyper paramètres” tant leur impact sur la performance du robot est importante.

Une bonne habitude est donc de les mettre en paramètres de lancement du robot afin de pouvoir les modifier par la suite plus aisément et ainsi tester différentes valeurs.

Voyons ce qu’il est important de savoir à ce sujet.

Tout d’abord, c’est votre stratégie de trading, qui a été privilégiée sur une échelle de temps donnée, qui va vous suggérer un objectif à atteindre. Cet objectif peut être exprimé de différentes manières: en points, ou en % de variation du prix de votre actif. Il peut être un objectif “rigide”, qui va se traduire par un Take Profit au niveau de vos positions, ou bien un objectif au-delà duquel va être appliqué un Trailing Stop, ou bien il va s’agir d’un objectif minimum au-delà duquel des signaux de sortie seront examinés (traversée moyenne mobile par exemple). Quelle que soit la manière dont va être utilisée cet objectif, il est préférable d’en avoir un car c’est lui qui va permettre de définir les autres paramètres tout aussi important pour notre robot.

Une fois notre objectif (strict ou minimum) défini, nous pouvons définir notre stop loss. L’occasion d’introduire une notion fondamentale, le Risk Reward, qui représente le ratio entre la perte potentielle d’un trade et son gain potentiel. Nous allons forcément chercher à avoir un Risk Reward le plus faible possible, tout en restant cohérent avec notre stratégie. Donc si par exemple vous avez un TP de 100, avec un SL de 50, vous obtenez un Risk Reward de 0.5 ce qui n’est pas si mal. Pour être rentable, votre stratégie devra alors avoir un WinRate d’au moins 33% (1 trade gagnant pour 2 trades perdants).

Vous l’aurez compris, les valeurs optimales de nos Take Profit et Stop Loss ne seront connues avec précision qu’une fois le robot déjà bien avancé, car nous devons connaître notre WinRate, dont la valeur va s’améliorer au fil des optimisations.

Il reste maintenant à fixer la taille de nos positions. Une bonne pratique est de déduire cette valeur de celle du Stop Loss, qui représente la perte maximale risquée (théoriquement…) pour chaque position ouverte. Ce qui vous intéresse réellement est de savoir quelle proportion en % de votre capital vous risquez à chaque trade ouvert. Ainsi, si vous risquez 50 points, en étant prêt à perdre 1% de votre capital, vous pourrez en déduire la taille de votre position.

Le fait de déduire la taille de vos positions de la valeur de votre Stop Loss et du Risk Ratio (% du capital à mettre en jeu) présente plusieurs avantages. Vous pouvez par exemple vouloir adapter votre stop loss à la situation du marché (stop loss variable déterminé sur une moyenne mobile, un high/low d’un bougie précédente ou une valeur d’atr), auquel cas la taille de vos positions s’adaptera automatiquement. Ensuite, vos tailles de positions vont suivre l’évolution de votre capital (qu’elle soit favorable ou pas), ce qui est aussi très important durant les simulations.

Ci-dessous une fonction pratique que j’utilise (Metatrader) pour calculer le montant des positions à ouvrir.

// CODE MQL5 pour Metatrader
//+——————————————————-+
//| Calculate Max Lot Size based on Maximum Risk |
//+——————————————————-+
double dblLotsRisk( double dbStopLoss )
{
double
dbLotsMinimum = SymbolInfoDouble( _Symbol, SYMBOL_VOLUME_MIN ),
dbLotsMaximum = SymbolInfoDouble( _Symbol, SYMBOL_VOLUME_MAX ),
dbLotsStep = SymbolInfoDouble( _Symbol, SYMBOL_VOLUME_STEP ),
dbTickSize = SymbolInfoDouble( _Symbol, SYMBOL_TRADE_TICK_SIZE ),
dbTickValue = SymbolInfoDouble( _Symbol, SYMBOL_TRADE_TICK_VALUE ),
dbValueAccount = fmin( fmin(
AccountInfoDouble( ACCOUNT_EQUITY ) ,
AccountInfoDouble( ACCOUNT_BALANCE ) ),
AccountInfoDouble( ACCOUNT_MARGIN_FREE ) ),
dbValueRisk = dbValueAccount * p_risk_ratio_1 / 100,
dbLossOrder = dbStopLoss * dbTickValue,
dbCalcLot = fmin( dbLotsMaximum, // Prevent too greater volume
fmax( dbLotsMinimum, // Prevent too smaller volume
round( dbValueRisk / dbLossOrder // Calculate stop risk
/ dbLotsStep ) * dbLotsStep ) ); // Align to step value
return ( dbCalcLot );
}

Stop Loss et Take Profit en % plutôt qu’en points

Une dernière notion très importante à comprendre. J’en ai parlé brièvement plus haut. Lors de la définition de vos Stop Loss et Take Profit, vous avez le choix entre l’utilisation de Points, ou de % de la valeur de votre actif.

Pourquoi privilégier les % ?

Les données financières sont des données “non stationnaires”, c’est à dire que leur valeur peut évoluer grandement au fil du temps. Un actif qui vaut 10000$ aujourd’hui en valait peut-être le tiers il y a 10 ans de cela.

Ainsi, on peut intuitivement comprendre que si un objectif de 100 points est réaliste pour un actif qui vaut 10000$, il l’est peut-être déjà beaucoup moins sur le même actif quand il en valait 3000$…

Cela pose de sérieux problèmes si vous souhaitez tester votre stratégie sur un historique de données de plusieurs années. D’où l’intérêt de définir votre objectif comme étant égal à 1% de la valeur de votre actif, plutôt que comme valant 100 points.

Ci-dessus un exemple des paramètres de lancement d’un robot sous Metatrader.

On y trouve en premier lieu le Risk Ratio % qui permet de définir le montant du capital mis en jeu à chaque trade.

Les TP et SL sont eux aussi définis en %.

Définis de cette manière, ces paramètres de lancement vont suivre l’évolution du capital ainsi que l’évolution de prix de l’actif au fil du temps.