Le mot important dans cette phrase est « précisément », et c'est tout l'objet de ce guide. Parce que la partie difficile n'a jamais été le code : elle est de savoir exactement ce que l'on veut, et de connaître les pièges qui font qu'un bot qui « marche » en backtest détruit un compte en réel.
Ce message est un retour d'expérience structuré, à partir du développement de plusieurs EA MQL5 sur indices. Il est long, mais il vous évitera les erreurs qui coûtent cher.
1. Ce que l'IA fait très bien, et ce qu'elle ne fera jamais
Autant poser le cadre tout de suite, parce que c'est là que la majorité des déceptions se logent.
Ce qu'elle fait remarquablement bien :
- Traduire une règle claire en code correct, dans à peu près n'importe quel langage.
- Gérer la syntaxe, la structure, la gestion d'erreurs, le logging — tout le travail fastidieux.
- Expliquer ligne par ligne un code existant, ce qui en fait un excellent outil d'apprentissage.
- Relire du code et détecter des bugs logiques, surtout si vous lui demandez explicitement de chercher les failles.
- Écrire les scripts d'analyse de vos résultats (Python/pandas sur vos rapports de trades), ce qui est souvent plus précieux que l'EA lui-même.
- Vous fournir un avantage de marché. Si vous demandez « écris-moi un bot rentable », vous obtiendrez un croisement de moyennes mobiles. C'est-à-dire une stratégie perdante après frais, testée par des millions de gens depuis quarante ans.
- Connaître les particularités de votre courtier, de votre symbole, de votre fuseau serveur. Elle produira du code générique et plausible, qui peut échouer silencieusement chez vous.
- Détecter que votre stratégie est biaisée si le biais est dans votre énoncé. Vous lui demandez d'utiliser la clôture de la bougie en cours ? Elle le fera, sans vous dire que votre backtest sera faux.
2. Le vrai prérequis : le cahier des charges
Avant d'ouvrir Claude ou ChatGPT, vous devez être capable d'écrire votre stratégie sous une forme telle qu'un inconnu pourrait l'exécuter manuellement sans jamais vous poser de question. Si vous n'y arrivez pas, vous n'avez pas de stratégie, vous avez une intuition.
Le test est simple. Pour chacun des points suivants, il doit exister une réponse chiffrée et non ambiguë :
- Quel instrument, quelle unité de temps, quelles heures de session exactement (et dans quel fuseau horaire) ?
- Quelle condition déclenche une entrée ? Sur quelle bougie exactement — celle en cours ou la précédente clôturée ?
- Quel type d'ordre : marché, limite, stop ? À quel prix précis ?
- Quelle taille de position, calculée comment ? En lots fixes, en pourcentage du capital, en risque fixe par trade ?
- Où est le stop de protection ? En points, en pourcentage, sur un niveau technique ?
- Quelle sortie en gain : objectif fixe, trailing stop, sortie temporelle, signal inverse ?
- Que se passe-t-il si un signal apparaît alors qu'une position est déjà ouverte ? On ignore, on cumule, on inverse ?
- Que se passe-t-il en cas de gap, de déconnexion, de trou de cotation, de spread anormal ?
- Quelles sont les conditions d'arrêt : perte journalière maximale, nombre de trades maximal, drawdown limite ?
3. Choisir sa plateforme et son langage
Le choix conditionne tout le reste. Pour un premier bot :
- MQL5 (MetaTrader 5) — le meilleur rapport accessibilité/puissance pour le CFD et le forex. Langage proche du C++, énormément de code d'exemple dans les données d'entraînement des IA, donc excellente qualité de génération. Strategy Tester intégré avec données tick. C'est le choix par défaut si vous tradez chez un courtier CFD.
- ProBuilder / ProOrder (ProRealTime) — langage propriétaire beaucoup plus simple, pensé pour les traders et non pour les développeurs. Très rapide à prendre en main, backtests fiables, exécution hébergée. En contrepartie, moins d'exemples publics, donc les IA sont un peu moins à l'aise : il faut leur fournir la documentation du langage dans le prompt pour obtenir un bon résultat. Excellent choix pour qui ne veut pas gérer d'infrastructure.
- Python — la plus grande liberté (API Interactive Brokers, backtesting avec vectorbt ou backtrader, analyse pandas). C'est aussi le domaine où les IA sont les plus performantes. Mais vous devez gérer vous-même l'environnement, l'hébergement, la connexion, les reconnexions. À réserver pour un deuxième projet, ou si vous avez déjà des bases.
- Pine Script (TradingView) — parfait pour prototyper visuellement et tester une idée en une heure. Mais l'exécution automatique passe par des webhooks et un relais externe, ce qui ajoute une couche de fragilité. À utiliser comme laboratoire d'idées, pas comme moteur d'exécution.
4. Claude ou ChatGPT ?
La réponse honnête : les deux, et pas pour les mêmes tâches.
- Claude est généralement plus à l'aise sur les fichiers de code longs et sur la cohérence d'un projet qui grossit : il tient mieux le fil d'un EA de 800 lignes qu'on modifie depuis deux heures, et se montre plus rigoureux sur la gestion d'erreurs et les cas limites. C'est aussi celui qui signale le plus spontanément les problèmes de conception dans une demande.
- ChatGPT est très efficace sur l'exploration rapide, la recherche de documentation, les scripts courts, et dispose d'un écosystème d'exécution de code pratique pour analyser directement un fichier de résultats.
5. La méthode de prompt qui fonctionne
N'écrivez jamais « fais-moi un bot qui achète quand le RSI est bas ». Structurez votre demande. Voici un squelette réutilisable :
Code : Tout sélectionner
CONTEXTE
Je développe un Expert Advisor MQL5 pour MetaTrader 5.
Courtier : [nom]. Symbole exact : [ex. NAS100.p]. Timeframe : M5.
Heure serveur du courtier : GMT+2 (attention au changement d'heure).
Compte : [devise], levier [x], taille de contrat [préciser].
STRATEGIE
Entrée : [règle exacte, en précisant sur quelle bougie]
Direction : [long uniquement / les deux]
Taille : [règle de calcul du lot]
Stop loss : [valeur exacte et méthode]
Take profit : [valeur exacte et méthode]
Sortie temporelle : [oui/non, délai]
Une seule position à la fois : OUI
Fenêtre horaire autorisée : [ex. 16h25 à 17h30 heure serveur]
CONTRAINTES OBLIGATOIRES
- Magic number paramétrable, et ne jamais toucher aux positions d'un autre magic
- Vérifier l'absence de position ET d'ordre en attente avant toute ouverture
- N'agir qu'une seule fois par bougie (mémoriser le temps de la dernière barre traitée)
- Vérifier les codes retour de OrderSend et logger les échecs
- Respecter SYMBOL_TRADE_STOPS_LEVEL et normaliser prix et volumes
- Perte journalière maximale paramétrable, au-delà l'EA cesse de trader
- Journaliser chaque décision en CSV : date, prix, lot, SL, TP, raison
LIVRABLE
Un fichier .mq5 complet, commenté en français, avec tous les paramètres
en input. Signale-moi explicitement les hypothèses que tu as dû faire.
Autre principe : travaillez par blocs. Faites d'abord la structure et la gestion des positions, testez, puis ajoutez la logique d'entrée, testez, puis la gestion du risque. Demander tout d'un coup produit un fichier volumineux dont vous ne saurez pas déboguer les interactions. Et lorsque vous corrigez, demandez la modification ciblée, pas une régénération complète — sinon vous perdez des corrections précédentes sans vous en apercevoir.
6. Les dix erreurs que l'IA commettra si vous ne l'en empêchez pas
Cette section est le cœur du guide. Ces erreurs ne sont pas des bugs de syntaxe : ce sont des pièges métier que le code compile parfaitement et que le backtest ne signale pas.
- Le biais de look-ahead. Utiliser la clôture de la bougie en cours, ou un indicateur calculé sur une barre non terminée. Votre backtest sera spectaculaire et irreproductible en réel. Exigez toujours de travailler sur la dernière bougie clôturée, et faites-le vérifier explicitement.
- Les doubles positions. Le cas d'école. La fonction de traitement des ticks est appelée très souvent, l'ordre précédent n'est pas encore confirmé par le serveur, et l'EA ouvre deux, cinq, dix positions. Il faut plusieurs couches de protection cumulées : vérification des positions, vérification des ordres en attente, verrou temporel après envoi, contrôle une fois par bougie seulement, et relecture après confirmation serveur.
- Le mauvais symbole. Les courtiers ajoutent des suffixes (.p, .cash, -PERP, .raw) et les instruments qui se ressemblent n'ont ni les mêmes horaires, ni les mêmes frais, ni la même valeur du point. Trader un contrat perpétuel en croyant trader l'indice cash coûte très cher, et le code fonctionne parfaitement pendant ce temps-là. Codez le symbole en paramètre et vérifiez-le au démarrage.
- La confusion valeur du point / taille de tick / lot. Sans cela, votre calcul de position et votre stop en euros sont faux. Faites toujours calculer la taille à partir des propriétés du symbole lues à l'exécution, jamais à partir d'une constante en dur.
- Le fuseau horaire. Heure serveur, heure locale, heure de marché et changements d'heure ne coïncident pas, et ne se décalent pas aux mêmes dates des deux côtés de l'Atlantique. Une stratégie d'ouverture US décalée d'une heure pendant trois semaines par an ne se voit pas dans les statistiques agrégées, mais elle contamine vos résultats.
- L'absence de gestion des codes retour. Un ordre refusé pour marge insuffisante, spread trop large ou marché fermé doit être détecté, journalisé, et éventuellement retenté. Sans cela, votre EA croit avoir une position qu'il n'a pas.
- La distance minimale de stop. Les courtiers imposent un écart minimum entre le prix et vos SL/TP. Un stop trop proche est simplement rejeté, et l'EA se retrouve avec une position nue.
- Les frais oubliés. Spread variable, commission, financement overnight, slippage. Une stratégie de scalping qui gagne 2 points par trade est morte si le spread moyen réel est de 1,5 point. Intégrez des frais volontairement pessimistes dans tout backtest.
- La qualité des données de test. Un backtest en « prix d'ouverture uniquement » ne veut rien dire pour une stratégie intraday. Exigez la modélisation par ticks réels et vérifiez le taux de qualité de modélisation.
- L'optimisation excessive. Les optimiseurs intégrés trouveront toujours des paramètres magiques. Plus vous testez de combinaisons, plus le résultat retenu est le fruit du hasard. Fixez vos paramètres par raisonnement, testez peu de variantes, et gardez une période d'historique jamais utilisée pour la validation finale.
Indépendamment de la stratégie, tout bot doit contenir ces protections. Demandez-les systématiquement :
- Un magic number, et l'interdiction absolue de toucher aux positions qui ne portent pas le sien.
- Une perte journalière maximale au-delà de laquelle l'EA se met en pause jusqu'au lendemain.
- Un nombre maximal de trades par jour.
- Un filtre de spread : au-delà d'un seuil, on ne prend pas la position.
- Une vérification de la connexion et de l'autorisation de trading avant chaque envoi d'ordre.
- Un interrupteur d'arrêt, c'est-à-dire un paramètre qui suspend toute nouvelle ouverture sans devoir retirer l'EA du graphique.
- Un journal CSV de chaque décision, y compris les non-décisions (« signal détecté mais rejeté car spread trop large »). C'est ce journal qui vous permettra plus tard de comprendre l'écart entre backtest et réel.
8. La séquence de validation
Ne sautez aucune étape, et surtout pas la troisième.
- Compilation et test unitaire. L'EA se lance, ouvre une position quand vous le forcez, la ferme correctement. Vérifiez sur quelques trades manuels que les prix, lots, SL et TP correspondent exactement à ce que vous attendiez.
- Backtest. Sur données ticks, avec frais réalistes, sur plusieurs années et surtout sur plusieurs régimes de marché distincts. Regardez le drawdown maximal, la plus longue série de pertes, et la distribution des résultats — pas seulement le profit final.
- Validation hors échantillon. Sur une période que vous n'avez jamais utilisée pendant la conception. Si les résultats s'effondrent, votre stratégie était surajustée. C'est une information, pas un échec.
- Démo. Minimum quatre à six semaines, sans intervention. Le but n'est pas de vérifier la rentabilité (l'échantillon est bien trop court) mais de vérifier le comportement technique : reconnexions, week-ends, changements d'heure, jours fériés, annonces macro, glissements d'exécution.
- Réel en taille minimale. Le plus petit lot possible, pendant plusieurs semaines. Vous découvrirez des écarts avec la démo, notamment sur l'exécution et le slippage. C'est normal, et c'est précisément l'information que vous cherchez.
- Montée en taille progressive, uniquement après avoir accumulé un nombre de trades suffisant pour que les résultats aient un sens statistique — ce qui, sur une stratégie à avantage modeste, se compte en centaines de trades, pas en dizaines.
Trois remarques pour finir, qui valent avertissement.
Le premier bot ne sera pas rentable. C'est presque une loi. Sa vraie fonction est de vous apprendre la chaîne complète : formaliser, coder, tester, mesurer, corriger. Cette compétence, elle, est durablement rentable.
L'automatisation ne supprime pas les erreurs humaines, elle les déplace et les accélère. Un trader discrétionnaire qui se trompe perd un trade ; un bot mal paramétré exécute la même erreur cinquante fois avant que vous ayez ouvert votre écran. La discipline exigée n'est pas moindre, elle est simplement déportée en amont.
Enfin, méfiez-vous de la facilité nouvelle. Le fait qu'un EA soit désormais produit en deux heures ne rend pas les marchés plus faciles : cela signifie simplement que des milliers de personnes déploient au même moment les mêmes stratégies évidentes. L'avantage ne s'est pas déplacé vers celui qui sait coder — il s'est déplacé vers celui qui sait quoi coder, et pourquoi.
Checklist avant de lancer en réel
- Mon cahier des charges répond aux dix questions du point 2, sans ambiguïté.
- Le code n'utilise aucune donnée de la bougie en cours.
- La protection contre les doubles positions est multi-couches et a été testée en la provoquant volontairement.
- Le symbole, la valeur du point et le fuseau serveur ont été vérifiés à la main sur un trade réel.
- Les frais du backtest sont supérieurs aux frais réels observés.
- La perte journalière maximale et l'interrupteur d'arrêt sont implémentés et testés.
- Le code a été relu de façon critique par un second modèle.
- La démo a tourné au moins un mois sans intervention, changement d'heure et jour férié inclus.
- Je connais à l'avance le drawdown et la série de pertes que je dois être capable de supporter.