Picks Tennis

Jeu de picks tennis personnel, mono-utilisateur. Next.js 16 (App Router) + Supabase + Tailwind v4.

Principe

À chaque tour d'un tournoi, on « pique » des joueurs. Barème : 5 pts par match gagné, net sets ×3 (plancher 0), net games sur les sets gagnés uniquement. Un forfait gagné vaut 5 pts secs, 10 pts pour un tournoi en 3 sets gagnants commencé le 2026-10-05 ou après (Shanghai 2026) — voir Où corriger le barème des picks. Un joueur ne peut être pické qu'une seule fois sur tout le tournoi — c'est la contrainte structurante du jeu. 12 picks par tournoi (2 par tour jusqu'aux quarts, puis 1 en demi et 1 en finale).

Le moteur (lib/) vient du projet tennis-picks : scoring, Elo par surface, simulation Monte Carlo, affectation optimale (algorithme hongrois), parser du JSON du bookmarklet. Il a été modifié et enrichi ici. Les six modules d'origine (types, scoring, elo, optimizer, montecarlo, parser) ont évolué, par exemple pour le barème forfait/abandon, le statut in_progress, le support WTA, l'échelle Elo configurable, le mélange Elo/cotes et la réconciliation des IDs joueurs. D'autres modules ont été ajoutés (voir Structure). C'est désormais la copie de référence : un bug du moteur se corrige ici, jamais dans tennis-picks/lib, qui est dépassé.

Démarrer

npm run dev      # http://localhost:3000

Variables d'environnement (.env.local) :

NEXT_PUBLIC_SUPABASE_URL=...
NEXT_PUBLIC_SUPABASE_ANON_KEY=...      # publique : lecture seule, inlinée dans le bundle
SUPABASE_SERVICE_ROLE_KEY=...          # SECRET : jamais préfixée NEXT_PUBLIC_
APP_PASSWORD=...                       # mot de passe unique d'accès à l'app
AUTH_SECRET=...                        # signature du cookie (sinon dérivé d'APP_PASSWORD)

Modèle complet dans .env.example.

Accès à l'app

L'app entière est privée derrière un mot de passe unique (APP_PASSWORD). proxy.ts — le middleware.ts de Next 16 — redirige vers /login toute requête sans cookie de session valide, et répond 401 sur /api/* et sur les Server Actions, où une redirection HTML serait illisible.

Le cookie tn_session est httpOnly, SameSite=Lax, secure en production, et signé en HMAC-SHA256 : il ne contient qu'une expiration, elle-même dans la charge signée — donc non modifiable côté client. Rien n'est stocké en base.

Le proxy n'est pas la ligne de défense principale. La doc Next 16 est explicite : une Server Action n'est pas une route, c'est un POST vers la route qui l'héberge, qu'un changement de matcher peut sortir de la couverture du proxy sans bruit. Chaque écriture revérifie donc la session elle-même via auth/garde.ts — importerExtrait, validerPick, supprimerPick, POST /api/recompute.

npm run build && npm start
npm run verify:auth            # 401 sans cookie, cookie signé, contournements

Sécurité de la base

Toutes les tables tn_* et ta_* sont en lecture publique / écriture service-role. Chaque migration qui crée une table y active la RLS, pose une seule policy for select to anon, authenticated, et retire aux rôles publics tout droit d'écriture. La clé publique (anon) sert à lire, rien d'autre. Seule la service role, utilisée côté serveur uniquement, écrit.

Côté fonctions SQL :

• tn_recompute_picks et tn_score_match ne sont pas appelables en RPC avec la clé publique (0001, 0009, 0013) ;
• ta_elo_a_la_date (0010) l'est volontairement. Elle est en lecture seule (stable, security invoker) et ne renvoie que ce que la table publique ta_elo_historique montre déjà.

Migrations

Les 20 migrations de supabase/migrations/ (0001 → 0020) se jouent dans l'ordre, une fois chacune : éditeur SQL Supabase, ou SUPABASE_ACCESS_TOKEN=sbp_… node scripts/appliquer-migration.mjs <fichier.sql>. La liste commentée, la date d'application de chacune et une requête de vérification par migration sont dans MIGRATIONS.md.

