Étude de cas : trading algorithmique avec le langage Go

• Cas d’un projet personnel ayant construit en Go un bot de trading retail qui surveille en temps réel plus de 5 500 actions cotées au NYSE et au NASDAQ et exécute des transactions automatiquement
• Au départ, le système perdait rapidement de l’argent, mais après plusieurs années d’essais et d’erreurs, il a progressé jusqu’à atteindre le seuil de rentabilité, et parfois même à générer des bénéfices
• Il repose sur trois composants clés : un fournisseur de données, une application Go et un broker ; il traite en mémoire plus de 60 000 événements par seconde à l’ouverture et à la clôture du marché
• Les principaux enseignements pratiques portent sur les tests du système via des achats aléatoires, la création de chandeliers maison basés sur des tick bars, et le passage à un traitement entièrement en mémoire
• Un exemple qui montre la complexité concrète, mais aussi les possibilités, de la construction d’une plateforme de trading personnelle à l’intersection de la finance, de la programmation et de l’analyse de données

---

Contexte et motivation du projet

• Le projet est parti d’une idée de suivi de tendance consistant à exécuter et gérer automatiquement environ 500 trades de court terme sur l’ensemble du marché actions, en capturant de petits profits sur chaque transaction
• L’automatisation a été lancée pour dépasser les limites du trading manuel
  • Investir tout son capital dans une seule action présentait un risque extrêmement élevé, mais surveiller simultanément des dizaines de paris de court terme dépasse les capacités humaines
  • Les entrées et sorties rapides n’étaient possibles que sur des actions très liquides, et il fallait acheter de petites quantités pour obtenir une exécution rapide
• La gestion des positions constituait également un défi majeur : synchroniser les moments d’entrée et de sortie sur plus de 25 paris simultanés est très complexe
• Il existait un problème de scalabilité : plus le capital augmente, plus le nombre de paris doit lui aussi augmenter
• Il fallait calculer rapidement les coûts de transaction — spread, commissions, slippage, frais d’API, impôts — afin de déterminer si une transaction était pertinente

Architecture de la solution

• Développement, sur plusieurs années, d’un outil automatisé surveillant en temps réel plus de 5 500 actions du NYSE et du NASDAQ afin de prendre rapidement des décisions de trading
• Exécution sur une machine de gaming hautes performances sous Linux : 16 cœurs, 128 Go de RAM, 8 To de stockage NVMe, connexion Internet 1 Gbit/s

• Trois composants clés

  • Data Provider (Massive.com) : couvre les données historiques et temps réel de l’ensemble du marché, avec une API et une documentation intuitives et adaptées aux développeurs. Modèle tarifaire simple donnant accès à toutes les données de marché sans limitations artificielles
  • Application Go : moteur central qui collecte et interprète les flux de données, prend les décisions de trading calculées, puis envoie les ordres d’achat et de vente à l’API du broker
  • Broker (Interactive Brokers) : fournit une API simple et se charge de l’exécution des ordres

• Pourquoi avoir choisi Go

  • Même si l’industrie des hedge funds s’appuie sur C++ et Python, l’auteur utilisait Go depuis plusieurs années et l’a choisi pour son excellente adéquation au traitement de flux de données et à l’intégration d’API

Principales fonctionnalités de l’application Go

• Data Ingestion Loop

  • Collecte en continu, via Massive.com, des données temps réel de plus de 5 500 actions
  • Au départ, une tentative de stockage en base de données a été faite, mais le système n’a pas pu traiter plus de 60 000 événements par seconde à l’ouverture et à la clôture du marché ; il est donc passé à une approche entièrement en mémoire

• Build Our View Of The Stock Market

  • Construction, à partir des données collectées, d’une vue en mémoire en temps réel de l’ensemble du marché : prix, spreads, activité de trading, etc.
  • Possibilité de détecter et de trader des opportunités avant les grands médias
  • Accès à l’activité de trading en pré-marché, séance régulière et after-hours

