Sécurité multi-tenant : empêcher vos données de fuiter chez le voisin
Vous utilisez sûrement des dizaines de logiciels « en ligne » (SaaS) : CRM, facturation, RH… Derrière chacun, une réalité rarement expliquée : votre entreprise et des centaines d'autres partagent souvent la même application et la même base de données. D'où une question qui devrait vous empêcher de dormir : qu'est-ce qui garantit qu'un autre client ne voie jamais vos données ? La réponse tient en trois lettres : RLS.
Le « multi-tenant », c'est quoi ?
Une application multi-tenant héberge plusieurs entreprises (les « tenants », les locataires) sur la même infrastructure. L'image la plus simple, c'est l'immeuble : un seul bâtiment, une seule adresse, mais chaque locataire a son appartement et ses clés. Personne ne se retrouve dans le salon du voisin. Tout l'enjeu de la sécurité, c'est de garantir ces cloisons — numériquement.
Le vrai risque : la fuite entre organisations
Le cauchemar d'un éditeur de SaaS, ce n'est pas seulement le pirate extérieur. C'est la fuite entre clients : à cause d'un bug, l'entreprise A aperçoit les prospects, les factures ou les contrats de l'entreprise B. Une seule occurrence suffit à détruire la confiance — et à déclencher un incident RGPD. C'est le risque le plus sous-estimé, et le plus grave.
La méthode fragile : filtrer seulement dans l'application
L'approche naïve consiste à demander poliment, à chaque écran, « ne montre que les données de ce client ». Ça marche… tant que personne n'oublie. Or une application, c'est des centaines d'écrans et de requêtes, modifiés par plusieurs développeurs pendant des années. Il suffit d'un seul filtre oublié pour ouvrir une porte. Miser la confidentialité de tous vos clients sur « personne ne fera jamais d'erreur » n'est pas une stratégie.
La bonne méthode : le Row-Level Security (RLS)
Le Row-Level Security déplace la protection là où vivent les données : dans la base de données elle-même. Chaque ligne (chaque prospect, chaque facture) est étiquetée par organisation. On pose ensuite une règle simple et incontournable : la base ne renvoie que les lignes qui appartiennent au demandeur. Point.
La différence est énorme : même si un développeur oublie un filtre dans l'application, la base refuse de servir les données d'un autre client. Ce n'est plus une politesse qu'on espère respectée, c'est une loi appliquée par le socle technique, à chaque requête.
Filtrer dans l'application, c'est fermer sa porte à clé. Le RLS, c'est en plus un gardien à l'entrée de l'immeuble qui vérifie chaque personne.
Ce que ça change pour vous
Que vous soyez éditeur ou client d'un SaaS, le RLS apporte trois choses concrètes : une isolation par défaut (l'erreur humaine ne suffit plus à provoquer une fuite), une conformité RGPD plus solide et démontrable, et une confiance que vous pouvez expliquer à vos propres clients. C'est exactement le socle sur lequel repose notre plateforme Orbit : chaque organisation est cloisonnée au niveau de la base, pas seulement de l'écran.
En résumé
Dans un logiciel partagé, la vraie question n'est pas « est-ce que c'est sécurisé ? » mais « où la sécurité est-elle appliquée ? ». Si la réponse est « uniquement dans l'application », méfiance. Si elle inclut le Row-Level Security au cœur de la base, vos données ont un vrai gardien. Avant de confier vos informations à un SaaS, posez la question.