Référence éditoriale du vocabulaire métier, statistique et produit utilisé dans EVCore.

• Objectif
• Paris sportifs et cotes
• Modélisation et statistiques
• Décision betting et performance
• Data, ETL et pipeline
• Formules importantes
• Sigles utiles
• Résumé express

Ce document sert de lexique de référence pour comprendre les termes techniques du projet EVCore.

Il couvre quatre familles de notions :

• les cotes et les bookmakers
• la modélisation statistique
• la décision betting
• le pipeline data / ETL

L’objectif n’est pas d’être académique à tout prix, mais d’être :

• juste
• lisible
• utile pour lire le repo

`odds`

Les cotes proposées par un bookmaker.

En cote décimale :

• une cote de 2.00 signifie qu’un pari gagnant de 1 retourne 2 au total
• le gain net est donc 2 - 1 = 1

`bookmaker`

L’opérateur de pari, par exemple Pinnacle, Bet365, Unibet.

Dans EVCore, tous les bookmakers ne servent pas au même usage :

• certains servent surtout de référence probabiliste
• d’autres servent plutôt de prix à battre

`market`

Le type de pari.

Exemples :

• ONE_X_TWO : victoire domicile / nul / victoire extérieur
• OVER_UNDER : plus ou moins d’un seuil de buts total
• OVER_UNDER_HT : plus ou moins d’un seuil de buts à la mi-temps
• BTTS : les deux équipes marquent
• HALF_TIME_FULL_TIME (HT/FT) : résultat à la mi-temps + résultat final
• FIRST_HALF_WINNER : vainqueur de la première mi-temps (1X2 sur 45 min)

`ONE_X_TWO`

Marché 1N2.

Interprétation :

• 1 = domicile
• X = nul
• 2 = extérieur

`OVER_UNDER`

Pari sur le total de buts.

Exemple :

• OVER 2.5 = au moins 3 buts
• UNDER 2.5 = 0, 1 ou 2 buts

`BTTS`

Both Teams To Score.

Exemple :

• YES = les deux équipes marquent
• NO = au moins une des deux ne marque pas

`OVER_UNDER_HT`

Pari sur le total de buts à la mi-temps uniquement.

Exemple :

• OVER 1.5 HT = au moins 2 buts avant la mi-temps
• UNDER 0.5 HT = aucun but avant la mi-temps

`FIRST_HALF_WINNER`

Pari 1X2 limité à la première mi-temps.

Même structure que ONE_X_TWO mais résolu à 45 min.

`HALF_TIME_FULL_TIME`

Pari combiné sur le résultat à la mi-temps ET le résultat final.

Exemple :

• V1 / V1 = domicile mène à la mi-temps et gagne le match
• NUL / V2 = nul à la mi-temps, victoire extérieur au final

C'est un marché à forte valeur sur les équipes qui renversent systématiquement des situations ou qui dominent dès l'entame.

`closing odds`

Les dernières cotes disponibles avant le coup d’envoi.

Elles sont souvent utilisées comme référence car elles condensent une grande partie de l’information de marché.

`snapshot`

Une photo des cotes à un instant donné.

Exemple :

• snapshotAt = 2026-04-05T18:16:30

`implied probability`

La probabilité implicite contenue dans une cote.

Formule simple :

probabilité implicite = 1 / cote

Exemple :

cote 2.50 -> 1 / 2.50 = 0.40 = 40 %

`margin`

La marge bookmaker.

C’est la commission implicite contenue dans les cotes. Plus elle est élevée, plus les prix sont “écrasés”.

`overround`

Autre nom de la marge.

Sur un marché 1X2, on additionne les probabilités implicites :

overround = (1 / homeOdds) + (1 / drawOdds) + (1 / awayOdds)
marge = overround - 1

Si la somme vaut 1.04, alors la marge est de 4 %.

`vig`

Autre nom courant de la marge bookmaker.

`de-vig`

Retirer la marge bookmaker pour retrouver une estimation de probabilités plus propre.

Dans EVCore, sur un 1X2 :

invHome = 1 / homeOdds
invDraw = 1 / drawOdds
invAway = 1 / awayOdds
sum = invHome + invDraw + invAway

