Webhooks TradingView vers l'API de votre broker

Section 01 · Fonctionnement global

Quatre éléments, une seule boucle

L'ensemble du workflow repose sur quatre outils effectuant chacun une tâche précise. TradingView décide quand trader. GitHub stocke le code du récepteur. TradingHost exécute ce code dans le cloud et héberge l'URL du webhook. Le broker exécute l'ordre. Une fois que vous avez identifié le rôle de chaque outil, le reste de ce guide n'est qu'une formalité.

Section 02 · En un coup d'œil

En un coup d'œil

Section 03 · Rédiger du Pine Script avec l’IA

Programmez la stratégie en binôme avec Claude ou ChatGPT

Pine Script est un langage léger et bien documenté, et la génération actuelle de grands modèles de langage a assimilé la documentation publique de Pine Script v6 de TradingView. Décrivez votre stratégie en langage naturel dans Claude ou ChatGPT (ou dans Cursor avec l’un de ces modèles) : ce qu’il faut surveiller, ce qui déclenche un achat (long), ce qui déclenche une vente (short), comment dimensionner l’ordre et quand sortir. Copiez-collez le code généré dans le Pine Editor de TradingView et laissez l’éditeur signaler les éventuelles erreurs de syntaxe.

Deux points essentiels à préciser au modèle. Premièrement, demandez-lui un script de stratégie Pine Script (il doit déclarer strategy() au lieu de indicator()), car seules les stratégies exposent les placeholders {{strategy.order.action}} et {{strategy.order.contracts}} dont vous aurez besoin dans le corps du webhook. Deuxièmement, demandez au modèle de déclencher ses entrées avec strategy.entry() et ses sorties avec strategy.close(), et d’écrire les notifications ponctuelles avec la fonction alert() plutôt qu’avec alertcondition() ; la fonction moderne alert() expose les mêmes placeholders de stratégie et accepte un argument freq qui contrôle si l’alerte se déclenche à chaque tick, une fois par barre ou une fois à la clôture de la barre.

Lisez chaque ligne de code générée par le modèle. Le code de trading ne pardonne pas les bugs subtils liés au dimensionnement des ordres, à l’état des positions et au comportement intra-barre. Demandez au modèle d’expliquer tout calcul complexe avant de l’accepter. Si vous souhaitez un flux de travail AI-IDE plus poussé (Pine combiné à un récepteur Python ou Go, le tout dans un seul éditeur), la page du workflow Cursor détaille cette approche.

Section 04 · Backtester avant de passer en réel

Exécutez le Strategy Tester avant de connecter le webhook

Le Strategy Tester de TradingView exécute votre stratégie Pine Script sur l’historique disponible du graphique, en affichant le profit net, le profit factor, le drawdown, le taux de réussite et la liste complète des transactions simulées. Les onglets Résumé des performances, Liste des transactions et Propriétés vous donnent suffisamment d’éléments pour décider si la stratégie mérite d’être connectée à un broker réel.

Effectuez cette étape avant de créer une alerte TradingView avec une URL de webhook. Un webhook actif sur une stratégie non validée est le moyen le plus coûteux de découvrir un bug.

Section 05 · Alertes et webhooks

Configurer l’alerte TradingView et l’URL du webhook

Ouvrez la boîte de dialogue Créer une alerte sur votre graphique, sélectionnez la stratégie comme condition, puis passez à l’onglet Notifications et cochez URL de webhook. Collez l’endpoint de webhook TradingHost comme URL. Le corps que vous saisissez dans le champ Message correspond à ce que TradingView enverra via une requête POST à cette URL lors du déclenchement de l’alerte.

Rédigez le message au format JSON. TradingView détecte automatiquement le JSON valide et définit le Content-Type de la requête sur application/json, ce que votre récepteur attend. Le corps minimal d’une alerte de stratégie contient le ticker, le sens (issu de {{strategy.order.action}}), la taille (issue de {{strategy.order.contracts}}) et un secret partagé que votre récepteur vérifie avant de transmettre quoi que ce soit au broker.

