Temps de lecture : … min

Vous gardez les clés. TradingHost exécute le code.

TradingHost est l'environnement d'exécution de vos stratégies de trading automatisées, pas un coffre-fort pour vos identifiants de courtiers ou de plateformes d'échange.

Conservez vos clés API, secrets de signature, phrases de passe et jetons de fournisseurs de données dans le gestionnaire de secrets auquel vous faites déjà confiance. TradingHost fournit à votre stratégie un chemin d'accès au runtime pour lire les valeurs requises, sans intégrer de fichiers .env dans vos déploiements, coder en dur vos identifiants sur GitHub ou les coller dans le tableau de bord TradingHost.

Pas de fichiers .env dans vos images. Pas de clés de courtiers codées en dur. Pas d'identifiants de plateformes d'échange collés dans le tableau de bord.

Gestion des secrets

  • Pas de conservation des secrets
  • Gestionnaires de secrets externes
  • Variables d'environnement au runtime
  • Déploiements natifs depuis GitHub
  • Rotation gérée par le client
  • Piste d'audit gérée par le client
  • Vos identifiants de courtiers et de plateformes d'échange restent les vôtres

Section 01 · Positionnement

TradingHost est l'environnement d'exécution, pas le coffre-fort.

TradingHost exécute le code de vos stratégies au sein d'environnements d'exécution cloud managés. Vos clés de courtiers, clés API de plateformes d'échange, secrets de webhooks, clés de signature et jetons de données tiers doivent rester dans votre propre gestionnaire de secrets.

Votre gestionnaire de secrets reste l'unique source de vérité. Votre environnement d'exécution reçoit les valeurs nécessaires au démarrage de la stratégie. Votre stratégie lit ensuite ces valeurs via des variables d'environnement ou un modèle de récupération (fetch) documenté au runtime.

TradingHost fournit le flux de déploiement, l'environnement d'exécution, les logs, les contrôles de santé, la gestion des ressources, le choix des régions et l'interface de contrôle MCP autour de votre stratégie. Il n'a pas vocation à devenir le lieu de stockage de vos identifiants de trading.

Cela permet de maintenir un périmètre de sécurité simple :

CoucheResponsabilité
Votre gestionnaire de secretsConserve les identifiants, contrôle les accès et enregistre l'historique d'audit.
Runtime TradingHostExécute la stratégie et expose les valeurs requises au processus.
Votre stratégieLit les valeurs et se connecte au courtier, à la plateforme d'échange ou au fournisseur de données.
Courtier ou plateforme d'échangeAuthentifie la clé API et applique les autorisations au niveau du compte.

Le résultat est un modèle de production plus propre pour le trading automatisé : votre code s'exécute sur TradingHost, tandis que la garde de vos identifiants reste sous votre entière responsabilité.

Section 02 · Qu'est-ce qu'un secret ?

Toute valeur privée dont votre stratégie a besoin pour s'exécuter.

Un secret est toute valeur qui, en cas de fuite, permet d'accéder à un compte, un service, une connexion ou un flux de trading.

Exemples courants :

  • Clés API de courtiers
  • Clés API de plateformes d'échange
  • Secrets d'API
  • Clés de signature
  • Phrases de passe
  • Secrets de webhook
  • Jetons de données de marché
  • Mots de passe de base de données
  • Identifiants de point de terminaison privé
  • Secrets client OAuth
  • Jetons de service interne

Un identifiant est un type spécifique de secret utilisé pour s'authentifier auprès d'un courtier, d'une plateforme d'échange, d'un fournisseur de données, d'une base de données ou d'un service tiers.

La plupart des identifiants de trading ne se résument pas à une seule valeur. Ils peuvent inclure une clé, un secret, une phrase de passe, un identifiant de compte, un identifiant de sous-compte, un nom d'environnement ou un périmètre d'autorisation.

TradingHost traite ces éléments comme des entrées d'exécution, et non comme des données produit.

Section 03 · Comment les secrets atteignent un runtime

De votre gestionnaire de secrets à votre stratégie en cours d'exécution.

