# Application de gestion de tournois de Padel en double

# 🎯 Vision du MVP

Application Rails 8 permettant aux juges-arbitres, gestionnaires de clubs et joueurs de gérer des tournois de padel en double de manière collaborative avec un système d'ACL (Access Control List) au niveau objet.

# 📋 Table des matières

1. Gestion des utilisateurs
2. Gestion des tournois
3. Gestion des terrains
4. Gestion des clubs
5. Gestion des matchs
6. Architecture technique

# 1. Gestion des utilisateurs

# 1.1 Rôles et permissions

# Rôles principaux

• Admin : Gestion complète de la plateforme
• Juge-Arbitre (JAP) : Organisateur et responsable des tournois
• Gestionnaire de club : Gestion des infrastructures et terrains
• Joueur : Participant aux tournois

# Niveaux de Juge-Arbitre Padel (FFT)

• JAP1 : Compétent pour P25 et P100 au niveau départemental
• JAP2 : Compétent pour P25 à P1000 au niveau ligue
• JAP3 : Compétent pour tous les tournois au niveau national
• JAPI : Compétence JAP3 étendue aux compétitions internationales

# 1.2 Système de classement des joueurs

# Classement FFT national

Les joueurs sont classés selon leur rang national et leur moyenne de points sur les 12 meilleurs résultats des 12 derniers mois.

# Niveaux de jeu (FFT 2024)

• Niveau 1-3 : Débutant à intermédiaire
• Niveau 4 : Intermédiaire (P25/P100 fin de tableau, moyenne 5-25 pts)
• Niveau 5 : Intermédiaire confirmé (P100 top 4, P250 milieu tableau, moyenne 25-50 pts)
• Niveau 6 : Avancé (P250 tête de série, moyenne 50+ pts)
• Niveau 7 : Expert (P500+, top 500 hommes / top 100 femmes)

# Restrictions de participation aux tournois (FFT 2023)

P25 (tournois loisirs)
- Dames : Top 1000 interdit
- Hommes : Top 10.000 interdit
- Niveau minimum : 4/4.5/5 selon régions

P100
- Dames : Classement > 300ème
- Hommes : Classement > 2000ème
- Poids de paire minimum : 1000
- Niveau : 4 et 5 principalement

P250
- Dames : Classement > 100ème
- Hommes : Classement > 500ème
- Niveau : 6 et 7 principalement
- 12 paires minimum

P500 et supérieurs
- Pas de limitation mais gestion FFT stricte
- Date limite inscription : J-14 à 23h59
- Validation des tableaux par la FFT

# 1.3 Système d'ACL (Access Control List)

Le système d'ACL permet une granularité fine au niveau objet (tournoi).

# Permissions disponibles

• Lecture : Consultation des informations du tournoi
• Écriture : Modification des données du tournoi
• Administration : Gestion complète incluant permissions

# Matrice de permissions par rôle

# Cas d'usage

1. JAP crée un tournoi : Il obtient tous les droits
2. JAP ajoute un co-organisateur : Autre JAP en lecture/écriture
3. JAP ajoute gestionnaire club : Lecture seule ou lecture/écriture selon besoin
4. Joueurs inscrits : Lecture automatique + saisie scores avec validation adversaire

# 1.4 Données utilisateur

# Modèle User
- email (unique, required)
- nom, prénom
- role (enum: admin, juge_arbitre, gestionnaire_club, joueur)
- niveau_jap (enum: JAP1, JAP2, JAP3, JAPI) # Si juge_arbitre
- classement_fft (integer) # Rang national pour joueurs
- niveau_jeu (integer, 1-7) # Niveau FFT pour joueurs
- moyenne_points (decimal) # Moyenne points/tournoi sur 12 mois
- licence_fft (string) # Numéro licence obligatoire pour compétition
- date_naissance
- encrypted_password
- timestamps

# 2. Gestion des tournois

# 2.1 Types de tournois (FFT)