pHome = invHome / sum
pDraw = invDraw / sum
pAway = invAway / sum

`sharp bookmaker`

Bookmaker considéré comme plus informatif et plus proche du “vrai” marché.

Dans ce projet, Pinnacle joue souvent ce rôle de référence.

`soft bookmaker`

Bookmaker plus orienté grand public, souvent plus margé et donc moins utile comme estimateur de probabilité de marché.

`price to beat`

Le prix contre lequel on compare le modèle.

Exemple :

• la probabilité vient du modèle Poisson ou d’un de-vig
• la cote à battre est celle proposée par Bet365

`line movement`

Le mouvement de cote dans le temps.

Si une cote baisse ou monte fortement avant le match, cela signifie que le marché a réévalué l’événement.

`market efficiency`

Idée selon laquelle certaines cotes incorporent mieux l’information disponible que d’autres.

Plus un marché est efficace :

• moins il laisse de prix aberrants
• plus il est difficile à battre

`model`

Le moteur qui transforme des données en probabilités de match.

Dans EVCore, le cœur du système repose sur :

• des statistiques glissantes
• des métriques xG
• un modèle de Poisson

`feature`

Variable d’entrée du modèle.

Exemples présents dans le repo :

• recentForm
• xg
• domExtPerf
• leagueVolat

`feature weight`

Le poids attribué à une feature dans un score composite.

Si une feature a un poids plus élevé, elle influence davantage la décision finale.

`deterministicScore`

Score composite dérivé de plusieurs features.

Dans EVCore :

deterministicScore =
  recentForm * w_recentForm +
  xg * w_xg +
  domExtPerf * w_domExtPerf +
  leagueVolat * w_leagueVolat

Ce score n’est pas une probabilité. Il sert surtout de filtre de qualité avant de valider un pick.

`xG`

Expected Goals.

Mesure de la qualité des occasions créées ou concédées.

Un match avec peu de tirs mais des occasions très franches peut produire un xG élevé.

`xgFor`

Le volume moyen de xG produit par une équipe.

`xgAgainst`

Le volume moyen de xG concédé par une équipe.

`recent form`

La forme récente d’une équipe, calculée sur une fenêtre glissante de matchs.

`rolling stats`

Des statistiques calculées sur les derniers matchs, plutôt que sur toute l’historique.

`league volatility`

Mesure de volatilité de la ligue.

Elle reflète le degré de stabilité ou de chaos des matchs dans une compétition donnée.

`lambda`

Dans un modèle de Poisson, lambda représente le nombre moyen de buts attendus.

Dans EVCore :

• lambdaHome = buts attendus domicile
• lambdaAway = buts attendus extérieur

Intuition :

• lambdaHome = 1.60 signifie qu’on attend en moyenne 1.6 but côté domicile

`league mean lambda`

Le niveau moyen de buts attendu pour une ligue.

Exemple d’usage :

• championnat ouvert -> lambda moyen plus haut
• championnat plus fermé -> lambda moyen plus bas

`home advantage`

Correction appliquée au domicile pour refléter l’avantage terrain.

Dans EVCore, cette correction est appliquée aux lambda avant le calcul des probabilités.

`Bayesian shrinkage`

Mécanisme qui rapproche une estimation extrême vers une moyenne de ligue plus stable.

L’idée :

• conserver le signal spécifique à l’équipe
• éviter des lambda irréalistes

`Poisson model`

Modèle probabiliste classique en football pour transformer les buts attendus en probabilités de scores.

Hypothèse standard :

• buts domicile et extérieur modélisés séparément
• chaque côté suit une loi de Poisson

`distribution`

Répartition de probabilités.

Exemple :

• probabilité de marquer 0 but
• probabilité de marquer 1 but
• probabilité de marquer 2 buts
• etc.

`joint probability`

Probabilité conjointe de deux événements.

Dans les combos, c’est essentiel, car deux sélections sur le même match ne sont généralement pas indépendantes.

`independence assumption`

Hypothèse selon laquelle deux événements ne s’influencent pas.

Exemple souvent faux en football :

• HOME
• OVER 2.5

Ces deux événements sont souvent corrélés.

`calibration`

Mesure de la cohérence entre les probabilités prédites et la réalité observée.

