Étude de cas · Projet personnel · 2026 — auj.
Sightstone
Un moteur de draft qu’on peut contredire.
- 18 127
- parties pro rejouées pour vérifier le moteur
- 49 %
- des vrais picks pro dans son top six, contre 9 % au hasard
- 567
- tests unitaires
- 2 jours
- du premier commit à un premier moteur calibré
En bref
- Le besoin
- Mon équipe drafte avec trente secondes par choix, et n’avait aucun outil pour s’y préparer.
- Ce que j’ai construit
- Une salle de draft dont le moteur explique chacune de ses suggestions, vérifié sur les données pro. Mon équipe s’en sert.
- Mon rôle
- Tout : le produit, l’architecture, le moteur et son calibrage. Seul, en pilotant des agents de code IA.
01 — Le pari
Une suggestion doit donner ses raisons.
Chaque score se décompose
Avant chaque partie de League of Legends, les deux équipes bannissent puis choisissent leurs champions à tour de rôle : vingt choix, une trentaine de secondes chacun. Les équipes pro préparent cette draft avec des analystes. Mon équipe à Lausanne Esport, en semi-pro, n’avait rien de tel. J’ai donc construit ce qui nous manquait : étudier l’adversaire, écrire les scénarios ensemble, drafter en direct le soir du match, puis revoir la série.
Au centre, il y a le moteur, et un pari produit. Un coach passe outre une boîte noire la première fois qu’elle se trompe, et ensuite il ne l’écoute plus. Le moteur n’est donc pas un modèle entraîné mais une somme de poids nommés. Chaque suggestion se décompose en ces termes, assez vite pour être lue pendant le chrono.
- 01Lee Sin 7,17
- tier S pour Orin+3,00
- en forme+1,00
- 58 % de présence en pro+1,09
- dans le plan « Plan A »+2,50
- exposé à un contre qu’ils peuvent prendre−0,42
- 02Jarvan IV 4,51
- 03Xin Zhao 3,85
Rejoué pick par pick sur 18 127 parties professionnelles, avec tous les champions disponibles, le choix réellement fait par le pro est dans son top six 49 % du temps, contre 9 % au hasard.
Une illustration : les vrais poids par défaut et la vraie formule du moteur, la présence pro de la semaine, sur une situation construite pour l’exemple.
02 — La preuve
Puis j’ai laissé les données me contredire.
Une règle fixée d’avance
Le moteur a deux moitiés. Les suggestions classent les champions pour le prochain pick. Le verdict lit une draft entière et dit quel camp elle avantage, à partir de quatre lectures : le matchup de chaque lane, les paires de champions, la forme de chaque composition, et le patch. Des poids posés à la main restent une intuition. Une tâche rejoue donc 18 127 parties professionnelles dans les deux moitiés, en évaluant chaque partie avec les seuls patchs joués avant elle, et ajuste le verdict par régression logistique.
Ce que l’ajustement a corrigé dans le verdict
- Les laneslog-odds par point de force du matchup
- 0,120,28
- Les paires de championselles valent moins que je ne pensais
- 0,720,46
- Le côté bleu, à lui seul0,135 log-odds, avant tout pick
- 53,4 %
Les poids ajustés ont donc remplacé les miens, selon une règle fixée avant de voir le résultat : un ajustement ne passe en production que s’il est mieux calibré, sans perdre plus d’un demi-point au classement. Et je ne le cache pas : une draft ne déplace une partie que de quelques points ; les cinq joueurs font le reste.
03 — Une décision
Pourquoi il regarde un pick plus loin, et pas davantage.
Pas une question de calcul
Un moteur d’échecs calcule de nombreux coups à l’avance. Sightstone ne regarde qu’un pick plus loin : avant de suggérer un champion, il vérifie ce que l’autre équipe pourrait répondre, pondéré par la probabilité qu’elle le fasse. Aller plus loin ne coûterait presque rien en calcul, mais rendrait l’outil moins bon, pour quatre raisons.
Le score est trop faible.
Les échecs se prêtent à une recherche profonde parce que le mat est un résultat net. Une draft déplace à peine l’issue d’une partie (AUC 0,54), et une recherche profonde sur un score aussi bruité trouve surtout les branches où le bruit a eu l’air bon.
L’adversaire n’est pas un joueur parfait.
La recherche classique suppose qu’il joue toujours le coup le plus dur pour nous. Une équipe amateur joue ce qu’elle connaît : le moteur lit donc ses picks probables dans son propre historique, et cette estimation se brouille un peu plus à chaque tour.
Il faudrait aussi deviner nos propres picks.
Soit le moteur joue contre lui-même et renforce ses propres biais, soit il modélise le coach à partir d’une trentaine de parties par split, ce qui ne suffit pas pour apprendre.
La raison doit tenir en une ligne.
Aujourd’hui, un coach lit « exposé à Fiora (62 %) s’ils la prennent » et peut le vérifier tout de suite. Un arbre de recherche ne se résume pas en une ligne.
Si une recherche doit un jour trouver sa place, ce sera en fin de draft, quand il reste peu de tours et que chaque choix pèse lourd. Au premier pick d’une partie, le moteur trouve le choix du pro dans son top six 71 % du temps ; au dernier, 39 %. Le même backtest tranchera : une recherche à deux tours n’entrera que si ce dernier chiffre monte.
04 — Architecture
Pensée pour un chrono de trente secondes, et un seul développeur.
Deux contraintes ont décidé du reste : une salle qui drafte contre la montre, et une seule personne pour la faire tourner. Les données des champions viennent du CDN public de Riot, donc pas besoin de clé pour drafter. Les tâches longues, comme l’import des drafts pro ou le réajustement des poids, tournent sur GitHub Actions plutôt qu’en serverless. Le plus simple, pour voir ce que le chrono impose, c’est de suivre un seul pick.
- 01
Une seule lecture pour toute la draft. À l’ouverture de la salle, chaque écran charge le plateau une fois. Ensuite, c’est le navigateur qui travaille.
- 02
Le clic n’attend jamais. À qui le tour ? La longueur de quatre tableaux suffit à le dire, rien n’est stocké. Le moteur reclasse dans l’onglet, sans requête.
- 03
Un aller-retour, une ligne. Chaque entrée indique combien de cases son écran voyait, et Postgres n’ajoute que si la ligne est d’accord. Un clic périmé est refusé, pas ajouté.
- 04
Un signal, pas un état. L’onglet qui a écrit prévient les autres que la draft a bougé, sans dire comment. Intercepter le message n’apprend rien.
- 05
Chaque lecture repasse par l’API. Les autres écrans relisent la draft par l’API, qui vérifie l’équipe, puis reclassent sur place.
La suite
Mon équipe s’en sert aujourd’hui. Ensuite viendront les équipes amateurs, pour que leurs drafts et leurs bilans nourrissent le calibrage ; puis les équipes pro, avec les données de match de GRID et une clé de production Riot.