Pourquoi Passer aux WebSockets pour Surveiller Vos Bots de Trading ?

Quand on rafraîchit sa boîte mail pour vérifier si un message est arrivé, on fait exactement ce que font nos bots de trading avec les exchanges : demander régulièrement si quelque chose a changé. Parfois il y a du nouveau, parfois non. À l'inverse, une notification push arrive toute seule, au moment exact où le message est reçu. Pas besoin de vérifier, l'information vient à nous.

En trading algorithmique, cette même distinction existe. On peut interroger l'exchange à intervalles réguliers (envoyer une requête pour placer un ordre, récupérer le solde, les bougies, etc.), ou bien ouvrir une connexion permanente et laisser l'exchange nous envoyer les mises à jour en temps réel. Cette deuxième approche repose sur un protocole appelé WebSocket.

Nous allons justement explorer comment les WebSockets fonctionnent et comment les utiliser en trading, avec un petit script Python pour écouter en temps réel les ouvertures et évolutions de positions sur notre compte futures.

REST API vs WebSocket : Deux Modes de Communication en Trading

Précisons les deux approches. Avec une API REST, l'utilisateur envoie une requête sur une URL, le serveur répond, et la connexion se ferme. Tout ça avec deux types de requêtes pour tout faire : GET pour lire des données (récupérer le solde, les bougies, l'état d'une position) et POST pour envoyer une action (placer un ordre, annuler un ordre). Par exemple, pour suivre l'état d'un compte, il faut envoyer des requêtes GET à intervalles réguliers (on parle de polling). C'est simple à implémenter, et on peut même tester une URL GET directement dans un navigateur pour voir la réponse. Suffisant pour beaucoup de cas d'usage. Les sites et applications web fonctionnent tous sur ce principe.

Un WebSocket passe aussi par une URL, mais avec un protocole différent : wss:// au lieu de https:// (le s signifie sécurisé, comme en HTTPS). Cette URL ne peut pas être ouverte dans un navigateur : elle ouvre un canal de communication persistant, pas une page. Il faut du code (ou un outil dédié) pour s'y connecter. La distinction GET/POST n'existe pas en WebSocket : il n'y a qu'un seul concept, envoyer un message. En pratique, tous les WebSockets ne fonctionnent pas dans les deux sens. Le flux de positions que nous utiliserons plus bas, par exemple, va dans un seul sens : de l'exchange vers nous. On s'y abonne (on subscribe), puis on écoute, on ne poste rien. D'autres WebSockets, sur certaines plateformes, autorisent aussi l'envoi de messages depuis le bot, par exemple pour placer un ordre. En contrepartie de cette connexion persistante, il faut gérer la reconnexion en cas de coupure et le ping/pong pour maintenir le lien, mais les SDK modernes s'en chargent. En termes d'infrastructure et de performance, c'est beaucoup plus lourd.

Par contre, ces deux approches sont tout à fait complémentaires dans le trading et peuvent coexister pour donner des automatisations très sophistiquées. Par exemple, un bot qui trade sur des bougies de 15 minutes n'a pas besoin de WebSocket pour placer ses ordres ou récupérer son solde : une requête REST toutes les 15 minutes fait très bien l'affaire. Mais ce même bot peut être complété par un service WebSocket indépendant qui écoute les positions d'un ou plusieurs comptes en continu, envoie des notifications, voire met à jour un fichier de configuration (des paramètres de risque, par exemple) que tel ou tel bot lira à sa prochaine exécution. Ce ne sont que quelques exemples : les combinaisons possibles entre REST et WebSocket sont très larges, et dépendent du setup et des besoins.

Les Streams WebSocket en Trading : Publics et Privés

Les exchanges crypto proposent généralement deux catégories de flux WebSocket.

