Le problème¶
Deux équipes de Counter-Strike 2 vont s'affronter dans quelques heures. La question naïve est « laquelle va gagner ? ». Ce n'est pas la question à laquelle ce projet répond — et comprendre pourquoi est le point de départ de tout le reste.
La question réellement traitée est :
Quelle est la probabilité que l'équipe A batte l'équipe B ?
Un nombre entre 0 et 1. Pas un nom d'équipe. Ce chapitre explique d'où vient cette exigence, sur quelle population elle s'applique, et pourquoi elle est difficile à satisfaire.
Le livrable n'est pas un vainqueur¶
Un pronostic est une décision : « A gagne ». Une probabilité est une description : « A gagne dans 63 % des mondes possibles ».
La différence paraît académique tant qu'on regarde un match isolé. Elle devient structurante dès qu'on empile des matchs — et c'est exactement ce que fait ce projet.
Ce que consomme la suite de la chaîne¶
Le prédicteur de match n'est pas le produit final. Il alimente un simulateur Monte Carlo dont l'objectif est de répondre à une tout autre question : quelles équipes seront invitées au prochain Major ?
Les invitations se lisent directement sur le classement mondial officiel de Valve (le VRS, Valve Regional Standings) à une date de coupure — le cutoff, fixé au 2 novembre 2026 dans la configuration du projet. Un nombre fixe de places est attribué par région : 18 pour l'Europe, 7 pour les Amériques, 7 pour l'Asie.
Le simulateur procède ainsi :
modèle de match simulateur Monte Carlo sortie
┌───────────────────┐ ┌───────────────────────────────┐ ┌────────────────┐
│ p(A bat B) │──►│ pour chaque tirage m = 1..M : │──►│ P(invitation) │
│ pour chacun des │ │ · jouer tous les tournois │ │ par équipe │
│ matchs à venir │ │ restants au hasard, selon p│ │ │
│ │ │ · recalculer le classement │ │ = fraction des │
│ │ │ VRS complet au cutoff │ │ futurs où │
│ │ │ · noter qui tient un slot │ │ l'équipe est │
└───────────────────┘ └───────────────────────────────┘ │ dans ses │
M = 500 par défaut │ slots │
└────────────────┘
La sortie est littéralement un décompte :
| Symbole | Signification |
|---|---|
| \(M\) | Nombre de futurs simulés (500 par défaut, paramétrable) |
| \(m\) | Indice d'un futur simulé |
| \(\mathbf{1}[\cdot]\) | Vaut 1 si la condition est vraie, 0 sinon |
| \(\hat{P}\) | Estimation de la probabilité — un chapeau, parce que c'est une fréquence observée sur \(M\) tirages, pas une vérité |
Autrement dit : P(invitation au Major) est une fraction de futurs simulés. Rien d'autre. Toute la subtilité du résultat vient de la diversité de ces futurs — et cette diversité vient exclusivement du fait que chaque match est tiré au sort, pas décidé.
Ce qui se passe si on remplace la probabilité par un pronostic¶
Supposons que le modèle de match renvoie 0 ou 1 au lieu d'une probabilité. Alors chaque tirage donne exactement le même résultat : les mêmes équipes gagnent, le même classement sort, les mêmes slots sont occupés.
Les 500 futurs deviennent 500 copies d'un unique futur. La fraction ne peut plus valoir que 0 ou 1. Une équipe est invitée à 100 % ou éliminée à 100 %, et on a perdu toute l'information qui faisait l'intérêt de l'exercice.
Intuition
Le Monte Carlo ne fabrique pas de l'incertitude : il transporte celle du modèle de match jusqu'à la question qui intéresse le lecteur. Si l'entrée n'a pas d'incertitude, la sortie n'en a pas non plus. Une probabilité de match est le carburant du simulateur, un pronostic en est le sable.
Un exemple minimal suffit à le voir. Une équipe doit enchaîner trois victoires pour sécuriser sa place, avec une probabilité de 0,6 à chaque match — on suppose ici les matchs indépendants, ce qui est une simplification.
Le modèle probabiliste répond « 21,6 % ». Le modèle à pronostics répond « elle gagne les trois » — donc 100 % — parce que \(0{,}6 \geq 0{,}5\) trois fois de suite. L'écart entre 21,6 % et 100 % n'est pas une nuance : c'est la différence entre une information exploitable et une affirmation fausse.
On descend des probabilités vers les pronostics, jamais l'inverse¶
Un pronostic se déduit trivialement d'une probabilité : on annonce A si \(p \geq 0{,}5\), B sinon. C'est d'ailleurs exactement ce que fait la métrique d'accuracy du chapitre suivant.
L'opération inverse est impossible. Un « A gagne » ne dit pas si l'écart est énorme ou infime. L'information est détruite, définitivement.
C'est pourquoi tout le projet — les onze approches, les métriques, le protocole — travaille sur des probabilités, et pourquoi le juge de paix de la campagne est une métrique qui punit les probabilités malhonnêtes plutôt que les pronostics erronés.
Erreur fréquente
« Mon modèle a 68 % d'accuracy, donc ses probabilités sont bonnes. » Non : l'accuracy ne regarde que le côté de 0,5 sur lequel tombe la probabilité. Un modèle qui annonce systématiquement 0,51 ou 0,99 selon son humeur peut avoir exactement la même accuracy et être inutilisable dans le Monte Carlo. Le chapitre 2 le démontre chiffres en main.
Le pool réel¶
Une métrique n'existe pas dans l'absolu : elle est calculée sur une population de matchs. Savoir laquelle est aussi important que savoir laquelle métrique.
Ce qui compte comme un match¶
Le projet ne prédit pas « tous les matchs de CS2 ». Il prédit les matchs qui comptent pour le classement de Valve, parce que ce sont ceux qui déterminent les invitations. Le filtre est repris tel quel du code officiel :
- cinq joueurs identifiés de chaque côté — un match à effectif incomplet est inexploitable ;
- depuis le 1ᵉʳ janvier 2025, le match doit être marqué ranked par Valve — avant cette date, tous les matchs comptaient ;
- pour l'entraînement, il faut en plus un vainqueur connu et les identifiants des deux équipes, faute de quoi la ligne n'a ni étiquette ni moyen d'être rattachée à un historique.
Il n'existe aucun système de tiers¶
C'est un point souvent mal compris de l'extérieur. Le classement de Valve ne connaît pas la notion de tier 1 / tier 2 / tier 3. Un tournoi n'est pas classé dans une catégorie : il reçoit un poids continu dérivé de sa dotation.
| Symbole | Signification |
|---|---|
| \(w_{\text{event}}\) | Poids de l'événement, entre 0 et 1 |
| dotation | Prize pool en dollars, borné entre 1 et 1 000 000 |
| \(\operatorname{curve}\) | Courbe symétrique en échelle logarithmique autour de \(x = 1\) |
Le plancher à 1 dollar est dans le code de Valve, pas une invention du projet : un tournoi sans dotation déclarée ne pèse pas zéro, il pèse \(\operatorname{curve}(10^{-6}) \approx 0{,}143\). Un tournoi à un million de dollars pèse 1.
La conséquence pratique est directe : le pool mélange les niveaux. Des demi-finales d'IEM y côtoient des matchs de ligues régionales à quelques milliers de dollars, avec des équipes que personne ne connaît.
Combien de matchs, sur quelle fenêtre¶
La fenêtre native du classement de Valve est de six mois — le projet la reproduit à l'identique, parce que c'est cette fenêtre qui définit le classement qu'on cherche à simuler.
Pendant la campagne d'apprentissage, cette fenêtre a été étendue à douze mois, non pas pour changer la définition du classement, mais pour réchauffer les horloges de force (Elo, Glicko, TrueSkill) avant la période mesurée : un système de rating qui démarre à froid met plusieurs mois à devenir informatif.
| Fenêtre | Entraînement | Holdout | Total |
|---|---|---|---|
| native, 6 mois | 4 916 | 1 146 | 6 062 |
| étendue, 12 mois | 10 287 | 1 146 | 11 433 |
Environ 6 000 matchs par semestre, donc, dont 1 146 réservés à la mesure finale. C'est peu pour de l'apprentissage automatique moderne, et cette rareté explique une grande partie des choix de la campagne : des modèles petits et fortement régularisés, une méfiance systématique envers les architectures gourmandes, et une attention obsessionnelle au bruit d'échantillonnage.
Le découpage temporel exact — pourquoi 42 jours, pourquoi cette coupure et pas une autre — est le sujet du chapitre 3.
Ce que cette composition interdit¶
Le repère le plus cité de la campagne, « bookmakers : Brier 0,198, accuracy 68,7 % », vient de la littérature et porte sur des matchs de tier 1 uniquement.
Limite importante
Nos 0,2041 et les 0,198 des bookmakers ne sont pas mesurés sur la même population. Notre pool mêle des affiches d'élite et des matchs où l'écart de niveau est écrasant ; ces derniers sont beaucoup plus faciles à prédire, ce qui pousse nos chiffres vers le bas (Brier) et vers le haut (accuracy) sans que le modèle soit meilleur pour autant.
Le 0,198 est un ordre de grandeur d'ambition, jamais un verdict. La seule comparaison rigoureuse du projet est interne : chaque approche contre les autres, sur exactement les mêmes 1 146 matchs.
Ce caveat sera répété partout où le chiffre apparaît. Il n'est pas de la prudence rhétorique : c'est la différence entre un classement interne défendable et une comparaison qui ne veut rien dire.
Ce qui rend le problème dur¶
Prédire un match de CS2 est difficile pour deux raisons de nature très différentes, qu'il faut absolument séparer : l'information qui manque, et le hasard qui reste.
L'information qui manque¶
Le modèle voit l'historique. Il ne voit pas ce qui se passe dans les deux heures qui précèdent le match.
La composition du jour. Un cinq peut changer sans préavis : joueur malade, remplaçant, problème de visa. Le projet approche cette information avec une variable de stabilité — la proportion de joueurs communs entre le cinq annoncé et celui du match précédent, sur 5 — mais c'est un proxy rétrospectif : quand le remplacement est annoncé une heure avant, il n'existe nulle part dans les données au moment où la prédiction doit être produite.
La motivation et l'enjeu réel. Le projet dispose du poids de l'événement, dérivé de la dotation. C'est une mesure de l'enjeu théorique. Elle ne dit rien d'une équipe déjà qualifiée qui joue son dernier match de poule sans y croire, d'un roster qui se sépare la semaine suivante, ou d'une finale de qualifier où tout se joue. Cette information circule dans les communautés, pas dans les tableaux de résultats.
Le marché. Les cotes des bookmakers agrègent, en temps réel, l'argent de gens qui savent des choses — y compris les deux points précédents. Elles ne font partie d'aucune donnée du projet. C'est une raison structurelle, et pas seulement technique, pour laquelle le 0,198 est difficile à atteindre : le bookmaker n'a pas un meilleur modèle, il a une meilleure entrée.
Intuition
Une bonne partie de l'écart restant entre un modèle statistique et un bookmaker n'est pas un écart de mathématiques. C'est un écart d'information. On peut raffiner l'algorithme indéfiniment sans jamais combler ce qui n'est pas dans les données.
Le hasard qui reste¶
Même en connaissant parfaitement les vraies probabilités, on ne peut pas atteindre un score parfait. Un match à 60/40 reste un match à 60/40 : le perdant annoncé gagne quatre fois sur dix, et le modèle « se trompe » quatre fois sur dix sans avoir commis la moindre erreur.
Formellement, si \(p\) est la vraie probabilité et que le modèle l'annonce exactement, l'erreur quadratique attendue sur ce match vaut :
où \(y \in \{0, 1\}\) est le résultat observé. Cette quantité est maximale à \(p = 0{,}5\) (elle vaut 0,25) et tend vers 0 quand \(p\) s'approche de 0 ou de 1.
En moyennant \(p(1-p)\) sur les probabilités effectivement annoncées par le leader de la campagne — calcul fait par tranches sur sa table de calibration — on obtient un ordre de grandeur du plancher de ce pool :
Limite importante
Ce 0,210 est un calcul dérivé, pas une mesure, et il est approximatif : il utilise la probabilité moyenne de chaque tranche au lieu de chaque probabilité individuelle, ce qui gonfle mécaniquement le résultat. C'est d'ailleurs pourquoi le Brier réellement mesuré (0,2041) tombe en dessous de cette estimation, ce qui serait impossible si le calcul était exact.
À retenir uniquement ceci : le plancher de ce pool est de l'ordre de 0,20, pas de 0. Le modèle final n'en est pas très loin, et l'espace de progression restant est bien plus étroit que ne le suggère la distance à zéro.
Tous les matchs ne sont pas également durs¶
Le pool n'est pas homogène, et le leader final le montre crûment. Sur les mêmes 1 146 matchs du holdout, découpés par segment :
| Segment | \(n\) | Brier | Accuracy |
|---|---|---|---|
| LAN | 380 | 0,1722 | 74,7 % |
| Bo1 | 60 | 0,1729 | 76,7 % |
| Bo3 en ligne entre équipes établies | 758 | 0,2205 | 64,3 % |
Sur LAN, le modèle atteint un niveau comparable au repère des bookmakers — sur un segment, et toujours sur un pool différent du leur. Sur le Bo3 en ligne entre équipes bien connues des systèmes de rating, il plafonne près de cinq centièmes de Brier plus haut — \(0{,}2205 - 0{,}1722 = 0{,}0483\), soit presque huit fois l'écart qui sépare encore le leader final du repère des bookmakers (\(0{,}2041 - 0{,}198 = 0{,}0061\)).
Ce dernier segment est le noyau dur du problème : les deux équipes sont documentées, les horloges de force les connaissent bien, l'écart est faible, et le format long réduit la variance qui pourrait produire une surprise exploitable. C'est là que la campagne a buté, et c'est là qu'une hypothèse apparemment solide — « un modèle plus simple devrait mieux s'y comporter » — s'est fait démentir par le protocole. Cette histoire est racontée au chapitre 3.
À retenir
- Le livrable est une probabilité, parce que le Monte Carlo en aval calcule \(P(\text{invitation})\) comme une fraction de futurs simulés : sans incertitude en entrée, il n'y a pas de nuance en sortie.
- Le pool réel, c'est ~6 000 matchs par semestre (11 433 sur douze mois), tous niveaux confondus — le classement de Valve ne connaît pas de tiers, seulement un poids continu dérivé de la dotation.
- La difficulté a deux sources distinctes : l'information absente (compositions du jour, motivation, marché) et le bruit irréductible, dont le plancher pour ce pool est de l'ordre de 0,20 de Brier.
- Toute comparaison avec les 0,198 des bookmakers est indicative : ce n'est pas le même pool.
Chapitre suivant : Les métriques — comment on transforme 1 146 probabilités et 1 146 résultats en un seul nombre, et pourquoi ce nombre n'est pas l'accuracy.