XAUXXCarnet de recherche
← Retour au carnet

Comment vérifier après l'optimisation d'un EA ? Séparer la sélection des paramètres de la validation hors échantillon

Définir d'abord l'usage des données, puis figer la configuration candidate, exécuter la période réservée et conserver les résultats d'échec, afin d'éviter de présenter un backtest issu d'ajustements répétés comme une validation indépendante.

Thomas · Mis à jour 2026-10-10

Auteur : Thomas|Pratique des EA et des plateformes|10 octobre 2026

Après avoir obtenu un bel ensemble de paramètres par optimisation d'un EA, l'étape suivante ne devrait pas se limiter à choisir la capture d'écran du rendement le plus élevé. La question plus utile est : que donnent les résultats sur une autre période de données n'ayant pas participé à la sélection ? Cet article présente un processus de consignation pour la sélection des paramètres et la validation hors échantillon ; il ne présente pas de résultats de test fictifs et ne considère pas les résultats historiques comme une garantie de gains futurs.

Préciser d'abord que test et optimisation ne sont pas la même chose

La documentation officielle de MT4 indique qu'un test unique utilise la valeur Value des paramètres d'entrée, tandis que Start, Step et Stop servent à l'optimisation des paramètres. Modifier les réglages d'optimisation ne revient pas à modifier toutes les conditions d'un test à paramètres fixes. Lors de la conservation des enregistrements, il convient d'indiquer clairement s'il s'agit de l'exécution d'une configuration fixe ou d'une recherche de plusieurs combinaisons.

Le fait qu'un logiciel propose une fonction d'optimisation ne signifie pas que la valeur maximale sélectionnée possède une capacité de prédiction future. Le résultat final dépend aussi des données, des hypothèses de coûts et de l'implémentation du programme, qu'il faut vérifier séparément.

Avant la recherche, définir d'abord l'usage des données

Désigner d'abord une période de données pour la sélection des paramètres, puis réserver une autre période pour la validation. Après avoir défini les périodes, les instruments et les usages, conserver les enregistrements, afin d'éviter de choisir après coup, en voyant tous les résultats, une période qui passe facilement.

Hors échantillon signifie que les données n'ont pas participé à cette sélection. Si l'on a déjà consulté à plusieurs reprises la même période de données et modifié les paramètres en conséquence, cette période ne peut plus servir de preuve de validation totalement indépendante. Il s'agit ici d'un processus de recherche ; aucun ratio de division fixe n'est présenté comme adapté à tous les EA.

Processus pédagogique : sélection, gel, validation

Le processus illustratif est le suivant : période de sélection A → conserver les paramètres candidats et la version → figer la sélection → exécuter les paramètres fixes sur la période réservée B → consigner la réussite ou l'échec. A et B ne sont que des étiquettes d'usage des données, pas des comptes réels ni des graphiques de marché.

Il ne faut pas, si les performances sont mauvaises sur B, modifier immédiatement les paramètres puis appeler les résultats modifiés de B un premier test hors échantillon. S'il faut réellement modifier, il convient de consigner le nouveau processus de sélection et d'indiquer que la validation initiale n'a pas été réussie ; de nouvelles données de validation seront ensuite nécessaires.

Ce qui est figé n'est pas seulement les paramètres, mais aussi l'environnement

Conserver la version de l'EA, les spécifications de l'instrument, l'unité de temps, la source des données, la date du test et le modèle. Le capital initial, les coûts et le sens des transactions doivent aussi être indiqués. Lors de la comparaison des résultats avant et après, vérifier si ces conditions sont identiques ; on ne peut pas modifier plusieurs réglages à la fois puis attribuer le résultat uniquement à l'amélioration des paramètres.

Il convient de vérifier auprès du développeur si le programme concerné prend en charge un instrument, une unité de temps ou un mode de gestion des positions donné. Le fait que le testeur puisse démarrer ne prouve pas que toutes les conditions d'exécution sont remplies.

Ne pas regarder seulement le rendement le plus élevé, mais aussi les limites de variation

Consigner le nombre de transactions, le drawdown, la base de coûts et si les résultats sont concentrés sur un petit nombre de transactions. Si des paramètres proches, légèrement modifiés, changent fortement le résultat, il faut examiner davantage la cause, plutôt que de conclure automatiquement avoir trouvé le code exact de rentabilité.

Des performances similaires autour des paramètres ne prouvent pas non plus de manière indépendante l'efficacité en réel. Elles ne fournissent qu'une piste pour poursuivre la recherche, et il reste nécessaire d'examiner l'environnement de marché, les différences d'exécution et un échantillon indépendant. Sans dossier de test complet, aucun taux de réussite ni chiffre de rendement fixe n'est donné.

Les résultats d'échec doivent rester dans le rapport

Lorsqu'une validation échoue, indiquer sur quelle période cela s'est produit, quelles hypothèses doivent être réexaminées et s'il manque des données. Conserver les configurations en échec et les résultats bruts, ne pas supprimer les enregistrements défavorables pour ne garder que le meilleur ensemble final.

Si l'on obtient un beau résultat seulement après avoir changé plusieurs fois d'échantillon ou d'objectif, ce processus doit être divulgué. Présenter isolément la dernière courbe empêche le lecteur de voir combien d'essais ont été nécessaires dans le processus de sélection.

Observation simulée et réel sont des étapes différentes

Après le test hors échantillon, une observation simulée peut être poursuivie pour vérifier les entrées en temps réel, les conditions de déclenchement et l'état du programme, mais les performances simulées ne garantissent pas non plus les résultats en réel. L'exécution et les frais de la plateforme doivent être vérifiés séparément ; les chiffres de backtest ne remplacent pas la vérification des ordres réels.

Le week-end convient pour organiser les versions, les paramètres et les enregistrements de validation. Aucun test ne doit contourner l'autorisation du compte ni augmenter arbitrairement le risque réel au nom de la validation. Le trading avec effet de levier peut entraîner des pertes importantes ; cet article sert à l'éducation sur le processus de recherche des EA, ne constitue pas un conseil en investissement et ne promet aucun gain.

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.