• BUY Signal Loop

  • En cas d’opportunité détectée, envoi d’une demande d’ordre d’achat à l’API du broker
  • Il ne s’agit pas d’un simple déclencheur : des calculs préalables sont effectués, notamment estimation du profit basée sur le spread, détermination du nombre d’actions nécessaires, prise en compte des commissions et des impôts
  • Inclut une logique pour gérer les variations de prix, les exécutions partielles, les annulations d’ordres, etc.

• Position Tracking System

  • Boucle surveillant en continu les positions détenues, en comparant en temps réel la table des positions et les prix actuels afin de suivre les gains et pertes
  • Une GUI permet de consulter la raison du déclenchement d’un trade, son état actuel et le moment de vente
  • Joue un rôle central dans l’affinage des logiques BUY et SELL

• SELL Signal Loop

  • Lorsqu’un bon profit ou une perte excessive est détecté, exécution d’un ordre de vente via l’API du broker
  • Inclut une logique complexe, comme la mise à jour des prix d’actions évoluant rapidement et la gestion des exécutions partielles

Interface web et captures d’écran

• L’interface web intégrée permet d’explorer toutes les structures de données, de visualiser les données, et de consulter les raisons de déclenchement des trades ainsi que leur état actuel
• Écran de vue d’ensemble du marché affichant les prix, spreads, etc. de plus de 5 500 tickers
• Page de symbole individuel (par exemple Tesla TSLA) affichant les tick bars et les informations associées
• Interface affichant le ratio victoires/défaites et les positions ouvertes actuelles (dans la session d’exemple, environ 900 $ de perte)
• Écran montrant les métadonnées et les graphiques des trades en temps réel, avec le point d’achat indiqué par une ligne orange
• Écran de logs console enregistrant les événements temps réel, comme les ordres d’achat et de vente

Développement de stratégie et backtesting

• L’application Go, la stratégie et le backtesting sont considérés comme trois éléments clés distincts
• La plupart des discussions se concentrent sur les stratégies — retour à la moyenne, suivi de tendance, régression linéaire, etc. — et le backtesting, mais la mise en œuvre concrète et la logistique des stratégies de trading intraday en temps réel ont tendance à être négligées
• Utilisation des vastes données historiques de transactions et de cotations de Massive.com pour explorer des stratégies et effectuer du backtesting en Python, ce qui explique l’usage de 8 To de stockage NVMe
• Le backtesting est comparé au fait de « conduire en avant en regardant dans le rétroviseur », mais il reste un moyen de validation utile pour juger des spreads, impôts, commissions, points d’entrée et points de sortie
• Les insights issus du développement de stratégie et du backtesting sont transformés en logique du BUY Signal Loop

Exemple de code

• Comprend du pseudo-code de haut niveau et des exemples de code Go réels ; l’application réelle compte environ 7 000 lignes
• Principales structures de données : TrackedSymbols (map de tous les symboles, flag d’activation du trading, verrou global), Symbol (données brutes de transactions et de cotations, Aggregate, Position, etc.), TradeEvent, QuoteEvent, Aggregate, Position
• Structure de la boucle principale
  • Collecte des données de transactions et de cotations via une connexion WebSocket, puis parsing des événements
  • Stockage dans la map de symboles, puis fusion des données de transaction et de cotation en Aggregate
  • Transmission de signaux aux logiques d’achat et de vente via des channels Go
  • Serveur HTTP fournissant des fonctions de consultation de tous les symboles, des positions et de watchlists personnalisées

Enseignements clés (Lessons Learned)

• Comprendre les abstractions

  • Le NYSE et le NASDAQ ne sont pas un système unique, mais un vaste système distribué composé de plus de 19 bourses
  • Les données en chandeliers constituent une abstraction massive construite à partir des données brutes de transactions, ou ticks ; il est indispensable de bien la comprendre
  • Des règles différentes s’appliquent selon les périodes de trading : pré-marché, séance régulière, after-hours, etc.

