Article

Créer une application de trading avec Claude Code (test et verdict)

Découvre comment générer un terminal de trading complet avec Claude Code. Analyse des performances, gestion des agents autonomes et limites du développement en un seul prompt.

Dans l’essai présenté par Meydeey, la première version d’une application de trading générée avec Claude Code demande encore des corrections et des vérifications. Lors d'un test grandeur nature visant à générer un terminal de Swing trading complet avec 5 moteurs de calcul en Python, le modèle a mis près de 5 h pour livrer une première version. Si l'architecture de base, la cartographie des API gratuites et les interfaces principales sont générées, le résultat brut souffre de défauts majeurs. Des erreurs 500 apparaissent sur des modules critiques comme le plan de trade, et l'intégration graphique reste approximative sans un design system exhaustif. La véritable force de l'outil réside dans sa capacité à lancer des dizaines d'agents en parallèle pour auditer l'écosystème existant et adapter le cahier des charges. Pour obtenir un outil métier robuste, la méthode exige de valider l'architecture initiale, puis de confier le développement page par page à l'intelligence artificielle.

Cet article reprend et développe la vidéo Crée ton outil de trading avec Claude Code (Guide Complet). Regarder la vidéo sur YouTube, puis t'abonner à la chaîne pour les prochaines.

À retenir

Le verdict après 5 h de génération autonome

L'ambition de départ consistait à fournir un cahier des charges complet et un fichier de design à l'environnement de développement, puis de le laisser opérer en totale autonomie. Après près de 5 h de calcul ininterrompu, l'application existe bel et bien. Elle intègre un tableau de bord, des graphiques en chandeliers, un screener d'actifs et un module de gestion des risques. Le socle technique est en place et les bases de données locales communiquent avec l'interface.

Cependant, la réalité de l'utilisation révèle les limites de cette méthode d'exécution massive. Dès les premières manipulations, des erreurs bloquantes surgissent. La tentative d'enregistrement d'un plan de trade se solde par une erreur 500 immédiate. Visuellement, l'interface manque cruellement de cohérence. L'agencement des éléments est erratique, alternant des lignes de 3 composants avec des blocs isolés, trahissant l'absence d'un design system suffisamment rigide pour encadrer les décisions de l'intelligence artificielle.

Pourquoi centraliser ses outils d'investissement devient vital

Un opérateur de marché indépendant navigue quotidiennement entre de multiples classes d'actifs. Il surveille les actions américaines, analyse les cryptomonnaies et garde un œil sur les ETF européens. Cette dispersion l'oblige à jongler entre des plateformes déconnectées les unes des autres, multipliant les abonnements et les interfaces incompatibles. La charge mentale augmente proportionnellement au nombre d'outils utilisés.

L'objectif de ce développement répondait précisément à cette friction. Il s'agissait de construire un terminal centralisé, dédié au Swing trading, capable d'agréger ces différentes sources sans recourir à des flux de données payants. Un outil sur mesure peut adapter les indicateurs au besoin exprimé. Son coût inclut toutefois la maintenance, les données, l’hébergement éventuel et les vérifications des calculs.

Déléguer la cartographie aux agents en parallèle

Plutôt que de foncer tête baissée dans l'écriture du code, une configuration optimisée permet de lancer une phase de reconnaissance. 13 agents autonomes ont été déployés simultanément pour cartographier l'écosystème existant. Leur mission consistait à vérifier la disponibilité des sources de données gratuites, à évaluer les bibliothèques graphiques open source et à tester les contraintes de stockage local.

Cette étape préparatoire s'avère cruciale pour la viabilité du projet. Les agents ont rapidement identifié des failles majeures dans le cahier des charges initial. Certaines API publiques exigeaient désormais des captchas, tandis que d'autres imposaient des limites strictes sur l'historique des bougies. Ces découvertes ont permis à l'outil d'ajuster l'architecture et de documenter ses décisions avant même de rédiger la première ligne du backend.

  • Vérification des limites de requêtes sur les plateformes d'échange.
  • Recherche de bibliothèques graphiques pour éviter de recréer la roue.
  • Validation des contraintes d'écriture sur les bases de données locales.

Structurer les 5 moteurs de calcul

La fondation technique de l'application repose sur une architecture en Python, divisée en 5 moteurs distincts. Chacun possède une responsabilité isolée pour garantir la stabilité de l'ensemble. Le premier gère l'acquisition et la normalisation des données multi-sources. Le second calcule les indicateurs techniques nécessaires à l'analyse. Les 3 autres se chargent respectivement du backtest, du filtrage des opportunités et de l'évaluation du risque du portefeuille.

Le processus de création suit une logique séquentielle stricte. L'environnement génère d'abord le socle de l'application, incluant les domaines, les dépôts et la structure de la base de données. Une fois cette fondation validée par des sous-agents de vérification, la production des moteurs de calcul démarre. Cette séparation des préoccupations facilite théoriquement le débogage, même si la complexité globale de la demande génère inévitablement des frictions lors de l'intégration finale.

Le piège de la surconsommation des crédits

L'utilisation de la parallélisation représente un levier de productivité massif, mais elle cache un danger financier redoutable. Lancer des dizaines d'agents simultanément pour explorer des solutions ou corriger des bugs additionne la consommation des différents agents, avec un surcoût éventuel lié aux contextes répétés et à leur coordination. Une erreur de configuration à ce stade peut vider un budget de développement en quelques heures seulement.

