Off quotes / Requote sur MT5 — erreur 10021

Off quotes / Requote (MT5/MQL5) : la solution complète

Lorsque vous faites tourner un EA et que le journal ou l'onglet Expert affiche off quotes (10021) ou requote (10004), on a l'impression que le broker a refusé l'exécution, ce qui peut être source d'inquiétude. Pourtant, ces deux erreurs ne concernent ni les fonds ni la taille de lot, mais uniquement le prix. Le prix que vous avez envoyé ne correspondait plus à celui détenu par le serveur au même instant — c'est tout. Dans l'immense majorité des cas, la cause se ramène à l'un de ces quatre facteurs : mouvement brutal du marché, slippage toléré, mode d'exécution, ou latence réseau.

Cet article s'adresse aussi bien aux utilisateurs d'EA sous MT5 qu'aux développeurs MQL5. Il rassemble en un seul document de référence la nature, les causes, les solutions immédiates et les corrections de code durables pour 10021 (TRADE_RETCODE_PRICE_OFF), 10004 (TRADE_RETCODE_REQUOTE), ainsi que les erreurs 136/138 de l'ère MT4. Pour la liste complète des codes d'erreur, consultez le guide complet des codes d'erreur MQL5 / MT5.

Quelle est la différence entre ces deux erreurs (+ 136/138 sous MT4) ?

Les refus liés à une « incohérence de prix » se déclinent en deux types de réponse côté serveur.

① TRADE_RETCODE_PRICE_OFF = 10021 (aucune cotation exploitable)

Cette valeur, renvoyée dans MqlTradeResult.retcode en réponse à OrderSend(), signifie « il n'y a pas de cotation permettant de traiter la requête » (There are no quotes to process the request). Cela indique que le serveur ne dispose d'aucun prix valide, ou que le prix envoyé s'écarte trop de la cotation actuelle pour être traité.

Signification : aucune cotation disponible pour traiter la requête
Constante     : TRADE_RETCODE_PRICE_OFF
Valeur        : 10021

② TRADE_RETCODE_REQUOTE = 10004 (requote = nouvelle proposition de prix)

Également renvoyée via retcode par OrderSend(), cette valeur n'est pas un simple refus mais une contre-proposition : « ce prix n'est plus valable, mais voici un nouveau prix ». Les champs bid / ask de MqlTradeResult contiennent alors le nouveau prix proposé par le serveur.

Signification : Requote — nouvelle proposition de prix
Constante     : TRADE_RETCODE_REQUOTE
Valeur        : 10004

// Exemple de sortie typique dans le journal
2026.07.07 21:30:02.118 EA_NAME EURUSD,M5: OrderSend error 10004 (requote)
2026.07.07 21:30:02.310 EA_NAME EURUSD,M5: OrderSend error 10021

③ Les erreurs 136 / 138 de l'ère MT4

Sous MQL4 (MT4), le même phénomène était renvoyé via le code d'erreur de GetLastError().

Si vous rencontrez « error 136 » ou « error 138 » dans un ancien article ou dans le journal d'un EA MT4, le contenu de cet article s'applique directement (sous MT4, la pratique classique consistait à rappeler RefreshRates() pour rafraîchir le prix avant de renvoyer l'ordre ; l'équivalent en MT5 est détaillé plus loin).

Distinction pratique :

Dans les deux cas, il s'agit d'erreurs temporaires (pouvant faire l'objet d'une nouvelle tentative). Aucune modification de code ou de réglage ne permet de les éliminer totalement, mais on peut en réduire fortement la fréquence.

Diagnostic rapide en 30 secondes

1. Vérifier l'horodatage dans le journal
   • Au moment précis d'une annonce macroéconomique (emploi américain, FOMC, etc.) → mouvement de marché normal. Si votre EA dispose d'un filtre d'actualités, activez-le
   • Autour de minuit heure serveur (rollover) ou lors du gap du lundi matin → plage horaire à cotation clairsemée. Comportement attendu
   • Erreurs fréquentes et aléatoires, sans lien avec l'horaire → suspecter la connexion, le VPS, ou le réglage de deviation
2. Vérifier sur quel instrument l'erreur apparaît
   • Si elle se concentre sur des paires mineures, exotiques, ou des CFD peu liquides, la cause est la faible profondeur de cotation de l'instrument
3. Tester en passage d'ordre manuel
   • Si un ordre rapide manuel passe normalement alors que seul l'EA est refusé → le deviation (slippage toléré) de l'EA est probablement trop restrictif

