Gestionnaire de personnage D&D

Aperçu de l'application

Le besoin

Les fiches de personnage de ma table de jeu vivaient dans un tableur Google Sheets. Pratique pour noter, beaucoup moins pour appliquer des règles qui dépendent à la fois de la classe, du niveau et de l'équipement, et peu lisible sur un téléphone en pleine partie.

L'objectif : une application que chaque joueur ouvre sur son téléphone pendant la partie, qui applique les règles à sa place et fonctionne même sans réseau.

Un cadre serré : trois jours

Je n'avais que trois jours pour construire l'application. J'en ai consacré deux et demi à mon propre personnage, Yomi, clerc du Crépuscule : c'est lui qui a servi à cadrer le moteur de règles, le mode jeu et les calculs. La dernière demi-journée a porté sur les spécificités des trois personnages de mes compagnons : un barbare, un moine et une druide.

Ce découpage tient parce que les classes, sous-classes, races et dons sont des registres déclaratifs : ajouter un personnage revient à décrire ce qui le distingue, pas à réécrire l'application. Le temps compté a imposé de choisir ce qui comptait vraiment à la table, et de documenter chaque choix dans un ADR plutôt que de le garder en tête.

Un moteur de règles plutôt qu'un formulaire

Le principe directeur : toute valeur dérivable des paramètres du personnage est calculée, jamais stockée. Seuls les choix du joueur et sa consommation de ressources sont persistés.

• Registres déclaratifs de classes, sous-classes, races et dons : ajouter une option revient à ajouter une entrée, pas à modifier l'interface.
• Fonctions pures et testées pour la classe d'armure, les attaques d'armes, les sauvegardes, l'initiative, les points de vie maximums et les emplacements de sorts.
• Chaque règle appliquée automatiquement est listée en clair dans la fiche, pour que le joueur comprenne d'où vient chaque chiffre.

Persistance et évolution des données

Pas de back-end dans cette première version : les données vivent dans le navigateur, derrière un repository pattern qui permettra de brancher une API sans toucher aux écrans.

• Formats de stockage versionnés, avec une migration à chaque évolution du modèle : les fiches existantes sont converties au chargement, jamais perdues.
• Import et export JSON validés par Zod, avec un aperçu ligne par ligne (nouveau, mise à jour, identique, invalide) avant d'écrire quoi que ce soit.
• Service worker pour un usage hors ligne, et application installable sur mobile.

Une interface pensée pour la table de jeu

Deux modes distincts : la configuration, où l'on construit le personnage, et le jeu, où l'on ne fait que consulter et consommer. En mode jeu, un HUD de combat reste visible en permanence : classe d'armure, points de vie, ressources de classe.

Viennent ensuite les mécaniques de partie : attaque guidée pas à pas, jets contre la mort, épuisement, repos courts et longs, forme sauvage du druide, historique des actions et journal de session.

Qualité et méthode

Le projet part d'un socle que j'ai formalisé dans un dépôt modèle : TypeScript strict, ESLint, Prettier, hooks de pré-commit, Vitest et Testing Library, et une CI qui enchaîne typecheck, lint, tests et build à chaque push.

Je développe avec un agent IA (Claude Code). Mon rôle : cadrer le besoin, trancher l'architecture, rédiger les ADR, relire chaque pull request et tenir le niveau d'exigence. Dans un délai aussi court, ce sont les tests, la CI et les ADR qui garantissent que la vitesse ne se paie pas en qualité, et qui rendent ce travail vérifiable par n'importe qui.