Un développeur partage comment créer un robot de trading Polymarket, en captant les fluctuations de prix du marché BTC sur 15 minutes, transformant 1 000 dollars en 1 869 dollars en quelques jours, avec un rendement backtest de 86 %. L’article détaille la logique de construction du robot, la méthode de backtesting et ses limites.
(Précédent : Le leader du marché des prévisions Polymarket annonce la création d’un L2, la carte maîtresse de Polygon disparaît-elle ?)
(Contexte supplémentaire : Comment réaliser un rendement annualisé de 40 % via l’arbitrage sur Polymarket ?)

Table des matières

• Logique de construction du robot
• Backtesting
• Limites du backtesting
• Infrastructure

Il y a quelques semaines, j’ai décidé de construire mon propre robot Polymarket. La version complète m’a pris plusieurs semaines.

Je suis prêt à investir ces efforts parce qu’il existe effectivement des failles d’efficacité sur Polymarket. Bien que certains robots exploitent déjà ces inefficacités pour faire du profit, cela reste encore insuffisant, et le marché offre encore beaucoup d’opportunités par rapport au nombre de robots existants.

Logique de construction du robot

La logique de ce robot est basée sur une stratégie que j’ai exécutée manuellement par le passé. Pour gagner en efficacité, je l’ai automatisée. Le robot fonctionne sur le marché « BTC 15-minute UP/DOWN ».

Le robot exécute un programme de surveillance en temps réel, capable de basculer automatiquement vers le cycle BTC 15 minutes en cours, en utilisant un flux WebSocket pour transmettre les meilleures offres d’achat/vente (best bid/ask), affichant une interface terminale fixe, et permettant un contrôle complet via commandes textuelles.

En mode manuel, vous pouvez passer des ordres directement.

buy up / buy down : acheter un montant spécifique en dollars.

buyshares up / buyshares down : acheter un nombre précis d’actions, en utilisant des ordres LIMIT (limite) + GTC (valide jusqu’à annulation), exécutés au meilleur prix de vente actuel (best ask).

En mode automatique, il exécute une boucle en deux étapes (two-leg).

La première étape consiste à observer la volatilité des prix dans une fenêtre de minutes après le début de chaque cycle. Si l’une des deux parties chute suffisamment vite (en environ 3 secondes, avec une baisse d’au moins movePct), cela déclenche la « première étape (Leg 1) », en achetant la partie en forte baisse.

Après avoir terminé Leg 1, le robot n’achètera plus du même côté. Il attend la « deuxième étape (Leg 2, c’est-à-dire la couverture) », qui se déclenche uniquement si la condition suivante est remplie : leg1EntryPrice + oppositeAsk <= sumTarget.

Lorsque cette condition est satisfaite, il achète la partie opposée. Après la fin de Leg 2, la boucle se termine, et le robot revient en mode observation, en attendant le prochain signal de chute avec les mêmes paramètres.

Si le cycle change en cours de route, le robot abandonne cette boucle ouverte et recommence avec les mêmes réglages lors du prochain cycle.

Les paramètres du mode automatique sont : auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares : taille de position pour chaque étape.
• sum : seuil de couverture autorisée.
• move (movePct) : seuil de chute (par exemple 0.15 = 15 %).
• windowMin : durée en minutes pour exécuter Leg 1 après le début de chaque cycle.

Backtesting

La logique du robot est simple : attendre une chute violente, acheter la partie qui a baissé, puis attendre que le prix se stabilise et couvrir en achetant la partie opposée, tout en garantissant : priceUP + priceDOWN < 1.

Mais cette logique doit être testée. Est-elle réellement efficace à long terme ? Plus important encore, le robot possède de nombreux paramètres (quantité d’actions, seuils, pourcentage de mouvement, durée de fenêtre, etc.). Quelle combinaison de paramètres est optimale pour maximiser le profit ?

Ma première idée était de faire fonctionner le robot en réel pendant une semaine pour observer les résultats. Le problème, c’est que cela prend trop de temps et ne permet de tester qu’un seul ensemble de paramètres à la fois, alors que j’en ai besoin de tester beaucoup.

Ma deuxième idée était d’utiliser des données historiques en ligne via l’API CLOB de Polymarket pour faire du backtest. Malheureusement, pour le marché BTC 15-minute UP/DOWN, le point d’accès aux données historiques retourne systématiquement un ensemble vide. Pas de ticks de prix historiques, donc impossible de détecter une chute d’environ 3 secondes, et donc impossible de déclencher Leg 1. Quel que soit le paramétrage, cela donne 0 cycle et 0 % de ROI.

Après investigation, j’ai découvert que d’autres utilisateurs rencontrent aussi ce problème pour certains marchés. J’ai testé d’autres marchés qui retournent bien des données historiques, et j’en ai conclu que, pour ce marché précis, aucune donnée historique n’est conservée.