Le flux d'exécution est volontairement familier. Il fonctionne de la même manière que le déploiement d'applications en production, les pipelines CI et les charges de travail cloud modernes.

  • Étape 1

    Stocker l'identifiant

    Conservez l'identifiant du courtier ou de la plateforme d'échange dans le gestionnaire de secrets que vous utilisez déjà. Il peut s'agir des secrets GitHub Actions, de HashiCorp Vault, d'AWS Secrets Manager, de Doppler, de 1Password Secrets Automation, d'Infisical, de Bitwarden Secrets Manager ou d'un autre gestionnaire compatible. Votre gestionnaire de secrets reste la source unique de vérité.

  • Étape 2

    Déployer le runtime

    Votre déploiement piloté par GitHub démarre le runtime TradingHost. Le runtime reçoit les valeurs dont votre stratégie a besoin via le modèle de transmission de secrets configuré. Pour la plupart des stratégies, ces valeurs sont exposées sous forme de variables d'environnement au démarrage.

  • Étape 3

    Démarrer la stratégie

    Votre stratégie lit les variables, se connecte au courtier, à la plateforme d'échange, au fournisseur de données de marché ou au service interne, puis commence à s'exécuter au sein du runtime TradingHost. La relation de trading reste établie directement entre votre stratégie et la plateforme.

Section 04 · Gestionnaires de secrets compatibles

Utilisez un gestionnaire de secrets auquel vous faites déjà confiance.

TradingHost est conçu pour s'intégrer à des sources de secrets externes. Vous n'avez pas besoin de transférer tous les identifiants de vos courtiers ou plateformes d'échange vers un coffre-fort appartenant à TradingHost simplement pour exécuter une stratégie.

Les fournisseurs ci-dessous représentent les modèles de gestion de secrets documentés en priorité par TradingHost.

Gestionnaire de secretsIdéal si
GitHub Actions secretsSi GitHub est déjà votre source unique de vérité pour le code et les flux de déploiement.
HashiCorp VaultSi vous utilisez déjà Vault pour vos politiques, vos secrets dynamiques, vos jetons à courte durée de vie ou HCP Vault.
AWS Secrets ManagerSi vous évoluez dans l'écosystème AWS et vous appuyez sur IAM, la rotation managée et les outils d'audit AWS.
DopplerSi vous souhaitez un tableau de bord simple pour centraliser vos secrets sur différents environnements.
1Password Secrets AutomationSi vous utilisez déjà les coffres-forts 1Password pour la gestion de vos identifiants.
InfisicalSi vous préférez une plateforme de secrets open source avec des options d'auto-hébergement.
Bitwarden Secrets ManagerSi vous utilisez déjà Bitwarden pour vos flux de mots de passe et de secrets.
Utilisez votre propre solutionTout gestionnaire compatible capable d'exposer des valeurs via des variables d'environnement ou un modèle de récupération au runtime.

TradingHost ne vous oblige pas à abandonner votre configuration de sécurité actuelle. Si vous disposez déjà d'un gestionnaire de secrets, d'un modèle d'accès, d'un rythme de rotation et d'un historique d'audit, l'objectif est de continuer à les utiliser.

Section 05 · En un coup d'œil

Le modèle de gestion des secrets, en clair.

QuestionRéponse
Qui en a la garde ?Le client.
Où doivent résider les secrets ?Dans le secret store choisi par le client.
Est-ce que TradingHost est le secret store ?Non.
Les secrets doivent-ils être commités sur GitHub ?Non.
Les fichiers .env doivent-ils être embarqués dans les images ?Non.
Comment une stratégie lit-elle les secrets ?Par des variables d'environnement ou des méthodes de récupération au runtime documentées.
Qui effectue la rotation des identifiants ?Le client, via son secret store ou son compte de broker / d'exchange.
Qui révoque les identifiants compromis ?Le client, via le secret store, le broker, l'exchange ou le fournisseur de données.
Où se trouve la piste d'audit ?Principalement dans le secret store, chez le broker, sur l'exchange et dans l'historique des déploiements.
Les secrets peuvent-ils apparaître dans les logs ?Uniquement si la stratégie les affiche, ce qu'elle ne doit jamais faire.
Que voit TradingHost ?Les métadonnées d'exécution, l'état du déploiement, les indicateurs de santé et les logs émis par le processus.
Que peut voir l'équipe de TradingHost ?Aucune interface interne n'expose les identifiants de broker ou d'exchange des clients aux équipes de TradingHost.

La distinction essentielle est simple :

TradingHost exécute le processus. Votre secret store gère les identifiants.

Section 06 · Ce dont TradingHost n'a pas besoin