La parade consiste à segmenter l'usage des modèles d'intelligence artificielle. Il est impératif d'assigner des modèles plus légers et rapides pour les tâches de reconnaissance et de cartographie. Le modèle principal, plus coûteux et doté d'une capacité de raisonnement supérieure, doit être strictement réservé à la prise de décision architecturale et à la génération des algorithmes complexes. Le suivi des appels et des reprises permet d’évaluer le coût réel de cette répartition des tâches.

Les moments clés de la vidéo

  1. Ce qu'on va construire

    Présentation de l'objectif : développer un terminal de Swing trading multi-actifs en Python, basé uniquement sur des sources de données gratuites et structuré autour de 5 moteurs de calcul.

  2. Le PRD en un seul prompt

    Préparation du cahier des charges et du fichier de référence visuelle pour guider l'intelligence artificielle dans la création de l'interface et des fonctionnalités.

  3. Opus 5 xhigh, on lance

    Démarrage de la session de développement avec le modèle principal et injection des instructions pour forcer la recherche de ressources existantes.

  4. 13 agents lancés en parallèle

    Déploiement d'une flotte de sous-agents chargés de cartographier l'écosystème open source et d'évaluer les API disponibles avant de commencer à coder.

  5. Jamais Opus en parallèle

    Explication de la stratégie d'optimisation des coûts : utiliser des modèles légers pour la reconnaissance afin d'éviter de brûler les crédits de l'API.

  6. Le trou dans mon PRD

    Les agents découvrent que certaines sources de données gratuites prévues dans le plan initial ne sont plus accessibles, forçant une adaptation de l'architecture.

  7. Le socle, puis les bugs

    Génération de la structure de base de l'application et lancement immédiat de sous-agents dédiés à la correction des premières erreurs de gabarit.

  8. Les 5 moteurs de calcul

    Développement séquentiel des modules backend en Python, incluant la gestion des indicateurs, le backtest et l'analyse des risques.

  9. 5 heures après, le résultat

    Exploration de l'interface générée après plusieurs heures de calcul autonome. Découverte du tableau de bord, des graphiques et du screener.

  10. L'erreur 500 en direct

    Test du module de plan de trade qui se solde par un crash serveur, illustrant les limites d'une génération massive sans validation intermédiaire.

  11. Pourquoi le design est raté

    Analyse des défauts visuels de l'application, causés par l'absence d'un design system exhaustif lors de la soumission du prompt initial.

  12. Mon verdict

    Conclusion sur la méthode de développement : la nécessité d'abandonner l'approche en un seul prompt au profit d'une construction itérative page par page.

Ce qu'il faut en faire

La création d'un outil métier sur mesure exige une rigueur implacable. Confier un développement complexe à une IA en espérant un résultat parfait du premier coup reste une illusion. La véritable compétence consiste à découper ton besoin. Valide d'abord ton architecture technique et tes sources de données. Ensuite, pilote le développement module par module, en testant chaque page avant de passer à la suivante. Consolide ton design system en amont pour éviter les mauvaises surprises. Si une méthode d'analyse te prend des heures, commence par isoler cette fonction précise et demande à ton environnement de l'automatiser.

Construis un système IA qui reste maîtrisable

Le LABO IA t'aide à choisir les modèles, connecter les outils et vérifier les workflows sur des cas réels, sans dépendre d'un seul fournisseur.

Découvrir le programme

Questions fréquentes

Est-il possible de créer une application complète avec un seul prompt ?

Techniquement oui, mais le résultat sera instable. Un prompt unique contenant tout le cahier des charges force l'intelligence artificielle à prendre des centaines de micro-décisions sans validation intermédiaire. Cette approche génère des erreurs de logique, des bugs bloquants et une interface souvent dégradée. La méthode recommandée consiste à valider l'architecture globale en une fois, puis à développer chaque fonctionnalité de manière itérative.

Comment éviter d'exploser son budget API avec les agents autonomes ?

Le coût du parallélisme dépend du nombre d’appels, des modèles, des contextes transmis et des reprises nécessaires. L'erreur classique consiste à utiliser le modèle le plus puissant pour des tâches de recherche ou de cartographie. Il faut impérativement assigner des modèles plus légers et rapides pour les sous-agents chargés de l'exploration, et réserver le modèle principal uniquement pour la synthèse et la génération du code complexe.

Pourquoi l'interface générée par l'IA est-elle souvent mal agencée ?

L'intelligence artificielle interprète strictement les contraintes visuelles qu'on lui fournit. Si tu lui donnes une maquette ou un moodboard sans un design system complet incluant les règles d'espacement, de comportement responsif et les états des composants, elle improvisera pour combler les vides. Le résultat sera fonctionnel techniquement, mais visuellement incohérent.

Faut-il demander à l'IA de coder toutes les fonctionnalités de zéro ?

Non, c'est une perte de temps et de ressources. Une bonne pratique consiste à forcer l'outil à auditer l'écosystème open source avant de coder. L'intelligence artificielle peut identifier des bibliothèques existantes ou des composants fiables pour gérer des éléments standards comme les graphiques financiers, avec une vérification de leur adéquation, de leur maintenance et de leurs contraintes.

Meydeey, architecte IA et automatisation
Meydeey, architecte IA et automatisation.

Tests terrain, architecture multi-modèles et systèmes d'automatisation conçus pour rester vérifiables.

Toutes les vidéos du sujet Dev IA & agents