Guide produit Pionex | 3 septembre 2026


Pionex.AI Quant est un espace de travail permettant de créer des stratégies de trading et de les tester sur des données de marché historiques. Vous décrivez les règles dans une conversation, examinez le test proposé, puis confirmez la simulation. L’essentiel est de vérifier ce qui sera réellement testé, et pas simplement de demander à l’IA de trouver une stratégie rentable.
Ce guide suit un exemple de moyennes mobiles sur BTC-USDT, depuis la demande initiale jusqu’au backtest terminé. Il montre les points à examiner avant de confirmer, la façon de lire le rapport et l’importance des paramètres non pris en charge ou des modifications de vos règles. Nous avons exécuté une simulation historique, sans créer de stratégie en conditions réelles.
Si vous avez recherché PionexGPT ou Pionex GPT pour transformer une idée de trading en backtest, ce guide présente le processus dans Pionex.AI Quant. Pour écrire et déboguer du Pine Script destiné à TradingView, consultez notre guide PionexGPT consacré à Pionex.AI Coder. Ces deux guides portent sur des tâches différentes, pas sur des outils interchangeables.
Contents
Commencez dans Quant avec une stratégie clairement définie
Ouvrez Pionex.AI et sélectionnez Quant. Cet espace comprend Market & Research et My Strategies. Market & Research place la conversation à côté d’un graphique de marché et propose les demandes de départ EMA Backtest, Bollinger Backtest et Risk Tuning.
Lors de notre parcours du 3 septembre, sélectionner EMA Backtest a rempli la zone de message avec une demande de test de croisement d’EMA sur BTC-USDT, utilisant des bougies d’une heure et les 500 dernières barres. Cela n’a pas lancé immédiatement la simulation. Vous pouvez donc préciser les règles de trading et les hypothèses avant d’envoyer la demande.
Une EMA, ou moyenne mobile exponentielle, accorde davantage de poids aux prix récents. Une stratégie de croisement compare une EMA rapide à une EMA lente. Dans cet exemple, nous avons défini une entrée à l’achat lorsque l’EMA à 9 périodes croise au-dessus de l’EMA à 21 périodes, et une sortie lorsqu’elle recroise en dessous.
Il s’agit d’une règle testable, pas d’une recommandation de trading. Un croisement peut entraîner une entrée tardive après un mouvement et des pertes répétées lorsque le marché évolue latéralement.
| Paramètre | Notre spécification pédagogique |
|---|---|
| Marché | BTC-USDT |
| Intervalle des bougies | Une heure |
| Période demandée | Les 500 dernières bougies clôturées |
| Direction | Positions longues uniquement, une position à la fois |
| Entrée | L’EMA 9 croise au-dessus de l’EMA 21 après la clôture d’une bougie |
| Sortie | L’EMA 9 croise en dessous de l’EMA 21 après la clôture d’une bougie |
| Capital initial demandé | 10 000 USDT de capital simulé |
| Taille de position acceptée après clarification | 10 % des capitaux propres du compte simulé par entrée |
| Commission demandée | 0,10 % par exécution, à titre d’hypothèse |
| Glissement demandé | Mouvement défavorable de 0,05 % par exécution, déclaré non pris en charge par Quant |
| Règles supplémentaires | Aucune position courte, aucun levier, take-profit ou stop-loss fondé sur le prix |
Le capital et les coûts sont des hypothèses de test. Ils ne représentent ni un investissement minimum, ni les frais de trading actuels de Pionex, ni une prévision de qualité d’exécution.
Pour découvrir la plateforme et ses modalités d’accès, consultez notre guide des agents Pionex.AI et de la prise en main.
Rédigez une demande qui explicite les hypothèses
Une demande utile précise le marché, l’intervalle des bougies, l’entrée, la sortie, la direction, la taille des positions, la période de test et les coûts de trading. Elle indique aussi à Quant comment réagir lorsqu’un paramètre demandé n’est pas disponible.
Voici une demande à adapter. Elle intègre les clarifications apportées pendant notre préparation, sans affirmer que tous les paramètres demandés sont pris en charge.
Prépare un backtest pédagogique sur BTC-USDT avec des bougies d’une heure et les 500 dernières barres clôturées. Ouvre une seule position longue lorsque l’EMA 9 croise au-dessus de l’EMA 21 après la clôture d’une bougie. Ferme-la lorsqu’elle recroise en dessous. Exige une observation précédente avec des EMA initialisées afin que la première lecture disponible ne puisse pas déclencher un faux croisement. Utilise 10 000 USDT de capital initial simulé et 10 % des capitaux propres simulés par entrée. Modélise une commission de 0,10 % par exécution si cela est pris en charge. N’ajoute ni levier, ni vente à découvert, ni take-profit, ni stop-loss fondé sur le prix. Précise si le glissement peut être modélisé, si une barrière technique de sortie est obligatoire et quels paramètres ne sont pas pris en charge. Explique le moment des exécutions et prépare la confirmation pour examen. Ne passe aucun ordre réel et ne déploie aucune stratégie.
Évitez les demandes comme « crée le bot BTC le plus rentable ». Elles ne définissent pas la logique de trading et encouragent à modifier les paramètres jusqu’à obtenir un résultat historique séduisant. Partez d’une règle que vous pouvez expliquer, puis vérifiez si son implémentation la respecte.
Examinez les règles générées avant de confirmer
L’écran Backtest Confirmation de Quant affiche le symbole, l’intervalle, la période et le code généré, avec les commandes Cancel et Confirm. Notre confirmation indiquait BTC_USDT, 1h et une période allant du 13 août au 3 septembre 2026. Elle affichait aussi le quota mensuel de backtests restant sur le compte.


