Scalping Forex par ordres à cours limité : premier retour, délai et exécution pendant l’annulation

1. Définir une hypothèse complète de premier retour

Cette stratégie étudie le premier retour après un petit range achevé et sa cassure immédiate. La question centrale est celle de l’exécution : l’ordre en attente a-t-il été accepté, exécuté, expiré ou annulé ? La séquence diffère d’une entrée au marché après deux vagues de repli ou une fausse cassure. Elle n’utilise ni EMA, RSI, SAR, ADX, ATR, ni sommet ou creux confirmé par des bougies futures.

Il s’agit d’une spécification pédagogique reproductible, pas d’un EA installable ou d’un système validé en réel. Nombre de bougies, distances et durées sont des hypothèses déclarées. Toutes les cotations appariées et tous les rapports sont inventés. Une intention d’attente limitée ne garantit pas que le compte soit effectivement sans exposition à cet instant précis.

2. Fixer contrat, horloge UTC et blocage du compte

Utiliser les OHLC Bid clôturés d’EURUSD M1 avec pip=0.0001; point=tick=0.00001; contract=EUR100,000/lot; pip_value=$10/lot sur un compte en USD. Ouvertures et clôtures de toutes les bougies de formation, ainsi que le placement, doivent respecter 09:00<=UTC<12:00. Avant toute recherche, vérifier l’absence de position, d’ordre en attente, d’autre exposition ou de demande non résolue sur l’ensemble du compte. Contrat, marge et prise en charge de la protection initiale jointe et de l’expiration serveur doivent être connus.

Vérifier la conversion entre UTC et l’heure du serveur, y compris ses changements de décalage. Les cas supposent explicitement server_UTC_offset=0; known_event_list=[]. Une liste d’événements connue à l’avance bloque le placement pendant [event−15 min,event+15 min] ; cet intervalle est une politique de recherche supposée. Horloge, calendrier ou données inconnus empêchent un nouvel ordre. Un ordre en attente existant ou une réponse non résolue maintient le blocage du compte.

3. Figer le premier range indépendant de cinq bougies

Après une libération vérifiée, prendre les cinq premiers intervalles M1 consécutifs réellement achevés dont l’ouverture est égale ou postérieure à cette libération. Figer H=max(High1..High5); L=min(Low1..Low5); 6<=(H−L)/pip<=10. Consommer le bloc avant de tester sa largeur. Ne pas décaler un bloc déjà consommé pour obtenir un meilleur range ; intervalle absent ou bloc invalide imposent un nouveau départ après observation de l’échec.

La sixième bougie est le seul emplacement de cassure B. Le range principal est 09:00–09:05 UTC; H=1.20080; L=1.20000; width=8 pip. Ses extrêmes sont déjà connus, sans choix rétrospectif de pivots. Un changement de minute ne suffit pas à prouver la clôture : vérifier l’intervalle à réception des données de la bougie suivante. Après rejet, sortie vérifiée, fin d’une suspension ou rétablissement des données, effacer l’ancien range et exiger des ouvertures entièrement nouvelles.

4. N’accepter que la clôture de cassure immédiatement suivante

Pour BUY, exiger Close(B)>Open(B); 0.5<=(Close(B)−H)/pip<=4.0. Le miroir SELL exige Close(B)<Open(B); 0.5<=(L−Close(B))/pip<=4.0. B est exactement l’intervalle suivant ; ne pas attendre une clôture ultérieure. Égalité sur la borne, doji, corps contraire ou distance excessive consomment le cycle sans ordre.

Le BUY principal présente B=k5; close_time=09:06 UTC; Close=1.20110; distance=3.0 pip. Un autre cas clôture à 1.20080=H et échoue. La bougie suivante clôture à 1.20110, mais ne peut remplacer B. Un range véritablement nouveau pourra créer un autre cycle ; il ne sauve pas rétroactivement le précédent.

5. Fixer prix d’attente et protections

À la clôture B admissible, choisir P_buy=H+0.1 pip; P_sell=L−0.1 pip. BUY fige S_bid=P_buy−3.5 pip; T_bid=P_buy+8.0 pip ; SELL fige S_ask=P_sell+3.5 pip; T_ask=P_sell−8.0 pip. Tous les prix doivent respecter le tick déclaré. Les décalages sont des hypothèses explicites du modèle, pas des distances optimisées ni des bougies Ask historiques reconstituées.