Les streams publics ne nécessitent pas d'authentification. On y trouve les prix en temps réel (ticker), les trades exécutés sur le marché, et l'order book (le carnet d'ordres). Ce dernier montre tous les ordres d'achat et de vente en attente à chaque niveau de prix. L'order book est notamment utilisé en HFT (High-Frequency Trading) et en market making, où le volume de messages peut être très élevé sur les paires liquides (il faut une grosse infrastructure pour gérer ça).

Les streams privés nécessitent une authentification par clé API. C'est là que se trouvent les données personnelles du compte :

Avec les streams privés, on peut savoir quasi instantanément quand une position s'ouvre ou se ferme, suivre le prix d'entrée et le prix de liquidation, et déclencher des alertes. En combinant avec un flux de prix public, on peut même calculer le PnL (Profit and Loss) en continu et réagir si un seuil est franchi. L'information arrive dès que l'événement se produit sur l'exchange, sans aucune requête à envoyer.

Écouter Ses Positions Futures en Python avec BitMart

Passons à la pratique. Le script ci-dessous se connecte au WebSocket privé futures de BitMart et affiche chaque mise à jour de position reçue. On utilise le SDK officiel bitmart-python-sdk-api qui gère l'authentification, la reconnexion automatique et le ping/pong.

Installation :

pip install bitmart-python-sdk-api

Le code :

from bitmart.lib.cloud_consts import FUTURES_PRIVATE_WS_URL
from bitmart.websocket.futures_socket_client import FuturesSocketClient

# Cette fonction est appelée automatiquement chaque fois que l'exchange
# envoie un message. Ici, on filtre sur le channel "futures/position"
# et on affiche les infos clés de chaque position mise à jour.
def on_message(message):
    group = message.get("group", "")
    if group == "futures/position":
        for pos in message["data"]:
            side = "long" if pos['position_type'] == 1 else "short"
            print(
                f"{pos['symbol']} | {side} | "
                f"size={pos['hold_volume']} | "
                f"entry={pos['open_avg_price']} | "
                f"liq={pos['liquidate_price']}"
            )

# On se connecte au WebSocket privé futures de BitMart.
# Le SDK ouvre un thread dédié, gère le ping/pong automatiquement,
# et se reconnecte tout seul si la connexion tombe.
client = FuturesSocketClient(
    stream_url=FUTURES_PRIVATE_WS_URL,
    on_message=on_message,
    api_key="...",          # Clé API (confidentielle !)
    api_secret_key="...",   # Clé secrète (confidentielle !)
    api_memo="...",         # Memo du compte
)

# Authentification : le SDK signe avec HMAC-SHA256
client.login(timeout=5)

# On s'abonne au channel position : à partir de maintenant,
# chaque ouverture, modification ou clôture de position
# déclenchera un appel à on_message.
client.subscribe(args="futures/position")

Deux points à savoir qui ne se voient pas dans le code. D'abord, les valeurs numériques (hold_volume, open_avg_price, liquidate_price) arrivent sous forme de chaînes de caractères, pas de nombres : il faut les convertir avec float() pour faire des calculs. Ensuite, ce script concerne les futures, pas le spot : le SDK et les channels diffèrent entre les deux.

Construire Sur Cette Base : Monitoring, Alertes et Dashboards

Ce script d'une vingtaine de lignes est un point de départ. À partir de là, on peut formater les données proprement, les envoyer vers Discord ou Telegram pour être notifié à distance, ou alimenter un dashboard de suivi. On peut aussi y greffer de la logique de risk management : en combinant avec un flux de prix, calculer le PnL et déclencher une action automatique si un seuil est franchi.

En s'abonnant à futures/order en plus de futures/position, on obtient une vue complète de l'activité du compte. Et avec futures/asset:USDT, on suit l'évolution du solde disponible.

Le monitoring en temps réel est une brique à part entière dans un setup de trading algorithmique. On investit du temps dans les stratégies, les backtests, l'optimisation des paramètres, et la supervision du bot en production mérite la même attention. Les WebSockets permettent de garder un œil sur ce qui se passe sans consommer de quota sur l'API REST de l'exchange.