Exemple :

• si le modèle annonce souvent 60 %
• l’événement devrait arriver environ 60 % du temps

`Brier score`

Mesure de qualité des probabilités.

Plus le score est bas, meilleur est le modèle.

`ECE`

Expected Calibration Error.

Mesure d’erreur de calibration par paquets de probabilités.

`baseline`

Point de comparaison simple.

Exemples :

• classifieur aléatoire
• marché de référence
• modèle simplifié

`signal`

Information utile et prédictive contenue dans une variable.

`noise`

Variation aléatoire ou peu informative qui dégrade la qualité du modèle.

`cold start`

Situation où l’on manque encore de données fiables, par exemple en début de saison.

`proxy`

Variable de remplacement utilisée quand la vraie donnée manque.

Exemple :

• utiliser une approximation de xG si le fournisseur n’expose pas expected_goals

`pick`

Une sélection candidate générée par le moteur pour un match donné.

Un pick contient :

• le marché (ONE_X_TWO, OVER_UNDER, etc.)
• la direction (HOME, AWAY, DRAW, OVER 2.5, etc.)
• la probabilité estimée par le modèle
• la cote disponible
• l'EV calculé

Un pick peut être viable (passe tous les filtres) ou rejeté (bloqué par un garde-fou).

`pick candidat`

Pick dont l'EV est positif et qui entre dans l'évaluation approfondie.

Tous les candidats ne deviennent pas des paris — ils passent ensuite par une série de filtres (probabilité directionnelle, cotes plancher/plafond, score qualité, etc.).

`EV`

Expected Value, ou valeur espérée.

C’est la mesure centrale de rentabilité théorique d’un pari.

Formule utilisée dans EVCore :

EV = (probabilité estimée * cote décimale) - 1

Interprétation :

• EV > 0 : pari théoriquement rentable
• EV = 0 : pari neutre
• EV < 0 : pari négatif

Exemple :

p = 0.40
odds = 2.80
EV = (0.40 * 2.80) - 1 = 0.12

Donc +12 % de valeur théorique.

`edge`

L’avantage théorique du modèle sur le bookmaker.

En pratique, c’est généralement cet écart qui produit un EV positif.

`ROI`

Return On Investment.

Mesure de rentabilité observée sur un ensemble de paris réellement joués.

Formule simple :

ROI = profit net / mise totale

`probabilité directionnelle`

La probabilité que le modèle assigne à la direction choisie pour un pari.

Exemple concret :

• on envisage un pari HOME sur Arsenal
• le modèle estime P(victoire Arsenal) = 38 %
• le seuil de probabilité directionnelle est 45 %
• → pick rejeté, raison : "Probabilité directionnelle insuffisante"

L’idée centrale : on ne mise pas dans une direction que le modèle lui-même juge improbable, même si les cotes offrent un EV positif sur le papier. Un EV positif peut apparaître mécaniquement quand la cote est très haute — mais si le modèle lui-même dit "ce résultat est peu probable", miser dessus est incohérent avec ses propres estimations.

Ce filtre est distinct du seuil d’EV :

| Filtre | Bloque quand | | --------------------- | ------------------------------------ | | ev_below_threshold | EV trop faible | | probability_too_low | P(direction) < seuil, même si EV > 0 |

Dans EVCore, le seuil par défaut est 0.45 (45 %). Il peut être ajusté par compétition et par direction (ex : seuil abaissé sur D2 AWAY où les cotes extérieur sont historiquement sous-évaluées).

`MODEL_SCORE_THRESHOLD`

Seuil minimum de deterministicScore requis pour qu’un match soit éligible à un pari.

Si le score déterministe d’un match est inférieur à ce seuil, aucun pick n’est généré, même si l’EV est positif et la probabilité suffisante.

Ce filtre protège contre les fixtures où le contexte statistique est jugé insuffisant — données incomplètes, cold start, faible couverture xG.

Différencié par compétition :

• UCL : 0.45 (données cross-compétition, moins de matchs)
• PL : 0.58 (marché très efficace)
• EL2 : 0.45 (division 4, tolérance plus haute)
• etc.

`qualityScore`

Score combiné utilisé dans EVCore pour prioriser les picks.