Gestes à ne pas oublier :

• après 0003 : repeupler ta_elo depuis /import/elo. La migration la vide, et seul un import la remplit, slug compris ;
• après 0012 et après 0013 : rejouer le backfill Fantasy (écran Calibration). Ces migrations suppriment des lignes de tn_fantasy_historique que seul le backfill réécrit ;
• 0015 et 0016 sont remplacées : 0016 supprime la table de 0015, et 0018 celle de 0016. Ne pas les rejouer sur une base qui a déjà 0018.

Vérifier

# Depuis la clé publique : lecture OK, écritures et RPC refusées
npm run verify:rls

verify:rls contrôle les 15 tables du schéma (migrations 0001 à 0020). Toute migration qui crée une table doit aussi l'ajouter à TABLES dans scripts/verifier-rls.mjs, sans quoi le « Tout est conforme » ne dit rien d'elle.

Tant que 0001 n'est pas appliquée, les pages s'affichent vides : les lectures se font avec la clé publique, que la RLS filtre à 0 ligne.

Écrans

• /import — coller le JSON du bookmarklet ATP ou WTA (même format, au champ tour près). parseExtract() + verifierExtraction(), puis upsert dans tn_tournaments, tn_players, tn_matches (réimportable après chaque tour). Le circuit du tournoi décide du rapport Elo interrogé : un tableau WTA n'est jamais rapproché des joueurs ATP, et inversement.
• /import/elo — mise à jour des Elo Tennis Abstract, par collage. Tennis Abstract répond 403 aux requêtes venant des IP de datacenter (Vercel) : le fetch serveur n'aboutit plus en production, alors que la page s'ouvre normalement dans un navigateur. C'est donc le navigateur qui lit le rapport — snippet public/extract-elo.js, servi par l'app (derrière le mot de passe) et copiable en un clic depuis l'écran — et l'app qui reçoit le JSON par collage, POST /api/elo/import. Un circuit à la fois, ou les deux en collant [extraitAtp, extraitWta]. L'écriture en base est rigoureusement la même que celle du fetch (mêmes lignes, même upsert par (ta_slug, tour), mêmes caches invalidés) : seule la source change. Chaque import laisse une trace datée. ta_elo est écrasée — c'est l'état courant, celui que lisent les picks, le fantasy et la simulation — mais le même rapport est aussi versé dans ta_elo_historique, sous la date qu'il annonce (« Last update »). Sans cette archive, juger un match passé se ferait sur l'Elo d'aujourd'hui, qui a déjà intégré son résultat. L'archive ne remonte pas le temps : elle part de l'instantané courant et n'accumule que vers l'avant, donc les tournois déjà en base n'auront jamais d'Elo antérieur. POST /api/elo/refresh est conservé en repli — inutilisable depuis Vercel, mais fonctionnel en local, et prêt à resservir si le filtre tombe. Le bouton « Tenter le fetch serveur » est en bas de l'écran.
• /tournoi/[id] — vue du tableau tour par tour (lecture seule).
• /tournoi/[id]/predictions?vue=tableau (onglet Prédictions → « Tableau pronostiqué » ; l'ancienne URL /tournoi/[id]/bracket y redirige, l'onglet « Bracket » désignant désormais le jeu, route /simulateur) — arbre pronostiqué depuis le tirage, du premier tour au champion. Pronostic déterministe : à chaque match, le plus haut Elo effectif sur la surface du tournoi (mélange 60/40, le même que l'écran Picks et que la simulation) l'emporte et avance ; un exempté passe sans match. À Elo strictement égal, le mieux classé ; à rang égal, un départage stable par identifiant, pour que deux affichages ne donnent jamais deux champions. Aucun Monte Carlo — un simple parcours de l'arbre, calculé à chaque affichage (quelques millisecondes). : seul alimente le calcul, la suite est déduite. L'arbre est donc identique que le tournoi soit à venir, en cours ou terminé — même parti pris que l'espérance Fantasy. Il n'y a rien à invalider, et un tour intermédiaire manquant en base ne l'empêche pas de se remplir. Rendu pensé pour le téléphone : un tour à la fois (sélecteur de tours), duels en liste verticale, filtre par moitié de tableau au-delà de 4 duels, et la carte du champion prédit avec son parcours tour par tour en tête d'écran. La logique vit dans , module pur sans I/O.

Décisions d'architecture

Ces points s'écartent légèrement de l'énoncé, pour des raisons dictées par la base et par Next.js 16 :

• Un joueur, plusieurs espaces d'identifiants. tn_players.id est l'ID de la source qui l'a fait entrer en base. Les extractions ne partagent pas toutes le même espace : à côté des ID officiels (J0DZ, KE17, 326160) on trouve des identifiants Sportradar (SR:COMPETITOR:972327) et un second espace numérique WTA. Une même personne peut donc arriver sous deux lignes, chacune avec ses matchs et son Elo maison — et le rapprochement Tennis Abstract ne s'accroche qu'à l'une d'elles, l'autre tombant en Elo « défaut ». Corrigé au cas par cas (migration 0011), jamais automatiquement : deux lignes de même nom sont parfois deux vraies personnes. Les deux « X. Wang » (326160 et 326376) sont deux joueuses distinctes, avec chacune leurs matchs ; les fusionner créerait le bug qu'on corrige. Le critère de fusion n'est donc pas le nom mais la preuve : mêmes tournois impossibles à cumuler, ou une ligne sans le moindre match face à une ligne peuplée.

• Elo courant pour prédire, Elo archivé pour juger. ta_elo ne garde qu'un instantané : le dernier import écrase le précédent. C'est ce qu'il faut pour la production — prédire un match à venir avec l'Elo du jour n'est pas un biais, c'est la seule chose à faire — mais pas pour les écrans de mesure. Sur un match déjà joué, l'Elo d'aujourd'hui a intégré son résultat : le vainqueur en est ressorti relevé, le perdant abaissé, si bien qu'a posteriori le favori d'une affiche est en partie désigné par son résultat. Le biais est orienté — le favori gagne trop souvent, l'Elo paraît meilleur qu'il ne l'est, et la courbe plus raide qu'elle ne l'est. D'où ta_elo_historique (migration 0010) : chaque import y ajoute un instantané daté du rapport, et la fonction SQL ta_elo_a_la_date(tour, date) rend, pour chaque joueur, sa dernière valeur strictement antérieure à une date. Par joueur et non par rapport, parce qu'un rapport hebdomadaire ne republie pas tout le monde — même règle que ta_elo, qui ne supprime jamais un joueur absent du rapport de la semaine. Deux frontières, tenues explicitement : la production n'appelle jamais db/elo-historique.ts, et les écrans de mesure ne remplacent jamais un Elo antérieur manquant par l'Elo courant — ni par l'Elo maison, recalculé sur les matchs importés, qui rentrerait le look-ahead par la porte de derrière. Un trou se signale (compté et affiché), il ne se remplit pas. Enfin l'archive ne remonte pas le temps : Tennis Abstract ne publie que le rapport de la semaine, donc l'évaluation propre ne portera que sur les tournois joués après sa mise en place.

• Séparation lecture / écriture des clés Supabase. Les lectures passent par la clé publique (), adossée à des policies RLS sur les 5 tables : ce client ne peut rien modifier, et reste donc utilisable jusque dans le navigateur. Les écritures (import, picks, cache de projections, ) passent par la (), qui contourne RLS et ne vit que côté serveur — le module porte , ce qui casse le build s'il est atteint depuis un Client Component. Aucune policy insert/update/delete n'existe : même volée, la clé publique ne permet aucune écriture.

Tester

madrid2026.json (127 matchs, 96 joueurs) permet de tester l'import et tous les écrans sans extraction fraîche : le coller dans /import.

Structure

proxy.ts                         porte d'entrée : tout est privé sauf /login
auth/
  session.ts                     jeton signé HMAC (importable depuis proxy.ts)
  garde.ts                       contrôle de session dans les écritures
app/
  login/                         mot de passe unique → cookie de session
  page.tsx                       liste des tournois
  fantasy/                       historique prédit / réalisé + bouton de reprise
  calibration/                   courbe Elo→proba confrontée aux matchs joués
  calibration/echelle/           effet d'une autre échelle sur le jeu Fantasy
  calibration/cotes/             blend Elo/cotes — mesure isolée, rien de branché
  import/                        import du JSON + action serveur
  import/elo/                    collage des Elo TA (snippet public/extract-elo.js)
  face-a-face/                   bilan entre deux joueurs + comparaison Elo
  bilan/                         bilan de saison (donnees.ts assemble, page affiche)
  tournoi/[id]/                  tableau, bracket, picks, fantasy, predictions, resultats
  tournoi/[id]/BadgeSourceElo.tsx  provenance d'un Elo — partagé picks/fantasy
  tournoi/[id]/fantasy/scenario/ « et si » du Fantasy (action serveur en lecture seule)
  api/recompute/route.ts         POST → tn_recompute_picks()
  api/elo/import/route.ts        POST → Elo TA collés (méthode principale)
  api/elo/refresh/route.ts       POST → Elo TA par fetch (repli, 403 sur Vercel)
  api/fantasy/backfill/route.ts  POST → historique des tournois déjà en base
  api/calibration/elo/route.ts   POST → calibration Elo→proba, en JSON
  api/cotes/refresh/route.ts     POST → cotes The Odds API → cache tn_odds
  EloRefreshButton.tsx           bouton du repli par fetch (écran /import/elo)
db/
  anon.ts                        client clé publique — LECTURES uniquement
  server.ts                      client service-role (server-only) — ÉCRITURES
  queries.ts                     point d'entrée, réexporte les quatre suivants :
  types.ts                         types des lignes tn_*
  lectures.ts                      lectures (clé anon)
  tableau.ts                       joueurs en lice, tour courant, état des slots
  moteur.ts                        reconstruction Match[]/Player, loadEngineData
  elo.ts                         cascade TA → défaut + sources (étage « maison »
                                 écrit mais jamais atteint, cf. plus haut)
  elo-refresh.ts                 collage OU fetch TA → ta_elo (écrasée) ET
                                 ta_elo_historique (instantané daté ajouté)
  elo-historique.ts              Elo tel qu'il était AVANT une date — lecture de
                                 l'archive, pour les seuls écrans de mesure
  fantasy-anterieur.ts           équipe Fantasy rejouée sur l'Elo d'avant le
                                 tirage (sans look-ahead, hors cache)
  projections.ts                 simulation Monte Carlo + cache tn_projections
  reference.ts                   score de référence : projections par tour puis
                                 lib/reference.ts (mémoïsé par requête)
  fantasy.ts                     point d'entrée : fantasy-cache.ts (espérances a
                                 priori, cache tn_fantasy) + fantasy-historique.ts
                                 (équipe, score réel, historique)
  face-a-face.ts                 rencontres entre deux joueurs + Elo comparés
  bilan-saison.ts                lectures paginées du bilan de saison
  calibration.ts                 mesure de la courbe Elo→proba (lecture seule)
  comparaison-echelle.ts         rejoue le Fantasy sous d'autres échelles Elo
