Surveiller un EA Forex dans MT4 : cotations, heartbeat et alertes

Définir le fonctionnement normal avant de rechercher une panne

Un EA peut fonctionner correctement sans ouvrir de position. Son filtre horaire, sa limite de spread, un panier existant, une règle de risque ou l'absence de signal valide peuvent expliquer cette inactivité. La surveillance doit vérifier si l'environnement prévu peut remplir sa fonction documentée, y compris gérer les ordres existants, sans exiger un nombre minimal de trades.

Consignez l'identité du terminal, le compte et le serveur prévus, les symboles et unités de temps exacts, la version de l'EA, les paramètres approuvés, les règles de responsabilité des ordres et les périodes de fonctionnement attendues. Incluez les autres symboles nécessaires. Demandez au développeur quels états, journaux et comportements après redémarrage le programme expose réellement. Un fichier EX4 ne fournit pas automatiquement de signal périodique d'activité ni d'explication complète de chaque décision.

Distinguez trois états : normal, problème confirmé et inconnu. Si un tableau de bord ne s'actualise plus, affichez la dernière observation et indiquez que l'état actuel est inconnu. Un ancien indicateur vert ne constitue pas une preuve actuelle.

Vérifier quatre niveaux de preuve

Ces vérifications sont distinctes. Elles peuvent être manuelles ou regroupées par un système de surveillance volontairement configuré. MT4 ne les combine pas automatiquement dans le tableau de bord décrit ici.

Une revue de cinq minutes sans modifier la stratégie

1. Confirmez où fonctionne l'EA. Examinez le terminal et le compte prévus, pas un graphique local resté ouvert après migration.
2. Vérifiez la séance et les cotations requises. Déterminez si des mises à jour sont attendues maintenant et si les symboles exacts du courtier ont des données utilisables.
3. Contrôlez initialisation et autorisations. Lisez les messages récents de Experts et Journal ainsi que l'état documenté de l'EA.
4. Examinez les ordres actuels. Vérifiez leur responsable et les protections réellement présentes chez le courtier.
5. Vérifiez le circuit de surveillance. Confirmez l'heure du dernier rapport et la réception d'une alerte test sur l'appareil prévu.

Cinq minutes désignent un format de revue, pas un diagnostic garanti ni un délai de réaction adapté à tous les EA. En cas de doute, conservez les éléments et consultez le guide des erreurs d'EA. Ne relâchez pas les limites de spread ou de risque, ne changez pas les Magic Numbers et ne forcez pas d'entrée pour rendre un indicateur vert.

Être connecté ne signifie pas recevoir des cotations récentes

IsConnected() indique la connexion du terminal au serveur. Cela ne certifie ni les données récentes de chaque symbole, ni l'accès au trading, ni le bon fonctionnement de la stratégie. Vérifiez les noms exacts, suffixes du courtier compris, et les données nécessaires au-delà du graphique de l'EA.

MarketInfo(symbol, MODE_TIME) donne l'heure du dernier tick reçu pour ce symbole, selon l'heure serveur du courtier. La dernière cotation est une observation passée, pas une horloge qui avance sans nouveaux ticks. Le week-end, pendant les interruptions de séance et les périodes calmes, une ancienne cotation peut être normale. Vérifiez le calendrier réel du courtier avant de conclure à une panne des données.

Définissez les contrôles d'ancienneté par symbole et séance après observation du fonctionnement normal. Aucun délai universel sûr ne convient à toutes les paires Forex ou à tous les EA. Un Bid inchangé ne suffit pas non plus : plusieurs ticks peuvent porter le même prix. Lorsque c'est possible, enregistrez la réception d'événements de données plutôt que les seuls changements de prix.

Choisir la bonne horloge pour chaque question

Ne soustrayez pas directement l'heure d'une cotation à l'horloge Windows pour calculer son âge sans établir une référence commune. Un développeur peut mesurer des intervalles avec un compteur approprié, mais doit gérer remises à zéro et débordements. Un collecteur externe doit détecter les rapports absents avec sa propre mesure de durée testée, séparée des horodatages du marché.

