Permettre aux passionnés de jeux de société de trouver facilement d'autres joueurs et d'organiser des sessions afin de créer une communauté active et engagée

Gamtog est une startup nantaise née d'un constat simple : pour un passionné de jeux de société, trouver d'autres joueurs et organiser une soirée reste étonnamment compliqué. En 2021, Lonestone a accompagné le porteur de projet pour transformer cette idée en application mobile, de la définition de la proposition de valeur jusqu'au déploiement sur l'App Store et le Google Play. Mon intervention a couvert la phase de discovery et de cadrage UX : interviews utilisateurs, analyse des besoins, définition du product backlog et conception des wireframes. La phase UI a ensuite été prise en charge par Florent, avant que l'équipe développement de Lonestone ne prenne le relai pour construire et livrer l'application.

Le benchmark des applications existantes a mis en évidence un marché peu structuré sur le segment des jeux de société : les solutions disponibles étaient soit trop généralistes (applications d'événements grand public), soit trop nichées (forums communautaires peu ergonomiques). Aucune ne proposait une expérience fluide couvrant à la fois la découverte de joueurs, l'organisation de sessions et la personnalisation selon le profil de jeu. L'analyse des parcours sur certaines apps concurrentes a aussi révélé des frictions importantes à l'onboarding et dans la création d'événements, deux moments pourtant critiques pour l'adoption.

J'ai mené six interviews couvrant des profils variés : joueurs occasionnels, joueurs habitués, organisateurs de soirées réguliers et un gérant de boutique de jeux de société, avec qui j'ai passé une heure trente à explorer la mécanique de segmentation des jeux et les différentes manières d'adresser les cibles. Ces entretiens ont produit des proto-personas et des cas d'usage concrets qui ont directement alimenté la priorisation du backlog. Trois insights ont particulièrement orienté la suite du travail : l'importance de qualifier le niveau attendu des joueurs lors de la création d'une soirée, la demande forte pour des sessions privées entre amis ou en famille en plus des événements publics, et l'intérêt pour des fonctionnalités gravitant autour du jeu au sens large, recommandations, découverte de boutiques, alertes sur les nouveautés et les compétitions locales.

La priorisation du backlog s'est construite autour de deux profils cibles distincts, les joueurs débutants et les joueurs expérimentés, avec des fonctionnalités pensées pour répondre aux attentes de chacun sans sacrifier la cohérence de l'expérience globale. Les features retenues en priorité couvraient la recherche de joueurs et de groupes, la création et la participation à des sessions publiques et privées, la messagerie entre joueurs pour développer le lien avant et après les rencontres IRL, la facilitation des sessions longues comme les jeux de rôle, et les alertes personnalisées sur les nouveautés, salons et compétitions. Certaines idées séduisantes ont été délibérément écartées du MVP pour ne pas alourdir un premier périmètre déjà ambitieux.

Deux parcours ont concentré l'essentiel de l'effort de conception : l'onboarding et la création de session. L'onboarding était le moment où l'application apprenait à connaître le joueur, ses jeux de prédilection, son niveau, ses préférences, pour pouvoir lui proposer du contenu pertinent dès le départ. Le rater aurait signifié une expérience générique et peu engageante dès la première ouverture. La création de session, quant à elle, devait être réductible à quelques clics : c'est le moteur de l'application, et chaque friction dans ce parcours se traduisait directement en moins de soirées créées et en moins d'activité sur la plateforme. La question de la nature des relations entre joueurs, relation réciproque de type "ami" ou abonnement unilatéral de type "follow", a aussi fait l'objet d'une réflexion approfondie, car ce choix structural détermine à la fois les dynamiques sociales et l'ensemble des fonctionnalités qui en découlent.

La phase UI, qui a suivi mon intervention, a été menée par Florent en collaboration avec l'équipe Lonestone. Elle a couvert la direction artistique complète de l'application et de la marque Gamtog : logo, charte graphique, typographie et illustrations, avant d'être appliquée à l'ensemble des wireframes pour produire les écrans finaux.

Le développement s'est déroulé en sprints de deux semaines, avec des démos à l'issue de chaque cycle pour valider les avancées et détecter les anomalies au plus tôt. L'intégration de l'API Board Game Geek a permis de simplifier la recherche et l'association des jeux aux événements sans avoir à construire une base de données propriétaire. Lonestone a ensuite accompagné Gamtog dans la recette fonctionnelle et le déploiement sur l'App Store et le Google Play.

L'application Gamtog est aujourd'hui disponible sur l'App Store et le Google Play, ce qui représente l'aboutissement concret d'un projet parti d'une idée et d'un postulat non validé. La phase de discovery a permis de poser des bases solides pour un développement itératif, en évitant de construire des fonctionnalités sur des hypothèses non testées.

Ce projet m'a confronté à toute la complexité des applications à dimension sociale. Une question en apparence simple, comme la nature de la relation entre deux joueurs, amis réciproques ou abonnement unilatéral, embarque en réalité des implications profondes sur les dynamiques communautaires, les fonctionnalités associées et les comportements que l'on cherche à encourager. Ce n'est pas une décision de design, c'est une décision de produit qui a des conséquences sur tout le reste. Travailler sur les leviers d'engagement et de fidélisation, notamment autour de la création de groupes et de tribus par affinité de jeu ou de localisation, m'a aussi donné un regard plus affûté sur ce qui fait qu'une communauté prend vie ou reste vide. La modération, enfin, est un sujet que j'aurais aimé adresser plus tôt dans le projet : dès qu'une plateforme est ouverte au public, la question de la qualité et de la sécurité des contenus échangés entre utilisateurs ne peut pas être traitée comme une contrainte secondaire.