supabase/migrations/             0001 → 0020, cf. MIGRATIONS.md (seul contenu de
                                 supabase/, dossier attendu par la CLI)
scripts/verifier-rls.mjs         contrôle des accès avec la clé publique
scripts/verifier-auth.mjs        contrôle de la protection par mot de passe
scripts/appliquer-migration.mjs  joue un .sql via l'API Management Supabase
lib/                             moteur issu de tennis-picks, modifié depuis
                                 (copie de référence, cf. Principe)
                                 Les plus gros modules sont découpés derrière un
                                 point d'entrée qui réexporte tout (les imports
                                 `@/lib/x` ne changent pas) : bracketSim →
                                 bracketArbre + bracketScenarios ; montecarlo →
                                 montecarloTournoi + montecarloBracket ; optimizer
                                 → optimizerProbabilites + optimizerAffectation ;
                                 parser → parserExtraction + parserJoueurs +
                                 parserControles ; calendrier (logique) +
                                 calendrierDonnees (fiches des tournois)
lib/fantasy.ts                   AJOUT : paliers, multiplicateurs, équipe optimale,
                                 score réel (réutilise optimizer/scoring/montecarlo
                                 tels quels) — point d'entrée de fantasyRegles.ts
                                 (bye, barèmes, paliers) + fantasyCalcul.ts
