Un filtre utile répond à une question concrète : cet EA peut-il envisager une nouvelle position avec les informations disponibles ? Un nom de séance ou un calendrier vide ne suffit pas. La règle exige une horloge vérifiée, une couverture précise des événements et des cotations actuelles du symbole négocié.
Commencez par une séparation simple : gérer l’exposition existante selon ses propres règles ; n’envisager de nouvelles entrées qu’après réussite des contrôles obligatoires. Ce guide précise cette séparation, illustre un court journal de décisions et explique comment la tester. Il ne fournit ni EA prêt à l’emploi ni preuve de rentabilité.
1. Définir ce que contrôle le filtre
Distinguez la règle horaire, la restriction liée aux nouvelles programmées et la configuration d’entrée de la stratégie. L’horaire définit les périodes permises ; la règle d’actualité exclut certains intervalles ; la configuration identifie l’occasion de trading. Réussir les deux premiers contrôles ne crée pas cette occasion et ne supprime pas les limites d’exécution ou de risque du compte.
Utilisez trois résultats explicites : PASS, BLOCK et UNKNOWN. Ce sont des étiquettes de données définies par l’auteur, pas des codes d’erreur MT4. Une plage fermée connue peut bloquer ; une information manquante ne justifie pas une validation. Dans la politique illustrée, un blocage ou une donnée obligatoire indéterminée suspend l’examen des nouvelles entrées. La gestion suit ses propres contrôles de données et d’autorisations.
2. Écrire les règles horaires et de couverture avant le test
Utilisez la correspondance horaire datée du guide des séances et les définitions d’événements du guide du calendrier économique. Consignez les règles dans une spécification versionnée qu’une autre personne pourrait appliquer aux mêmes données.
- Instrument et périmètre : courtier, compte, symbole, devises concernées et familles d’événements retenues, y compris les étapes ultérieures.
- Séance : dates complètes, fuseau horaire, jours de semaine et bornes incluses ou exclues précisément définies.
- Correspondance horaire : relation vérifiée entre UTC, éventuelle règle locale et heure du serveur du courtier à la date concernée.
- Exclusion d’actualité : source de l’heure, marges avant et après, chevauchements et traitement des événements provisoires, retardés ou modifiés.
- Exigences de données : dates et devises couvertes, schéma, version de la source, état de mise à jour et limites d’ancienneté.
- Réaction aux défaillances : motifs de suspension des entrées, poursuite de la surveillance et de la gestion, et rapprochements nécessaires avant reprise.
Pour une séance locale traversant minuit, définissez le jour de trading auquel elle appartient et traitez explicitement le changement de date. Incluez les événements des jours voisins dont l’exclusion atteint l’heure de décision. Lors des changements d’heure, vérifiez la conversion retenue pour les heures locales répétées ou inexistantes. Ne remplacez pas silencieusement une correspondance manquante par le fuseau d’affichage de l’ordinateur.
3. Valider l’instantané du calendrier, pas seulement le téléchargement
Un instantané est une version enregistrée du calendrier utilisée pour décider. Un téléchargement réussi ou une liste vide ne prouve pas son exhaustivité. Vérifiez que le fournisseur couvre les devises, dates et types d’événements demandés, que tous les enregistrements nécessaires sont récupérés et que les horaires, unités et versions sont correctement interprétés.
Conservez séparément les informations de mise à jour du fournisseur et votre heure de réception. Une réponse nouvellement reçue peut contenir des données anciennes. Ne remplacez l’instantané actif qu’après validation de toute la nouvelle version ; un fichier partiel ou une liste à moitié actualisée ne doit pas devenir valide. Un échec d’actualisation ou une nouvelle lecture du cache ne doit pas remettre à zéro l’ancienneté de la dernière version vérifiée.
Un instantané vérifié et suffisamment récent peut établir qu’aucun intervalle sélectionné n’est actif dans sa couverture déclarée. Une couverture absente, un changement non résolu, une heure d’événement pertinent inconnue ou un instantané expiré reste indéterminé. Suspendez les entrées dépendantes comme prévu et poursuivez le traitement des défaillances et la gestion définis. Les nouvelles imprévues restent hors de la protection d’un calendrier programmé.
4. Vérifier séparément la cotation du symbole négocié
Suivez la réception et la validité du Bid/Ask de ce symbole avec une mesure du temps écoulé qui gère les redémarrages et changements d’horloge. Une réception récente ne prouve ni l’actualité des données en amont ni la disponibilité d’une exécution. Validez séparément le flux, le contexte horaire, le spread et les autorisations de trading ; voir la surveillance des EA.
Dans MT4, TimeCurrent() dans OnTick() correspond au tick traité ; dans d’autres gestionnaires, il peut refléter la dernière cotation de n’importe quel symbole de l’Observation du marché. Cela ne prouve pas que votre propre symbole dispose d’une cotation récente. En direct, TimeGMT() dépend des réglages horaires de l’ordinateur ; dans le testeur MT4, il égale TimeCurrent() simulé. Leur différence dans le testeur ne reconstitue pas les décalages historiques du courtier.
5. Suivre un journal de décisions fictif
Pour cet exemple uniquement, utilisez la séance UTC [08:00, 17:00) du 2026-03-16. Reprenez l’union hypothétique des exclusions A/B [12:15, 13:05) du guide précédent. La couverture et les métadonnées nécessaires sont supposées vérifiées ; les événements couvrent toute la journée UTC, ce qui suffit pour ces contrôles diurnes et leurs marges. Aucun fournisseur ni aucune publication réelle n’est affirmé.
Pour illustrer le calcul, choisissez un âge maximal de l’instantané de 30 minutes et de la cotation du symbole de 5 secondes. Ces paramètres sont choisis par l’auteur : ce ne sont ni des réglages d’actualisation recommandés ni des garanties de sécurité. Le premier instantané a été vérifié à 12:00:00 ; un remplacement complet et actuel est vérifié à 13:06:00. À 17:00:00, un autre instantané valide est disponible. Les âges supposent des mesures de temps vérifiées et comparables.
| Décision · UTC | Âge de l’instantané | Âge de la cotation du symbole | Résultat horaire/données uniquement |
|---|---|---|---|
12:10:00 | 10 min | 1 s | Ces contrôles réussissent ; poursuivre les autres |
12:20:00 | 20 min | 1 s | Blocage : intervalle d’actualité actif |
13:05:00 | 65 min | 1 s | Attente : calendrier périmé |
13:06:06 | 6 s | 12 s | Attente : cotation du symbole périmée |
13:06:07 | 7 s | 1 s | Ces contrôles réussissent ; poursuivre les autres |
17:00:00 | 0 s | 1 s | Blocage : hors séance |
À 13:05:00, l’exclusion d’actualité se termine, mais l’ancien instantané a 65 minutes. À 13:06:06, le nouveau a 6 secondes, mais la dernière réception du symbole à 13:05:54 remonte à 12 secondes. Une réception à 13:06:06 n’a que 1 seconde à 13:06:07. Cette ligne valide les contrôles horaires et de données illustrés, pas ceux de stratégie, d’exécution ou de risque. La borne de 17:00 est exclue. Aucun ordre, sortie ou rendement n’est simulé.
6. Préserver la gestion et rapprocher les ordres chez le courtier
Bloquer les nouvelles entrées ne doit pas court-circuiter la surveillance et la gestion prévues des positions existantes. Les actions de gestion exigent toujours leurs propres données et autorisations valides ; l’absence de prix ne permet pas de modifier un stop à l’aveugle. Précisez séparément le maintien ou l’annulation des ordres en attente, puis vérifiez l’état accepté par le courtier au lieu de supposer qu’une demande d’annulation a abouti.
Le bouton AutoTrading de MT4 interdit les demandes automatiques de trading, tandis que l’EA et OnTick() peuvent continuer à fonctionner. Ce n’est donc pas une pause réservée aux entrées : la gestion nécessitant de telles demandes peut aussi être affectée. Distinguez ce bouton du retrait d’un EA ou d’une déconnexion du terminal. La protection existante chez le courtier et la gestion côté client sont des mécanismes différents ; voir la gestion du risque.
7. Éviter que la récupération bloque le processus de décision
Utilisez un cache complet et validé pour décider et un processus contrôlé pour l’actualiser. Définissez les délais d’attente, le signalement des échecs et l’activation des nouvelles versions. Appeler la gestion une fois avant une requête lente ne la maintient pas active pendant que cette requête bloque le même EA.
Facultatif : limites réseau et événements de MT4
En MQL4, WebRequest() est synchrone. Le déplacer de OnTick() vers OnTimer() dans le même EA ne le rend pas asynchrone ; l’attente peut toujours retarder ce programme. Un composant de récupération distinct peut fournir un instantané validé, mais son transfert et ses défaillances doivent aussi être vérifiés. Un minuteur sert à planifier les appels, sans garantir une gestion ininterrompue.
La séquence logique est la suivante : exécuter la gestion et la surveillance prévues, évaluer les contrôles obligatoires des nouvelles entrées puis, seulement après leur réussite, envisager une configuration actuelle avec contrôles d’exécution et de risque. Cela décrit des responsabilités, pas du code MQL4 exécutable ni une garantie de traitement à temps. Testez l’intégration réelle, les autorisations et les réactions aux défaillances avant de vous y fier.
8. Garder une trace des décisions après redémarrage
Consignez l’heure UTC de décision, l’heure serveur et leur correspondance vérifiée, la version des règles, l’identifiant de l’instantané et les heures de source et de réception, la couverture, la réception et l’âge des cotations, les exclusions actives et les motifs du résultat. Conservez les candidats rejetés comme les contrôles réussis. Le journal doit expliquer une attente sans la reconstruire ensuite à partir d’un calendrier révisé.
Après redémarrage ou reconnexion, rapprochez avec le courtier les positions existantes, les ordres en attente et les demandes non résolues. Ne restaurez qu’un état vérifiable : redémarrer ne signifie ni compte sans position ni cache actuel. Évitez de traiter plusieurs fois le même candidat. Si un état nécessaire est inconnu, suspendez les entrées jusqu’au rapprochement et poursuivez la gestion et la réaction aux défaillances prévues.
9. Tester la correction avant d’interpréter un backtest
Avant de tester les performances de marché, créez de petits cas fixes avec résultats attendus. Incluez :
- Début de séance inclus, fin exclue et intervalles traversant minuit.
- Débuts et fins d’exclusion, événements superposés et calendrier retardé ou modifié.
- Données absentes, partielles, mal formées ou hors couverture, y compris une réponse vide non vérifiée.
- Ancienneté exactement à la limite choisie et juste au-delà, avec un tick récent d’un autre symbole alors que celui négocié reste périmé.
- Redémarrage, saut d’horloge, actualisation échouée et remplacement interrompu sans remise à zéro de l’ancienneté.
- Ordres conservés chez le courtier et gestion pendant le blocage des entrées, avec annulation rejetée ou autorisation de trading indisponible.
Le testeur de stratégies de MT4 n’exécute pas WebRequest() et ne traite pas les événements Timer. Testez la logique commune avec des données figées et une correspondance horaire historique vérifiée, via un chemin de test pris en charge. Rejouez chaque instantané seulement lorsqu’il aurait été disponible. Une table historique d’événements ne reproduit pas à elle seule la récupération en direct ou la planification des appels. Le guide du backtesting MT4 détaille les limites générales.
10. Évaluer l’utilité séparément du bon fonctionnement
Un filtre correctement réalisé peut exclure des transactions gagnantes comme perdantes. Comparez la règle proposée à une référence déclarée avec la même stratégie, les mêmes données et hypothèses de coûts. Conservez tous les candidats et motifs de rejet, réservez des données ultérieures pour valider et intégrez des coûts d’exécution réalistes. Explorer de nombreuses plages et ne publier que la meilleure peut surajuster l’échantillon.
Observez ensuite l’intégration réelle en démo, avec des données normales puis défaillantes. Mesurez les échecs d’actualisation, les attentes pour données périmées, les interruptions de cotation, les retards de gestion et les réponses du courtier. Un journal propre montre ce qu’a fait le système ; il ne prouve pas sa rentabilité future. Avant un usage élargi, confirmez que :
- La spécification versionnée, la correspondance horaire et la sélection des événements sont documentées.
- Les contrôles de couverture et d’ancienneté distinguent les états libres, bloqués et indéterminés.
- Les cas de bornes et de défaillances donnent les résultats attendus.
- Les tests historiques respectent la disponibilité de l’information et signalent les historiques manquants.
- Les essais démo vérifient récupération, redémarrages, continuité de gestion et état des ordres chez le courtier.
- Tout bénéfice avancé est évalué séparément, avec coûts et données ultérieures, sans chiffre de performance inventé.
11. Questions sur les filtres d’EA
Un calendrier libre signifie-t-il que l’EA doit entrer ?
Non. Un calendrier vérifié sans restriction ne valide qu’une partie de la décision. Séance, qualité des cotations, exécution, risque du compte et configuration actuelle de la stratégie restent nécessaires. Des nouvelles imprévues peuvent survenir hors calendrier.
Pourquoi un téléchargement récent peut-il laisser l’état indéterminé ?
La réponse peut être ancienne, incomplète, hors couverture ou mal interprétée. L’heure de réception ne valide pas à elle seule les données du fournisseur. Maintenez l’attente liée aux données requises jusqu’à réussite des contrôles concernés.
Puis-je tester les téléchargements d’actualités en direct dans MT4 ?
Le testeur documenté n’exécute ni WebRequest ni les événements Timer. Utilisez des entrées figées et versionnées, via un chemin pris en charge, pour tester la logique commune. Vérifiez ensuite séparément en démo la récupération et la planification réelles.
Faut-il utiliser AutoTrading pour la pause d’actualité ?
Ce bouton ne se limite pas aux nouvelles entrées : il peut aussi interdire des demandes automatiques nécessaires à la gestion. Ce guide décrit un contrôle interne des entrées avec responsabilités de gestion vérifiées séparément, pas un interrupteur universel pour supprimer l’exposition.
12. Références et portée
La référence officielle MQL4 sur WebRequest explique les requêtes synchrones et leurs restrictions. Les limites du testeur de stratégies MT4 documentent la simulation du temps ainsi que les fonctions externes et événements non pris en charge. Vérifiez les fonctions de votre plateforme et de votre intégration précises, sans supposer qu’un exemple d’une autre plateforme soit compatible. Références vérifiées le 2026-10-17.
Ce guide termine le groupe consacré aux séances et aux actualités par un cadre de règles et de validation. Horaires, instantanés, anciennetés et résultats sont des exemples pédagogiques inventés. Les seuils ne sont pas des recommandations ; aucune exécution d’EA ni aucun résultat de trading n’est revendiqué. Les filtres n’éliminent pas les risques de marché, d’exécution ou de compte.