ProRealAI — Copilote IA ProRealTime & ProBuilder

[Fabien Labrousse]

"ProRealAI est votre copilote IA pour ProRealTime™. Décrivez en clair — obtenez des indicateurs, screeners et systèmes de trading prêts à utiliser."

>> https://ai.prorealcode.com/fr/

[JosephTot]

Pour compléter l'annonce, voici une présentation plus détaillée de l'outil, avec quelques conseils pratiques et les précautions à garder en tête.

C'est quoi exactement ?

ProRealAI est un assistant de programmation dédié à ProRealTime, développé par ProRealCode, la grande communauté francophone et internationale autour de la plateforme (plus de 64 000 membres, une bibliothèque de milliers de codes gratuits et des forums très actifs). On décrit son idée en langage courant, en français ou dans l'une des 7 langues proposées, et l'outil renvoie du code ProBuilder prêt à coller dans la plateforme : indicateurs, screeners (ProScreener) et systèmes de trading automatiques (ProBackTest / ProOrder).

Sa particularité, selon ses créateurs : il a été entraîné spécifiquement sur les données de ProRealCode (extraits de code, discussions du forum, documentation, codes fonctionnels de la communauté). L'idée est d'éviter un défaut bien connu des IA généralistes comme ChatGPT ou Claude, qui connaissent souvent mal la syntaxe ProBuilder et produisent du code qui ne compile pas. L'outil vérifie aussi le code produit par rapport à la documentation officielle.

Ce qu'on peut lui demander

• Créer un code de A à Z : indicateur, screener ou système complet, à partir d'une description en français.

• Déboguer un code qui ne compile pas : coller le code et le message d'erreur exact renvoyé par ProRealTime.

• Déboguer un code qui compile mais se comporte mal : par exemple un système qui ne prend jamais de position vendeuse, ou qui rentre à chaque bougie.

• Améliorer un code existant : ajouter un stop suiveur, un passage au point mort, une gestion de la taille de position, un filtre horaire, le côté vendeur...

• Transformer un indicateur en screener, ou l'inverse.

• Traduire une idée trouvée ailleurs : un livre, une vidéo, ou un indicateur Pine Script de TradingView.

• Auditer un code avant de l'utiliser en réel : c'est à mon avis l'un des usages les plus utiles. On peut lui demander d'expliquer ce que fait un système récupéré sur un forum et de repérer s'il "repeint" ou s'il utilise des informations du futur, ce qui donnerait un backtest trompeur.

• Poser des questions sur la plateforme : fonctionnement de certaines instructions, différences entre backtest et réel, prise en compte du spread et des commissions...

• Apprendre ProBuilder : demander des explications ligne par ligne. Les explications sont l'occasion de progresser plutôt que de simplement copier-coller.

Combien ça coûte ?

L'outil fonctionne avec des crédits. Chaque compte reçoit 150 crédits gratuits tous les 30 jours, avec quelques subtilités :

• C'est une recharge jusqu'à 150, pas un ajout de 150 : s'il vous reste 120 crédits, vous recevez 30. Il ne sert donc à rien de les économiser d'un mois sur l'autre.

• Le cycle est individuel : il démarre à partir de votre dernière recharge, pas le 1er du mois.

• La recharge se fait à votre retour : si vous ne vous connectez pas pendant trois mois, vous ne recevez qu'une seule recharge.

Il est possible d'acheter des crédits supplémentaires pour un usage plus intensif.

Bien l'utiliser pour économiser ses crédits

Point important à comprendre : à chaque message, l'assistant relit toute la conversation en cours. Plus une conversation est longue, plus chaque nouveau message coûte cher. D'où quelques règles simples :

• Une conversation = un sujet : nouvel indicateur ou nouveau problème, nouvelle conversation.

• Repartir de zéro quand un code fonctionne : le copier, puis ouvrir une nouvelle conversation en collant uniquement la version finale si on veut le faire évoluer.

• Poser des demandes complètes : préciser dès le départ s'il s'agit d'un indicateur, d'un screener ou d'un système, le marché, l'unité de temps, le sens (achat, vente ou les deux), les conditions d'entrée et de sortie, le stop. Une demande précise évite cinq ou six messages d'allers-retours.

