Lundi, notre agent de recherche IA a trouvé une stratégie sur les contrats à terme crypto avec un ratio de Sharpe de 4.1. Jeudi, après avoir compté les expériences et empêché l’agent de régler les paramètres en fonction de la même fenêtre de validation, le résultat était de 0.8. La stratégie n’avait pas changé. Notre estimation de ce que la recherche avait produit, si.
Nous avons tenu ce journal de recherche pour documenter le processus, car « optimiser avec soin » est un conseil facile à donner et difficile à mettre en pratique lorsqu’un agent peut écrire du code, lancer des backtests, examiner le score et recommencer en quelques minutes. Voici ce qui a déraillé, dans l’ordre.
Lundi : poser une question bien délimitée à l’agent
Nous avons demandé à l’agent de tester une idée simple de suivi de tendance horaire sur un marché liquide de contrats perpétuels : entrer quand une moyenne mobile courte croise une moyenne plus longue, dimensionner la position selon une cible de volatilité fixe et la clôturer au signal inverse. Nous avons précisé l’instrument, les dates, le barème des frais, l’historique du funding, l’hypothèse d’exécution et les plages de paramètres à explorer.
L’échantillon historique couvrait 2021 à 2025. Nous avons affecté 2021–2023 au développement, 2024 à la validation et gardé 2025 sous clé comme échantillon de test final. Cette séparation était inscrite dans la configuration de la tâche : l’agent pouvait consulter les résultats de développement et les scores de validation, mais ne pouvait pas récupérer les rendements de l’échantillon de test.
Notre première erreur a été d’autoriser 300 combinaisons de paramètres dans une seule tâche, sans consigner le budget de recherche comme résultat de recherche. L’agent a renvoyé la meilleure combinaison : une moyenne rapide de 9 heures, une moyenne lente de 73 heures et une cible de volatilité de 0.8%. Son Sharpe de validation était de 4.1. Nous savions que l’agent avait essayé de nombreux réglages. Mais nous n’avions pas encore fait en sorte qu’il soit impossible d’oublier ce fait.
Mardi : le gagnant change lors de la nouvelle exécution
Nous avons relancé la même tâche dans un environnement vierge. Le meilleur réglage avait changé et son Sharpe était tombé à 2.7. Un cache de données de marché avait fourni une série de funding mise à jour lors de la première exécution, tandis que la relance utilisait un instantané figé. Les deux tâches prétendaient couvrir la même période ; une seule disposait d’une version des données reproductible.
Nous avons cessé de comparer les scores et commencé à consigner chaque expérience dans son intégralité : révision du code, instantané des données, frais, funding, paramètres d’exécution, valeurs des paramètres et chaque essai lancé par l’agent. Cela a montré que le 4.1 ne signalait pas un mystérieux avantage de marché. Il correspondait à un réglage parmi 300 essais sur la même année de validation.
Mercredi : figer la recherche avant d’ouvrir l’échantillon de test
Nous avons relancé l’expérience avec un instantané de données fixe et une grille plus réduite, définie à l’avance : 24 combinaisons. L’agent pouvait les classer selon les résultats de la période de développement 2021–2023. Nous l’avons laissé consulter 2024 une fois, pour effectuer la sélection, puis nous avons verrouillé les paramètres retenus et le code.
La stratégie retenue a obtenu un Sharpe de 0.8 en validation. Sur l’échantillon de test 2025, resté scellé, son score était de 0.3 après prise en compte des frais taker, du funding et du même délai d’exécution d’une barre appliqué tout au long de l’étude. C’était une réponse utile. Ce n’était pas la preuve que la stratégie gagnerait de l’argent sur un compte réel.
Une parenthèse sur cette semaine : nous avons passé plus de temps à nous mettre d’accord sur ce qui constituait « un essai » qu’à écrire le code des moyennes mobiles. Nous avons compté chaque ensemble de paramètres modifié comme un essai, ainsi que les exécutions qui changeaient le signal ou la règle de dimensionnement. Un nouvel instantané de données ou une nouvelle hypothèse d’exécution faisait l’objet d’un enregistrement distinct, car l’un comme l’autre pouvait modifier le classement tout autant.
Jeudi : ce que nous éviterions la prochaine fois
Nous éviterions la première tâche sans limites précises. Un agent de recherche a besoin d’un budget de recherche et d’un registre de ses essais, surtout lorsqu’il peut s’appuyer sur chaque résultat pour choisir la suite. L’échantillon de test doit aussi être protégé des consultations informelles : dès que quelqu’un en lit le résultat et modifie la stratégie, il devient un autre jeu de validation.
Pour une recherche de petite envergure, un registre d’expériences peut rester simple et explicite :
| À consigner | Pourquoi c’est important |
|---|---|
| Versions du code et des données | Pour qu’une relance utilise les mêmes entrées et la même logique |
| Chaque variante testée | Pour comprendre le gagnant à la lumière de la recherche |
| Rôle des périodes de développement, de validation et de test final | Pour éviter de réutiliser discrètement le score final afin de régler les paramètres |
| Frais, funding et hypothèses d’exécution | Pour que le résultat publié décrive une simulation vérifiable |
Une fois l’échantillon de test ouvert, reprenez le développement avec une nouvelle question de recherche et conservez l’ancien résultat comme élément historique. Ne continuez pas à peaufiner la même stratégie à partir d’une période qu’elle a déjà vue.
L’agent a fait son travail : il a effectué la recherche rapidement et trouvé une configuration qui méritait d’être étudiée. Notre travail consistait à rendre la recherche lisible, à préserver un test intact et à traiter le score comme une mesure dont il fallait connaître l’historique. Le résultat intéressant n’était ni 4.1 ni 0.3. C’était de voir précisément comment le premier chiffre avait été obtenu.
← Tous les articles
