Une API modulaire et sécurisée par défaut

Le backend livré avec une application Maleus n'est pas une collection de routes générées au fil de l'eau. Il part d'un monolithe modulaire : une seule unité simple à déployer, découpée en modules fonctionnels qui isolent les responsabilités, les données et les dépendances.

La sécurité commence par une route fermée

Un garde d'authentification s'applique globalement. Chaque route doit déclarer explicitement l'un des deux contrats suivants :

• @Auth, avec l'action ou la capability nécessaire ;
• @PublicApi, pour une route volontairement publique.

Une route sans configuration est refusée. Une route marquée à la fois privée et publique l'est aussi. Cette règle transforme un oubli de sécurité en erreur visible au lieu d'exposer silencieusement un endpoint.

Les entrées sont validées par des schémas Zod. Les mêmes contrats alimentent la documentation OpenAPI et les clients générés. Les erreurs HTTP suivent un format commun, les cookies sont signés, les corps de requête sont bornés et les routes SDK cross-origin sont isolées dans une liste explicite sans credentials navigateur.

Un monolithe modulaire, pas un bloc indifférencié

Une fonctionnalité suit généralement quatre zones :

1. presentation reçoit et valide les requêtes ;
2. services porte les cas d'usage et les règles métier ;
3. data contient tables et repositories ;
4. tests verrouille le comportement attendu.

Le noyau transversal regroupe l'identité, les tenants, les groupes, la sécurité, la base de données, le SSO et les clés API. Les domaines métier vivent dans leurs propres modules. Les clients d'infrastructure, comme PostgreSQL, RabbitMQ, S3 ou une API tierce, sont injectés derrière des interfaces.

Cette séparation permet de remplacer une intégration, de tester un service sans son fournisseur réel et de faire évoluer un module sans répandre sa logique dans toute l'application.

01Contrat HTTPAuthentification, validation, actions et erreurs normalisées

02Cas d'usageRègles métier et orchestration dans chaque module fonctionnel

03DonnéesRepositories tenant-aware, transactions et migrations

04InfrastructurePostgreSQL, S3, RabbitMQ, Redis et APIs tierces

Des contrats qui traversent toute la chaîne

Le schéma d'une requête ne sert pas seulement à rejeter une valeur invalide. Il devient un point de raccord entre :

• le contrôleur HTTP ;
• la validation d'exécution ;
• le contrat OpenAPI ;
• le client TypeScript ;
• les tests de contrat.

Pour ajouter une opération métier, on décrit donc son entrée, sa sortie, son action de sécurité et son module propriétaire. Le client frontend consomme ensuite une API typée plutôt que des URL et des objets reconstruits à la main.

Des primitives réutilisables autour des modules

Le socle fournit aussi des bibliothèques partagées pour les besoins qui reviennent d'une application à l'autre :

• authentification et rotation des sessions ;
• SSO OIDC et SAML ;
• chiffrement applicatif ;
• stockage S3 et URLs présignées ;
• transactions, repositories et migrations ;
• logs structurés et erreurs normalisées.

Ces briques accélèrent un nouveau domaine, sans décider à sa place du modèle métier, de la rétention ou des règles d'accès.