# Catégories selon le nombre de points

• P25 : 25 points (joueurs intermédiaires, loisir)
• P100 : 100 points (intermédiaire confirmé)
• P250 : 250 points (avancés)
• P500 : 500 points (avancés+)
• P1000 : 1000 points (experts)
• P1500 : 1500 points (experts)
• P2000 : 2000 points (top niveau)

# Particularités par catégorie

P25 - Tournoi loisir
- Phase de poules possible : 5-6 paires en super tie-breaks de 10 points
- Puis 3 tableaux selon classement poule
- Format court : 3 matchs de 4 jeux chacun
- Gestion locale par comité de tournoi
- Inscription jusqu'à J-1

P100
- 8 paires minimum
- Format standard avec tableaux éliminatoires
- Gestion locale
- Historiquement le 1er tournoi homologué

P250
- 12 paires minimum
- Catégorie "reine" des clubs
- Têtes de série importantes
- Gestion locale

P500 et supérieurs
- Gestion FFT nationale
- Tableaux 100% sur classement officiel
- Inscription J-14 à 23h59
- Validation FFT des tableaux en amont
- Qualifications possibles

# 2.2 Structure d'un tournoi

# Têtes de série (Seeds)

Les têtes de série sont déterminées selon le classement FFT des paires.

Règles importantes :
- Les têtes de série peuvent être exemptées de premier tour (BYE)
- Elles doivent jouer minimum 3 matchs même si exemptées au 1er tour
- Placement dans le tableau pour éviter de se rencontrer trop tôt
- Le nombre de têtes de série dépend du nombre de participants

# Système de BYE

• Accordé aux meilleures têtes de série quand nombre de paires non puissance de 2
• Permet d'équilibrer le tableau
• Exemple : 12 paires = 4 BYE pour 1er tour

# Phases du tournoi

1. Qualifications (si nécessaire pour P500+)
2. Tableau principal
   • Premier tour
   • Huitièmes de finale
   • Quarts de finale
   • Demi-finales
   • Finale
3. Tableau de consolante (optionnel pour P25)
   • Perdants du 1er tour s'affrontent entre eux
   • Même nombre de matchs pour tous

# 2.3 Formats de matchs

Les formats varient selon la catégorie et la durée souhaitée.

# Format A (long - finales)

• A1 : 3 sets à 6 jeux
• A2 : 3 sets à 6 jeux, point décisif

# Format B (standard)

• B1 : 2 sets à 6 jeux ; 3ème set = super tie-break à 10 points
• B2 : 2 sets à 6 jeux, point décisif ; 3ème set = super tie-break à 10 points

# Format C (court)

• C1 : 2 sets à 4 jeux, jeu décisif à 4/4 ; 3ème set = super tie-break à 10 points
• C2 : 2 sets à 4 jeux, point décisif, jeu décisif à 4/4 ; 3ème set = super tie-break

# Format D (très court)

• D1 : 1 set à 9 jeux, jeu décisif à 7 points à 8/8
• D2 : 1 set à 9 jeux, point décisif, jeu décisif à 7 points à 8/8

# Format E (express - P25 uniquement)

• 1 set à 10 points (super tie-break)

# Restrictions par jour (FFT)

Pour protéger les joueurs :
- 2 matchs/jour : Tous formats possibles
- 3 matchs/jour : Maximum 2 matchs en format A1/A2
- 5 matchs/jour : Aucun format A1/A2, max 3 matchs C1/C2/D1/D2
- 7+ matchs/jour : Uniquement P25 sur soirée/demi-journée, format E principalement

# 2.4 Horaires et convocations

# Gestion des créneaux

• Heure de convocation pour chaque match
• Attribution d'un terrain disponible
• Temps de repos réglementaire entre matchs
• Possibilité de dérogation avec accord écrit des 4 joueurs

# Planning automatisé

• Calcul durée estimée selon format
• Éviter conflits de terrains
• Respecter repos minimum réglementaire
• Notification aux joueurs