Section 06 · Réception sur TradingHost

Hébergez l’URL du webhook sur un runtime, pas sur votre ordinateur portable

L’URL du webhook appelée par TradingView doit être en ligne dès que le marché est ouvert. Un ordinateur portable n’est pas adapté ; un ordinateur de bureau avec une connexion internet instable non plus ; et un VPS Windows générique fonctionne, mais seulement si vous pensez à appliquer les mises à jour et à laisser le terminal concerné ouvert.

TradingHost vous fournit un conteneur Linux basé sur Kubernetes qui s’exécute à partir d’un dépôt GitHub et expose un point de terminaison HTTPS stable. Votre code de réception peut être écrit comme vous le souhaitez (un gestionnaire Python FastAPI, une route Node Express, un serveur Go net/http), tant qu’il communique en HTTP sur le port 443 et répond dans le délai de trois secondes imposé par TradingView. Lorsque vous poussez du code sur GitHub, TradingHost reconstruit le conteneur et le redéploie ; l’URL du webhook reste inchangée.

Les identifiants de l’API du broker sont stockés sous forme de secrets chiffrés sur le runtime, et non dans votre dépôt GitHub. Le secret partagé que vous insérez dans le corps du message TradingView y est également conservé. Votre récepteur valide ce secret partagé à chaque requête entrante, puis lit les identifiants du broker depuis l’environnement et appelle l’API du broker.

Les journaux (logs) sont diffusés en continu afin que vous puissiez suivre l’ordre des opérations : envoi par TradingView, analyse de la charge utile (payload), soumission de l’ordre, confirmation du broker. En cas d’échec, la ligne de log indique précisément où l’erreur s’est produite.

Section 07 · Exécution chez le broker

N’importe quel broker doté d’une API ; la structure du récepteur reste la même

TradingHost est indépendant des brokers (broker-agnostic). Le conteneur TradingHost ne se soucie pas du broker qui se trouve derrière l’endpoint REST qu’il appelle ; la même structure de récepteur fonctionne que la destination soit un broker forex, actions, contrats à terme (futures) ou une plateforme d’échange crypto. Seuls diffèrent le protocole d’authentification, la symbologie des instruments et les types d’ordres proposés par le broker. Tout le reste demeure identique.

Section 07.5 · Sécurité opérationnelle

Les pièges qui coûtent cher en conditions réelles

La transmission des alertes TradingView fonctionne selon le principe du « best-effort ». Les webhooks peuvent être perdus, répétés ou retardés. Les API des brokers peuvent renvoyer des tentatives de reconnexion qui ressemblent à un nouvel ordre. Les bugs de Pine Script peuvent générer des tailles de position bien au-delà du risque prévu par la stratégie. C'est au niveau du récepteur qu'il faut installer la ceinture de sécurité. Voici six garde-fous : chacun correspond à une portion de code du récepteur conçue pour éviter un mode de défaillance impossible à corriger une fois la stratégie lancée.

Section 08 · Comparatif PineConnector + MT4/MT5

Pourquoi acheminer un webhook via un runtime cloud plutôt qu'un EA MetaTrader

Le chemin le plus courant pour lier une alerte TradingView à un ordre réel passe par PineConnector, une passerelle tierce qui transmet les alertes à un Expert Advisor (EA) au sein d'un terminal MetaTrader 4 ou MetaTrader 5. L'EA soumet l'ordre via MetaTrader, ce qui impose de laisser le terminal tourner en continu sur une machine Windows. TradingHost supprime entièrement cette étape intermédiaire : le webhook arrive sur un conteneur, le conteneur appelle directement l'API REST du broker, éliminant ainsi le terminal MetaTrader et l'Expert Advisor MQL. GitHub sert de source de vérité, et un conteneur Linux s'exécute dans une région managée plutôt que sur un bureau Windows qu'il faut maintenir actif.