Architecture #
Vue d’ensemble #
Navigateur
↓
Nginx :8080
├── SPA React / TypeScript / Vite / Material UI
└── API Symfony / PHP-FPM
├── PostgreSQL
├── Redis → Symfony Messenger
├── stockage documentaire privé
└── SMTP / Gmail API / Microsoft GraphNginx est l’unique point d’entrée du compose. PostgreSQL est la source de vérité. Redis utilise l’AOF et transporte les messages asynchrones.
Flux sécurisé #
Symfony vérifie signature JWT, session, activité du compte et rôle. Le contrôleur résout chaque relation dans l’organisation courante ; les repositories filtrent les lectures par tenant. Le journal d’audit enregistre les mutations sensibles.
Rôles et documents #
SUPER_ADMIN → ADMIN → RISK_MANAGER → VIEWER. AUDITOR et ACTION_OWNER héritent de la lecture. Les documents ajoutent les ACL READ, EDIT et MANAGE.
Règles d’évolution #
Toute ressource doit filtrer par organisation, revalider les relations, autoriser côté API, journaliser les mutations, migrer le schéma et fournir des tests tenant/RBAC.
Flux asynchrones #
Le backend publie les emails dans Redis ; le worker Messenger les consomme et sélectionne SMTP, Gmail ou Microsoft Graph selon le tenant. Le scheduler exécute expirations d’acceptations et rappels de revue. Une panne du worker n’empêche pas nécessairement la mutation métier : surveillez la file.
Réseau #
Nginx expose 8080. PostgreSQL, Redis, PHP-FPM et Vite restent privés au réseau Docker. En production, un reverse proxy externe termine TLS. N’exposez jamais directement base, Redis ou PHP-FPM.
Évolutivité et reprise #
Les services applicatifs peuvent être reconstruits depuis les images ; les données résident dans PostgreSQL, Redis, documents et clés JWT. Toute mise à l’échelle doit préserver sessions, transport asynchrone et accès au stockage partagé.
Contrôles d’architecture #
Vérifiez santé des services, migrations, isolation tenant, autorisations API, volumes persistants, traitement Messenger, scheduler et terminaison HTTPS après chaque livraison.