# 2.5 Attribution des points

Le nombre de points attribués dépend de la place finale et du nombre de participants.

# Points vainqueurs (fixes)

• P25 : 25 points
• P100 : 100 points
• P250 : 250 points
• P500 : 500 points
• etc.

# Points dégressifs

La répartition des points pour les autres places suit un barème FFT qui varie selon :
- Le nombre total de paires inscrites
- La place obtenue dans le tournoi
- Le type de tableau (principal, consolante)

# 2.6 Données tournoi

# Modèle Tournament
- nom (string, required)
- type_tournoi (enum: P25, P100, P250, P500, P1000, P1500, P2000)
- club_id (foreign key)
- date_debut, date_fin
- date_limite_inscription
- statut (enum: brouillon, ouvert_inscriptions, cloture_inscriptions, en_cours, termine, annule)
- nombre_paires_min, nombre_paires_max
- format_match_principal (enum: A1, A2, B1, B2, C1, C2, D1, D2, E)
- format_finale (enum)
- avec_qualifications (boolean)
- avec_consolante (boolean)
- nombre_tetes_serie (integer)
- homologue_fft (boolean)
- numero_homologation (string)
- juge_arbitre_principal_id (foreign key -> User)
- description (text)
- reglement (text)
- prize_money (decimal) # P500+ uniquement
- timestamps

# Modèle TournamentPermission (ACL)
- tournament_id
- user_id
- permission_type (enum: read, write, admin)
- granted_by_id (qui a donné la permission)
- timestamps

# 3. Gestion des terrains

# 3.1 Normes FIP/FFT

# Dimensions réglementaires

• Surface de jeu : 20m x 10m (200 m²)
• Surface totale recommandée : minimum 240 m² (avec zones de sécurité)
• Filet :
  • Longueur : 10m
  • Hauteur centre : 88 cm
  • Hauteur extrémités : 92 cm

# Murs et parois

• Murs arrière : 10m large x 4m haut (3m verre + 1m grillage)
• Murs latéraux :
  • Configuration "escalier" européenne
  • 2 premiers mètres : 4m haut (3m verre + 1m grillage)
  • Reste : 3m haut
• Portes d'accès : Au centre des parois latérales

# Hauteur libre (CRITIQUE pour homologation)

Minimum réglementaire FIP/FFT :
- 6 mètres minimum absolu sur toute la surface
- SANS AUCUN ÉLÉMENT D'OBSTRUCTION dans cette zone
- Pas de lampadaire, poutre, tuyau qui dépasse

Recommandations :
- 8 mètres fortement conseillé pour nouvelles installations
- 10 mètres optimal pour clubs haut niveau
- Tolérance FFT tacite à 7m mais risque pour l'expérience joueur

⚠️ Note importante : De nombreux clubs avec moins de 8m perdent des clients au profit de concurrents avec plafonds plus hauts.

# 3.2 Types de terrains

# Par localisation

• Intérieur (Indoor) : Sous structure couverte
• Extérieur (Outdoor) : À l'air libre

# Caractéristiques pour homologation

• Hauteur sous plafond (si intérieur) : ≥ 6m réglementaire, 8m recommandé
• Éclairage : Conforme pour jeu nocturne (lux minimum)
• Surface : Gazon synthétique homologué, qualité suffisante
• Verre : 10-12mm épaisseur minimum
• Possibilité de sorties : Zone libre 2m x 1.4m x 3m haut
• Cadre acier : Épaisseur profil suffisante

# 3.3 Statut d'homologation

Un terrain peut être homologué pour accueillir des compétitions officielles FFT.

# Critères d'homologation FFT

• Dimensions conformes aux normes
• Hauteur réglementaire respectée
• Matériaux conformes (verre, gazon)
• Éclairage suffisant
• Zones de sécurité présentes
• Contrôle par expert agréé FFT

# Types d'homologation

