Comment diagnostiquer l'erreur 130 d'un EA MT4 ? Méthode en quatre étapes, de la distance du stop loss aux limites dynamiques
Diagnostiquer pas à pas l'ERR_INVALID_STOPS d'un EA MT4 à l'aide d'un organigramme original bleu clair : journaux, précision des cotations, MODE_STOPLEVEL et limites dynamiques, afin d'éviter de masquer le risque en élargissant le stop loss.
Auteur : Thomas|Pratique EA et MT4|20 octobre 2026
Lorsqu'un EA est déjà attaché à un graphique et que le trading automatique est activé, mais qu'un « 130 » apparaît lors de la soumission d'un ordre, on a souvent tendance à croire que le programme est complètement défaillant. La documentation de référence MQL4 classe le code 130 comme ERR_INVALID_STOPS : le stop loss, le take profit, le prix de l'ordre en attente ou leur mode de normalisation dans la requête n'ont pas été acceptés par le serveur de trading. Il s'agit d'un indice de localisation, et non d'une raison d'élargir aveuglément le stop loss. Cet article présente une méthode de diagnostic en quatre étapes pour déterminer quels enregistrements consulter.
Première étape : identifier d'abord quelle requête a échoué
Ouvrez le terminal MT4 ou le journal correspondant du programme, et notez l'heure serveur de l'erreur, le symbole, le sens de l'ordre, si l'opération est OrderSend ou OrderModify, ainsi que le code d'erreur retourné. Si le journal ne contient que les mots « échec de l'ordre », demandez d'abord à l'EA d'enregistrer le prix de la requête, le stop loss, le take profit et la valeur de retour, sans afficher de données sensibles telles que les mots de passe. Distinguez d'abord l'échec d'ouverture de position, l'échec de modification du stop loss et l'échec d'ordre en attente ; les relations de prix à vérifier diffèrent selon les trois cas.
Ne cherchez pas à « tenter sa chance » sur un compte réel en renvoyant sans cesse la même requête en échec. Les tentatives répétées peuvent générer une charge supplémentaire et, après une variation du marché, réussir soudainement et créer une position inattendue. Reproduisez d'abord le problème dans un environnement de démonstration, en conservant la version des paramètres et les cotations de la plateforme à ce moment-là.
Deuxième étape : vérifier Bid, Ask, Point et Digits
MarketInfo de MQL4 permet de lire le Bid, l'Ask, le Point et les Digits du symbole courant. Le Point représente l'une des plus petites unités d'affichage de la cotation, et Digits le nombre de décimales ; le montant en dollars que représente « 10 points » doit être calculé selon le Point réel du symbole, sans confondre les codes de l'or et les précisions de différents courtiers. Avant la transmission, le prix doit également être normalisé selon le nombre de décimales correspondant.
Exemple purement mathématique : si le Point d'un symbole de démonstration est de 0,01 et la distance minimale de 50 points, la distance calculée est de 0,50 unité de cotation ; avec un symbole dont le Point est de 0,001, elle serait de 0,05. Ces chiffres ne représentent aucune règle contractuelle réelle d'une plateforme aujourd'hui. Lors de la consultation des journaux, enregistrez également les prix d'achat et de vente, afin d'éviter de vérifier avec le prix de vente le côté qui devrait se référer au prix d'achat, ou inversement.
Troisième étape : vérifier MODE_STOPLEVEL et le type d'ordre
La documentation officielle d'OrderSend indique que le stop loss et le take profit ne doivent pas être trop proches du prix du marché ; le prix d'ouverture prévu d'un ordre en attente ne doit pas non plus être trop proche du marché actuel. MarketInfo(Symbol(),MODE_STOPLEVEL) permet de consulter la distance minimale publique, exprimée en points. Vérifiez ensuite séparément, selon qu'il s'agit d'un achat, d'une vente ou d'un type d'ordre en attente, la direction du prix, la distance et la normalisation, plutôt que d'appliquer un décalage fixe à tous les ordres.

L'image ci-dessus est un schéma de processus original, sans cotation ni données de compte réelles. La distance minimale n'est qu'une limite technique pour l'acceptation de l'ordre par le serveur, et non une distance de stop loss raisonnable sur le plan stratégique. Si l'on éloigne le stop loss pour contourner l'erreur 130, le risque prévu par transaction augmente ; il faut d'abord recalculer la taille de position et, si nécessaire, renoncer à cette transaction.
Quatrième étape : un retour de 0 ne garantit pas l'absence de limite
La documentation officielle MQL4 sur MODE_STOPLEVEL précise que le retour de 0 peut signifier l'absence de distance minimale fixe, mais aussi que le serveur applique une limite dynamique que le terminal ne peut pas représenter directement. Dans ce dernier cas, l'erreur 130 peut encore se produire. Ainsi, « si l'on obtient 0, on colle le stop loss au prix » n'est pas valable. Lors de fortes variations du marché, la mise à jour des cotations, les changements de spread et les règles côté serveur peuvent également invalider une distance calculée auparavant.
Si la formule du code correspond au journal de l'époque et que l'erreur 130 persiste, conservez l'heure de l'échec, le symbole, les paramètres de l'ordre et la version de la plateforme, consultez les spécifications du symbole et les restrictions d'ordre du courtier, et vérifiez auprès du support technique de la plateforme. Ne déduisez pas les règles de ce compte à partir du Point et du StopLevel d'une autre plateforme, et ne masquez pas la véritable cause de l'échec en supprimant le stop loss.
Ordre de vérification après correction
Exécutez d'abord un cas minimal reproductible sur un compte de démonstration : enregistrez les quatre paramètres de cotation et le StopLevel pour le même symbole, envoyez une requête de test unique, puis vérifiez la réponse du serveur et l'état de l'ordre. Testez ensuite le comportement lors de variations rapides des prix ou à différents moments de la séance. Vérifiez que le programme dispose d'un mécanisme d'arrêt ou de refroidissement après un échec, et qu'il ne rouvre pas de position lors d'une nouvelle tentative. Vérifiez enfin si le budget de risque, le spread et la perte acceptable correspondent toujours au plan initial.
Le diagnostic de l'erreur 130 porte sur « pourquoi la requête a été rejetée », et non sur « comment la forcer à s'exécuter ». Les résultats d'un EA dépendent aussi de la logique de stratégie, du réseau et de l'exécution de la plateforme ; aucune correction ne garantit un profit ni n'évite une perte. Le trading avec effet de levier peut entraîner des pertes importantes.