Jidoka Lab

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é

Deux écrans du pitch : la couverture « Fini le chaos WhatsApp » et la solution en quatre briques, matching instantané, niveau certifié, cercles, sans friction
Le pitch, six écrans : le problème, la solution, la feuille de route, la différenciation, l'appel à rejoindre.

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.

Six wireframes mobiles : fil des parties proches avec carte et cartes de partie, notifications avec actions rapides, création d'une partie, détail d'une partie avec les joueurs, profil joueur avec statistiques et préférences, notation des partenaires
Six écrans clés : fil, notifications, création, détail, profil, notation. Les versions 2 et 3 sont marquées comme telles dès la maquette.

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.

Système de design de Padel Sync : palette de marque autour du vert-jaune de la balle, fonds sombres et clairs, sémantiques
Le système de design : couleurs, typographie, espacements, composants, écrans en mode sombre.

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.

← Tous les projets