Malo
Guillou

1. Démarches, prises de décisions et implication

Le projet Droopy était une reprise et une amélioration d'une plateforme existante de mise à jour modulaire de firmware embarqué. Avant d'écrire la moindre ligne de code, j'ai passé un temps significatif à comprendre l'architecture : six composants (Bootstrapper, Module Manager, Dynamic Loader, Memory Allocator, Update Manager, Update Provider), chacun indépendant, avec un cycle de vie précis pour chaque module.

Une fois l'architecture assimilée, j'ai pris en charge trois fonctionnalités de façon autonome :

• L'état pending des modules : un module qui dépend d'autres non encore chargés doit attendre. J'ai défini les conditions de transition et implémenté la logique dans le Module Manager.
• L'affichage des informations d'un module : lecture et présentation du manifeste binaire de 100 octets (type, ID, version, checksum SHA1, signature, dépendances).
• Le verrouillage d'un module en cours d'utilisation : empêcher qu'un module actif soit déchargé, avec vérification d'état avant toute opération.

Le stage m'a placé en situation entièrement autonome : reprendre seul un projet Node.js / Express existant, sans mission prédéfinie, avec pour objectif de l'améliorer, le sécuriser et le déployer. La première décision a été de réaliser un audit complet du code avant de toucher quoi que ce soit : console.log de données sensibles en production, mots de passe hachés en SHA-256, logique de tests rigide codée en dur, session détruite sans await, double envoi de réponse HTTP dans deux routes.

À partir de cet état des lieux, j'ai construit moi-même une feuille de route en 7 phases (qualité, sécurité urgente, sécurité applicative, déploiement, documentation, RGPD, tests utilisateurs) et rédigé des issues GitLab pour chaque tâche, en distinguant ce qui était fait, en cours, bloqué ou à planifier. Les décisions techniques ont toutes été prises de façon autonome : choix de csrf-sync plutôt que csrf-csrf (incompatibilité avec express-session découverte en pratique), choix de crypto.randomUUID() pour remplacer MD5, architecture du middleware d'auth centralisé à construire sur le modèle déjà présent dans classes.js.

2. Ressources choisies et combinées

Ce projet m'a demandé de combiner des ressources très différentes :

• R4.01 Architecture logicielle pour la décomposition en modules indépendants.
• R4.10 Cryptographie et R3.09 Cryptographie et sécurité pour la signature RSA et le checksum SHA1.
• R3.05 Programmation système pour manipuler la mémoire flash et le code embarqué C bas niveau.
• R4.05 Anglais indispensable : toute la documentation, l'article IEEE et les commentaires de code étaient en anglais.

Le stage a mobilisé un spectre de ressources encore plus large, car les domaines abordés étaient nouveaux :

• R4.12 Sécurité système et réseaux et R3.09 Cryptographie et sécurité : fondement de toute la phase 2 (bcrypt, CSRF, session fixation, Helmet, HTTPS).
• R4.08 Virtualisation et R4.11 Réseau avancé : nécessaires pour comprendre le déploiement Nginx en reverse proxy et la configuration Let's Encrypt.
• R3.11 Droit des contrats du numérique : mobilisé pour la réflexion RGPD sur la conservation des données de performance d'élèves mineurs.

En dehors des ressources de cours, j'ai utilisé la documentation officielle d'Express, de Sequelize, de csrf-sync et de Helmet, les guides Certbot et Let's Encrypt pour Nginx, la documentation MySQL sur la gestion des privilèges, et les forums communautaires pour diagnostiquer l'incompatibilité de csrf-csrf avec express-session.

3. Justification de la maîtrise des apprentissages visés

• AC21.01 : description écrite de l'état pending et de ses transitions dans le wiki avant implémentation.
• AC21.03 : code C annoté Doxygen, fonctions à responsabilité unique, commentaires sur les conditions de verrouillage.
• AC22.01 : représentation compacte de l'état du module cohérente avec les contraintes mémoire STM32.
• AC24.04 : parsing du manifeste binaire de 100 octets (entiers, SHA1, signature RSA, flags).
• AC26.02 : documentation Doxygen, pages wiki, participation au rapport collectif en anglais et français.

• AC21.03 (bonnes pratiques) : suppression des console.log de production, correction du double res.send, ajout du await manquant sur session.destroy - chaque correction documentée en issue GitLab.
• AC22.03 (sécurisation des données) : migration bcrypt sur 13 fichiers, protection CSRF complète (formulaires Pug + fetch JS), régénération de session, Helmet, remplacement des identifiants MD5 par UUID - chantier le plus conséquent du stage.
• AC23.03 (sécuriser un système) : déploiement HTTPS Nginx + Let's Encrypt sur st-eps.org, activation du flag secure sur les cookies.
• AC24.02 (confidentialité des données) : identification des données de santé potentielles (performances sportives d'élèves), formalisation d'une politique de conservation, suppression de req.session.pass.
• AC25.04 (suivi de projet) : feuille de route en 7 phases, issues GitLab avec statuts (fermée / en cours / bloquée / à faire), points réguliers avec le tuteur.
• AC26.03 (rendre compte) : rapport de stage, documentation technique mise à jour, communication avec les interlocuteurs externes (Eskemm, OVH).

4. Ressources manquantes et ce que je changerais

Trois lacunes principales ont ralenti mon travail : le C embarqué bas niveau, l'anglais technique (article IEEE, documentation d'architecture), et les notions d'architecture modulaire dynamique (chargement, résolution de symboles, allocation best-fit). Si c'était à refaire, je consacrerais une semaine entière à lire et annoter l'article de référence avant de toucher au code, et j'aurais proposé plus tôt une cartographie collective des interfaces entre composants.

Deux lacunes m'ont freiné :

• L'écosystème Node.js / Express en profondeur : je connaissais JavaScript, mais pas les subtilités d'Express (middleware pipeline, gestion des sessions, ORM Sequelize). Il m'a fallu du temps pour comprendre pourquoi csrf-csrf était incompatible avec express-session et migrer vers csrf-sync - une demi-journée qui aurait pu être évitée avec une meilleure connaissance préalable de l'écosystème.
• Le déploiement et l'administration Linux en conditions réelles : configurer Nginx, obtenir un certificat Let's Encrypt, gérer les accès serveur via VPN, configurer les droits MySQL - autant de tâches que je n'avais pratiquées qu'en local ou en TP. La dépendance à des tiers (accès Eskemm, DNS OVH) a aussi introduit des blocages que je n'avais pas anticipés dans ma feuille de route initiale.

Si c'était à refaire, j'aurais consacré les deux premiers jours à un déploiement en local complet (Nginx + HTTPS autosigné + PM2) avant d'aborder la production, pour ne pas découvrir les difficultés de déploiement en même temps que les difficultés d'accès au serveur cible. J'aurais aussi intégré dès le début les délais liés aux tiers dans ma feuille de route.