-- Présentation --
InnotechFusion est une application web de gestion de l'émargement électronique des votants, développée pour l'association fictive InnotechFusion à l'occasion de l'élection de son conseil d'administration. L'application liste l'ensemble des membres de l'association dans un tableau, avec leurs informations personnelles, et permet à un opérateur de valider leur passage au vote via un bouton d'action irréversible. Une fois actionné, le bouton se transforme en statut "A voté". Simple en apparence. Exigeant dans l’exécution.
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. Deux blocs de compétences évalués simultanément : intégration, industrialisation et déploiement du logiciel, et conception avancée de l'architecture logicielle. Le périmètre couvrait le développement de l'application V1, sa Dockerisation, une pipeline CI/CD, des tests automatisés, un document d'architecture, et un schéma prévisionnel pour une V2 intégrant la gestion de plusieurs scrutins et
-- Objectifs --
L'objectif principal était de livrer une application fonctionnelle, simple d'utilisation, et conçue dans les règles de l'art pour qu'elle soit évolutive et maintenable par un tiers. Pas d'interface complexe, pas de fonctionnalités superflues : la V1 devait faire une seule chose, la faire bien, et être conçue pour pouvoir en faire davantage demain sans tout réécrire.
Le contexte était particulièrement contraint. Le vote avait lieu à une date fixe, le délai était minimal, et les assurances qualité demandées par Steve, le référent légal de l'association, n'étaient pas négociables : document d'architecture, tests, Docker, CI/CD. Un projet qui devait être à la fois rapide à livrer et solide dans ses fondations.
L'enjeu dépassait la simple fonctionnalité. La validité du vote dépendait de la fiabilité de l'application. Une action de vote enregistrée deux fois, un état incohérent entre ce que l'interface affiche et ce que la base de données contient, une application qui plante pendant le scrutin : chacun de ces scénarios aurait compromis la légitimité de l'élection. L'irréversibilité de l'action de vote était une contrainte fonctionnelle et une contrainte d'intégrité simultanément.
Les risques étaient de deux natures. Le risque technique : garantir l'irréversibilité de manière solide, côté backend, sans se reposer uniquement sur l'interface pour empêcher une double action. Le risque temporel : le délai serré combiné à des livrables nombreux laissait très peu de marge pour les imprévus. Chaque heure mal investie se payait directement sur un livrable manquant.
-- Étapes --
Phase 1 : Analyse et architecture
Avant tout développement, les exigences ont été traduites en décisions d'architecture. La stack était fixée : Angular, Spring Boot, MySQL. L'architecture de l'application a été documentée dans un document dédié, couvrant la structure du projet frontend et backend, le schéma de la base de données V1, la description de la stack technique, et le schéma prévisionnel de la V2.
La base de données V1 a été conçue avec une volonté de simplicité maximale : une table de membres avec les informations personnelles (nom, prénom, date de naissance) et un champ booléen d'émargement. Ce champ ne peut passer qu'une seule fois de false à true. Jamais dans l'autre sens. Cette contrainte a été pensée dès la modélisation, pas ajoutée en cours de route.
Le schéma V2 a demandé une réflexion différente. Gérer plusieurs scrutins, enregistrer les votes de manière anonyme sans jamais permettre de reconstituer le lien entre un vote et son auteur : ces contraintes impliquaient une séparation claire entre la table des membres, la table des scrutins et la table des votes, avec un mécanisme d'anonymisation réfléchi. Ce schéma a été livré avec le projet sans être implémenté, comme requis par l’énoncé.
Phase 2 : Organisation et workflow Git
Un workflow Git structuré a été mis en place dès le début du projet. Une branche principale stable, des branches de fonctionnalité créées pour chaque développement significatif, des commits atomiques liés à leur contexte. Sur un projet avec un délai aussi serré, la discipline Git peut sembler superflue. C'est exactement l'inverse : un historique propre permet de revenir en arrière sans panic si quelque chose casse, et de comprendre immédiatement l'état de chaque partie du code.
Phase 3 : Développement backend
Le backend Spring Boot a été structuré en couches classiques : contrôleur, service, repository. Un seul endpoint réellement critique : celui qui enregistre l'action de vote. Cet endpoint a été conçu pour être idempotent côté réseau mais irréversible côté données : appeler deux fois l'action de vote pour le même membre retourne une erreur explicite, la base de données n'est modifiée qu'une seule fois. Cette logique a été implémentée au niveau service, pas au niveau contrôleur, pour qu'elle soit testable indépendamment du transport HTTP.
Les endpoints de lecture pour lister les membres et consulter leur statut ont été conçus pour être appelés régulièrement par le frontend sans générer de charge inutile sur la base de données.
Phase 4 : Développement frontend
L'interface Angular a été pensée pour être d'une clarté absolue. L'énoncé était explicite sur ce point : aucun doute possible sur l'utilisation de l'application. Un tableau de membres, leurs informations lisibles, une colonne d'action avec un bouton "Voter" qui devient un texte "A voté" une fois actionné. Pas de confirmation, pas de modal : l'irréversibilité est signalée visuellement par le changement d'état permanent du bouton. Le composant Angular gère l'état local de l'affichage en cohérence avec l'état persisté en base, via un service de communication avec l'API backend.
Phase 5 : Tests
Les tests ont couvert les comportements critiques de l'application. Côté backend : vérification que l'action de vote modifie correctement l'état du membre en base, vérification qu'un membre déjà émargé ne peut pas être émargé une seconde fois, vérification que la liste des membres retourne les données dans le bon format. Côté frontend : vérification que le composant affiche correctement l'état initial des membres, vérification que le bouton "Voter" déclenche bien l'appel au service et met à jour l'affichage en conséquence. Les rapports de couverture ont été générés et versionnés dans le
repository.
Phase 6 : Industrialisation
Deux Dockerfiles ont été écrits, un pour Angular et un pour Spring Boot. Le frontend a été buildé en mode production et servi via un serveur web léger. Le backend a été packagé dans une image Java minimale. Un fichier docker-compose.yml orchestre les trois services avec les bonnes variables d'environnement et les dépendances de démarrage.
La pipeline CI/CD a été configurée pour automatiser le build, l'exécution des tests et le push des images sur DockerHub. Le README documente la procédure de déploiement complète, de la récupération des images jusqu'au lancement de l'application en une commande.
-- Acteurs --
Le scénario fictif positionne Steve, référent légal de l'association InnotechFusion, comme commanditaire direct. C'est lui qui définit les besoins : une application simple, fiable, avec des assurances qualité suffisantes pour que le vote soit reconnu comme valide. Ses exigences ont servi de fil conducteur pour chaque décision technique : la simplicité de l'interface, la robustesse de l'irréversibilité, la documentation de l’architecture.
Dans la réalité de l'examen, Steve est l'énoncé, et l'évaluateur est le destinataire de toutes les décisions. Développée seule, l'application n'a bénéficié d'aucune relecture externe, d'aucun feedback intermédiaire. Chaque arbitrage technique a été fait de manière autonome, avec l'énoncé comme seul point de référence.
-- Résultats --
Pour le développeur : InnotechFusion a été l'exercice de synthèse le plus intense en termes de rapport délai/périmètre. Livrer seul, dans un temps minimal, une application fonctionnelle avec tests, Docker, pipeline CI/CD et document d'architecture : c'est une démonstration de capacité à travailler sous pression sans sacrifier la qualité sur les points qui comptent vraiment. La réflexion sur la V2 et l'anonymisation des votes a aussi été un exercice de conception avancée qui dépasse le cadre du simple développement.
Pour l'évaluation : L'ensemble des livrables a été livré dans les délais : application fonctionnelle, document d'architecture avec schéma V1 et V2, tests automatisés côté frontend et backend, images Docker, pipeline CI/CD, README de déploiement. Le projet démontre une capacité à hiérarchiser les priorités sous contrainte temporelle forte tout en maintenant les standards de qualité requis.
-- Lendemains --
Dans un futur immédiat, l'application V1 était fonctionnelle pour son usage prévu : gérer l'émargement d'un scrutin unique, dans un contexte où tous les opérateurs sont de confiance, sans authentification ni contrôle d'accès. Cette absence de sécurité est volontaire et documentée dans l'énoncé. La première évolution naturelle aurait été l'ajout d'une authentification basique pour s'assurer que seul un opérateur autorisé puisse accéder à l'application pendant le scrutin.
À distance, les schémas et l'architecture conçus pour la V2 constituent une base de réflexion réutilisable sur d'autres problématiques similaires : comment concevoir un système où des actions doivent être traçables sans être réattribuables à leur auteur, comment modéliser des scrutins multiples sans créer de redondance dans les données. Ces questions de conception avancée ont une portée bien au-delà de l'application d’émargement.
Aujourd'hui, InnotechFusion est sur le portfolio comme preuve de capacité à livrer vite et bien sous pression. C'est souvent ce que les clients et les recruteurs veulent voir : pas seulement qu'un développeur sait coder proprement quand il a le temps, mais qu'il sait aussi prioriser et livrer quand le temps manque. Ce projet est la démonstration directe de cette capacité.
-- Regard critique --
InnotechFusion est le projet sur lequel la contrainte temporelle a été la plus visible dans le résultat final. L'application fonctionne, les livrables sont complets, mais certains aspects auraient mérité plus de soin si le délai l'avait permis.
L'interface est fonctionnelle mais minimaliste au point de la sécheresse. L'énoncé demandait une interface simple, et cette contrainte a été respectée à la lettre, peut-être trop à la lettre. Une interface simple ne signifie pas une interface sans attention au détail visuel. Un peu plus de soin sur la lisibilité du tableau, sur les états visuels du bouton, sur la communication à l'opérateur de ce qui vient de se passer : ces éléments auraient pu être ajoutés sans complexifier l’usage.
La couverture de tests est suffisante mais pas exemplaire. Sur un projet où la fiabilité de l'irréversibilité est centrale, tester plus exhaustivement les cas limites côté backend (que se passe-t-il si deux requêtes de vote arrivent simultanément pour le même membre ?) aurait été justifié. Ce niveau de réflexion sur les cas de concurrence n'était pas dans le périmètre de l'examen, mais c'est exactement le type de question qu'un développeur expérimenté poserait sur une application destinée à un usage réel.
Ce qui reste, c'est la satisfaction d'avoir livré complet dans un délai que beaucoup auraient trouvé insuffisant. La hiérarchie des priorités établie en début de projet a tenu jusqu'à la fin sans dérapage. C'est une compétence aussi importante que les compétences techniques, et ce projet en est la preuve la plus directe.