On nous demande souvent ce que signifie concrètement « une équipe d'IA fait de la recherche de stratégies », alors voici une hypothèse suivie de bout en bout. L'essentiel à retenir : c'est un entonnoir qui existe pour rejeter. La plupart des idées meurent. C'est le signe que le produit fonctionne.
Les questions qu'on nous pose vraiment à ce sujet
Qui trouve les idées ?
Un agent de recherche qui lit ce que la bibliothèque de données peut réellement soutenir — taux de funding, open interest, flux de liquidations, surfaces d'options, sentiment des actualités, Fear & Greed — et rédige des hypothèses avec une thèse, une plateforme, un horizon temporel et un profil de risque. Il est explicitement conscient des frais : une idée dont l'edge plausible est inférieur au coût aller-retour de la plateforme est mal formée dès son arrivée. Il lit aussi le cimetière. La raison d'échec de chaque stratégie abandonnée est vectorisée et interrogeable, si bien que « momentum de funding sur bougies horaires, troisième tentative » est signalé avant de gaspiller un cycle.
Qui écrit le code, et pourquoi devrait-on lui faire confiance ?
Un agent développeur code la stratégie sur un template de base imposé — sizing relatif au capital, logique de stop explicite, besoins en données déclarés. La confiance vient du parcours du combattant, pas de l'auteur. Quatre couches : l'analyse statique (des vérifications AST ciblant les anti-patterns que nous avons catalogués) ; des scénarios synthétiques (six configurations de marché avec des données supplémentaires fabriquées — une stratégie qui achète dans un scénario de krach qu'elle était censée éviter meurt ici) ; un backtest en sandbox sur données réelles qui doit produire au moins un trade ; et un agent QA qui fait une revue de code portant sur la polarité des signaux, les cas limites et la viabilité face aux frais. La couche 2 attrape la classe d'erreurs la plus embarrassante : du code qui tourne parfaitement et fait l'inverse de l'hypothèse.
Que facture réellement le backtest ?
Les vrais frais maker/taker de chaque plateforme, l'accumulation du funding sur le prix mark, un impact de marché en racine carrée, la marge et la liquidation pour les books à effet de levier, les calendriers de séance pour les actions. Une equity en mark-to-market incluant le PnL latent, pour que les drawdowns ne se cachent pas entre l'entrée et la sortie. Si cela ressemble à un minimum syndical, ça ne l'est pas ; chaque élément a été ajouté parce que son absence avait produit une promotion erronée bien précise.
L'optimisation ne fait-elle pas que de l'overfitting ?
Elle essaie. Le pipeline part de ce principe : les paramètres passent d'abord par un balayage de sensibilité (une stratégie qui ne fonctionne qu'à exactement lookback=14 est une coïncidence, pas une stratégie), puis par une optimisation walk-forward sur trois fenêtres avec suivi in-sample/out-of-sample, puis par un holdout final que la stratégie ne voit qu'une seule fois. Un Sharpe out-of-sample inférieur à la moitié du chiffre in-sample vaut rejet. Le holdout doit conserver au moins 70% du Sharpe out-of-sample du walk-forward. Ce sont des garde-fous imposés par le code, pas laissés à la discrétion de l'analyste — l'analyste peut lever un plancher souple en consignant sa raison, mais ne peut pas lever les contrôles d'overfitting.
Quel est le taux de réussite ?
Faible, et c'est voulu. La mort la plus fréquente survient à la revue de l'analyste : l'edge est réel mais sous 0.15% par trade après coûts. La deuxième cause la plus courante est la falaise de sensibilité. Les survivants passent devant un risk officer, puis en paper trading, où un contrôle quotidien de parité de replay les confronte indéfiniment aux données réelles. Le capital réel, lui, reste derrière une barrière séparée, contrôlée par un humain.
