SL, TP et robots : que reste-t-il actif quand MetaTrader ferme ?

Fermer votre MT4 ne supprime pas automatiquement les protections et ordres déjà acceptés par le serveur du courtier. Cela arrête la logique de cette copie locale. La distinction essentielle est donc « accepté et stocké où ? », plutôt que « ai-je cliqué sur le bouton ? ». Une conservation côté serveur ne garantit ni déclenchement en toute circonstance ni exécution au prix exact ; le produit, la validité et les règles d’exécution comptent toujours.

SL et TP : vérifier l’état accepté

Un SL ou TP enregistré auprès du courtier appartient à l’état de l’ordre ou de la position. Les ordres en attente acceptés peuvent aussi rester actifs selon leur durée et leurs conditions. Une saisie dans le formulaire ou une requête envoyée ne démontre pas que le changement existe effectivement. Vérifiez le compte, le serveur, le ticket et les valeurs enregistrées. Un stop ordinaire peut subir un glissement ou une discontinuité ; une éventuelle garantie est une caractéristique contractuelle particulière, pas une propriété universelle de MT4.

Une réponse perdue ne révèle pas le SL enregistré

Notre modèle contient deux versions possibles après une demande de modification de 1,0900 vers 1,0950. Dans A, le serveur accepte le nouveau SL mais la réponse n’est pas observée localement. Dans B, le changement n’est pas accepté et l’ancien 1,0900 reste enregistré. Les deux produisent le même symptôme : aucune réponse observée. Ce symptôme seul ne permet pas de sélectionner la version A ou B.

Un symptôme, deux SL possibles

Demande fictive 1,0900 vers 1,0950 ; position toujours ouverte, sans changement concurrent.

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

Nous supposons ici la même position toujours ouverte et aucune autre modification. En réalité, elle pourrait aussi avoir été clôturée, une demande pourrait rester en traitement ou une autre instance agir. Après rétablissement d’une connexion actuelle et synchronisation, lisez l’état de la bonne position. Une ancienne copie de données ne règle pas l’incertitude. MQL4 précise que OrderSelect() copie des propriétés qui peuvent devenir périmées ; rappeler une fonction sur un environnement non synchronisé n’établit pas une lecture serveur fraîche. Le résultat documenté de OrderModify() se distingue aussi d’une réponse que vous n’avez pas observée.

Les ordres en attente restent des instructions

Buy limit, sell limit et ordres stop acceptés dépendent de leurs conditions de déclenchement, de validité et d’exécution. La fermeture du terminal personnel n’est pas une annulation automatique. Une coupure de marché n’est pas l’unique cas à contrôler : expiration, suspension du symbole, état du compte et refus d’opération peuvent aussi compter. Après reconnexion, rapprochez positions ouvertes, instructions actives et historique. Ne recréez pas un ordre uniquement parce qu’une fenêtre locale n’affiche pas la confirmation attendue.

EA et trailing stop local ne sont pas le SL serveur

Un EA répond aux événements programmés, par exemple ticks ou minuterie ; ce n’est pas nécessairement une action pour chaque tick reçu. MQL4 traite les événements en série et ne rajoute pas un NewTick lorsqu’un événement équivalent est déjà en attente ou en traitement. Fermer le terminal décharge l’EA. Une simple perte réseau est différente : le code peut rester chargé sans pour autant disposer de nouvelles cotations ou d’un accès opérationnel au serveur.

Le trailing stop standard MT4 calcule localement des demandes de modification. Quand cette copie ferme, il ne suit plus les prix ; seul le dernier SL effectivement accepté demeure sous ses conditions. Activer le trailing ne prouve pas qu’un premier SL a déjà été placé. Une fonction de trailing côté serveur proposée par un autre service ne doit pas être confondue avec ce mécanisme standard.

Un exemple qui sépare activation et distance

Cas entièrement fictif : achat EUR/USD à 1,0865, SL accepté 1,0810, TP accepté 1,0920, trailing de 40 pips, soit 400 points pour cette cotation à cinq décimales, et un EA local. La fermeture a lieu à 23 h dans notre scénario, sans signification particulière de session. Un Bid à 1,0910 donne 45 pips favorables ; le trailing peut demander un SL à 1,0870. Si ce niveau est accepté avant la fermeture, c’est lui qui remplace 1,0810. En revanche, un Bid de 1,0880 ne donne que 15 pips : il n’active pas un seuil de 40 pips.

La distance de 40 pips n’est pas une promesse de modification par pas de 40 pips. Elle ne garantit pas non plus le prix final de clôture. Dans un exemple EUR indépendant, 2 000 EUR de base achetés à 1,0865 puis clôturés exactement à 1,0810 perdent 11 USD. Une conversion hypothétique fixe à 1,10 USD/EUR donne 10 EUR de perte, puis 1 EUR de frais donne 11 EUR. Si la sortie glisse à 1,0800, la perte devient 13 USD / 1,10 + 1, soit environ 12,82 EUR. Le budget de 12 EUR convient au premier calcul, pas au second ; il n’est pas une limite garantie.

VPS : identifier l’instance qui travaille

Un VPS Windows général peut héberger une autre copie du terminal, avec surveillance du processus, du réseau et des journaux. L’hébergement virtuel MetaQuotes migre un environnement sélectionné ; ce n’est pas un bureau Windows complet accessible à distance. La documentation MT4 interdit les appels DLL dans cet hébergement et ne migre pas les scripts. Elle décrit l’autorisation d’autotrading distant et la désactivation locale lors de la migration pour éviter deux copies agissant ensemble.

Un bouton local modifié ensuite n’est pas une preuve d’arrêt de l’instance distante. Contrôlez les journaux et l’état de cette dernière. Un simple SL/TP déjà accepté sur le serveur ne nécessite pas votre propre VPS pour rester enregistré ; c’est la logique additionnelle qui peut avoir besoin d’un hôte actif.

Deux changements réussis peuvent donner deux résultats

Autre modèle sans exécution ni acteur supplémentaire : entrée à 1,1050, deux modifications acceptées successivement à 1,1030 et 1,1000. Si 1,1000 est le dernier niveau accepté, il est à 50 pips sous l’entrée. Dans l’ordre inverse, le dernier 1,1030 est à 20 pips. Les deux demandes peuvent avoir réussi tout en produisant un état final différent selon leur ordre. Nous supposons les niveaux valides et ne simulons pas le trajet de prix entre les opérations. C’est pourquoi il faut rapprocher chronologie et état, pas compter uniquement les messages « succès ».

Contrôle à effectuer sur démonstration

1. Inventoriez SL/TP acceptés, ordres actifs, trailing, stops cachés et chaque instance locale ou distante.
2. Avant une fermeture, relevez compte, ticket, niveaux et horodatage avec fuseau ; vérifiez ce qui est réellement accepté.
3. Après reconnexion et synchronisation, contrôlez état courant et historique avant toute nouvelle requête. Si l’incertitude reste, utilisez le support officiel.

Le diagnostic des erreurs d’ordre aide à distinguer refus, résultat partiel et état incertain. Le stop loss reste une instruction conditionnelle à vérifier, pas une perte maximale universelle.