Le BUY principal utilise P=1.20081; S_bid=1.20046; T_bid=1.20161 et SELL P=1.19919; S_ask=1.19954; T_ask=1.19839. Conserver ces niveaux absolus après placement ou exécution. Aucun suivi de stop, passage au prix d’entrée, renforcement à la baisse, sortie partielle, position opposée ou remplacement par un ordre au marché n’est prévu. Si le courtier ne permet pas les deux sorties initiales et l’expiration exigée, ignorer cet événement.

6. Consommer une seule première cotation après B

Examiner uniquement le premier couple reçu après la clôture programmée de B, en vérifiant aussi sa clôture effective. Exiger arrival<=B_close+1.000 s; 0<=quote_age<=250 ms; 0<=spread<=0.6 pip. Les prix doivent être positifs, non croisés et alignés au tick. Exiger Ask>P_buy for BUY; Bid<P_sell for SELL : le premier retour du bon côté ne doit pas avoir déjà eu lieu. Revérifier fenêtre UTC, compte libre, contexte, distances actuelles du courtier, volume, marge disponible, conversion horaire et compatibilité des protections et de l’expiration.

Le couple principal est 09:06:00.100 quote; 09:06:00.120 arrival; Bid/Ask=1.20110/1.20116. Si tous les contrôles passent, autoriser une seule demande de placement avec niveaux et expiration figés. Un premier couple mauvais, ancien ou hors délai consomme l’autorisation ; aucun couple ultérieur ne le remplace. Un stop level local nul ne promet pas l’acceptation. Le paramètre de glissement du terminal ne garantit pas le prix d’exécution d’un ordre en attente.

7. Conserver le miroir SELL et le bon côté de prix

SELL fixe la borne basse, exige la clôture baissière immédiatement suivante au-dessous et place Sell Limit sous cette borne tant que Bid reste sous P. Son premier retour pertinent est Bid>=P_sell ; BUY utilise Ask<=P_buy. Après confirmation d’une exécution, les sorties BUY sont testées sur Bid et les sorties SELL sur Ask. Les seuls OHLC Bid ne révèlent ni anciens contacts Ask ni priorité d’exécution.

L’exemple SELL est exécuté à 1.19919. Plus tard, le couple Bid/Ask=1.19948/1.19954 atteint le stop Ask alors que Bid reste inférieur. La sortie moins favorable fournie est Ask=1.19964; net=−$28.56 et dépasse le budget prévu. Le résultat monétaire illustré dépend du rapport, pas d’un cours commode du graphique. Des seuils Ask choisis selon la géométrie Bid ne constituent pas des OHLC Ask historiques.

8. Séparer expiration de l’attente et compte libre confirmé

La limite de l’ordre en attente est D_wait=min(B_close+120 s,12:00 UTC). Demander cette expiration serveur explicite avec la conversion UTC vérifiée et la contrôler dans l’acceptation. Retirer également l’intention d’attente à D_wait par un minuteur connecté et calibré. Un délai atteint ou une demande de suppression ne prouvent pas l’absence d’exécution juste avant. Rapprocher ticket, positions et historique avant de lever le blocage.

Dans le cycle principal, B_close=09:06; D_wait=09:08 UTC. Le cas de retour tardif fournit server_expired=09:08:00.000; verified_flat_observed=09:08:00.060 ; le premier retour Ask se produit à 09:08:00.100. Aucun remplacement n’est autorisé. Une expiration inconnue ou non prise en charge bloque le placement. Une réponse définitive de refus d’expiration error=147 termine le cycle ; ne jamais supprimer l’expiration pour retenter le même événement.

9. Dimensionner selon le potentiel net, avec P comme prix prévu

Le plan utilise P, pas une exécution déduite d’un contact. Avec c=0.3 exit reserve+0.6 linear round-trip commission=0.9 pip, BUY a L=(P−S_bid)/pip+c; W=(T_bid−P)/pip−c et SELL L=(S_ask−P)/pip+c; W=(P−T_ask)/pip−c. L et W doivent être positifs et respecter W/L>=1.50. Les bons côtés d’entrée et de sortie intègrent déjà le spread ; ne pas le compter deux fois. Aucun financement ni autre frais n’est supposé.

