Un EA télécharge des données API en démo, mais n'obtient aucune réponse équivalente dans le testeur. Cela ne prouve pas une panne du serveur. Vérifiez d'abord si la fonction est disponible dans cet environnement. Télécharger la valeur actuelle puis l'attribuer aux décisions anciennes construit un autre test, même avec un fichier parfaitement valide.

Pourquoi WebRequest en démo ne suffit pas

La documentation MQL5 indique que WebRequest ne peut pas s'exécuter dans Strategy Tester. Ajouter l'adresse à la liste des URL permises ne change pas cette restriction. Distinguez fonction indisponible, défaut réseau, autorisation refusée et réponse reçue hors testeur. Ne remplacez pas un échec par zéro : zéro peut être une valeur réelle ; l'échec indique une entrée indisponible.

Un fichier ne résout pas tout s'il contient des révisions encore inconnues au moment étudié. Définissez observation requise, version, valeur et date de disponibilité avant de relier la règle à HTTP. Premier algorithme : vérifier les données avant les ordres sépare données, décision et exécution ; ce problème concerne d'abord la première couche.

Séparer adaptateurs en ligne et hors ligne

L'adaptateur en ligne traite une réponse du fournisseur ; celui du test choisit un enregistrement conservé disponible au moment de décision. Tous deux livrent à la règle le même type de résultat : valeur valide, indisponibilité explicite ou erreur. C'est une organisation proposée, sans robot complet ni compatibilité garantie avec toute API.

Préservez réponses brutes et fichiers prêts au test séparément, avec fournisseur, version du schéma, date de récupération et preuve de disponibilité. La période décrite par une statistique n'est pas son heure de publication. Une archive donnant seulement une date de millésime ne justifie pas d'inventer une heure précise pour une décision intrajournalière.

FRED distingue périodes en temps réel et informations connues maintenant ou auparavant : exemple de données versionnées, pas API universelle Forex. Une date de vintage ne fournit pas automatiquement un timestamp UTC de publication. Dans MQL5, FileOpen travaille dans un espace défini, y compris pendant les tests ; un chemin relatif ne vise pas forcément le répertoire ordinaire du terminal. Vérifiez ouverture, lecture et erreurs : un tableau vide ne devient pas un historique complet.

Quelle version une décision ancienne peut-elle utiliser ?

Trois réponses fictives conservées

Observation fictiveGDP-model, le 1er octobre 2026, toutes heures UTC. Ce ne sont ni annonces PIB ni réponses d'un véritable endpoint. À 12 h, version initiale"1.0" ; à 13 h, révision"1.4" ; à 14 h, indisponibilité explicitenull. availableAt définit l'accès de notre modèle à l'enregistrement, pas l'heure d'exécution d'un ordre.

La version connue alors, pas celle d'aujourd'hui

Version sélectionnée aux trois décisions fictives

Version sélectionnée aux trois décisions fictivesLe 1 octobre 2026 UTC : 1.0 disponible 12 h, 1.4 à 13 h, null à 14 h. Décisions 12 h 30 ; 13 h 30 et 14 h 30 donnent 1.0 ; 1.4 et indisponible. Pas de zéro ni retour automatique à 1.4.Disponibilité déclaréeDécision et sélection12 h : « 1.0 »12 h 30 → 1,013 h : « 1.4 »13 h 30 → 1,414 h : null14 h 30 → indisponibleCas fictif, 1er octobre 2026, toutes heures UTC.
Une révision ne change pas ce qui était connu par une décision antérieure.

Faites défiler horizontalement ou agrandissez le schéma pour lire les détails.

Versions et indisponibilitéTrois événements fictifs GDP-model du 1er octobre 2026 UTC : chaînes 1.0/1.4/null.EXEMPLE DE CALCUL12 h 301,013 h 301,414 h 30Indisponible
Versions et indisponibilité. Trois événements fictifs GDP-model du 1er octobre 2026 UTC : chaînes 1.0/1.4/null.

À 14 h 30, null bloque : ni zéro ni repli vers 1,4 dans cette politique.

12 h 30
1,0 – Révision 13 h encore future.
13 h 30
1,4 – Dernière version admissible.
14 h 30
Indisponible – Null explicite, pas zéro.

