Étude de cas principale · Plateforme métier modulaire
DigCore
Un socle ERP Full-Stack modulaire réunissant interfaces multilingues, services Spring Boot et autorisation en couches pour des parcours métier sensibles aux rôles.
01
Le défi
Réunir plusieurs capacités métier dans une plateforme cohérente tout en gardant explicites et maintenables la visibilité dans l’interface, l’authentification JWT, le RBAC, la hiérarchie des autorités, les garanties au niveau service et le support LTR/RTL.
02
Ma contribution
À travers les frontières du produit.
- Développement d’interfaces produit avec Next.js, React et TypeScript.
- Contribution aux services Java 21 et Spring Boot 3 exposés via des API REST.
- Mise en œuvre de parcours multilingues avec prise en charge LTR et RTL.
- Développement de parcours authentifiés par JWT et adaptés aux rôles, en distinguant la visibilité dans l’interface de l’application des règles backend.
- Centralisation de l’autorisation au niveau service avec un aspect Spring AOP pour les opérations utilisateurs, pays et paramètres.
- Ajout d’une couverture Spring Boot et JUnit ciblée sur les chemins hiérarchiques autorisés et refusés.
03
Points forts techniques
Des règles de sécurité explicites.
Le backend vérifié montre comment l’authentification, l’autorisation, les garanties métier, les tests et la localisation coopèrent sans être confondus.
Sécurité en couches
JWT établit la requête authentifiée, Spring Security applique les règles de route et de méthode, puis un aspect Spring AOP exécute les contrôles métier avant les opérations de service protégées.
Authentification, RBAC, hiérarchie, contrôles de service et interface adaptée aux rôles restent des couches distinctes.Administration hiérarchique
La création, la mise à jour et la suppression d’utilisateurs comparent l’autorité la plus élevée de l’utilisateur connecté aux rôles affectés ou ciblés. L’API ne peut ni créer un SUPER_ADMIN, ni lui retirer ce rôle, ni promouvoir un compte normal vers ce niveau.
Le même aspect protège les changements de pays, certaines lectures de pays et les paramètres ; ceux-ci sont rechargés après une mise à jour réussie.Vérification ciblée
Une suite Spring Boot/JUnit dédiée couvre les scénarios utilisateurs et pays autorisés comme refusés, notamment les tentatives sur un niveau égal ou supérieur et les protections SUPER_ADMIN.
18 tests ciblés réussis, sans échec, erreur ni test ignoré.Communication internationalisée
L’interface prend en charge l’anglais, le français et l’arabe en LTR/RTL. Les e-mails de vérification backend utilisent la locale de la requête, des bundles de messages, des modèles Thymeleaf et un envoi HTML asynchrone.
Les corps d’e-mail sont localisés en anglais et en français ; l’arabe surcharge actuellement un objet et utilise sinon le bundle par défaut.- Requête authentifiée
- Spring Security
- Contexte de sécurité
- Rôles et autorités
- Contrôle Spring AOP
- Hiérarchie et opération
- Couche service
- Créer un utilisateur
- Modifier un utilisateur
- Supprimer un utilisateur
- Accès aux pays
- Modifier les paramètres
04
Vue du système
Les parties qui doivent fonctionner ensemble.
Un socle réutilisable avec contrôle d’accès en couches, limites de privilèges explicites, livraison multilingue et parcours d’administration testés.
Interface Next.js et React avec parcours adaptés aux rôles
Authentification des requêtes par JWT et Spring Security
Services REST Spring Boot avec persistance JPA
Contrôles hiérarchiques Spring AOP à la frontière des services
05
Preuves visuelles
Uniquement des éléments approuvés.
Les captures produit approuvées présentent des données de démonstration représentatives et un périmètre d’interface vérifié.
06
Preuves et limites
Ce qui peut être vérifié.
- Projet documenté dans le CV et dans l’expérience actuelle chez DigCoder.
- Le backend privé a été inspecté localement pour vérifier l’aspect, la configuration de sécurité, la hiérarchie des autorités, les opérations de service protégées et le parcours de localisation des e-mails.
- RoleValidationAspectTest contient 18 tests ciblés ; l’exécution vérifiée s’est terminée sans échec, erreur ni test ignoré.
- Produit privé : aucun dépôt public ni lien de production n’est divulgué.
- Quatre captures produit approuvées documentent le tableau de bord, l’administration des utilisateurs, l’espace profil et l’expérience arabe en RTL.
Les captures publiées présentent des données de démonstration représentatives ; les détails du produit restent limités aux informations vérifiées et non confidentielles.