StockSuaps est une application distribuée : le client Flutter tourne sur les postes et appareils des utilisateurs (Windows, Android, Web) tandis que le backend Node.js et la base MySQL sont hébergés sur un serveur distant de l'université. Toute l'application repose donc sur des échanges réseau constants, chaque consultation de l'inventaire, chaque mouvement de stock, chaque action sur les référentiels déclenche des appels HTTP vers l'API. Cette architecture communicante a soulevé des problématiques concrètes d'administration système : configuration du serveur, gestion des accès réseau, sécurisation des échanges, et fiabilité de la communication entre les différentes plateformes clientes.
1. AC23.01 | Concevoir et développer des applications communicantes
Comprendre les couches basses d'un système permet de concevoir des architectures applicatives plus fiables et mieux maîtrisées. J'ai consolidé cette approche à travers deux étapes de ma formation :
R3.05 - Programmation système (Mécanismes bas niveau et communication) : Le travail sur les processus, la mémoire, le multi-threading et les sockets réseau m'a montré le fonctionnement réel des échanges de données. Je ne manipulais plus des abstractions floues, mais des mécanismes physiques déjà expérimentés à bas niveau.
R4.01 - Architecture logicielle (Conception d'API et contrats d'interface) : Le projet Java sous Maven a complété cette vision en introduisant la formalisation des échanges. L'utilisation d'OpenAPI et de Swagger m'a appris à aborder une API comme un contrat strict entre le client et le serveur. Cette démarche impose de définir rigoureusement la structure des données avant le codage pour garantir l'interopérabilité du système.
SAE :
StockSuaps repose entièrement sur la communication entre le client Flutter et le serveur distant : chaque action utilisateur déclenche une requête HTTP/JSON vers l'API Node.js, qui interroge la base MySQL et retourne une réponse structurée. J'ai contribué à la conception et à l'implémentation de plusieurs endpoints, en gérant la sérialisation des données, les codes de réponse HTTP, la gestion des erreurs réseau côté Flutter, et la cohérence des données entre les différentes plateformes clientes (Windows, Android, Web).
2. AC23.02 | Utiliser des serveurs et des services réseaux virtualisés
La conteneurisation transforme la gestion des environnements de développement et de production en éliminant les barrières matérielles. J'ai validé ces compétences techniques lors de travaux pratiques ciblés :
R4.08 - Virtualisation (Encapsulation et isolation des services) : L'utilisation de Docker m'a appris à encapsuler un service complet, comme une base de données MySQL, dans un conteneur portable. Cette approche permet à chaque développeur d'exécuter instantanément une instance identique, sans aucune configuration manuelle sur sa machine. Ce module a rendu concrets les principes d'isolation et de reproductibilité, offrant une solution définitive aux conflits d'environnement au sein d'une équipe.
SAE :
L'API Node.js et la base MySQL de StockSuaps sont hébergées sur un serveur distant partagé. Nous avons configuré l'environnement serveur (ports, variables d'environnement, accès à la base), géré les problèmes de connectivité réseau rencontrés lors du développement (conflits de ports, accès refusé, synchronisation des données entre développeurs), et assuré que l'API reste accessible depuis les différentes plateformes clientes Flutter.
3. AC23.03 | Sécuriser les services et données d’un système
La sécurité d'un système logiciel repose sur le principe de la méfiance systématique face aux données entrantes. J'ai intégré cette posture défensive à travers deux approches distinctes :
R3.02 - Développement efficace (Programmation par contrat et validation des données) : L'écriture de tests basés sur des préconditions, des postconditions et des invariants en Java m'a appris à sécuriser le code dès sa conception. Cette logique impose de vérifier rigoureusement les données à l'entrée et à la sortie de chaque fonction. Cette habitude permet de filtrer les requêtes en amont afin de bloquer les injections et les accès illégitimes.
R3.03 - Analyse (Intégration d'API tierces et gestion des flux externes) : La manipulation d'une API externe pour le projet de bibliothèque sous FlutterFlow a mis en évidence les risques liés aux dépendances extérieures. Cette expérience montre qu'il ne faut jamais faire confiance aveuglément aux données reçues. Il devient alors indispensable de valider chaque réponse, de traiter proprement les erreurs de communication et de sécuriser les échanges avec les services tiers.
SAE :
La sécurisation de l'API de StockSuaps a été construite en couches : token JWT obligatoire sur toutes les routes, rôle de l'utilisateur encodé dans ce token pour que l'API filtre les données selon les droits (un professeur ne peut pas accéder aux stocks d'un autre enseignant ni aux pages mouvement et gestion), validation des inputs côté serveur avant toute écriture en base, et hashage des identifiants articles pour éviter l'énumération. Ces mesures garantissent qu'un appel non authentifié ne peut ni lire ni modifier des données auxquelles il n'a pas accès.