Discussion de l'article "MetaTrader 5 et le Calendrier Économique MQL5 : comment transformer les actualités en un système de trading reproductible"

 

Un nouvel article MetaTrader 5 et le Calendrier Économique MQL5 : comment transformer les actualités en un système de trading reproductible a été publié :

Cet article présente une approche systématique du trading d'actualités dans MetaTrader 5 utilisant le Calendrier Économique intégré : structure des données, fonctions API, règles de synchronisation temporelle et filtrage des événements. Des méthodes de mise en cache et de mise à jour incrémentale sans surcharge du serveur sont décrites. L'article propose également un mécanisme pour exporter l'historique vers une ressource .EX5 en vue de tests déterministes utilisant le même algorithme.

Les principaux problèmes du trader d'actualités moderne sont la fragmentation des outils et l'absence d’un processus de trading structuré et algorithmique. Il est assez difficile de répartir son attention entre son navigateur internet (pour consulter des sites d'actualités) et son terminal de trading lorsqu'on passe des ordres.

Le flux de travail d'un trader sur actualités ressemble à ceci : Ouvrir rapidement le calendrier des actualités dans son navigateur Web et vérifier les changements d'événements → Évaluer rapidement les événements à venir et décider quoi et comment trader → Accéder au terminal MetaTrader 5 – placer des ordres en attente ou rester devant le terminal et attendre la publication des actualités pour prendre une décision. Dans ce scénario, le trader perd souvent le contexte opérationnel, ce qui entraîne des retards dans sa réaction aux actualités, ce qui à son tour engendre des pertes.

Et si le trading d’actualités fonctionnait comme un problème d’ingénierie — avec des règles claires, des résultats reproductibles et des tests automatisés ? L'objectif de cet article est de démontrer l'architecture opérationnelle d'un module d’actualités pour MetaTrader 5 : une source de données unique, une utilisation appropriée de l'API Calendar, un mécanisme de filtrage et de mise en cache, l'export des événements historiques vers une ressource pour le testeur et la bascule automatique entre les modes Live et Tester — afin que le même code produise des résultats déterministes à la fois en temps réel et avec des données historiques.


Auteur : MetaQuotes

 

Merci pour cet article, c'est très intéressant. Je vais essayer de comprendre comment ça fonctionne... Je voulais moi-même me connecter via Viber et des agents IA à partir des actualités et du parseur Twitter – pour faire ça... On pourrait aussi mettre en place une solution hybride entre MQL5 et les agents IA...

 
Roman Shiredchenko #:

Merci pour cet article, c'est très intéressant. Je vais essayer de comprendre comment ça fonctionne… Je voulais moi-même utiliser les codes Vibe et les agents IA via les actualités et le parseur Twitter – c'est ce que je vais faire… On peut aussi mettre en place une solution hybride entre MQL5 et les agents IA…

Pourquoi analyser quoi que ce soit si toutes les données, avec tous les détails, sont déjà disponibles dans le terminal ? Et l'IA est là aussi)
 
Dmitriy Skub #:
Pourquoi analyser quoi que ce soit, alors que toutes les entrées avec tous les détails sont déjà disponibles dans le terminal ? Et l'IA est là aussi)

C'est cool, il faut juste regarder… et coder dans une bonne ambiance… )

 

Écrit :

Если брокер учитывает переход на летнее/зимнее время — календарь автоматически подстраивается под этот переход

Corrigez-moi si quelque chose a changé dans l'API MQL5, mais auparavant, le calendrier s'adaptait au fuseau horaire ACTUEL en tenant compte de l'heure d'été : ainsi, en été, les appels de fonctions renvoyaient des horodatages, par exemple, dans le fuseau UTC+3, tandis qu’une requête portant sur la même période historique en hiver renverrait des événements horodatés dans le fuseau UTC+2, si le serveur effectue le passage à l’heure d’été et inversement. Ainsi, pour exporter avec précision l’historique du calendrier sur une période de six mois ou plus, il est nécessaire d’analyser l’historique des changements de fuseau horaire du courtier. Plus de détails dans la base de code.

De plus, l’approche consistant à mettre en cache le calendrier sous forme de lien vers une ressource semble peu pratique et, en particulier, provoque des erreurs mentionnées dans l’article lui-même (du type : « n’oubliez pas de recompiler l’expert »). Pourquoi ne pas définir le cache du calendrier dans le paramètre d’entrée sous la forme d’un fichier issu du dossier « Common », accessible à tous les agents ?

Economic Calendar Monitor and Cache for Backtesting on History
Economic Calendar Monitor and Cache for Backtesting on History
  • 2024.11.10
  • www.mql5.com
This indicator displays current events on the chart and allows you to export the calendar to archives for backtesting, automatically fixing time discrepancies between the history of bars and the history of events. This is an improved version of CalendarMonitorCached indicator from the algotrading book.
 
Corrigez-moi si quelque chose a changé dans l'API MQL5, mais auparavant, le calendrier s'adaptait au fuseau horaire ACTUEL en tenant compte de l'heure d'été : ainsi, en été, les appels de fonctions renvoyaient des horodatages, par exemple, dans le fuseau UTC+3, tandis qu’une requête portant sur le même segment d’historique en hiver renverrait des événements avec des horodatages dans le fuseau UTC+2, si le serveur effectue le passage à l’heure d’été et inversement. Ainsi, pour exporter avec précision l’historique du calendrier sur une période de six mois ou plus, il est nécessaire d’analyser l’historique des conversions часового пояса du courtier. Plus de détails dans la base de code.

Et pourquoi les cotations (et plus généralement tous les horodatages) ne sont-elles pas enregistrées, par exemple, en UTC ?

Pourquoi les ticks des courtiers ont-ils des représentations numériques différentes pour un même repère temporel ?

C'est une question philosophique :-) C'est ainsi que cela s'est fait, même si ce n'est pas correct et que cela engendre des problèmes sans raison.


P.S. C’est pourquoi il vaut mieux puiser les « informations historiques » dans d’autres sources.

Et il ne faut jamais « analyser soi-même l’historique des conversions d’heure » : tout cela existe déjà, c’est une fonctionnalité du système d’exploitation ou, au pire, des bibliothèques système. Cherchez « tzdata » sur Google

Combien de vélos peut-on fabriquer, surtout des vélos tordus ?

 
Stanislav Korotky #:

Auparavant, le calendrier s'adaptait au fuseau horaire ACTUEL en tenant compte de l'heure d'été ; ainsi, en été, les appels de fonctions renvoyaient des horodatages, par exemple dans le fuseau horaire UTC+3, tandis qu’une requête portant sur la même période historique en hiver renverra des événements horodatés dans le fuseau horaire UTC+2, si le serveur effectue le passage à l’heure d’été et inversement.

C'est exactement ce que j'avais compris.
 
Maxim Kuznetsov #:


P.S. : c'est pourquoi il vaut mieux puiser les « informations historiques » dans d'autres sources.

Et il ne faut jamais « analyser soi-même l'historique des conversions d'horloge » : tout cela existe déjà, c'est une fonction du système d'exploitation ou, tout au plus, des bibliothèques système. Cherchez « tzdata » sur Google.

Combien de vélos peut-on fabriquer, surtout des vélos tordus ?


Les autres sources ne résoudront pas le problème, car celui-ci est ancré dans la manière dont les cotations sont stockées dans MT5.

Commencez par nous montrer votre vélo tout droit, puis donnez-nous des conseils.

 
MetaQuotes:

Les principaux problèmes auxquels est confronté le trader d'actualité moderne sont la fragmentation de ses outils et l'absence d'un processus de trading systématique et algorithmique. Il est en effet assez difficile de partager son attention entre son navigateur Internet (pour consulter les sites d'actualités) et son terminal de trading lorsqu'on effectue des transactions.

