J'ai donné 1000 euros à gérer à mon bot de trading AI

Les premiers résultats

J'ai laissé mon workflow agentique trader de manière autonome pendant trois mois. Sur cette période, il a obtenu une performance de [X %], supérieure à celle de son indice de référence le [indice de référence].

Ce résultat est encourageant, mais il doit être interprété avec prudence. Trois mois restent insuffisants pour évaluer sérieusement une stratégie d'investissement. Je vais donc continuer à faire tourner le système afin de mesurer sa robustesse dans différentes conditions de marché.

Pourquoi j'ai construit Deep Copy : le problème personnel

Depuis quelques années, je m'intéresse beaucoup aux problématiques de finance personnelle. Je suis pas mal la communauté autour de Finary, Matthieu Louvet avec s'Investir conseil, Matias Bacinos avec Trade Republic, Crésus sur YouTube. C'est un univers que j'affectionne tout particulièrement.

Malgré l'excellent travail de Finary et des autres, je me suis demandé si, avec mes compétences d'ingénieur et les outils IA tels que Claude Code, Codex, je pouvais sortir un SaaS en production avec une landing page, un backend Python capable d'automatiser le trading via un système agentique complet. C'est ainsi que mon application Deep Copy est née.

Avant cette application, tous les mois, je devais faire de la veille sur Twitter, YouTube, Spotify pour récupérer des idées d'actions, analyser les entreprises que j'avais sélectionnées et passer des ordres en bourse sur chacun de mes comptes si je jugeais que c'était le bon moment. J'ai donc décidé de lancer mon application boostée à l'IA, capable de fournir des analyses complètes et complètement autonome, pour voir ce que ça donne.

Ce que l'IA permet vraiment : prototype rapide vs produit fiable

Il y a quelques années, les développeurs pouvaient développer des side projects pendant plusieurs mois avant d'avoir une application qui termine soit à la poubelle, soit en prod. Aujourd'hui, n'importe qui est capable de lancer son projet. En 2018–2020, le rêve des développeurs, c'était d'avoir une application avec du revenu passif appelé MRR dans le milieu. On est passés du SaaS qui veut tout faire, pour tout le monde, avec l'objectif de scaler à tout prix, à des micro-SaaS ultra-ciblés, pensés pour résoudre des problèmes très personnels : planning de garde des enfants, gestion des courses.

Aujourd'hui, on ne construit plus forcément un produit pour le marché entier. On le construit d'abord pour soi, pour ses proches, puis pour ceux qui vivent exactement le même problème autour de nous.

Au départ, j'ai été surpris d'y passer un mois complet. Sur LinkedIn, on a souvent l'impression qu'il est désormais possible de sortir une application fonctionnelle en deux jours. En réalité, c'est vrai pour un prototype. Mais dès qu'on veut construire quelque chose de fiable, maintenable, sécurisé et réellement utilisable, le temps nécessaire augmente très vite.

Ce qui différencie mon application des autres, c'est l'intégration de l'IA de manière native et agentique. Au lieu de faire un énième service de recommandation comme il en existe partout sur Internet, mon application est capable de passer des ordres, de déclencher des analyses d'actions et de produire une stratégie adaptée à mon profil investisseur.

Les outils à ma disposition

Pour développer cette application, je me suis doté de plusieurs stagiaires Claude Code avec Opus 4.6/7/8 en effort low, mon préféré. Codex avec les modèles GPT5-Codex et GPT5.5, qui sont bluffants et viennent sérieusement concurrencer. Stitch pour la génération de maquettes, parce que je suis une merguez en UI/UX.

Les contraintes du projet

La plus grosse contrainte que j'ai, c'est mon temps : je réalise ça le midi et le soir, en parallèle de mon travail chez SFEIR. En complément, je souhaite documenter toutes les étapes, que ce soit via cet article ou sur LinkedIn. Je souhaite également que ce soit Open Source et que ma consommation Cloud reste raisonnable. On verra par la suite que les coûts peuvent exploser malgré nous. J'ai souhaité aller jusqu'au bout en exposant mon service sur Internet avec un nom de domaine, une CI/CD, une base de données et de vrais utilisateurs.

Mon background

5 ans d'expérience chez Décathlon comme Software Engineer Java à Lille et Singapour. Depuis plusieurs mois, j'ai fait le pari de migrer vers la GenAI chez SFEIR.

La stack technique

Côté front, j'ai choisi Next.js 16, React, Tailwind CSS. Je n'ai aucune connaissance en frontend : j'ai toujours réalisé des microservices backend-to-backend. Concernant le back, j'ai choisi Python, avec de la FastAPI, le framework Google ADK et LangGraph. Pour la persistance des données, j'ai utilisé mon bon vieux PostgreSQL ainsi que Redis, qui sont gratuits sur Aiven.

Architecture : DeepCopy + Momentum

L'application est composée de deux services distincts.

Le premier, dénommé DeepCopy, est une FastAPI qui inclut ADK. Ce service expose un workflow séquentiel de 4 agents :