Utiliser equity=$10,000; risk_fraction=0.25%; budget=$25; lot_min=lot_step=0.01; lot_max=1.00 et lots=floor_step(25/(L×10),0.01). Le plan principal donne L=4.4; W=7.1; W/L=1.6136364; lots=0.56; planned_loss=$24.64; planned_net_target=$39.76. Rejeter un volume incompatible ou une marge indisponible. P est une hypothèse de planification, pas une promesse d’exécution. Réduire le volume ne corrige pas un ratio net linéaire insuffisant. Sauts de prix ou autres conditions d’exécution peuvent dépasser le budget prévu.

10. Distinguer contact Bid, bon retour et exécution

Pour BUY, le couple 09:06:30.000; Bid/Ask=1.20081/1.20087 touche P sur Bid seulement. Le vrai retour Ask est 09:06:40.000; Bid/Ask=1.20075/1.20081. Il s’agit de deux observations appariées distinctes. Dans le cas principal, l’exécution fournie à P est connue à 09:06:40.010, avant réception de la cotation de retour à 09:06:40.020 ; la position exécutée est donc gérée sans demande de suppression.

Rapprocher les rapports disponibles avant chaque action. Si le premier contact du bon côté arrive alors que le dernier état vérifié reste en attente, retirer l’événement et demander une seule annulation ; ne pas attendre un deuxième contact. Le cas non exécuté demande la suppression à 09:06:40.020 et fournit annulation confirmée et compte libre à 09:06:40.080. Si le retour précède l’accusé de placement, noter l’intention de retrait puis rapprocher les états ; ne demander l’annulation qu’une fois un ticket en attente connu. Une exécution confirmée après retrait nécessite la règle d’urgence.

11. Annuler une seule fois une idée en attente invalidée

Tant que l’ordre est vérifié en attente, retirer l’intention à l’expiration, en cas de données ou calendrier indisponibles, de suspension pour nouvelles, de couple invalide ou de spread>0.8 pip. La retirer aussi si le côté de sortie atteint l’objectif avant exécution ou si une bougie M1 effectivement clôturée et observée revient dans le range : Close<=H for BUY; Close>=L for SELL. Ce sont des politiques déclarées, pas la garantie que la demande devancera la prochaine exécution serveur.

Le cas d’invalidation présente k6 Close=1.20078<H=1.20080, observé après le début de l’intervalle suivant. L’annulation est demandée à 09:07:00.120 et le compte libre confirmé à 09:07:00.180. Le retour valide ultérieur à 09:07:20.000 ne crée aucun nouvel ordre. Envoyer au plus une demande d’annulation par ticket connu. Refus, restriction de gel, déconnexion ou timeout maintiennent le blocage ; rapprocher les états au lieu de supprimer à répétition, remplacer ou élargir les niveaux.

12. Gérer une exécution qui survient pendant l’annulation

Dans ce cas, une cotation à spread large entraîne la demande de suppression à 09:06:30.020. Le serveur exécute ensuite à 09:06:30.030; P=1.20081, connu à 09:06:30.040. La tentative d’annulation n’a pas supprimé cette position. Le refus de suppression est observé à 09:06:30.080. Les restrictions de gel et les délais des messages peuvent empêcher l’annulation prévue ; seul le rapport fourni établit ici l’état.

Une exécution confirmée après l’intention de retrait conserve sa protection jointe et autorise une unique fermeture d’urgence sur la première cotation fiable du bon côté après confirmation. La demande est ici 09:06:30.050 et la sortie fournie Bid=1.20074; net=−$7.28. Garder le blocage jusqu’à vérification de la clôture ; une réponse incertaine reste non résolue. Une protection initiale manquante de façon imprévue impose la même procédure. Ne jamais déplacer les niveaux pour forcer l’acceptation ni traiter l’intention d’annuler comme une opération de résultat nul.

13. Gérer une position normalement exécutée jusqu’à la limite fixe

Après acceptation et exécution normale du premier retour, conserver la protection initiale et utiliser D_position=min(B_close+10 min,12:00 UTC). L’ancrage est B, pas une exécution plus tardive ni la fin de l’attente. Sans sortie protectrice préalable, envoyer une seule demande de fermeture sur la première cotation disponible et fiable du bon côté à partir de cette limite. La protection a priorité sur une même cotation et reste active pendant l’attente de la réponse de fermeture.

Le cas de sortie temporelle utilise D_position=09:16 UTC; first_quote=09:16:00.100; arrival=09:16:00.120. Sa sortie BUY fournie est Bid=1.20076; net=−$6.16. L’absence de cotation au délai ne signifie pas que le compte est libre ; une ancienne cotation n’est pas une exécution fictive à la borne. Vérifier l’état réel après clôture. Un timeout de fermeture n’autorise ni autre position ni deuxième demande fondée seulement sur une supposition.

