-- Mes preuves --

InnotechFusion était une étude de cas d’entrainement, l'objectif était de développer une application permettant de gérer l'émargement des votants pour les élections du conseil d'administration de l'association. Un contexte contraint, un délai serré, une stack imposée : Angular, Spring et MySQL. Aucune marge pour improviser. Le frontend Angular a été conçu pour afficher sous forme de tableau la liste complète des membres de l'association, avec leurs informations personnelles et un bouton d'action irréversible. Une fois actionné, le bouton se transformait en statut "A voté" : une interaction simple en apparence, mais qui demandait une gestion précise de l'état du composant, de la communication avec l'API backend et de l'immutabilité de l'action côté client. L'ensemble a été réalisé seul, de A à Z, avec en prime la Dockerisation du frontend, une pipeline CI/CD configurée et quelques tests automatisés pour garantir la stabilité du rendu. Le résultat : une interface claire, fonctionnelle, et une couverture de tests satisfaisante dans le temps imparti. ShopWise était une étude de cas examen différente dans sa forme, mais identique dans son exigence. La mission : développer une plateforme web et mobile destinée aux commerces indépendants, couvrant la gestion clients, la fidélisation par points et la prise de rendez-vous. Stack imposée : Angular côté frontend, Java Spring Boot en backend, base de données relationnelle. Le frontend Angular devait être responsive, couvrir deux types d'écrans minimum, et s'interfacer proprement avec le backend. Chaque module de l'application, gestion des clients, agenda des rendez-vous, tableau de fidélité, a été construit sous forme de composants distincts, avec des services Angular dédiés pour les appels HTTP et la logique métier. Les tests frontend ont atteint le seuil requis de 60% de couverture, les rapports ont été générés et versionnés dans le repository. La pipeline CI/CD a automatisé le build, les tests et le push des images Docker sur DockerHub. Tout cela, développé seul, sans filet. Le projet PMT était une étude de cas qui représentait probablement le défi Angular le plus complet de ces études de cas. Il s'agissait de concevoir une plateforme de gestion de projet collaboratif, à destination d'équipes de développement, avec des rôles différenciés : administrateur, membre, observateur. Côté frontend Angular, cela impliquait une gestion fine des permissions dans l'interface : certaines actions ne devaient apparaître qu'à certains profils, les vues devaient s'adapter dynamiquement selon le rôle de l'utilisateur connecté. Les fonctionnalités couvraient la création de projets, l'invitation de membres, l'attribution de tâches, le tableau de bord par statut et la notification par e-mail lors d'une assignation. Chaque user story a été implémentée, testée, et liée à une issue GitHub. Le frontend a été entièrement structuré en modules Angular, chaque domaine fonctionnel isolé dans son propre espace, avec un routing précis et des services bien découplés. Un projet réalisé seul, de la conception du schéma de base de données jusqu'au déploiement Docker, en passant par la configuration de la pipeline GitHub Actions.

-- Autocritique --

Honnêtement, Angular n'a pas été une évidence. La courbe d'apprentissage est réelle, et il serait malhonnête de prétendre le contraire. Les premiers composants étaient trop gros, trop chargés en logique : ce qui aurait dû appartenir à un service se retrouvait directement dans le TypeScript du composant, ce qui rendait les tests plus difficiles à écrire et le code plus fragile à maintenir. La gestion du routing a également été un point de friction au début. Configurer des routes protégées, gérer des paramètres dynamiques, comprendre la différence entre un module lazy-loaded et un module chargé à l'initialisation : tout ça demande du temps, de la pratique et souvent quelques erreurs avant que ça devienne naturel. Les projets d'examen ont forcé à progresser vite, parfois trop vite pour prendre le recul nécessaire sur les choix d'architecture. Le niveau de maîtrise actuel est honnête : les fondamentaux sont solides, les composants, les services, le routing, les formulaires réactifs, les pipes, les directives. Les tests unitaires Angular avec Jest sont fonctionnels. Mais il reste des zones d'ombre, notamment sur la gestion avancée de l'état avec des librairies comme NgRx ou sur l'exploitation des Signals. Ce sont des sujets que les projets d'examen n'ont pas eu l'occasion de couvrir en profondeur, faute de temps. La vitesse d'acquisition a été correcte dans l'ensemble. Partir d'une compréhension basique du framework pour livrer trois projets complets en conditions d'examen, chacun avec un frontend Angular testé, dockerisé et intégré dans une pipeline CI/CD : c'est un signe que la progression a été réelle, même si la maîtrise n'est pas encore celle d'un développeur Angular senior. Ce qui est acquis, c'est surtout la capacité à structurer une application de façon cohérente, à isoler les responsabilités, à écrire du code qu'un autre développeur pourrait reprendre sans se perdre. Le conseil que je me donnerais : ne pas attendre d'avoir terminé un projet pour refactoriser. Remettre à plus tard la séparation d'un composant trop lourd ou la création d'un service manquant, c'est accumuler une dette technique qui coûte cher en fin de projet. Prendre cinq minutes pour bien organiser avant d'écrire la première ligne : c'est du temps économisé au moment du debug et des tests.

-- Évolution --

Angular est la technologie sur laquelle le prochain palier est le plus clairement identifié. Les projets d'examen ont posé une base solide, mais ils avaient tous une contrainte commune : le temps. Et le temps contraint ne permet pas toujours d'aller explorer les coins du framework qui font vraiment la différence sur un projet long. L'objectif à court terme, c'est de maîtriser les Signals. C'est quelque chose que je veux comprendre en profondeur, pas juste utiliser parce que c'est à la mode. Il y a aussi la question du state management. Sur des projets de taille modeste comme ceux réalisés en examen, s'en passer est envisageable. Sur une vraie application en production avec plusieurs dizaines de composants et des flux de données complexes, ça devient indispensable. NgRx est sur la liste. Pas pour empiler des couches d'abstraction inutiles, mais pour comprendre quand et pourquoi c'est pertinent. Dans le cadre du projet de création de société, Angular sera probablement l'un des outils privilégiés pour les applications web. L'idée est d'y revenir sur un projet personnel ambitieux, quelque chose qui dépasse le cadre de l'examen, où il sera possible de vraiment prendre le temps de construire une architecture pensée sur la durée, testée sérieusement, et documentée correctement. C'est là que la compétence passera du niveau "fonctionnel" au niveau "maîtrisé".

-- Projets liés --