Vue d’ensemble
Stage associatif volontaire au sein de la Fédération Française de Volley-Ball à Orléans : concevoir et livrer VolleyX, une application mobile de notation et de suivi de matchs de volley. L’objectif était de transformer les besoins d’arbitres en fonctionnalités utilisables sur le terrain, puis d’accompagner l’application jusqu’à sa publication sur l’App Store.
Travailler avec des interlocuteurs non techniques
Ce que ce stage m’a appris en premier, c’est écouter avant de coder.
Les arbitres décrivaient leurs besoins en langage terrain, sans forcément les traduire en fonctionnalités techniques. Mon travail consistait d’abord à reformuler, poser les bonnes questions, et extraire les contraintes réelles derrière chaque demande. Cette discipline de traduction du besoin métier vers les spécifications a structuré les choix de conception.
Les principales fonctionnalités livrées couvraient la notation de match, la gestion des accès par rôles et les notifications temps réel. Les parcours UX/UI ont ensuite été ajustés à partir de plus de 8 retours métier, avec des itérations centrées sur les usages des arbitres.
Prendre des décisions en autonomie
Dans un contexte associatif, il n’y a pas de hiérarchie technique pour valider chaque choix. J’ai dû assumer seul des décisions qui allaient rester : modélisation des rôles, gestion des permissions, choix d’hébergement. Ça oblige à raisonner les compromis plutôt que de suivre des recettes.
La contrainte principale n’était pas la complexité technique — c’était le délai. Ce cadre a tout recentré sur l’essentiel : qu’est-ce qui doit marcher à la livraison, et qu’est-ce qui peut attendre ?
Ce que cette expérience a changé
Avant ce stage, je pouvais m’attarder sur une feature intéressante techniquement. Après : je pense d’abord en termes d’impact utilisateur. Un arbitre en plein match n’a pas de tolérance pour la latence ou l’ambiguïté — cette contrainte m’a appris à évaluer chaque décision à l’aune de son utilité réelle.
J’ai aussi compris que livrer une application, c’est plus que coder : gérer les retours, documenter les choix, anticiper les contraintes légales (RGPD, App Store), et maintenir la confiance des interlocuteurs tout au long du projet.
Résultats
L’application a été publiée sur l’App Store et a atteint une note de 4.8, avec environ 25 téléchargements dès la première semaine. Au-delà du résultat chiffré, cette expérience m’a surtout appris à tenir un cycle produit court : comprendre un besoin, livrer une version utilisable, recueillir les retours, puis corriger sans perdre de vue le contexte réel d’utilisation.
Les détails techniques — architecture, schéma relationnel, stack, défis d’implémentation — sont documentés dans la page projet :