Logs d'EA : reconstituer un incident après coup

En bref : sans logs, un EA ne peut pas être analysé après un incident

Commençons par la conclusion. Un EA devrait écrire au minimum, à raison d'une ligne chacun, trois éléments : « les valeurs utilisées pour décider », « la raison pour laquelle il n'est pas entré » et « le résultat de l'exécution ». Avec ces trois éléments, vous pouvez reconstituer après coup un trade inattendu, ou le fait qu'« il ne s'est rien passé ». Sans eux, que vous subissiez une perte ou que le nombre de trades reste à 0, impossible de distinguer si la cause vient de la logique de l'EA, du marché ou du courtier.

Nous développons nous aussi des EA, et nous avons connu à la fois des cas où les logs nous ont sauvés et des cas où leur insuffisance nous a laissés sans explication. Cet article présente, du côté de l'utilisateur, ce qu'est un « bon log ».

Pourquoi trois types de logs ?

Une décision d'EA suit en gros ce déroulement : « calcul des valeurs → évaluation des conditions → envoi de l'ordre → exécution ». Pour identifier a posteriori l'étape où les choses ont dévié, il faut une trace de chacune.

Valeurs de décision : sans chiffres, impossible de distinguer du hasard

Un log qui dit simplement « signal d'achat » n'est guère utile. Sans savoir de combien la valeur de l'indicateur s'écartait du seuil, on ne peut pas dire si la condition était remplie de justesse ou nettement. Notez aussi toujours sur quelle bougie (l'heure de la bougie clôturée) la décision a été prise.

Raison du saut : le log le plus souvent omis, et le plus important

La plupart des EA n'écrivent un log que lorsqu'ils entrent en position. Pourtant, la question la plus fréquente en exploitation est : « il n'entre jamais ». Si la raison du saut figure dans les logs, vous pouvez vérifier s'il s'agit d'un renoncement conforme à la conception, d'une erreur de paramétrage ou d'un décalage de l'heure du serveur.

Notre MEGAMAX DONCHIAN, en forward test sur un compte démo Exness, affichait 0 trade au 11 novembre 2026. Nous n'avons pas encore pu en confirmer la raison, et nous ne la supposerons pas ici. Mais dans ce genre de situation, la présence ou non d'un log des raisons de saut change beaucoup l'effort de vérification. 0 trade ne signifie pas de mauvaises performances, mais tant que les logs n'ont pas été lus, on ne peut pas non plus affirmer qu'il s'agit d'un renoncement normal.

Exécution : enregistrer ce qui se passe en dehors de l'EA

Savoir si un ordre a été rejeté, ou exécuté avec un fort slippage, relève d'un problème distinct de la logique de l'EA. Si vous conservez le code retour et le prix d'exécution, vous pouvez séparer ce qui vient de l'EA de ce qui vient du courtier ou de la connexion.

Que mettre sur une ligne : exemples de format

Nous regroupons chaque décision sur une seule ligne, dans un format fixe facile à rechercher ensuite.

[EVAL] bar=2026.11.10 14:00 sig=BUY val=1.234 th=1.200 spread=18 -> ENTRY
[SKIP] bar=2026.11.10 15:00 reason=SPREAD spread=45 max=30
[FILL] ticket=123456 req=152.340 fill=152.346 slip=6 ret=10009

Quelques points à retenir pour l'écriture :

• Placer en tête une balise de type (EVAL / SKIP / FILL) pour pouvoir filtrer avec grep ou une recherche
• Indiquer l'heure de « la bougie clôturée utilisée pour la décision » (en partant du principe qu'il s'agit de l'heure du serveur)
• Exprimer la raison par un code fixe plutôt que par une phrase (SPREAD, TIME, POSITION, etc.)
• Ne pas écrire à chaque tick, mais uniquement au moment de la décision

Écrire à chaque tick fait gonfler les logs en très peu de temps, sature le disque et noie les lignes importantes. La règle de base : « une fois, à la clôture de la bougie ».

Procédure de vérification côté utilisateur

Si vous utilisez un EA, cet ordre de vérification vous mènera plus vite à la cause :

1. Dans l'onglet « Experts » de MT5, vérifier que l'EA écrit bien ses propres logs
2. Repérer la ligne EVAL à l'heure du trade inattendu et examiner les valeurs de décision et le seuil
3. Pour les périodes sans entrée, lire les lignes SKIP et compter quelles raisons reviennent le plus
4. Dans les lignes FILL, vérifier l'écart entre prix demandé et prix exécuté, ainsi que le code retour
5. Croiser les heures avec l'onglet « Historique des opérations » (l'enregistrement côté courtier)

Pour revoir vos réglages, consultez Configurer un EA, et pour un environnement qui tourne en continu, Infos VPS.

Limites et précautions

Les logs ne sont pas une solution universelle. Soyons honnêtes sur ce point.

• Ce qui n'est pas écrit dans les logs reste inconnu. Un phénomène que le développeur n'avait pas prévu n'est tout simplement pas enregistré.
• Les logs ne sont pas forcément corrects. Si le code qui écrit les logs contient un bug, des valeurs erronées seront enregistrées.
• On ne peut pas juger la qualité des décisions de marché. Les logs indiquent si l'EA a fonctionné « conformément à sa conception », pas si cette conception est gagnante.
• En écrire trop est aussi source d'incidents. Un volume massif de logs occupe de l'espace et rend les oublis plus probables à la lecture.
• La signification des logs diffère entre backtest, compte démo et compte réel. Dans le testeur, slippage et rejets ne sont pas reproduits comme en conditions réelles ; tenez compte de cette différence d'environnement quand vous comparez les logs d'exécution.

Résumé

• Écrire dans les logs trois types de lignes : « valeurs de décision », « raison du saut » et « exécution »
• Le log des raisons de saut est le plus souvent omis, et le plus utile pour comprendre pourquoi « rien ne bouge »
• Définir des balises et des codes de raison permet de rechercher et de compter ensuite
• N'écrire qu'une fois par bougie clôturée, et non à chaque tick
• Les logs disent seulement si l'EA a fonctionné « conformément à sa conception » ; savoir s'il est gagnant exige d'autres vérifications

Retrouvez d'autres conseils d'exploitation MT5 dans Savoir-faire EA et MT5.