REST vs WebSocket pour les cotes : quand le temps réel compte vraiment

En REST, c'est toi qui demandes : tu interroges l'API à intervalle régulier et tu reçois un instantané des cotes. En WebSocket, c'est le serveur qui pousse : une connexion reste ouverte et chaque changement de cote t'arrive au moment où il se produit.

La différence n'est pas une question de mode ou de confort d'implémentation. C'est une question de fraîcheur des données, et la fraîcheur a une valeur directement chiffrable quand on parle de cotes.

Avec un polling toutes les T secondes, un changement de cote t'est visible en moyenne T/2 secondes après qu'il a eu lieu, et T secondes dans le pire cas. Un poll à 30 secondes te donne donc 15 secondes de retard moyen ; à 60 secondes, une minute de retard au pire.

Or les cotes ne bougent pas uniformément dans le temps. Elles s'accélèrent dans les minutes précédant le coup d'envoi, quand les compositions tombent et que l'argent afflue, et changent toutes les quelques secondes en live après chaque action de jeu. Ton retard moyen est donc maximal exactement quand l'information est la plus précieuse.

Le push supprime ce terme : la latence n'est plus liée à ton intervalle de polling mais au trajet réseau. Sur le flux WebSocket d'OddStream, la latence médiane est sous 200 ms, soit deux ordres de grandeur de mieux qu'un polling à 30 secondes.

Prends un value bet type : cote 2,10, cote juste 1,92, EV +9,2 %. Le book corrige à 1,95 pendant tes secondes de retard : l'EV tombe à (0,521 × 1,95) − 1 = +1,6 %. Le pari existe encore, mais il vaut six fois moins. Sur une mise de 50 €, c'est 3,8 € d'espérance évaporés sur un seul pari.

Multiplie par la fréquence : si ton retard te fait manquer ou dégrader ne serait-ce que deux opportunités par jour, tu perds plusieurs centaines d'euros d'espérance par mois, soit davantage que le coût de n'importe quelle infrastructure de données. La latence n'est pas un détail technique, c'est une ligne de ton PnL.

Pour l'arbitrage, le verdict est encore plus net : des fenêtres qui vivent quelques secondes sont simplement invisibles à un polling de 30 ou 60 secondes. Sans push, cette stratégie n'existe pas.

Tout n'a pas besoin de temps réel. Si tu paries sur des lignes d'ouverture, si ton modèle tourne la veille des matchs, ou si tu construis un historique pour du backtesting et de l'analyse de CLV, un poll REST toutes les une à cinq minutes est parfaitement adapté, plus simple à opérer et plus facile à reprendre après une panne.

REST garde aussi des avantages structurels : la récupération d'un état complet en une requête, idéale au démarrage ou après une déconnexion, et une consommation prévisible. Un flux push sans mécanisme de resynchronisation est fragile : il te dit ce qui change, pas ce que tu as manqué pendant que tu étais déconnecté.

Les stacks sérieux combinent les deux. Au démarrage, un appel REST charge l'état complet des marchés suivis. Ensuite, le WebSocket applique les deltas en continu sur cet état en mémoire. À chaque reconnexion, un nouveau snapshot REST resynchronise avant de reprendre le flux, ce qui élimine toute dérive silencieuse.

Ce pattern, snapshot puis flux de deltas, est exactement celui des places de marché financières, et c'est pour ça qu'OddStream expose les deux interfaces sur les mêmes données : REST pour l'état, WebSocket pour le mouvement, avec des identifiants communs pour que le raccord soit trivial.

Côté implémentation, prévois trois choses dès le premier jour : un heartbeat pour détecter les connexions mortes, une reconnexion avec backoff exponentiel, et des mises à jour idempotentes, horodatage ou numéro de séquence, pour qu'un message rejoué n'écrase jamais une donnée plus récente.

La question à te poser : quelle est la durée de vie des opportunités que ta stratégie exploite ? Si elle se compte en heures, poll REST et dors tranquille. Si elle se compte en minutes, un polling agressif peut tenir, au prix de quotas de requêtes élevés. Si elle se compte en secondes, live, arbitrage, value betting proche du coup d'envoi, le push est obligatoire.

Le bon réflexe est de mesurer plutôt que supposer : enregistre pendant quelques jours les horodatages des mouvements de cotes sur tes marchés cibles, et calcule combien d'opportunités survivraient à ton intervalle de polling. Ce chiffre décide de l'architecture à ta place.