← Tous les projets
Projets 03/Freelance · Python, TypeScript

NVRValueBet

Une plateforme qui collecte les cotes de football de plusieurs bookmakers et d’une bourse de paris, les aligne sur le même match et le même marché, et montre où un prix s’écarte d’une référence à faible marge. Elle ne place aucun pari.

Dépôt privé

01Ce qu’elle fait

Toutes les quelques minutes, elle collecte les prix de bookmakers français et internationaux ainsi que d’une bourse de paris, et rapproche le même événement entre tous. Elle retire la marge du bookmaker des prix de référence pour obtenir des cotes justes, puis compare le meilleur prix français à cette référence. Le résultat est un tableau d’écarts, où chaque prix est marqué comme frais ou périmé. C’est un outil de signal : rien n’y est relié à de l’argent réel.

02Ce que j’ai construit

Un service Python sur FastAPI avec un collecteur en arrière-plan, un adaptateur par opérateur et une couche qui ramène équipes, compétitions et marchés à une seule identité. L’API sert un flux paginé, des facettes de filtre, une page de match, un tableau, un rapport de couverture et un audit des données suspectes, ainsi qu’une seconde interface calquée sur une API de cotes commerciale. Devant, une application React Native construite avec Expo et livrée en web, en français, en anglais et en espagnol.

03Les parties difficiles

Le même match s’écrit différemment chez chaque opérateur, donc l’identité fait l’essentiel du travail : alias pour les équipes et les compétitions, garde-fous contre le mélange d’équipes de genre ou d’effectif différents, un identifiant canonique par opérateur. La collecte tourne avec un budget par opérateur et un disjoncteur qui temporise après des échecs répétés, et les matchs proches du coup d’envoi sont rafraîchis plus souvent que les lointains. L’audit signale les événements en double, les paires d’équipes impossibles, les heures de coup d’envoi incohérentes et les cotes aberrantes.

04Comment elle tourne

L’API tourne comme service systemd sur un petit VPS Linux, liée à l’interface de bouclage. L’application web est sur Cloudflare Pages, une Pages Function relaie ses appels par un tunnel, et une seule application Cloudflare Access protège les deux, de sorte que l’API n’est jamais publique. Les prix sont dans SQLite, et le flux est servi depuis un cache construit une fois par cycle de collecte. GitHub Actions exécute les tests et livre chaque côté à chaque push sur main. Le projet est parti d’un ensemble de scrapers et de feuilles de calcul où chaque étape se faisait par copier-coller manuel, que j’ai documenté avant de le reconstruire en service.

Comment c’est construit

  1. Client

    Web aujourd’hui

  2. Périphérie

    Cloudflare

  3. Backend

    Un service Python

  4. Stockage

  5. Sources

    Hors de mon contrôle

  6. Livraison

    GitHub Actions vers la production

Sélectionnez un élément du schéma pour voir son rôle. Chaque couleur est un flux à travers le système.

© 2026 Benoit Ardiet · Quito, Équateur · UTC−5GitHubLinkedInAucun pistage, aucun cookie.