Notre parcours dans l’intelligence artificielle.

Nous voulions préparer les données, entraîner nos modèles et obtenir leurs sorties dans notre environnement Python. Notre propre IA désignait des modèles spécialisés pour des questions numériques, pas un modèle de langage général entraîné de zéro, qui demanderait une autre échelle de moyens.

Le travail a précisé les choix : une bougie, une suite d’observations ou un tableau de variables ? Une direction ou une plage de valeurs ? Nous avons dû définir les cibles, organiser les entrées et conserver des transformations cohérentes.

Nous avons exploré LSTM pour les séquences, les arbres pour les variables construites et Prophet pour les séries temporelles. Plus tard, nous avons envoyé du contexte par API à des modèles déjà entraînés et abordé les images par la vision locale.

Nous avons gardé une distinction : local indique où le calcul se fait, sans dire s’il apprend des nombres, interprète du texte ou détecte des objets. Chaque branche répond à une tâche particulière.

Nous voulions que le modèle voie l’évolution des mesures au lieu d’isoler la dernière bougie. Les LSTM traitent les observations dans l’ordre avec un état interne. Nous avons préparé des fenêtres glissantes.

Les modèles archivés utilisent 30 observations de 689 variables chacune. Ce sont des dimensions historiques de recherche, pas des presets de trading. Il fallait conserver l’ordre des colonnes et le scaler associé.

Nous avons aussi défini les trois classes. Horizon et règles de labellisation donnent leur sens à baisse, neutre et hausse. Changer ces règles change la question même si le réseau reste identique.

Nous avons travaillé avec une version compacte et une autre empilée plus grande. Leurs trois scores décrivent des classes, pas tout un chemin de prix. Liste de variables, transformations et cible sont devenues aussi importantes que le réseau enregistré.

Deux mouvements haussiers peuvent différer fortement par leur taille et leur parcours. Nous avons exploré la régression pour exprimer des quantités, avec deux sorties plutôt que trois scores de classes.

Les variantes archivées utilisent 240 variables et des fenêtres de 30 ou 60 observations, avec LSTM empilés et composants apparentés à l’attention. Ces choix modifient l’histoire fournie et sa représentation, sans définir automatiquement les unités des sorties.

Nous avons traité l’échelle d’entrée et la restitution des unités en sortie. D’autres scripts utilisent un sélecteur enregistré et une entrée LSTM à un seul pas : une formulation distincte. Les rapports rapprochent différences maximales et minimales observées et prédites.

L’étude du range nous a aussi amenés à l’ordre des événements. Les mêmes extrêmes peuvent être atteints dans l’ordre inverse. L’illustration rappelle pourquoi deux limites ne reconstruisent pas tout le parcours.

Notre travail a aussi porté sur les arbres, dont XGBoost et CatBoost. Leur partition des variables diffère d’un LSTM qui lit une histoire ordonnée, même si les mesures proviennent du même marché.

Nous avons développé des services chargeant plusieurs familles via une interface commune. Cela facilite leur examen, mais ne prouve ni la bonne façon de les combiner ni la supériorité d’un ensemble.

Une interface utilisait les percentiles 20, 50 et 80. Le milieu est la médiane ; entre 20 % et 80 %, la couverture centrale nominale vaut 60 % si les quantiles sont calibrés. Ce n’est pas une garantie de confiance de 80 %.

Nous pouvions ainsi distinguer une classe, une estimation ponctuelle et une bande de quantiles. Nous choisissons la sortie selon la question plutôt que de considérer tous les scores comme interchangeables.

Après les matrices et fenêtres, nous avons exploré une formulation plus directe. Notre script Prophet utilisait des observations XAUUSD toutes les 15 minutes et demandait cinq observations futures.

Prophet apporte tendance et composantes saisonnières facultatives. Cinq pas de 15 minutes donnent 75 minutes pendant une séance continue. Fermetures et données absentes doivent encore être traitées : cinq lignes ne représentent pas toujours du temps ininterrompu.

