En bref
Padora est une application mobile iOS (React Native / Expo) qui aide les joueurs de padel à trouver des partenaires, compléter des matchs à 4 et organiser des parties réelles — en tenant compte du niveau, de la zone géographique, de la fiabilité et des disponibilités de chacun.
Cible initiale : joueurs de padel en Belgique, avec une logique pensée pour scaler vers d’autres villes.
Statut : MVP avancé, en cours de préparation pour publication sur l’App Store.
L’idée
Le padel se joue presque toujours en double (4 joueurs). En pratique, beaucoup de parties échouent avant même d’avoir lieu : il manque un ou deux joueurs, le niveau ne colle pas, quelqu’un annule tardivement ou ne vient pas, ou le terrain n’est pas réservé à temps.
L’idée de Padora est de proposer une couche sociale et opérationnelle dédiée au padel : pas seulement « trouver un court » (comme une app de réservation), mais passer de l’envie de jouer à un match confirmé et joué, avec des règles claires, du matching intelligent et une communauté locale de confiance.
L’application distingue notamment :
- les matchs garantis (terrain déjà réservé) ;
- les matchs à confirmer (terrain à réserver par un responsable, avec délai).
Cette distinction structure toute l’expérience : priorité d’affichage, notifications, responsabilités et annulations.
Le problème que ça résout
Pour les joueurs
| Problème | Impact |
|---|---|
| Difficulté à compléter un match à 4 | Parties annulées, frustration, temps perdu sur WhatsApp / groupes |
| Niveaux mal assortis | Matchs peu équilibrés, mauvaise expérience |
| Annulations tardives et absences (no-show) | Courts réservés pour rien, méfiance entre joueurs |
| Coordination éclatée (messages, calendriers, lieux) | Friction, oublis, pas de source de vérité |
| Peu de visibilité sur qui est vraiment disponible | Propositions inadaptées ou trop tardives |
Pour les organisateurs
| Problème | Impact |
|---|---|
| Terrain réservé sans assez de joueurs | Coût et créneau gaspillés |
| Gestion manuelle des invitations et confirmations | Charge cognitive élevée |
| Pas de signal sur la fiabilité des joueurs | Risque accru d’absence le jour J |
Ce que Padora apporte comme réponse
- Centraliser disponibilités, matchs, invitations et messagerie dans une seule app.
- Matcher des joueurs compatibles (créneau, distance, niveau, côté, fiabilité).
- Verrouiller un match avec des statuts explicites, des confirmations avant le match et une validation après coup (« match joué ? »).
- Responsabiliser via un score de fiabilité et des pénalités en cas de no-show.
- Évaluer le niveau avec un rating dynamique (type Playtomic) en complément du niveau déclaré.
Objectif produit (North Star) : maximiser le nombre de matchs confirmés, puis matchs réellement joués par semaine — pas seulement les inscriptions ou les conversations.
Fonctionnalités de l’application
Authentification et profil
- Connexion via Google, Apple ou email / mot de passe (flux type Playtomic : détection automatique inscription vs connexion selon l’email).
- Validation d’email obligatoire pour les comptes email ; réinitialisation de mot de passe.
- Profil joueur : photo, prénom, nom, téléphone (format international avec sélecteur de pays), niveau manuel (P25, P50, P100…), côté préféré (gauche / droite / indifférent).
- Onboarding guidé + questionnaire de niveau pour initialiser le rating dynamique et le niveau manuel.
- Position de domicile (GPS ou adresse avec suggestions) et zone de visibilité (rayon en km) pour contrôler où le joueur apparaît aux autres.
Accueil et parcours principaux
- Écran d’accueil avec les prochains matchs, invitations en attente, demandes de participation, actions requises (confirmer, réserver un terrain, voter « match joué », etc.).
- « Je veux jouer » : création de match en plusieurs étapes (date/heure/durée, terrain réservé ou à réserver, club, groupe partiel, matching de joueurs).
- « Trouver un match » : recherche de matchs rejoignables avec filtres (dont rayon de recherche en km).
- « Je me rends dispo » : déclaration de créneaux de disponibilité sur un calendrier ; le joueur peut être proposé aux organisateurs de matchs compatibles.
Matchmaking et lobby de match
- Suggestions de joueurs dans le lobby d’un match (« Joueurs disponibles »), basées sur disponibilités, distance, niveau et rating.
- Matchmaking hybride : priorité au rating dynamique (0–10), repli sur le niveau manuel si le rating n’est pas encore calibré.
- Filtre par distance (formule Haversine côté base de données) pour la recherche active et la visibilité passive.
- Invitations et demandes de participation ; acceptation / refus par l’organisateur.
- Lobby de match : statut du match, participants, emplacements (gauche/droite), terrain, actions (confirmer présence, annuler, quitter, retirer un participant).
- Gestion des terrains : match avec terrain déjà réservé vs match en attente de réservation (timer, responsable « booker »).
- Annulation automatique si moins de 4 participants confirmés à l’heure du match (cron + Edge Function).
Fiabilité et fair-play
- Score de fiabilité (0–100) affiché sur le profil avec indicateur visuel (couleur, libellé).
- Historique des gains et pénalités (confirmations, annulations tardives, no-show).
- Système de vote post-match : « Match joué ? » avec motifs (dont no-show et sélection du joueur absent).
- Résolution des conflits de votes lorsque les avis sont partagés (attente de tous les votes avant décision finale).
- Pénalité automatique (-20 points de fiabilité) lorsqu’au moins deux joueurs identifient le même absent.
- Notifications dédiées (style d’alerte) pour les pénalités de fiabilité.
Rating dynamique (niveau calculé)
- Rating de 0 à 10 (inspiré de Playtomic), complémentaire au niveau manuel modifiable.
- Questionnaire d’onboarding pour une estimation initiale.
- Période de calibration (10 premiers matchs) avec indicateur visuel sur le profil.
- Mise à jour automatique après validation des résultats de match (algorithme type ELO, prise en compte des coéquipiers, adversaires et marge de score).
- Graphique d’évolution du rating sur le profil + écran historique détaillé des variations.
Messagerie et social
- Chat par match (fil lié à un match, participants uniquement).
- Messages directs entre amis avec conversations 1-to-1.
- Affichage en temps réel des messages (Supabase Realtime + mises à jour optimistes côté client).
- Notifications in-app et push pour invitations, confirmations, messages de match, messages d’amis, rappels, etc.
Profil, statistiques et découverte
- Statistiques : matchs joués, gagnés, perdus, etc.
- Modal profil joueur consultable depuis les listes de joueurs / matchs.
- Historique de fiabilité et historique de rating.
- Aide contextuelle (ex. explication du calcul du rating, de la fiabilité).
Notifications et technique mobile
- Notifications push (Expo Notifications) + stockage des tokens.
- Deep links pour validation email et réinitialisation mot de passe (
padora://). - Permissions localisation, caméra et galerie pour profil et géolocalisation.
- Interface dark, design system Tamagui (tokens, composants réutilisables, typographie harmonisée).
Stack technique
| Couche | Technologies |
|---|---|
| Mobile | React Native, Expo SDK 54, TypeScript, Expo Router |
| UI | Tamagui, React Native SVG, expo-location, expo-image-picker |
| État / données client | TanStack React Query, contextes React (auth) |
| Backend | Supabase (PostgreSQL, Auth, Storage, Realtime) |
| Sécurité données | Row Level Security (RLS) sur les tables sensibles |
| Logique métier serveur | Fonctions SQL (RPC), triggers PostgreSQL, Edge Functions (Deno) |
| Tâches planifiées | Cron (Edge Function pour participants insuffisants, rappels) |
| Build / déploiement | EAS Build, préparation App Store Connect |
Architecture logicielle (côté app)
- Routes par dossiers :
app/(Expo Router). - Domaines métier dans
src/features/:auth,matches,profile,rating,direct-messages,location,intentions, etc. — chaque feature avecapi.ts,hooks.ts,types.ts. - Composants UI partagés dans
src/components/. - Scripts SQL et migrations documentés dans
supabase/.
Points techniques mis en avant (pour un profil dev)
- Modélisation d’un cycle de vie de match complet (BUILDING → WAITING_COURT → CONFIRMED → PLAYED / CANCELLED).
- Matching géospatial (Haversine) intégré aux RPC Supabase.
- Système de votes et consensus avec gestion des conflits et effets sur fiabilité / statut du match.
- Double système de niveau (manuel + ELO) avec matchmaking hybride.
- Realtime et UX réactive (optimistic updates sur la messagerie).
- Auth multi-provider + email custom avec vérification et deep linking.
- Documentation technique extensive (
docs/) pour chaque sous-système majeur.
Périmètre et vision
Inclus dans le MVP / version actuelle : tout le parcours de la création ou recherche de match jusqu’à la validation « match joué », avec messagerie, amis, fiabilité, rating et géolocalisation.
Hors scope (vision future) : réservation de terrain intégrée type Playtomic, paiement in-app, feed social avancé, multi-villes à grande échelle, monétisation.
Mots-clés pour recruteurs
React Native · Expo · TypeScript · Supabase · PostgreSQL · Mobile · Product MVP · Realtime · Push notifications · Géolocalisation · Algorithmes de matching · UX mobile · App Store

