Le contexte
Un maître du jeu de mon entourage mène chaque semaine une table de cinq à six joueurs sur Symbaroum, un jeu de rôle dont les règles sont réparties entre plusieurs livres. Il m'a demandé un outil pour gérer ses monstres et calculer leurs statistiques en pleine partie, y compris pour une créature improvisée sur le moment.
J'ai mené le projet en parallèle de la fin de mon master de manager en ingénierie informatique.
Le vrai problème
La demande parlait de calculs. En creusant avec lui, le problème s'est déplacé : ce ne sont pas les calculs qui le gênent, c'est de ne pas pouvoir se fier aux informations. Elles sont dispersées entre plusieurs ouvrages et difficiles à croiser, et une erreur de lecture peut passer inaperçue pendant des semaines.
Un exemple réel : pendant la pause d'été, en relisant des règles pour préparer la suite de sa campagne, il a découvert qu'un talent qu'il pensait accessible ne l'était pas. Un des personnages avait justement été construit pour l'obtenir.
La formulation qui l'a fait réagir le plus fort est devenue la vision du projet :
Transformer chaque combat en moment de narration, pas en pause de calcul.
Sa réponse : « c'est l'essence même de mon problème ».
La démarche
J'ai traité ce projet personnel comme une mission client : je voulais une approche professionnelle, et me former au travail produit.
- Cadrage avant le code. Vision, problème, utilisateur type, analyse de l'existant, user stories, feuille de route, indicateurs. Aucune maquette ni ligne de code avant la fin de cette étape.
- L'existant. Aucun outil ne combinait quatre choses : pensé pour le maître du jeu, statistiques calculées, usage sur tablette autour de la table, et en français.
- Faire valider par l'utilisateur. J'ai proposé plusieurs formulations de la vision. C'est celle qui l'a fait réagir qui a été retenue, pas ma préférée.
- Un journal de décisions. Chaque choix y est noté avec son contexte et les alternatives écartées, pour pouvoir le justifier ou le revoir.
La solution
Une application web installable sur tablette, qui fonctionne sans connexion :
- création et modification de monstres à la volée ;
- les 35 créatures du bestiaire de base, classées par race ;
- calcul automatique de la défense, de l'armure et des dégâts selon les traits et talents ;
- dégâts affichés en moyenne et en formule de dés ;
- recherche par nom, race et résistance ;
- données enregistrées sur l'appareil, puis synchronisées en ligne.
Les choix techniques
| Choix | Plutôt que | Pourquoi |
|---|---|---|
| Vue 3 et TypeScript | Flutter, React | un premier produit à livrer seule, pensé pour tablette |
| Dexie.js (IndexedDB) | localStorage | un bestiaire volumineux, des parties parfois sans connexion |
| Application web installable | application Android | une adresse à partager, rien à installer depuis un store |
| Supabase | Firebase | une vraie base PostgreSQL, l'authentification intégrée, une offre gratuite |
La principale difficulté était dans les règles : certains talents changent la statistique de départ d'un calcul. Avec le talent Poigne de fer, par exemple, l'attaque et la défense ne partent plus de la Précision mais de la Force. Ces règles sont isolées dans des fonctions de calcul séparées de l'interface, ce qui permet de les vérifier une à une.
Le développement a été fait avec Claude Code et les maquettes avec Claude Design, à partir du cadrage et des règles documentées en amont.
Les retours et les itérations
Le maître du jeu teste l'outil et me transmet un fichier de remarques. En vérifiant ses statistiques, il a fait remonter trois erreurs de calcul et six évolutions, toutes traitées dans le sprint suivant.
La synchronisation en ligne a été avancée avant l'export de fichiers : non pas après une perte de données, mais pour ne pas attendre qu'elle arrive.
Où en est le projet
L'application est en ligne et en phase de test : le maître du jeu vérifie les calculs créature par créature avant de l'emmener à sa table. Les derniers ajustements de calcul sont en cours.