• Gestion des ordres

  • Le succès en trading ne dépend pas seulement de l’envoi d’ordres d’achat et de vente : dimensionnement préalable des positions, capacité à trader rapidement, gestion simultanée de plus de 25 positions, calcul des impôts et commissions, gestion du slippage, suivi de l’état des ordres, etc., y contribuent tous

• Cas limites

  • Il existe de nombreux cas limites : exécution, suivi, modification, annulation, exécutions partielles, suspensions de cotation, etc. Les manquer peut entraîner des pertes financières
  • Il est indispensable de tester avec du paper trading (simulation) plutôt qu’avec de l’argent réel
  • Expérience vécue : achat au plus haut d’une action qui avait bondi de 40 % en pré-marché, puis chute brutale et perte de 40 % en quelques minutes après l’échec de l’ajustement de l’ordre de vente. Le pré-marché et l’after-hours obéissent à des règles différentes de celles de la séance régulière, et des mouvements extrêmes peuvent s’y produire très vite

• Utiliser des achats aléatoires

  • Tester les fonctions cœur du système est plus important que découvrir une stratégie secrète
  • Exécuter 1 000 achats d’actions aléatoires par jour pendant une semaine permet de valider efficacement la logique d’achat et de vente, la gestion des exécutions partielles, la logique d’annulation et le système de suivi des positions
  • L’intégration d’achats aléatoires dans le processus de test sur un compte de paper trading constitue une méthode efficace pour vérifier simultanément plusieurs aspects du système

• Tick bars vs time bars

  • Les barres en chandeliers fournies par les brokers couvrent des périodes fixes, par exemple 30 secondes, mais lors de mouvements rapides du marché, 100 transactions et plusieurs milliers de transactions peuvent se retrouver mélangées dans la même fenêtre temporelle
  • Construction de barres maison basées sur le nombre de transactions à partir des données brutes de ticks et de cotations, offrant une résolution bien plus élevée pendant les périodes de forte activité comme l’ouverture et la clôture du marché, avec possibilité d’ajouter des métriques personnalisées comme le spread

• Passage en mémoire

  • L’approche initiale basée sur une base de données ne supportait pas les pics massifs d’activité à l’ouverture et à la clôture du marché
  • Passage à une architecture entièrement en mémoire utilisant une grande map protégée par des verrous mutex, ce qui a résolu les problèmes de scalabilité
  • Sauvegarde de la structure contenant toutes les données sous forme de fichier gob compressé, avec possibilité de rechargement au redémarrage. Elle dépasse 40 Go au cours d’une journée, et un patch du build Go a été nécessaire pour prendre en charge des dumps gob de cette taille
  • Après avoir perdu tout l’état du système en production lors d’une coupure de courant, l’ajout d’une alimentation sans interruption (UPS) est devenu indispensable

• Complexité et solitude

  • Le projet s’est révélé bien plus difficile et chronophage que prévu, passant d’un petit hobby à une véritable obsession
  • Comme tout se résume à faire augmenter le solde du compte, l’expérience peut être solitaire et s’accompagner de montagnes russes émotionnelles extrêmes

• Combiner Go et Python

  • Approche hybride : le système de trading est écrit en Go, tandis que l’exploration des données s’appuie sur le vaste écosystème de bibliothèques de data science de Python

• Utiliser un PC personnel

  • Avec une optimisation suffisante, les PC de bureau modernes sont assez puissants pour gérer la surveillance en temps réel de l’ensemble du marché actions

• Utiliser ChatGPT

  • Au lieu de s’appuyer sur la recherche et la lecture sans savoir comment résoudre un problème, l’auteur est passé à une méthode consistant à expliquer le problème à ChatGPT, lui demander une solution, puis lui faire générer du code, avec le sentiment d’avoir triplé sa productivité

Expérience des événements de marché

