Plateforme de trading auto avec IG

Bonjour,

Après quelques mois passés sur prt et le trading auto avec ProBuilder, j'ai décidé de créer une plateforme de trading auto en passant directement par l'Api IG. Cette API est découpée en deux parties, une partie RESTful pour l'envoi de commandes (récupération des marchés, historiques, prise et fermeture de positions...) et une partie en Streaming principalement pour récupérer les cotations en temps réel.

Plusieurs langages sont proposés en exemple, je suis donc parti des exemples fournis en Java (mon domaine). L'implémentation en exemple s'appuie sur le framework Spring qui traduit les requêtes RESTful en classes Java. Après une étude détaillée des exemples, j'en suis venu à abandonner l'usage jugé trop brouillonne en terme d'organisation objet et pas assez performante... J'ai donc refait tous les accès RESTful sans passer par leur exemple en effectuant des tests au cas par cas, cela n'a pas posé de problème.

Pour la partie Streaming, une API est imposée, les ticks sont reçus sans problème une fois que l'on a bien choisi le code epic du marché. La plateforme que j'ai développé les traduit automatiquement en Bougie selon différentes tailles déterminées par le demandeur. Point négatif côté ig, l'historique n'est pas disponible en ticks, il faut donc stocker les ticks en permanence.

La plateforme n'est pas encore opérationnelle, elle permet actuellement de :

- Choisir un ou plusieurs marchés (un robot par exemple pourrait parfaitement switcher d'un marché à l'autre)
- Recevoir les ticks avec conversion en chandeliers selon la dimension voulue (plusieurs dimensions simultanées possibles)
- Calculer le rsi selon différentes périodes
- Prendre une position au marché à l'achat/vente et clôturer la position
- Toutes les positions se font avec un stop garanti et une limite.

Cela paraît bien pauvre en comparaison de ProBuilder mais c'est déjà pas mal de chose en plus : tick, multi-dimensions, stop garanti...

A suivre ...

Le SLG et le multidimension c'est très bien, par contre les ticks sont pris en compte dans la dernière version de prt. Bon courage pour la suite !

Je te rejoins : Les requetes REST n'ont pas besoin d'être transformé par un outil. La "simplicité" des requetes est assez facile à interpreter et à la mettre dans des fonctionns spéciques voir pas du tout.

Pour le lightstream, là il est plus aisé de s'appuyer sur une biblio déjà existante, le boulot pour tout ré-écrire étant plus conséquent.

Mis à part les ticks qui ne sont pas dispo dans l'historique, je trouve les API bien plus "fine" dans la gestions des tickets que prt.

Nor-mal la population visée n'est pas la même.

Avantage à prt, le flux de données est de bien meilleurs qualité.

Donc tout dépend de quelle vitesse tu as besoin pour tes trades.

Bonjour à tous,

@plataxis merci pour l'info concernant les ticks, bizarre car on les a bien en backtest, mais je n'ai pas vu qu'il était aussi dispo en réel. Merci pour l'encouragement cela fait plaisir.

@falex, oui l'exemple est un piège à débutant selon moi car l'auteur ne s'est concentré que sur l'aspect technique des accès en générant tout un bazard de classes parfaitement inutiles. Par contre ce que tu me dis sur les flux de données sous prt plus rapide m'étonne (sauf si cela tourne sur leur serveur à priori), je n'ai pas comparé avec prt mais j'ai fait tourné en parallèle le site ig et les ticks reçus, à l'oeil nu c'est beaucoup trop rapide pour que je puisse voir de la latence donc on est largement sous la seconde en réactivité déjà. Si j'arrive à construire quelque chose qui tienne la route , je ferais en sorte que le code tourne proche de leur serveur de toute manière...

A suivre !

Bonjour,

Quelques évolutions de la plateforme réalisées ;

- TP/Stop en discrétionnaire avec contrôle de la fiabilité en positions aléatoires avec ig
- Robots coopérants par marché à N états
- Un premier robot fonctionnant via un biais statistique, il est très bête dans son fonctionnement mais il est tout même assez original par rapport au codage sous ProBuilder
- Backtests avec étude combinatoire des paramètres de robot

Je n'ai pas fait de gros efforts sur le robot qui fonctionne à des fins d'étude de la plateforme, malgré tout il donne des résultats pas si mauvais... Le test n'a été effectué que sur le mois de mai avec étude d'une limite idéale. Le backtest donne également un retour sur les positions perdantes qui auraient pu devenir gagnantes en coupant plus tôt. Le prochain objectif va être de faire tourner le tout en continu et voir si la plateforme est assez robuste.

