Preuve SAE 3.01
StockSuaps est une application multiplateforme (Windows, Linux, Android, Web) conçue pour gérer le matériel du Service Universitaire des Activités Physiques et Sportives (SUAPS). Le projet a débuté par une phase de recueil des besoins auprès des utilisateurs, basée sur un cahier des charges initial et la création d'une maquette Figma pour valider l'interface.
Architecture et fonctionnalités
L'application utilise un client Flutter connecté à un backend Node.js et une base de données MySQL hébergée à distance. Le système s'organise autour de cinq sections principales :
- Accueil : Intégration d'un calendrier pour le suivi des activités.
- Inventaire : Affichage et droits d'accès différenciés selon le rôle de l'utilisateur (administrateurs ou enseignants).
- Mouvements : Traitement et traçabilité des flux de matériel (entrées, sorties et transferts entre sites).
- Besoins : Gestion des demandes de réapprovisionnement.
- Administration : Configuration des référentiels de l'application (distributeurs, salles, sports, familles d'articles et comptes enseignants).
Sécurité du système
La protection des données et des accès est gérée à plusieurs niveaux :
- Authentification : Stockage des mots de passe hashés dans la base de données.
- Contrôle d'accès : Utilisation de tokens JWT contenant le rôle de l'utilisateur pour verrouiller les points d'entrée de l'API Node.js.
- Intégrité : Hashage des identifiants des articles pour sécuriser les requêtes et éviter les manipulations de l'URL ou des requêtes HTTP.
▶︎ Les apprentissages critiques
1. AC21.01 | Elaborer et implémenter les spécifications fonctionnelles et non fonctionnelles à partir des exigences
La traduction de besoins fonctionnels en spécifications techniques exige une approche méthodique. J’ai développé cette pratique à travers deux réalisations concrètes :
- R3.01 - Développement web (Spécifications fonctionnelles et logique métier) :
Le développement en PHP du système de radars et de comptes m’a obligé à suivre des exigences strictes dès le départ. Il a fallu définir précisément la visibilité des données, restreindre les accès selon les différents profils d'utilisateurs et planifier les réactions de l'application face aux saisies incorrectes.
- R4.01 - Architecture logicielle (Spécifications non fonctionnelles et contrats d'interface) :
Dans le cadre du projet Java sous Maven, la démarche est devenue plus rigoureuse. Intégrer OpenAPI et Swagger pour décrire chaque endpoint avant la phase de codage impose de valider les contrats d'interface en amont. Cela permet de traiter les cas limites et de sécuriser l'architecture avant même de produire le code.