Étude de cas · Personnel
Application web de bar associatif solde prépayé, stocks et journal traçable
Les membres paient sur un solde prépayé les admins gèrent stocks et comptes via un journal des opérations traçable, sans suppression.
En bref
- Application web pour le bar d’une association, qui remplace une maquette limitée au navigateur les membres paient sur un solde prépayé, les admins gèrent stock, comptes et recharges.
- Chaque mouvement de solde ou de stock est ajouté sans jamais être modifié un contrôle nocturne vérifie que les valeurs stockées concordent, et une annulation écrit l’inverse au lieu de supprimer.
- Spécifié, conçu, relu et recetté par moi code écrit avec Claude Code. Environ 430 tests unitaires et d’API et 56 parcours navigateur passent avant chaque déploiement.
En résumé
- Rôle
- Développeur unique
- Équipe
- Projet individuel
- Période
- Statut
- Réalisé en octobre 2026, avec deux séries de retours du client
- Assistance IA
- importante Spécification, architecture, revue, tests et recette par moi code écrit avec Claude Code.
- Technologies
Contexte
Un projet pour le bar d’une association, qui n’est pas nommée ici. Son seul outil était une maquette HTML cliquable qui gardait ses données dans le navigateur. Le travail est passé par deux séries formelles de retours du client en octobre 2026.
Problème
Plusieurs personnes vendent, réassortissent et rechargent des comptes. Des données gardées dans un seul navigateur ne peuvent être ni partagées, ni contrôlées, ni sauvegardées. L’association avait besoin d’une vraie application multi-utilisateurs où chaque euro et chaque bouteille sont traçables.
Mon rôle, l’équipe et la part de l’IA
Projet solo. J’ai écrit les exigences (environ 900 lignes, avec des identifiants que les messages de commit citent), choisi l’architecture, relu le code et mené les tests et la recette. Le code a été écrit avec Claude Code à partir de ces exigences.
Contraintes
- Argent pas d’erreur d’arrondi, pas de double débit si une requête est renvoyée, pas de vente au-delà du découvert autorisé.
- Traçabilité rien de ce qui touche un solde ou le stock ne peut être supprimé.
- Appareil partagé une tablette de bar utilisée par plusieurs personnes doit fonctionner sans mot de passe personnel, sans ouvrir le reste de l’application.
- Données personnelles les membres peuvent obtenir un export de leurs données.
Solution et architecture
- Trois rôles le membre achète dans un catalogue, paie sur son solde, consulte son historique, propose des produits et paie sa cotisation l’admin gère le stock, les réassorts, les comptes, les recharges, le découvert de chaque compte, un tableau de bord et un journal exportable en Excel un mode « service bar », utilisable seulement depuis une tablette enregistrée, décompte les fournitures et tient la liste de courses.
- Journal solde, stock et fournitures sont des valeurs stockées, adossées à des tables de mouvements en ajout seul qui enregistrent la valeur après chaque mouvement et son auteur. L’argent est stocké en centimes entiers, et les règles métier sont aussi imposées par des contraintes SQL
CHECK. - Achat une seule transaction SQLite immédiate revérifie stock et solde, prend les prix côté serveur, recopie noms et prix dans les lignes de vente et utilise une clé d’idempotence deux acheteurs ne peuvent pas prendre le dernier article en même temps.
- Sécurité mots de passe Argon2id, vérification factice pour que le temps de réponse ne révèle pas si un compte existe, verrouillage après des échecs répétés, sessions en base qui ne stockent que l’empreinte des jetons dans des cookies
httpOnly, contrôle d’origine sur chaque écriture et contrôle du rôle sur chaque route. - Couches les services reçoivent la base en paramètre et lèvent des erreurs typées les routes d’API valident les entrées avec Zod et traduisent les erreurs en réponses.
- Démo une instance de démonstration séparée le code de démo est retiré du build de production à la compilation, et chaque base enregistre son mode, si bien qu’une réinitialisation de la démo ne peut jamais toucher la production.
Stack
TypeScript, SvelteKit et Svelte 5, Vite, Node.js, SQLite avec better-sqlite3 et Drizzle ORM, Zod, Argon2id, ExcelJS, Vitest, Playwright, nginx, systemd.
Qualité et vérification
- Environ 430 cas Vitest sur les services, les migrations appliquées à des données existantes et les routes d’API appelées à travers les vrais hooks de requête.
- 56 parcours Playwright sur téléphone et sur la tablette du bar, chacun en thème sombre et clair, plus un projet dédié à la démo.
- Le script de déploiement refuse de livrer si le typage, le lint ou l’une des deux suites de tests échoue il sauvegarde la base avant les migrations et revient en arrière si le contrôle de santé échoue.
- Une tâche nocturne vérifie que la somme des mouvements est égale à chaque solde et niveau de stock stocké.
Résultats et statut
Réalisé en octobre 2026 et revu avec le client en deux séries de retours. L’usage en production n’est pas communiqué ici.
Ce que je ferais autrement
- Lancer les suites de tests en intégration continue, en plus du script de déploiement.
- Rédiger la description publique anonymisée et les captures en même temps que les exigences, plutôt qu’après.
- Tester la charge du parcours d’achat sur la vraie tablette avant la première utilisation, pas seulement en émulation.
Liens
- Code source dépôt privé.
- Captures d’écran à venir, depuis l’instance de démonstration.