Runtime natif IA pour stratégies de trading Bitget
Développez dans Cursor, Claude Code ou n'importe quel IDE IA. Déployez depuis GitHub sur un runtime cloud managé avec contrôle MCP de premier ordre, logs et choix de région.
Section 01 · En un coup d’œil
En un coup d’œil
- Plateforme
- Bitget
- Type de plateforme
- Plateforme d'échange crypto (axée copy-trading)
- Classe d’actifs
- Crypto (spot, contrats perpétuels USDT-M et coin-M, marge, copy-trading)
- Produits pris en charge
- Spot, contrats à terme perpétuels USDT-M, contrats perpétuels coin-M, contrats perpétuels USDC-M, marge isolée et croisée, copy-trading sur contrats perpétuels. Trading démo disponible via l'API de production.
- Modèle d’exécution
- Runtime de stratégie conteneurisé
- Source de déploiement
- GitHub
- Langages
- Tout langage compatible avec un conteneur
- Intégrations courantes
- REST et WebSocket natifs Bitget V2, CCXT, Hummingbot, connecteurs personnalisés
- Intégration du workflow d’IA
- Interface de contrôle MCP pour Cursor, Claude Code, GitHub Copilot et agents CLI
- Rôle de TradingHost
- Runtime, déploiement, logs, bilans de santé (health checks), choix de région, contrôle MCP
- Rôle de Bitget
- Compte d'échange, accès API, accès au marché, lieu d'exécution
- Affiliation
- TradingHost est indépendant et n'est pas affilié à Bitget.
Section 02 · Ce que propose Bitget
Ce que propose Bitget
Bitget propose du spot, des contrats à terme perpétuels USDT-M, coin-M et USDC-M, de la marge croisée et isolée, ainsi qu'une couche de copy-trading sur les contrats perpétuels via des API REST et WebSocket. Les stratégies s'authentifient avec des requêtes signées par HMAC-SHA256 à trois en-têtes auprès de l'API V2. Les spécificités des endpoints évoluent avec le temps. La structure globale reste stable ; les limites de requêtes (rate limits), les paliers de frais et les listes de symboles précis figurent dans la documentation de Bitget.
Marchés et types de stratégies
- Stratégies sur contrats à terme perpétuels USDT-M
- Stratégies sur contrats perpétuels Coin-M et USDC-M
- Flux de comptes principaux (parent) et suiveurs (follower) en copy-trading
- Trading de taux de financement (funding rate) et de base sur contrats perpétuels
- Stratégies spot et sur marge (croisée ou isolée)
- Déploiements multi-stratégies isolés par sous-comptes
- Flux d'ordres et de positions sur canaux privés WebSocket
- Déploiements validés en trading démo sur l'API de production
Interface API
- Produits couverts
- Spot, contrats à terme perpétuels USDT-M, contrats perpétuels coin-M, contrats perpétuels USDC-M, marge isolée et croisée, et hiérarchies parent/suiveur pour le copy-trading. Le trading démo expose la même interface V2 pour validation sur l'API de production sans capital réel.
- Méthodes de connexion
- REST pour le passage d'ordres et les requêtes de compte. Canaux publics WebSocket pour les données de marché et les mises à jour du carnet d'ordres. Canaux privés WebSocket pour les événements de compte, de solde, de position et d'ordre. Bitget V2 est la génération d'API actuelle ; les endpoints hérités V1 restent documentés mais les nouvelles intégrations ciblent la V2.
- Authentification
- Clé API, secret et phrase secrète (passphrase) par stratégie. Les requêtes privées comportent trois en-têtes : ACCESS-KEY, ACCESS-TIMESTAMP et ACCESS-SIGN. La signature est un HMAC-SHA256 encodé en base64 combinant timestamp + méthode + requestPath + corps de la requête. Bitget rejette les requêtes hors d'une fenêtre de fraîcheur de 30 secondes.
Pour plus de détails, reportez-vous à Bitget
Les endpoints spécifiques, les limites de requêtes, les listes de symboles, les paliers de frais et l'historique des versions figurent dans la documentation de Bitget. Considérez-les comme la source de vérité.
Section 03 · Développer avec l’IA
Développez votre stratégie Bitget avec l’IA
Choisissez une méthode d’intégration, dupliquez (fork) un starter de framework TradingHost et concevez votre stratégie dans un AI IDE. Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande fonctionnent tous avec le même cycle de déploiement natif sur GitHub.
API native Bitget V2
Contrôle direct du comportement spécifique à Bitget, des hiérarchies de copy-trading et de la logique d'exécution des ordres.
Hummingbot
Déploiements basés sur un framework utilisant la structure de stratégie et le modèle de configuration de Hummingbot.
Connecteur personnalisé
Votre propre moteur de trading interne ou intégration propriétaire Bitget.
Compatibilité des frameworks avec les produits Bitget
La couverture varie selon le framework. CCXT prend en charge le spot et les contrats perpétuels de Bitget ; Hummingbot propose un connecteur dédié bitget_perpetual en plus du spot. Les hiérarchies de copy-trading ne sont gérées que par l'API native aujourd'hui ; aucun framework ne les abstrait en tant que primitive native. L'API native Bitget V2 couvre l'intégralité de l'offre de Bitget, y compris le copy-trading.
✓ compatibilité confirmée selon la documentation officielle du framework. « no » indique que la compatibilité n’est pas officiellement documentée.
TradingHost n’impose aucun framework. Il exécute votre projet.
Développer avec l’IA
Les starters de framework ci-dessus s’associent naturellement avec les AI IDE. L’interface de contrôle MCP de TradingHost ferme la boucle : les outils d’IA peuvent inspecter les déploiements, consulter les journaux et gérer l’environnement d’exécution à vos côtés, sans jamais interférer avec le flux d’exécution des ordres.
Section 04 · Exécuter sur TradingHost
Exécutez votre code sur TradingHost
Bitget fournit la plateforme d’échange et l’accès API. TradingHost fournit l’environnement de production où s’exécute votre stratégie connectée à Bitget.
Au lieu d’exécuter le code de votre stratégie sur un ordinateur portable, un ordinateur de bureau, un VPS générique ou un serveur configuré manuellement, vous le déployez depuis GitHub dans un environnement d’exécution de conteneurs géré par TradingHost.
Vous
- Votre dépôt contient votre code.
- Votre déploiement définit son mode d’exécution.
- Votre stratégie se connecte à Bitget.
TradingHost
- Maintient l’environnement d’exécution en ligne.
- Affiche les logs et les contrôles d’état.
- Sélection de la région.
- Surface de déploiement contrôlée.
Flux de déploiement
- ÉTAPE 01
Connecter GitHub
Autorisez TradingHost à accéder à votre compte GitHub.
- ÉTAPE 02
Associez un dépôt ou démarrez depuis un framework
Pointez TradingHost vers votre dépôt de stratégie existant, ou dupliquez (fork) un runtime de framework TradingHost (CCXT ou Hummingbot) pour obtenir une base de travail fonctionnelle.
- ÉTAPE 03
Déployer dans un conteneur TradingHost
Choisissez une région (EU ou US-East), renseignez les variables d'environnement nécessaires à votre stratégie (clé API, secret et passphrase Bitget, etc.) et déployez. TradingHost génère votre conteneur à partir du dépôt et exécute votre stratégie sur une infrastructure Kubernetes managée. Pas besoin d'installer Docker localement.
- ÉTAPE 04
Suivre les logs et l’état de santé
Suivez en direct les logs, l’état de santé et l’état d’exécution depuis le tableau de bord TradingHost. Cette même interface est accessible via MCP depuis n’importe quel AI IDE, permettant à Cursor, Claude Code ou un agent en ligne de commande de lire l’état du déploiement et de gérer le runtime à vos côtés.
- ÉTAPE 05
Mettre à jour et redéployer
Poussez vos modifications sur votre branche principale GitHub et TradingHost relance automatiquement le déploiement.
Section 05 · Notes opérationnelles
Notes opérationnelles pour Bitget
Les pièges qui vous guettent lorsque vous exécutez réellement une stratégie Bitget dans un runtime cloud conteneurisé, absents de la documentation de Bitget ou des fichiers README des frameworks. Chaque point ci-dessous est cité ou paraphrasé de la documentation officielle de Bitget ; les conseils liés au déploiement sont issus de l'exploitation de ces stratégies sur TradingHost.
01 · Authentification à trois en-têtes
ACCESS-KEY, ACCESS-TIMESTAMP et ACCESS-SIGN sont tous requis
Les requêtes privées Bitget V2 comportent trois en-têtes : ACCESS-KEY (votre clé API), ACCESS-TIMESTAMP (timestamp Unix actuel en millisecondes) et ACCESS-SIGN (HMAC-SHA256 encodé en base64 combinant timestamp + méthode + requestPath + corps de la requête, signé avec votre clé secrète). Un quatrième en-tête, ACCESS-PASSPHRASE, est requis pour chaque requête signée. Les stratégies omettant l'un de ces quatre éléments renvoient des erreurs de signature non valide error 40009. La phrase secrète (passphrase) est définie lors de la création de la clé et ne peut plus être récupérée par la suite ; en cas de perte, la seule solution est de générer une nouvelle clé.
02 · Fenêtre de 30 secondes
Tout ACCESS-TIMESTAMP en dehors de la fenêtre de fraîcheur de 30 secondes est rejeté
Bitget rejette toute requête signée dont le paramètre ACCESS-TIMESTAMP diffère de plus de 30 secondes de l'heure du serveur Bitget. Les conteneurs présentant une dérive d'horloge supérieure à 30 secondes verront leurs requêtes signées refusées côté serveur, quelle que soit la validité de la signature. Les environnements d'exécution TradingHost sont synchronisés via NTP, ce qui rend cette tolérance de 30 secondes confortable. Néanmoins, un conteneur qui dérive (par exemple après une longue coupure réseau) doit resynchroniser son horloge avant de pouvoir signer à nouveau ses requêtes avec succès.
03 · De V1 à V2
La V2 est la génération actuelle de l'API ; les endpoints V1 restent documentés mais ne doivent pas être ciblés pour de nouvelles intégrations
Bitget a publié l'API V2 pour regrouper les endpoints spot, USDT-M, coin-M et de copy-trading sous un schéma de signature et un chemin de base uniques. Les endpoints V1 restent documentés pour des raisons de rétrocompatibilité, mais le flux des notes de mise à jour suit les dépréciations par rapport à la V2. Les nouvelles stratégies doivent cibler directement les endpoints V2 pour éviter d'hériter d'un calendrier d'obsolescence. Verrouillez la version de l'API dans votre client afin qu'une future transition vers la V3 soit une migration explicite et non une panne silencieuse.
SourceBitget V2 release notes04 · Hiérarchie du copy-trading
Les sous-comptes parents et abonnés héritent du stpGroupId ; les stratégies doivent savoir de quel côté elles s'exécutent
Les positions de copy-trading Bitget héritent du stpGroupId entre le compte d'un trader (parent) et ses abonnés (followers). Une stratégie s'exécutant sur un compte parent qui ouvre une position déclenche des ordres de copie sur chaque compte abonné lié, pondérés selon la configuration de l'abonné. Les stratégies qui ne doivent pas être copiées doivent s'exécuter sur un compte non-trader, ou explicitement s'exclure au niveau de la position. L'impact d'un compte parent de copy-trading mal configuré est considérable ; l'isolation des sous-comptes et la restriction des permissions par clé sont les bonnes pratiques de confinement.
SourceBitget API introduction05 · Restriction des clés
Une clé restreinte par stratégie, jamais de clé maîtresse partagée entre plusieurs stratégies
Les clés API Bitget disposent de restrictions par permission (lecture, trading spot, trading de futures, retraits). Les stratégies ne devraient jamais avoir besoin de la permission de retrait ; isolez les clés permettant les retraits dans des identifiants distincts gérés manuellement en dehors de l'environnement d'exécution des conteneurs. Des clés dédiées par stratégie, limitées aux seules permissions nécessaires, limitent l'impact en cas de fuite de clé. Bitget prend également en charge la mise sur liste blanche d'adresses IP par clé ; configurez-la si la plage d'adresses IP de sortie de l'environnement d'exécution est connue et stable pour la région choisie.
SourceBitget API introduction06 · Séparation du trading démo
Le trading démo partage l'interface V2 mais utilise des clés et des soldes distincts
Bitget propose le trading démo via la même interface d'endpoints V2 que la production ; la structure des requêtes est identique, mais le jeu de clés, les soldes et les positions sont isolés de la production. Une erreur fréquente et silencieuse consiste à déployer en production du code validé en démo sans remplacer le jeu de clés, ou inversement. Conservez les secrets de démo et de production dans des entrées de secrets TradingHost distinctes ; ne réutilisez jamais un secret d'un environnement à l'autre.
SourceBitget API introduction
Section 06 · Conçu pour
Conçu pour
Les runtimes TradingHost pour Bitget sont particulièrement adaptés aux :
- Développeurs concevant des stratégies dans des IDE IA (Cursor, Claude Code)
- Traders crypto systématiques
- Développeurs quantitatifs
- Utilisateurs de CCXT et Hummingbot
- Équipes migrant d'un hébergement VPS vers un déploiement conteneurisé
La connexion à GitHub et la création de votre première stratégie sont gratuites.
Section 08 · FAQ
FAQ
Non. TradingHost est indépendant et n'est pas affilié à Bitget.
Non. Le code de votre stratégie se connecte à Bitget et envoie des instructions selon votre propre logique, les permissions de votre compte et votre méthode d'intégration. TradingHost fournit l'environnement d'exécution où ce code s'exécute.
Non. L'accès à l'API de Bitget est fourni par Bitget. Vous êtes responsable de votre compte Bitget, des permissions de l'API, de vos identifiants et du respect des conditions d'utilisation de Bitget.
Non. TradingHost est l'environnement d'exécution cloud où s'exécute le code de votre stratégie. Nous ne fournissons pas de signaux, de modèles de prédiction IA ou de bots prêts à l'emploi. Avec TradingHost, vous écrivez ou générez vous-même la stratégie (souvent avec Cursor ou Claude Code), vous la conservez sur GitHub sous forme de code, et vous utilisez TradingHost pour l'exécuter en production. Des produits comme 3Commas ou Cryptohopper détiennent la logique de la stratégie ; TradingHost se charge d'exécuter la vôtre.
AWS et DigitalOcean vous fournissent de la puissance de calcul brute. Vous devez gérer vous-même les mises à jour de l'OS, l'orchestration des conteneurs, la centralisation des journaux, la rotation des secrets, le basculement de région et la surveillance de la disponibilité. TradingHost vous offre un environnement d'exécution managé, conçu spécifiquement pour les stratégies de trading : déploiement natif depuis GitHub, contrôle via MCP depuis vos IDE IA, ainsi que des interfaces de logs et de santé prêtes à l'emploi. Si vous préférez gérer l'infrastructure vous-même, AWS convient parfaitement. Si vous souhaitez un environnement d'exécution sous forme de service managé, TradingHost est la voie la plus rapide.
Oui. TradingHost exécute des stratégies en Python ; choisissez l'environnement d'exécution de framework qui correspond à votre stack ou déployez votre propre dépôt.
Oui. TradingHost prend en charge n'importe quel langage capable de s'exécuter dans un conteneur.
Oui. CCXT expose les marchés spot et perpétuels de Bitget via la classe unifiée `bitget`. Les endpoints de copy-trading n'étant pas des primitives natives de CCXT, ces flux s'exécutent directement via l'API native Bitget V2. Consultez l'environnement d'exécution du framework CCXT pour connaître tous les détails de configuration.
TradingHost est indépendant des plateformes au niveau de l'environnement d'exécution : tout code capable de s'authentifier auprès de Bitget peut s'exécuter dans un conteneur, y compris une stratégie hébergée sur un compte parent de copy-trading Bitget. Vous devez toutefois anticiper le fait que toute position ouverte par votre stratégie déclenchera des ordres de copie sur chaque compte abonné lié, selon leur configuration. Exécutez vos stratégies éligibles à la copie sur un sous-compte distinct de vos stratégies non publiques, et isolez les clés API par stratégie pour limiter l'impact en cas de problème.
Oui, si votre projet est conçu ainsi. Vous pouvez exécuter plusieurs processus ou services de stratégie au sein d'un même environnement d'exécution, ou les séparer dans différents environnements pour plus d'isolation et de clarté opérationnelle. Consultez la page de l'environnement d'exécution TradingHost pour découvrir le modèle multi-stratégie.
La méthode la plus rapide consiste à forker un environnement d'exécution de framework TradingHost : CCXT ou Hummingbot pour un projet prêt à être déployé. Vous pouvez également connecter votre propre dépôt de stratégie GitHub. Lier un dépôt GitHub et créer une stratégie est gratuit ; les abonnements pour les environnements d'exécution sont détaillés sur la page des tarifs.
Dans votre flux de gestion des secrets contrôlé par GitHub. TradingHost les lit lors de l'exécution via les secrets de dépôt GitHub, les secrets d'environnement ou votre propre processus approuvé de gestion des secrets. TradingHost n'a pas besoin de conserver votre clé API, votre secret ou votre phrase secrète. Consultez la section sur les secrets de la plateforme pour connaître l'intégralité du modèle de gestion.
Non. Les stratégies ne devraient jamais avoir besoin des permissions de retrait. Utilisez des permissions restreintes (lecture, trading spot, trading de futures) et la mise sur liste blanche d'adresses IP si nécessaire.
Oui. TradingHost prend en charge le contrôle basé sur MCP pour les IDE IA, notamment Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande. Les outils d'IA peuvent inspecter les déploiements, consulter les logs, redémarrer les stratégies et gérer les flux de travail de l'environnement d'exécution. MCP est une interface de contrôle et d'observabilité, et non le chemin d'exécution des transactions. Consultez la section sur l'interface de contrôle MCP pour en savoir plus.
Les deux. L'interface de contrôle MCP fonctionne aussi bien depuis des agents en ligne de commande (CLI de Claude Code, clients MCP personnalisés, appels MCP scriptés) que depuis un IDE. Le cycle de déploiement natif via GitHub fonctionne également sans aucun outil d'IA : un simple git push vers votre branche principale déclenche un redéploiement.
L'environnement d'exécution détecte le plantage et expose les logs et les informations de santé correspondantes. Lorsque cela est pris en charge, la stratégie concernée peut être redémarrée sans perturber les autres stratégies s'exécutant dans le même conteneur. Le code de votre stratégie reste responsable de la gestion sécurisée des erreurs, de la protection contre les ordres doublons et des contrôles de risques. Consultez la section observabilité pour en savoir plus sur l'interface de logs et de santé.
L'erreur Bitget 40009 signifie que la signature envoyée par votre stratégie ne correspond pas au HMAC-SHA256 attendu pour la chaîne timestamp + method + requestPath + body, signée avec votre clé secrète. Les causes fréquentes sont l'absence ou l'invalidité de l'en-tête ACCESS-PASSPHRASE, un ACCESS-TIMESTAMP en dehors de la fenêtre de validité de 30 secondes, l'utilisation d'une mauvaise clé secrète (clé de test au lieu de production) ou la signature d'un corps de requête canonique incorrect (espaces superflus, réorganisation des clés). Utilisez un SDK éprouvé ou effectuez des tests unitaires sur votre logique de signature en vous référant aux exemples de Bitget. Consultez la section Notes opérationnelles ci-dessus pour obtenir des instructions détaillées.
TradingHost est disponible dans les régions EU et US-East. Choisissez la région la plus proche du moteur d'appariement dont dépend votre stratégie. Consultez la page des régions pour plus de détails sur le routage et la proximité.
Non. TradingHost se concentre exclusivement sur l'exécution en production et le déploiement. Le backtesting relève de votre infrastructure de recherche, de votre framework ou d'AlgoBuilder.