SaaS multi‑tenant pour fondateurs : isolation des locataires et contrôles de bon sens

Le problème en clair

Si vous développez un SaaS multi‑tenant, vous entendrez des mots comme « locataire », « isolation » et « séparation des données ». L'idée est simple : de nombreux clients utilisent la même application, et chacun doit l'expérimenter comme s'il était le seul client.

La difficulté, c'est qu'un produit peut sembler correct en surface (connexion qui fonctionne, pages qui chargent, paiements passés) alors qu'une erreur de configuration cachée permet discrètement à un client de voir ou d'affecter les éléments d'un autre client.

Votre produit doit tenir une promesse : pas de fuite entre clients. Pas de consultation des données d'autrui, pas de modification, pas de suppression, pas d'« oups, le système a envoyé le mauvais email ». Même de petites fuites brisent la confiance très vite.

Voici comment cela arrive souvent en pratique :

• Un utilisateur modifie un numéro dans la barre d'adresse et voit soudain la facture d'une autre entreprise.
• Un administrateur support exporte « tous les utilisateurs » et envoie par erreur un fichier contenant plusieurs clients.
• Un job en arrière‑plan (comme des rapports nocturnes) s'exécute avec le mauvais ID de client et mélange les résultats.
• Un bucket de fichiers partagé stocke les uploads dans le même dossier, si bien que les documents se chevauchent.
• Un raccourci de cache affiche à un client une page générée pour un autre.

Si vous n'êtes pas technique, considérez cela comme un risque et une liste de vérifications, pas comme du génie logiciel profond. Vous n'avez pas besoin de comprendre les bases de données pour poser les bonnes questions et repérer les signaux d'alerte.

Ce que « multi‑tenant » veut dire (et ce que ça ne veut pas dire)

Un SaaS multi‑tenant est une même application qui sert plusieurs clients en même temps. Chaque client est un « locataire ». Vous vous connectez, voyez votre espace de travail, et tout semble construit pour vous, même si le système est partagé en coulisses.

Le modèle mono‑tenant (single‑tenant) est l'inverse : chaque client dispose de sa propre copie de l'application (ou de son propre environnement) avec sa base de données et souvent ses serveurs. Cela peut sembler plus sûr, mais c'est généralement plus coûteux à exploiter et plus compliqué à maintenir.

Multi‑tenant ne veut pas dire « toutes les données sont mélangées ». Bien fait, les locataires partagent le code et l'infrastructure, mais leurs données restent séparées.

En pratique, beaucoup d'équipes partagent le code applicatif, les serveurs/worker et les outils de déploiement, tout en séparant l'accès aux données et les règles d'autorisation. Certains séparent aussi les clés de chiffrement ou des paramètres spécifiques par locataire.

Une analogie simple : imaginez un immeuble. Tout le monde partage le même bâtiment, les couloirs et la plomberie. Mais chaque appartement a sa porte fermée à clé, ses propres clés et son espace privé. Le mono‑tenant, c'est plutôt des maisons séparées : plus de séparation, plus de coûts, plus d'entretien.

Quand les gens s'inquiètent du multi‑tenant, ils pensent généralement à une chose : les serrures. L'isolation des locataires consiste à s'assurer que les portes ne peuvent pas être contournées, même par accident.

Isolation des locataires : les 4 domaines qui comptent

L'isolation des locataires rassemble les règles qui empêchent le Client A de voir, modifier ou ralentir le Client B.

1) Isolation des données

C'est le point principal : ce que chaque client peut lire et modifier. Chaque requête doit être limitée au locataire courant (souvent une organisation ou un espace de travail). Si votre appli a des vues « admin », elles doivent aussi être scindées par locataire à moins qu'il ne s'agisse d'un vrai outil interne.

2) Isolation des actions

