Concevoir un bot de trading, partie 2
Dans la première partie de cette série d’articles nous voyions ensemble les principes derrière la stratégie DMAC. Il est donc temps de les appliquer.
Afin de définir une organisation valable pour notre programme il est important de fixer de façon claire le déroulement des étapes. Cela peut sembler évident, mais délimiter correctement les concepts utiles nous permettra d’en structurer les différentes parties. Trois grandes parties composeront donc le bot :
- requêtage et nettoyage des données (Watch)
- analyse des données (Compute)
- passage d’ordre et gestion des fonds (Serve)
Par ailleurs, j’ajoute une quatrième partie, un point d’entrée du programme (Main) chargé de l’initialisation des composants ainsi que de leur communication entre eux. J’entends par initialisation la définition des paramètres nécessaires à la bonne marche du programme. Assez simplement, il s’agit de la liste des cryptomonnaies à surveiller pour Watch, les stratégies à appliquer pour Compute (pour l’instant seulement DMAC mais le but est d’en inclure d’autres par la suite) et enfin les clefs publique et privée pour Serve, pour pouvoir consulter son wallet et passer des ordres sur une plateforme d’échange. Pour ma part, je choisis Bittrex, car cette dernière présente les avantages de proposer à la fois un grand nombre de monnaies mais aussi de traiter un trafic important et donc d’être la plateforme de référence pour une majeure partie de celles-ci.
Je vous passe les détails d’implémentation, ce n’est pas forcément le plus passionnant. Néanmoins je souhaite partager ici quelque chose qui pourra aider ceux qui souhaitent se lancer dans le développement d’outils. Il existe un endpoint non documenté de l’API Bittrex pour obtenir les données OCHL + Volume :
https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-CUR&tickInterval=INTER&_=TIMEVous pouvez le tester directement dans votre navigateur en changeant les valeurs :
- CUR : sigle de la monnaie (LTC, NXS, etc.)
- INTER : valeurs fixes définies par Bittrex (ThirtyMin, Hour et autres)
- TIME : timestamp actuel en secondes
D’autres endpoints sont utilisés en fonction des besoins, par exemple /public/getticker pour pouvoir vérifier si les monnaies choisies sont échangeables sur la plateforme ou bien /account/getbalancespour obtenir son solde. Néanmoins, pour les besoins documentés il est préférable d’utiliser les wrappers mis en avant par Bittrex.
Maintenant que tout est en place, plusieurs choix s’offrent à nous. Nous pouvons lancer gaiement le programme avec la permission d’échanger réellement les devises sur Bittrex, mais ce n’est pas très malin sans garanties que la stratégie est gagnante. Nous pouvons alors choisir plutôt de simuler le passage d’ordres en temps réel pour estimer les gains/pertes. L’inconvénient de cette approche est qu’elle se révèle être très chronophage. Si à chaque changement apporté il faut simuler pendant cinq jours pour obtenir les performances d’une stratégie, il me faudra plusieurs années pour finir ce projet au rythme où je travaille dessus.
La démarche à suivre est donc d’intégrer une solution de backtesting, qui simulera en accéléré notre stratégie sur des données en local. L’inconvénient est que nos résultats finaux seront moins précis qu’avec une simulation temps réel. Nous pouvons en créer une nous-même, ou bien utiliser une solution éprouvée comme Zipline. Peu importe le choix fait, testons vite les performances de notre première approche DMAC sur une quinzaine de jours sur quelques monnaies :
Résultat moyen : -0,66 % par transaction
Bon, nous savions dès le départ que la stratégie DMAC est beaucoup trop simple pour être vraiment gagnante (sans compter les commissions de Bittrex à hauteur de 0.25% par transaction). Mais le plus intéressant est de réfléchir aux explications de ce résultat, et pour ma part j’en vois deux principales :
- Les moyennes mobiles engendrent intrinsèquement un retard de prise de décision par rapport à l’évolution réelle du marché.
- Les tailles de fenêtre choisies doit être parfaitement adaptées aux tendances d’un marché.
Concernant le point 1. nous ne pouvons malheureusement pas faire grand chose. Nous avons utilisé des moyennes mobiles exponentielles afin de pallier déjà un peu à ce problème, en donnant ainsi davantage de poids aux données les plus récentes. Le problème est que nous ne pouvons pas non augmenter indéfiniment cette répartition biaisée sous peine de juste prendre la dernière valeur en date, ce qui est contraire à l’esprit des moyennes mobiles.
En ce qui concerne le point 2. nous avons choisi arbitrairement les tailles des fenêtres court et long terme. Mais j’ai une petite idée pour choisir automatiquement et surtout plus judicieusement ces dernières afin de les faire correspondre davantage à la volatilité propre d’un cours. Ce point fera l’objet d’un prochain article hors série. Pour l’heure, j’ai davantage envie de partir sur une approche bien plus ambitieuse, mais ce sera l’objet de l’article suivant !
C’est ainsi que se conclut cette nouvelle partie de cette série consacrée à la réalisation d’un bot de trading. La structure globale étant en place, le travail restant consiste principalement à travailler sur des méthodes d’analyse à intégrer afin d’obtenir de meilleurs résultats.
Enfin, je vous remercie pour le fort enthousiasme autour de ce sujet, je réfléchis aux moyens de l’ouvrir afin d’en faire un véritable projet communautaire.
N’hésitez pas à rejoindre La Baleine ici.