• Market Scanner — un agent qui analyse le régime de marché (19 actifs : VIX, S&P 500, NASDAQ, Or, Pétrole, Bitcoin…) via Yahoo Finance sur 7 horizons temporels. Le résultat est caché dans Redis pour une durée de 24h.
• Portfolio Analyzer — un agent qui évalue les positions du client en récupérant les données live (soldes, positions, ordres) via le MCP IBKR (FastMCP, transport HTTP streamable).
• Stock Picker — un agent qui combine le régime de marché et l'analyse portfolio, consulte le MCP Momentum pour récupérer les analyses existantes, et produit des recommandations de trading à la demande.
• Order Executor — le dernier agent, qui exécute les ordres via les outils MCP IBKR (submit, modify, cancel). Au niveau de cet agent, il est important qu'il dispose des bonnes informations : il n'a pas besoin de connaître les ordres en cours. J'ai un mécanisme où, si un ordre est en cours, alors le Stock Picker qui produit un trading plan ne peut pas proposer ce ticker. L'Order Executor est un loop agent qui itère sur le trading plan.

Chaque utilisateur dispose d'un gateway IBKR dédié (conteneur Docker isolé, ~200 Mo RAM, login auto via Puppeteer + 2FA Challenge/Response).

Le second service, dénommé Momentum, est composé d'une FastAPI et de LangGraph. Il s'agit d'un service d'analyse multi-agents qui simule une salle de trading. La première équipe d'analystes gère les fondamentaux, le sentiment, les news. La seconde équipe est orientée recherche et débat : elle fait s'opposer deux agents, un Bull Researcher et un Bear Researcher, pour produire un scoring structuré composé d'une notation sur 5 niveaux : Buy / Overweight / Hold / Underweight / Sell.

Le système supporte plusieurs providers de LLMs comme OpenAI, Gemini, Claude, Grok, DeepSeek, Ollama. Un worker async avec job queue atomique (SELECT…FOR UPDATE) persiste toutes les analyses dans un PostgreSQL Aiven (schéma flat, pas de JSONB) avec les indicateurs techniques, les fondamentaux, le sentiment, les news, les propositions trader, les arguments du débat et les stats d'exécution token in/out.

DeepCopy accède aux analyses Momentum via le MCP Momentum (read-only : list_analyses, latest_analyses, get_analysis, get_recommendations). Les deux services partagent la même base PostgreSQL Aiven. Le coût d'une analyse pour le service Momentum, avec un modèle Gemini 3.1 et l'option de thinking, est de l'ordre de 40 centimes par analyse. Pour pouvoir analyser toutes les actions du S&P 500 et du CAC 40, j'ai A/B testé plusieurs configurations afin d'obtenir l'analyse la plus juste tout en gardant un coût réduit.

Le vrai apprentissage métier : ordres en attente, garde-fous, mémoire agentique

Au fur et à mesure du développement et des bugs rencontrés, j'ai dû ajouter des contraintes métier de plus en plus fortes.

Par exemple, imaginons que mon agent s'exécute cinq fois dans la journée alors que la place de marché est fermée. Les ordres générés ne sont donc pas exécutés immédiatement. À chaque run, l'agent refait la même analyse du portefeuille : il détecte qu'une action représente un pourcentage trop important de l'allocation globale, puis produit un ordre en attente pour réduire cette exposition.

Prenons un cas concret : je détiens 100 actions AAPL. L'agent génère un premier ordre de vente de 25 actions, puis un deuxième, un troisième et un quatrième. Comme le marché est fermé, ces ordres restent en attente et le portefeuille visible n'a pas encore changé. Au cinquième run, l'agent pourrait donc tenter de générer un nouvel ordre de vente de 25 actions.

À ce moment-là, IBKR refuserait l'ordre, car les 100 actions disponibles sont déjà couvertes par les ordres précédents. Même si elles apparaissent encore dans le portefeuille, elles ne sont plus réellement disponibles à la vente.

Pour éviter ce problème, j'ai ajouté une règle métier stricte : un TradingPlan ne peut être produit que sur des actions qui ne sont pas déjà concernées par un live_order en attente sur IBKR. Cela permet d'éviter les doublons, de prendre en compte les quantités déjà engagées, et de garantir que l'agent ne génère pas plusieurs fois le même ordre sur une position inchangée.

Autre exemple de problématique rencontrée sur le service Momentum : deux agents peuvent déclencher des jobs sur Momentum, le Portfolio Analyzer et le Stock Picker. Lorsqu'une analyse est lancée par un utilisateur, le nom du ticker ainsi que le job id sont sauvegardés dans Redis, dans une clé associée à cet utilisateur. L'objectif est que, lors du prochain run, l'agent puisse retrouver ce qu'il a demandé à analyser. Ainsi, mon agent est capable de se souvenir de ce qu'il a demandé lors du run précédent. L'analyse délivrée par le service Momentum est asynchrone et peut prendre jusqu'à 8 min ; à partir du moment où elle est terminée, elle est disponible pour tous les utilisateurs.

