Comment backtester des stratégies de marchés de prédiction sur Polymarket & Kalshi

Ce qui rend les marchés de prédiction différents à backtester

Un contrat de marché de prédiction n'est ni une action ni un perpétuel. Chaque résultat est coté de 0 à 1 — sa probabilité implicite — et au règlement, un côté vaut exactement $1 et l'autre $0. Les marchés haussiers/baissiers crypto se règlent en 5 à 60 minutes contre un prix de référence, les spreads s'élargissent et la profondeur se rétrécit à l'approche de la clôture, et la durée de vie entière d'un marché peut être plus courte qu'une seule bougie sur un graphique normal.

Cette forme change ce dont un backtest a besoin. Échantillonner un dernier prix une fois par minute manque la majeure partie d'un marché de cinq minutes ; ignorer le carnet dissimule le spread qui détermine votre P&L sur un contrat qui rapporte au maximum un dollar ; et mal étiqueter le règlement transforme des gagnants en perdants. Le reste de ce guide explique comment bien traiter chacun de ces points.

Étape 1 — Partir du vrai carnet d'ordres

Un backtest ne peut être aussi honnête que ses données. Vous avez besoin du carnet d'ordres complet — chaque ordre acheteur et vendeur au repos avec sa taille, des deux côtés — capturé à chaque changement plutôt que sur une horloge fixe, parce que la capture événementielle est la seule façon de voir tout l'arc d'un marché à courte échéance. Ni Polymarket ni Kalshi ne servent leur propre profondeur de carnet d'ordres historique, de sorte que rejouer le carnet tel qu'il était nécessite un fournisseur qui l'a capturé en continu.

DepthFeed sert exactement cela pour les deux plateformes dans un même schéma : Polymarket capturé en mode événementiel depuis le websocket CLOB, Kalshi interrogé en continu à pleine profondeur (jusqu'à 100 niveaux par côté), chaque snapshot portant des horodatages en epoch-millis et un prix de référence crypto sous-jacent joint. Un seul loader lit l'une ou l'autre plateforme.

Étape 2 — Modéliser les exécutions contre la profondeur, pas le mid

C'est l'étape qui sépare un backtest sur lequel vous pouvez trader d'un qui ment. Un ordre à cours du marché parcourt le carnet — il remplit d'abord le meilleur niveau, puis le suivant, de sorte que son prix moyen est moins bon que la touche dès qu'il consomme plus que le niveau supérieur. Un ordre à cours limité rejoint la file d'attente et ne s'exécute que si le marché traite à son prix avec suffisamment de taille derrière lui. Tout exécuter au mid avec un slippage nul, le défaut de la plupart des backtests courants, surestime systématiquement l'edge.

Quelle que soit la voie que vous empruntez, insistez sur une exécution tenant compte de la profondeur. Sur un spread aller-retour de quatre centimes, sur un contrat qui rapporte au maximum un dollar, la différence entre un fill au mid et un fill réel est énorme — et elle se cumule sur chaque transaction.

Étape 3 — Régler au résultat réel

Parce que le gain est binaire, le règlement n'est pas un détail d'arrondi — c'est l'essentiel du P&L. Les marchés haussiers/baissiers de Polymarket se règlent contre un « prix à battre » fixé à l'ouverture par rapport à la référence finale à la clôture ; les contrats Kalshi se règlent oui/non contre un prix de référence publié à l'expiration. Backtestez contre la résolution réelle, pas une hypothèse, et vérifiez la répartition : sur les marchés haussiers/baissiers crypto réglés que nous avons capturés, les résultats atterrissent près d'un pile ou face, donc tout backtest dont le règlement s'écarte fortement de cela étiquette probablement mal les gagnants.

Étape 4 — Choisir votre workflow : sans code ou API

Il y a deux façons d'exécuter tout ce qui précède sur DepthFeed. Le chemin sans code est le Backtest Lab : choisissez un actif et une fenêtre, sélectionnez un preset ou rédigez une règle courte, choisissez un modèle d'exécution, et il rejoue les marchés résolus et les règle pour vous dans le navigateur — exécutions VWAP tenant compte de la profondeur incluses, aucun pipeline à construire.

Le chemin API est destiné à la recherche personnalisée à grande échelle : récupérez des snapshots à pleine profondeur via l'API REST, reconstruisez le carnet dans votre propre stack, et exécutez le modèle que vous souhaitez. Parce que l'API REST historique et le WebSocket en direct émettent le même JSON identique, le loader que vous écrivez pour rejouer l'historique lit le flux en direct sans modification — vous tradez le code exact avec lequel vous avez backdesté.

Étape 5 — Tester en avant avant de risquer de l'argent

Un backtest est ajusté au passé, aussi légèrement soit-il, donc la dernière étape est d'exécuter la survivante en avant sur des marchés dont personne ne connaît encore le résultat. Déployez la règle en paper trading — ou pilotez-la depuis votre propre bot via un webhook — et elle trade des carnets en direct avec des fonds virtuels, s'exécutant au vrai prix acheteur/vendeur et se réglant automatiquement à la résolution. La courbe de capitaux qu'elle construit est la preuve prospective qu'un backtest ne peut pas vous fournir.

Cela complète la boucle : données → backtest honnête → test en avant. Éliminez les idées à moindre coût sur l'historique, faites progresser celles qui survivent vers des carnets paper en direct, et seulement alors envisagez du capital réel.

Pièges courants

• Données au dernier prix ou horaires : dissimule le spread et manque la durée de vie d'un marché de 5 à 60 minutes.
• Exécutions au mid : supposer un slippage nul surestime fortement l'edge sur un contrat qui rapporte au maximum $1.
• Règlement supposé : étiquetez les gagnants depuis le vrai prix de référence, pas une estimation — c'est l'essentiel du P&L.
• Biais prospectif : ne réagissez qu'à des données avec un horodatage de réception égal ou antérieur à votre moment de décision.
• Ignorer le test en avant : un edge qui n'existe que sur l'historique réglé peut ne pas résister aux marchés en direct.