-- Présentation --
ShopWise est une plateforme SaaS destinée aux commerces de proximité indépendants : épiceries, librairies, salons de coiffure. L'application centralise la gestion des clients, la prise de rendez-vous et la fidélisation par points dans une interface web responsive, accessible aussi bien depuis un desktop que depuis un mobile. Un outil pensé pour réduire le temps administratif du commerçant tout en améliorant l'expérience de ses clients.
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 bloc de compétences évalué couvrait l'intégration, l'industrialisation et le déploiement du logiciel. Périmètre complet : modélisation du domaine métier, développement fullstack, tests automatisés avec couverture à 60%, pipeline CI/CD GitHub Actions, Dockerisation et documentation de déploiement. Contraintes RGPD incluses, responsive design obligatoire.
-- Objectifs --
L'objectif était de développer une solution logicielle répondant à la digitalisation des commerces de proximité, avec trois modules fonctionnels interdépendants : gestion des clients, gestion des rendez-vous avec leur cycle de vie complet, et module de fidélisation avec attribution automatique de points. Le tout dans une application scalable, multi-commerces, multi-utilisateurs, respectueuse du RGPD.
Le contexte était celui d'une startup fictive, ShopWise SAS, dont la cliente principale était Marie Dupont, propriétaire d'une épicerie locale. Ce cadre narratif posait les bases d'une vraie relation client : des besoins métier concrets, une contrainte d'accessibilité pour des utilisateurs non techniques, une exigence de simplicité d'usage sans sacrifier la richesse fonctionnelle.
L'enjeu principal était la cohérence entre les trois modules. La fidélisation dépend des rendez-vous, les rendez-vous dépendent des clients : un mauvais choix de modèle de données à l'étape de conception pouvait rendre l'implémentation de la règle métier centrale (attribution automatique de points lors de l'honoration d'un rendez-vous) beaucoup plus complexe que nécessaire. Concevoir juste dès le départ était la condition de survie du projet.
Les risques étaient de plusieurs ordres. La contrainte RGPD introduisait des exigences sur la gestion des données personnelles des clients qui devaient se traduire concrètement dans le modèle de données et les endpoints, pas rester à l'état de déclaration d'intention. Le responsive design obligatoire sur deux types d'écrans minimum imposait une discipline côté frontend Angular qui ne pouvait pas être traitée comme une afterthought. La couverture de tests à 60% sur un périmètre à trois modules demandait une stratégie de test pensée dès le développement, pas rattrapée en fin de projet. Enfin, la scalabilité multi-commerces exigeait une architecture qui ne casse pas dès qu'un second commerce est ajouté.
-- Étapes --
Phase 1 : Analyse du domaine métier et modélisation
L'analyse des user stories a commencé par identifier les entités et leurs relations. Clients avec leurs informations personnelles (nom, email, téléphone), rendez-vous avec leur cycle de vie (planifié, honoré, annulé), services associés aux rendez-vous, points de fidélité avec leur historique de transactions. La relation entre un rendez-vous et l'attribution de points a nécessité une réflexion spécifique : comment garantir qu'un rendez-vous honoré n'attribue des points qu'une seule fois, même si son statut est consulté ou rechargé plusieurs fois.
Le schéma de base de données a été conçu pour refléter cette logique : une table clients, une table rendez-vous avec un champ statut et un champ de date de service, une table transactions de fidélité reliée à la fois au client et au rendez-vous source. Cette relation directe entre la transaction et son rendez-vous d'origine permettait de détecter et d'empêcher une double attribution. Le script SQL de génération avec données de test a été livré avec le schéma.
Phase 2 : Organisation du travail et workflow Git
Les user stories ont été découpées en issues GitHub avec des labels et un ordre de traitement séquentiel. Clients en premier, rendez-vous ensuite, fidélisation en dernier. Chaque branche correspondait à une fonctionnalité isolée, chaque commit était lié à son issue. Ce workflow a permis de maintenir un état propre du repository à chaque étape et de pouvoir démontrer l'avancement à n'importe quel moment du développement.
Phase 3 : Développement backend
Le backend Spring Boot a été structuré en couches séparées pour chacun des trois modules. Le module clients expose les endpoints de création, consultation et mise à jour des fiches clients. Le module rendez-vous gère la création avec saisie du client, de la date, de l'heure et du service, la consultation avec filtrage dynamique par date, statut ou client, et la mise à jour du statut. Le module fidélisation expose le solde de points d'un client et l'historique de ses transactions.
La règle métier critique a été implémentée au niveau service : lorsqu'un rendez-vous passe au statut "honoré", le service vérifie qu'aucune transaction de points n'existe déjà pour ce rendez-vous avant d'en créer une nouvelle. Cette vérification en base de données est la vraie garantie d'unicité, indépendamment de l'interface ou du nombre d'appels à l'endpoint.
La connexion client a été implémentée selon la user story dédiée : un commerçant crée le compte du client, le client peut ensuite se connecter avec ses identifiants pour consulter ses informations et son solde de points. Deux profils distincts, deux vues distinctes.
Phase 4 : Développement frontend
L'interface Angular a été construite avec une attention particulière au responsive design. Chaque composant a été pensé pour s'adapter à deux contextes d'usage : le commerçant sur son desktop qui gère son planning et sa base clients, et le client sur son mobile qui consulte ses points et ses rendez-vous. Les breakpoints Angular Material ou CSS natif ont été utilisés pour adapter la mise en page sans dupliquer les composants.
Le tableau de bord des rendez-vous avec son système de filtrage dynamique a demandé une implémentation soignée côté Angular : les filtres par date, statut et client devaient fonctionner en combinaison, avec un retour visuel immédiat et des appels API optimisés pour ne pas surcharger le backend à chaque frappe dans un champ de recherche.
Phase 5 : Tests
La stratégie de test a priorisé les règles métier critiques. Côté backend : test de l'attribution automatique de points lors du passage au statut "honoré", test de l'impossibilité de double attribution, test du filtrage des rendez-vous par paramètres combinés, test de la création d'un client et de sa consultation. Côté frontend : test des composants de liste et de formulaire, test de l'intégration des services Angular avec les mocks HTTP.
Les rapports de couverture ont été générés pour les deux couches et versionnés dans le repository. Le seuil de 60% sur les instructions et les branches a été atteint avec une stratégie délibérée : couvrir les chemins critiques en priorité plutôt que d'optimiser le taux en testant ce qui était trivial.
Phase 6 : Industrialisation
Deux Dockerfiles ont été écrits. Le frontend Angular compilé en production est servi via un serveur léger. Le backend Spring Boot est packagé dans une image Java minimale. Le `docker-compose.yml` orchestre les trois services (frontend, backend, base de données relationnelle) avec les variables d'environnement nécessaires, les networks isolés et les dépendances de démarrage.
La pipeline GitHub Actions automatise le build Maven et npm, l'exécution des tests avec génération des rapports de couverture téléchargeables en artefacts, et le push des images Docker sur DockerHub. Les issues GitHub ont été maintenues à jour tout au long du projet, chaque statut reflétant l'état réel d'avancement.
-- Acteurs --
Le scénario met en scène deux profils utilisateurs principaux : Marie Dupont, commerçante et utilisatrice principale de l'interface de gestion, et ses clients qui accèdent à une vue simplifiée de leurs informations et de leurs points. Ces deux profils ont des besoins distincts, des niveaux de compétence technique différents, et des contextes d'usage différents.
ShopWise SAS, la startup éditrice, joue le rôle du Product Owner dans ce scénario : c'est elle qui définit la vision produit, les contraintes de scalabilité multi-commerces et les exigences RGPD. Ces contraintes organisationnelles ont influencé directement les décisions d'architecture, notamment la séparation claire des données par commerce et la gestion des consentements clients.
Dans la réalité de l'examen, le seul acteur humain reste le développeur. Les décisions ont été prises seul, les arbitrages assumés seul, les livrables produits seul. Cette configuration renforce la valeur démonstrative du projet : chaque fonctionnalité livrée est le résultat d'un effort individuel non dilué.
-- Résultats --
Pour le développeur : ShopWise a été l'occasion de travailler pour la première fois sur un domaine métier avec une vraie logique de fidélisation et de gestion de planning. Comprendre les dépendances entre modules, modéliser une règle métier complexe (l'attribution automatique de points) de manière fiable, et la tester correctement : ce niveau de réflexion dépasse la simple implémentation technique. La contrainte RGPD a aussi forcé à penser la gestion des données personnelles comme une exigence de conception, pas comme une contrainte administrative.
Pour l'évaluation : L'ensemble des livrables a été livré : schéma de base de données, script SQL, code source frontend et backend, rapports de couverture frontend et backend, Dockerfiles, docker-compose.yml, pipeline CI/CD configurée avec artefacts téléchargeables, README de déploiement, tableau de suivi des issues GitHub. Le projet démontre une capacité à modéliser un domaine métier réaliste, à implémenter des règles métier fiables et à industrialiser le tout dans les standards attendus d'un expert en ingénierie logicielle.
-- Lendemains --
Dans un futur immédiat, l'application était fonctionnelle mais sans authentification sécurisée. L'énoncé excluait explicitement JWT et la sécurisation avancée. Sur une vraie plateforme SaaS multi-commerces, c'est la première évolution indispensable : un commerçant ne doit pas pouvoir accéder aux données d'un autre, un client ne doit consulter que ses propres informations. Spring Security avec une gestion JWT par rôle était la suite logique immédiate.
À distance, ShopWise a posé des bases réutilisables sur la modélisation de domaines métier avec des règles d'intégrité complexes. La pattern de vérification d'unicité avant insertion, appliquée à l'attribution de points, est un schéma qui revient régulièrement dans des contextes différents : transactions financières, allocations de ressources, tout système où une action ne doit se produire qu'une seule fois malgré des appels potentiellement multiples.
Aujourd'hui, ShopWise représente sur le portfolio le projet le plus proche d'une vraie application métier. Les commerces de proximité sont un marché réel, le besoin de digitalisation est documenté, et la stack utilisée (Angular, Spring Boot, MySQL) est exactement celle que l'on retrouve dans les projets d'entreprise. Dans le cadre du projet de société de développement logiciel, ce type d'application représente une cible commerciale directe : des TPE et PME qui ont besoin d'outils sur mesure sans les prix des grands éditeurs.
-- Regard critique --
ShopWise est le projet sur lequel la réflexion métier a été la plus poussée, et c'est aussi celui qui révèle le plus clairement ce qui manque encore dans la pratique.
La gestion du RGPD est restée trop superficielle. Respecter le RGPD ne se limite pas à ne pas stocker d'informations inutiles. Cela implique un droit à l'effacement, un droit d'accès aux données personnelles, une traçabilité des consentements. Ces aspects n'ont pas été implémentés, en partie parce que l'énoncé ne les détaillait pas explicitement. Mais un développeur consciencieux aurait dû les identifier et au moins les documenter comme évolutions nécessaires avant toute mise en production réelle.
Le responsive design a été traité correctement mais sans finesse. L'application fonctionne sur mobile et desktop, les deux types d'écrans requis sont couverts. Ce qui manque, c'est une vraie réflexion sur l'expérience mobile : les interactions tactiles, la taille des zones cliquables, la hiérarchie de l'information sur un petit écran. Cocher la case "responsive" et concevoir une vraie expérience mobile sont deux choses différentes.
Ce projet reste celui dont le domaine métier est le plus inspirant pour la suite. Construire des outils pour des commerces indépendants, c'est avoir un impact concret et mesurable sur des personnes réelles. Cette dimension, absente d'un projet académique, sera au cœur des projets de la société en construction.