La gestion des données est au cœur de StockSuaps. L'application centralise un stock physique complexe : chaque article de sport est décrit à deux niveaux — un article global (nom, référence, distributeur, sport, famille) et un article précis qui l'instancie avec ses détails contextuels (salle, enseignant, état, quantité, couleur, taille). S'y ajoutent les référentiels métier (salles, enseignants, sports, familles, distributeurs), les mouvements (entrées, sorties, transferts avec traçabilité), et les besoins formulés par les utilisateurs. La base MySQL hébergée sur un serveur distant centralise l'ensemble, avec des contraintes d'intégrité, une gestion des droits d'accès par rôle, et des mots de passe et identifiants hashés pour protéger les données sensibles.
1. AC24.01 | Optimiser les modèles de données de l’entreprise
L'indépendance entre le stockage des données et le code métier est cruciale pour concevoir une application évolutive. J'ai mis en œuvre cette séparation des responsabilités grâce aux architectures d'accès aux données :
R3.07 - SQL dans un langage de programmation (Persistance et découplage architectural) : L'utilisation de JDBC, de JPA, ainsi que des patrons de conception DAO et Repository, m'a appris à masquer la complexité de la base de données. L'intégration de procédures stockées complète cette démarche en isolant les traitements lourds.
SAE :
Le modèle de données de StockSuaps distingue deux niveaux d'article : l'article global (nom, référence, distributeur, sport, famille) et l'article précis qui l'étend avec ses détails contextuels (salle, enseignant, état, quantité, couleur, taille). Ce modèle a été conçu pour éviter la redondance tout en permettant de gérer efficacement les mouvements et les besoins. Les tables sont normalisées, les clés étrangères définissent les relations, et des index ont été ajoutés sur les colonnes fréquemment filtrées.
2. AC24.02 | Assurer la sécurité des données (intégrité et confidentialité)
L'indépendance entre le stockage des données et le code métier est cruciale pour concevoir une application évolutive. J'ai mis en œuvre cette séparation des responsabilités grâce aux architectures d'accès aux données :
R3.07 - SQL dans un langage de programmation (Persistance et découplage architectural) : L'utilisation de JDBC, de JPA, ainsi que des patrons de conception DAO et Repository, m'a appris à masquer la complexité de la base de données. L'intégration de procédures stockées complète cette démarche en isolant les traitements lourds.
SAE :
Dans StockSuaps, l'intégrité des données est garantie par des contraintes MySQL (clés étrangères entre articles précis et articles globaux, NOT NULL sur les champs obligatoires) et par la validation côté API avant toute écriture en base. La confidentialité repose sur le hashage bcrypt des mots de passe, les tokens JWT pour contrôler l'accès aux données, et le hashage des identifiants d'articles pour éviter l'énumération.
3. AC24.03 | Organiser la restitution de données à travers la programmation et la visualisation
La restitution claire des informations repose sur une séparation stricte entre l'extraction des données et leur affichage. J'ai structuré cette passerelle technique en combinant deux compétences complémentaires :
R3.01 - Développement web (Affichage dynamique et intégration de données) : Le développement en PHP du système de gestion des radars m'a appris à l'interroger une base de données pour en afficher le contenu en temps réel. Transformer ces informations brutes en une interface utilisateur lisible.
R3.07 - SQL dans un langage de programmation (Couche de persistance et découplage des vues) : L'exploitation de JPA et du patron de conception DAO m'a permis de structurer proprement la couche d'accès aux données. Isoler la persistance de la logique d'affichage garantit l'indépendance des composants, ce qui a grandement facilité le développement et la maintenance des vues au sein de l'application.
SAE :
StockSuaps restitue les données différemment selon le profil connecté : les administrateurs voient l'ensemble du stock toutes salles confondues, tandis que les professeurs ne voient que les articles qui leur sont rattachés. Cette logique de filtrage est appliquée côté API via le rôle contenu dans le token JWT. L'inventaire est présenté sous forme de liste détaillée, et le module de besoins permet de visualiser les demandes en attente et de les appliquer directement depuis l'interface.
4. AC24.04 | Manipuler des données hétérogène
Gérer des données variées sans créer de bugs demande une vraie méthode. J'ai travaillé sur ce point précis à travers deux matières :
R3.01 - Développement web (Normalisation et validation des données d'entrée) :
Pour le TP PHP sur les radars, l'application recevait des informations très différentes : du texte, des entiers, des dates et des coordonnées de capteurs. Ce projet m'a appris à filtrer et vérifier chaque donnée à l'entrée avant de la traiter ou de l'enregistrer.
R4.03 - Qualité et au delà du relationnelle (Intégrité des données et cohérence inter-couches) :
Avec le projet MongoLingo en React, j'ai manipulé du NoSQL où les documents n'ont pas de structure fixe. Cette flexibilité de MongoDB impose d'être très vigilant. Si le format des données envoyées par l'application React ne correspond pas exactement à ce que la base attend, on crée des incohérences qui cassent l'affichage ou l'apprentissage de l'utilisateur.