lib/bracket.ts                   AJOUT : arbre pronostiqué depuis le tirage
                                 (déterministe, sans Monte Carlo ni résultats)
lib/cotes.ts                     AJOUT : dévigorisation, consensus des books,
                                 scores de Brier et log-loss (mesure seule)
lib/reference.ts                 AJOUT : picks recommandés tour par tour sous
                                 contrainte d'unicité, et leurs points réels
lib/picksRegles.ts               AJOUT : règles datées du jeu des picks
                                 (forfait gagné à 10 pts, pointsForfaitPour)
lib/faceAFace.ts                 AJOUT : bilan des rencontres entre deux joueurs
lib/bilanSaison.ts               AJOUT : agrégats du bilan de saison
lib/cotesEvolution.ts            AJOUT : séries de cotes avant chaque match
lib/fantasyScenario.ts           AJOUT : probabilités surchargées, score projeté

Où corriger le barème des picks

Le barème d'un match est dans lib/scoring.ts (scoreMatch) et son miroir SQL tn_score_match : les deux doivent rester identiques. Une règle qui change en cours de saison n'y est pas écrite en dur : elle est datée dans lib/picksRegles.ts (miroir SQL tn_points_forfait, migration 0025), sur le modèle de compositionPour — c'est la start_date du tournoi qui choisit, et une règle déjà jouée n'est jamais modifiée.