• Le système a permis de détecter par lui-même et d’observer avant les médias diverses anomalies de marché : épisode des meme stocks, grandes IPO, phases d’euphorie et de krach, annonces de la Fed et hausses de taux, etc.
• Une expérience comparable à un siège au premier rang pour voir les événements de marché se dérouler sous ses yeux

[GN⁺]

Commentaires Hacker News

• J’ai travaillé un temps dans le HFT, et tout ce domaine était vraiment fascinant ; ça fait plaisir de voir que l’auteur du billet original y a pris un plaisir similaire
  Si la plateforme elle-même est souvent absente des discussions, c’est parce que le trading est un domaine où se concentrent à la fois un haut niveau technique, une forte complexité, une réglementation stricte et une concurrence extrême
  Construire un système de saisie d’ordres, un système de gestion du risque et un système de suivi des positions est déjà un gros accomplissement, mais du point de vue d’une société de trading, cela relève presque déjà du coût d’entrée
  C’est pourquoi les gens parlent de stratégies. La plateforme de base est déjà en place, et l’étape suivante consiste à trouver comment gagner de l’argent avec
  En plus, tous les acteurs du marché ne jouent pas au même jeu. En HFT, on se battait pour des alphas de quelques secondes, à gratter des nanosecondes sur des FPGA et des microsecondes sur les réseaux sans fil du New Jersey, tandis que les banques se soucient davantage des élections et de la géopolitique que de la météo à Carteret. Quand il pleut, le réseau micro-ondes ne marche pas ce jour-là
  Entre les deux, il existe d’innombrables stratégies visant des alphas qui durent de quelques heures à plusieurs semaines, donc il est même difficile d’en parler dans un langage commun sur un forum public. Mais c’est un univers passionnant, et il me manque parfois

  • La plateforme n’est pas seulement un coût d’entrée, c’est aussi paradoxalement la partie la plus directe à construire. Même à la frontière de la latence, il s’agit le plus souvent de pousser jusqu’aux limites du budget, pas de découvrir quelque chose de totalement nouveau
    En revanche, la stratégie est le domaine de la découverte. Il existe bien quelques stratégies connues qui restent rentables, mais elles ont en général déjà été captées par les plus grosses sociétés ; pour le reste, c’est surtout un travail d’exploration. Certaines stratégies ne sont rentables que pendant une phase de marché très courte
    Moi aussi, ça me manque parfois, mais le secteur s’est tellement consolidé que c’est désormais surtout un monde de grandes entreprises
  • Honnêtement, ça me paraît encore plus dénué de sens que les cryptomonnaies
  • Mon échantillon se limite à un seul cas, mais après avoir travaillé deux ans sous contrat dans une société de trading, j’ai vu que faire tourner le business ne reposait pas uniquement sur les capacités techniques
  • Je suis vraiment d’accord à 100 %. J’ai lu presque tous les livres accessibles sur le sujet, et personne ne parle de la plateforme ; cette perspective me paraît très convaincante
    J’ai l’impression que la plupart de ces sujets sont cloisonnés à l’intérieur de chaque entreprise et ne sont jamais discutés à l’extérieur
    Le HFT joue à un tout autre jeu. J’ai lu sur l’architecture des places boursières et le câblage réel ; moi je reçois les données via le SIP, alors que le HFT se connecte directement aux bourses [1]
    Moi je trade à l’échelle de la seconde, et le HFT, comme tu l’as dit, à l’échelle de la microseconde, donc la comparaison n’a même pas lieu d’être. D’une certaine façon, c’est presque rassurant de ne pas être en concurrence directe avec eux. Ou alors je suis en concurrence avec eux malgré tout, mais il reste quand même possible de gagner un peu d’argent
    [1] https://www.researchgate.net/figure/Latencies-in-the-Electro...
  • Je suis du côté du trading à fréquence intermédiaire. Je calcule beaucoup de conditions de marché et j’envoie au maximum quelques ordres par minute. J’aimerais mieux comprendre le monde du HFT
    Je me demande si, fondamentalement, il s’agit juste de faire du trading à fréquence intermédiaire plus vite, ou s’il existe des avantages plus spécifiques, comme obtenir la priorité dans la file d’attente des ordres