14. Laisser les réponses inconnues non résolues et repartir de bougies nouvelles

Distinguer placement_permission=B_close+1 s; pending_expiry=B_close+120 s; ack_timeout=request_time+2 s. Sans réponse au placement, acceptation et exécution restent inconnues. Sans réponse à l’annulation, le statut en attente ou exécuté demeure non résolu. Un prix de référence atteignant ensuite l’objectif ne prouve ni exécution ni bénéfice. Laisser entrée exécutée, sortie et P&L vides jusqu’à obtention de preuves faisant autorité ; ne jamais retenter le même événement.

Après refus définitif ou compte libre confirmé, effacer l’ancien scénario. Dans le redémarrage indépendant, l’échec B est observé à 09:06:00.120 ; seules les nouvelles ouvertures à partir de 09:07 forment les cinq bougies suivantes. Son propre B=k12; close=09:13; P=1.20131; S_bid=1.20096; T_bid=1.20211 produit une demande, définitivement refusée avec error=130. L’ancien B échoué et sa bougie ultérieure séduisante restent rejetés. Le seul passage du temps ne libère pas une recherche si l’état du compte est incertain.

15. Reproduire les observations et résultats fictifs

Les téléchargements contiennent 14 independent cases; 24 closed bars/case; 336 Bid bars; 15 declared formation windows; 1,375 paired quotes; 1,419 ledger rows. Chaque cas observe un cycle déclaré, sauf le redémarrage qui en comporte deux. Les cotations ultérieures décrivent son contexte et non une nouvelle recherche exhaustive. Le registre sépare 12 simulated placements; 4 cancel requests; 2 close requests; 4 supplied fills; 0 live orders. Heure de cotation et heure de réception sont distinctes ; une cotation de la bougie suivante en formation confirme le dernier intervalle fermé sans inventer une autre bougie clôturée.

Le flux inventé reste constant entre les mises à jour indiquées. Ses paires reproduisent les OHLC Bid exportés ; elles ne reconstituent ni Ask historique, ni file d’attente, ni priorité. Après la commission annoncée, les résultats fermés fournis sont target +$41.44; gap stop −$28.56; time exit −$6.16; cancellation race −$7.28. Cas sans exécution et cas non résolus gardent des résultats d’exécution vides. Recalculer fenêtres complètes, premiers contacts pertinents, transitions rapportées, volume et montants ; ces quatre clôtures ne sont pas des statistiques de performance.

Télécharger les observations Bid M1 fictives (CSV)

Télécharger les fenêtres déclarées et résultats (CSV)

Télécharger cotations appariées, demandes et rapports (CSV)

16. Tester tout le protocole sur des données chronologiques inédites

Figer range, emplacement de cassure, côtés de cotation, coûts, délais et annulation avant la recherche. Conserver toutes les fenêtres admissibles et les premiers couples rejetés, pas uniquement les exécutions. Des paires fiables permettent de distinguer contact Bid seul et retour Ask. Mesurer les résultats nécessite de vraies preuves d’acceptation, rejet, annulation et exécution ; les OHLC seuls ne fournissent pas de modèle d’exécution des ordres en attente.

Évaluer nouvelles, changements de spread, cotations manquantes, expiration serveur, gels, réponses retardées et exécutions pendant la suppression sous les mêmes hypothèses de compte. Documenter toute modification du calendrier admissible lorsqu’une règle change. Utiliser des périodes chronologiques inédites et des conditions de courtier réalistes. L’objectif est une hypothèse bornée et testable ; la mécanique fictive ne démontre ni avantage ni aptitude au réel.

Questions fréquentes

Sources et notes de recherche

Les références officielles décrivent les côtés de cotation, l’expiration, la suppression d’ordres en attente et les contraintes du courtier. Range, seuils, délais et rapports fictifs sont des hypothèses pédagogiques. Ils ne prouvent ni réglages optimaux, ni exécution historique, ni rentabilité. Cette spécification n’appelle aucune API de trading.

• MetaTrader4: order types and Bid/Ask triggers
• MQL4: OrderSend and pending expiry restrictions
• MQL4: OrderDelete
• MQL4: broker contract, stop and freeze properties

Spécification pédagogique d’ordres limites. Cotations appariées et rapports fictifs ; aucun ordre réel, backtest historique ou résultat de rentabilité mesuré.