Développement d’une application web pour le sport | Playse

Création d’une plateforme de mise en relation entre coachs et jeunes footballeurs, avec des espaces dédiés pour les parents, les coachs et les administrateurs Playse

Réalisé avec ♥︎

Découvrez la réalisation ↓

Expertise

Développement sur-mesure

Technologies / Modules

Ruby On Rails

Make

Clever Cloud

Description

Playse est une application web qui met en relation coachs sportifs, jeunes joueurs et parents. Cofondée et portée par l’ex-international Blaise Matuidi, la plateforme poursuit une promesse simple : rendre le coaching privé plus accessible, plus fluide et plus fiable au quotidien.

Quand nous arrivons, l’équipe a déjà de l’audience et des inscriptions… mais trop peu de réservations effectives. Les familles se perdent entre les rôles (parent, joueur), les coachs jonglent avec un planning instable, et les changements ne sont pas toujours bien communiqués. Notre mission : réduire les frictions entre l’inscription et la séance réalisée, et fiabiliser la planification dans un contexte multi-profils, sans alourdir le travail des coachs.

‍

Visiter leur site

Contexte du projet

Disponible en France, aux États-Unis et aux Émirats arabes unis, le produit touche une large population et s’articule autour de trois espaces synchronisés : coach, parent, joueur — et d’un parcours complet : création des séances, recherche et réservation de terrains, inscription en ligne et paiement sécurisé.

Avant notre intervention, plusieurs irritants freinaient l’activation : les frontières entre rôles n’étaient pas assez nettes, le planning manquait de lisibilité, et les notifications (changements, reports, annulations) n’arrivaient pas toujours au bon moment ni à la bonne personne. Conséquence : une activation faible, des chevauchements de créneaux et une confiance fragile côté parents. Notre travail a consisté à poser un cadre clair, stabiliser la planification et remettre l’utilisateur au centre du parcours.

Objectifs

Unifier l’expérience multi-profils

L’objectif était de clarifier les rôles et permissions pour que chacun — coach, parent, joueur — voie la bonne information au bon moment. Nous avons réduit la charge cognitive en séparant clairement les intentions de chaque profil et en limitant les écrans au strict nécessaire.

Rendre la planification fiable

La planification devait cesser d’être source de stress. Nous avons cadré la création, la modification et l’annulation des séances avec des règles simples et des retours immédiats. Les notifications sont redevenues utiles parce qu’elles sont contextuelles et actionnables.

Réserver et payer en ligne, sans frictions

La réservation devait être rapide et prévisible. Recherche par région, formule et niveau ; affichage des places en temps réel ; paiement sécurisé et confirmations claires. L’objectif : supprimer les points d’abandon au moment critique.

Donner de la visibilité sur la progression

Parents et coachs ont besoin d’un même référentiel. Nous avons posé un espace de suivi simple, centré sur l’essentiel, pour visualiser l’évolution d’un joueur et renforcer l’engagement au fil des séances.

Garantir performance et scalabilité

Le socle technique devait rester stable sous charge et prêt pour les prochaines fonctionnalités. Nous avons travaillé la réactivité, la disponibilité et la capacité à faire évoluer le produit sans tout casser.

Garantir performance et scalabilité

Plutôt que vingt KPI tièdes, nous avons instrumenté les métriques vraiment utiles : activation par profil, taux de créneaux remplis, délai moyen de remplissage, récurrence de réservation et délivrabilité des notifications. Ces indicateurs guident les arbitrages produit.

Solutions

Ce que nous avons mis en place

Nous avons d’abord remis l’utilisateur au centre : une architecture multi-profils nette, des vues dédiées par rôle et un parcours de réservation resserré. Le planning est synchronisé en temps réel et les notifications ne partent que lorsqu’elles apportent une action claire. La recherche et réservation de terrains intègre le paiement en ligne pour éviter les ruptures de parcours.

Côté technique, l’application web s’appuie sur Ruby on Rails (stabilité, time-to-market), un hébergement Clever Cloud (disponibilité), Redis pour la mise en file et la réactivité, un back-office ActiveAdmin pour l’opérationnel, et des automatisations Make. L’usage est instrumenté avec Mixpanel pour piloter l’activation.

‍

Ce que nous n’avons pas fait (volontairement)

Nous n’avons pas empilé des fonctionnalités “sympas” mais non essentielles au lancement (messagerie avancée, statistiques complexes). Nous n’avons pas développé d’apps natives iOS/Android avant d’avoir validé l’usage : le web-first offrait le meilleur couple vitesse/apprentissage. Nous n’avons pas alourdi l’onboarding : moins d’étapes, plus de clarté, des itérations courtes.

‍

Nos difficultés (et comment on s’en est sortis)

Trois personas, une app. Nous avons cartographié les intentions de chaque rôle et posé des permissions fines pour éviter les collisions.
Changements et annulations. La synchronisation a été fiabilisée via des files d’attente (Redis) et des notifications vérifiées par des métriques d’acheminement.
Dette produit au lancement. Nous avons tenu la ligne : réservation / planning / paiement d’abord, le reste ensuite, avec un backlog priorisé et partagé.
Alignement business/design. Rituels courts, specs claires, décisions rapides côté Playse ; cela a évité les sur-promesses et le rework.

‍

Enseignements clés

Le multi-profils fonctionne si chaque écran sert une intention unique.
Une notification est utile si elle est contextualisée et actionnable.
Le paiement est une épreuve de confiance : transparence et confirmations réduisent l’abandon.
Mesurer peu mais bien accélère les bons arbitrages produit.
Une approche web-first bien exécutée suffit pour prouver l’usage et poser un socle durable.