Infrastructure cloud pour stratégies de trading
Aucun serveur à gérer. Pas de Kubernetes à apprendre. Aucun terminal à laisser ouvert.
Connectez un dépôt GitHub, choisissez une région, et votre stratégie de trading s'exécute sur l'infrastructure de TradingHost, conçue pour les charges de travail en continu. TradingHost gère le calcul, l'orchestration, le réseau d'exécution et les contrôles opérationnels sous-jacents. Vous restez concentré sur votre stratégie.
Ce que vous obtenez
- SLA d'infrastructure de 99,99 %
- Environnements d'exécution conteneurisés
- Déploiement multi-région
- Contrôles de redémarrage de l'environnement
- Logs en streaming
- Flux de travail natif GitHub
- Aucun serveur à gérer par le client
Section 01 · Le cloud managé, en clair
Nouveau dans l'infrastructure cloud managée ?
Si vous avez déjà exécuté une stratégie de trading sur un VPS, vous connaissez le travail que cela implique : se connecter à un serveur, installer des mises à jour, configurer des gestionnaires de processus, se battre avec des sessions de terminal, et redémarrer le tout à 3 heures du matin quand un problème survient. C'est à vous de jouer les baby-sitters avec le serveur.
L'infrastructure cloud managée change la donne. Vous confiez à la plateforme un morceau de code issu de votre dépôt GitHub. La plateforme l'exécute, le maintient actif et vous informe de ce qui se passe. Vous cessez d'être administrateur système pour redevenir trader ou développeur.
C'est exactement ce que propose TradingHost. Votre code réside sur GitHub, et l'infrastructure est notre affaire.
Définition du cloud managé
TradingHost exécute votre code de trading sur une infrastructure cloud managée. TradingHost gère les ressources de calcul, l'orchestration, le réseau d'exécution et les contrôles opérationnels sous-jacents à votre déploiement. Les clients n'accèdent pas aux serveurs hôtes physiques.
Section 02 · Fiabilité
SLA d'infrastructure de 99,99 % pour la couche sous-jacente à votre environnement d'exécution
TradingHost s'engage sur un SLA d'infrastructure de 99,99 % couvrant la disponibilité du réseau, du datacenter et de l'alimentation, sous réserve des conditions et exclusions du SLA.
TradingHost fournit un SLA d'infrastructure. La disponibilité de votre stratégie dépend également de votre propre code, des API des courtiers et des plateformes d'échange, de vos identifiants, de vos dépendances, des services tiers et de la récupération de l'état.
Le SLA de TradingHost s'applique uniquement à la couche d'infrastructure : disponibilité du réseau, du datacenter et de l'alimentation. Il ne garantit pas le bon fonctionnement continu du code utilisateur, des API des courtiers ou des plateformes d'échange, de GitHub, des services tiers, des identifiants, des dépendances ou de l'état en mémoire de la stratégie.
- Contrôles de redémarrage de l'environnement
- Si le processus d'une stratégie s'arrête de manière inattendue, TradingHost peut le redémarrer conformément à la politique de redémarrage de l'environnement d'exécution et signaler l'erreur dans vos logs. Le comportement de redémarrage dépend de la configuration de votre déploiement.
- Récupération de l'infrastructure
- Lorsque cela est pris en charge, la couche d'orchestration peut redémarrer ou replanifier les environnements d'exécution affectés lors d'incidents sur l'infrastructure sous-jacente. Votre stratégie doit néanmoins être conçue pour récupérer son état en toute sécurité après un redémarrage.
- Déploiement multi-région
- Vous choisissez la région dans laquelle réside votre environnement d'exécution. Si les performances d'une région se dégradent, vous pouvez redéployer votre stratégie dans une autre région en quelques secondes, depuis le tableau de bord ou depuis votre IDE IA via MCP.
Exclusions du SLA
Le SLA d'infrastructure ne s'applique pas lors des événements suivants. La liste complète est disponible dans nos Conditions générales.
- Fenêtres de maintenance planifiée et de maintenance d'urgence
- Migrations planifiées
- Suspension de compte ou résiliation du service
- Cas de force majeure
- Défaillances des fournisseurs en amont
- Problèmes liés au fournisseur d'accès Internet (FAI) du client
- Logiciels s'exécutant au sein des environnements d'exécution (runtimes) du client
- Attaques de tiers, virus et compromissions de serveurs
- Erreurs de manipulation ou d'activité de l'utilisateur
Section 03 · Aperçu rapide
TradingHost en dix lignes
Une vue d'ensemble de la plateforme, facile à parcourir. Chaque ligne renvoie à la section ou à la page détaillée correspondante.
- Infrastructure
- Cloud managé, basé sur des conteneurs.
- Ce que vous gérez
- Le code de vos stratégies, la logique de trading, la configuration des courtiers et des plateformes d'échange, ainsi que les contrôles de risque.
- Ce que TradingHost gère
- La puissance de calcul, le système d'exploitation, l'orchestration, le réseau de l'environnement d'exécution et les opérations d'infrastructure.
- Accès au serveur
- Aucun accès client aux serveurs d'hébergement sous-jacents.
- Isolation
- Les environnements d'exécution des clients sont isolés les uns des autres.
- Stratégies par environnement d'exécution
- Une ou plusieurs, selon la configuration de déploiement.
- Régions
- Multiples, voir Régions.
- Faut-il maîtriser Kubernetes ?
- Non.
- Modèle de fiabilité
- Contrôles de redémarrage de l'environnement d'exécution, suivi de l'état de santé, flux de journaux (logs) en temps réel et SLA d'infrastructure.
- SLA
- SLA d'infrastructure de 99,99 % couvrant le réseau, le centre de données et l'alimentation électrique, sous réserve d'exclusions.
Section 04 · Fonctionnement
Trois couches, une seule avec laquelle vous interagissez
Trois couches s'interposent entre vous et le cloud sous-jacent. Vous n'interagissez qu'avec une seule d'entre elles. Cette séparation est précisément le but recherché : vous écrivez votre code de trading, vous le poussez sur GitHub, et votre stratégie s'exécute. TradingHost gère la puissance de calcul, l'orchestration, le réseau de l'environnement d'exécution et les contrôles opérationnels sous votre déploiement.
Plan de contrôle
Ce que vous voyez. Le tableau de bord, le flux de déploiement, les journaux (logs) et le serveur MCP. C'est ici que se déroule chaque interaction client.
Environnement d'exécution (Runtime)
Le conteneur dans lequel votre stratégie s'exécute réellement. Configuré via votre dépôt GitHub et le flux de déploiement. Vous ne vous y connectez jamais directement.
Infrastructure
Puissance de calcul, orchestration, réseau de l'environnement d'exécution et contrôles opérationnels. Gérés par TradingHost. Les clients n'accèdent pas aux serveurs d'hébergement sous-jacents.
Section 05 · TradingHost vs VPS
Un VPS vous fournit un serveur. TradingHost offre à votre code un espace d'exécution dédié.
TradingHost n'est pas simplement un VPS plus esthétique. C'est une infrastructure conçue sur mesure pour le code de trading. Le tableau de bord, le moteur d'exécution, la gestion sécurisée des secrets et les contrôles de cycle de vie sont déjà intégrés et configurés.
Sur un VPS
- Vous gérez le serveur
- Connexion via RDP ou SSH
- Installation manuelle des dépendances
- Maintien actif des sessions de terminal
- Recherche fastidieuse des fichiers de log
- Mises à jour du système d'exploitation
- Redémarrage manuel en cas de plantage
- Centré sur le serveur
Sur TradingHost
- Vous gérez votre stratégie
- Utilisation du tableau de bord ou de l'MCP
- Définition directement dans votre dépôt
- Exécution dans des environnements gérés
- Flux de logs en direct sur le tableau de bord
- Nous gérons le système d'exploitation
- Redémarrages automatiques
- Centré sur la stratégie
Section 06 · Ce que vous n'avez plus à faire
Ce qui ne relève plus de votre responsabilité
Plus besoin de garder un terminal ouvert sur votre bureau ni de relancer vos scripts après un plantage. Nous nous occupons de tout.
- Systèmes d'exploitation
- Mises à jour du noyau
- Correctifs de sécurité
- Orchestrateurs de conteneurs
- Configuration réseau
- Pare-feux
- Surveillance du matériel
- Planification de la capacité
- Redémarrages
- Surveillance de l'état du système
Pas besoin non plus d'apprendre Kubernetes. Nous l'utilisons en arrière-plan car c'est l'outil idéal pour orchestrer des tâches de fond à grande échelle, mais il reste totalement invisible pour vous. Votre interface se résume à votre dépôt, une région et un bouton de déploiement.
Section 07 · Ce qui reste à votre charge
Les décisions de trading restent les vôtres
TradingHost exécute le code. Les décisions de trading, le modèle de risque et la connexion au courtier restent sous votre contrôle exclusif.
- Écrire la stratégie
- Vous connecter à votre courtier ou plateforme d'échange
- Définir les paramètres de risque
- Déterminer la taille des positions et la gestion des ordres
- Tester avant la mise en production
- Surveiller le comportement de vos algorithmes
Section 08 · Transparence
Les limites de notre service, sans détour
Aucune différence entre nos promesses et la réalité du produit.
Ce que couvre le SLA de 99,99 %
Le SLA de TradingHost s'applique uniquement à la couche d'infrastructure : disponibilité du réseau, du centre de données et de l'alimentation électrique. Il ne garantit pas le bon fonctionnement du code utilisateur, des API des courtiers ou des plateformes d'échange, de GitHub, des services tiers, des identifiants, des dépendances ou de l'état en mémoire de la stratégie.
La disponibilité de votre stratégie dépend également de votre code, des API des courtiers et plateformes d'échange, de vos identifiants, de vos dépendances, des services tiers et de la restauration de l'état. L'intégralité des conditions et exclusions de notre SLA est disponible dans nos Conditions générales d'utilisation.
- TradingHost ne fournit pas d'accès shell aux serveurs sous-jacents.
- TradingHost ne conserve pas l'état en mémoire de votre stratégie lors des redémarrages. Les stratégies doivent reconstruire leur état à partir des API du courtier ou d'un stockage externe.
- TradingHost ne garantit pas de latence spécifique vers des courtiers particuliers. La latence dépend de la région choisie, des conditions réseau et de l'infrastructure propre au courtier.
- TradingHost n'agit pas en tant que courtier ou plateforme d'échange. Votre stratégie s'y connecte directement.
FAQ
Questions fréquentes
Le SLA de 99,99 % couvre la disponibilité de l'infrastructure de TradingHost pour le réseau, le centre de données et l'alimentation électrique, sous réserve des conditions et exclusions du SLA. Il ne garantit pas la disponibilité du code de stratégie de l'utilisateur, des API des courtiers, des API des plateformes d'échange, des services tiers, des identifiants, des dépendances ou de l'état de la stratégie en mémoire.
Non. Le SLA s'applique à la couche d'infrastructure. Votre stratégie peut toujours échouer en raison d'erreurs de code, d'une mauvaise configuration, d'identifiants invalides, de pannes de courtier ou de plateforme d'échange, de limites de requêtes (rate limits), de problèmes de dépendances, de difficultés de récupération d'état ou d'erreurs de manipulation de l'utilisateur.
Oui. Les runtimes des clients sont isolés les uns des autres. Un runtime peut exécuter une ou plusieurs stratégies selon la configuration de déploiement, mais les stratégies de comptes clients différents ne partagent pas le même environnement d'exécution.
Non. Un VPS vous fournit un serveur distant que vous devez gérer vous-même. TradingHost exécute votre code de trading sur une infrastructure cloud managée. Vous connectez un dépôt GitHub et nous nous occupons du reste.
Non. TradingHost utilise Kubernetes en arrière-plan, mais vous n'avez jamais à le manipuler. Vous connectez GitHub, choisissez une région et déployez.
TradingHost signale la défaillance dans le statut de déploiement et les logs. Selon la configuration du runtime et le type de panne, le processus de la stratégie peut être redémarré automatiquement ou nécessiter une intervention de votre part.
Lorsque cela est possible, TradingHost peut redémarrer ou replanifier les runtimes affectés sur une infrastructure saine. Votre stratégie doit tout de même être conçue pour récupérer son état de manière sécurisée après un redémarrage.
Oui. Choisissez parmi les régions prises en charge lors du déploiement pour que votre runtime soit situé au plus près de votre courtier ou de votre plateforme d'échange. Consultez la page Régions pour voir la liste actuelle.
Non. L'état en mémoire ne doit jamais être considéré comme persistant. Votre stratégie doit reconstruire sa vision du marché à partir des API des courtiers, de bases de données externes ou de fichiers sauvegardés.
Non. TradingHost est une infrastructure managée. Vous gérez tout via le tableau de bord, le MCP et les logs d'exécution.
Déployez votre première stratégie
Connectez GitHub, choisissez une région, configurez votre runtime et déployez votre première stratégie sur l'infrastructure de TradingHost.