DOCS/sport/myinfomate-sport-spec.md

# MyInfoMate Sport — Spécification V1

## Concept

Verticale "clubs sportifs" de MyInfoMate, pilote avec le **Hockey Club de Namur**.
Même infrastructure que MyInfoMate (manager-service, manager-app, PostgreSQL, Firebase) — un club = une `Instance`.

Marché cible : clubs sportifs structurés (D1/D2) qui veulent une app branded pour leurs membres.
Concurrent principal à analyser : **Spond** (gratuit, très utilisé), **iclub** (gestion administrative, marché belge).
Différenciation : expérience membre, white-label, module mobilisation (arbitrage + renfort), kiosk tablette.

---

## Rôles

### Responsable du club (= `InstanceAdmin` dans manager-app)
- Crée et gère les équipes
- Crée les membres et vérifie leur statut (cotisation en ordre)
- Assigne les membres aux équipes
- Désigne les capitaines
- Gère le contenu global de l'app (sections, programme, résultats, events)
- Envoie des notifications à tout le club ou par équipe ciblée

### Capitaine (= `ContentEditor` dans manager-app)
- Gère les membres de son équipe
- Encode les matchs et résultats de son équipe
- Poste les demandes d'arbitrage et de renfort (**lui seul peut créer ces demandes**)
- Envoie des notifications à son équipe uniquement

### Membre (= nouveau rôle, app mobile uniquement)
- Voit le contenu global + contenu de ses équipes
- Reçoit les notifications ciblées
- Peut se proposer comme arbitre ou comme renfort
- Ne peut pas créer de demandes

---

## Gestion des membres

### Flow d'inscription
1. Responsable club crée le membre dans manager-app (nom, email, cotisation OK)
2. Le membre reçoit un email d'invitation avec un lien pour créer son mot de passe
3. Il se connecte dans l'app mobile avec email/password
4. Responsable ou capitaine l'assigne à une ou plusieurs équipes
5. Si cotisation non payée → compte désactivé (`IsActive = false`), accès bloqué

### Entité `Member` (nouvelle, séparée de `User`)

`User` existant = gestionnaires de la solution (manager-app).
`Member` = membres du club (app mobile). Auth séparée, JWT séparé.

```
Member
- Id
- InstanceId          (le club)
- TeamIds             (ses équipes)
- FirstName, LastName
- Email
- PasswordHash
- IsCaptain           (bool)
- IsActive            (cotisation OK)
- DateCreation
- InvitationToken     (flow email invitation)
```

Nouvel endpoint : `POST /api/member/login` → JWT avec claims membres.

---

## Module Mobilisation

### Demandes d'arbitrage (par équipe)
- Le capitaine poste une demande pour un match (date, heure, rémunération proposée)
- Les membres volontaires (liste arbitres) reçoivent une notification
- Un membre accepte → demande confirmée, fermée pour les autres
- Seul le capitaine peut créer/clôturer une demande

### Demandes de renfort (inter-équipes)
- Le capitaine poste "besoin de X joueurs" pour un match
- Les membres d'autres équipes compatibles reçoivent une notification
- Ils se proposent → le capitaine valide
- Même logique que l'arbitrage

### Modèle technique suggéré
Un modèle générique `ClubRequest` avec un type (Arbitrage / Renfort) plutôt que deux modèles séparés.

```
ClubRequest
- Id
- InstanceId
- TeamId
- MatchId
- Type              (Arbitrage | Renfort)
- Description
- Compensation      (arbitrage : montant, renfort : nb joueurs)
- Status            (Open | Closed)
- CreatedByMemberId (capitaine uniquement)
- DateCreation
```

---

## Sections de l'app mobile

### Réutilisées depuis MyInfoMate
| Section | Usage sport |
|---------|-------------|
| `SectionAgenda` | Programme des rencontres + événements club |
| `SectionArticle` | Règles du hockey, infos pratiques, présentation |
| `SectionSlider` | Galerie photos des matchs |
| `SectionVideo` | Highlights, interviews, vidéos entraînement |
| `SectionMap` | Localisation terrains, plans déplacements extérieurs |
| `SectionWeb` | Live score fédération, site RBFH |
| `SectionPDF` | Règlement intérieur, convocations, documents |
| `SectionWeather` | Météo pour savoir si terrain praticable |