Formule :

qualityScore = EV * deterministicScore * longshotPenalty

Ce n’est pas une probabilité. C’est un score de classement qui pénalise les picks à la fois peu soutenus statistiquement et à forte cote (longshot).

`stake sizing`

Le choix de la taille de mise.

`Kelly`

Formule classique de sizing basée sur l’avantage théorique et la cote.

Dans EVCore :

K = (p * odds - 1) / (odds - 1)
stakePct = fraction * K

Avec des gardes supplémentaires :

• si odds <= 1, retour 0
• si K <= 0, retour 0
• le résultat final est plafonné par maxStake

`fractional Kelly`

Version prudente du Kelly.

Au lieu d’appliquer 100 % de la taille recommandée, on n’en applique qu’une fraction.

`longshot`

Sélection à grosse cote.

Ces paris sont risqués car une petite surestimation de probabilité peut gonfler artificiellement l’EV.

`hard cap`

Plafond strict — le pick est rejeté sans exception si la valeur dépasse la limite.

Exemples dans EVCore :

• EV_HARD_CAP = 0.90 : un EV supérieur à 90 % contre Pinnacle est irréaliste, il signale une erreur de lambda ou de xG
• MAX_SELECTION_ODDS = 4.0 : les cotes très élevées amplifient les erreurs de probabilité

`soft cap`

Plafond de calibration, moins strict qu’un hard cap.

Utilisé quand un segment (ex : UEL HOME) montre que plus l’EV est élevé, moins le pari gagne — signe d’une sur-confiance du modèle à haute EV. Le soft cap coupe le segment surestimé sans désactiver le marché entier.

`overconfidence`

Situation où le modèle surestime systématiquement la probabilité d’un résultat.

Signe typique :

• P_model = 55 %
• win_rate observé = 30 %
• écart = +25 pp (points de pourcentage)

Dans ce cas, l’EV calculé est gonflé artificiellement, et les paris à EV élevé sont les plus mauvais.

Corrections utilisées dans EVCore : MODEL_SCORE_THRESHOLD plus strict, EV soft cap, seuil de probabilité directionnelle ajusté.

`backtest`

Test du modèle sur des données historiques passées.

Dans EVCore, le backtest simule les décisions du moteur sur des saisons terminées et mesure :

• le ROI simulé
• le Brier score
• l’erreur de calibration (ECE)

Un backtest valide que le modèle est calibré et rentable — pas seulement théoriquement, mais sur des données réelles.

`suspension threshold`

Seuil à partir duquel un marché ou une ligue est automatiquement suspendu.

Dans EVCore, un marché est suspendu si son ROI descend sous -15 % sur au moins 50 paris réglés. La suspension est automatique — seul un humain peut la lever manuellement.

`ETL`

Extract, Transform, Load.

Concrètement :

• récupérer des données
• les transformer
• les charger en base

`sync`

Opération de synchronisation entre une source externe et la base locale.

`worker`

Processus ou job en tâche de fond qui exécute un traitement ciblé.

Exemples :

• sync de fixtures
• import de cotes
• settlement des paris

`one-shot import`

Import ponctuel massif, non continu.

Exemple :

• import historique de plusieurs saisons d’un seul coup

`fallback`

Solution de secours quand la source ou la logique principale n’est pas disponible.

Exemple :

• Pinnacle absent
• repli sur Bet365

`schema`

Structure attendue des données.

Le schéma sert à valider qu’une réponse source ressemble bien à ce que le système attend.

`validation`

Vérification du format et de la cohérence des données entrantes.

`mapping`

Correspondance entre deux représentations.

Exemples :

• nom d’équipe source A vers équipe locale
• code compétition externe vers code interne

`coverage`

Taux de couverture d’une donnée.

Exemple :

• xG coverage = 90 %

Cela signifie que 90 % des matchs attendus disposent d’une valeur xG.

`fixture`

Un match.

Selon le contexte :

• programmé
• en cours
• terminé

`competition`

Une compétition sportive.

Exemples :

• PL
• L1
• UCL

`season`

Une saison sportive.

Exemple :

• 2024-2025

`coupon`

Un ticket ou un groupe de sélections généré pour une journée ou une fenêtre donnée.