Associez aux journaux la source, la date et le fuseau horaire. Normalisez les sources avant de reconstituer un incident ; deux heures semblables à l'écran ne prouvent pas l'ordre des événements. Voir le guide Experts et Journal.

Déterminer ce qu'un heartbeat prouve réellement

Un heartbeat est un rapport périodique d'un composant identifié. Celui du VPS renseigne sur cette machine ; celui d'un EA de surveillance, sur ses propres événements. Aucun ne prouve automatiquement qu'un autre EA de trading a évalué un signal ou géré un panier.

OnTick() s'exécute lors des nouveaux ticks du symbole du graphique auquel l'EA est attaché. Un heartbeat envoyé uniquement depuis ce gestionnaire peut disparaître en l'absence de ticks. Si le développeur l'a prévu, le programme peut employer EventSetTimer() avec OnTimer() pour demander des événements périodiques. Ceux-ci sont mis en file d'attente ; si un événement Timer est déjà en attente ou en cours, aucun nouveau n'est ajouté. Ce n'est pas une horloge externe précise ni une garantie qu'un programme bloqué continuera à informer.

Demandez quel point de contrôle produit le rapport : entrée dans un gestionnaire, contrôle des données terminé, cycle de gestion terminé ou transmission réussie. Identité d'instance, version, numéro de séquence, mode, état des données et heures de génération/réception sont utiles. Une séquence croissante distingue les nouveaux rapports des répétitions, sans prouver une exécution d'ordre.

Avec un EA sans code source accessible, utilisez les états prévus par le fournisseur et les observations externes. Un observateur ajouté n'accède pas pour autant au fonctionnement interne de la stratégie. Un EA de surveillance séparé nécessite son propre graphique ; l'attacher au graphique de la stratégie remplace l'EA existant. Il doit observer sans envoyer de trades ni gérer les ordres de la stratégie.

Détecter les rapports absents depuis l'extérieur du terminal

Un terminal arrêté ne peut pas envoyer fiablement son propre dernier message de panne. Un observateur indépendant peut détecter l'arrêt des rapports attendus si lui-même, sa connexion et son canal d'alerte fonctionnent encore. Garder l'unique superviseur sur le même VPS l'expose à la même panne de machine.

Séparez collecte et intervention. Une alarme de rapport absent signifie que l'observation a échoué quelque part entre émetteur, réseau, collecteur et circuit d'alerte. Elle ne prouve pas que l'EA principal a cessé de trader et ne doit pas activer automatiquement une autre instance. Examinez la machine et les ordres actuels avant le transfert décrit dans le Guide 3.

Attribuez une identité de surveillance distincte à chaque instance prévue et détectez les émetteurs inconnus ou en double. Surveillez aussi le collecteur et testez un contact de secours. Transmettez uniquement l'état nécessaire ; mots de passe, secrets d'activation et accès illimité au compte n'ont pas leur place dans un heartbeat.

Surveiller les autorisations sans les activer aveuglément

Dans MT4 de bureau, contrôlez AutoTrading, l'autorisation propre à l'EA, l'accès de trading du compte prévu et la licence du fournisseur. Une connexion en lecture seule peut afficher le compte tout en empêchant de trader. Un changement d'autorisations peut laisser l'EA calculer sans pouvoir modifier les ordres comme prévu.

IsTradeAllowed() sans argument vérifie les autorisations de l'EA appelant et la disponibilité du contexte de trading. false n'est pas un diagnostic complet ; true ne garantit pas que le courtier acceptera la prochaine requête. Le résultat d'un observateur séparé ne certifie pas les autorisations individuelles d'un autre EA.

Alertez sur un écart inattendu du mode approuvé. Un terminal volontairement suspendu doit être enregistré comme tel, sans « réparation » automatique par un superviseur. Désactiver l'automatisation ne ferme pas les positions et peut interrompre les sorties locales. Toute pause exige un plan de gestion explicite.