Pas de dispersion d'identifiants pour exécuter une stratégie.

Un runtime de trading ne devrait pas nécessiter la dispersion de copies d'identifiants sensibles sur des ordinateurs portables, des tickets de support, des captures d'écran, des messages de chat, des outils d'assistance, des dépôts de code ou des fichiers .env non gérés.

Avec TradingHost, vous n'avez pas besoin de :

  • Écrire en dur des clés de broker dans un dépôt de code
  • Embarquer des fichiers .env dans des images de conteneur
  • Coller des identifiants d'exchange dans un tableau de bord générique
  • Envoyer des clés API à l'équipe de support
  • Stocker des secrets de production dans des feuilles de calcul
  • Vous connecter en SSH à un serveur uniquement pour modifier des variables d'environnement
  • Partager des clés par chat ou par e-mail
  • Copier manuellement des identifiants d'un environnement à un autre
  • Laisser d'anciennes clés actives parce que vous avez perdu la trace de l'endroit où elles sont utilisées

Le modèle le plus propre consiste à conserver les secrets dans un emplacement de confiance unique, et à laisser le runtime recevoir uniquement ce dont la stratégie a besoin.

Section 07 · Ce qui reste sous votre contrôle

La gouvernance des identifiants reste sous votre contrôle.

TradingHost fournit le runtime. Vous gardez le contrôle des décisions relatives aux identifiants sensibles.

C'est vous qui décidez :

  • Quel secret store utiliser
  • Quelle stratégie peut accéder à quel identifiant
  • À quel compte de broker ou d'exchange appartient une clé
  • Le fait d'autoriser ou non une clé à passer des ordres, lire les soldes, consulter les positions ou retirer des fonds
  • La fréquence de rotation des identifiants
  • Qui peut afficher ou modifier les secrets de production
  • La gestion de la révocation
  • Le lieu de consultation et d'analyse des journaux d'audit
  • Quels environnements peuvent accéder aux identifiants de production
  • L'utilisation ou non de clés distinctes pour le développement, le staging et la production

C'est un point crucial pour l'infrastructure de trading, car les permissions d'API ont un impact financier direct. Une clé de courtier ou de plateforme d'échange peut donner accès aux soldes, aux positions ouvertes, à la transmission d'ordres, à l'historique du compte ou aux fonctions de retrait.

TradingHost ne doit pas compliquer la gouvernance de ces permissions.

Section 08 · Comportement du runtime

Votre stratégie lit les secrets comme n'importe quelle application en production.

Une stratégie déployée sur TradingHost doit traiter les secrets comme des configurations d'exécution (runtime).

Par exemple :

  • Stratégie crypto

    • EXCHANGE_NAME
    • EXCHANGE_API_KEY
    • EXCHANGE_API_SECRET
    • EXCHANGE_API_PASSPHRASE
    • TRADING_MODE

  • Stratégie connectée à un courtier

    • BROKER_NAME
    • BROKER_ACCOUNT_ID
    • BROKER_API_KEY
    • BROKER_API_SECRET
    • BROKER_ENVIRONMENT

  • Stratégie de données de marché

    • DATA_PROVIDER
    • DATA_API_KEY
    • DATA_REGION
    • DATA_FEED

Les noms exacts des variables sont définis par votre projet, votre framework, votre connecteur ou votre workflow de déploiement.

TradingHost n'a pas besoin de connaître la valeur privée elle-même. Il lui suffit de fournir au processus en cours d'exécution un moyen d'accéder à la configuration attendue.

Section 09 · Logs et observabilité

Les secrets ne doivent jamais être écrits dans les logs.

TradingHost fournit des logs d'exécution et une visibilité sur l'état de santé de vos stratégies, vous permettant de voir si elles s'exécutent, échouent, redémarrent, se connectent ou émettent des erreurs.

Ces logs sont indispensables pour l'exploitation en production, mais ils ne constituent pas un emplacement sécurisé pour des secrets.

Votre stratégie ne doit jamais écrire :

  • Clés API
  • Secrets d'API
  • Payloads de signature
  • Phrases secrètes (passphrases)
  • En-têtes d'authentification
  • Jetons Bearer
  • Secrets de webhook
  • Chaînes de connexion complètes
  • Dumps bruts de l'environnement
  • Jetons de session de courtier
  • Réponses d'authentification des plateformes d'échange