### Nouvelles sections à créer
| Section | Usage |
|---------|-------|
| `SectionTeam` | Roster équipe (photos, numéros, stats) |
| `SectionMatch` | Résultats + classement en temps réel |
| `SectionRequest` | Demandes arbitrage/renfort ouvertes (capitaine uniquement pour créer) |

---

## App mobile membres

### Navigation

**Header**
- Logo + nom du club à gauche (brandé via Flutter flavor)
- Avatar du membre en haut à droite → tap → page profil

**Bottom navigation bar (5 onglets)**
| Icône | Onglet | Contenu |
|-------|--------|---------|
| Maison | Home | Météo, news, prochains matchs, demandes ouvertes |
| Calendrier | Programme | Calendrier filtrable par équipe |
| Maillot | Mon équipe | Roster, résultats, classement |
| Mégaphone | Mobilisation | Demandes arbitrage/renfort ouvertes |
| Plus | Club | Sections configurées depuis manager-app (articles, vidéos, PDF, map...) |

---

### Page Profil (accessible via avatar)
- Photo, nom, numéro de maillot
- Ses équipes
- Stats perso (V2)
- Trophées gagnés (V2)
- Paramètres / déconnexion

---

### Home
- Météo du jour (terrain du club)
- Dernières news du club
- Prochains matchs de MES équipes
- Demandes de mobilisation ouvertes pour moi

### Programme
- Calendrier de tous les matchs du club
- Filtrable par équipe
- Tap sur un match → détail (heure, terrain, adversaire, résultat)

### Mon équipe
- Roster de l'équipe (liste des joueurs, numéros, postes)
- Résultats et classement de l'équipe

### Mobilisation
- Demandes d'arbitrage ouvertes
- Demandes de renfort ouvertes
- Je me propose → validation par le capitaine

### Club (dynamique)
- Sections configurées depuis manager-app par le responsable
- Même logique de rendu que mymuseum-visitapp
- Articles, vidéos, galerie, PDF, map, events...

---

## Pricing (cible)

- **40-90€/mois** par club
- Basé sur : nombre d'équipes, nombre de membres actifs, notifications/mois
- Pas de quota stockage/IA (inutile dans ce contexte)
- Pilote Hockey Namur : **gratuit 3-6 mois** pour valider les features

---

## Architecture technique

- **manager-service** : nouvelles entités (Team, Match, Member, ClubRequest) + nouveaux controllers. Rien d'existant modifié.
- **manager-app** : nouvelles sections dans le menu. UI globale inchangée.
- **Nouvelle app Flutter** : app mobile membres, consomme le client API généré depuis manager-app. **White-label via Flutter flavors dès le départ** — une seule codebase, un flavor par club (couleurs, logo, nom d'app, bundle ID).
- **Base PostgreSQL** : même instance, isolation par `InstanceId`. Nouvelles tables via migrations EF Core.
- **mymuseum-visitapp** : non touchée.

---

## V2 (hors scope V1)

### Messagerie d'équipe (remplacement WhatsApp)
- Texte uniquement dans un premier temps (pas de photos/vidéos)
- Historique limité à 90 jours — suppression automatique au-delà
- Stocké en PostgreSQL (pas Firebase Storage) — coût marginal nul
- Notifications push via FCM (gratuit sans limite)
- Photos/vidéos envisageables en V3 avec quota strict par club dans le plan tarifaire

### Intégration fédérale RBFH (hockey.be)
API publique disponible sur `hockey.be/wp-json/sportlink-api/cached` — pas d'auth requise.
Endpoints identifiés :
- `endpoint=program&clubid=CC6VD3E` → programme des matchs (date, heure, équipes, division)
- `endpoint=standing&clubid=CC6VD3E&subpool=A` → classement (subpool à investiguer pour les autres divisions)

Implémentation : job Hangfire quotidien (pattern identique à `AgendaSyncService`) qui synchronise programme + classements automatiquement sans encodage manuel.

À investiguer : paramètre `subpool` pour récupérer toutes les divisions (pas uniquement la D1).

### Stats et gamification
- Stats par joueur : buts, assists, cartons, matchs joués
- Stats par équipe : classement, buts pour/contre
- Trophées automatiques calculés par job Hangfire hebdomadaire :
  - "Meilleur buteur U16 de la saison"
  - "100 matchs joués au club"
  - "Arbitre de la saison" (nombre d'arbitrages acceptés)
  - "Joueur le plus fiable" (jamais forfait)
  - "Renfort d'or" (x fois venu en renfort)

### Autres
- Réservation de terrains
- État des terrains en temps réel (MQTT + capteurs)