Trading · Module avancé · Guide 09/10
Du backtest à la démonstration Forex : contrôler les écarts
Observer une version figée sur des données nouvelles et rapprocher signal, ordre et exécution. La démonstration est un exercice de contrôle, pas un certificat de passage en réel.
← Retrouver le parcours du module avancé
Préciser ce que l’on veut observer
Un compte de démonstration utilise un capital fictif. Selon le service, les prix peuvent être en temps réel tandis que les remplissages restent simulés. Vérifiez les conditions au lieu de supposer que tout correspond à un compte réel.
Avant l’exercice, conservez les règles, paramètres et données du backtest de référence. N’introduisez pas discrètement un filtre, une autre heure de clôture ou une quantité différente. Le suivi doit préciser sa fréquence de revue et les motifs de suspension.
La question initiale peut être : la version produit-elle les signaux prévus avec les informations disponibles ? Ce contrôle est distinct d’une estimation de rentabilité future.
Geler le dossier de départ
Version
Règles, paramètres et contrat d’instrument.
Hypothèses
Prix, coûts, délais et taille.
Contrôles
Journal, rapprochement et procédure d’incident.
Rapprocher des événements comparables
Pour chaque événement, liez un identifiant de signal aux demandes d’ordre et à leurs exécutions. Certaines demandes peuvent ne pas être remplies ; certaines exécutions peuvent être partielles. Leur absence du résultat ne doit pas disparaître du journal.
Comparez d’abord le signal et les données, puis les prix et quantités. Une différence de clôture entre flux peut expliquer un signal manquant. Un signal correct avec un ordre refusé relève d’une autre question.
| Étape | Prévu | Observé fictif |
|---|---|---|
| Signal | Clôture répondant à la règle | Même événement identifié |
| Entrée ask | 1,1002 dans le modèle | 1,1005 simulé |
| Quantité | 10 000 EUR | 10 000 EUR |
| Sortie bid | 1,1020 | 1,1020 |
| Commission aller-retour | 1 USD | 1 USD |
Chiffrer un écart avant de l’expliquer
Dans l’exemple, le résultat prévu vaut 10 000 × (1,1020 − 1,1002) − 1 = 17 USD. Le résultat observé fictif vaut 10 000 × (1,1020 − 1,1005) − 1 = 14 USD. La différence est −3 USD.
Ce calcul isole l’écart d’entrée dans des hypothèses simplifiées. Il ne prouve pas que la latence en est la cause. Les horodatages, les côtés de cotation, l’ordre et le moteur de remplissage doivent être examinés.
Le spread est ici inclus dans les côtés de prix. Les autres frais éventuels doivent être traités de manière cohérente. Une différence de devise de compte demanderait une conversion documentée.
Prévoir une suspension et un redémarrage
Une donnée absente, une discordance de position ou une impossibilité d’annuler un ordre peut nécessiter une suspension selon le protocole. Arrêter les nouvelles entrées ne supprime pas les positions ouvertes ; leur gestion doit être prévue séparément.
Conservez un état de référence, les identifiants et les réponses de la plateforme. Un redémarrage ne doit pas réémettre un ordre déjà accepté simplement parce que son statut local est inconnu. La réconciliation sert d’abord à établir l’état réellement enregistré.
Après un incident
Établir
État du compte, positions et ordres.
Rapprocher
Journal local et réponses de la plateforme.
Reprendre
Seulement selon la procédure définie, avec la version identifiée.
Faire une revue sans modifier en continu
Regroupez les écarts par type : données, règles, coûts, exécution et intervention humaine. Les séries courtes et les résultats extrêmes doivent rester visibles. Un cumul favorable ne compense pas automatiquement une anomalie opérationnelle non comprise.
Une correction de bug doit être distinguée d’un changement de stratégie. Les deux nécessitent une trace et peuvent imposer de refaire des vérifications. Ne mélangez pas leurs observations sous une même version présentée comme inchangée.
Aucun nombre de jours ni résultat de démonstration ne constitue ici une autorisation automatique d’engager du capital. Le suivi ne reproduit pas entièrement la liquidité, les contraintes du compte ni les réactions personnelles aux pertes.
Exercice corrigé : vérifier la distinction
Après une interruption, le journal local ne sait pas si un ordre a été accepté. Faut-il l’envoyer à nouveau pour être certain de ne pas manquer le signal ?
Correction : il faut d’abord rapprocher l’état des ordres et positions avec celui de la plateforme. Réémettre sans vérifier peut créer un doublon et augmenter l’exposition.
La procédure d’incident doit définir les identifiants, les informations à consulter et les conditions de reprise. Cet exercice porte sur la cohérence opérationnelle, pas sur la possibilité de garantir un rattrapage du prix envisagé.
Questions fréquentes
La démonstration est-elle un test réel ?
C’est une observation sur un environnement défini, avec capital fictif et parfois données réelles. L’exécution peut rester différente du réel.
Un écart de prix indique-t-il un bug ?
Pas nécessairement. Il faut d’abord vérifier les prix comparés, les instants, les côtés bid/ask et le modèle.
Peut-on corriger les paramètres chaque jour ?
On peut créer de nouvelles versions, mais cela empêche de présenter la période comme l’observation continue d’une version figée.
Sources et prolongements
- QuantConnect : démonstration avec capital fictif
- QuantConnect : rapprochement entre environnements
- BRI : risque d’exécution
Ces ressources documentent les concepts ou leurs limites. Leur présence ne constitue pas une recommandation de leurs services commerciaux.