TradingHost affiche les logs émis par votre processus. Si une stratégie écrit un secret dans stdout, stderr, des traces de pile (stack traces), des sorties de débogage ou des payloads d'erreur, cette valeur peut devenir visible dans les logs d'exécution.

La pratique la plus sûre consiste à journaliser l'état de la connexion, et non les identifiants.

  • Correct

    • Connecté au compte spot Binance.

  • Incorrect

    • Connecté à Binance avec la clé API abc123...

Section 10 · Limite de sécurité

La limite de sécurité, clairement définie.

TradingHost ne doit pas être considéré comme le système de référence pour les identifiants de courtiers ou de plateformes d'échange.

Vos identifiants doivent résider dans votre propre coffre-fort de secrets, régis par vos propres contrôles d'accès, politiques de rotation et processus d'audit.

TradingHost ne requiert jamais de commiter des secrets sur GitHub, de les intégrer dans des images de déploiement, de les ajouter à des fichiers .env dans le conteneur ou de les partager avec le support technique.

TradingHost fournit la couche d'exécution (runtime) autour de la stratégie. Votre stratégie utilise le modèle de transmission configuré pour accéder aux valeurs requises. Votre courtier, plateforme d'échange, fournisseur de données ou service interne reste le système qui authentifie l'identifiant et applique les permissions au niveau du compte.

Cette séparation est précisément le but recherché.

TradingHost exécute le code.
Vous contrôlez les clés.

Ressources associées

Pour aller plus loin

FAQ

Questions fréquentes

TradingHost est conçu pour que votre gestionnaire de secrets reste l'unique source de vérité pour vos identifiants de brokers et d'exchanges. Le runtime reçoit les valeurs requises par votre stratégie via un mécanisme de transmission sécurisé, sans vous demander de coder les clés en dur ni d'intégrer des fichiers .env dans vos images.

Non. Les clés de brokers, clés API d'exchanges, phrases de passe, clés de signature et jetons de fournisseurs de données ne doivent jamais être commités dans un dépôt. Utilisez les secrets GitHub Actions, un gestionnaire de secrets externe ou une autre méthode documentée pour injecter vos secrets au runtime.

Votre image de déploiement ne doit pas contenir de fichier .env avec des identifiants actifs. Les secrets doivent être fournis au moment de l'exécution (runtime), et non intégrés au code source ou à l'image.

La plupart des stratégies lisent les secrets depuis des variables d'environnement au démarrage. Selon la configuration de votre workflow de déploiement, certaines structures récupèrent dynamiquement les secrets au runtime depuis Vault, AWS Secrets Manager, Doppler, 1Password, Infisical, Bitwarden ou un autre gestionnaire compatible.

Le renouvellement s'effectue dans votre gestionnaire de secrets ou directement auprès du broker, de l'exchange ou du fournisseur de données. Une fois l'identifiant renouvelé, redémarrez ou redéployez le runtime concerné pour que la stratégie reçoive la nouvelle valeur.

Révoquez l'identifiant dans le système qui l'a généré. Pour les clés de trading, il s'agit généralement du broker, de l'exchange, du fournisseur de données ou d'un service interne. Vous devez également supprimer ou remplacer cette valeur dans votre gestionnaire de secrets.

Uniquement si votre stratégie les affiche. TradingHost restitue les logs émis par votre processus : vos stratégies ne doivent donc jamais afficher d'identifiants, de dumps d'environnement, d'en-têtes d'authentification, de jetons, de phrases de passe ou de chaînes de connexion brutes.

TradingHost ne propose aucune interface permettant à son personnel de consulter les identifiants de brokers ou d'exchanges des clients. Votre propre gestionnaire de secrets doit rester l'unique espace de contrôle et d'audit des accès à vos identifiants.

Oui. TradingHost est conçu pour s'intégrer à des sources de secrets externes. Si votre gestionnaire de secrets peut exposer des valeurs via des variables d'environnement ou un mécanisme de récupération documenté au runtime, il est généralement compatible avec le modèle de déploiement de TradingHost.

TradingHost documente les configurations pour les secrets GitHub Actions, HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation, Infisical et Bitwarden Secrets Manager.

Utilisez votre propre gestionnaire de secrets. Déployez avec GitHub.

Connectez GitHub, configurez votre runtime et associez votre stratégie au gestionnaire de secrets de votre choix.

TradingHost exécute le code.
Vous gardez les clés.