• Homologué compétition : Peut accueillir tous types de tournois
• Usage loisir : Non homologué mais peut accueillir jeu libre
• En cours d'homologation : Demande déposée, en attente validation

# 3.4 Données terrain

# Modèle Court
- club_id (foreign key)
- nom (string, required) # Ex: "Court Central", "Court 1"
- numero (integer)
- type_localisation (enum: interieur, exterieur)
- hauteur_sous_plafond (decimal) # En mètres, pour intérieur uniquement
- possibilite_sorties (boolean)
- homologue (boolean)
- niveau_homologation (enum: P25, P100, P250, P500, P1000+) # Si homologué
- date_homologation
- certificat_homologation (string) # Référence document FFT
- surface_type (string) # Ex: "Gazon synthétique Mondo"
- eclairage_conforme (boolean)
- statut (enum: disponible, maintenance, hors_service)
- notes (text)
- timestamps

# Modèle CourtAvailability (pour planning tournoi)
- court_id
- tournament_id
- date
- heure_debut, heure_fin
- disponible (boolean)

# 4. Gestion des clubs

# 4.1 Informations club

# Données principales

• Nom et raison sociale
• Adresse complète
• Coordonnées GPS (pour applications mobiles futures)
• Téléphone, email, site web
• Affiliation FFT (numéro)

# 4.2 Données club

# Modèle Club
- nom (string, required)
- adresse (string)
- code_postal (string)
- ville (string)
- pays (string, default: 'France')
- latitude, longitude (decimal)
- telephone (string)
- email (string)
- site_web (string)
- numero_affiliation_fft (string)
- date_affiliation_fft
- nombre_terrains_total (integer)
- nombre_terrains_interieurs (integer)
- nombre_terrains_exterieurs (integer)
- gestionnaire_principal_id (foreign key -> User)
- description (text)
- photo_url (string)
- timestamps

# Association
Club has_many :courts
Club has_many :tournaments
Club has_many :club_managers (User avec role gestionnaire_club)

# 5. Gestion des matchs

# 5.1 Structure d'un match

# Composition

• 2 équipes (paires) de 2 joueurs chacune
• Terrain assigné
• Horaire de convocation
• Format de jeu
• Tour du tournoi (1er tour, 1/8, 1/4, 1/2, finale)

# 5.2 Saisie et validation des scores

# Workflow de validation

1. Joueurs saisissent le score : Une équipe propose le score
2. Contre-validation adversaire : L'équipe adverse doit confirmer
3. Validation JAP : Le juge-arbitre valide définitivement
4. Calcul automatique : Points attribués, classement mis à jour

# Cas de désaccord

• Si adversaires ne valident pas : Alerte au JAP
• JAP arbitre et valide le score correct
• Historique des modifications conservé

# 5.3 Données match

# Modèle Match
- tournament_id (foreign key)
- court_id (foreign key)
- round (enum: qualifications, premier_tour, huitiemes, quarts, demis, finale, consolante)
- match_number (integer) # Numéro dans le tour
- date_match
- heure_convocation
- heure_debut_reelle
- heure_fin_reelle
- format_match (enum: A1, A2, B1, B2, C1, C2, D1, D2, E)
- statut (enum: planifie, en_cours, termine, forfait, reporte)
- timestamps

# Modèle Team (paire)
- tournament_id
- joueur1_id (foreign key -> User)
- joueur2_id (foreign key -> User)
- seed_number (integer) # Numéro tête de série si applicable
- poids_paire (integer) # Somme classements pour vérif contraintes
- points_tournoi (integer)
- statut (enum: inscrit, valide, elimine, vainqueur)

# Modèle MatchTeam (participation équipe au match)
- match_id
- team_id
- position (enum: team1, team2)
- score_set1, score_set2, score_set3 (integer)
- vainqueur (boolean)