Le robot de test à un taux de réussite de 65% et gagne 46 points en mai. Ce n'est bien sûr pas significatif sur un backtest aussi court mais cela donne un aperçu. Les avantages par rapport à prt commencent à se dessiner :

- Les backtests en ticks ne se limitent plus à quelques jours
- Le combinatoire reste possible pour évaluer les meilleurs paramètres des robots en tick sur une période assez vaste sans prendre trop de ressource, mais là aussi il existe très certainement des systèmes pour converger vers des solutions plus optimales
- Les backtests sont très rapides de l'ordre de quelques secondes par mois.
- Le codage hors du langage ProBuilder offre beaucoup plus de souplesse.

A suivre...

Bonjour,

Petites évolutions de la plateforme :

- Backtests journaliers,mensuels et annuels
- DD disponible
- Mode "bad result" pour créer un backtest dérivé de toutes les erreurs, les erreurs se cumulent et se suppriment automatiquement selon les résultats / améliorations.
- Système de monitoring pour l'instant console mais des graphiques sont prévus pour mieux comprendre ce qui se passe.

J'ai continué à améliorer les réglages du robot témoin :

BACKTEST YEAR 2016
TOTAL=-26,40Pts WIN=180 LOST=23 DD=29,50Pts RATE=88,67%

BACKTEST YEAR 2017
TOTAL=82,10Pts WIN=72 LOST=4 DD=79,80Pts RATE=94,74%

BACKTEST BAD 2017
TOTAL=-76,80Pts WIN=0 LOST=4 DD=0,00Pts RATE=0,00%

Le BAD 2017 correspond à la construction d'un backtest avec toutes les erreurs, il ne reste plus qu'à relancer le backtest dans ce mode pour essayer de filtrer le plus d'erreur possible sans impacter avec les bonnes positions ce qui est finalement compliqué. Il faut de toute manière s'attendre à ce que le robot échoue à certains moments.

Après quelques réglages dans les "Bad result" délicats le robot semble plus fiable...

BACKTEST YEAR 2016
TOTAL=147,80Pts WIN=103 LOST=10 DD=144,80Pts RATE=91,15%

BACKTEST YEAR 2017
TOTAL=77,00Pts WIN=24 LOST=0 DD=74,30Pts RATE=100,00%

A noter que même en cas de coupure internet, ou autre après une prise de position, cela n'impacte pas les performances.

Il ne prend pas beaucoup de positions mais s'il arrive à conserver ce niveau de réussite je serais déjà content et pourrait passer au développement de nouveaux robots.

Prochaines étapes :

- Location d'un serveur
- Exécution en autonome de la plateforme
- Suivi en démo pendant 1 mois

A bientôt

Bonjour,

Quelques évolutions de la plateforme selon le temps dispo (soupir) :

- Backtests en micro et macro mode pour distinguer un robot d'un panel de robots
- Système de premier niveau pour détecter des anomalies de ticks et arrêter les robots
- Chaque robot est indépendant de la plateforme et paramétré en XML, ils sont "pluggables" dans la plateforme qui se charge de l'assemblage final.

Il reste encore pas mal de travail pour en faire une plateforme solide et n'ayant encore jamais fait de fonctionnement en démo/réel, le résultat à suivre est encore incertain. Pour l'instant je me concentre uniquement sur la plateforme plutôt que sur les robots qui suivront, tant que je ne suis pas sûr d'avoir quelque chose qui résiste "aux chocs" et qui me donne un bon suivi, je reste en test.

