Sur un SaaS B2B, plusieurs clients partagent la même infrastructure. C'est précisément ce qui rend le modèle économiquement viable — une seule base de code, une seule infrastructure, N clients. Mais c'est aussi ce qui en fait l'un des terrains les plus minés de l'édition logicielle.
Un bug d'isolation et les données du client A deviennent visibles par le client B. Ce n'est pas une hypothèse de manuel — c'est l'une des failles les plus fréquemment identifiées lors des audits de sécurité SaaS en 2026. Et c'est, dans la quasi-totalité des cas, le résultat d'une architecture conçue sans penser au problème dès le départ.
Ce guide explique comment concevoir une architecture multi-tenant réellement sécurisée, quelles sont les erreurs classiques à éviter, et pourquoi l'approche native est la seule qui tienne face aux exigences ISO 27001 et NIS2.
C'est quoi le multi-tenant en SaaS ?
Le multi-tenant désigne simplement le fait que plusieurs clients — qu'on appelle des tenants — utilisent la même instance d'une application et partagent la même infrastructure sous-jacente. Chaque client a son propre espace de données, ses propres utilisateurs, ses propres paramètres. Mais tout ça tourne sur les mêmes serveurs, la même base de données, le même code.
C'est la norme sur les SaaS B2B. C'est ce qui permet de ne pas multiplier les coûts d'infrastructure au rythme des clients signés.
Il existe trois grandes architectures multi-tenant, chacune avec ses avantages et ses risques.
La base de données partagée avec séparation par colonnes est l'approche la plus simple et la plus économique. Tous les clients partagent les mêmes tables, avec une colonne tenant_id qui distingue les données de chacun. Le risque est évident : si un WHERE tenant_id = ? est oublié dans une seule requête, les données d'un client sont exposées à un autre. C'est une architecture qui repose entièrement sur la vigilance des développeurs — ce qui n'est pas une garantie.
La base de données partagée avec schémas séparés affecte un schéma PostgreSQL dédié à chaque tenant. L'isolation est meilleure, mais la logique de routage reste dans le code applicatif. Si le code se trompe de schéma, le problème est le même.
L'infrastructure dédiée par tenant est la plus robuste, mais la plus coûteuse. Elle est réservée aux grands comptes qui l'exigent contractuellement, pas à un modèle SaaS B2B standard.
La question n'est donc pas quelle architecture choisir, mais comment la rendre réellement sûre — quelle que soit l'approche retenue.
Les 3 erreurs classiques d'isolation
Erreur 1 — Filtrer par tenant dans le code applicatif
C'est l'erreur la plus répandue, et la plus dangereuse. Le code vérifie l'appartenance des données à un tenant via un filtre dans la requête SQL ou l'ORM. Quelque chose comme WHERE tenant_id = :currentTenant.
Le problème : cette logique est dispersée dans des centaines d'endroits dans le code. Une nouvelle fonctionnalité, une refactorisation rapide, un développeur qui reprend une tâche à la dernière minute — et un filtre est oublié. L'application fonctionne parfaitement. Les tests passent. Et quelque part dans le code, une route expose les données de tous les tenants sans filtre.
Ce type de faille ne se détecte pas facilement lors d'un code review. Elle se découvre lors d'un test de pénétration, ou pire, lors d'un incident réel.
Erreur 2 — Stocker les rôles et permissions dans le JWT
Le JSON Web Token est utilisé dans la quasi-totalité des SaaS B2B comme mécanisme d'authentification. Le problème survient quand les développeurs y stockent non seulement l'identité de l'utilisateur, mais aussi ses droits, ses rôles, et son identifiant de tenant.
Le raisonnement est compréhensible : ça évite une requête base de données à chaque appel. Mais c'est une faille conceptuelle majeure.
Si un JWT est intercepté — via une attaque man-in-the-middle, un log mal configuré, une erreur de manipulation — l'attaquant dispose de toutes les informations nécessaires pour usurper les droits d'un utilisateur, connaître sa structure de rôles, et potentiellement accéder aux données d'autres tenants si la logique d'isolation repose sur ces informations.
Plus subtil : si les droits d'un utilisateur changent (révocation d'accès, changement de rôle), le JWT existant reste valide jusqu'à son expiration. L'utilisateur révoqué continue d'avoir accès tant que son token est valide. Dans un contexte B2B avec des durées de session longues, c'est une fenêtre de risque réelle.
Erreur 3 — Aucun test d'isolation automatisé
Même avec une architecture soigneuse, l'absence de tests d'isolation automatisés est une erreur structurelle. Les développeurs testent que les fonctionnalités marchent. Ils testent rarement que le tenant A ne peut pas accéder aux données du tenant B.
Un test d'isolation doit vérifier systématiquement qu'une requête authentifiée avec les credentials du tenant A ne retourne aucune donnée appartenant au tenant B — et ce sur toutes les routes de l'API. Ce type de test doit être intégré dans la CI/CD et bloquant au déploiement.
Sans ça, chaque nouvelle fonctionnalité ou refactorisation est une opportunité d'introduire une faille d'isolation sans s'en rendre compte.
Comment le Cybercoding résout ça nativement
L'approche Cybercoding part d'un principe radicalement différent : l'isolation des tenants n'est pas la responsabilité du code applicatif. C'est la responsabilité de la plateforme de runtime.
Concrètement, ça signifie que le code généré ne contient aucune logique de filtrage par tenant. Il n'y a pas de WHERE tenant_id = ? dispersé dans le code. Il n'y a pas de vérification d'appartenance dans les controllers. Le code applicatif est, structurellement, aveugle à la notion de tenant.
L'isolation est opérée au niveau de la gateway de la plateforme, qui intercepte chaque appel entrant, extrait l'identifiant du tenant depuis l'infrastructure IAM, et injecte dynamiquement les contraintes d'isolation avant que la requête n'atteigne le code applicatif. Ce mécanisme est systématique et transparent — il fonctionne sur toutes les routes sans exception.
L'avantage est immédiat : même si un développeur oublie de gérer le filtrage dans une nouvelle fonctionnalité, la gateway applique l'isolation. L'erreur humaine ne peut pas produire de fuite cross-tenant parce que la protection ne dépend pas du code humain.
Les JWT sont vides. Ils ne contiennent que l'identifiant unique de l'utilisateur — le userId ou sub. Aucun rôle, aucune permission, aucun identifiant de tenant. À chaque appel, la gateway interroge en temps réel l'infrastructure IAM pour vérifier les droits de l'utilisateur pour ce tenant précis, pour cette ressource précise, pour cette action précise.
Ce découplage a une conséquence architecturale importante : si un utilisateur est révoqué ou change de rôle, l'effet est immédiat sur le prochain appel. Pas d'attente d'expiration du token. Pas de fenêtre de risque.
Les tests d'isolation sont automatisés dans le pipeline CI/CD de la plateforme. Chaque build vérifie qu'aucune route n'expose des données cross-tenant. Ce test est bloquant — un build ne peut pas passer en production s'il échoue.
Ce que ça change concrètement pour ISO 27001
La norme ISO 27001 exige plusieurs contrôles directement liés à l'isolation des données dans un environnement multi-tenant. Elle demande que l'accès aux informations soit restreint selon le principe du moindre privilège, que les accès soient tracés de manière auditables, et que les données de clients différents soient effectivement séparées.
Dans un modèle classique, prouver la conformité de ces contrôles lors d'un audit nécessite de documenter chaque point de filtrage dans le code, de démontrer que les tests couvrent l'ensemble des routes, et de fournir des preuves d'isolation pour chaque type de donnée. C'est un travail considérable qui prend des mois et mobilise une équipe dédiée.
Dans le modèle Cybercoding, l'isolation est une propriété architecturale de la plateforme — pas du code. Elle est documentée une fois, au niveau de la plateforme, et s'applique à toutes les applications hébergées dessus. L'auditeur vérifie la plateforme, pas chaque ligne de code de chaque fonctionnalité.
Le résultat : le délai de certification ISO 27001 passe de 18 mois à 3 mois. Pas parce que les exigences sont moins strictes, mais parce que la conformité est structurelle et non pas documentaire.
La même logique s'applique à NIS2, qui impose des mesures de gestion des risques sur les systèmes d'information. Un mécanisme d'isolation native, avec des logs d'audit inaltérables sur chaque accès, est par définition conforme aux exigences de traçabilité et de segmentation de NIS2.
Ce qu'il faut retenir
L'architecture multi-tenant est l'une des décisions les plus structurantes d'un SaaS B2B. Elle détermine non seulement la sécurité des données de vos clients, mais aussi votre capacité à obtenir ISO 27001, à répondre à NIS2, et à convaincre les DSI des grands comptes.
Les trois erreurs classiques — filtrage dans le code applicatif, stockage des droits dans le JWT, absence de tests d'isolation — ont en commun d'être des solutions de court terme qui génèrent des risques de long terme. Elles viennent toutes d'une architecture pensée après le développement plutôt qu'avant.
L'isolation native au niveau du runtime, des JWT vides avec vérification temps réel, et des tests d'isolation automatisés dans la CI/CD ne sont pas des luxes réservés aux grandes structures. Ce sont les fondations que tout SaaS B2B sérieux doit poser dès la conception.
Votre architecture multi-tenant actuelle isole-t-elle vraiment vos clients au niveau du runtime, ou au niveau du code ? La réponse à cette question détermine votre niveau d'exposition réel.
→ L'audit Wakanalytics permet d'identifier en 24h les points de risque de votre architecture multi-tenant et vos actions prioritaires. Démarrer sur wakastart.com/wakanalytics