Structurer un système administratif Spring Boot et Angular

Vu de l'extérieur, un système administratif paraît simple : quelques formulaires, quelques tableaux, un écran de connexion. La difficulté ne vient jamais des écrans — elle vient des règles qui se trouvent en dessous, et du fait que ces règles changent selon la personne connectée.

Voici un retour court sur la façon dont j'ai structuré le système administratif et RH sur lequel j'ai travaillé chez LANAI SARL, avec Angular côté interface et Spring Boot côté services.

Placer les règles dans le backend

La première décision a été d'arrêter d'exprimer les règles métier dans l'interface. Un bouton désactivé est une indication, pas une garantie. Chaque contrainte — qui peut créer un enregistrement, quel département un utilisateur peut modifier, si une entrée de planning entre en conflit avec une autre — a été implémentée comme une vérification au niveau des services Spring Boot.

L'interface continue de masquer ce qu'un utilisateur ne peut pas faire, car un écran rempli d'actions interdites est une mauvaise expérience. Mais l'interface est désormais une projection des règles, pas leur propriétaire.

Modéliser la permission avant la fonctionnalité

L'accès par rôles devient simple quand les rôles sont conçus en premier. Concrètement, cela signifiait répondre à trois questions avant d'écrire un endpoint :

• Quels rôles peuvent l'appeler ?
• Quel sous-ensemble de données chaque rôle peut-il voir ?
• Que deviennent les données lorsqu'un rôle change ?

La troisième question est celle que l'on saute, et c'est elle qui produit des enregistrements incohérents six mois plus tard.

Garder les fichiers hors de la base de données

Les documents étaient stockés sur un serveur dédié via MinIO plutôt qu'en blobs dans MySQL. La base conserve la référence et les métadonnées ; le stockage objet conserve les octets. Les sauvegardes sont plus rapides, le schéma reste lisible, et servir un fichier n'entre plus en concurrence avec les requêtes qui font tourner l'application.

Conteneuriser tôt, pas à la fin

Docker faisait partie du workflow dès le départ, et non d'une étape de déploiement ajoutée à la fin. Chaque service tournait dans son propre conteneur avec sa configuration, ce qui a rendu les frontières entre services réelles plutôt que théoriques. Quand une frontière est imposée par un conteneur, elle cesse de fuir.

Ce que je garde

Trois habitudes se sont transmises à tout ce que j'ai construit depuis :

1. Les règles appartiennent à l'endroit où elles ne peuvent pas être contournées.
2. Les permissions font partie du modèle de données, pas d'une décoration posée au-dessus.
3. Les décisions d'infrastructure prises tôt coûtent moins cher que les mêmes décisions prises sous la pression d'une échéance.