# Modèle ScoreProposal (pour validation)
- match_id
- proposed_by_team_id
- score_team1_set1, score_team1_set2, score_team1_set3
- score_team2_set1, score_team2_set2, score_team2_set3
- validated_by_opponent (boolean, default: false)
- validated_by_jap (boolean, default: false)
- validated_at
- notes (text) # En cas de contestation
- timestamps

# 6. Architecture technique

# 6.1 Stack technique

# Backend

• Ruby 3.3+
• Rails 8.0 (dernier stable)
• PostgreSQL 16+ (base de données)
• Devise (authentification)
• Pundit (autorisation + ACL personnalisé)
• Active Storage (upload documents/photos)

# Frontend

• Hotwire (Turbo + Stimulus) - Rails 8 natif
• Tailwind CSS (styling)
• ViewComponent (composants réutilisables)

# Tests

• RSpec (tests)
• FactoryBot (fixtures)
• Capybara (tests système)

# 6.2 Modèles principaux

User (Devise)
  ├── has_many :created_tournaments (as juge_arbitre)
  ├── has_many :tournament_permissions
  ├── has_many :accessible_tournaments, through: :tournament_permissions
  ├── has_many :teams (as joueur1 or joueur2)
  └── belongs_to :managed_club (optional, if gestionnaire_club)

Club
  ├── has_many :courts
  ├── has_many :tournaments
  └── belongs_to :gestionnaire_principal (User)

Court
  ├── belongs_to :club
  └── has_many :matches

Tournament
  ├── belongs_to :club
  ├── belongs_to :juge_arbitre_principal (User)
  ├── has_many :tournament_permissions
  ├── has_many :authorized_users, through: :tournament_permissions
  ├── has_many :teams
  └── has_many :matches

Team
  ├── belongs_to :tournament
  ├── belongs_to :joueur1 (User)
  ├── belongs_to :joueur2 (User)
  └── has_many :match_teams

Match
  ├── belongs_to :tournament
  ├── belongs_to :court
  ├── has_many :match_teams
  ├── has_many :teams, through: :match_teams
  └── has_many :score_proposals

TournamentPermission (ACL)
  ├── belongs_to :tournament
  ├── belongs_to :user
  └── belongs_to :granted_by (User)

MatchTeam
  ├── belongs_to :match
  └── belongs_to :team

ScoreProposal
  ├── belongs_to :match
  └── belongs_to :proposed_by_team (Team)

# 6.3 Fonctionnalités MVP (Phase 1)

# Authentification et autorisations

• ☐ Sign up / Sign in avec Devise
• ☐ Profil utilisateur avec rôle et niveau
• ☐ Système ACL au niveau tournoi avec Pundit
• ☐ Gestion des permissions lecture/écriture/admin

# Gestion des clubs

• ☐ CRUD clubs
• ☐ Association gestionnaire ↔ club
• ☐ Liste et carte des clubs

# Gestion des terrains

• ☐ CRUD terrains rattachés à un club
• ☐ Caractéristiques : intérieur/extérieur, homologation, hauteur
• ☐ Statut disponibilité

# Gestion des tournois

• ☐ Création tournoi par JAP avec type (P25-P2000)
• ☐ Configuration : dates, format match, têtes de série
• ☐ Gestion permissions : ajout co-JAP, gestionnaire club
• ☐ Contraintes de participation selon classement
• ☐ Calcul automatique nombre BYE
• ☐ Inscription des équipes (paires)
• ☐ Validation contraintes poids paire

# Gestion des matchs

• ☐ Génération automatique du tableau
• ☐ Placement des têtes de série
• ☐ Attribution BYE
• ☐ Planning automatique : terrain + horaire
• ☐ Respect contraintes : repos entre matchs, disponibilité terrains

# Saisie et validation scores

• ☐ Interface saisie score pour joueurs
• ☐ Système de contre-validation adversaire
• ☐ Validation finale par JAP
• ☐ Historique modifications
• ☐ Calcul automatique vainqueur
• ☐ Progression dans le tableau

