XAUXXCarnet de recherche
← Retour au carnet

Courbe de backtest EA flatteuse : vérifiez d'abord ces conditions de test

Distinguez les modes de modélisation des données tick par tick réelles, consignez les hypothèses de spread, la sélection des paramètres et la plage de contrôle indépendante, afin que les conclusions des tests d'EA puissent être vérifiées.

Thomas · Mis à jour 2026-10-06

Auteur : Thomas | EA et pratiques de plateforme | 6 octobre 2026

Une courbe de backtest ascendante ne dit pas dans quelles conditions le programme a été exécuté, et ne représente pas directement non plus la performance en réel. Lorsque l'on compare des EA sur l'or, il est plus utile de vérifier d'abord les conditions de test, puis de lire les résultats, que de choisir uniquement le rapport avec le profit net le plus élevé. Cet article traite du testeur MT4 standard et ne confond pas ses fonctions avec celles de MT5 ou d'outils de test tiers.

Consignez d'abord un enregistrement de test vérifiable

Avant d'exécuter un test, conservez la version de l'EA, le fichier de paramètres, le nom complet de l'instrument, la période du graphique, la plage de dates, le capital initial et sa devise, ainsi que la source des données et la version du terminal. À chaque modification de paramètres ou de conditions, notez la raison, et ne conservez pas uniquement la meilleure occurrence après avoir vu les résultats.

Ces enregistrements n'ont pas pour but d'augmenter le nombre de pages du rapport, mais de permettre à d'autres personnes de savoir ce qui a réellement été comparé dans le test. Même si deux courbes se ressemblent, si les conditions contractuelles, les quantités ou les conventions de capital diffèrent, elles peuvent ne pas être directement comparables. Les conditions manquantes dans un rapport doivent être indiquées comme inconnues et ne doivent pas être complétées par supposition.

Le mode de modélisation doit correspondre à la logique du programme

L'aide officielle de MT4 répertorie différents modes de modélisation de l'historique. Un test uniquement sur les prix d'ouverture et un programme qui dépend des variations de prix à l'intérieur des barres peuvent ne pas refléter le même processus de déclenchement. Lors du choix du mode, il convient d'abord de déterminer si l'EA évalue après la formation d'une bougie complète, ou s'il dépend des prix, des sorties et des variations d'ordres à l'intérieur d'une même bougie.

Le mode Every tick mentionné dans la documentation officielle utilise lui aussi des données de périodes plus courtes et une interpolation pour générer des variations de prix ; il n'équivaut pas automatiquement à un historique complet et réel des transactions tick par tick. Le simple fait de voir la mention « chaque tick » ne permet pas de conclure que tous les détails du marché ont été reproduits. Si des données ou des outils tiers sont utilisés, leur source et leur méthode doivent être précisées séparément.

L'hypothèse de spread n'équivaut pas à l'environnement de transaction historique

Selon l'aide officielle de MT4, le testeur standard utilise par défaut le spread courant de l'instrument au début du test pour simuler l'Ask, et il est également possible de définir une valeur personnalisée dans le champ Spread. Cela signifie que l'hypothèse de spread du test doit être consignée explicitement ; une hypothèse fixe ne doit pas être prise pour le spread flottant réel sur toute la période historique.

Les conditions d'exécution lors de publications de données, de variations de liquidité ou de périodes anormales ne sont pas nécessairement reflétées de manière adéquate par un ensemble de réglages fixes. Les commissions, frais overnight et autres effets d'exécution doivent aussi être vérifiés dans le rapport et l'outil concernés : sont-ils pris en compte, et selon quelles conventions ? Les éléments non simulés doivent être clairement indiqués ; il ne faut pas remplacer ces vérifications par « le backtest a réussi ».

Les résultats d'optimisation ne sont qu'un classement dans des conditions données

Les résultats d'optimisation MT4 peuvent afficher des statistiques telles que le profit, le nombre de transactions, le drawdown et le profit attendu pour différentes combinaisons de paramètres. Être classé premier signifie que cette combinaison a atteint les indicateurs correspondants dans la plage et les conditions choisies ; cela ne signifie pas qu'elle restera première à l'avenir.

Lors de l'analyse, il ne faut pas seulement regarder la meilleure ligne, mais aussi observer si des résultats totalement différents apparaissent lorsque les paramètres voisins varient légèrement. Si la performance ne se concentre que sur une combinaison très étroite, cela indique que la conclusion peut être sensible aux réglages, mais ce phénomène seul ne permet pas de conclure que le programme est nécessairement inefficace. Il convient de continuer à vérifier la logique, les données et les conditions de test, et de conserver les résultats favorables comme défavorables.

Réservez des données non utilisées pour le réglage des paramètres, puis effectuez la vérification

Il est possible de diviser à l'avance la plage utilisée pour ajuster les paramètres et une plage de vérification indépendante qui ne participe pas à cet ajustement. La méthode de division et les critères d'évaluation doivent être définis avant de voir les résultats de la vérification. Si, après la vérification, la même portion de données est réutilisée à plusieurs reprises pour modifier les paramètres, elle ne constitue plus un test totalement indépendant.

En cas de variation des conditions, conservez la comparaison avant/après

En gardant les autres conditions identiques, modifier une hypothèse précise et comparer les résultats peut aider à identifier la sensibilité du programme aux conditions. Il convient de consigner la modification, sa justification, le résultat du test et les limites non couvertes, plutôt que de se contenter d'une appréciation difficile à vérifier comme « plus stable ».

L'exécution en simulation peut servir à vérifier le déroulement du programme et à consigner l'environnement réel de cotation, mais les exécutions simulées ne sont pas équivalentes au trading réel. Avant toute phase d'exécution, il faut définir clairement la procédure de contrôle en cas d'ordres anormaux, de déconnexion, d'écart de position et d'atteinte d'une limite de perte ; il ne faut pas assouplir les règles temporairement pour prolonger la courbe de backtest.

Finalement, formulez la conclusion sous forme conditionnelle

Un résumé clair doit préciser : avec quelles données, quels paramètres et quelles hypothèses de coûts tel résultat a été observé ; quels risques n'ont pas été couverts ; et ce qui reste à vérifier. Conserver les éléments inconnus aide davantage à la vérification ultérieure que de présenter les résultats de recherche comme une promesse de rendement.

Le trading avec effet de levier peut entraîner des pertes importantes. Cet article a pour objet la présentation des tests d'EA et des méthodes de recherche ; il ne constitue pas un conseil d'achat de programme, de trading ou de position. Les résultats de backtest, de simulation et d'optimisation ne peuvent garantir la sécurité en réel ni les gains futurs.

Avertissement : les opérations avec effet de levier peuvent entraîner des pertes importantes. Ce contenu est destiné à la recherche et à l’éducation, sans garantie de rendement. Les performances passées ne préjugent pas des résultats futurs.