• Je peux répondre aux questions sur ce projet. Ça a commencé comme un side project, puis c’est devenu une véritable obsession
  Le système en lui-même n’a pas grand-chose de secret ; l’essentiel est d’avoir une plateforme solide dans laquelle on peut brancher des stratégies
  Je pourrais peut-être en faire un projet open source, mais avant ça il faudrait que je nettoie tous les bricolages que j’y ai accumulés

  • Ça peut t’intéresser : https://www.techtrader.ai/#wall
    Tech Trader se présente comme un système de trading entièrement autonome qui tourne en conditions réelles depuis plus de 10 ans, sans intervention humaine ni mises à jour
    Ce qui le différencie des systèmes algorithmiques traditionnels, d’après sa présentation, c’est qu’il n’utilise ni approche quantitative, ni arbitrage statistique, ni haute fréquence, mais cherche plutôt à voir les actions comme le ferait un humain, tout en exploitant la discipline froide et la concentration illimitée d’une machine
    Depuis son lancement en décembre 2012, il traderait de manière entièrement automatisée avec du capital réel, et son créateur serait un développeur autodidacte unique utilisant le pseudo de jeu pftq
  • Bon billet. Je travaille moi aussi sur un projet similaire en Go, mais je n’utilise que des données en chandeliers à la minute, pas des ticks temps réel
    Je me demande si tu pourrais partager ton approche pour brancher différentes stratégies. Un système de stratégies façon plugin peut vite devenir délicat, car il peut s’étendre à plusieurs couches
    Je me demande aussi si, pour les backtests, tu stockes et rejoues toutes les données d’ordres et de ticks, ou si tu n’utilises que des données agrégées historiques
  • Ça fait plusieurs années que je fais de l’algorithmic trading en side project, mais toujours via TD Ameritrade. Grâce au compte, je reçois gratuitement les cotations et d’autres données, et j’utilise aussi d’autres sources gratuites
    En lisant l’article, je me suis dit que j’allais peut-être tester une configuration WebSocket avec Polygon, puis j’ai vu que le premier forfait avec fonctionnalité WebSocket est à 29 dollars, et que le forfait Advanced avec données temps réel coûte 200 dollars par mois
    Les données temps réel avec appels API illimités ont l’air plutôt intéressantes, mais avec ma stratégie, qui a au mieux un taux de réussite d’environ 78 % sur des capitaux ordinaires, il me serait difficile de justifier 200 dollars par mois
    J’aimerais savoir quel forfait tu utilises et quels en sont les avantages et inconvénients. Si tu préfères répondre par e-mail, c’est indiqué sur mon profil
  • Je me demande si tu as une adresse e-mail. Je construis depuis assez longtemps un système similaire en F#, et j’aimerais entrer en contact
  • Si tu te connectes à l’API TWS d’IB et que tu n’exécutes les transactions que là-dessus, n’y a-t-il pas aussi l’option de récupérer les prix en temps réel via l’API IB et de ne pas utiliser polygon.io du tout ?
    Je ne sais pas si IB envoie réellement le flux de prix en temps réel. L’écran TWS se met bien à jour en continu, donc j’imagine que les données sont transmises en temps réel, mais je me demande si le carnet d’ordres est aussi accessible via l’API
    Je sais que cet article a été publié sur le blog de polygon.io, mais je me demande si l’architecture pourrait aussi fonctionner uniquement avec l’API IB/TWS