# Tableau et classement

• ☐ Affichage tableau temps réel
• ☐ Classement provisoire du tournoi
• ☐ Attribution automatique des points selon barème FFT
• ☐ Suivi historique joueur

# Dashboard et notifications

• ☐ Dashboard JAP : mes tournois, prochains matchs
• ☐ Dashboard joueur : mes inscriptions, prochains matchs
• ☐ Notifications par email : convocation, changement horaire

# 6.4 Fonctionnalités futures (Phase 2+)

# Avancées

• ☐ Application mobile (React Native ou Flutter)
• ☐ Intégration API FFT (classements officiels)
• ☐ Gestion paiements inscriptions (Stripe)
• ☐ Live scoring temps réel
• ☐ Statistiques avancées joueurs
• ☐ Génération documents officiels (feuilles de match)
• ☐ Export PDF récapitulatif tournoi
• ☐ Gestion multi-clubs et circuits
• ☐ Système de communication intégré (chat)
• ☐ Mode hors-ligne pour JAP (PWA)

# 📚 Références

# Documentation FFT

• Guide de la compétition Padel (Chapitre I - Règles générales)
• Cahier des charges des tournois
• Barèmes de points P25, P100, P250, P500+
• Niveaux de padel 2024

# Normes techniques

• Fédération Internationale de Padel (FIP) - Spécifications terrains
• FFT - Normes d'homologation des terrains
• Guide construction terrain padel

# Contraintes réglementaires

• Licence FFT obligatoire pour participer aux tournois homologués
• JAP obligatoire pour homologation tournoi
• Saisie résultats : 24h maximum après fin tournoi
• Limitation simultanéité : Maximum 3 P1000 simultanés en France (si éloignés)
• Délais inscription :
  • P25-P250 : Jusqu'à J-1 (gestion locale)
  • P500+ : J-14 à 23h59 (validation FFT)

# 🎯 Métriques de succès MVP

# Utilisateurs

• 10+ clubs enregistrés
• 50+ joueurs inscrits
• 5+ juges-arbitres actifs

# Tournois

• 5+ tournois créés
• 2+ tournois complétés de bout en bout
• 100+ matchs saisis et validés

# Qualité

• Temps de création tournoi < 15 min
• 95%+ scores validés sans litige
• 0 conflit de planning terrain/joueur

# 🚀 Plan de développement

# Sprint 1 (2 semaines) - Fondations

• Setup projet Rails 8 + PostgreSQL
• Modèles User, Club, Court
• Authentification Devise
• CRUD clubs et terrains

# Sprint 2 (2 semaines) - Tournois base

• Modèle Tournament
• Système ACL avec Pundit
• Création tournoi par JAP
• Gestion permissions

# Sprint 3 (2 semaines) - Équipes et inscriptions

• Modèle Team
• Inscription paires
• Validation contraintes (classement, poids paire)
• Interface gestion équipes

# Sprint 4 (2 semaines) - Matchs et planning

• Modèle Match
• Génération tableau automatique
• Placement têtes de série + BYE
• Planning terrains et horaires

# Sprint 5 (2 semaines) - Scoring

• Modèle ScoreProposal
• Interface saisie score joueurs
• Système contre-validation
• Validation JAP
• Calcul vainqueur et progression

# Sprint 6 (2 semaines) - Dashboard et finitions

• Dashboard JAP et joueurs
• Notifications email
• Affichage tableau temps réel
• Tests end-to-end
• Documentation utilisateur

# Sprint 7 (1 semaine) - Tests et déploiement

• Tests de charge
• Corrections bugs
• Setup production (Heroku/Render/Fly.io)
• Formation utilisateurs pilotes

# 🔐 Sécurité et conformité

# RGPD

• Consentement explicite collecte données
• Droit accès, rectification, suppression
• Encryption données sensibles (BCrypt pour passwords)
• Logs d'accès et modifications

# Sécurité applicative