Aujourd'hui : un forfait gagné vaut 5 pts, 10 pts à partir du 2026-10-05 pour un tournoi en 3 sets gagnants (pointsForfaitPour). Abandons, perdant du forfait et Grands Chelems masculins en 5 sets inchangés.

Périmètre : tn_recompute_picks (donc tn_picks.points) et le Score de référence de l'onglet Résultats. Le Fantasy, le Bracket et les équipes figées gardent le défaut de scoreMatch (5 pts). Après un changement de règle, rejouer tn_recompute_picks sur les seuls tournois concernés.

Où corriger le barème de multiplicateurs

Les valeurs Grand Chelem sont officielles ; celles des Masters 1000 ne le sont pas encore et sont dérivées du barème Grand Chelem, ramené au nombre de tours du tournoi (premier tour ×1, finale ×2, progression régulière). Pour les corriger, une seule ligne à ajouter dans BAREMES_EXPLICITES (lib/fantasyRegles.ts, réexporté par lib/fantasy.ts) :

export const BAREMES_EXPLICITES: Record<string, readonly number[]> = {
  'GC:7': BAREME_GRAND_CHELEM,
  'M1000:7': [1, 1.15, 1.3, 1.5, 1.7, 1.85, 2],   // ← clé = famille:nombre de tours
};

Le cache tn_fantasy mémorise les multiplicateurs utilisés : changer le barème le périme de lui-même, sans invalidation manuelle.

Où corriger l'échelle Elo → probabilité

La constante de pVictoire vit dans ECHELLE_ELO (lib/elo.ts), une seule ligne dont dépend tout le moteur — simulation Monte Carlo comme propagation analytique, qui appellent pVictoire sans surcharge :

export const ECHELLE_ELO = 400;   // ← hérité des échecs, jamais calibré tennis

pVictoire, simulerMatch, simulerTournoi et simulerDepuis acceptent un paramètre echelle optionnel : il n'existe que pour les écrans de calibration, qui rejouent le calcul sous d'autres valeurs sans rien changer à la production. Omis, c'est toujours ECHELLE_ELO qui s'applique.

Après un changement, vider les caches dérivés (tn_projections, tn_fantasy) : ils ont été calculés sous l'ancienne échelle. Un import d'Elo (/import/elo) le fait déjà pour les deux.