Surveiller les requêtes échouées et les positions existantes

Suivez une requête documentée : action prévue, tentative, résultat retourné et rapprochement avec les données du courtier. Rejets et modifications échouées comptent même sans nouvelle position. Si le fournisseur ne journalise ni tentatives ni motifs de signaux ignorés, la liste des trades ne permet pas de reconstituer fiablement ces informations.

L'erreur 128 indique un délai d'attente dépassé pour une opération. Après une réponse perdue ou incertaine, contrôlez ordres ouverts, ordres en attente et historique pertinent avant de décider d'un nouvel envoi. L'absence de confirmation locale ne prouve pas un rejet. Incluez symbole exact, sens, volume, ticket connu et heure de requête ; ne devinez pas quel ordre correspond à la tentative.

Examinez exposition, P/L latent, equity et Stop Loss/Take Profit acceptés avec les règles de responsabilité de l'EA. La protection chez le courtier diffère d'un stop virtuel prévu ou d'un futur ajustement de trailing. Un EA arrêté peut laisser des positions ouvertes ; un ordre en attente peut se déclencher sans surveillance locale. Ce guide ne fixe ni nouveau seuil de drawdown ni liquidation automatique.

Tester les alertes jusqu'au destinataire

1. Dans le terminal prévu, ouvrez Tools → Options → Notifications, activez les notifications push et saisissez le MetaQuotes ID du terminal mobile voulu.
2. Utilisez Test, vérifiez le résultat dans le terminal et la réception sur l'appareil réel. Contrôlez ses autorisations de notification et le circuit pratique de réponse.
3. Testez séparément la vraie condition d'alerte de l'EA ou de l'observateur. Un test de paramètres ne prouve pas l'existence d'une règle de heartbeat absent ou de requête rejetée.
4. Consignez heure, émetteur, destinataire et résultat ; recommencez après migration du VPS, changement d'appareil ou modification des notifications.

Notify of trade operations concerne les opérations réussies et certains événements de compte documentés ; les opérations échouées ne sont pas notifiées. Ce n'est donc pas une surveillance complète des rejets, données anciennes ou pannes du terminal.

Pour SendNotification(), MetaQuotes documente une limite de 255 caractères, au maximum 2 appels par seconde et 10 par minute. Dépasser les limites de fréquence peut désactiver la fonction. Elle ne fonctionne pas dans Strategy Tester : vérifiez la livraison dans un environnement démo en cours d'exécution adapté. Un envoi réussi ne prouve pas qu'une personne a vu ou acquitté le message. Regroupez les erreurs répétées et signalez les changements d'état utiles plutôt que chaque tick.

Écrire chaque règle avec un contexte et une action suivante

Définissez durée de persistance, intervalle de répétition, acquittement et condition de retour à la normale. Un message de reprise doit préciser quelles observations ont recommencé ; un seul heartbeat ne prouve pas le rétablissement de tous les niveaux. Prévoyez une fenêtre de maintenance avec responsable et heure de fin, sans désactiver définitivement une alarme trop fréquente.

Évaluez la gravité selon la situation réelle du compte. Le même problème de données peut avoir des implications différentes sans exposition ou avec des positions dépendant de sorties locales. La surveillance identifie ce contexte, sans fournir un délai d'attente universellement sûr.

Un exemple de heartbeat absent avec une seule horloge

Exemple hypothétique : un collecteur attend un rapport identifié toutes les 60 secondes et alerte après 180 secondes sans nouveau rapport. Ces valeurs sont pédagogiques, pas des seuils universels recommandés. Toutes les heures ci-dessous sont des observations du collecteur en UTC ; aucune heure de cotation du courtier n'en est soustraite.

Ici, 180 ÷ 60 = 3 intervalles attendus se sont écoulés sans nouvelle réception. Cela ne prouve ni l'arrêt du trading à 10:00:00, ni un rejet du serveur, ni l'absence de gestion de l'ordre. Vérifiez EA, journaux et état actuel des ordres avant d'agir. Si le collecteur lui-même était indisponible, il ne peut prétendre avoir observé tout l'intervalle sans interruption.