Même si les données sont séparées, les actions peuvent propager des droits. Les utilisateurs ne doivent pouvoir inviter des personnes, exporter des données, supprimer des enregistrements ou gérer la facturation que dans leur propre locataire, et seulement si leur rôle le permet.

3) Isolation des paramètres

Les paramètres provoquent certaines des fuites les plus embarrassantes : branding, modèles d'email, rôles, feature flags et détails de facturation. Si ces éléments traversent les locataires, les clients le remarquent vite car l'interface est incorrecte ou les factures arrivent au mauvais destinataire.

4) Isolation des performances

Un locataire « bruyant » ne doit pas paralyser les autres. Cela implique en général des limites de taux, des files de jobs et des plafonds de ressources pour éviter qu'une grosse importation ou un script incontrôlé n'impacte toute l'application.

Une façon simple de vérifier les quatre domaines :

• Voient‑ils uniquement les bonnes données ?
• Peuvent‑ils effectuer uniquement les actions autorisées ?
• Ont‑ils uniquement les bons paramètres ?
• Un locataire peut‑il surcharger les autres ?

Au début, « assez bien » n'est pas une isolation parfaite. C'est une isolation prévisible. Si vous vous connectez à deux comptes tests et que le second affiche un jour les utilisateurs, projets ou factures du premier, arrêtez‑vous et corrigez cela avant de livrer d'autres fonctionnalités.

Pourquoi l'isolation compte pour votre business

L'isolation des locataires peut sembler technique, mais l'impact est simple : les clients vous confient leurs données. Dans un SaaS multi‑tenant, une erreur qui expose les informations d'une autre entreprise peut faire échouer des ventes, provoquer du churn et vous coller pendant des années.

Les acheteurs considèrent la confidentialité comme une base minimale. Si un prospect entend « un autre locataire a vu de mauvais enregistrements », il n'entendra pas « cas limite ». Il entendra « ça pourrait nous arriver », et la vente s'arrête ou le service achat freine.

Il y a aussi des conséquences juridiques et de conformité, même pour les petites équipes. Beaucoup de contrats exigent la séparation des données clients et la notification en cas de violation. Si vous traitez des données personnelles (noms, emails, informations de facturation), vous pouvez être tenu de signaler une fuite, subir des audits et payer des amendes, en plus des coûts juridiques.

Le support devient compliqué également. Quand l'isolation est faible, vous ne pouvez pas répondre avec confiance aux questions basiques comme « Qui a vu quoi ? » ou « Combien de temps a duré l'incident ? ». Cela génère de longs échanges, des remboursements et des escalades.

Les problèmes d'isolation se manifestent souvent par des glitches « aléatoires » faciles à minimiser mais dangereux à ignorer :

• Un utilisateur voit l'enregistrement d'une autre entreprise dans une liste ou un résultat de recherche.
• Un email part au mauvais client avec les détails d'un autre.
• Un export CSV contient des lignes de plusieurs locataires.
• Un total de tableau de bord paraît trop élevé parce qu'il compte des données inter‑locataires.
• Une action admin affecte le mauvais compte.

Le compromis coût/risque vaut d'être dit clairement : partager l'infrastructure est généralement acceptable. Partager les données ne l'est pas. Vous pouvez économiser en mutualisant le calcul, mais vous ne devez pas être laxiste sur qui peut lire ou écrire quelles lignes.

Où l'isolation casse généralement

La plupart des fuites entre locataires ne sont pas le fait de « hackers ». Ce sont des erreurs quotidiennes : une vérification manquante, une clé de cache partagée, un raccourci admin. Tout peut paraître correct en test jusqu'à l'arrivée de données et d'utilisateurs réels.

1) Connexion, sessions et « qui suis‑je en ce moment ? »

L'isolation casse quand l'appli stocke l'info de locataire au mauvais endroit (ou pas du tout). Un utilisateur peut être correctement connecté, mais la session ne l'attache pas à un locataire unique. Cela apparaît quand vous changez d'espace dans le même navigateur et que l'appli « se souvient » du mauvais workspace.

