-- Présentation --
PMT est une plateforme de gestion de projet collaboratif destinée aux équipes de développement logiciel. L'application permet de planifier, suivre et collaborer sur des projets de manière structurée, avec un système de rôles différenciés, un tableau de bord de suivi des tâches et des notifications par e-mail. Un outil pensé pour les équipes qui ont besoin de visibilité sur leur travail sans la complexité d'un Jira ou d'un Linear.
C'est une étude de cas examen, réalisée seule, de A à Z, dans le cadre du titre mastère Expert en Ingénierie du Logiciel. Le périmètre couvrait l'intégralité du cycle de développement : conception du modèle de données, développement fullstack, tests automatisés avec couverture à 60%, conteneurisation Docker et pipeline CI/CD GitHub Actions. Aucun compromis possible sur les livrables, aucune équipe pour partager la charge.
-- Objectifs --
L'objectif central était de livrer une application web fullstack fonctionnelle, testée, conteneurisée et déployable, couvrant douze user stories allant de l'inscription jusqu'à l'historique des modifications des tâches. Le tout avec une stack imposée : Angular en frontend, Java Spring Boot en backend, MySQL ou PostgreSQL en base de données.
Le contexte était celui d'un examen : délai contraint, évaluateur exigeant, périmètre non négociable. L'enjeu n'était pas seulement de faire fonctionner l'application, mais de démontrer une maîtrise complète du cycle de développement logiciel, de la modélisation jusqu'à l’industrialisation.
Les risques étaient multiples. Un périmètre large conduit seul, c'est un risque permanent de sous-estimer une fonctionnalité et de se retrouver bloqué en fin de projet. La gestion des rôles avec des permissions différenciées (administrateur, membre, observateur) était le point le plus complexe à modéliser et à implémenter correctement. Un mauvais choix de modèle de données à ce niveau aurait conduit à une refactorisation coûteuse en temps. Les notifications par e-mail via Spring Mail introduisaient une dépendance externe qui pouvait échouer silencieusement. La couverture de tests à 60% sur un périmètre aussi dense nécessitait une stratégie de test pensée dès le début, pas ajoutée en catastrophe à la fin.
-- Étapes --
Phase 1 : Analyse et modélisation
Avant d'écrire la première ligne de code, l'ensemble des user stories a été analysé pour identifier les entités et leurs relations. Utilisateurs, projets, la relation d'appartenance entre un utilisateur et un projet avec son attribut de rôle, les tâches avec leurs propriétés (nom, description, date d'échéance, priorité, statut), l'historique des modifications, les assignations. Chaque entité a été positionnée dans un schéma de base de données, les clés étrangères tracées, les contraintes d'intégrité définies. Ce schéma a été livré en premier, avant tout développement, pour servir de fondation stable à toute la suite.
Le script SQL de génération de la base de données a été produit en parallèle, avec des données de test permettant de valider immédiatement les requêtes une fois l'application lancée.
Phase 2 : Organisation du travail
Chaque user story a été traduite en issue GitHub avec un label, une priorité et un ordre de traitement logique. Les entités fondamentales d'abord : utilisateurs et authentification, puis projets et gestion des membres avec leurs rôles, puis les tâches et leurs cycles de vie, puis l'historique et les notifications. Ce séquençage évitait de se retrouver à implémenter une fonctionnalité dont la fondation n'était pas encore en place.
Un workflow Git a été défini et appliqué rigoureusement : une branche par fonctionnalité, chaque commit lié à son issue, les merges sur la branche principale uniquement quand la fonctionnalité était testée et fonctionnelle.
Phase 3 : Développement backend
Le backend Spring Boot a été structuré en couches séparées : contrôleurs pour l'exposition des endpoints REST, services pour la logique métier, repositories pour la persistance via Spring Data JPA. Les endpoints couvrent l'intégralité des user stories : inscription, connexion, CRUD des projets, gestion des membres et des rôles, CRUD des tâches avec assignation, tableau de bord par statut, historique des modifications, notifications par e-mail via Spring Mail à chaque assignation de tâche.
La gestion des rôles a été implémentée au niveau service : chaque action contrôlée selon le rôle de l'utilisateur sur le projet concerné. Un administrateur peut tout faire, un membre peut créer et modifier des tâches, un observateur consulte sans modifier.
Phase 4 : Développement frontend
L'interface Angular a été construite module par module, en miroir de l'architecture backend. Un module d'authentification, un module de gestion des projets, un module de tâches avec son tableau de bord par statut, un module de gestion des membres. Les services Angular gèrent l'ensemble des appels HTTP vers l'API. Le design a été laissé à la discrétion de l'implémentation, ce qui a permis de concentrer l'effort sur la fonctionnalité et la structure plutôt que sur l’esthétique.
L'affichage du tableau de bord par statut des tâches a demandé une attention particulière : les tâches devaient être regroupées dynamiquement par statut, triées par priorité, avec un indicateur visuel clair pour chaque état.
Phase 5 : Tests
Les tests ont été écrits en parallèle du développement, pas ajoutés en fin de projet. Côté backend : tests unitaires sur les services avec JUnit et Mockito, tests d'intégration sur les repositories et les contrôleurs avec Spring Boot Test. Côté frontend : tests unitaires sur les composants et les services avec Jest. La couverture a été mesurée et les rapports générés pour les deux couches, atteignant le seuil requis de 60% sur les instructions et les branches.
Phase 6 : Industrialisation
Deux Dockerfiles ont été écrits, un pour le frontend Angular et un pour le backend Spring Boot. Un fichier docker-compose.yml orchestre les trois services : frontend, backend, base de données MySQL, avec les variables d'environnement nécessaires et les dépendances de démarrage correctement configurées.
La pipeline GitHub Actions automatise le build, l'exécution des tests avec génération des rapports de couverture téléchargeables, et le push des images Docker sur DockerHub. La procédure de déploiement a été documentée dans le README pour permettre à n'importe quel développeur de cloner le projet et de le lancer en une commande.
-- Acteurs --
Le scénario de l'énoncé positionne trois interlocuteurs fictifs : John Doe, le CEO de Code Solutions, qui affecte le développeur au projet PMT, Nicolas, le Product Owner, qui fournit la liste des user stories, et Mariana, la tech lead, qui définit les guidelines techniques à respecter.
Dans la réalité de l'examen, ces trois rôles se traduisent par l'énoncé lui-même : les user stories de Nicolas comme contrat fonctionnel, les guidelines de Mariana comme contraintes techniques non négociables, et l'évaluateur comme destinataire final du livrable. Chaque décision d'implémentation a été prise en cohérence avec ces trois référentiels simultanément.
Le seul vrai acteur humain a été le développeur. Aucune équipe, aucun pair pour relire le code, aucun QA pour valider les fonctionnalités. Cette configuration solo a rendu chaque décision entièrement assumée et chaque livrable entièrement responsable.
-- Résultats --
Pour le développeur : PMT a été le projet le plus complet réalisé en termes de périmètre fonctionnel et technique. Couvrir seul l'intégralité du cycle, de la modélisation jusqu'à la pipeline CI/CD, sur une application avec une logique métier aussi riche que la gestion des rôles et l'historique des modifications, a représenté un saut qualitatif réel. La maîtrise de Spring Boot, d'Angular, de Docker et de GitHub Actions s'est consolidée sur ce projet d'une manière que les tutoriels ne permettent pas. Chaque problème rencontré, chaque bug débugué, chaque test écrit a laissé une trace durable dans la compréhension de ces technologies.
Pour l'évaluation : L'ensemble des livrables requis a été livré : schéma de base de données, script SQL, code source frontend et backend, rapports de couverture, Dockerfiles, docker-compose.yml, pipeline CI/CD configurée, README documenté. Le projet démontre une capacité à conduire un développement logiciel complet de manière autonome, en respectant des standards de qualité mesurables.
-- Lendemains --
Dans un futur immédiat, l'application était fonctionnelle et déployable mais présentait des manques identifiés. Spring Security n'était pas requis par l'énoncé, ce qui signifiait qu'aucune authentification réelle ne protégeait les endpoints : n'importe qui pouvant accéder à l'API pouvait appeler n'importe quel endpoint. Ce compromis acceptable dans un contexte académique serait éliminatoire en production. L'ajout de JWT et d'une sécurisation des routes par rôle était la prochaine étape logique.
À distance, PMT a posé des bases techniques solides réutilisées sur les projets suivants. L'architecture en couches du backend Spring Boot, le découpage en modules Angular, la structure de la pipeline GitHub Actions : ces patterns ont été repris et affinés sur ShopWise et InnotechFusion. Un projet ne disparaît pas une fois livré, il devient un référentiel pour les décisions futures.
Aujourd'hui, PMT est un projet de démonstration sur le portfolio. Il illustre concrètement la capacité à concevoir et livrer une application fullstack complète, testée et industrialisée. Dans le cadre du projet de société de développement logiciel, le type d'outil représenté par PMT a une valeur commerciale directe : les équipes de développement ont besoin de ces outils, et maîtriser leur construction est un atout différenciant.
-- Regard critique --
PMT est le projet sur lequel la fierté est la plus justifiée, et aussi celui sur lequel le regard critique est le plus acéré. Livrer seul un périmètre aussi dense, de bout en bout, dans un délai contraint : c'est une réussite mesurable. Mais la distance permet de voir ce qui aurait pu être mieux.
L'absence de Spring Security est le regret le plus évident. L'énoncé le dispensait, mais rien n'empêchait de l'ajouter. Une application de gestion de projet sans authentification réelle n'est pas une application de production, c'est une démonstration. Ce choix de rester dans le périmètre minimal plutôt que d'aller au-delà reflète une gestion du temps correcte mais une ambition un peu trop calibrée sur la note plutôt que sur la qualité finale.
La couverture de tests à exactement 60% est un autre point de vigilance. Atteindre le seuil requis est une chose. L'atteindre en testant ce qui comptait vraiment, les règles métier critiques, les cas limites, les comportements sur les permissions, plutôt qu'en cherchant le taux le plus facile à atteindre : c'est là que la maturité du développeur se révèle. La stratégie de test aurait pu être plus intentionnelle.
Ce projet reste une référence personnelle forte. Il représente le niveau atteint à un moment précis, avec les contraintes qui étaient celles du moment. Le relire aujourd'hui donne envie de le reconstruire avec Spring Security, avec des tests plus solides, avec une interface plus soignée. C'est exactement le signe que la progression a été réelle.