• L’un des concepts les plus mal compris en algorithmic trading, c’est que, dans la plupart des systèmes, la vitesse n’est pas le facteur décisif.
  Des modèles comme mon système https://grizzlybulls.com/models/vix-ta-macro-mp-extreme ont largement surperformé le marché en conditions réelles depuis plus de 3 ans, tout en ne tradant en moyenne qu’une fois tous les 18 jours de bourse environ, avec des signaux générés uniquement près de points de bascule horaires.
  Ces 18 derniers mois ont été plus faibles que le début à cause d’un grand changement structurel — forte inflation et hausse rapide des taux — mais depuis le lancement du site en janvier 2022, le rendement est de +14,11 % contre -7,83 % pour le SPX.
  Et cela sans levier, avec sur la même période un drawdown maximal de -16,48 %, inférieur aux -27,57 % du SPX.

  • Mettre un graphique qui ressemble à des données de backtest démarrant en 2009 ne semble pas très honnête. Le point de départ est totalement arbitraire, et puisque tu dis avoir commencé il y a 3 ans, ce n’est pas de la performance réelle.
    La présentation donne l’impression que le modèle a largement battu le marché. Si tu as vraiment une mine d’or encore inexploitée, c’est impressionnant, mais personnellement j’ai du mal à y croire à cause de plusieurs signaux d’alerte.
  • Je me demande dans quelle mesure ces modèles utilisent des données externes, ou à quelle fréquence ils reçoivent une intervention humaine régulière ou des ajustements fins.

• Si l’algorithmic trading t’intéresse, Collective2 vaut le détour. C’est une plateforme où des ingénieurs fournissent des signaux d’achat et de vente via abonnement.
  Ça donne un peu l’impression de la ligue mineure de l’algorithmic trading, et c’est assez intéressant.
  Comme le système suit les profits et pertes, il est difficile de tricher sur les performances, et si tu autorises Collective2 à accéder à ton compte Interactive Brokers, les signaux peuvent être exécutés automatiquement à ta place.
  Le service existe depuis au moins 10 ans, donc on peut aussi voir les performances de long terme, mais la plupart des systèmes ne durent pas aussi longtemps.
  https://collective2.com/leader-board
  Même parmi les mieux classés actuellement, presque aucun n’y reste longtemps : en général 1 à 2 ans. Cela montre que, pour la plupart des systèmes, l’alpha disparaît assez vite.
  Les courbes de rendement sont aussi très irrégulières, avec une structure où quelques trades représentent l’essentiel des gains.