À 12 h 30, dernier enregistrement admissible : 1,0 ; à 13 h 30 : 1,4. À 14 h 30, le plus récent admissible est null : notre variante bloque l'évaluation d'un nouveau signal, sans remplacer par 0 ni reprendre 1,4. Une règle hypothétique « valeur strictement supérieure à 1,2 » serait fausse à 12 h 30. Employer la future révision 1,4 l'inverserait sans changer aucun prix. Le sélecteur de l'outil ne calcule pourtant ni signal ni rendement.

Conserver la dernière valeur connue serait une politique distincte, avec âge maximal et motif d'absence définis avant examen des résultats. Ne l'ajoutez pas seulement après avoir trouvé une meilleure courbe et ne présentez pas cette modification comme test inchangé.

Contrat exact du relecteur local

Collez un objet JSON avecversion: 1 numérique et tableauevents de 1 à 200 événements. Chaque événement a exactementavailableAt, observation, value, revision. Le timestamp suitYYYY-MM-DDTHH:mm:ssZ, sans fraction de seconde ni autre offset. observation et revision sont des chaînes ; value est une chaîne numérique à point décimal ou null, jamais convertie en Number.

Limites : 64 KiB JSON, huit niveaux, 2000 valeurs ; observation et value jusqu'à 128 caractères, revision 64. Renseignez decisionAt séparément au même format UTC. La version sélectionnée est la dernière dont availableAt ne dépasse pas la décision, borne incluse. Avant le premier événement, aucune valeur n'est disponible. Même observation et même availableAt dans deux entrées bloquent l'analyse comme ambiguïté ; l'ordre de collage et l'étiquette de révision ne résolvent pas cette collision.

Relire l'information disponible au moment de décision

Cet exemple pédagogique fonctionne localement dans votre navigateur : il ne se connecte ni au compte ni à une API, ne transmet pas vos saisies et ne les conserve pas de façon persistante. Ne saisissez ni mot de passe ni données personnelles.

Format et limites du modèle

version: 1; events: 1 à 200 objets possédant exactement les champs availableAt, observation, value, revision. availableAt: YYYY-MM-DDTHH:mm:ssZ. observation: chaîne de 128 caractères au maximum ; revision: chaîne de 64 caractères au maximum ; value: chaîne numérique à point décimal (128 caractères au maximum), ou null. Une absence ne signifie pas zéro.

La dernière version dont availableAt ne dépasse pas la décision est sélectionnée. Deux entrées partageant observation et availableAt sont ambiguës et bloquent l’analyse. Limites JSON : 64 KiB, 8 niveaux, 2 000 valeurs. Les heures sont des déclarations : cette page ne vérifie pas l’heure réelle de publication.

Ce modèle travaille localement sur les événements collés, sans téléchargement d'annonce, accès au compte ou clé API, transmission des saisies ni conservation persistante. Il ne vérifie pas l'heure réelle du fournisseur. Un JSON valide peut déclarer des dates fausses : attribuer la première date à toutes les révisions donnera une sélection techniquement correcte sur des hypothèses erronées.

Contre-exemple EUR distinct : observation fictive de coût « commission-estimee-EUR », 2 EUR disponibles à 12 h puis 3 EUR à 13 h. Avec budget 20 EUR et perte de prix prévue 18 EUR, la somme vaut 20 EUR à 12 h 30, mais 21 EUR après la révision. Employer 3 EUR dans la décision ancienne modifierait son information. Ce n'est ni tarif de courtier ni autorisation d'ordre ; frais réels et glissement restent à vérifier séparément.

Conservez un jeu figé pour les agents parallèles au lieu de l'écraser par une réponse en direct. Archivez sa version dans Même backtest, résultat différent : comparer les preuves, pas seulement le nom de l'endpoint. Backtest Python : alignement, disponibilité et exécution développe les jointures temporelles ; données, prix Bid/Ask, frais, quantité et états d'ordres restent des composants distincts.

Protocole avant de juger les résultats

  1. Déclarez schéma, adaptateurs et preuves d'heure ; marquez les versions anciennes manquantes comme limites.
  2. Tracez un cas avant première valeur, entre publication et révision, puis après null ; testez borne exacte et timestamps contradictoires.
  3. Vérifiez le fichier réellement lu par le testeur, puis archivez jeu, rapport et entrées sélectionnées ensemble.
  4. Après réconciliation des données, contrôlez signaux, exécutions et coûts sans attribuer tout écart à la stratégie.

Le Backtest : test historique d’une règle d'un Expert Advisor (EA), robot MetaTrader peut lire correctement une version sans posséder un avantage. Le Calendrier économique demande lui aussi de séparer période observée, publication et révision.