La réponse en bref : confiez à GPT-6 Astra la partie lourde et difficile, c’est-à-dire chercher, dans les données du carnet d’ordres et des transactions, des schémas de scalping que personne n’a encore décrits. Confiez à Claude Opus 5.5 tout le reste : préparation des données, environnement de test, correction des bogues, tests de non-régression, backtests, tentatives de réfuter les résultats et gestion des tâches. L’idée n’est pas d’employer l’IA la plus intelligente pour tout. Utilisez Astra comme un chercheur coûteux et Opus 5.5 comme un chef de chantier qui ne s’arrête jamais.
1. Ce qui a surpris, ce n’est pas l’intelligence, mais le fait de ne pas s’arrêter
Lors d’une longue session de maintenance logicielle, l’IA n’a pas corrigé la première erreur pour en rester là.
Elle a trouvé la cause d’un test qui échouait à cause de différences d’environnement d’exécution, en utilisant l’injection de dépendances. Elle a réécrit un vieux test qui vérifiait encore une règle supprimée. Elle a réparé un audit qui n’avait pas suivi le passage à un validateur commun. Enfin, elle a découvert qu’il manquait des données de test (fixtures), ce qui bloquait la compilation réelle. Après chaque correction, elle a relancé toute la suite de tests, puis la vraie compilation.
Pour une personne, cela vaut plus qu’une seule réponse brillante.
Avec les agents, le goulot d’étranglement est souvent le coût des interruptions humaines :
- L’IA trouve un problème.
- Elle en corrige un.
- Elle découvre un autre échec.
- Elle s’arrête avec un « vérifiez ceci ensuite ».
- Une personne doit dire « non, continue » et la relancer.
Anthropic présente Opus 5.5 comme un modèle pour les longues sessions de programmation, les grandes bases de code et le travail d’agents qui utilisent plusieurs outils avec peu de supervision. Elle indique aussi que les charges de travail courantes facturées au jeton coûtent environ 40 % de moins qu’avec Opus 5.[1]
L’essentiel est que la valeur d’une IA ne se mesure pas seulement à sa façon de résoudre un problème difficile. Dans le travail réel, ce qui compte, c’est de pouvoir aller jusqu’au bout : trouver la cause, corriger, vérifier, corriger encore et confirmer que c’est terminé.
2. Astra est-il donc inutile ? Non : il ne vaut son prix que pour explorer
GPT-6 Astra est le modèle le plus puissant d’OpenAI pour les travaux complets les plus difficiles. Son prix d’API est de 10 dollars par million de jetons en entrée et de 50 dollars par million en sortie. Opus 5.5 coûte 4 et 20 dollars.[2][1]
La présentation d’Astra par OpenAI cite aussi Jane Street, qui a constaté une nette amélioration par rapport à GPT-5.6 Sol dans des tests d’« intuition de trading » (trading intuition). Le produit d’OpenAI pour les services financiers dit également qu’Astra est fort pour chercher de l’information, raisonner sur la finance et produire des livrables.[2][3]
Ce serait donc du gâchis d’employer Astra pour ranger des fichiers CSV, corriger des dépendances, créer des données de test ou renommer des fichiers.
Ne donnez à Astra que les problèmes de recherche :
- Vous ne savez pas ce qui marche vraiment.
- Il y a beaucoup de caractéristiques possibles.
- Il y a beaucoup de combinaisons de conditions.
- Vous ne savez pas encore à quoi ressemble une bonne réponse.
- Il faut écarter un grand nombre d’hypothèses fausses.
Pas besoin d’une Formule 1 pour construire une route. Appelez la F1 quand le circuit existe.
3. La recherche inverse dans le carnet d’ordres part des mouvements de prix futurs et remonte le temps
La façon courante de concevoir une stratégie est de fixer d’abord une règle à la main : « si le RSI est bas, j’achète » ou « l’achat est épais dans le carnet, le prix va peut-être monter ».
La recherche inverse fait l’inverse.
D’abord, on repère automatiquement les moments où le prix a bougé plus que les frais et l’écart (spread) à 500 millisecondes, 1 seconde, 3 secondes ou 5 secondes. Ensuite, on revient au carnet d’ordres et aux transactions juste avant ces moments pour voir ce qu’ils avaient en commun.
Voici quelques indices possibles :
- les volumes près du meilleur prix d’achat et de vente
- le déséquilibre sur plusieurs niveaux de prix
- le sens et la force des ordres au marché
- le déséquilibre du flux d’ordres (order-flow imbalance)
- le rapport entre ordres annulés et ordres ajoutés
- la vitesse à laquelle le carnet se remplit de nouveau
- l’écart qui s’élargit ou se resserre
- la façon dont le carnet se rétablit après une transaction
- la différence entre le microprix et le prix moyen
- le type de volatilité du moment
- l’heure de la journée
- l’ordre des événements à l’échelle de quelques centaines de millisecondes
Cont, Kukanov et Stoikov ont montré que les variations de prix sur de courtes durées sont liées plus fortement au déséquilibre du flux d’ordres près des meilleurs prix qu’au simple volume échangé, et que cet effet dépend aussi de la profondeur du marché.[4]
Le carnet d’ordres n’est donc pas une photo figée du genre « l’achat est épais, donc ça monte ». C’est une suite d’événements dans le temps : nouveaux ordres, annulations, ordres au marché et remplissages.
C’est cette partie qui mérite d’être explorée par Astra.
4. Mais « j’ai essayé 100 idées et la meilleure a gagné » peut être une loterie de surapprentissage, pas un Graal
Le plus grand piège de l’exploration par IA est que plus elle est intelligente, plus elle peut tester de stratégies.
Bailey et ses collègues ont étudié ce problème : si l’on teste un très grand nombre de candidates dans un backtest et qu’on retient la meilleure, on risque fort de choisir une stratégie qui n’avait l’air bonne que par hasard sur ces données.[5]
Donc, quand Astra trouve 10 000 conditions et dit « celle-ci est la meilleure », il faut se méfier davantage, pas moins.
Une recherche inverse devrait au minimum :
- Séparer la période de recherche de la période d’évaluation finale.
- Ne pas se fier uniquement à des découpages aléatoires qui brisent l’ordre du temps.
- Ne pas revenir sans cesse sur la même période pour ajuster les conditions.
- Noter combien d’idées ont été testées.
- Vérifier que les résultats tiennent dans différents types de marché.
- Évaluer les résultats après frais et écart.
- Contrôler qu’aucune information du futur ne s’est glissée dedans.
Ici, Opus 5.5 joue le rôle de relecteur dont le travail est de démolir ce qu’Astra trouve.
Astra découvre. Opus doute.
Une équipe de recherche fonctionne mieux quand ses membres ne sont pas tout à fait d’accord entre eux.
5. Le plus effrayant dans un backtest de carnet d’ordres : auriez-vous vraiment été exécuté à ce prix ?
En scalping, voir un prix sur le graphique n’est pas la même chose que voir son ordre exécuté à ce prix.
Un ordre à cours limité a une place dans la file d’attente. La probabilité d’exécution dépend du nombre d’ordres devant vous, du nombre d’ordres opposés qui arrivent et de l’annulation éventuelle des ordres qui vous précèdent.
Une étude publiée dans Management Science en 2025 examine comment des retards aléatoires peuvent changer l’ordre de la file, même pour des ordres limités envoyés presque au même moment.[6] Une recherche récente sur le marché des cryptomonnaies signale aussi qu’il y a un délai entre le moment où l’on voit le carnet et celui où l’ordre arrive au moteur d’appariement. Du coup, on ne peut parfois pas prendre le volume qu’on avait vu. C’est ce qu’on appelle un échec d’exécution (failure-to-fill), et il influence les backtests à haute fréquence.[7]
Le simulateur doit donc gérer au moins :
- les frais
- l’écart (spread)
- le glissement de prix (slippage), c’est-à-dire la différence entre le prix attendu et le prix obtenu
- la latence
- la position dans la file
- les exécutions partielles
- le délai d’annulation
- les ordres rejetés et les échecs d’exécution
- l’antisélection, c’est-à-dire le fait de traiter justement avec ceux qui en savent plus que vous
Sinon, plus Astra explore bien, plus vite vous fabriquez de magnifiques profits imaginaires.
Une IA plus intelligente avec un simulateur d’exécution bâclé, c’est une Ferrari avec des pneus en carton.
6. Qui fait quoi : Opus gère l’usine, Astra le laboratoire
En pratique, ce partage est facile à suivre :
| Tâche | Responsable principal |
|---|---|
| Collecter les données du carnet d’ordres et des transactions | Opus 5.5 |
| Corriger les trous, synchroniser les heures, normaliser | Opus 5.5 |
| Mettre en place Parquet, les bases de données et le magasin de caractéristiques | Opus 5.5 |
| Programmer le backtester et le modèle d’exécution | Opus 5.5 |
| Tests, protection contre les régressions et journaux | Opus 5.5 |
| Préparer la variable cible et l’espace de recherche | Opus 5.5 + une personne |
| Recherche inverse de caractéristiques et de conditions inconnues | Astra |
| Générer des hypothèses et explorer des groupes | Astra |
| Vérifier l’usage d’informations du futur (look-ahead / fuite de données) | Opus 5.5 |
| Tenter de réfuter le surapprentissage et la dépendance au type de marché | Opus 5.5 |
| Reprogrammer les candidates et refaire les tests à grande échelle | Opus 5.5 |
| Choisir la prochaine question de recherche | Opus 5.5 → Astra |
Anthropic dit clairement qu’Opus 5.5 est un modèle de tous les jours pour la programmation, les agents, l’utilisation de l’ordinateur et les tâches qui passent par plusieurs applications.[1]
OpenAI, de son côté, présente Astra comme son modèle le plus puissant pour le raisonnement complexe, la programmation, l’utilisation de l’ordinateur et la recherche.[2]
Comme leurs capacités se recoupent, la bonne conception n’est pas « celui qui peut le faire s’occupe de tout », mais « n’appeler le plus coûteux que lorsque c’est vraiment nécessaire ».
7. Laisser Opus piloter Chrome pour utiliser Astra convient pour un prototype ; en production, une API est plus propre
Voici un montage où une IA en utilise une autre. Opus 5.5, avec la permission de contrôler un navigateur, ouvre l’écran de discussion d’Astra et :
- envoie une tâche d’exploration
- vérifie qu’elle est terminée
- récupère le résultat
- essaie de le réfuter de son côté
- envoie la recherche suivante si ce n’est pas suffisant
Comme prototype, c’est très facile à comprendre.
Anthropic cite l’utilisation de l’ordinateur parmi les principaux usages d’Opus 5.5. Avec un navigateur ou un système de contrôle de l’ordinateur adapté, il peut diriger un travail en plusieurs étapes comme celui-ci.[1]
Mais une fois la routine bien établie, une API est en général plus facile à utiliser qu’un passage par l’écran.
Passer par le navigateur apporte des problèmes comme :
- la session de connexion qui expire
- les changements de l’interface
- l’état des boutons qui prête à confusion
- la difficulté de savoir s’il génère encore ou s’il est bloqué
- une partie de la réponse qui se perd
- une conversation qui devient trop longue
- le navigateur lui-même qui plante
Avec une API, on peut enregistrer de façon structurée l’identifiant de l’expérience, l’empreinte (hash) des données d’entrée, la version du prompt, la sortie et les résultats d’évaluation.
L’ordre naturel est donc :
D’abord, automatiser dans Chrome ce que ferait une personne, pour voir si ça vaut la peine. Quand la boucle de recherche est solide, passer à une API.
Inutile de construire une fusée au début. Attachez d’abord une fusée à un vélo et vérifiez que vous voulez vraiment aller dans cette direction.
8. Le but n’est pas de « faire réfléchir Astra », mais de « ne lui donner que des problèmes qui valent sa réflexion »
La pire configuration consiste à balancer à Astra une montagne de données brutes et du code cassé en disant :
« Trouve-moi une stratégie rentable. »
La bonne configuration est l’inverse. Du côté d’Opus 5.5, il faut :
- garantir la qualité des données
- créer un environnement d’expérience reproductible
- fournir une API de recherche
- définir ce qu’est la réussite
- intégrer un modèle de coûts
- automatiser les contrôles de fuite de données
- enregistrer les résultats
- tester les candidates renvoyées par Astra avec une vérification séparée qui cherche à les réfuter
Seulement ensuite, on demande à Astra de creuser là où personne n’a encore pensé à une caractéristique.
Le flux de travail devient alors :
Opus 5.5 construit la base → Astra explore l’inconnu → Opus 5.5 essaie de casser le résultat → seul ce qui survit passe à l’étape suivante.
Il ne s’agit pas de tout confier à une seule IA géniale.
Laissez le chercheur chercher et le chef de chantier diriger le chantier.
Même à l’ère des agents IA, ce qui marche le mieux au bout du compte, c’est la façon d’organiser l’équipe.
Références (7)
- Anthropic — „Introducing Claude Opus 5.5“ und Produktseite zu Claude Opus (22.09.2026) https://www.anthropic.com/claude/opus Belegt die Einordnung von Opus 5.5 bei agentischem Programmieren, langen Arbeiten, Computernutzung und Abläufen über mehrere Anwendungen, außerdem Preise und die rund 40 % geringeren Kosten typischer, nach Token abgerechneter Arbeiten im Vergleich zu Opus 5 anthropic.com
- OpenAI — „GPT-6 Astra: A new generation of intelligence“ und API-Modellseite zu GPT-6 Astra (09/2026) https://developers.openai.com/api/docs/models/gpt-6-astra Belegt die offizielle Einordnung von Astra, die API-Preise und das Zitat von Jane Street zu Fortschritten bei „Trading Intuition“-Tests gegenüber GPT-5.6 Sol openai.com
- OpenAI — „Introducing ChatGPT for Financial Services“ (10.09.2026) Belegt die Einordnung von Astra bei Informationssuche, Finanzanalyse und der Erstellung fertiger Ergebnisse openai.com
- Cont, Rama; Kukanov, Arseniy; Stoikov, Sasha — „The Price Impact of Order Book Events“, Journal of Financial Econometrics 12(1), 2014 Belegt den Zusammenhang zwischen kurzfristigen Kursänderungen, dem Ungleichgewicht im Orderfluss und der Markttiefe arxiv.org
- Bailey, David H.; Borwein, Jonathan M.; López de Prado, Marcos; Zhu, Qiji Jim — „The Probability of Backtest Overfitting“, Journal of Computational Finance https://doi.org/10.21314/jcf.2016.322 Belegt das Risiko, dass die Auswahl des besten Ergebnisses nach dem Test vieler Strategiekonfigurationen einen überangepassten Gewinner liefert escholarship.org
- Yueshen, Bart Zhou — „Queuing Uncertainty of Limit Orders“, Management Science, online veröffentlicht am 17.09.2025 Belegt die Unsicherheit der Position in der Warteschlange und zufällige Verzögerungen bei fast gleichzeitigen Limit-Orders pubsonline.informs.org
- „The good, the bad, and latency: exploratory trading on Bybit and Binance“, Quantitative Finance, 2025 Belegt Latenz, nicht ausgeführte Orders, Slippage, Adverse Selection und Fragen bei Hochfrequenz-Backtests doi.org
