Projet personnel, mené seul · 2025
SparkleQuiz
Application de quiz en solo et en multijoueur, en production sur le web, Android et iOS.
- plateformes : web, Android, iOS
- 3
- versions publiées
- 210+
- tests PHPUnit
- ~6 000
- coupure à chaque déploiement
- 0
Conçue, développée et exploitée seul : API Symfony, interface Vue 3, applis mobiles Capacitor, parties en temps réel, classements et quiz créés par les joueurs.
Mon rôle. Seul développeur : conception, back-end, front-end, applis mobiles, infrastructure et publication sur les stores.
Ce que j'ai fait
- Progression complète : niveaux, expérience, quêtes quotidiennes, 68 trophées et 4 classements synchronisés avec Game Center.
- Huit pipelines GitHub Actions : tests, déploiement Docker en production, publication sur les stores, mise à jour des fiches.
- Tests de bout en bout avec Playwright sur le web et Maestro sur mobile, audits Lighthouse.
Le point de départ
Je voulais un projet qui m'oblige à tout faire comme en entreprise, mais sans filet : concevoir le produit, l'architecture, la base, le front, les applis mobiles, puis le faire tourner en production et le maintenir.
Architecture
Une API Symfony 7 sur MariaDB sert à la fois le site et les applis. Le front Vue 3 en TypeScript est le même code partout : Capacitor l'emballe pour Android et iOS. Redis sert de cache et de file de messages, Mercure pousse les événements en temps réel.
Choix assumé : un monolithe bien découpé plutôt que des microservices. Pour une personne, c'est ce qui se déploie, se teste et se débogue le plus vite.
Vue 3 + TypeScript · Capacitor
Temps réel
Les parties multijoueur passent par Mercure (Server-Sent Events) plutôt que par des WebSockets maison : moins de code serveur, reconnexion gérée par le navigateur, et l'autorisation des canaux reste dans Symfony.
Qualité et CI
Chaque changement passe par la même porte : PHPStan, PHP-CS-Fixer, PHPUnit, lint et vérification de types du front, Vitest, contrôle de parité des traductions et budget CSS. Playwright rejoue les parcours critiques chaque nuit.
Côté API, une règle simple : toute erreur prévisible renvoie un 4xx clair, un 5xx signale un vrai bug et remonte dans le monitoring.
Déploiement
Un push sur main déploie le site sur mon serveur par GitHub Actions, en blue/green derrière Caddy : la nouvelle version démarre à côté de l'ancienne et ne reçoit le trafic qu'une fois saine. Un tag de version publie l'appli sur Google Play et la soumet à Apple. Les correctifs urgents partent en mise à jour à chaud, sans repasser par les stores.
Ce que ça m'a appris
Le plus dur n'est pas d'écrire la fonctionnalité, c'est de la faire tenir en production : migrations sans coupure, compatibilité entre versions d'applis encore installées, performances sur des téléphones d'entrée de gamme, et des tests assez fiables pour livrer souvent sans stress.