Ces trois vérifications permettent d'orienter le diagnostic vers « le marché », « l'instrument » ou « le réglage/l'environnement » avant de passer aux solutions détaillées par cause.

Causes et solutions (5 scénarios)

① Mouvement brutal du marché / pic lors d'une annonce (le prix envoyé est devenu obsolète avant d'arriver)

Symptôme : les erreurs 10004/10021 se concentrent au moment des annonces économiques, des déclarations de responsables, ou tôt le lundi matin.

Cause : l'EA calcule un prix à partir d'un tick, puis l'ordre met de quelques dizaines à quelques centaines de millisecondes pour atteindre le serveur ; pendant ce laps de temps, le prix a bougé de plusieurs pips. Le prix envoyé n'existe déjà plus, donc le serveur renvoie soit un requote (10004), soit une absence de cotation (10021). Il ne s'agit pas vraiment d'une anomalie, mais d'un phénomène normal en marché rapide.

Solutions :

1. Bloquer les nouvelles entrées autour des annonces (filtre d'actualités). Les EA distribués sur ce site intègrent en standard un module EconomicFilter
2. Élargir le deviation (slippage toléré) à une valeur réaliste (voir ②)
3. Mettre en place une logique de nouvelle tentative (code présenté plus bas)

② Un deviation (slippage toléré) trop restrictif

Symptôme : l'erreur apparaît sporadiquement même en marché calme. Les ordres manuels passent, mais pas ceux de l'EA.

Cause : MqlTradeRequest.deviation déclare l'écart maximal, exprimé en points, accepté par rapport au prix envoyé. Si cette valeur est réglée entre 0 et quelques points, même une variation de tick tout à fait normale déclenche un refus. Une confusion classique consiste à croire qu'il s'agit de pips alors qu'il s'agit de points (pour un broker à 5 chiffres, 1 pip = 10 points).

Solutions :

1. Commencer avec un deviation de 10 à 30 points (soit 1 à 3 pips) et observer. Hors scalping, 20 points constitue un point de départ raisonnable
2. Vérifier l'absence d'erreur d'unité (par exemple deviation=5 pensé comme 0,5 pip)
3. Pour une stratégie refusant tout slippage, considérer les refus comme normaux et se contenter de contrôler le nombre de tentatives

③ Différence de mode d'exécution (le requote est propre à l'exécution instant)

Symptôme : le phénomène est fréquent chez le broker A mais ne se produit jamais chez le broker B.

Cause : le requote (10004) est un phénomène spécifique à l'exécution instant (instant execution). Ce mode signifie « exécute-moi à ce prix précis » : si le prix bouge, le serveur propose un nouveau prix (requote). À l'inverse, l'exécution market (market execution) signifie « exécute-moi au prix actuel du marché » : le requote ne peut, par principe, pas se produire, et l'ordre est exécuté directement au prix décalé (slippage).

Autrement dit, « pas de requote » ne signifie pas « meilleur broker » : il s'agit d'un compromis entre refus et exécution avec glissement. Le mode d'exécution d'un symbole se vérifie dans les « spécifications du symbole » (onglet Execution) sous MT5, ou par code via SYMBOL_TRADE_EXEMODE.

Solutions :

1. Vérifier le mode d'exécution de son propre compte (de nombreux comptes standards chez les brokers offshore utilisent l'exécution market, où le requote n'apparaît jamais)
2. Si les requotes fréquents nuisent à la stratégie, envisager un type de compte ou un broker en exécution market
3. Certains brokers en exécution market respectent le deviation, d'autres non ; si un slippage excessif est inacceptable, vérifier le slippage réel dans l'historique des transactions

④ Plage horaire ou instrument à cotation clairsemée ou interrompue

Symptôme : l'erreur 10021 apparaît autour de minuit heure serveur (rollover), juste après l'ouverture du lundi, pendant les périodes creuses (Noël, etc.), ou sur des instruments mineurs.

Cause : pendant le rollover, la diffusion des cotations peut être temporairement interrompue ou le spread s'élargir fortement en raison du traitement des swaps. Juste après l'ouverture du lundi ou sur des instruments peu liquides, les cotations exploitables sont tout simplement rares. Passer un ordre dans ces conditions produit l'erreur 10021 (aucune cotation).

Solutions :

1. Éviter les nouvelles entrées entre 23h55 et 0h05 environ, heure serveur (filtre horaire)
2. Éviter les premières minutes suivant l'ouverture du lundi (réglage de type AvoidMondayOpen)
3. Mettre en place un filtre de spread (MaxSpread) : le spread s'élargissant lors des plages à faible cotation, ce filtre permet d'éviter automatiquement ces créneaux

