Bien prompter une IA pour analyser les marchés, optimiser et backtester une stratégie
Publié : 14 sept. 2026, 12:26
Depuis deux ans, à peu près tout le monde ici a testé ChatGPT, Claude, Gemini ou Mistral sur un sujet boursier. Et à peu près tout le monde en est ressorti avec le même sentiment : soit c'est bluffant, soit c'est du vent. En réalité, l'écart de qualité entre deux utilisateurs ne vient presque jamais du modèle utilisé. Il vient de la façon dont la demande est formulée, et surtout de la matière qu'on lui donne à traiter.
Je vous propose ici une méthode de travail, avec des exemples de prompts directement réutilisables.
1. Commencer par comprendre ce que l'outil sait faire (et ne sait pas faire)
C'est la base, et c'est ce qui explique 80 % des déceptions. Un LLM est un moteur de raisonnement et de structuration du langage, pas une base de données financière.
Ce qu'il fait très bien :
2. L'anatomie d'un prompt qui fonctionne
Un prompt utile contient presque toujours six briques. Si vous en oubliez trois, le résultat sera générique.
3. Analyse de marché : donner la matière, interdire la boule de cristal
L'erreur classique est de demander une prévision. On obtient alors un texte tiède, plein de « cependant » et de « il convient de rester prudent », qui n'aide à rien.
La bonne approche consiste à demander un cadre de scénarios avec des niveaux d'invalidation. Vous transformez une question de divination en question d'ingénierie.
Autre usage très rentable, et largement sous-exploité : l'analyse documentaire. Copiez-collez un communiqué de résultats, un rapport annuel, la déclaration d'une banque centrale, et demandez une extraction ciblée. « Liste tous les éléments de ce document qui contredisent la thèse du management », « compare le discours de ce communiqué avec celui du trimestre précédent que je te fournis en second », « extrais uniquement les chiffres liés à la dette et à la génération de cash ». Là, le modèle est sur son terrain : du texte long, une tâche d'extraction, une donnée vérifiable.
4. Le piège numéro un : le modèle vous dit ce que vous voulez entendre
C'est le point le plus important de ce message. Les LLM sont entraînés à satisfaire l'utilisateur. Si vous écrivez « je pense que le Nasdaq est en train de former un double sommet, qu'en penses-tu ? », vous allez recevoir une belle argumentation en faveur de votre thèse. Ce n'est pas une analyse, c'est un miroir.
Deux parades.
D'abord, neutralisez la question. Au lieu de « est-ce un bon point d'entrée ? », écrivez « voici un point d'entrée envisagé. Liste les cinq raisons les plus solides de ne pas prendre cette position. »
Ensuite, systématisez la contradiction. Une fois que vous avez obtenu une analyse, relancez avec :
Faire tourner une idée dans les deux sens, thèse puis antithèse, donne un résultat bien supérieur à une analyse unique, quelle que soit la qualité du prompt initial.
5. Optimiser une stratégie sans fabriquer du surapprentissage
Si vous demandez à une IA d'optimiser une stratégie, elle va faire exactement ce que vous demandez : trouver les paramètres qui maximisent la performance sur les données fournies. C'est-à-dire fabriquer une courbe de capital magnifique et parfaitement inutile en réel.
Il faut donc inverser la commande : ne demandez pas d'optimiser, demandez de tester la robustesse.
Le point 4 est celui qui fait le plus de dégâts, et c'est tant mieux. Une stratégie dont on ne peut pas expliquer pourquoi elle gagne est une stratégie qu'on ne saura pas défendre le jour où elle enchaîne huit pertes.
6. Faire écrire et déboguer du code
C'est probablement l'usage où le rapport qualité/temps est le meilleur. Mais la précision du prompt y est encore plus critique qu'ailleurs, parce que le code, lui, ne devine pas.
Quelques règles.
7. Travailler en itérations, pas en une seule requête
Le réflexe naturel est d'écrire un prompt géant qui demande tout. Le résultat est systématiquement moyen partout.
La bonne méthode ressemble à une conversation de travail. Une tâche par message, et on construit.
8. Vérifier, toujours
Le point non négociable.
9. Les erreurs les plus fréquentes, en résumé
Pour conclure
Un LLM ne vous donnera jamais un avantage de marché tout fait. En revanche, il divise par cinq le temps passé à structurer une analyse, à écrire du code, à éplucher un document de 200 pages, et il constitue le meilleur contradicteur disponible à 3 heures du matin quand on est seul devant son écran avec une idée qu'on aime un peu trop.
C'est un outil d'analyse et de discipline, pas un générateur de signaux. Prompté ainsi, il devient réellement utile.
N'hésitez pas à partager ici vos propres prompts, ceux qui fonctionnent comme ceux qui ont échoué. C'est le genre de sujet où l'expérience collective vaut bien mieux que la théorie.
Je vous propose ici une méthode de travail, avec des exemples de prompts directement réutilisables.
1. Commencer par comprendre ce que l'outil sait faire (et ne sait pas faire)
C'est la base, et c'est ce qui explique 80 % des déceptions. Un LLM est un moteur de raisonnement et de structuration du langage, pas une base de données financière.
Ce qu'il fait très bien :
- structurer une analyse, poser un cadre, hiérarchiser des arguments
- critiquer un raisonnement, trouver les failles d'une stratégie, jouer l'avocat du diable
- écrire, corriger et commenter du code (ProBuilder, MQL5, Python, Pine Script)
- traiter un texte long que vous lui fournissez : rapport annuel, communiqué, compte rendu de banque centrale, journal de trading
- faire des maths de gestion du risque et expliquer des concepts statistiques
- vous donner un cours en temps réel ou une donnée chiffrée fiable de mémoire (il inventera un chiffre plausible plutôt que d'admettre qu'il ne sait pas)
- prédire une direction de marché
- calculer précisément sur de longues séries de données sans outil d'exécution de code
- rester neutre face à une question orientée
2. L'anatomie d'un prompt qui fonctionne
Un prompt utile contient presque toujours six briques. Si vous en oubliez trois, le résultat sera générique.
- Le rôle : à qui vous parlez. « Tu es un gérant quantitatif qui a 15 ans d'expérience sur les futures indices » oriente le vocabulaire et le niveau d'exigence.
- Le contexte : qui vous êtes, votre capital, votre horizon, vos instruments, votre contrainte de temps, votre niveau. Sans ça, on vous répondra pour un investisseur moyen qui n'existe pas.
- La tâche : une seule, formulée avec un verbe d'action précis. Analyser, comparer, critiquer, coder, réécrire, lister. Pas « parle-moi de ».
- Les contraintes : ce qui est interdit, ce qui est imposé. Pas d'effet de levier, uniquement des ETF éligibles PEA, maximum 2 % de risque par position, horizon 6 mois.
- Le format de sortie : tableau, liste numérotée, code commenté, 300 mots maximum. C'est ce qui rend la réponse exploitable au lieu d'être un pavé.
- Le critère de qualité : dites-lui à quoi ressemblerait une bonne réponse. « Chaque scénario doit comporter un niveau d'invalidation chiffré. »
3. Analyse de marché : donner la matière, interdire la boule de cristal
L'erreur classique est de demander une prévision. On obtient alors un texte tiède, plein de « cependant » et de « il convient de rester prudent », qui n'aide à rien.
La bonne approche consiste à demander un cadre de scénarios avec des niveaux d'invalidation. Vous transformez une question de divination en question d'ingénierie.
Code : Tout sélectionner
Tu es un analyste marché chargé de préparer une note interne, pas de faire une prévision.
Contexte : je suis investisseur particulier, horizon 3 à 6 mois, je travaille sur [instrument]. Je te fournis ci-dessous [les données / le rapport / le communiqué].
Tâche : construis trois scénarios (haussier, central, baissier).
Pour chaque scénario, donne obligatoirement :
- les conditions qui le déclenchent
- les niveaux de prix clés, chiffrés
- le niveau ou l'événement qui l'invalide
- une estimation de probabilité, avec la justification de cette estimation
- ce que je devrais observer dans les prochaines semaines pour savoir si ce scénario prend le dessus
Contraintes : n'utilise aucune donnée que je ne t'ai pas fournie. Si une information te manque, dis-le explicitement au lieu de l'inventer. Pas de conclusion générale du type « rester prudent ».
Format : un tableau de synthèse, puis un paragraphe par scénario.
4. Le piège numéro un : le modèle vous dit ce que vous voulez entendre
C'est le point le plus important de ce message. Les LLM sont entraînés à satisfaire l'utilisateur. Si vous écrivez « je pense que le Nasdaq est en train de former un double sommet, qu'en penses-tu ? », vous allez recevoir une belle argumentation en faveur de votre thèse. Ce n'est pas une analyse, c'est un miroir.
Deux parades.
D'abord, neutralisez la question. Au lieu de « est-ce un bon point d'entrée ? », écrivez « voici un point d'entrée envisagé. Liste les cinq raisons les plus solides de ne pas prendre cette position. »
Ensuite, systématisez la contradiction. Une fois que vous avez obtenu une analyse, relancez avec :
Code : Tout sélectionner
Tu vas maintenant changer de rôle. Tu es le gérant du risque et ton travail est de refuser ce dossier.
Reprends l'analyse que tu viens de produire et démonte-la :
- quelles hypothèses ne sont pas démontrées ?
- quel biais cognitif est visible dans mon raisonnement initial ?
- quel scénario n'a pas été envisagé et ferait perdre le plus d'argent ?
- qu'est-ce qui, dans ce raisonnement, relève du hasard plutôt que de l'edge ?
Sois direct. Ne cherche pas à ménager ma thèse de départ.
5. Optimiser une stratégie sans fabriquer du surapprentissage
Si vous demandez à une IA d'optimiser une stratégie, elle va faire exactement ce que vous demandez : trouver les paramètres qui maximisent la performance sur les données fournies. C'est-à-dire fabriquer une courbe de capital magnifique et parfaitement inutile en réel.
Il faut donc inverser la commande : ne demandez pas d'optimiser, demandez de tester la robustesse.
Code : Tout sélectionner
Tu es un quant sceptique. Je te présente une stratégie et ton rôle est de déterminer si son edge est réel ou s'il s'agit de surapprentissage.
Stratégie : [règles d'entrée, de sortie, de filtre, exactes et complètes]
Instrument et unité de temps : [...]
Période testée : [...]
Résultats : [nombre de trades, gain moyen, perte moyenne, taux de réussite, drawdown maximum, profit factor]
Analyse dans cet ordre :
1. Compte le nombre de degrés de liberté de la stratégie (paramètres optimisables, conditions, filtres) et rapporte-le au nombre de trades. Conclus sur le risque de surapprentissage.
2. Identifie les paramètres qui te semblent « choisis pour que ça marche » plutôt que justifiés par une logique de marché.
3. Propose un protocole de validation : découpage in-sample / out-of-sample, walk-forward, test sur instruments corrélés, test sur une période de régime opposé.
4. Formule l'hypothèse économique sous-jacente : pourquoi ce comportement de prix existerait-il, et qui perd de l'argent en face ?
5. Liste les coûts non modélisés : spread, slippage, commissions, financement overnight, gaps d'ouverture.
Si tu estimes que l'edge n'est pas démontré, dis-le clairement.
6. Faire écrire et déboguer du code
C'est probablement l'usage où le rapport qualité/temps est le meilleur. Mais la précision du prompt y est encore plus critique qu'ailleurs, parce que le code, lui, ne devine pas.
Quelques règles.
- Nommez explicitement la plateforme et la version : ProBuilder ProRealTime v12, MQL5 pour MetaTrader 5, Python avec backtrader, Pine Script v5. Les syntaxes ne sont pas interchangeables et le modèle mélangera les dialectes si vous restez vague.
- Écrivez vos règles comme un cahier des charges, pas comme une intention. « J'achète quand la moyenne mobile croise » est ambigu. « Ouvrir une position longue à la clôture de la bougie si la MM20 en clôture passe au-dessus de la MM50 en clôture, une seule position à la fois, pas de pyramidage » est exécutable.
- Précisez la gestion des cas limites : que se passe-t-il si un signal d'entrée apparaît alors qu'une position est ouverte ? Le week-end ? Sur un gap qui saute le stop ? À l'ouverture des séances ?
- Imposez les coûts : spread moyen, commissions, slippage. Un backtest sans coûts est un exercice de style.
- Demandez du code commenté et testez par morceaux. Faites valider la logique du signal avant d'ajouter la gestion de position, puis le money management. Un script de 200 lignes généré d'un bloc est impossible à déboguer.
7. Travailler en itérations, pas en une seule requête
Le réflexe naturel est d'écrire un prompt géant qui demande tout. Le résultat est systématiquement moyen partout.
La bonne méthode ressemble à une conversation de travail. Une tâche par message, et on construit.
- Étape 1 : poser le contexte et vérifier qu'il est compris. « Voici ma situation, mes contraintes et mon objectif. Reformule-les avec tes mots. »
- Étape 2 : cadrer. « Quelles sont les trois approches possibles pour ce problème, avec leurs inconvénients ? »
- Étape 3 : approfondir celle qui vous intéresse.
- Étape 4 : faire critiquer le résultat.
- Étape 5 : faire produire le livrable final (code, tableau, note).
8. Vérifier, toujours
Le point non négociable.
- Tout chiffre sorti « de mémoire » par un LLM doit être considéré comme faux jusqu'à vérification sur une source primaire. Les cours, les ratios financiers, les dates de publication, les niveaux historiques : vérifiez.
- Les fonctions et indicateurs exotiques cités dans du code n'existent pas toujours dans la plateforme visée. Le modèle peut inventer une fonction parfaitement plausible.
- Un backtest produit par une IA n'est pas un backtest tant que vous ne l'avez pas fait tourner vous-même sur vos données.
- Aucune décision de position ne devrait sortir directement d'une réponse d'IA. L'outil sert à structurer votre réflexion et à trouver les failles de vos idées, pas à décider à votre place.
9. Les erreurs les plus fréquentes, en résumé
- Demander une prédiction au lieu d'un cadre de scénarios.
- Poser une question orientée et prendre l'approbation obtenue pour une validation.
- Ne pas fournir de données et s'étonner que les chiffres soient inventés.
- Rester vague sur la plateforme, la version, l'unité de temps, l'instrument.
- Tout demander en un seul prompt.
- Demander d'optimiser plutôt que de tester la robustesse.
- Ne pas fixer de format de sortie et recevoir un pavé inexploitable.
- Oublier de dire au modèle ce qu'il doit faire quand il ne sait pas.
Pour conclure
Un LLM ne vous donnera jamais un avantage de marché tout fait. En revanche, il divise par cinq le temps passé à structurer une analyse, à écrire du code, à éplucher un document de 200 pages, et il constitue le meilleur contradicteur disponible à 3 heures du matin quand on est seul devant son écran avec une idée qu'on aime un peu trop.
C'est un outil d'analyse et de discipline, pas un générateur de signaux. Prompté ainsi, il devient réellement utile.
N'hésitez pas à partager ici vos propres prompts, ceux qui fonctionnent comme ceux qui ont échoué. C'est le genre de sujet où l'expérience collective vaut bien mieux que la théorie.