`settled bet`

Pari résolu. Le résultat final est connu.

`pending bet`

Pari encore ouvert, non résolu.

`audit`

Contrôle de qualité ou diagnostic approfondi.

Exemples :

• vérifier les lambda
• vérifier les anomalies de calibration
• vérifier la couverture odds

`pipeline`

La chaîne complète de traitement, depuis la collecte de données jusqu’à la décision produit.

Cette section résume les formules les plus utiles pour lire le repo.

Probabilité implicite

probabilité implicite = 1 / cote

Exemple :

odds = 2.20
prob = 1 / 2.20 = 0.4545 = 45.45 %

Overround / marge bookmaker

Sur un 1X2 :

overround = (1 / homeOdds) + (1 / drawOdds) + (1 / awayOdds)
marge = overround - 1

Exemple :

home = 2.50
draw = 3.40
away = 2.90

overround = 1/2.50 + 1/3.40 + 1/2.90
          = 0.4000 + 0.2941 + 0.3448
          = 1.0389

marge = 3.89 %

De-vig simple sur `1X2`

invHome = 1 / homeOdds
invDraw = 1 / drawOdds
invAway = 1 / awayOdds

sum = invHome + invDraw + invAway

pHome = invHome / sum
pDraw = invDraw / sum
pAway = invAway / sum

Exemple :

2.50 / 3.40 / 2.90

invHome = 0.4000
invDraw = 0.2941
invAway = 0.3448
sum = 1.0389

pHome = 0.4000 / 1.0389 = 38.5 %
pDraw = 0.2941 / 1.0389 = 28.3 %
pAway = 0.3448 / 1.0389 = 33.2 %

EV

Formule canonique du projet :

EV = (p * odds) - 1

Exemple :

p = 0.36
odds = 2.90

EV = (0.36 * 2.90) - 1
   = 1.044 - 1
   = 0.044

Donc :

EV = +4.4 %

Kelly

Formule utilisée par le moteur :

K = (p * odds - 1) / (odds - 1)
stakePct = fraction * K

Puis :

• si K <= 0, mise 0
• si stakePct > maxStake, on coupe à maxStake

Exemple :

p = 0.40
odds = 2.80

K = (0.40 * 2.80 - 1) / (2.80 - 1)
  = (1.12 - 1) / 1.80
  = 0.12 / 1.80
  = 0.0667

Soit environ 6.67 % de bankroll en Kelly plein.

Score déterministe

Forme générale :

deterministicScore =
  recentForm * w1 +
  xg * w2 +
  domExtPerf * w3 +
  leagueVolat * w4

Ce score n’est pas une probabilité.

Il sert à vérifier qu’un pick n’est pas seulement “EV positif sur le papier”, mais soutenu par un contexte statistique suffisant.

Lambda Poisson

Interprétation :

lambdaHome = moyenne attendue de buts domicile
lambdaAway = moyenne attendue de buts extérieur

Exemple :

lambdaHome = 1.6
lambdaAway = 1.1

Lecture :

• domicile : 1.6 but attendu
• extérieur : 1.1 but attendu

Construction des lambdas dans EVCore

Forme actuelle du projet :

leagueAvg = max(0.5, (homeXgFor + awayXgFor + homeXgAgainst + awayXgAgainst) / 4)

rawHome =
  alpha * ((homeXgFor * awayXgAgainst) / leagueAvg) +
  (1 - alpha) * anchor

rawAway =
  alpha * ((awayXgFor * homeXgAgainst) / leagueAvg) +
  (1 - alpha) * anchor

Puis correction domicile / extérieur :

lambdaHome = clamp(rawHome * homeAdvFactor, 0.05, 5)
lambdaAway = clamp(rawAway * awayDisadvFactor, 0.05, 5)

Dans le repo :

• alpha = 0.70
• anchor = league mean lambda

Intuition :

• xgFor * xgAgainst / leagueAvg produit le signal équipe contre équipe
• anchor ramène ce signal vers une moyenne de ligue
• homeAdvFactor / awayDisadvFactor corrigent l’avantage terrain
• clamp empêche les valeurs aberrantes

Loi de Poisson

Formule de masse utilisée :