⑤ Latence réseau (VPS trop éloigné du serveur du broker)

Symptôme : fréquence nettement supérieure à celle d'autres environnements, indépendamment de l'horaire ou de l'instrument. Ping élevé.

Cause : plus le temps d'aller-retour (latence) jusqu'au serveur est long, plus la probabilité que le prix ait bougé entre-temps augmente. Faire tourner l'EA sur un PC personnel ou sur un VPS situé dans une région éloignée du serveur du broker (souvent à Londres ou New York) accroît structurellement la fréquence des erreurs 10004/10021. Le ping affiché en bas à droite de MT5 constitue un bon indicateur (plusieurs centaines de ms sont clairement défavorables, quelques dizaines de ms ou moins sont préférables).

Solutions :

1. Vérifier la valeur du ping en bas à droite de MT5 ; si elle est constamment élevée, revoir l'environnement d'exécution de l'EA
2. Migrer vers un VPS situé près du serveur du broker. En toute franchise, la part des erreurs 10004/10021 due à la latence ne peut pas être réduite par du code : seul le rapprochement physique fonctionne. Voir le guide de choix d'un VPS pour EA pour la méthode de sélection
3. L'impact de la latence est plus marqué pour les EA de scalping. Pour un EA sur unités de temps journalières ou H4, cette cause est de priorité moindre