En raison de cette limitation, la seule méthode fiable pour backtester cette stratégie est d’enregistrer en direct, lors du fonctionnement du robot, des snapshots du best-ask en temps réel pour créer ma propre base de données historique.

Le logger écrit ces snapshots sur disque, comprenant :

• Horodatage
• Identifiant du cycle (round slug)
• Secondes restantes
• ID du token UP/DOWN
• Best ask

Ensuite, le « recorded backtest » rejoue ces snapshots, en appliquant de façon déterministe la même logique automatique. Cela garantit d’avoir des données haute fréquence nécessaires pour détecter la chute et la couverture.

J’ai collecté au total 6 Go de données en 4 jours. Je pouvais en enregistrer davantage, mais je pense que cela suffit pour tester différentes configurations.

J’ai commencé à tester cette configuration :

• Solde initial : 1 000 $
• 20 actions par transaction
• sumTarget = 0.95
• Seuil de chute = 15 %
• windowMin = 2 minutes

J’ai aussi appliqué un taux fixe de 0,5 % et une marge de 2 % pour rester dans un scénario conservateur.

Le backtest a montré un ROI de 86 %, en quelques jours, 1 000 $ sont devenus 1 869 $.

Ensuite, j’ai testé une configuration plus agressive :

• Solde initial : 1 000 $
• 20 actions par transaction
• sumTarget = 0.6
• Seuil de chute = 1 %
• windowMin = 15 minutes

Résultat : en 2 jours, le ROI est de -50 %.

Cela montre clairement que le choix des paramètres est crucial. Il peut faire gagner beaucoup d’argent ou entraîner des pertes importantes.

Limites du backtesting

Même en incluant les frais et la marge, le backtest a ses limites.

• D’abord, il ne couvre que quelques jours de données, ce qui peut ne pas suffire pour une vision globale du marché.
• Il dépend de snapshots du best-ask ; en réalité, les ordres peuvent être partiellement exécutés ou à des prix différents. La profondeur du carnet et le volume disponible ne sont pas modélisés.
• Il ne capte pas les micro-mouvements sous la seconde (données échantillonnées toutes les secondes). Bien que les timestamps soient à 1 seconde, beaucoup de choses peuvent se passer entre deux.
• Le slippage est constant dans le backtest, sans modéliser des délais variables (200–1500 ms) ou des pics réseau.
• Chaque étape est considérée comme une exécution « instantanée » (pas de file d’attente, pas d’ordres en attente).
• Les frais sont uniformément appliqués, alors qu’en réalité, ils peuvent dépendre du marché / du token, du type d’ordre, du niveau de frais ou des conditions.

Pour rester prudent, j’ai appliqué une règle : si Leg 2 ne s’exécute pas avant la fermeture du marché, Leg 1 est considéré comme une perte totale.

C’est une hypothèse conservatrice, mais qui ne correspond pas toujours à la réalité :

• Parfois, Leg 1 peut se clôturer prématurément,
• parfois, il finit dans la monnaie (ITM) et gagne,
• parfois, la perte peut être partielle plutôt que totale.

Même si la perte est surestimée, cela donne une idée du « pire scénario ».

L’essentiel, c’est que le backtest ne peut pas simuler l’impact de grandes ordres sur le carnet ou l’attraction d’autres traders pour vous chasser. En réalité, votre ordre peut :

• perturber le carnet,
• attirer ou repousser d’autres traders,
• entraîner un slippage non linéaire.

Le backtest suppose que vous êtes un simple preneur de prix (price taker), sans aucune influence.

Enfin, il ne modélise pas la limitation de fréquence (rate limits), erreurs API, ordres rejetés, suspensions, timeout, reconnections, ou le fait que le robot rate des signaux en étant occupé.

Le backtest est très utile pour identifier une bonne plage de paramètres, mais ce n’est pas une garantie à 100 %, car certains effets du monde réel ne peuvent pas être modélisés.

Infrastructure

Je prévois de faire tourner ce robot sur un Raspberry Pi pour éviter de consommer les ressources de mon PC principal, et pour assurer une opération 24/7.

Mais il y a encore beaucoup d’améliorations possibles :

• Utiliser Rust au lieu de JavaScript pour des performances et une gestion du temps bien meilleures.
• Déployer un nœud RPC Polygon dédié pour réduire encore la latence.
• Héberger sur un VPS proche des serveurs Polymarket pour réduire la latence.

Il doit sûrement y avoir d’autres optimisations que je n’ai pas encore découvertes. Pour l’instant, j’apprends Rust, car c’est une langue qui devient incontournable dans le développement Web3.

#####