2) Accès aux données : filtre de locataire manquant

Le bug le plus courant est simple : une requête DB récupère des enregistrements par ID, statut ou email, mais oublie de restreindre aussi par locataire. Ça peut être un endpoint ajouté rapidement, un export ou un écran « lister tout ».

Cela se cache souvent dans les pages de détail qui chargent par ID d'enregistrement, les builders de rapports/exports, la recherche/autocomplete, les outils support, et les handlers de webhooks qui recherchent des utilisateurs par email.

3) Stockage, recherche, caches et jobs en arrière‑plan

Les fichiers sont de vieux coupables. Un bucket partagé avec des liens publics peut exposer factures, avatars ou pièces jointes entre locataires, surtout si les noms de fichiers sont prévisibles.

La recherche et le cache peuvent mêler les locataires s'ils partagent un index ou une clé de cache. L'analytics peut aussi combiner des événements de locataires différents, ce qui reste une fuite de données même si personne ne voit l'écran d'un autre locataire.

Les jobs en arrière‑plan (emails, PDFs, rapports hebdomadaires) cassent l'isolation quand ils s'exécutent sans le bon contexte de locataire. Exemple classique : un job nocturne « envoyer les factures » récupère la facture correcte, mais utilise le branding ou les destinataires du locataire précédent.

Étape par étape : vérifications faciles que vous pouvez faire vous‑même

Vous n'avez pas besoin de lire le code pour détecter beaucoup de problèmes d'isolation. Il vous faut des comptes tests propres et l'habitude d'essayer de « regarder par‑dessus la clôture ».

Créez deux locataires facilement identifiables. Utilisez des données très distinctes comme « Locataire A : Boulangerie Bleue » et « Locataire B : Salle Rouge ». Ajoutez quelques clients, factures et notes dans chacun. Puis créez deux utilisateurs par locataire : un admin et un utilisateur standard.

Parcourez ensuite les endroits où les données fuient souvent :