• Demander "le code seul, sans explication" quand on itère sur un code qu'on comprend déjà, puisque les réponses longues coûtent plus cher.

• Ne pas recoller son code à chaque message : il est déjà dans la conversation.

Les précautions à garder en tête

• L'outil ne voit pas votre écran : il faut coller le code dans ProRealTime, le lancer, et revenir lui indiquer précisément le résultat ou l'erreur obtenue.

• Un code qui compile n'est pas une stratégie qui gagne : ProRealAI vous aide à écrire le code de votre idée, il ne garantit absolument pas que cette idée soit rentable.

• Attention à la suroptimisation : il devient très facile de générer des dizaines de variantes et d'optimiser tous les paramètres jusqu'à obtenir un backtest magnifique. C'est précisément le piège dans lequel tombent la plupart des systèmes automatiques. On peut d'ailleurs demander à l'outil quels paramètres optimiser et lesquels laisser fixes, ou comment structurer un test walk-forward.

• Vérifier les conditions du backtest : spread, commissions, mode d'exécution (à la clôture de la bougie ou tick par tick). Un backtest sans frais réalistes n'a aucune valeur.

• Toujours relire et comprendre le code avant de le passer en réel : comme avec toute IA, des erreurs restent possibles. Et un système automatique qu'on ne comprend pas, c'est un système qu'on ne saura pas arrêter au bon moment.

Pour rappel, nous avons publié sur le forum un sujet complet sur les étapes de validation d'une stratégie (idée, backtest, tests de robustesse, démo, petite taille, montée en charge). ProRealAI peut faire gagner énormément de temps sur la partie programmation, mais ne remplace aucune de ces étapes.

Et vous ?

L'avez-vous déjà testé ? Sur quels types de codes, et avec quels résultats ? N'hésitez pas à partager ici vos retours, vos meilleures requêtes, ou les limites que vous avez rencontrées.

[jackoneil]

Merci JosephTot pour ce complément très complet. J'ajoute quelques points pratiques, propres à ProBuilder, qui font souvent la différence entre un backtest flatteur et un système qui se comporte en réel comme prévu.

Ce qu'il vaut la peine de préciser dans la demande

L'outil répond à ce qu'on lui demande. Plusieurs paramètres qui changent complètement le résultat ne sont pas évidents si on ne les mentionne pas :

• Le moment d'exécution : en ProBuilder, une condition validée à la clôture d'une bougie déclenche un ordre exécuté à l'ouverture de la bougie suivante. Sur une petite unité de temps ou un marché qui gappe, l'écart n'est pas anodin.

• Les stops : un stop défini par SET STOP est transmis comme un ordre, alors qu'une sortie codée par condition n'est évaluée qu'à la clôture de la bougie. Ce ne sont pas du tout les mêmes résultats en cas de mouvement brutal.

• Le cumul des positions (DEFPARAM CumulateOrders) : selon le réglage, un système peut empiler les entrées sans qu'on l'ait voulu, et se transformer en grille sans le dire.

• Le nombre de barres préchargées (PreLoadBars) pour les indicateurs à longue période, sans quoi les premiers signaux du backtest sont faux.

Une méthode qui fait gagner du temps et des crédits

Avant de demander le code, demander à l'outil de reformuler la stratégie en règles numérotées : entrée, sortie, stop, taille, horaires, cumul ou non. On corrige la reformulation, puis on demande le code. La plupart des allers-retours viennent d'une ambiguïté dans la description, pas d'une erreur de syntaxe.

Le bon usage : auditer plutôt que générer

Je rejoins JosephTot sur ce point. Générer dix variantes d'un système devient trivial, et c'est justement le danger. L'usage le plus rentable, à mon avis, c'est de demander à l'outil de chercher ce qui pourrait rendre le backtest trompeur : informations du futur, exécution irréaliste, frais absents, paramètres trop nombreux pour le nombre de trades. Un système qui survit à cet audit vaut plus que dix systèmes générés.

Si certains d'entre vous l'ont testé sur un même besoin en parallèle d'une IA généraliste, le comparatif m'intéresse : qualité du code, mais aussi pertinence des remarques sur le backtest.