• Protection CSRF (Rails natif)
• Strong parameters
• SQL injection prevention (ActiveRecord)
• XSS protection (ERB escaping)
• Rate limiting (Rack::Attack)
• 2FA pour comptes JAP (optionnel phase 2)

# 📝 Notes complémentaires

# Particularités padel à ne pas oublier

# Le "poids de paire"

Contrainte spécifique au padel : la somme des classements des 2 joueurs ne doit pas être inférieure à un seuil.
Exemple P100 : poids ≥ 1000 (joueur 150e + joueur 250e = 400, éligible si seuil 400)

# Tous les joueurs jouent le même nombre de matchs

Important pour l'équité : tableaux consolante pour perdants du 1er tour.

# Les têtes de série doivent jouer 3 matchs minimum

Même si exemptées de 1er tour, elles doivent avoir disputé au minimum 3 matchs dans le tournoi.

# Hauteur sous plafond = critère #1 pour clubs indoor

La hauteur minimale de 6m est réglementaire, mais 8m est le vrai standard attendu.
Certains clubs avec 7m perdent des clients. Investisseurs refusent < 10m.

# Format court = plus de matchs par jour

Le format E (super tie-break) permet jusqu'à 7+ matchs/jour en P25 soirée.

# 🤝 Contribuer

Ce document est évolutif. Pour toute suggestion :
- Ouvrir une issue sur GitHub
- Proposer une Pull Request avec modifications
- Contacter l'équipe produit

# 📅 Historique des versions

MiPadel - Gérez vos tournois de padel comme un pro 🎾

# Annexe : Exemples de scénarios utilisateur

# Scénario 1 : JAP crée un tournoi P250

1. Connexion : Jean (JAP2) se connecte à MiPadel
2. Création : Crée un nouveau tournoi P250 "Open d'été" au club Padel Paradise
3. Configuration :
   • Dates : 15-16 juillet 2025
   • Format : B1 (2 sets de 6 jeux + super TB)
   • 12 paires minimum, 16 maximum
   • 4 têtes de série
4. Permissions :
   • Ajoute Marie (autre JAP2) en lecture/écriture
   • Ajoute Paul (gestionnaire du club) en lecture seule
5. Publication : Ouvre les inscriptions
6. Inscriptions : 14 paires s'inscrivent
   • Système vérifie automatiquement : classement > 500e hommes
   • Calcule poids de paire correct
7. Clôture inscriptions : J-3, Jean clôture
8. Génération tableau :
   • 4 têtes de série placées
   • 2 BYE calculés automatiquement (14 paires = besoin 16)
   • Tableau généré avec placement optimal
9. Planning :
   • 4 terrains disponibles
   • Système génère horaires automatiquement
   • Respect temps de repos
10. Notifications : Joueurs reçoivent convocations par email

# Scénario 2 : Joueurs saisissent un score

1. Match terminé : Thomas/Lucas vs Pierre/Marc (6-4, 3-6, 10-7)
2. Saisie : Thomas (Team 1) saisit le score sur son mobile
3. Notification : Pierre (Team 2) reçoit notification pour valider
4. Validation : Pierre confirme le score
5. Alerte JAP : Jean reçoit notification pour validation finale
6. Validation JAP : Jean valide définitivement
7. Mise à jour :
   • Team 1 avance en quart de finale
   • Points provisoires calculés
   • Prochain match programmé automatiquement

# Scénario 3 : Désaccord sur score

1. Match disputé : Score litigieux
2. Saisie Team 1 : Propose 6-4, 7-5
3. Refus Team 2 : Conteste, prétend 6-4, 6-7, 10-8
4. Alerte JAP : Jean reçoit alerte immédiate
5. Investigation : Jean consulte les deux équipes
6. Décision : Jean valide le score correct : 6-4, 6-7, 10-8
7. Historique : Toutes les propositions conservées pour traçabilité

Fin du document MVP Roadmap - MiPadel v1.0.0