07 · Mise en production et supervision¶
Le passage en production est le moment où les problèmes qui n'existaient pas en backtest apparaissent tous en même temps.
L'hébergement¶
| Option | Latence vers CME | Coût | Disponibilité | Contrainte |
|---|---|---|---|---|
| Machine personnelle | 50-150 ms | 0 $ | Faible | Coupures, veille, mises à jour |
| VPS générique (Europe) | 100-200 ms | 10-30 $/mois | Bonne | Latence élevée |
| VPS Chicago | ~0,5-2 ms | 60-200 $/mois | Excellente | Interdit chez Topstep |
Les offres orientées trading annoncent une latence inférieure à 0,52 ms vers le CME depuis les centres de données de Chicago et Aurora (QuantVPS).
Vérifiez la règle avant d'acheter
Topstep interdit explicitement VPS, VPN et outils d'accès distant : toute activité doit se dérouler depuis votre propre appareil (AlgoProven). Un VPS acheté chez une firme qui l'interdit est au mieux un abonnement perdu, au pire un motif de fermeture de compte.
Si vous devez tourner depuis chez vous¶
- stops côté serveur obligatoires : une coupure internet ne doit pas laisser une position sans protection ;
- onduleur sur la machine ;
- connexion de secours (partage 4G) avec basculement automatique ;
- désactivation des mises à jour automatiques et de la mise en veille ;
- alerte externe (téléphone) si le bot cesse d'émettre son signal de vie.
La supervision¶
Le signal de vie¶
async def heartbeat(chemin="/tmp/bot.alive", periode=10):
"""Écrit un horodatage régulièrement. Un processus externe surveille
la fraîcheur du fichier."""
while True:
with open(chemin, "w") as f:
f.write(str(time.time()))
await asyncio.sleep(periode)
Surveillance externe, en trois lignes de shell :
# à mettre en cron toutes les minutes
age=$(( $(date +%s) - $(cat /tmp/bot.alive) ))
[ "$age" -gt 60 ] && notifier "bot muet depuis ${age}s"
La surveillance doit être externe au bot
Un bot qui se surveille lui-même ne détecte pas son propre plantage. Le processus qui vérifie doit être différent de celui qui trade. Un cron et un fichier suffisent : pas de service de supervision, pas d'agent, pas de dépendance supplémentaire qui peut elle-même tomber.
Les alarmes indispensables¶
| Alarme | Seuil | Gravité |
|---|---|---|
| Bot muet | > 60 s sans heartbeat | Critique |
| Absence de données | > 30 s sans tick en séance | Critique |
| Ordre rejeté | 1 occurrence | Haute |
| Divergence de position | 1 occurrence | Critique |
| Perte journalière | 70 % du plafond | Haute |
| Drawdown disponible | < 40 % | Haute |
| Latence de traitement | > 500 ms | Moyenne |
| Fréquence de signaux anormale | ±50 % vs référence | Moyenne |
L'absence de données est l'alarme la plus importante
Un bot qui ne reçoit plus de données ne plante pas : il attend, poliment, indéfiniment. Le heartbeat continue, le processus est vivant, rien n'indique d'anomalie — et le bot ne trade plus, ou pire, gère une position ouverte avec des prix périmés.
C'est le mode de panne le plus fréquent et le plus silencieux. Il survient après un rollover mal géré, une souscription perdue lors d'une reconnexion, ou une coupure côté fournisseur.
Le tableau de bord minimal¶
Un fichier texte suffit :
def etat_texte(bot):
return f"""
état : {bot.etat}
symbole : {bot.symbole}
position : {bot.position.taille} @ {bot.position.prix_entree}
P&L jour : {bot.pnl_jour:+.2f} $
trades jour : {bot.trades_jour} / {bot.config.max_trades_jour}
drawdown dispo: {bot.compte.drawdown_disponible:.0f} $ ({bot.ratio_dd:.0%})
plafond consis: {bot.plafond_consistance:+.2f} $
dernier tick : il y a {bot.age_dernier_tick:.1f} s
latence médiane: {bot.latence_mediane_ms:.1f} ms
"""
Consultable en SSH depuis un téléphone. Pas d'interface web à maintenir, pas de serveur supplémentaire qui tombe.
Le déploiement progressif¶
| Étape | Durée | Objectif |
|---|---|---|
| 1. Rithmic Test, sans ordres | 5 séances | Valider le flux, la latence, l'agrégation |
| 2. Rithmic Test, ordres simulés | 10 séances | Valider la logique complète |
| 3. Paper Trading | 20 séances | Valider contre le backtest |
| 4. Évaluation, 1 contrat | 20 séances | Valider avec de l'argent réel |
| 5. Évaluation, taille normale | — | — |
| 6. Compte financé | — | — |
Ne sautez pas l'étape 1
Cinq séances à seulement recevoir et journaliser révèlent : le vrai débit de messages, les heures de creux, les déconnexions, la latence réelle, les anomalies de données. Ces informations changent souvent les paramètres de la stratégie — et il vaut mieux les découvrir avant d'avoir codé l'exécution.
Le rituel quotidien¶
Avant la séance (10 min)
□ le bot est-il vivant ? heartbeat récent ?
□ le contrat souscrit est-il le bon (rollover) ?
□ le drawdown disponible et le plafond de consistance sont-ils à jour ?
□ y a-t-il une publication macro majeure aujourd'hui ?
□ les positions de la veille sont-elles bien fermées ?
Pendant la séance
□ vérifier l'état toutes les heures
□ ne pas intervenir sur une position ouverte sans raison technique
Après la séance (15 min)
□ comparer le nombre de signaux à la référence
□ vérifier les rejets d'ordres
□ vérifier les divergences de position
□ archiver le journal
□ mettre à jour le P&L cumulé et le plafond de consistance
« Ne pas intervenir sans raison technique »
L'intervention discrétionnaire sur un bot est le mécanisme par lequel un système testé redevient du trading discrétionnaire — avec en prime la frustration de voir la machine avoir raison après votre intervention.
Deux raisons valides d'intervenir : un bug avéré, ou une anomalie de marché hors du domaine de validité testé. « Je sens que ce trade est mauvais » n'en est pas une. Si vous ne pouvez pas vous en empêcher, c'est un signe que le dimensionnement est trop grand pour votre tolérance : réduisez la taille, pas la systématicité.
La revue hebdomadaire¶
| Question | Donnée à examiner |
|---|---|
| La fréquence des signaux est-elle stable ? | Signaux/séance sur 4 semaines |
| Le taux de réussite dérive-t-il ? | Sur les 50 derniers trades |
| Le slippage réel correspond-il au modèle ? | Prix demandé vs prix obtenu |
| Quelle zone produit les meilleurs résultats ? | Ventilation par champ reason |
| Quel créneau horaire ? | Ventilation horaire |
| Un seuil d'arrêt est-il approché ? | Cf. filtres et risque |
La ventilation par reason est ce qui rend cette revue possible — d'où
l'importance de remplir ce champ dès le premier jour.
Analyser, oui ; modifier chaque semaine, non
Une modification hebdomadaire de paramètres sur la base de 30 trades est du surajustement en temps réel. Fixez à l'avance la cadence de révision — par exemple mensuelle, et sur 100 trades minimum — et tenez-vous-y.
Les erreurs de production classiques¶
| Erreur | Conséquence | Prévention |
|---|---|---|
| Fuseau horaire mal géré | Trading hors créneau | Tout en UTC en interne |
| Symbole en dur | Panne silencieuse au rollover | Calendrier + alarme données |
| Pas de limite de trades | 400 trades sur un bug | Compteur journalier |
| Pas d'idempotence | Positions doublées | Clé déterministe |
| Reconnexion sans réconciliation | État divergent | Réconciliation obligatoire |
| Journal en mémoire seulement | Aucun diagnostic après plantage | Append-only sur disque |
| Stop côté client uniquement | Position nue après coupure | Bracket côté serveur |
Résumé¶
- Vérifiez la règle VPS de votre firme avant d'acheter un VPS.
- Heartbeat surveillé par un processus externe.
- L'alarme « absence de données » est la plus importante : la panne silencieuse est le mode d'échec dominant.
- Déploiement en six étapes, sans sauter l'étape d'observation pure.
- Rituel quotidien avant/pendant/après séance.
- Analyse hebdomadaire, modification mensuelle au plus.
- Tout en UTC en interne.
Chapitre précédent : Données historiques et backtest · Partie suivante : Économie