Votre SaaS fonctionne avec 100 utilisateurs. Il va s’effondrer à 10 000.
Quand vous développez un SaaS, les premiers mois sont euphoriques. Le produit marche, les premiers clients arrivent, tout va bien. Puis le trafic augmente. Et un jour, tout s’effondre. Le serveur rame, les requêtes timeout, les clients appellent furieux.
Ce scénario, nous l’avons vu des dizaines de fois. Et à chaque fois, les problèmes étaient prévisibles et évitables. Mais personne n’en parle lors de la phase de développement initial, parce que “on verra quand on aura du trafic”.
Voici les vérités architecturales que j’aurais aimé qu’on me dise avant de construire mon premier SaaS.
Le choix fondamental : multi-tenant, oui, mais comment ?
La première décision architecturale d’un SaaS, c’est le modèle de multi-tenancy. Et ce choix va conditionner tout le reste.
Option 1 : Base de données partagée, schéma partagé
Tous les clients dans les mêmes tables, différenciés par un tenant_id. C’est le modèle le plus simple et le moins coûteux.
Avantages : coût d’infrastructure minimal, déploiement simple, maintenance centralisée. Inconvénients : un client bruyant impacte tous les autres, isolation des données fragile, migration complexe quand un client veut quitter.
Quand l’utiliser : SaaS B2B avec des clients de taille similaire, données peu sensibles, budget limité.
Option 2 : Base de données partagée, schémas séparés
Chaque client a son propre schéma PostgreSQL dans la même base. Un bon compromis.
Avantages : meilleure isolation, migrations par client possibles, coût raisonnable. Inconvénients : plus complexe à gérer, connexion pooling à surveiller, backup par client plus délicat.
Quand l’utiliser : SaaS B2B avec des besoins d’isolation modérés, clients de tailles variables.
Option 3 : Base de données dédiée par client
Chaque client a sa propre base de données. L’isolation maximale.
Avantages : isolation totale, performance prévisible, compliance facile, migration client triviale. Inconvénients : coût élevé, complexité opérationnelle, mises à jour à propager sur N bases.
Quand l’utiliser : SaaS avec données sensibles (santé, finance), clients enterprise avec exigences de compliance.
Notre recommandation : commencez par l’option 2 (schémas séparés). C’est le meilleur compromis entre coût, isolation et opérabilité. Vous pourrez toujours migrer les gros clients vers l’option 3 plus tard.
Les 5 points de rupture que personne n’anticipe
1. La base de données qui ne suit plus
C’est le point de rupture n°1. Votre PostgreSQL tient très bien avec 100 clients. À 1000 clients, les requêtes commencent à ralentir. À 5000, c’est l’agonie.
Les coupables habituels :
- Pas d’index sur les colonnes de filtre les plus utilisées (et surtout sur
tenant_id) - Des requêtes N+1 qui passent inaperçues avec peu de données
- Pas de read replicas pour séparer les lectures des écritures
- Des connexions qui explosent : chaque requête ouvre une connexion, et PostgreSQL a une limite
La solution : mettez en place PgBouncer pour le connection pooling dès le premier jour. Utilisez des read replicas pour les requêtes de reporting. Indexez méthodiquement. Et surtout, monitorez les slow queries en permanence.
2. Le background job qui bloque tout
Votre SaaS envoie des emails, génère des rapports, synchronise des données. Ces tâches de fond partagent les mêmes ressources que les requêtes HTTP de vos utilisateurs. Quand un client lance un export de 500K lignes, tous les autres clients rament.
La solution : séparez physiquement les workers de background des serveurs web. Utilisez des queues avec priorités. Implémentez des limites par tenant : pas plus de X jobs simultanés par client. Et surtout, rendez ces jobs idempotents pour pouvoir les retry sans risque.
3. Le stockage de fichiers qui explose
Les clients uploadent des fichiers. Beaucoup de fichiers. Et le jour où votre volume de stockage dépasse le téraoctet, les problèmes commencent : coût S3 qui grimpe, temps de listing qui explose, backups qui prennent des heures.
La solution : structurez votre stockage par tenant dès le départ (s3://bucket/tenant-id/...). Mettez en place des lifecycle policies pour archiver les vieux fichiers. Implémentez des quotas par client. Et ne stockez jamais de fichiers sur le filesystem local de vos serveurs.
4. L’authentification qui ne scale pas
Votre système d’auth maison marchait bien. Puis il faut gérer le SSO pour les clients enterprise. Puis le MFA. Puis les API keys avec des scopes. Puis l’audit logging de toutes les connexions.
La solution : utilisez un service d’authentification managé (Auth0, Clerk, ou AWS Cognito). Le temps que vous passeriez à construire et maintenir un système d’auth complet est mieux investi dans votre produit. L’auth est un problème résolu, ne le résolvez pas à nouveau.
5. Le déploiement qui fait peur
Quand vous avez 10 clients, un déploiement raté affecte 10 personnes. Quand vous en avez 10 000, c’est une autre histoire. Le stress du déploiement augmente linéairement avec le nombre de clients.
La solution :
- Déploiements blue/green : la nouvelle version tourne en parallèle de l’ancienne, le switch est instantané et réversible
- Feature flags : activez les nouvelles fonctionnalités progressivement, client par client
- Canary releases : déployez d’abord pour 1% des utilisateurs, puis 10%, puis 100%
- Rollback automatique : si les métriques se dégradent, rollback sans intervention humaine
L’architecture qui tient
Après avoir construit et scalé plusieurs SaaS, voici l’architecture que nous recommandons pour viser les 10K utilisateurs :
Frontend : SPA (React/Next.js) déployée sur CDN. Stateless, cachée, rapide.
API : API REST ou GraphQL stateless, derrière un load balancer. Horizontalement scalable. Rate limiting par tenant.
Base de données : PostgreSQL avec schémas par tenant, PgBouncer, read replicas. Redis pour le cache et les sessions.
Background jobs : Workers séparés avec Bull/BullMQ (Node.js) ou Celery (Python). Queues par priorité.
Stockage : S3 avec structure par tenant, CDN pour le serving.
Infra : Kubernetes pour l’orchestration. Autoscaling horizontal basé sur le CPU et les requêtes par seconde.
Monitoring : Datadog ou Grafana Stack. Alertes par tenant sur les métriques clés.
Les métriques à surveiller
Voici les métriques qui vous préviendront avant l’effondrement :
- P95 latency par endpoint : si ça monte, vous avez un problème avant vos utilisateurs
- Connexions DB actives : si ça approche de la limite, préparez-vous à l’orage
- Queue depth : si les jobs s’accumulent, vos workers ne suivent plus
- Error rate par tenant : un client qui génère des erreurs impacte potentiellement les autres
- Coût par tenant : si un client coûte plus cher qu’il ne rapporte, vous avez un problème business
Le piège du “on optimisera plus tard”
La pire décision que j’ai vue prendre, c’est de repousser les choix d’architecture à plus tard. “On est en mode startup, on va vite, on nettoiera après.”
Sauf que “après” arrive toujours trop tard. Quand vous avez 5000 utilisateurs qui dépendent de votre service, refactorer l’architecture de multi-tenancy est un cauchemar. C’est comme changer les fondations d’un immeuble pendant que les gens y habitent.
Investissez dans l’architecture dès le départ. Pas tout, pas la solution parfaite, mais les bonnes fondations. Schémas séparés, jobs isolés, monitoring par tenant, rate limiting. Ce sont des choix qui coûtent quelques jours au début et qui économisent des mois plus tard.
FAQ
Kubernetes est-il nécessaire pour un SaaS qui scale ?
Non, pas au début. Un simple PaaS (Railway, Render, Fly.io) suffit jusqu’à quelques milliers d’utilisateurs. Kubernetes devient pertinent quand vous avez besoin de contrôle fin sur le scaling, l’isolation des workloads, et les déploiements canary. Typiquement au-delà de 5000 utilisateurs actifs.
Comment gérer les clients “bruyants” qui consomment trop de ressources ?
Trois mécanismes : rate limiting par tenant sur l’API, quotas sur les background jobs, et monitoring par tenant pour détecter les abus. En dernier recours, migrez les gros clients vers une infrastructure dédiée avec un pricing adapté.
Faut-il construire le multi-tenant dès le jour 1 ?
Oui, c’est non négociable. Ajouter le multi-tenant après coup est exponentiellement plus complexe que de le prévoir dès le départ. Même si vous n’avez qu’un seul client, structurez votre code et vos données avec un tenant_id dès le premier commit.
Quel est le coût d’infrastructure typique pour un SaaS à 10K utilisateurs ?
Entre 2K et 8K euros par mois, selon la complexité du produit et l’intensité d’utilisation. Le poste principal est la base de données, suivi du compute et du stockage. Avec une bonne pratique FinOps, vous pouvez maintenir un coût par utilisateur inférieur à 1 euro/mois.