• Listes et tableaux de bord (éléments récents, « top clients », flux d'activité)
• Recherche et filtres (cherchez un nom qui existe uniquement chez l'autre locataire)
• Exports (les exports CSV/PDF oublient souvent le filtre par locataire)
• Pages de détail (ouvrez un élément, puis modifiez l'ID dans l'URL si votre appli le permet)
• Pages de facturation (abonnements, factures, reçus)

Testez aussi les flux qui touchent aux emails et à l'identité : invitez un utilisateur, réinitialisez un mot de passe et vérifiez les emails envoyés. Un bug courant : un email pointe vers la bonne appli mais vous fait atterrir dans le mauvais locataire après la connexion.

Téléversez un fichier dans le Locataire A et vérifiez qu'il ne peut pas être ouvert depuis le Locataire B, même si vous copiez l'URL du fichier. Faites de même pour les images, pièces jointes et tout bouton « télécharger ».

Enfin, testez les outils support et admin. Si votre équipe peut usurper un utilisateur, émettre des remboursements ou supprimer des données, assurez‑vous que ces outils exigent toujours la sélection du bon locataire et affichent clairement sur quel locataire vous intervenez.

Rendre vos vérifications répétables (pour que vous les fassiez vraiment)

La plupart des fuites ne sont pas un gros bug unique. Ce sont des petites erreurs qui réapparaissent quand vous changez l'auth, ajoutez un rapport ou touchez au cache. La solution est ennuyeuse mais efficace : ranimez les mêmes contrôles rapides à chaque fois avec les mêmes locataires tests, et notez ce que vous avez vu. Une simple note suffit : date, version, ce que vous avez testé et le résultat. Quand quelque chose casse, cette note transforme une crainte vague en un bug clair.

Une routine réutilisable

Exécutez ceci à chaque livraison majeure, changement d'auth, ajout de rôles/permissions ou toute modification liée aux workspaces.

• Changez de locataire (via le sélecteur de locataire ou le mécanisme utilisé) puis répétez la dernière action (recherche, consultation d'un record, modification d'un paramètre).
• Déconnectez‑vous et reconnectez‑vous, confirmez que vous atterrissez dans le bon locataire avec le bon rôle.
• Exportez quelque chose (PDF, CSV, facture, rapport) et parcourez l'en‑tête et les IDs. Mauvais noms de société et IDs étrangers sont des signaux précoces.
• Répétez un test dans une fenêtre incognito et sur un autre appareil pour détecter les problèmes d'état en cache.
• Reprenez l'ensemble après tout changement d'auth ou de permissions, même si la fonctionnalité livrée semble « sans rapport ».

Check‑list rapide : revue d'isolation en 5 minutes

Ouvrez deux fenêtres du navigateur : une connectée en Locataire A, l'autre en Locataire B (deux comptes tests). Puis faites ce contrôle rapide :

• Parcourez les écrans principaux (listes, recherche, activité récente). Vous ne devez jamais voir les noms, enregistrements ou totaux d'un autre locataire.
• Générez un export ou un rapport (CSV, PDF, totaux de dashboard). Vérifiez qu'il n'inclut que le locataire actif et que les totaux correspondent à l'affichage.
• Déclenchez quelques notifications (email d'invitation, reset de mot de passe, facture, alerte de commentaire). Vérifiez nom de l'expéditeur, logo et destinataires pour s'assurer qu'ils correspondent au locataire.
• Essayez d'accéder aux fichiers en « devinant » (changez un ID de fichier dans l'URL, réutilisez un lien du Locataire A en étant connecté en Locataire B). Vous devez être bloqué à chaque fois.
• Ouvrez les outils admin/support. Limitez l'accès au minimum, et assurez‑vous que les actions sont loggées (qui a consulté quoi et quand).

Terminez par un test destructif en staging : désactivez un locataire et confirmez que l'accès est réellement coupé. Les sessions anciennes doivent cesser de fonctionner, les API doivent rejeter les requêtes, et les données ne doivent plus être accessibles via exports, fichiers ou recherches admin.

Si l'une de ces vérifications échoue, traitez‑la comme un bug de production, pas comme une tâche « plus tard ».

Erreurs courantes qui causent des fuites entre locataires

La plupart des fuites n'apparaissent pas parce que quelqu'un vous a « piraté ». Elles surviennent parce qu'un petit raccourci est devenu une habitude et que personne ne l'a remarqué jusqu'à ce qu'un client voie les mauvaises données.

Erreur 1 : « sécurité par l'UI »

Cacher des données via l'interface (filtres, menus désactivés) sans imposer la règle côté serveur est un piège classique. Si le backend accepte un ID et renvoie un record sans vérifier « ce record appartient‑il à ce locataire ? », quelqu'un peut changer l'ID et récupérer les données d'un autre client.

Erreur 2 : rôles non scindés par locataire

Un simple flag is_admin est facile, mais souvent trop grossier. Quand vous avez des agences, des revendeurs ou des workspaces partagés, vous devez lier les rôles à un locataire (et parfois à un projet à l'intérieur du locataire). Sinon, un « admin » du Locataire A peut se retrouver avec des droits d'admin sur le Locataire B.

Erreur 3 : IDs devinables ou révélateurs

Des IDs globaux courts, séquentiels ou réutilisés entre tables facilitent l'accès aux enregistrements d'autres locataires. Même si l'UI ne les affiche pas, ils fuient via les URLs, logs, exports et captures d'écran envoyées au support.

Quelques autres patterns récurrents :

• Une clé API ou un secret réutilisé entre clients, ou copiée entre dev, staging et prod
• Jobs en arrière‑plan qui s'exécutent avec un compte service trop puissant capable de lire tous les locataires
• Partir du principe que « ça marchait en staging » alors que la production a plus de données, de cas limites et de concurrence

Un échec réaliste ressemble à ça : un outil support permet d'usurper un utilisateur, mais l'endpoint d'usurpation vérifie seulement que l'agent est interne, pas quel locataire il a sélectionné. Un mauvais clic et la page suivante charge les factures d'un autre client.

Un exemple réaliste : comment une fuite arrive et comment on la corrige

Imaginez un SaaS multi‑tenant simple : deux clients, Boulangerie Bleue et Gym Vert. Ils utilisent la même appli, mais ne doivent voir que leurs propres factures.

Un matin, la Boulangerie Bleue ouvre l'écran Factures et remarque une facture avec un logo étrange. Elle contacte le support avec une capture d'écran. L'agent reproduit les mêmes étapes et constate le même problème. En exportant les factures en CSV, la Boulangerie trouve quelques lignes qui ne lui appartiennent pas.

La cause racine est souvent banale : un filtre manquant. La requête DB récupère les factures par statut (par exemple « payée ») mais oublie de limiter aussi au tenant_id du client connecté. L'UI marche la plupart du temps, jusqu'à ce que deux locataires aient des factures correspondant aux mêmes statuts ou plages de dates.

Une bonne correction va au‑delà de « rajouter un filtre ». Elle comprend généralement :

• Scoper chaque requête de factures par tenant_id, pas seulement l'écran où on l'a remarqué
• Imposer les vérifications de locataire dans les règles d'autorisation pour que le backend bloque l'accès même si l'UI est bugguée
• Mettre à jour les exports et jobs en arrière‑plan (rapports, emails) qui lisent les factures en masse
• Ajouter un test de non‑régression qui tente de récupérer la facture d'un autre locataire et attend un échec net
• Logger et alerter quand une requête essaye d'accéder aux données d'un autre locataire

La communication client est importante. Informez la Boulangerie Bleue que vous avez trouvé et corrigé un bug d'isolation, précisez quelles données ont pu être visibles (de manière claire et spécifique), et partagez ce que vous avez changé pour éviter les récidives. En interne, planifiez un audit rapide des pages similaires (factures, clients, paiements) et ajoutez le nouveau test à votre checklist de livraison.

Prochaines étapes : quoi demander et quand demander de l'aide

Vous n'avez pas besoin de lire chaque ligne de code. Vous devez avoir une réponse claire à une question : « Où, exactement, empêchons‑nous qu'un client voie les données d'un autre ? » Demandez des preuves, pas des assurances vagues.

Questions à envoyer à vos devs :

• Où la vérification de locataire se produit‑elle sur chaque requête (middleware, contrôleur, couche de requête) ?
• Quelle est la source d'identité du tenant_id (sous‑domaine, token d'auth, header), et peut‑elle être falsifiée ?
• Comment testez‑vous l'isolation : tests unitaires, end‑to‑end, ou les deux ?
• Qu'est‑ce qui empêche les jobs, imports et exports de mélanger les locataires ?
• Si un bug passe en prod, comment le détecterions‑nous (logs, alertes, pistes d'audit) ?

Demandez ensuite des preuves que vous pouvez parcourir rapidement : un modèle de données d'une page (ce qui est scindé par locataire vs global) et un plan de test court avec 6–10 cas « essayez de le casser », incluant au moins un export et une action admin/support.

Si vous avez hérité d'un prototype généré par IA qui montre maintenant ses limites en production, il est souvent utile d'avoir un regard extérieur sur le scoping des locataires, les exports, les jobs en arrière‑plan et les secrets. FixMyMess (fixmymess.ai) se spécialise dans le diagnostic et la réparation de bases de code générées par IA pour les rendre prêtes pour la production ; un audit rapide peut cartographier les frontières des locataires et pointer les chemins les plus probables de fuite avant que vous n'ajoutiez d'autres fonctionnalités.