Pour les besoins spécifiques des agents, j'utilise également des callbacks. Ils interviennent avant les appels aux agents, aux modèles et aux tools, principalement pour gérer le logging et tracer précisément chaque étape d'exécution. Afin d'éviter une logique dispersée dans plusieurs endroits du code, j'ai uniformisé ce fonctionnement via un plugin. Cela me permet d'avoir un format de logs cohérent sur tout le workflow, quel que soit l'agent, le modèle ou le tool appelé.

À terme, l'architecture sera composée d'un seul framework, ADK2. Cette version est GA depuis peu ; elle est orientée graph à l'instar de LangGraph. Je pourrai ainsi migrer le service LangGraph vers ADK2 pour simplifier la maintenance de la codebase.

Infra, coûts, sécurité : IBKR, Docker, Redis, Postgres, kill switch budget

Concernant l'infrastructure, j'ai utilisé Terraform pour faire de l'Infrastructure as Code (IaC). J'ai eu plusieurs problématiques : pour avoir un service scalable et utiliser les APIs d'IBKR, je dois être capable de déployer un conteneur Java de 200 Mo par client, qui fait le pont entre mon application et les APIs. J'ai donc utilisé le SDK Docker pour déployer une gateway par client avec les sources, Puppeteer pour remplir les champs login/mot de passe, et une petite API dans chacun des conteneurs pour résoudre le challenge 2FA d'IBKR. Le code source n'étant pas fourni, j'ai eu très peu de marge de manœuvre.

Mon projet est composé également d'un PostgreSQL sur Aiven ainsi que d'un Redis. J'ai utilisé un projet GCP dédié à la partie infrastructure, qui s'arrête via une Cloud Function si le billing du projet associé est dépassé — merci à mon collègue pour le partage de ce mécanisme ! Ainsi, je m'évite une facture GCP à 20 k en cas de marketing agressif. Spoiler : l'infra va tomber avant, et c'est voulu.

Base de données

Mes deux applications distinctes écrivent dans la même base de données. Pour la maintenance, j'ai préféré faire ainsi, même si le mieux reste d'avoir un microservice avec sa propre base de données. Je dispose de 1 Go de stockage ; le jour où je serai limité, je passerai sur un plan payant à 20 $/mois. Pour le moment, le sujet n'est pas là.

Évaluation et limites : MLflow, paper trading, risques, hallucinations, conformité

Pour évaluer mes agents — l'équivalent des tests unitaires — j'ai utilisé MLflow, un outil open source qui permet de faire de l'évaluation d'agent.

Le site en ligne

Il est disponible à l'adresse suivante, ainsi que la documentation.

[Section à compléter : liens vers le site et la documentation.]

Ce que dit la science et la recherche sur le sujet

[Section à compléter.]

Comment j'ai testé mon workflow sans dépenser 1 centime

IBKR permet, dès la création du compte, d'ouvrir également un compte de simulation. Celui-ci est utile pour se familiariser avec la plateforme, comprendre les différentes interfaces et tester des workflows sans engager de capital. Une fois mon algorithme affiné sur le compte de simulation, j'ai déposé 1 000 € sur mon compte réel afin de le faire tourner en conditions réelles, de manière contrôlée, avec une fréquence d'un appel par jour. J'ai pu obtenir les résultats suivants :

[Section à compléter : résultats détaillés.]

La concurrence sur mon secteur

La concurrence est déjà bien installée sur ce secteur, notamment dans l'univers crypto, avec de nombreux bots de trading spécialisés sur le BTC ou l'ETH. Lors du développement de mon projet, j'ai identifié plusieurs acteurs répondant chacun partiellement à certaines de mes problématiques, mais aucun ne couvre l'ensemble du périmètre que je souhaite adresser. À ma connaissance, aucun concurrent ne combine aujourd'hui : l'analyse de portefeuille, le trading automatisé, l'analyse d'actions et l'exposition des analyses via MCP. Parmi les acteurs identifiés :

• Baggr propose une expérience très qualitative pour la recherche et l'analyse d'actions, avec un abonnement autour de 15 € par mois.
• Finary est davantage positionné sur l'analyse de patrimoine, le suivi de portefeuille et l'identification des frais cachés, notamment sur les assurances-vie et les fonds.
• Alpaca propose une infrastructure orientée trading automatisé, notamment via API, mais reste davantage centré sur l'exécution d'ordres que sur l'analyse complète de portefeuille, la recherche fondamentale ou l'exposition des analyses via MCP.

Il existe de nombreux projets sur GitHub qui travaillent sur les mêmes problématiques, le plus connu étant TauricResearch avec 80k stars. Pour mon service Momentum, j'ai utilisé des mécaniques similaires : l'outil fonctionnait en CLI, j'ai repris la logique pour persister les analyses dans une base de données et exposer des endpoints pour consommer et déclencher des analyses.

L'opportunité de mon projet se situe donc dans cette combinaison : offrir une plateforme capable d'analyser un portefeuille, d'étudier des actions, de produire des recommandations exploitables, de rendre ces analyses accessibles à d'autres agents ou outils via le protocole MCP, et de passer des ordres.

Conclusion

Il s'agit de mon premier vrai SaaS. Je suis plutôt fier de moi : sans l'IA, je n'aurais pas pu sortir cela aussi vite.