App · communauté
Padel Sync
Trouver trois joueurs de son niveau, disponibles au même moment, près du même club, sans quarante messages. Pour l'instant : un pitch, un système de design, six écrans clés, et une décision.
- État
- exploration · maquettes et spécifications
- Stack
- pitch, système de design, wireframes mobiles, spécifications fonctionnelles
- Depuis
- 2026
- Preuves
- aucun code, volontairement ; pitch, design et écrans prêts
Le problème
Organiser une partie de padel, c’est un travail à plein temps. Un groupe de discussion, des dizaines de messages pour trouver trois joueurs disponibles, au même niveau, près du même club. Des niveaux auto-déclarés qu’on découvre sur le terrain. Un désistement la veille, et toute la chaîne recommence, souvent trop tard.
Ce que j’ai spécifié

Une idée simple : on décrit sa partie (club, créneau, niveau souhaité, places libres, visibilité), et l’application notifie les joueurs qui correspondent. Quatre briques : le matching automatique sur le niveau, la disponibilité et la distance ; un niveau certifié par les parties réellement jouées plutôt qu’auto-déclaré ; des cercles privés qui remplacent les groupes de discussion, ouverts progressivement à de nouveaux joueurs triés ; et aucune friction sur la réservation, laissée aux plateformes existantes.
Le parti pris qui rend le projet crédible : commencer par les cercles d’amis, pas par un marché ouvert. Le réseau existe déjà, la valeur est là dès le premier jour, sans attendre une masse critique.

Une feuille de route en trois versions : d’abord la machine à parties (profil, création, matching, notifications, cercles) ; puis la réputation (notes après match, niveau calculé, recommandations) ; enfin les tournois et un tableau de bord pour les clubs. Et un système de design complet, couleur de balle de padel, typographie condensée, composants et états, pour que la première version soit cohérente dès le premier écran.

Pourquoi pas de code
C’est volontaire. Avant de construire, je veux deux réponses : aucune application existante ne couvre le besoin tel que je l’ai spécifié (les concurrents font la réservation ou visent un marché ouvert), et l’analyse vidéo du coach produit un signal assez fiable pour devenir une brique du niveau certifié. Tant que ces deux conditions ne sont pas réunies, le projet reste une spécification, pas un chantier.
Ce que ça raconte
- Spécifier avant de coder. Le problème, la solution, la feuille de route et les écrans existent ; le code attend d’être justifié.
- Une décision produit assumée. Une idée qui reste à l’état de spécification tant qu’elle n’a pas passé la validation, c’est une décision, pas un abandon.
- Une méthode reproductible. Pitch, système de design, wireframes : la même chaîne servira au prochain projet, avec ou sans code au bout.