Concernant le passage de prt à l'Api IG, le sentiment de liberté est vraiment appréciable par contre je dirais si vous n'avez pas un bon niveau en développement, il vaut mieux se concentrer sur prt/MT4.... ou bien se former sérieusement surtout en terme objet (c'est un développeur avec 20 ans de dev. en back et font office qui le dit...), réaliser une plateforme solide et facilement évolutive ne s'improvise pas.

A suivre

Quelques améliorations de la plateforme :

- Arrêt automatique à heure fixe ou bien en cas de problème
- Si une perte maximummale est atteinte, la plateforme s'arrête
- Monitoring étendu à tous les marchés, tous les robots et toutes les positions, la plateforme stocke toutes ces informations sur le disque dès qu'elle s'arrête chaque jour.
- la plateforme est maintenant autonome et exécutable via un simple batch, un répertoire de travail avec sa configuration et les marchés/robots autorisés sont alors pris en compte au démarrage, comme tous les répertoires sont relatifs cela marche n'importe où.

Comme la plateforme dispose de suffisamment d'éléments pour tourner, j'ai créé un compte aws chez amazon, puis j'ai choisi une instance ec2 à dublin pour l'instant gratuite mais je ne connais pas le délais avant paiement.

Pour l'installation de la plateforme, j'ai choisi un accès FTP sécurisé (pas envi qu'on me pique mon code sur le net), il faut définir un groupe de sécurité côté AWS, l'associer à l'instance, autoriser les ports 20/21 en entrée/sorties. Pour le service FTP je suis passé par IIS, j'ai associé le serveur à un répertoire en autorisant un compte utilisateur windows dédié. Cette partie d'administration m'a demandé quelques heures avant de fonctionner.

La transfert de la plateforme s'est faite par filezilla mais j'espère pouvoir tout automatiser en ligne de commande.
Pour l'exécution de la plateforme j'avais deux choix :
- La faire tourner 100% du temps,
- Ne l'activer qu'en début de journée et la laisser se fermer toute seule. J'ai choisi cette configuration qui semble la plus fiable même en cas de crash. Il suffit de créer une tâche planifiée en précisant bien les horaires d'exécution et faire une exécution hors connexion utilisateur et les priorités.

Voilà la plateforme est maintenant autonome, il n y a que le robot témoin qui tourne..., y a plus qu'à voir si tout cela tient la route en démo.

A suivre !

Que de chemin parcouru depuis tes premiers robots sur prt ^^`

J'ai hâte de voir la suite de tes expérimentations

Merci anewa pour le clin d'œil, c sympa de te recroiser . Oui je suis passé à l'étape 2 mais bon pour l'instant je ne suis sûr de rien ! Comme je disais sous prt advienne que pourra

Bonjour Alex44,

Etant moi même en phase de dév de robots via l'Api IG (en java) je salue le courage et le boulot accompli.
Moi perso je cherche juste à créer un robot solide et bien sur rentable , je ne cherche pas à créer de plateforme généraliste ça demande trop d'efforts et avec mes problèmes de santé je n'ai plus le courage de faire ce genre de choses.

J'ai une question: parmis tous les robots que tu as créés , est ce que tu en as trouvé avec petit TP/gros SL (donc gros % de réussite), un peu comme takapoto ?
Perso je n'arrive pas à trouver de système de ce type, les configurations gagnantes sont toujours l'inverse (gros TP, petit SL) mais je n'aime pas ces robots qui font du coup du swing trading.
C'est pas très motivant de mettre en prod un robot qui fait uniquement 15% de trades gagnants et où il faut parfois attendre des semaines avant d'encaisser des PVs.

Bonjour ticktack,

Je n'ai pas vraiment commencé la partie codage des robots à part ce que j'appelle un robot témoin qui n'a été que backtesté sur 1 an et demi de ticks et me sert avant tout à tester la plateforme, ce dernier fonctionne également avec un TP < SL et donc nécessite un taux de réussite en proportion, il n'est pas rentable de mémoire sous un taux de réussite de 90%.... Cela implique un temps d'exposition au marché à chaque position assez faible mais avec l'inconvénient qu'un marché qui serait trop "fluctuant" aurait un impact très négatif sur les perfs.

Si tu es sur une configuration TP > SL c'est normal que cela impacte ton taux de réussite à la baisse,le money management et le taux de réussité sont liés, l'un agit sur l'autre. L'important c'est que cela gagne au final, peu importe le système. Je n'ai pas de règle là dessus. Je ferais peut être par la suite des robots avec TP > SL aussi, je verrais.

Pour la plateforme, je me suis lancé la dedans parce que j'ai déjà une expérience pro importante (sans vantardise) sur laquelle je peux m'appuyer, sinon cela aurait été excessif et bien trop chronophage, il est bien plus simple de se concentrer sur un robot, quelques indicateurs et lancer le tout. Pour l'instant, l'avenir n'est pas écrit peut être que cela aboutira sur un flop monumental mais tant que je n'ai pas été au bout du bout je n'en sais rien, je veux gravir la pente et voir ce qu'il y a tout en haut.

Bonne continuation avec ton robot !

Quelques nouvelles sur le projet :

- La plateforme s'est bien comportée pour sa première semaine de lancement, le système de monitoring a fait son travail, le robot "témoin" n'a pris qu'une position ce vendredi gagnante, donc dans la lignée du backtest qui prédisait une à deux positions par semaine. Je précise que la plateforme a fonctionné sur un t2.micro avec 1Go de ram via aws, cela laisse de la marge pour augmenter la puissance matérielle.

- La robot témoin n'étant pas assez véloce en terme de prise de positions, j'ai réalisé un robot de stress qui prend un grand nombre de positions aléatoires, l'objectif étant de valider que la plateforme peut s'arrêter toute seule en cas de dépassement de perte journalière, valider que l'état du robot reste cohérent après une série de positions... Ce robot m'a permis de corriger quelques bugs. La plateforme dispose d'un mode "debug" qui injecte ce robot et trace alors toutes les opérations en live, cela me permet de vérifier sur un autre ordinateur que la plateforme est bien opérationnelle (pas de blocage ip...).

- Le système de monitoring a été étendu : la durée de chaque position pour chaque robot pour chaque marché est maintenant disponible. Un système d'alerte m'envoie sur mon téléphone le compte-rendu de la journée, j'ai la performance totale et la performance de chaque robot.

A suivre !

J'ai profité d'un week-end pluvieux pour programmer un robot, robot ridicule de 5 lignes car je souhaitais avoir plus de positions pour tester la plateforme qu'avec le robot témoin un peu mou à mon goût. Développé donc à la va vite je lance un backtest malgré tout sur 2016 :

BACKTEST YEAR 2016
total=3130,50Pts WIN=1372 LOST=0 RATE=100,00%

Ou là, y a un truc qui est pas normal là , je refais un backtest sur 2017 :

BACKTEST YEAR 2017
total=752,60Pts WIN=345 LOST=0 RATE=100,00%

Bon il y a manifestement un gros bug dans les backtests, je regarde le code, je ne trouve rien, je relance sur le robot témoin, j'ai toujours l'ancien résultat conforme ?? Après des recherches supplémentaires je me rend compte qu'aucun stop n'a été défini dans ce nouveau robot, d'où le résultat

A suivre

Oui les robots sans stops ça marche .. en théorie ... en pratique quand on regarde le levier nécessaire et l mum adverse excursion (MaxDD en tenant compte des trades ouverts à chaque Bougie/tick) , on prend vite peur et une fois la perf ramenée au capital total nécessaire pour encaisser la MaxDD sans faire sauter le compte ... ben en fait c'est pas terrible (mais ceci dit si on a un gros capital, pas peur des MaxDD de fou et qu'on se contente de gains modestes ça marche).

c'est ce que fait Warren Buffet

Je crois qu'avec le portefeuille de w.buffet on peut tout se permettre

Merci ticktack pour le retour. Je suis très embêté j'ai rebackteste avec un stop j'ai encore des perfs anormalement élevées. J'ai lancé en demo aujourd'hui il a fait 29 points mais ce qui est intriguant c qu'il n'a travaillé qu'une heure car je l'ai volontairement bridé. Pour info C un robot scalpeur.

On verra...

Si c'est un robot scalpeur fait super gaffe a bien prendre en compte dans les backtests le spread réel et les intérêts overnight (sauf si les trades sont tous fermés avant la fin de journée), car ça change totalement les résultats.
Personnellement en tenant compte de ces 2 paramètres je n'ai pas réussi à trouver de robot scalpeur qui gagne grand chose (mais vu que takapoto nous a montré que c'est possible , c'est moi qui ne doit pas être très doué )

Tous les trades sont fermés la nuit et le spread est bien géré. Le système de backtest est interne à la plateforme, il n y a pas de différence de fonctionnement entre le flux ig et le backtest. Lorsque j'ai refait le backtest, j'ai augmenté le TP pour voir, j'ai juste halluciné... J'ai même pas voulu poster le résultat.... Et débrider le robot, je n'y pense même pas.

Pour l'instant, je ne sais pas s'il y a un bug dans la plateforme, faudra quelques jours/semaines voire mois en fonctionnement réel pour être fixé.

Rien n'est acquis !

Bilan de la semaine négative en démo, le robot (R2) du week end dernier n'a pas tenu ses promesses et pour cause les backtests étaient finalement faux, la dernière position du robot n'était jamais fermée par un SL ce qui entraînait à un moment de la journée un gain d'où des résultat hallucinants..

Voici le vrai résultat du backtest corrigé de R2 :

BACKTEST YEAR 2017
total=-996,80Pts WIN=942 LOST=230 RATE=80,38%

R2 amélioré donne maintenant

BACKTEST YEAR 2017
total=148,70Pts WIN=37 LOST=21 RATE=63,79%

Autre problème, je n'autorisais qu'une seule position à la fois pour tous les robots, mais cela entraînait une baisse des performances car les robots se gênaient mutuellement. La plateforme autorise maintenant une position par robot à la fois.

Voici un nouveau backtest pour R1 + R2

BACKTEST YEAR 2017
total=193,10Pts WIN=73 LOST=20 RATE=78,49%

Les logs ont été également renforcés pour connaître la durée de la position, le temps d'obtention de l'acquitement de la position par ig...

L'objectif est d'atteindre 100 Pts / mois, reste encore du boulot