Le flux de travail d’un trader réactif aux actualités se présente ainsi : ouvrir rapidement le calendrier des actualités dans son navigateur web et vérifier s’il y a des changements dans les événements → évaluer rapidement les événements à venir et décider quoi et comment trader → se rendre sur le terminal MetaTrader 5 – soit passer des ordres en attente, soit rester devant le terminal et attendre la publication de l’actualité pour prendre une décision. Dans ce scénario, le trader perd souvent le fil de la situation, ce qui entraîne des retards dans sa réaction aux actualités, et donc des pertes.

Souhaitez-vous que le trading sur l’actualité fonctionne comme un problème d’ingénierie — avec des règles claires, des résultats reproductibles et des tests automatisés ? L’objectif de cet article est de présenter l’architecture fonctionnelle d’une couche d’actualités pour MetaTrader 5 : une source de données unique, une utilisation appropriée de l’API du calendrier, un mécanisme de filtrage et de mise en cache, l’exportation des événements historiques vers une ressource pour le testeur, et le basculement automatique entre le mode Live et le mode Tester — afin que le même code produise des résultats déterministes aussi bien en temps réel qu’avec des données historiques.

Oui, c’est un véritable casse-tête pour le trading sur l’actualité.

Passer du navigateur au calendrier puis au terminal brise la concentration et ralentit considérablement les réactions. Disposer d’un flux de travail ou d’un système unifié qui intègre directement les actualités dans l’environnement de trading rendrait sans aucun doute l’exécution plus rapide et plus cohérente.

L’idée d’en faire une configuration structurée et reproductible, de type « ingénierie », avec des tests et de l’automatisation, est en réalité tout à fait pertinente pour éviter les décisions émotionnelles ou tardives.