Vérifiez votre quota avant d’expérimenter. Le nombre affiché sur un compte ne constitue pas une promesse valable pour toutes les formules, et générer une explication écrite n’équivaut pas à terminer un backtest.
Notre examen a fait ressortir trois points à vérifier dans votre propre stratégie.
Une lecture haussière n’est pas forcément un croisement
La première version générée pouvait autoriser une entrée dès que les EMA devenaient disponibles, si l’EMA rapide se trouvait déjà au-dessus de l’EMA lente. Cela diffère d’un passage observé de l’EMA rapide depuis le dessous vers le dessus de l’EMA lente.
Nous avons demandé à Quant d’exiger deux observations initialisées. La logique révisée conservait les valeurs précédentes des EMA, utilisait la première lecture uniquement comme référence et exigeait que l’EMA rapide précédente soit inférieure ou égale à l’EMA lente avant une entrée sur une nouvelle lecture supérieure. La sortie utilisait le test inverse, du dessus vers le dessous.
Il n’est pas nécessaire de comprendre chaque ligne de Python pour poser cette question : « La première lecture disponible de l’indicateur peut-elle déclencher une transaction sans qu’un croisement ait eu lieu ? » Demandez à Quant de montrer où le code applique cette condition.
Une correction peut introduire une règle sans rapport
Pendant la révision, Quant a ajouté un stop-loss de 20 % fondé sur le prix, absent de la demande. Nous avons annulé cette confirmation et demandé de conserver les règles de sortie EMA initiales.
Chaque révision doit donc être comparée à la spécification. Un stop-loss, une entrée à découvert, une autre taille de position ou un nouveau filtre modifie la stratégie testée, même si ce changement paraît raisonnable pris isolément.
Quant a également indiqué qu’au moins une barrière technique de sortie était obligatoire. La correction demandée a conservé une échéance temporelle très éloignée plutôt qu’un stop fondé sur le prix. Ce détail d’implémentation doit être expliqué, et non masqué derrière l’affirmation que le code contient uniquement les règles demandées.
Les coûts non pris en charge et le calcul des positions doivent être précisés
Quant a indiqué que l’hypothèse de glissement de 0,05 % demandée ne pouvait pas être modélisée avec les paramètres disponibles. Le glissement correspond à l’écart entre le prix d’exécution attendu et le prix réellement obtenu. Une simulation qui l’omet présente une limite, même si elle inclut les commissions.
Quant a aussi précisé que son dimensionnement en pourcentage repose sur les capitaux propres du compte, et non sur les liquidités disponibles. Nous avons accepté cette méthode pour l’exemple pédagogique et consigné le changement. Ne présentez pas un test fondé sur les capitaux propres comme un test fondé sur les liquidités au seul motif que la demande initiale parlait de liquidités.
L’explication du fonctionnement interne donnée par l’assistant n’est pas un audit indépendant du moteur. Lorsque le rapport ne révèle pas un paramètre ou un détail d’exécution, cette limite doit rester explicite.
Lisez le backtest comme une observation, pas comme une prévision
Un backtest terminé décrit une simulation historique sous des règles et hypothèses particulières. Avant d’utiliser son rendement principal, vérifiez que l’exécution est terminée, que le marché et la période sont corrects et que la stratégie générée correspond aux règles prévues.
Notre exécution a atteint le statut Succeeded. Le rapport indiquait 500 barres d’une heure, un capital initial de 10 000 et une commission de 10 points de base par exécution. Le rapport brut fournissait des horodatages allant du 13 août 2026 à 17:00 UTC au 3 septembre à 12:00 UTC. Il ne précisait pas s’ils désignaient l’ouverture ou la clôture des bougies ; le rapport seul ne confirme donc pas indépendamment le filtrage demandé des bougies clôturées.


