VersaVibes

Le besoin de départ est simple: éviter de jongler entre plusieurs outils pour surveiller l'état d'un serveur, partager l'accès avec une équipe, répondre au support et connecter ses addons. VersaVibes regroupe ces usages dans une même interface orientée exploitation.

Le périmètre couvre le suivi d'état, l'historique de connexion, les statistiques de joueurs, les tickets de support et un bridge API pensé pour des environnements comme FiveM et Garry's Mod, puis étendu avec un plugin Minecraft dans la seconde version.

Une partie importante du produit consiste à séparer lecture, administration et support. Les dépôts et la documentation décrivent un modèle avec authentification Discord, rôles granulaires, sous-utilisateurs et historique d'actions pour déléguer sans perdre le contrôle.

Ce choix de conception répond à un besoin concret: permettre à des modérateurs ou membres d'équipe de consulter des statistiques et suivre le support sans leur donner la main sur la configuration complète d'un serveur.

La structure V2 montre un produit plus large qu'un front marketing: backend Fastify, schéma Prisma, scripts d'administration, bot Discord, plugin Minecraft Gradle et SDK Go pour des usages edge. Chaque brique répond à un contexte précis sans casser l'unité du projet.

C'est ce genre de transition qui m'intéresse dans un case study: partir d'un panel utile, puis reconstruire progressivement l'architecture pour absorber davantage d'intégrations, de temps réel et d'outillage opérationnel.

Aujourd'hui, cette étude de cas documente surtout ce qui reste observable: l'architecture du code, la progression entre V1 et V2 et les écrans publics encore disponibles, le client ayant entre-temps arrêté l'API qui alimentait les parcours connectés.