Trading OS : construire un contexte de marché explicable avant de parler d’intelligence

Le projet a changé de nature

La première fois que j’ai présenté Trading OS, je le décrivais surtout comme un assistant de trading discrétionnaire : un endroit où centraliser les données de marché, les comptes broker, les règles de risque, la préparation, l’exécution contrôlée et l’analyse des trades.

Cette description reste juste, mais elle ne dit plus vraiment où se situe le travail important.

Trading OS n’est pas devenu un bot autonome. Il ne prédit pas le marché et ne prend pas les décisions à la place du trader. En revanche, le projet possède maintenant un premier parcours PAPER complet et une fondation de contexte de marché beaucoup plus précise. L’enjeu n’est plus seulement de faire circuler des données entre des services. Il est de savoir quelles observations peuvent être produites, avec quelles preuves, dans quelles limites et avec quelle autorité.

Ce qui est maintenant réellement parcourable

Le dernier parcours validé concerne un trader authentifié travaillant sur un compte PAPER. Le chemin est le suivant :

compte PAPER
    → contexte de décision et marché éligible
    → TradePlan MANUAL
    → acceptation humaine
    → Risk déterministe
    → autorisation explicite
    → exécution simulée
    → position persistée et valorisée
    → fermeture complète
    → historique conservé

Ce flux passe par l’interface officielle. Il ne nécessite ni identifiant fabriqué, ni mutation directe de la base, ni appel caché au broker.

Le résultat est important pour une raison très pratique : il permet de distinguer une architecture prometteuse d’un parcours réellement utilisable. Le plan manuel reste relié au compte et au marché sélectionnés. Le moteur de risque garde son rôle. L’exécution PAPER produit une position persistée, qui survit au rechargement, puis peut être fermée dans le parcours normal.

Cela ne constitue pas une validation LIVE, encore moins une preuve de rentabilité. C’est une validation de chaîne et d’autorité : les étapes critiques existent et leurs frontières peuvent être vérifiées.

Pourquoi les bougies ne suffisent pas

Un historique OHLC peut sembler être une matière première suffisante pour parler de contexte. En pratique, transmettre une liste de bougies ne dit pas tout ce dont une analyse structurée a besoin.

Il faut aussi savoir :

  • quel rôle joue chaque série — BIAS, SETUP ou TRIGGER ;

  • quel intervalle et quel cut-off ont été utilisés ;

  • si une bougie est clôturée ou encore ouverte ;

  • si elle est réelle ou synthétique ;

  • quelles lacunes ou anomalies ont été détectées ;

  • quelle est la fraîcheur de la donnée ;

  • quelle source et quelle version de règles soutiennent le résultat.

Sans ces informations, une analyse peut confondre une absence de données avec une absence de signal, ou traiter une bougie reconstruite comme une observation de marché ordinaire.

La Story 0062 a donc introduit un contrat dédié TrendContextAssessmentInput. L’objectif est de conserver ces propriétés à la frontière du domaine, sans transformer le modèle générique d’historique en fourre-tout spécialisé.

Flux explicable du contexte de marché vers l’observation

Un moteur déterministe avant l’IA

La Story 0063 implémente un moteur Trend Context pur. Il ne dépend ni de Spring, ni d’une base, ni d’un broker, ni d’un modèle de langage. Il reçoit un input immuable et produit une évaluation rejouable.

Le moteur couvre notamment :

  • les pivots confirmés et la suppression des swings concurrents ;

  • les relations HH, HL, LH et LL ;

  • les niveaux protégés et les cassures confirmées ;

  • la distinction entre une cassure par mèche et une cassure structurelle ;

  • les transitions et les reprises de structure ;

  • l’évaluation des pullbacks ;

  • les éléments de support EMA et ATR ;

  • l’alignement BIAS / SETUP / TRIGGER ;

  • des issues d’attention conservatrices.

Ce vocabulaire ne constitue pas encore une stratégie complète. Il décrit un contexte et ses findings. Le moteur ne crée pas de TradePlan, ne calcule pas une décision de Risk et n’envoie pas d’ordre.

Les 24 scénarios canoniques du domaine sont couverts par des tests dédiés, avec des invariants de replay et de non-look-ahead. Deux exécutions identiques doivent rester identiques ; une donnée située après le cut-off ne doit pas pouvoir modifier une évaluation passée.

De l’analyse à une observation durable

La Story 0064 fait entrer ce moteur dans l’architecture Market Intelligence existante. Le pipeline devient :

