D’où viennent nos cas réels et les chiffres des 110 contacts ?

Nos exemples utilisent des bougies historiques de Binance sur BTC/USDT, ETH/USDT et SOL/USDT. Les chiffres 25 objectifs, 74 invalidations et 11 cas non résolus décrivent les 110 épisodes de contact d’une banque pédagogique sélectionnée, avec un horizon de 72 heures. Ce ne sont ni les résultats de transactions exécutées ni le taux de réussite d’une stratégie.

Cette page est publiée par l’équipe de développement de Price Action Trading Simulator. Les fichiers et règles ont été vérifiés dans notre dépôt le 22 octobre 2026 ; aucune vérification indépendante de performance n’est revendiquée.

Source, périmètre et sélection

L’index public déclare une banque de 220 cas : 110 contacts, 29 approches de zone, 28 ranges étroits et 53 situations de mise à l’écart. Les contacts conservés s’étendent du 19 octobre 2024 à 22 h 45 UTC au 2 octobre 2026 à 18 h 45 UTC. Les autres catégories servent à varier les exercices ; elles ne font pas partie du dénominateur de 110.

Les métadonnées indiquent la révision 2 et la règle fresh-confirmed-source-touch-v1. Le moteur local recherche notamment une zone dont l’origine est déjà confirmée, une première arrivée admissible et l’absence d’une invalidation déjà connue. Il conserve un épisode par origine et sens selon ses critères. Ce filtre algorithmique ne constitue pas un échantillonnage aléatoire de tous les contacts observables sur le marché, et les niveaux ne représentent pas un consensus de traders.

Les cinq exemples du site viennent ensuite d’un tirage fixe CaseDraw.seeded(bank, {}, seed) avec la graine 20261021. Ce tirage utilise les métadonnées des cas et équilibre les types d’exercice ; il n’utilise pas leurs issues pour choisir un exemple favorable. Un tirage indépendant des issues dans une banque sélectionnée ne rend pas la banque représentative du marché.

Définitions des trois issues

Le moteur examine les bougies M15 après la décision, dans l’ordre, sur une fenêtre de 72 heures. Les niveaux de zone, d’invalidation et d’objectif sont ceux du scénario enregistré, pas des ordres soumis à un courtier.

Champ	Règle de classement	Effectif
targetFirst	L’extrême d’une bougie atteint l’objectif avant une invalidation	25
invalidatedFirst	Une clôture dépasse la limite d’invalidation avant l’objectif	74
unresolved	Aucun de ces événements ne résout le scénario dans l’horizon	11

Pour un scénario acheteur, l’invalidation exige une clôture strictement sous la limite ; pour un scénario vendeur, strictement au-dessus. Une mèche suffit à atteindre l’objectif. Si les deux conditions apparaissent dans la même bougie, le moteur donne priorité à l’invalidation : c’est une convention de classement, pas une reconstruction de l’ordre intrabougie.

Les chiffres décrivent cette règle asymétrique. Ils ne comparent pas une entrée au contact à une entrée avec confirmation. Déduire de ces comptes qu’une confirmation améliore le rendement demanderait un autre test, avec règles d’entrée, exécution et coûts définis.

Vérifier le cas SOL

Le fichier complet SOLUSDT-touch-1762793100000 place la décision le 10 novembre 2025 à 16 h 45 UTC. La zone vaut 163,1725–165,6875, la limite 163,1725 et l’objectif 176,5875.

• La bougie M15 ouverte le 11 novembre à 9 h 15 UTC a un plus bas à 163,15, mais clôture à 164,11.
• La première clôture sous la limite est celle de la bougie ouverte à 12 h 30 UTC, close à 12 h 45, à 163,05 : vingt heures après la décision.

Les lignes de bougies sont [heureOuvertureUnixMs, ouverture, plusHaut, plusBas, clôture, volume]. La documentation Binance décrit les données de chandeliers de la source. Un horodatage d’ouverture n’est pas l’instant de connaissance de la clôture. Les données OHLC ne donnent pas une heure précise d’exécution à l’intérieur d’une bougie.

Les séries H1 et H4 exportées peuvent se terminer par une bougie partielle arrêtée à knownAt — ici 12 h 45 UTC — et non par une bougie H1 ou H4 complète : vérifiez la chronologie des événements avec la série M15 et knownAt.

Limites de la publication

Le guide des fichiers et la provenance avec empreintes SHA-256 permettent d’identifier les exports. Seuls les cinq cas du tirage fixe sont publiés avec leurs bougies. L’agrégat des 110 contacts ne peut pas être recalculé indépendamment à partir de ces cinq fichiers. Les empreintes vérifient l’identité des fichiers, pas la validité d’une méthode financière.

Aucune quantité, liquidité, commission ou exécution réelle n’est contenue dans ces observations. Un stop au contact n’équivaut pas à une sortie à la clôture ; attribuer exactement −1R au cas SOL serait injustifié. Les séries or et devises du backtest de l’application constituent un autre périmètre ; en particulier, GC=F est un contrat à terme COMEX affiché sous XAU/USD, pas l’or spot.

Utilisez ces cas pour pratiquer une décision avant la suite. Pour étudier un éventuel avantage, consultez les preuves nécessaires et construisez un protocole distinct.