Tenir un registre opérationnel simple

Notez dernière revue réussie, état des données requises, identité EA/terminal, responsable des ordres ouverts, messages non résolus, résultat du test d'alerte et changements prévus. Vérifiez après déploiement, redémarrage, migration, modification approuvée des paramètres et maintenance du courtier, puis à une fréquence adaptée aux besoins réels de gestion de l'EA.

Un suivi public aide à examiner les performances, mais vérifiez sa dernière mise à jour et son délai de publication. Une belle courbe de solde n'est pas un contrôle opérationnel en temps réel. Un rapport sans nouveauté ou un solde plat ne distingue pas l'attente d'un signal d'une panne. Séparez évaluation des performances et surveillance opérationnelle immédiate.

Observer l'environnement qui trade réellement

Sur un VPS Windows, contrôles machine/processus, observations du terminal et collecteur indépendant peuvent couvrir différentes pannes. Examinez ressources et démarrage dans le Guide 2 ; une connexion Windows réussie ne confirme pas le fonctionnement de l'EA.

Pour l'hébergement virtuel intégré de MetaTrader, consultez état distant, synchronisation et journaux terminal/Experts demandés via ses commandes. Un graphique ou heartbeat local ne montre pas l'EA distant. Tout heartbeat distant doit être volontairement déployé, compatible et testé dans cet environnement ; services Windows et outils à DLL non prises en charge ne s'y transfèrent pas simplement.

AutoTrading local n'arrête pas la copie hébergée. Utilisez les commandes d'hébergement et vérifiez l'état distant réel lors d'une intervention. Le système doit identifier s'il observe l'hôte principal de trading, un terminal local de préparation ou un secours.

Répéter les scénarios de surveillance sur démo

Utilisez un environnement démo autorisé avec ses propres fichiers d'état. Testez fermeture contrôlée du terminal, perte du circuit de rapports, interruption de séance prévue, pause volontaire et retour à la normale. Distinguez une véritable alerte d'un test de livraison réussi. Ne créez pas de position réelle sans gestion pour tester un superviseur.

Consignez configuration testée, observations et angles morts restants. Une surveillance réussie réduit l'incertitude ; elle ne garantit ni disponibilité, ni exécution, ni performance de stratégie.

Questions courantes sur la surveillance d'un EA

Aucun nouveau trade signifie-t-il que l'EA est en panne ?

Non. Vérifiez séance, règles de signal, données, autorisations et gestion des ordres existants. Une stratégie saine peut rester inactive à juste titre.

Un heartbeat prouve-t-il que toutes les fonctions sont saines ?

Non. Il prouve uniquement que le rapport documenté a été généré ou reçu. Sa valeur dépend du point où il est produit et des champs réellement à jour.

Les notifications push standard détectent-elles toute panne ?

Non. Les notifications de trades réussis omettent les opérations échouées, et un terminal arrêté ne peut signaler fiablement sa propre panne complète. Testez séparément règles personnalisées et détection indépendante des rapports absents.

Un heartbeat absent doit-il démarrer automatiquement un VPS de secours ?

Non. Établissez d'abord l'état de trading du principal, les ordres actuels du courtier et la responsabilité de leur gestion. Un rapport absent n'autorise pas une automatisation en double.

Références officielles et portée pratique

Les détails de plateforme ont été vérifiés dans la documentation officielle MetaQuotes. Format de revue, seuils de l'exemple et règles d'incident sont des conseils opérationnels pédagogiques, pas un produit de surveillance fourni ni des résultats mesurés de fiabilité. Les noms d'interface varient selon la langue ; vérifiez votre installation.

• MQL4 : état de connexion et autorisations de l'EA.
• MQL4 : horodatages des cotations, heure serveur et limites des événements Timer.
• MetaTrader 4 : réglages des notifications ; MQL4 : limites des push personnalisés.
• MetaTrader 4 : état et journaux de l'hébergement distant.