Conclusion en cinq secondes : confiez à GPT-6 Astra la partie coûteuse et incertaine : découvrir des structures inconnues dans les données de carnet d’ordres et de transactions. Confiez à Claude Opus 5.5 tout ce qui rend cette recherche fiable : ingénierie des données, environnement expérimental, débogage, tests de régression, backtests, falsification et orchestration. Astra devient le chercheur coûteux ; Opus 5.5, le contremaître qui maintient l’atelier en marche.
1. Le plus impressionnant n’était pas une réponse brillante, mais le fait de continuer
Lors d’une longue session de maintenance logicielle, un bon agent ne s’est pas contenté de corriger une panne.
Il a isolé un test dépendant du runtime via l’injection de dépendances, réécrit un test encore attaché à un contrat abandonné, réparé un audit qui n’avait pas suivi la migration vers un validateur partagé, puis trouvé un fixture manquant qui bloquait le vrai build. Ensuite, il a relancé tous les tests et le build.
Ce comportement vaut souvent plus qu’une réponse géniale isolée.
Le coût caché des agents est fréquemment la « taxe de réactivation humaine » :
- trouver un problème ;
- corriger une couche ;
- découvrir un autre échec ;
- s’arrêter à « ensuite, vérifiez… » ;
- attendre qu’un humain dise « continue ».
Anthropic positionne Opus 5.5 pour le coding de longue durée, les grandes codebases et les agents complexes utilisant plusieurs outils avec peu de supervision. Anthropic indique aussi un coût d’environ 40% inférieur à Opus 5 sur les workloads typiques facturés au token.[1]
En production, relier diagnostic, modification, vérification, réparation et clôture compte autant que résoudre une question difficile.
2. Astra devient-il inutile ? Au contraire : la spécialisation le rend plus rentable
OpenAI présente GPT-6 Astra comme son modèle le plus puissant pour les tâches end-to-end les plus difficiles. Son tarif API est de 10 dollars par million de tokens d’entrée et 50 dollars en sortie, contre 4 et 20 dollars pour Opus 5.5.[2][1]
La page de lancement d’Astra cite également Jane Street, qui rapporte un progrès clair par rapport à GPT-5.6 Sol sur des évaluations de « trading intuition ». Le produit Financial Services d’OpenAI présente Astra comme fort en recherche d’information, raisonnement financier et génération d’artefacts.[2][3]
Il est donc peu rationnel d’utiliser cette inférence premium pour nettoyer des CSV, réparer des dépendances ou créer des fixtures.
Astra devient intéressant quand :
- on ne sait pas encore quelles variables comptent ;
- l’espace de features est large ;
- les combinaisons explosent ;
- la forme de la réponse est inconnue ;
- il faut éliminer beaucoup d’hypothèses plausibles.
On ne goudronne pas une route avec une Formule 1.
3. La recherche inversée en scalping part du mouvement futur et remonte vers le carnet
Une stratégie classique commence par une règle humaine : « RSI bas, achat », ou « davantage de profondeur côté bid, donc peut-être une hausse ».
La recherche inversée commence à l’autre bout.
On identifie d’abord les fenêtres où le prix a bougé assez, en 500 ms, 1 s, 3 s ou 5 s, pour dépasser spread et frais. Puis on remonte dans les événements de carnet et de transactions juste avant ces fenêtres afin de chercher des structures communes.
Variables candidates :
- profondeur best bid / ask ;
- déséquilibre multi-niveaux ;
- direction et intensité des market orders ;
- order-flow imbalance ;
- ratio cancel / add ;
- vitesse de replenishment ;
- expansion et compression du spread ;
- récupération du carnet après transaction ;
- microprice vs mid-price ;
- régime de volatilité ;
- moment de la journée ;
- ordre des événements sous la seconde.
Cont, Kukanov et Stoikov montrent qu’à court horizon, les variations de prix sont fortement liées à l’order-flow imbalance autour du best bid et ask, avec un impact qui dépend aussi de la profondeur du marché.[4]
Le carnet n’est pas une photographie. C’est un flux d’ordres, d’annulations, d’agressions et de replenishment.
C’est précisément là qu’Astra mérite d’être utilisé.
4. Mais « nous avons testé 10 000 règles et celle-ci gagne » peut être une loterie d’overfitting
Plus l’IA est puissante, plus elle peut tester de stratégies. Cette puissance crée un risque statistique.
Bailey et ses coauteurs étudient le backtest overfitting : quand on teste de nombreux candidats puis qu’on choisit le meilleur résultat in-sample, le gagnant peut n’être qu’un mirage statistique.[5]
Si Astra explore des milliers de combinaisons et annonce « c’est la meilleure », l’exigence de validation doit augmenter.
Au minimum :
- séparer découverte et évaluation finale ;
- respecter la structure temporelle ;
- ne pas optimiser en boucle sur le même holdout ;
- enregistrer le nombre d’hypothèses testées ;
- valider sur plusieurs régimes ;
- inclure frais et spread ;
- auditer les fuites d’information future.
Ici Opus 5.5 devient le reviewer hostile.
Astra découvre. Opus essaie de casser la découverte.
Une équipe de recherche peut bénéficier d’un peu de conflit.
5. La question la plus dangereuse d’un backtest de scalping : « auriez-vous réellement été exécuté à ce prix ? »
Voir un prix ne signifie pas obtenir une exécution à ce prix.
Une limit order possède une queue position. La probabilité de fill dépend du volume devant vous, du flux opposé et des annulations qui modifient votre place.
Un article de Management Science de 2025 étudie l’incertitude de file causée par les latences aléatoires entre limit orders envoyées presque au même moment.[6] Des travaux empiriques récents sur les marchés crypto montrent également que le délai entre l’observation du carnet et l’arrivée au matching engine peut provoquer des failure-to-fill et fausser des backtests haute fréquence.[7]
Un simulateur sérieux doit au minimum modéliser :
- frais ;
- spread ;
- slippage ;
- latence ;
- queue position ;
- partial fills ;
- latence d’annulation ;
- rejet ou failure-to-fill ;
- adverse selection.
Sinon, une IA plus intelligente fabriquera simplement des profits fictifs plus vite.
Une Ferrari avec des pneus en carton reste une mauvaise voiture.
6. Répartition propre : Opus gère l’usine, Astra le laboratoire
| Travail | Responsable principal |
|---|---|
| Capturer carnet et transactions | Opus 5.5 |
| Gaps, synchronisation, normalisation | Opus 5.5 |
| DB / Parquet / feature store | Opus 5.5 |
| Backtester et modèle d’exécution | Opus 5.5 |
| Tests, régressions, logs | Opus 5.5 |
| Définir objectifs et frontières | Opus 5.5 + humain |
| Recherche inversée de features inconnues | Astra |
| Génération d’hypothèses et clusters | Astra |
| Contrôle look-ahead / leakage | Opus 5.5 |
| Réfutation de l’overfitting et des régimes | Opus 5.5 |
| Revalidation massive des survivants | Opus 5.5 |
| Préparer la prochaine question | Opus 5.5 → Astra |
Anthropic décrit Opus 5.5 comme un daily driver pour coding, agents, computer use et workflows complexes multi-applications.[1] OpenAI positionne Astra pour le raisonnement complexe, coding, computer use et research.[2]
Comme leurs capacités se recouvrent, la bonne optimisation n’est pas « qui peut le faire ? », mais « où l’intelligence premium vaut-elle son coût ? »
7. Laisser Opus piloter Chrome pour utiliser Astra est très bien en prototype ; l’API est plus propre quand la boucle se stabilise
Un Opus doté d’un accès navigateur peut :
- ouvrir Astra ;
- envoyer une tâche de recherche ;
- détecter la fin ;
- récupérer le résultat ;
- tenter de le réfuter ;
- envoyer la tâche suivante.
C’est un moyen rapide de prototyper « une IA qui utilise une autre IA ». Opus 5.5 est officiellement positionné pour le computer use et les tâches multi-applications avec un harness adapté.[1]
Pour des exécutions répétées, une API est généralement plus fiable.
Le navigateur ajoute : expiration de session, changements d’UI, état ambigu des boutons, difficulté à distinguer « génération en cours » de « bloqué », perte de sortie, contexte qui gonfle et crash navigateur.
Avec une API, experiment ID, hash d’entrée, version de prompt, sortie et évaluation peuvent être stockés de manière structurée.
Chemin naturel :
prouver la valeur par automatisation navigateur → stabiliser la boucle → migrer vers des jobs API.
Inutile de construire un vaisseau spatial avant de confirmer la destination.
8. L’architecture finale n’est pas « laisser Astra réfléchir », mais « ne lui donner que des problèmes dignes d’Astra »
Le mauvais design consiste à jeter du code cassé et des données brutes dans Astra en disant « trouve une stratégie rentable ».
Le bon design fait préparer par Opus 5.5 :
- la qualité des données ;
- un environnement reproductible ;
- une interface de recherche bornée ;
- des métriques de succès ;
- un modèle de coûts ;
- des checks automatiques de leakage ;
- la persistance des résultats ;
- une falsification indépendante.
Ensuite seulement Astra reçoit la partie réellement inconnue.
La boucle devient :
Opus construit le terrain → Astra explore l’inconnu → Opus essaie de casser le résultat → seuls les survivants avancent.
Ne demandez pas à un génie de devenir toute l’entreprise.
Le chercheur recherche. Le contremaître fait tourner l’atelier.
Même à l’ère des agents, le design organisationnel reste décisif.
Sources
- Anthropic — “Introducing Claude Opus 5.5” / Claude Opus model page (2026-09-22) https://www.anthropic.com/claude/opus Used for Opus 5.5 positioning around agentic coding, long-running work, computer use, multi-application workflows, pricing, and the roughly 40% lower typical token-billed workload cost compared with Opus 5 anthropic.com
- OpenAI — “GPT-6 Astra: A new generation of intelligence” and GPT-6 Astra API model page (2026-09) https://developers.openai.com/api/docs/models/gpt-6-astra Used for Astra’s official positioning, API pricing, and the Jane Street quotation concerning progress on trading-intuition evaluations versus GPT-5.6 Sol openai.com
- OpenAI — “Introducing ChatGPT for Financial Services” (2026-09-10) Used for Astra’s positioning in financial information retrieval, financial reasoning, and artifact generation openai.com
- Cont, Rama; Kukanov, Arseniy; Stoikov, Sasha — “The Price Impact of Order Book Events,” Journal of Financial Econometrics 12(1), 2014 Used for the relationship between short-horizon price changes, order-flow imbalance, and market depth 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 Used for the risk that selecting the best result after testing many strategy configurations can produce an overfit winner escholarship.org
- Yueshen, Bart Zhou — “Queuing Uncertainty of Limit Orders,” Management Science, published online 2025-09-17 Used for queue-position uncertainty and random latency among near-simultaneous limit orders pubsonline.informs.org
- The good, the bad, and latency: exploratory trading on Bybit and Binance,” Quantitative Finance, 2025 Used for latency, failure-to-fill, slippage, adverse-selection, and high-frequency backtesting concerns doi.org
