Architecture de référence : SaaS multi-tenant sur AWS

Cette architecture de référence n'est pas un projet client : c'est le socle que nous utilisons comme point de départ lorsqu'un éditeur nous confie la conception d'un SaaS B2B. Elle est maintenue comme un projet démonstratif et sert de base de discussion sur les choix techniques.

Le cas modélisé est celui d'un logiciel de gestion vendu par abonnement à des entreprises, où chaque entreprise cliente (tenant) dispose de ses propres utilisateurs, données et paramètres, tout en partageant la même infrastructure.

L'objectif est de montrer une manière éprouvée de répondre aux questions que tout éditeur SaaS se pose : comment isoler les données, comment gérer les abonnements, comment déployer sans interruption et comment garder la maîtrise des coûts.

Un SaaS multi-tenant doit garantir qu'aucun client ne peut voir les données d'un autre, tout en mutualisant les serveurs, la base de données et les déploiements. Les erreurs d'isolation sont les plus graves et les plus difficiles à détecter a posteriori.

Il doit aussi relier la facturation aux droits d'accès (essai, formule, quotas, suspension) et pouvoir être livré plusieurs fois par semaine sans interrompre le service pour l'ensemble des clients.

Le front est une application Next.js servie derrière un CDN, avec rendu côté serveur pour les pages publiques et application React pour l'espace client.

L'API est développée en Java avec Spring Boot ; chaque requête porte l'identifiant du tenant extrait du jeton d'authentification, propagé jusqu'à la couche de données.

PostgreSQL sur Amazon RDS héberge toutes les données dans une base partagée ; la sécurité au niveau des lignes (row-level security) applique un filtre par tenant directement dans la base, en plus des vérifications applicatives.

Redis sert de cache, de stockage de sessions et de file pour les tâches asynchrones (envoi de courriels, exports, webhooks).

Les conteneurs Docker de l'API et du front sont déployés sur Amazon ECS ; l'ensemble (réseau, ECS, RDS, Redis, secrets, journaux) est décrit en Terraform.

GitHub Actions construit les images, exécute les tests (y compris les tests d'isolation entre tenants), applique les migrations et déploie en blue/green.

L'identifiant de tenant est la colonne vertébrale de l'architecture. Il est fixé à l'authentification, transmis dans le contexte de chaque requête et positionné comme variable de session PostgreSQL ; les politiques de sécurité au niveau des lignes refusent toute lecture ou écriture qui ne correspond pas. Une requête qui oublierait le filtre côté application ne renvoie donc rien, plutôt que les données d'un autre client.

La facturation est modélisée dans le domaine métier (formules, abonnements, périodes d'essai, quotas) et un adaptateur traduit ces notions vers Stripe. Les webhooks de paiement sont traités de manière idempotente et mettent à jour les droits d'accès du tenant ; changer de prestataire revient à écrire un autre adaptateur.

Les migrations de base de données sont écrites pour rester compatibles avec la version précédente de l'API, ce qui permet un déploiement blue/green : la nouvelle version est démarrée à côté de l'ancienne, vérifiée, puis reçoit le trafic. Le retour arrière consiste à rebasculer le trafic.

L'observabilité est intégrée dès le départ : journaux structurés portant l'identifiant du tenant, métriques par tenant, traces distribuées et alertes sur les erreurs et la latence. Les coûts AWS sont étiquetés par composant pour être suivis.