Code MQL5 pour réduire cette erreur (pour les développeurs d'EA)

Trois axes : (1) régler deviation à une valeur réaliste, (2) en cas de refus, récupérer le dernier tick et renvoyer l'ordre, (3) limiter les nouvelles tentatives aux seuls retcodes liés au prix.

Régler deviation correctement, en unités de points

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
req.action    = TRADE_ACTION_DEAL;
req.symbol    = _Symbol;
req.type      = ORDER_TYPE_BUY;
req.volume    = lots;
req.deviation = 20;   // Slippage toléré de 20 points (2,0 pips pour un broker 5 chiffres)
// Définir également req.price / req.sl / req.tp / req.magic, etc.

L'unité de deviation est le point. Chez un broker affichant 5 (ou 3) décimales, 10 points = 1 pip. Une valeur nulle ou trop faible augmente inutilement le taux de refus.

Ne relancer que les retcodes liés au prix (en renvoyant l'ordre avec le dernier tick)

Le point essentiel est de récupérer un nouveau prix via SymbolInfoTick() à chaque tentative (renvoyer l'ordre avec l'ancien prix ne ferait que provoquer le même refus), et de limiter les nouvelles tentatives aux codes 10004/10021. Relancer automatiquement en cas de fonds insuffisants (10019) ou de requête invalide (10013) n'a aucun sens et ne fait qu'encombrer le journal.

bool IsRetryableRetcode(uint rc)
{
   return (rc == TRADE_RETCODE_REQUOTE       // 10004
        || rc == TRADE_RETCODE_PRICE_OFF);   // 10021
}

// Renvoie l'ordre jusqu'à 3 fois en actualisant le prix avec le dernier tick
bool SendWithRetry(MqlTradeRequest &req, MqlTradeResult &res, int maxTries = 3)
{
   for(int attempt = 0; attempt < maxTries; attempt++)
   {
      MqlTick tick;
      if(!SymbolInfoTick(req.symbol, tick))
      {
         Print("SymbolInfoTick failed: ", GetLastError());
         return false;
      }
      req.price = (req.type == ORDER_TYPE_BUY) ? tick.ask : tick.bid;

      if(OrderSend(req, res) && res.retcode == TRADE_RETCODE_DONE)
         return true;                          // Exécution réussie

      if(!IsRetryableRetcode(res.retcode))
      {
         PrintFormat("OrderSend failed (no retry): retcode=%d", res.retcode);
         return false;                         // Ne pas relancer pour les autres codes
      }
      PrintFormat("Retry %d/%d after retcode=%d", attempt + 1, maxTries, res.retcode);
      Sleep(200 + 150 * attempt);              // Attente progressive : 200ms → 350ms → 500ms
   }
   Print("Order abandoned after retries (price kept moving).");
   return false;
}

Le temps d'attente de Sleep() augmente progressivement car renvoyer l'ordre en boucle à 0ms lors d'un mouvement brutal ne ferait qu'accumuler les mêmes refus. À l'inverse, attendre trop longtemps éloigne le prix d'entrée de l'hypothèse initiale de la stratégie : il est sain d'abandonner après 2 à 3 tentatives. Pour un ordre en attente (TRADE_ACTION_PENDING), notez que le retcode de succès est TRADE_RETCODE_PLACED (10008).

Utiliser le prix reproposé lors d'un requote (10004)

Lors d'un 10004, les champs bid / ask de MqlTradeResult contiennent le nouveau prix proposé par le serveur. Renvoyer l'ordre avec le dernier tick, comme ci-dessus, suffit dans la plupart des cas ; mais si vous souhaitez construire, en exécution instant, une logique du type « accepter le nouveau prix s'il reste dans une plage tolérable », il faudra comparer, en points, l'écart entre res.ask / res.bid et le prix initialement visé avant de renvoyer l'ordre.

Créer des plages horaires où l'on s'abstient de passer un ordre

La nouvelle tentative en code reste un traitement symptomatique. Un filtre bloquant les nouvelles entrées autour du rollover, des annonces, ou lors de l'élargissement du spread agit de façon plus fondamentale.

// Exemple de filtre de spread : renoncer aux nouvelles entrées si le spread est trop large
long spreadPts = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spreadPts > MaxSpreadPoints)
{
   // Renoncer à la nouvelle entrée (évite automatiquement les plages clairsemées propices au 10021)
   return;
}

Les EA distribués par FXEA365 intègrent en standard le filtre de spread, le filtre d'actualités, et la nouvelle tentative automatique limitée aux retcodes liés au prix.

Check-list par ordre de priorité

Résumé

• 10021 (TRADE_RETCODE_PRICE_OFF) signifie « aucune cotation exploitable », 10004 (TRADE_RETCODE_REQUOTE) signifie « nouvelle proposition de prix ». Elles appartiennent à la même famille de refus liés au prix que les erreurs 136/138 de l'ère MT4, et ne concernent ni les fonds ni la taille de lot.
• Les causes se ramènent à cinq facteurs : mouvement brutal du marché, deviation trop faible, exécution instant, plage horaire/instrument à cotation clairsemée, latence réseau.
• Le requote est un phénomène propre à l'exécution instant ; en exécution market, il se manifeste à la place par du slippage. « Pas de requote » n'est pas synonyme de « meilleur broker », c'est un compromis.
• Les développeurs d'EA doivent mettre en place des solutions durables : 2 à 3 nouvelles tentatives avec récupération du dernier tick (limitées aux codes 10004/10021), réglage adéquat du deviation, et filtres horaires/de spread. Seule la part liée à la latence ne peut être réduite que par une solution physique (VPS proche du broker).

Pour l'ensemble des codes d'erreur, consultez le guide complet des codes d'erreur MQL5 / MT5 ; pour des EA gratuits intégrant ces protections en standard, voir le classement des EA.

FAQ

Q : 10004 et 10021, laquelle est la plus grave ?

Les deux sont des erreurs temporaires liées au prix, sans différence notable de gravité. 10004 signifie « un nouveau prix a été proposé », 10021 signifie « aucune cotation exploitable n'était disponible ». En cas d'occurrence isolée, il n'y a pas lieu de s'inquiéter ; ce n'est que si l'erreur se répète fréquemment sur une plage horaire ou un instrument donné qu'il faut en traiter la cause (annonce, rollover, deviation, connexion).

Q : Un broker chez qui le requote n'apparaît jamais est-il meilleur ?

Il s'agit probablement d'une simple différence de mode d'exécution. Sur un compte en exécution market, le requote ne peut, par principe, pas se produire : si le prix a bougé, l'ordre est directement exécuté au prix décalé (slippage). C'est un compromis entre refus et glissement ; il convient de vérifier le slippage réel dans l'historique des transactions avant de trancher.

Q : Mon EA sous MT4 affiche error 136 / 138. Le même traitement s'applique-t-il ?

Oui. 136 (ERR_OFF_QUOTES) correspond à 10021, et 138 (ERR_REQUOTE) à 10004 ; causes et solutions sont communes. Sous MQL4, la pratique classique consistait à appeler RefreshRates() avant de renvoyer l'ordre afin d'actualiser Bid / Ask, ce qui correspond exactement à la récupération via SymbolInfoTick() sous MQL5.

Q : L'erreur n'apparaît pas en backtest mais survient en réel.

C'est normal. Le Strategy Tester ne reproduit pas (ou simplifie) « le délai avant que l'ordre n'atteigne le serveur » et « la variation de prix pendant ce délai » : les erreurs 10004/10021 ne se manifestent donc qu'en conditions réelles (forward). Un bon résultat en backtest ne dispense pas de régler séparément le deviation, la logique de nouvelle tentative, et l'environnement d'exécution (VPS) pour le trading en réel.