A la cool
Application de gestion de buvette et système de commande de snacks.
01 — Le contexte
Le projet consistait à moderniser un ancien projet étudiant (une application de gestion de buvette) en utilisant des technologies plus récentes. L’objectif principal était de créer une plateforme robuste permettant de gérer une buvette et d’offrir aux étudiants la possibilité de commander des snacks numériquement pour réduire significativement les files d’attente.
Le système de paiement est entièrement fictif et sert de simulation financière pour les besoins du projet universitaire, permettant aux utilisateurs d’alimenter un portefeuille virtuel.
02 — Inscription et Authentification
Pour rejoindre le système, un utilisateur doit s’inscrire dans une association en tant que bénévole. L’authentification est protégée par un token JWT côté backend.
L’interface de connexion a été conçue pour être claire et immédiate. Une fois connecté, chaque utilisateur est rattaché au solde global de son association, ce qui permet des transactions centralisées.
03 — Gestion des associations
Les administrateurs (Super Admins) disposent d’un tableau de bord complet pour gérer le cycle de vie des associations.
Cette vue permet de consulter les associations actives, de suivre leurs statistiques et d’interagir avec les fiches de chaque organisation. Côté utilisateur, l’interface permet également de consulter le catalogue de produits, de les ajouter au panier et d’utiliser le solde fictif.
04 — Traitement des demandes
La création d’une association ou l’ajout d’un membre n’est pas automatique : tout repose sur un système de demandes d’approbation.
Cette interface liste les requêtes en attente. C’est ici que l’équipe administrative peut approuver ou rejeter les nouvelles associations. Les commandes des utilisateurs passent par un processus similaire avec un suivi en temps réel des statuts (PAID, PREPARING, READY, COMPLETED, CANCELLED) grâce à Socket.IO.
05 — L'architecture technique
Pour soutenir cette application temps réel, le projet a été divisé en deux applications distinctes, nécessitant une communication rigoureuse :
Le Frontend (Angular) : L’architecture côté client a été découpée de manière modulaire :
core: Services d’authentification, gestion du panier et communication Socket.features: Composants métier.layout&shared: Éléments d’interface réutilisables.
Le Backend (Flask) :
L’API REST Python a été modélisée par domaine (authentication, products, orders, user). L’ensemble des endpoints est documenté via Swagger.
Les difficultés rencontrées :
L’un des défis majeurs a été l’intégrité de la base de données relationnelle (PostgreSQL). Par exemple, un bug empêchait la suppression correcte des demandes d’association rejetées de la table demande. Ce problème de contraintes de clés étrangères a été diagnostiqué au niveau de l’ORM (SQLAlchemy) puis corrigé avec des suppressions en cascade appropriées.