Nous avons aussi conservé un rapport étiqueté ARIMAX avec différences extrêmes observées et prédites. ARIMAX associe structure autorégressive et variables externes. Le rapport ne révèle pas tous les choix de modélisation ; nous ne les inventons pas à partir du nom.

Passer d’une approche à l’autre a changé nos questions. Nous choisissons l’histoire de variables fournie au réseau ; un modèle de série intègre la structure temporelle dans sa formulation. Dans les deux cas, “plus tard” doit être défini.

Les API nous donnaient accès à des modèles déjà entraînés par leurs fournisseurs. Notre travail portait sur les informations réunies, leur sélection et la question à laquelle nous voulions pouvoir revenir.

Notre pipeline Python assemblait bougies MT5 M5, M15 et M30, tick actuel et publications publiques d’analystes datées. Nous distinguions prix observés et commentaires interprétatifs. Sources et horaires comptaient face à des avis divergents.

Nous demandions du JSON avec scénarios, conditions, invalidation et option sans trade. La structure facilite le traitement, mais ne valide pas le contenu. Le script enregistrait et affichait la réponse : un flux contexte-réponse, pas la preuve d’un contrôleur d’exécution complet.

Cette branche nous a montré qu’un travail substantiel existe autour d’un modèle que nous n’avons pas entraîné. Choisir les éléments, formuler la demande et conserver le retour sont des tâches à part entière.

En lisant une courbe, nous voyons des relations spatiales entre bougies, mouvements et structures. Nous voulions étudier cette représentation, d’où notre exploration locale avec YOLOv8.

Un détecteur localise et classe des objets visibles avec des boîtes et des scores. Il nous fallait réfléchir aux structures annotables de façon cohérente. Détecter une forme diffère d’expliquer une image ou de prévoir un prix.

Zoom, découpage, largeur des bougies, couleurs et annotations changent les pixels. Nous devions distinguer présentation et information de marché. Les exemples sans la structure recherchée comptent également.

Le détecteur parle en pixels ; le trading parle en prix et en temps. Échelle et coordonnées relient les deux. Cela fait de la vision une branche avec son propre travail de préparation et d’interprétation.

MT5 portait les observations et la logique de trading, Python les bibliothèques et modèles. Les connecter demandait un accord sur les données transmises et sur le sens du retour, au-delà d’une liste de nombres.

Nous avons développé plusieurs services d’inférence combinant LSTM, arbres et quantiles. Ils préparent les entrées et renvoient des sorties. Ce travail se distingue de l’entraînement, chaque modèle attendant une organisation particulière.

La liste des variables conserve le sens des colonnes, le scaler d’entrée la transformation et celui de sortie les unités. Version, longueur de séquence, instrument et unité doivent correspondre. Recevoir une réponse ne prouve pas cette cohérence.

Nous avons donc regardé le modèle comme un ensemble complet. L’architecture publique explique les liens, tandis que les adresses de services, connexions de comptes et réglages restent privés.

On peut montrer un réseau ou une prédiction, mais beaucoup d’effort se trouvait autour. Nous avons préparé tables de variables avec heure et OHLC, cibles séparées, extractions et exports pour organiser les branches.

Un script recharge un sélecteur avant l’entrée LSTM ; un autre la liste nommée de XGBoost. Tous deux conservent heure et champ de référence avec deux sorties. Un utilitaire extrait une portion bornée vers un fichier de travail.

CSV et Excel permettent d’examiner les résultats hors du code. Certains exports contiennent des prédictions, d’autres les différences maximales et minimales observées à côté. UTF-16 et UTF-8 demandaient aussi de l’attention. Nous partageons la structure, pas les lignes privées ni des taux déduits des noms.

Nous retrouvons le même fil : garder de quoi comprendre l’origine d’une réponse. En local, données et transformations ; chez un fournisseur, sources, prompt et retour. Dans les deux cas, l’output a besoin de contexte.