Bots de marchés prédictifs : construire une simulation
Construis un bot de marché prédictif en simulation : lecture publique horodatée, signaux hypothétiques, fills simulés, réconciliation par decision_id et conditions d'arrêt.
Dans ce guide
À quoi ressemble un bot qui n'engage pas d'argent
Un bot de marché prédictif est un programme qui lit des données de marché, applique une règle et en déduit un signal. En mode simulation, il s'arrête avant tout ordre réel et n'interroge que des points d'accès publics en lecture. Sur Polymarket, la découverte publique ne demande pas d'authentification : tu passes active=true et closed=false, tu ajoutes limit et after_cursor, et tu reçois des événements accompagnés d'un next_cursor que tu parcours jusqu'à épuisement. Une donnée observée n'est pas une autorisation de trader, et ces réponses sont des instantanés en lecture seule.
La première version ne cherche pas à gagner. Elle reproduit fidèlement la chaîne décision, hypothèse de fill, journal. Chaque observation porte un horodatage, chaque signal reçoit un identifiant decision_id, et une répétition du même signal doit être reconnue comme une seule décision. Sans cette discipline, ton journal empile des lignes identiques et le bilan de la simulation ne veut plus rien dire.
Un signal vu 2 fois reste une décision
Exemple illustratif, pas une étude. Un bot interroge la découverte publique toutes les 30 secondes et tombe sur un marché à question binaire. À 12:00:00, le carnet affiche une meilleure offre d’achat à 0,54 et une meilleure offre de vente à 0,58, soit un prix affiché de 0,56 (le milieu). Ta règle déclenche un signal d'achat hypothétique à 0,56. À 12:00:30, le bot revoit le même marché et le même signal : le journal doit compter une décision, pas 2. 2 fills simulés « gagnants » sur un seul signal gonflent artificiellement la performance, alors que tu n'as rien gagné du tout.
Voici le protocole de simulation. Tu interroges les métadonnées publiques en conservant l'horodatage. Tu valides que le marché est actif et ouvert. Tu vérifies la fraîcheur et la profondeur de la cotation. Tu enregistres un signal hypothétique. Tu simules les fills selon des hypothèses que tu écris noir sur blanc. Tu réconcilies les répétitions avec une clé event + market + decision_id. Tu arrêtes le traitement dès qu'une donnée manque, qu'une cotation est périmée ou que le marché est fermé. Aucune clé, aucun portefeuille, aucun appel d'ordre réel.
| Horodatage | Signal | Répétition | Fill simulé | Ligne journalisée |
|---|---|---|---|---|
| 12:00:00 | achat à 0,56 | 1re observation | 1 fill à 0,56 | 1 (decision_id D-1) |
| 12:00:30 | même signal | répétition | ignoré | 0 (même D-1) |
| 12:01:00 | timeout API | donnée manquante | arrêt | 0 (pas de prix = pas zéro) |
Ce que ton bot lit vraiment
Les détails de marché te donnent la question, les outcomes, outcomePrices, clobTokenIds, l'activité, la fermeture, l'acceptation d'ordres, la liquidité et le volume. Les tableaux sérialisés demandent souvent un parsing. Conserve toujours la date d'observation du prix. Volume et liquidité sont 2 choses différentes. Une valeur manquante ou périmée ne vaut jamais zéro. Et l'authentification de trading n'a rien à voir avec les GET publics.
Les prix affichés sont en général le milieu entre meilleure offre et meilleure demande. Quand l'écart dépasse 0,10, c'est le dernier trade qui s'affiche. Ce sont la cotation exécutable, sa profondeur et sa date qui comptent : un ordre au marché consomme plusieurs niveaux et subit du slippage, donc le milieu n'est pas une garantie d'exécution. Et un timeout d'API ne vaut jamais un prix à zéro : tu ne sais simplement pas.
Monter la boucle et réconcilier
Pour poser les bases, la lecture publique de l'API Polymarket définit les filtres et la pagination, et tu dois poser des hypothèses de fill dans un backtest avant de croire à un résultat. Le point de contrôle principal reste la réconciliation : un même event + market + decision_id ne doit produire qu'une seule ligne d'exécution simulée. Dans ce protocole de simulation, suspends le calcul lorsqu’un prix manque, est périmé ou ne correspond pas au contrat attendu.
Le tableau plus bas fixe des hypothèses illustratives, pas un résultat observé. La colonne « condition d'arrêt » dit ce qui invalide la ligne : donnée manquante, cotation périmée, marché fermé ou valeur aberrante. Toute valeur indisponible reste vide, jamais remplacée par zéro.
| Élément | Hypothèse illustrative | Condition d'arrêt |
|---|---|---|
| Prix de référence | milieu offre/demande affiché | Prix absent, périmé ou lié au mauvais contrat |
| Fraîcheur | cotation < 60 s | horodatage absent ou dépassé |
| Statut marché | active=true et closed=false | fermé ou acceptation d'ordres inactive |
| Volume vs liquidité | suivis séparément | valeur manquante ou périmée |
| Répétition | clé event+market+decision_id | doublon détecté |
| Timeout | aucun prix enregistré | arrêt, jamais 0 |
Ce que la simulation ne prouve pas
Cette simulation ne mesure pas la performance réelle. Elle teste seulement la cohérence de ta chaîne lecture, décision, journalisation. Elle ne prouve pas qu'un fill réel serait possible au milieu affiché, ni que la liquidité resterait présente. Les valeurs du tableau sont illustratives, aucune statistique de marché n'est fournie ici. Le cas perdant typique : tu prends le milieu affiché comme prix d'entrée garanti, tu additionnes des fills simulés sans réconcilier les répétitions, et ton bot te raconte une performance qui n'existe pas. Avant d'ajouter une règle de trading, vérifie chaque condition d'arrêt.
Garde en tête les risques d'un bot de marché prédictif avant d'aller plus loin : données périmées, répétitions comptées 2 fois, marchés fermés à tort et faux signaux sur des cotations non exécutables sont tes vrais ennemis, bien avant la stratégie.
Sources et vérification
Sources consultées
Sources consultées
Sources consultées
Rédaction PolyZeno. Relecture automatisée avec DeepSeek V4.1 Flash.