MT5 Fermer tout : pourquoi des positions restent ouvertes

Dans MT5, Fermer toutes les positions décrit une suite de demandes, pas une garantie de clôture simultanée de tout le compte. Un refus, une interruption ou la fermeture de l’application peut laisser de l’exposition. La bonne question est : quelles quantités ont réellement été clôturées et que reste-t-il maintenant ? Nous examinons les opérations groupées intégrées, pas le comportement supposé de tous les scripts portant un nom similaire.

Quel périmètre couvre la commande ?

Relevez son nom complet : toutes les positions, les gagnantes, les perdantes, un symbole ou un sens. La sélection d’une position peut changer les commandes proposées. Une inversion n’est pas une clôture : elle peut recréer une exposition opposée. Le nombre de fenêtres disparues ne confirme pas le périmètre traité.

Sur un compte hedging, l’aide MT5 décrit d’abord des Close By entre positions opposées, puis des clôtures ordinaires des positions restantes. Une erreur dans la phase séquentielle Close By arrête le processus. Dans la phase asynchrone suivante, un refus laisse sa position ouverte sans empêcher l’envoi des autres demandes. Les comptes FIFO utilisent une séquence qui s’arrête sur erreur ; certaines commandes incompatibles n’y sont pas proposées. Les opérations groupées demandent One Click Trading. Vérifiez compte et réglages, plutôt qu’une règle supposée propre à la France ou à une langue.

Comment rapprocher cinq positions ?

Modèle fictif source : compte hedging sans FIFO, EUR/USD autorisant Close By. A est un achat EUR/USD de 0,10 lot ; B une vente du même symbole de 0,10. C est un achat GBP/USD de 0,20 ; D une vente USD/JPY de 0,10 ; E un achat XAU/USD de 0,05. Nous excluons exécutions partielles, nouvelles entrées et autres événements. Nous ne calculons pas leur résultat monétaire et n’additionnons pas des lots de contrats différents.

La paire A–B est confirmée clôturée : le nombre passe de cinq à trois. Les demandes ordinaires pour C, D et E partent ensuite sans attendre chaque confirmation précédente. C et E sont clôturées ; D est refusée. Il reste une position D, vendeuse USD/JPY de 0,10 lot. Trois demandes envoyées n’ont produit que deux clôtures ordinaires.

Cinq positions au départ, une reste exposée

Compter les résultats, pas les clics

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

Pour chaque ticket, conservez symbole, sens, quantité initiale, identifiant de demande ou d’ordre, réponse, exécutions et volume restant. DEAL_ORDER et DEAL_POSITION_ID relient les événements. Un ordre peut produire plusieurs exécutions : une seule ligne n’est pas forcément la clôture intégrale d’un ticket. Distinguez refus confirmé et résultat non résolu ; l’absence de réponse n’est pas une preuve d’absence d’exécution.

Ajout distinct en EUR, sans conversion des contrats précédents : une clôture partielle confirmée a réalisé +24 EUR et imputé 2 EUR de coûts, mais une position restante est valorisée −9 EUR au même instant. Le solde a augmenté de 22 EUR ; le résultat combiné de ce périmètre est de 13 EUR. La hausse du solde ne prouve donc pas que tout le risque a disparu. Ce cas ne mesure ni le délai ni les tarifs d’une plateforme réelle.

Que change une erreur ou une interruption ?

Variante séparée : A–B reçoit une erreur Close By avant toute exécution. Sous cette hypothèse explicite, la séquence s’arrête avant C, D et E ; les cinq positions restent. Ce n’est pas le même état que le refus de D après la paire confirmée. Dans un incident réel, une réponse absente exige d’enquêter sur l’état serveur.

Fermer l’application termine le processus groupé sans annuler les transactions déjà confirmées. Si A–B a fermé et si aucune demande C–E n’a encore été envoyée, trois positions restent dans cette variante. Les demandes déjà envoyées doivent être rapprochées du serveur. Redémarrer ne démontre pas un compte sans position et ne justifie pas de relancer la liste initiale de mémoire.

Un EA, une autre application ou une personne peut créer une nouvelle position pendant l’opération. Un nouveau ticket n’est pas nécessairement une ancienne clôture échouée. Comparez événements, origine et horaires. Pour une automatisation MQL5, un retour true d’OrderSend n’est pas la preuve de l’exécution : contrôlez résultat, événements et compte.

Une liste de positions vide termine-t-elle le contrôle ?

Vérifiez aussi les ordres différés. MT5 propose leur suppression séparément ; fermer les positions ne confirme pas leur annulation. Un achat différé P peut rester, puis exécuter et recréer une position. Une demande d’annulation non résolue conserve donc son propre risque d’interprétation.

Après synchronisation, retirez les filtres qui pourraient masquer un symbole ou un sens. Rapprochez historique et quantité actuelle sur le bon compte. Une capture vide prouve seulement une observation dans ce périmètre et à cet instant ; elle ne prouve pas qu’un EA ne rouvrira rien. Contrôlez les protections de tout reliquat. Ordre refusé sur MT4 ou MT5 : diagnostiquer sans augmenter le risque aide ensuite à qualifier les refus.

Comment préparer une vérification fiable ?

• Sur démonstration, préserver le mode de compte, la commande complète et l’état initial de chaque ticket.
• Séparer les étapes Close By et ordinaires, puis marquer confirmations, refus et résultats incertains.
• Relire les quantités et protections actuelles avant une nouvelle opération.
• Vérifier positions et ordres différés, avec l’heure et le périmètre final dans le journal.