L'architecture d'un SaaS n'est pas une décision technique abstraite. C'est une série de choix qui conditionnent votre vélocité de développement, vos coûts d'infrastructure, votre capacité à scaler — et votre dette technique future. Ces décisions se prennent en début de projet. Elles sont difficiles à défaire ensuite.
1. Multi-tenant ou single-tenant ?
C'est la décision fondatrice. Dans un modèle multi-tenant, tous vos clients partagent la même infrastructure : une base de données, un ensemble de serveurs, une instance applicative. Vous isolez les données logiquement (par identifiant client). Dans un modèle single-tenant, chaque client a sa propre instance.
Le multi-tenant est la norme pour les SaaS B2C et la majorité des SaaS B2B : coûts d'infrastructure divisés, déploiements unifiés, maintenance centralisée. Le single-tenant s'impose quand la réglementation l'exige (données de santé, défense) ou quand le client a un pouvoir de négociation suffisant pour l'exiger contractuellement.
Erreur fréquente : commencer single-tenant "pour simplifier" et tenter de migrer vers le multi-tenant à 10 000 clients. C'est un projet de 12 à 18 mois que personne ne veut faire.
2. Monolithe ou microservices ?
La réponse honnête : pour la majorité des SaaS en phase de démarrage, le monolithe est le bon choix. Les microservices introduisent une complexité opérationnelle (orchestration, observabilité distribuée, gestion des échecs en cascade) que des équipes de 2 à 5 développeurs ne peuvent pas absorber productivemennt.
Partez sur un monolithe modulaire : code bien organisé en domaines fonctionnels, avec des interfaces claires entre modules. Quand un module spécifique devient un goulot d'étranglement — en termes de performance ou de vélocité d'équipe — c'est le moment de l'extraire en service indépendant. Pas avant.
3. Stratégie d'isolation des données multi-tenant
Si vous partez sur le multi-tenant, trois patterns existent :
- Schema isolation : un schema SQL par client dans la même base. Isolation forte, migration par client possible, mais complexité des requêtes et des migrations.
- Row-level isolation : toutes les tables ont une colonne
tenant_id. Plus simple, plus fragile si un bug oublie le filtre tenant. - Database isolation : une base par client. Isolation maximale, coûts d'infrastructure élevés.
Pour la majorité des cas, le row-level avec des Row Level Security (RLS) au niveau de la base de données (PostgreSQL le supporte nativement) offre le meilleur équilibre.
4. Authentification et gestion des identités
Ne codez pas votre propre authentification. La gestion des mots de passe, des tokens, des sessions, des SSO, du MFA — c'est un domaine de sécurité complexe où les erreurs sont coûteuses. Utilisez un service d'identité éprouvé (Auth0, Clerk, Supabase Auth) et concentrez-vous sur votre domaine métier.
Pensez dès le départ aux besoins enterprise : SSO SAML, provisionnement SCIM, gestion des rôles et permissions granulaires. Implémenter le RBAC (Role-Based Access Control) après le fait est une refactorisation majeure.
5. Observabilité dès le jour 1
L'observabilité n'est pas optionnelle — c'est ce qui vous permet de savoir ce qui se passe dans votre système en production. Trois piliers : logs structurés (JSON, avec contexte : tenant_id, user_id, request_id), métriques (temps de réponse, taux d'erreur, saturation des ressources), et tracing distribué.
Ajouter l'observabilité après coup sur un système de plusieurs dizaines de milliers de lignes de code est un projet à part entière. Brancher un outil comme Datadog, New Relic, ou une stack open source (Prometheus + Grafana + Loki) dès le début coûte quelques jours — et vous en fait économiser des semaines lors du premier incident de production sérieux.
Ces décisions ne sont pas réversibles facilement
L'équipe de Valtieri construit des SaaS depuis plusieurs années. Ces cinq décisions font partie du cadrage que nous faisons systématiquement avec nos clients en début de projet. Si vous démarrez un produit ou héritez d'une architecture à questionner, parlons-en.