Trois clients sur la même application, la même base, le même cron nocturne. Le quatrième lance un import CSV géant ; les autres voient des timeouts. Personne n'avait prévu l'isolation du bruit — seulement « on agrandira le serveur ».
Un SaaS multi-tenant partage infrastructure et code entre clients. C'est économique — mais sans isolation des données, des performances et de l'exploitation dès le début, chaque gros client devient un risque pour les autres. Reporter l'isolation « jusqu'au contrat entreprise » signifie souvent refactoriser sous pression après l'incident.
Trois niveaux d'isolation
| Niveau | Isolation | Coût opérationnel |
|---|---|---|
| Logique (identifiant client) | Bonne si code rigoureux | Faible |
| Schéma base par client | Meilleure séparation | Moyen |
| Instance ou cluster par client | Forte (entreprise) | Élevé |
Commencez par l'isolation logique avec des tests automatisés prouvant qu'un client A ne lit jamais les données d'un client B — non négociable. Chaque requête sans filtre client est une faille en attente.
Hébergement : choix réalistes
Évitez le mutualisé type WordPress : processus partagés, ressources opaques, pas de workers dédiés. Le minimum sérieux : VPS ou cloud avec ressources dédiées, base managée ou PostgreSQL/MySQL réglée, environnement de préproduction distinct (pas un clone par client), sauvegardes testées avec possibilité de restauration par client si votre modèle le permet.
Pour les pics imprévisibles, voir marketplace. L'hébergement marque blanche reste hors périmètre sauf compétence opérationnelle avérée.
Données, RGPD et gros clients
PostgreSQL permet la sécurité au niveau des lignes ou des équivalents applicatifs stricts. Prévoyez export et suppression par client pour les droits des personnes. Un DPA par client B2B est la norme. Sur la résidence des données, un gros client français peut exiger la France — comparez données France et pool Union européenne. Anticipez un client entreprise sur infrastructure dédiée sans réécrire toute l'application.
Surveillance par client
Mesurez au minimum les requêtes lentes par identifiant client, la charge processeur et entrée-sortie par compte, le taux d'erreurs 5xx par client, et la profondeur des files de tâches par tenant. Alertez avant que le voisin se plaigne — pas quand le contrat entreprise est déjà menacé.
Le sommet : le multi-tenant retarde l'isolation jusqu'à la grosse facture
Décider et avancer sans angle mort
Modélisez d'abord les clients avec un identifiant présent partout et des tests de fuite automatisés. Choisissez un hébergement VPS ou cloud — pas de mutualisé. Mettez des limites de débit et des quotas dès la première version commerciale. Déployez une surveillance par client avec un runbook pour le « client bruyant ». Documentez enfin le plan entreprise (schéma ou cluster dédié) avant qu'un prospect ne le demande en urgence. Comparez l'infrastructure via le comparateur et les guides.
Questions fréquentes
Multi-tenant dès le MVP ?
Oui avec identifiant client strict et tests d'isolation — un schéma partagé mal conçu coûte cher à corriger plus tard.
Base par client ou partagée ?
Partagée avec identifiant client pour le B2B PME ; schéma ou instance si conformité ou très gros comptes.
Mutualisé ou VPS ?
VPS ou cloud dès plusieurs clients payants — le mutualisé WordPress-like est inadapté.
Client bruyant ?
Quotas, limites de débit, surveillance par compte, contrat autorisant limitation ou montée de gamme.
La prochaine fois qu'on ajoutera un tenant sans tests d'isolation, rappelez-vous : le CSV d'un client est déjà un incident pour les autres.