Architecture SaaS : isoler les clients et préparer l’exploitation dès le départ

Définir le client technique et ses frontières

Dans un service SaaS, plusieurs utilisateurs peuvent appartenir à une même organisation cliente. Cette organisation forme souvent un tenant, c’est-à-dire une unité logique d’isolation. Microsoft distingue explicitement cette notion de celle d’utilisateur dans sa documentation d’architecture multitenant. Avant de choisir une base ou un hébergeur, décrire cette frontière et les ressources qu’elle couvre.

Un utilisateur peut appartenir à plusieurs organisations, avec des droits différents. Il faut donc distinguer son identité, l’organisation active et l’action autorisée. La sélection d’un espace dans l’interface ne constitue pas une preuve d’autorisation. Le serveur doit vérifier le contexte sur chaque opération, y compris les exports, la recherche et les tâches exécutées en arrière-plan.

Pour approfondir : Microsoft — architecture multitenant

Choisir un modèle d’isolation proportionné

Plusieurs stratégies existent : partager les tables avec un identifiant de client, séparer les schémas ou bases, ou isoler davantage l’infrastructure. Chacune déplace les coûts et les responsabilités. Un modèle mutualisé facilite certaines opérations communes mais exige une discipline rigoureuse de filtrage. Une séparation plus forte multiplie parfois les déploiements et les migrations à exploiter.

Le choix doit partir des exigences réelles : niveau d’isolation attendu, restauration par client, personnalisation, volume et compétences disponibles. Écrire ces contraintes avant le choix permet de comparer les options. Il faut aussi envisager le passage d’un petit client à un client très consommateur, sans supposer que tous auront un comportement comparable.

Construire les contrôles d’accès dans plusieurs couches

L’application vérifie les actions autorisées et la couche de données peut ajouter une protection complémentaire. PostgreSQL propose des politiques de sécurité par ligne. Sa documentation précise toutefois que certains rôles, dont ceux disposant de privilèges particuliers, peuvent contourner ces politiques. Leur présence ne suffit donc pas : le rôle réellement utilisé par l’application doit être vérifié.

Les tests doivent essayer de lire, modifier, rechercher et exporter les données d’un autre client. Couvrir également les chemins moins visibles : liens de téléchargement, notifications, cache, outils d’administration et journaux. Un contrôle présent sur la page principale mais absent d’un export laisse une faille dans le parcours complet.

Pour approfondir : PostgreSQL — politiques de sécurité par ligne

Séparer traitement interactif et travaux longs

Un import volumineux ou une génération de rapport peut être confié à une file de traitement pour éviter de bloquer la requête utilisateur. Le travail doit conserver son identité de client, ses permissions et son état. Prévoir les reprises : une interruption peut provoquer la répétition d’une opération qui avait déjà produit un effet.

L’idempotence aide à éviter les doublons, mais elle doit être conçue autour de l’opération métier. Enregistrer une clé avant un paiement et marquer correctement son résultat n’est pas équivalent à relancer aveuglément une fonction. Définir les états possibles, les transitions et les procédures de correction permet au support de comprendre ce qui s’est réellement passé.

Préparer sauvegarde, restauration et suppression

Une sauvegarde n’est utile que si sa restauration a été testée. Préciser l’unité restaurable : tout le service, une base ou les données d’un client. Une restauration globale peut réintroduire des données supprimées ou affecter d’autres clients ; le scénario doit être connu avant un incident. Les délais visés doivent correspondre à un exercice réalisable par l’équipe.

La suppression demande elle aussi un parcours complet : données actives, fichiers, index de recherche, caches et politique des sauvegardes. Décrire ce qui est immédiat et ce qui suit une durée de conservation. Les engagements commerciaux doivent refléter cette réalité technique. Les obligations applicables au projet doivent être examinées séparément, avec les compétences appropriées.

Observer le service sans exposer les données

Les traces doivent permettre de suivre une opération avec un identifiant technique et de comprendre une erreur. Éviter d’y copier systématiquement les documents, secrets ou contenus sensibles. Définir qui consulte les journaux, pendant combien de temps et pour quel usage. La supervision ne doit pas devenir un canal d’accès parallèle sans contrôle.

Mesurer par client les ressources importantes aide à détecter une consommation anormale et à comprendre la marge. Prévoir des limites, des alertes et un comportement explicite en cas de dépassement. Un seul client ne devrait pas pouvoir dégrader sans contrôle le service de tous les autres. Les files, quotas et ressources dédiées sont des options à évaluer selon la charge.

Choisir une architecture que l’équipe peut maintenir

Une petite équipe doit pouvoir déployer, diagnostiquer et restaurer sans dépendre d’un seul expert. Documenter les procédures essentielles et répéter les opérations sensibles sur un environnement de test. Une architecture sophistiquée mais mal maîtrisée peut créer davantage de risque qu’un système plus simple correctement exploité.

Avant la mise en service, organiser une revue de bout en bout : création d’un client, arrivée d’un utilisateur, changement de rôle, export, incident et départ. Cette revue rend visibles les liens entre produit, sécurité et exploitation. Elle fournit aussi une base concrète pour décider quelles protections doivent être disponibles dès le lancement.