Comment une API de cotes automatise ton stack de paris

Le premier réflexe de tout développeur parieur est d'écrire un scraper : quelques requêtes HTTP, un peu de parsing, et les cotes de Winamax ou Betclic tombent dans une base. Ça marche une semaine, parfois un mois. Puis ça devient un second métier.

Le scraping n'est pas un problème de code, c'est un problème de maintenance. Tu ne construis plus une stratégie de paris, tu entretiens une infrastructure d'extraction qui casse sans préavis, multipliée par le nombre de bookmakers couverts.

D'abord les sélecteurs : chaque refonte de front, chaque renommage de champ dans une API interne non documentée casse ton parsing silencieusement. Tu le découvres quand tes cotes ont l'air normales mais sont fausses, ce qui est pire qu'une panne franche.

Ensuite les bans : les bookmakers détectent les patterns d'accès automatisés et bloquent par IP, par fingerprint, par rate limiting. Tu escalades vers des proxies résidentiels et de la rotation de headers, et ton coût d'infrastructure explose pour un résultat instable.

Enfin la latence : un scraper qui fait le tour de 8 bookmakers toutes les 60 secondes voit les cotes avec en moyenne 30 secondes de retard, et jusqu'à une minute dans le pire cas. Sur du live ou des cotes d'avant coup d'envoi, c'est disqualifiant.

Une API de cotes inverse le rapport : la couverture des bookmakers, la normalisation des marchés et la fraîcheur des données deviennent le problème du fournisseur, pas le tien. Tu consommes un flux structuré et stable, avec des identifiants d'événements et de marchés cohérents entre les books.

OddStream couvre les 8 bookmakers licenciés ANJ sur 12 sports, en REST pour les snapshots et en WebSocket pour le push, avec une latence médiane sous 200 ms. Le contrat d'interface ne change pas quand un bookmaker refait son site.

Le pipeline type tient en quatre étages. Un : ingestion, un consommateur WebSocket écrit chaque mise à jour de cote dans ta base avec horodatage. Deux : calcul, un worker maintient la cote juste par marché et calcule l'EV de chaque cote de chaque bookmaker en continu.

Trois : filtrage et alerte, tout marché dépassant ton seuil, par exemple EV supérieur à 3 % avec une liquidité suffisante, déclenche une notification, typiquement Telegram ou Discord, avec cote, book, marché et EV calculé. Quatre : action, tu places le pari, et le settlement automatisé vient plus tard fermer la boucle dans ton PnL.

Chaque étage est remplaçable indépendamment. C'est la différence entre un stack et un script : tu peux changer ton modèle d'EV sans toucher à l'ingestion, ou ajouter un sport sans réécrire les alertes.

Le dernier kilomètre est souvent le plus lent : entre l'alerte et le pari placé, il y a ouvrir le site du bookmaker, chercher le match, trouver le marché, cliquer la sélection. Trente secondes à une minute pendant lesquelles la cote peut bouger ou disparaître.

L'add-on Betslip d'OddStream compresse cette étape en un clic : chaque opportunité est livrée avec un lien profond qui ouvre le bookmaker avec le pari déjà placé dans le panier. Il ne reste qu'à saisir la mise et confirmer. Sur des opportunités qui vivent quelques dizaines de secondes, c'est souvent la différence entre pris et raté.

Ne construis pas tout d'un coup. Commence par l'ingestion et le stockage : quelques jours de cotes horodatées suffisent déjà à valider ton calcul d'EV et à mesurer la vitesse réelle des mouvements sur tes marchés cibles.

Ajoute ensuite le filtre et les alertes, et fais tourner le système en observation pure pendant deux semaines : note chaque opportunité signalée et la cote encore disponible au moment où tu aurais cliqué. Ce simple écart mesure la latence totale de ton stack, et te dit si le problème restant est ton modèle ou ta vitesse d'exécution.