| Résultat | Valeur rapportée pour cette exécution |
|---|---|
| Rendement total | +1,8 % dans le résumé ; +1,7962 % dans le rapport brut |
| Capitaux propres simulés finaux | 10 179,62 dans le rapport brut ; le résumé arrondit à 10 180 $ |
| Drawdown maximal | -0,5 % dans le résumé ; environ -0,5143 % dans le rapport brut |
| Transactions clôturées | 11 |
| Taux de réussite | 36,4 % |
| Facteur de profit | 4,69 |
| Référence achat-conservation | +23,4 % |
La liste des opérations comprenait 12 achats et 11 ventes, laissant 0,01308 BTC sans vente de clôture correspondante à la fin. Voilà pourquoi 23 exécutions ne représentent pas 23 transactions clôturées. Ne présentez pas les capitaux propres finaux comme un bénéfice issu de positions entièrement clôturées.
La quantité, le prix et la commission de la première exécution étaient cohérents avec l’hypothèse de frais de 0,10 % demandée. Cela vérifie une opération visible, pas tous les aspects du moteur d’exécution. Le glissement restait non modélisé.
La référence compte également : cette exécution n’a pas dépassé le rendement achat-conservation affiché. Toutefois, la stratégie visait environ 10 % des capitaux propres par entrée, tandis que la référence représentait un achat suivi d’une conservation ; leurs expositions différaient. Ni le rendement supérieur de la référence ni le drawdown plus faible de la stratégie ne prouvent quelle approche sera la plus performante à l’avenir.
Le résumé généré employait l’expression « sort ou inverse la position ». Nos règles soumises autorisaient uniquement les positions longues, et la séquence d’opérations montrait des sorties suivies de nouveaux achats, pas des entrées à découvert. Vérifiez les règles soumises et les opérations au lieu de considérer un résumé générique comme une spécification exacte.
Pour votre propre test, suivez le même ordre de vérification :
| Vérification | Ce qu’elle permet de comprendre |
|---|---|
| Rendement de la période | L’évolution pendant la période testée, et non un rendement annuel promis |
| Drawdown maximal, s’il est affiché | La plus forte baisse depuis un sommet antérieur des capitaux propres pendant la simulation |
| Nombre de transactions | Combien de transactions ont contribué au résultat |
| Entrées et sorties, si disponibles | Si la stratégie a exécuté les opérations conformément à ses règles |
| Hypothèses de coûts | Les dépenses incluses et omises dans la simulation |
| Positions ouvertes à la fin | Si le résultat inclut une transaction non terminée |
Un indicateur absent n’est pas égal à zéro. Si le rapport ne montre pas le détail des opérations ou une statistique demandée, indiquez que cette information est indisponible plutôt que de combler le manque avec une estimation présentée comme un résultat de la plateforme.
Distinguez aussi le rendement d’une période d’un chiffre annualisé. Notre explication du rendement annualisé d’un backtest sur sept jours présente ce calcul. N’appliquez pas à Quant la définition d’un indicateur de Grid Bot sans vérifier qu’il utilise la même définition.
Ce rapport affichait un rendement annualisé de +36,7 %. Cela ne signifie pas que le compte a gagné 36,7 % pendant le test, ni que ce rendement pourrait être maintenu pendant un an. Le rendement observé sur la période était d’environ 1,8 %.
Déterminez ce qui reste à tester
Cinq cents bougies d’une heure couvrent une courte période historique. Un résultat utile sur cette période ne démontre pas le comportement de la stratégie pendant une baisse prolongée, une forte tendance ou un autre régime de volatilité.
Conservez la spécification initiale et consignez chaque modification. Lorsque les possibilités de test et le quota le permettent, évaluez les règles inchangées sur une période distincte, non utilisée pour choisir les paramètres. Incluez les périodes perdantes dans votre examen au lieu de ne présenter que la meilleure exécution.
Ajuster sans cesse les paramètres aux mêmes données historiques peut provoquer un surapprentissage : une stratégie décrit précisément cet échantillon, mais fonctionne mal sur de nouvelles données. C’est un risque général de recherche, qu’une stratégie générée par IA n’évite pas automatiquement. Le guide de backtesting de QuantConnect explique la simulation historique et les périodes réservées à la validation, tandis que sa documentation sur l’optimisation traite de ce risque. Ces références expliquent les concepts, pas l’implémentation de Pionex.AI.
Le processus de backtesting de Quant est également distinct de la création de Pine Script pour TradingView avec Coder. Dans ce tutoriel, la confirmation de Quant contenait du code Python. Pour générer du Pine Script ou traiter les erreurs de compilation, consultez notre guide PionexGPT consacré à Pionex.AI Coder.
Le rapport terminé proposait deux boutons distincts : Save Strategy et Create Live Strategy. Nous n’avons utilisé aucun des deux dans ce tutoriel. Une simulation réussie ne prouve pas qu’une stratégie a été enregistrée ou déployée.
⚠️ Une confirmation de backtest n’autorise pas le passage d’ordres réels. Examinez séparément tout processus d’exécution ou de déploiement, ses permissions de compte et ses risques financiers avant de poursuivre. Ne communiquez jamais de mots de passe, de secrets d’API ou de phrases de récupération dans une demande à une IA.
Le backtesting n’est pas du trading agentique en conditions réelles
Le backtest de Pionex.AI Quant évalue les règles d’une stratégie sur des données historiques. Robinhood Agentic Trading connecte un agent IA externe via MCP pour soumettre des ordres réels éligibles. Obtenir une simulation utile et autoriser le trading sont deux étapes distinctes. Pour les différences de configuration, de produits pris en charge et de contrôles, consultez notre comparatif du trading agentique Robinhood et de Pionex. Ce tutoriel ne démontre aucune intégration entre Quant et Robinhood.
Questions fréquentes
Pionex.AI Quant est-il identique à PionexGPT ?
Ce guide présente Pionex.AI Quant, l’espace de création de stratégies et de backtesting. Il n’établit pas que Quant est un nouveau nom de PionexGPT ou un « PionexGPT 2.0 » officiel. Si vous êtes arrivé après une recherche PionexGPT, choisissez le processus actuel adapté à votre tâche : Quant pour le backtest présenté ici, ou Coder pour l’aide en Pine Script.
Peut-on assimiler le backtest de Quant à celui d’une AI Strategy de Grid Bot ?
Non. Considérez la simulation de stratégie de Quant et les indicateurs AI Strategy d’un Grid Bot comme deux processus distincts. Vérifiez leurs règles, périodes de données, hypothèses de coûts et définitions du rendement avant de les comparer.
Que faire si Quant modifie mes règles de trading ?
Annulez le test proposé avant de le confirmer. Identifiez précisément l’écart, demandez la correction minimale et comparez les règles révisées d’entrée, de sortie, de dimensionnement et de coûts à votre spécification initiale.
Une stratégie sans stop-loss fondé sur le prix présente-t-elle un risque limité ?
Non. L’absence de stop fondé sur le prix ne limite pas les pertes, et une sortie EMA peut survenir après une baisse importante. Les règles de cet article servent à une simulation pédagogique, pas à une configuration réelle recommandée.
Dois-je coller mes identifiants de compte dans Quant pour exécuter cet exemple ?
Aucun identifiant n’était nécessaire dans la demande pour ce tutoriel réalisé avec une session déjà connectée. Ne collez pas de mots de passe, de secrets d’API, de clés privées ou de phrases de récupération dans la conversation.
Avertissement
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d’investissement. Le trading de cryptomonnaies comporte des risques importants, y compris la perte totale du capital. Les performances passées ne préjugent pas des résultats futurs. Effectuez toujours vos propres recherches avant de trader.
Observations produit : interface Pionex.AI Quant avec une session connectée, le 3 septembre 2026. Les options de l’interface, les conditions d’accès et les quotas peuvent changer. Tout résultat de simulation doit être interprété avec sa période de données, ses règles de trading et ses limites propres.