• Lorsqu’on développe un système de trading automatisé, les axes importants sont le flux et la collecte des données, la génération de features, la génération de signaux, l’exécution réelle des trades, la gestion des ordres et l’orchestration de l’ensemble.
  Les données brutes sont rarement utilisées telles quelles pour la prise de décision, et une bonne génération de features est souvent le principal facteur de réussite. La moyenne mobile en est un exemple, mais aujourd’hui cela ne suffit presque plus.
  Cet article montre les aspects techniques du traitement des données et de la gestion des ordres, ainsi que l’ensemble du pipeline, mais j’aurais aimé plus de détails sur la montée en charge de la solution et l’implémentation asynchrone.
  En particulier avec Go, il y a une structure à base de channels bien adaptée à ce type d’usage, donc ça m’intéresse encore plus.
  Je comprends que ce ne soit pas le sujet central de l’article, mais des informations générales sur la logique de trading, sur la manière de brancher de nouvelles stratégies et de paramétrer les stratégies existantes auraient aussi été utiles.
  Les liens de fin étaient intéressants, et comme je développe un bot de trading intelligent fondé sur le machine learning et le feature engineering (https://github.com/asavinov/intelligent-trading-bot), ce genre d’article peut être important pour moi.

  • D’accord. C’est la partie qui m’a échappé.
    La structure est simple : des goroutine et channel qui communiquent entre eux, avec un gros mutex unique pour verrouiller le tout.
    Quand de nouvelles données arrivent, on calcule les agrégats nécessaires, c’est-à-dire des chandeliers basés sur les ticks, puis ces données déclenchent la boucle de logique BUY. Si quelque chose est détecté, cela émet un ordre via l’API IB.
    C’est très simple, rien de particulièrement complexe. J’ai déjà suivi plus de 100 positions en même temps et ça tournait simplement bien, donc je n’ai pas beaucoup touché à une logique asynchrone complexe.
    Les paramètres sont en fait codés en dur directement dans la boucle BUY. Ça peut sembler étrange, mais dans une petite configuration, ça ne change pas si souvent.
    Je fais tourner quelques trades, j’ajuste les valeurs, puis je redémarre pour retester. Dans un environnement enterprise, il y aurait sans doute un vrai langage ou du hot loading, mais dans mon cas le hardcoding fonctionne largement assez bien.

• Ni Go lui-même ni aucun autre langage n’apportent de gros avantages. Ce qui apporte un avantage, c’est l’algorithme de trading, et c’est toujours difficile à trouver
  J’ai passé des mois à chercher les paramètres optimaux, mais au final ils ne fonctionnaient que sur les données historiques, et en réel c’était complètement différent
  Si l’algorithme et la stratégie sont parfaits, on pourrait faire mieux avec Visual Basic qu’avec Go, Rust ou n’importe quel autre langage. Un langage n’est qu’un outil
  C’est bien d’avoir utilisé Go, mais le titre peut être un peu trompeur. Les gens pourraient y voir une sorte d’avantage, alors que ce n’est pas le cas
  Et pour le HFT, je ne pense pas qu’un langage avec garbage collector soit un bon choix

  • Au final, il faut décider s’il faut acheter ou vendre, et en quelle quantité, et cette décision se retrouve en concurrence avec d’autres décisions fondées sur une certaine logique
    Comme il est évidemment difficile de développer manuellement une telle logique, c’est-à-dire une stratégie, j’ai créé un bot de trading intelligent qui dérive des stratégies de trading à partir de données historiques
    https://github.com/asavinov/intelligent-trading-bot
    Pour l’instant, il fonctionne sur les cryptomonnaies, mais il peut être appliqué à d’autres marchés
    https://t.me/intelligent_trading_signals
    Le fait que cela fonctionne bien uniquement sur des données passées et différemment en réel est une situation typique. L’essentiel est de créer une stratégie qui fonctionne aussi sur des données futures encore jamais vues
    L’algorithme de backtest doit lui aussi être conçu pour éviter toute fuite de données futures vers le passé
  • C’est moi qui ai écrit cet article, et je l’ai effectivement fait en Go. La raison est simplement que Go est le langage de programmation que j’utilise le plus
    Dans le secteur, on utilise surtout C++ et Python, donc utiliser Go peut même être un désavantage, mais c’était le langage que je savais utiliser
    Je n’avais pas l’intention d’induire qui que ce soit en erreur. Go convient assez bien pour recevoir et traiter des données et appeler des API distantes, donc dans la pratique cela fonctionne bien
    En revanche, si vous comptez vous appuyer là-dessus pour trouver un emploi, cela ne vous aidera probablement pas beaucoup
  • Si on écrit un code qui n’alloue absolument rien, même un langage avec garbage collector peut être utilisé en HFT
    Certains utilisent Java en préallouant dès le démarrage toute la mémoire nécessaire. Jane Street est aussi connue pour utiliser OCaml
  • Cela dépend des cas. J’ai entendu dire que certains utilisent Java en créant un grand tas, en réduisant les allocations à presque zéro, puis en redémarrant périodiquement l’application avant que le tas ne soit plein
    Avec cette méthode, les performances sont plutôt bonnes et il n’y a pas à se soucier des bugs mémoire
  • C’est du surapprentissage. Cela peut arriver non seulement avec l’optimisation par ordinateur, mais aussi quand des humains optimisent directement
    Après avoir expérimenté pendant un certain temps sur des données historiques, l’utilité de ces données diminue

• Moi, je construis des bots en TypeScript parce que c’est un langage que je connais, et en Python parce qu’il y a beaucoup d’outils
  C’est un travail extrêmement accablant et solitaire. Tous mes autres projets se faisaient toujours en équipe, et même dans de toutes petites équipes où le travail était autonome, il y avait quand même de temps en temps des réunions et des stand-ups
  Cela fait six mois que je fais ça seul, au point de me demander si je ne devrais pas faire rejoindre un ami juste pour ne plus être seul

  • Moi aussi, je fais partie de ceux qui développent du trading algorithmique en solo. On pourrait se mettre en contact et en discuter
  • Cet article tombe bien. J’étais justement en train de chercher un prétexte pour apprendre d’autres technologies en surveillant les options
    Comme c’est un side project, je ne ferai peut-être pas de grands progrès, mais je serais partant pour en discuter à tout moment
  • Je me demande comment vous espérez pouvoir rivaliser avec les pros. Il est difficile d’être plus rapide qu’eux, et à moins d’avoir plusieurs profils de niveau doctorat en maths, il est peu probable de produire de meilleurs algorithmes
    La seule façon que je vois serait d’obtenir des données qu’ils n’ont pas

• Je trouve cet article totalement vide de sens et racoleur. En résumé, il dit à peu près : « on peut utiliser polygon.io pour les données de marché, mais le trading algorithmique reste de toute façon difficile, donc il n’y a pas encore grand-chose à partager »

  • C’est moi qui ai écrit cet article, et je suis désolé que vous l’ayez ressenti ainsi
    Personnellement, je voulais partager la structure de haut niveau de la construction de son propre système. Quand je suis tombé dans ce terrier de lapin, j’aurais aimé qu’un tel article existe
    Si vous me dites ce qu’il aurait fallu ajouter pour l’améliorer, je l’intégrerai volontiers

• Il vaut mieux trouver des gens qui apprécient la boucle de feedback pure que procurent le code, la stratégie et l’argent dans le trading
  De mon côté, j’étudie depuis un certain temps le timing et les corrélations entre actions et indices comme source d’alpha, avec quelques résultats
  J’essaie maintenant d’automatiser ce processus, et j’aime vraiment ce travail en lui-même
  Je ne cherche ni à jouer un rôle de teneur de marché ni à passer constamment d’un titre à l’autre. Je me concentre sur l’affinage de modèles précis permettant de très bien monétiser quelques titres
  Parmi les outils utiles, il y a TradingView et les indicateurs et stratégies Pinescript, des modèles Excel utilisant des données exportées pour le backtest, Python et Go pour le machine learning côté backend, ainsi que ChatGPT pour accélérer l’itération sur le nouveau code
  Si cela vous intéresse, j’aimerais en discuter à trading @ dianazink.com

• Bon article, avec des explications concrètes, et j’ai particulièrement apprécié les captures d’écran
  Je comprends que vous ne détailliez pas la stratégie, mais je me demande si le trading repose entièrement sur de l’analyse technique, ou si vous utilisez aussi des données externes ou des flux de données alternatifs
  Autrement dit, est-ce un système presque fermé avec seulement l’entrée Polygon et la sortie API IB, ou une configuration plus large incluant aussi des flux de données personnalisés comme des sites d’actualités, Twitter ou Reddit
  Si c’est le second cas, je serais aussi curieux de savoir comment vous équilibrez cela avec les backtests historiques lorsque la couverture historique de certaines sources de données est partielle

  • Toutes mes données viennent de polygon.io, il n’y a pas de données externes
    Récemment, j’examine une méthode qui utilise une table de consultation de valeurs historiques précalculées pour détecter des anomalies, par exemple pour juger si « cette activité est-elle normale pour cette action »
    Le BXRX d’aujourd’hui en est un bon exemple [1]
    J’examine aussi l’activité de trading sur options pour voir si je peux l’utiliser comme signal
    [1] https://www.google.com/search?q=BXRX