P(X = k) = exp(-lambda) * lambda^k / k!

Interprétation :

• X = nombre de buts
• k = 0, 1, 2, 3, ...
• lambda = moyenne attendue

Probabilités `1X2` via distributions de scores

Une fois qu’on a :

• la distribution des buts domicile
• la distribution des buts extérieur

on additionne tous les cas :

• HOME quand h > a
• DRAW quand h = a
• AWAY quand h < a

`UNDER 2.5`

Dans EVCore, c’est la somme des probabilités de scores dont le total de buts est inférieur ou égal à 2.

UNDER 2.5 = somme des P(h, a) tels que h + a <= 2
OVER 2.5 = 1 - UNDER 2.5

`BTTS`

Approximation utilisée dans le moteur à partir des distributions :

BTTS_YES = (1 - P(home=0)) * (1 - P(away=0))
BTTS_NO = 1 - BTTS_YES

Probabilité jointe combo

Pour deux sélections sur le même match, EVCore cherche une probabilité jointe au lieu de multiplier aveuglément deux probabilités comme si elles étaient indépendantes.

Idée :

P(A et B) != P(A) * P(B) en général

C’est particulièrement important pour des combos comme :

• HOME + OVER 2.5
• DRAW + UNDER 2.5

Brier score multiclasses `1X2`

Formule du repo :

Brier =
  moyenne de [
    (pHome - oHome)^2 +
    (pDraw - oDraw)^2 +
    (pAway - oAway)^2
  ]

avec :

• oHome = 1 si le résultat réel est HOME, sinon 0
• oDraw = 1 si le résultat réel est DRAW, sinon 0
• oAway = 1 si le résultat réel est AWAY, sinon 0

Plus le score est bas, meilleur est le modèle.

Calibration error `ECE`

Le projet utilise une erreur de calibration par buckets :

ECE = somme sur les buckets de
      poids_du_bucket * |proba_moyenne - fréquence_observée|

Plus ECE est faible, plus les probabilités du modèle sont crédibles.

Cette section reprend les codes de compétitions réellement seedés dans la base du projet.

`FRI`

International friendlies, c’est-à-dire matchs amicaux internationaux.

`BL1`

Bundesliga.

`CH`

Championship.

`D2`

2. Bundesliga.

`EL1`

League One.

`EL2`

League Two.

`ERD`

Eredivisie.

`F2`

Ligue 2.

`I2`

Serie B.

`J1`

J1 League.

`L1`

Ligue 1.

`LL`

La Liga.

`MX1`

Liga MX.

`PL`

Premier League.

`POR`

Primeira Liga.

`SA`

Serie A.

`SP2`

Segunda División.

`UCL`

UEFA Champions League.

`UEL`

UEFA Europa League.

`UECL`

UEFA Europa Conference League.

`UNL`

UEFA Nations League.

`WCQE`

World Cup Qualification - Europe.

Codes CSV utiles

Certains codes de compétitions sont reliés à des codes football-data.co.uk dans le seed :

• PL -> E0
• CH -> E1
• EL1 -> E2
• EL2 -> E3
• SA -> I1
• I2 -> I2
• LL -> SP1
• SP2 -> SP2
• BL1 -> D1
• D2 -> D2
• L1 -> F1
• F2 -> F2
• ERD -> N1
• POR -> P1
• J1 -> JPN
• MX1 -> MEX

Si tu ne devais retenir que douze notions :

1. odds = la cote 2. implied probability = 1 / cote 3. de-vig = retirer la marge bookmaker pour retrouver des probabilités propres 4. EV = rentabilité théorique : (p_model × cote) - 1 5. xG = qualité des occasions créées / concédées 6. lambda = buts attendus (entrée du modèle Poisson) 7. Poisson = transforme les lambdas en distribution de scores 8. deterministicScore = score statistique composite du match, sert de filtre qualité 9. probabilité directionnelle = P(direction choisie) — doit dépasser un seuil, sinon le pick est incohérent 10. overconfidence = le modèle surestime la proba, l'EV calculé est trompeur 11. calibration = mesure si les probabilités prédites correspondent à la réalité observée 12. backtest = test du modèle sur des saisons passées pour valider ROI et calibration