Market Data
    ↓
TrendContextAssessmentInput
    ↓
moteur déterministe
    ↓
IntelligenceObservation typée
    ↓
contrat de lecture authentifié

L’observation conserve son identité, sa lignée, sa validité, ses références de source, son fingerprint, son cut-off et les versions du profil et des règles. Une nouvelle preuve matérielle produit une nouvelle version ou une supersession ; elle ne réécrit pas silencieusement l’historique.

Le contrat de lecture distingue aussi une évaluation courante d’une dernière évaluation réussie. Un échec opérationnel ne doit pas être présenté comme une observation fraîche, et l’absence d’une nouvelle donnée ne doit pas effacer la possibilité d’auditer l’état précédent.

Le résultat CONTEXTUALLY_ATTRACTIVE reste une observation analytique. Il ne déclenche pas automatiquement une opportunité, un TradePlan, une décision Risk ou une exécution. Cette séparation est probablement moins spectaculaire qu’un bouton « trade », mais elle est beaucoup plus importante pour garder une architecture gouvernable.

Les frontières entre les autorités

Trading OS s’organise progressivement autour d’une répartition explicite :

Couche Autorité
Market Data faits de marché, sources, fraîcheur et état des données
Market Intelligence analyses, observations, provenance et réutilisation
Risk règles déterministes et verdict d’éligibilité
Trader acceptation du plan et autorisation d’exécution
Broker Service capacités du broker et soumission technique

Chaque couche enrichit le contexte sans absorber la responsabilité de la suivante. Une observation favorable n’est donc pas une autorisation. Une intention d’exécution n’est pas un ordre broker. Une position PAPER persistée n’est pas une preuve de comportement LIVE.

Cette distinction entre fait, analyse, autorisation et action est la partie la plus structurante du projet.

Ce que l’IA n’a pas encore le droit de faire

Le repository décrit encore un AI Engine désactivé. Aucun résultat IA fictif n’est produit pour donner l’impression que le système est plus avancé qu’il ne l’est. Le News Service, le Passive Scanner, l’Active Scanner UI et le monitoring des positions restent également des composants prévus, pas des fonctionnalités acquises.

Ce choix est volontaire. Je préfère brancher plus tard une IA sur un contexte inspectable plutôt que de lui demander de reconstruire une vérité à partir de données ambiguës.

L’IA pourra interpréter et expliquer des informations structurées. Elle ne devra pas contourner le Risk Domain, changer les règles d’éligibilité ou exécuter un ordre sans autorisation humaine explicite.

Ce que cela change pour la suite

La prochaine difficulté ne sera pas d’ajouter immédiatement davantage de sophistication. Elle sera de préserver ces contrats lorsque le projet commencera à produire des stratégies, des opportunités et des analyses plus riches.

Il faudra notamment éviter trois raccourcis :

  1. confondre une observation de contexte avec une stratégie ;

  2. transformer un classement analytique en décision de trading ;

  3. faire passer une suggestion générée par IA au-dessus des règles déterministes.

La fondation actuelle donne un endroit précis où placer ces futures capacités. Elle permet aussi de tester leurs limites sans faire varier en même temps l’identité des comptes, la provenance des données et l’autorité d’exécution.

État réel du projet

  • Implémenté : parcours MANUAL PAPER, exécution simulée persistée, contexte Trend Context, moteur déterministe, observations versionnées, lecture authentifiée et contrats broker-neutres.

  • Décidé : pas d’exécution autonome, pas de passage direct d’une analyse favorable vers une opportunité, et comportement fail-closed lorsque les données sont insuffisantes.

  • En attente : revue humaine finale et validation opérationnelle externe des Stories récentes.

  • Prévu : stratégie, opportunités, AI Engine réel, news, scanning et monitoring.

Conclusion

Trading OS avance, mais pas dans la direction d’un bouton magique.

Le projet sait maintenant faire vivre un parcours PAPER de bout en bout et produire un contexte de marché déterministe, versionné et relié à ses sources. Ces capacités ne disent pas encore quand acheter ou vendre. Elles rendent plutôt explicites les informations disponibles, les incertitudes et les frontières d’autorité.

C’est une étape moins visible que l’ajout d’une IA autonome, mais c’est celle qui rendra les prochaines étapes vérifiables. Avant de demander à un système d’être intelligent, il faut lui donner un contexte qui ne change pas de sens dès qu’on le relit.