ML Football Lab

Le point de départ

Je voulais apprendre le machine learning presque depuis zéro, mais sans commencer par une succession de définitions, de notebooks abstraits ou de formules détachées d’un problème concret.

Le football sert ici de terrain d’intuition. On peut regarder un tir, faire une prédiction naïve — par exemple « plus on est proche du but, plus on a de chances de marquer » — puis observer immédiatement les cas qui mettent cette règle en défaut. Le concept arrive après le problème : on ressent d’abord pourquoi une idée manque, puis on découvre le vocabulaire qui permet de la nommer.

Une progression en sept chapitres

Le premier cycle construit volontairement les notions une par une :

1. Predict — écrire une règle manuelle de distance et observer ses erreurs.
2. Learn — entraîner un premier modèle logistique à partir de la distance.
3. Describe — comprendre pourquoi l’angle apporte une information supplémentaire et introduire les features.
4. Test — séparer train et test pour rencontrer la généralisation avant le vocabulaire associé.
5. Probabilise — relier la probabilité prédite à l’intuition de l’expected goals.
6. Distrust — expérimenter deux pièges différents : overfitting et data leakage.
7. Compare — comparer régression logistique et k-NN, puis modifier k comme premier hyperparamètre.

L’objectif n’est pas de couvrir tout le machine learning. Il est de construire un socle suffisamment intuitif pour que des notions plus avancées aient ensuite un endroit où se rattacher.

Les choix qui comptent

Les expériences des chapitres 04 à 07 tournent réellement dans le navigateur. La régression logistique, le split train/test, k-nearest-neighbours et les évaluations sont implémentés en TypeScript et recalculés pendant les interactions.

Ce choix évite de cacher trop tôt l’apprentissage derrière un backend Python ou une librairie opaque. Pour quelques centaines ou quelques milliers d’observations pédagogiques, le navigateur suffit largement. Une architecture Python ou serveur ne deviendra pertinente que lorsque le volume de données, la complexité des modèles ou les besoins de reproductibilité le justifieront réellement.

À partir du chapitre 04, des sections Sous le capot permettent aussi d’aller plus loin techniquement sans imposer ce niveau de détail à la progression principale.

La donnée comme garde-fou pédagogique

L’application utilise encore des fixtures construites explicitement pour l’apprentissage. Elles ne sont pas présentées comme de vraies observations StatsBomb.

Un convertisseur offline existe déjà pour transformer des événements StatsBomb ouverts vers le même format de tirs. Le prochain gate n’est toutefois pas de remplacer les fixtures le plus vite possible : il faut d’abord choisir un échantillon stable, inspecter l’équilibre buts/non-buts et la géométrie des tirs, puis vérifier que les révélations pédagogiques restent compréhensibles avec des données moins « propres ».

C’est une contrainte intéressante du projet : une donnée plus réelle n’est pas automatiquement une meilleure donnée d’apprentissage si elle rend le premier concept illisible.

Où le projet en est

Le Cycle 1 possède déjà sept chapitres, une navigation progressive, du responsive, la sauvegarde locale de progression et les expériences ML principales directement dans le navigateur. Le repo est public et documente explicitement la frontière actuelle entre pédagogie, runtime ML et préparation des données.

La prochaine étape est surtout un playtest : parcourir les chapitres 04 à 07 avec un regard de débutant complet et repérer les moments où l’explication devient soit trop technique trop tôt, soit au contraire trop magique. Ensuite seulement vient le premier remplacement contrôlé par des données StatsBomb réelles.

Ce que j’en retiens

Le projet me fait déjà changer ma manière d’aborder l’apprentissage technique. Comprendre pourquoi une notion existe avant d’apprendre son nom produit une accroche beaucoup plus forte que mémoriser la définition puis chercher un exemple.

Il montre aussi qu’un outil pédagogique peut être conçu comme un produit : ordre des révélations, difficulté, feedback, données utilisées et niveau de détail optionnel sont des décisions d’expérience, pas simplement du contenu de cours.