Comparez ressources mutualisées et séparées dans les données, tâches et opérations. Rendez l’isolation explicite au-delà de la seule connexion utilisateur.
Une architecture multi-tenant permet à un service d’accueillir plusieurs organisations. La question essentielle est de savoir où les ressources sont partagées et comment accès et charge restent maîtrisés. Authentifier un appelant ne détermine pas à lui seul les ressources d’organisation auxquelles il peut accéder. L’isolation doit couvrir tous les chemins, y compris support et traitements différés.
Choisir les frontières selon les besoins
| Modèle | Avantage possible | Question opérationnelle |
|---|---|---|
| Tables partagées et identifiant client | Infrastructure commune efficace | Comment imposer le filtrage partout ? |
| Schémas ou bases séparés | Frontière de données plus distincte | Comment gérer migrations et sauvegardes ? |
| Ressources de déploiement séparées | Capacité et configuration indépendantes | Comment exploiter une flotte croissante ? |
Ces modèles peuvent se combiner. Un service peut mutualiser son plan de contrôle et isoler une charge particulière. Documentez la raison de la frontière et sa sélection à l’arrivée du client. Des bases séparées ne garantissent pas l’isolation si identifiants applicatifs, outils de support ou exports franchissent les frontières sans contrôle.
Transporter un contexte fiable
Résolvez appartenance et permissions côté serveur. Un identifiant d’organisation reçu dans la requête ne prouve pas le droit d’accès. Incluez le contexte dans les tâches, clés de cache, chemins de fichiers et journaux, puis vérifiez-le au point d’accès à la ressource. Examinez séparément les opérations administratives transversales et limitez-les à des usages explicites.
- Créer des comptes dans deux organisations de test avec des données distinctes.
- Vérifier lectures, modifications, exports et pièces jointes selon les rôles.
- Exercer tâches différées et cache après changement de contexte.
- Tracer acteur, organisation et motif des actions de support.
- Tester restauration et suppression selon la frontière choisie.
Examiner aussi l’isolation de charge
Un import volumineux ou un rapport coûteux peut dégrader le service des autres clients sans exposer de données. Définissez quotas, ordonnancement ou séparation si nécessaire, puis mesurez sous une charge représentative. Maintenez un inventaire des organisations et une procédure de provisionnement versionnée pour éviter les exceptions invisibles. Réexaminez l’architecture lorsque les engagements ou les charges changent.
Conservez les preuves de vérification par chemin et par rôle. Une seule requête réussie entre deux comptes ne démontre pas toute l’isolation du système.
- Développement SaaS
- Fonctionnalités d’un MVP SaaS : un parcours client complet
- Due diligence technique pour une acquisition SaaS
Questions fréquentes
Un identifiant client dans chaque table suffit-il ?
Non. Requêtes, tâches, cache, fichiers et administration doivent utiliser un contexte fiable et contrôlé.
Chaque client doit-il avoir une base ?
Pas toujours. Choisissez selon isolation, reprise, charge et capacité d’exploitation.
La séparation remplace-t-elle l’autorisation ?
Non. Application et opérations nécessitent toujours des droits et identifiants adaptés.
Comment tester l’isolation ?
Avec des comptes autorisés dans des organisations distinctes et des vérifications de lecture, écriture, export, tâches et administration.
Qu’est-ce qu’un voisin bruyant ?
Un client qui consomme les ressources partagées au point de dégrader les autres. Il peut nécessiter des limites même sans fuite de données.
Transformons votre besoin en périmètre réalisable
Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.
Pour aller plus loin
Fonctionnalités d’un MVP SaaS : un parcours client complet
Définissez le MVP selon la valeur client, l’isolation et l’exploitation. Reportez les variantes sans laisser le premier parcours incomplet.
Due diligence technique pour une acquisition SaaS
Examinez isolation, facturation, coûts d’exploitation et dépendances de transfert. Reliez les preuves techniques au projet d’acquisition et d’intégration.
Intégrer les abonnements Stripe : checklist de livraison SaaS
Reliez les événements de facturation à une politique d’accès explicite. Testez renouvellement, échecs, doublons et reprise avant la facturation réelle.