- Next.js 16
- React 19
- NestJS
- socket.io
- Prisma
- PostgreSQL
- Docker
Code privé, démo sur demande
Le contexte
Jouer au Scrabble en ligne entre amis passe souvent par des applis chargées de publicités et qui imposent un compte. L'objectif : une plateforme simple, sans compte obligatoire, où l'on partage un lien et la partie commence. Le Scrabble est le premier jeu, l'architecture est pensée pour en accueillir d'autres (échecs, Puissance 4…).
Mon rôle
Projet personnel : architecture, front-end, back-end, infrastructure et déploiement.
Points clés
Moteurs de jeu indépendants
Les règles vivent dans des packages TypeScript purs, sans framework, derrière une interface commune (créer une partie, vérifier un coup, l'appliquer, détecter la fin). L'API ne connaît aucune règle : ajouter un jeu ne touche pas au serveur.
Temps réel et serveur qui fait autorité
Les coups passent par socket.io et sont validés côté serveur. Les clients ne reçoivent jamais l'état brut : les chevalets adverses et le sac restent masqués, impossible de tricher en inspectant le réseau.
Pensé pour tous
Interface en français et en anglais (traductions vérifiées par le compilateur), thème clair et sombre, responsive avec glisser-déposer tactile. Le domaine renvoie des codes, la traduction se fait côté web.
Prêt pour la production
Monorepo pnpm + Turborepo, développement en TDD (Vitest, tests e2e contre PostgreSQL), Docker Compose, HTTPS via Caddy, sauvegardes quotidiennes vérifiées et CI GitHub Actions.
Ce que j'en retiens
Séparer strictement les règles du jeu de l'infrastructure rend chaque partie testable isolément et le projet facile à faire évoluer. Gérer des informations cachées en temps réel m'a obligé à penser la sécurité dès la conception du protocole.