Architecture multi tenant pour un SaaS B2B

Le multi tenant, ou comment une application sert tous vos clients

Une architecture multi tenant désigne une application unique qui sert plusieurs organisations clientes, appelées tenants, sur une même infrastructure, tout en garantissant que les données d un client restent invisibles à tous les autres. C est l opposé du modèle mono tenant, où chaque client reçoit sa propre installation isolée. Pour un éditeur de SaaS, ce choix d architecture n est pas un détail technique : il conditionne le modèle économique entier. Un produit mono tenant oblige à déployer, maintenir et mettre à jour autant d instances que de clients, ce qui fait exploser les coûts d exploitation dès les premières dizaines de comptes. Le multi tenant, lui, permet de corriger un bug ou de livrer une fonctionnalité une seule fois, pour tous, simultanément.

C est précisément ce qui rend un SaaS commercialisable à l échelle. Prenez CoProFlex, le SaaS de gestion de syndic que nous avons conçu en interne : chaque cabinet de syndic est un tenant qui retrouve ses immeubles, ses copropriétaires et ses documents, sans jamais voir ceux d un autre cabinet, alors que tous partagent la même application et la même base de données. Le jour où une nouvelle fonction d assemblée générale est développée, elle devient disponible pour l ensemble des cabinets en un déploiement, sans migration cliente à cliente. Cette mutualisation est la raison pour laquelle un éditeur peut vendre à un tarif d abonnement raisonnable tout en restant rentable. La séparation stricte des données devient alors le cœur du contrat de confiance : un tenant qui verrait, ne serait ce qu une fois, la donnée d un autre, c est la fin de la crédibilité du produit.

Construire ce socle dès le départ change aussi le profil de risque et de coût du projet. Reprendre un produit conçu pour un seul client et le transformer ensuite en plateforme multi tenant est un chantier lourd, qui touche le schéma de données, les requêtes et toute la couche de droits. À l inverse, intégrer le multi tenant dès le premier incrément ne renchérit pas significativement le budget : il fait partie de notre standard de développement SaaS, qui va de 40 000 à 300 000 EUR, et qu un MVP commercialisable à 40 000 à 80 000 EUR inclut déjà. La donnée structurée et bien rangée qui en résulte est aussi un atout au delà du produit : un contenu adossé à une donnée originale et complète est nettement mieux repris par les moteurs, classiques comme génératifs.

3SaaS verticaux conçus en interne (CoProFlex, DocAgora)10 ansd'expérience en web, SEO et logiciel métier4,2xplus de citations IA pour un contenu sémantiquement complet (r=0,87)Source : GenOptima, 2026+22%de visibilité pour les sites publiant de la data originaleSource : SE Ranking, March 2026 Core Update

Les 3 modèles d isolation des données, comparés

Toute la question du multi tenant tient dans une seule contrainte : comment garantir qu un tenant n accède jamais aux données d un autre. Trois modèles d isolation répondent à ce problème, du plus mutualisé au plus séparé. Ils n ont ni le même coût, ni le même profil de sécurité, ni la même facilité de maintenance. Choisir le bon modèle dès le cadrage évite une dette d architecture qui coûterait dix fois plus cher à corriger plus tard, une fois des clients en production.

1. Base partagée avec filtrage par ligne. Tous les tenants partagent la même base et les mêmes tables. Chaque ligne porte un identifiant de tenant, et un mécanisme de filtrage garantit qu une requête ne renvoie que les lignes du client connecté. C est le modèle le plus mutualisé, donc le plus économique à exploiter et le plus simple à faire évoluer pour tous en une fois. Sa fiabilité repose entièrement sur la qualité du filtrage : c est là que la Row Level Security entre en jeu, en posant la barrière au niveau de la base et non du code applicatif.
2. Un schéma par tenant. Les tenants partagent la même base PostgreSQL, mais chacun dispose de son propre schéma, c est à dire son propre jeu de tables. L isolation est plus forte qu un simple filtrage par ligne, mais le nombre de schémas grossit avec les clients, et chaque migration de structure doit être appliquée à chaque schéma. La maintenance devient lourde au delà de quelques dizaines de tenants, et l outillage standard supporte mal des centaines de schémas.
3. Une base par tenant. Chaque client dispose de sa propre base de données, voire de sa propre infrastructure. L isolation est maximale et certains secteurs très régulés l exigent. Mais le coût d exploitation grimpe vite, chaque mise à jour doit être orchestrée base par base, et le modèle économique du SaaS mutualisé s effondre. On le réserve à des cas précis : exigence contractuelle de cloisonnement physique, ou très gros comptes payant pour cette séparation.

Dans la pratique, pour la quasi totalité des SaaS B2B que nous construisons, la base partagée sécurisée par Row Level Security est le choix rentable : elle conserve la mutualisation qui rend le produit viable économiquement, tout en posant une isolation robuste au niveau de la base. C est le modèle que nous avons retenu pour CoProFlex comme pour DocAgora, notre SaaS médical, où la sensibilité des données imposait pourtant un niveau d exigence élevé. Le tableau ci dessous résume les arbitrages.

74,2%des citations IA proviennent de contenus structurés en listesSource : Authoritas, 202660%des SERP Google affichent désormais un AI OverviewSource : SearchEngineLand, avril 2026

Notre approche : isolation par RLS Supabase au niveau de la ligne

Notre standard d isolation repose sur les Row Level Security (RLS) de Supabase, qui s appuie sur PostgreSQL. Le principe est simple à énoncer et puissant en pratique : une règle de sécurité, écrite directement dans la base, décide pour chaque ligne si l utilisateur connecté a le droit de la voir ou de la modifier. Concrètement, chaque table porte une colonne d identifiant de tenant, et une politique RLS impose que toute requête ne renvoie que les lignes dont le tenant correspond à celui de l utilisateur authentifié. Cette règle ne s applique pas dans le code de l application, mais dans le moteur de base de données lui même. Le code métier peut comporter un oubli de filtre, la base, elle, refusera de servir une ligne hors périmètre.

C est cette double barrière qui fait la différence. Dans une approche purement applicative, l isolation dépend de la rigueur de chaque développeur à ajouter la bonne condition à chaque requête : un seul oubli, et un tenant peut voir les données d un autre. Avec RLS, la séparation est centralisée, déclarative et impossible à contourner depuis l application, puisqu elle vit sous la couche applicative. Pour CoProFlex, cela signifie qu un cabinet de syndic ne peut techniquement pas requêter les immeubles d un autre cabinet, même en cas de défaut dans le code. Pour DocAgora, où la donnée est médicale, cette garantie posée dans la base est un argument de conformité autant que de sécurité. L authentification, gérée par Supabase, fournit l identité et le tenant de l utilisateur, que les politiques RLS consomment pour appliquer le filtrage.

Cette brique s intègre dans une stack cohérente et éprouvée, celle que nous utilisons sur nos propres SaaS : Next.js et TypeScript strict pour l application, Supabase (PostgreSQL, RLS, authentification) pour la donnée et l isolation multi tenant, Stripe pour la facturation et les abonnements, Resend ou Brevo pour les emails transactionnels, et un déploiement sur Vercel. Le typage strict de bout en bout réduit les erreurs au moment où elles coûtent le moins cher, à l écriture du code, plutôt qu en production. Ce choix de stack n est pas théorique : c est la même équipe Propulseo qui conçoit CoProFlex et DocAgora qui développe les SaaS de nos clients, ce qui garantit une cohérence technique sur toute la durée du projet.

70+clients accompagnés depuis 202450+projets livrés53%des sources citées par les IA datent de moins de 6 moisSource : Authoritas, 2026

Sécurité, performance et migrations à l échelle

Une architecture multi tenant bien conçue ne se limite pas à l isolation des données. Trois enjeux l accompagnent et méritent d être traités dès la conception : la sécurité et la conformité, la performance quand le nombre de tenants grandit, et la gestion des migrations de structure sur une base partagée. Les négliger, c est accumuler une dette qui se paie au pire moment, quand le produit a justement trouvé son marché et que les clients affluent.

Sur la sécurité et le RGPD, le multi tenant bien fait est un atout plutôt qu une contrainte. L isolation par tenant signifie que chaque client n accède qu à ses propres données, ce qui colle naturellement aux principes de minimisation et de cloisonnement attendus par le RGPD. Nous ajoutons une gestion des accès par rôles à l intérieur de chaque tenant (un gestionnaire ne voit pas ce que voit un administrateur) et le chiffrement des données sensibles. La sécurité n est pas un correctif appliqué à la fin, mais une contrainte traitée dès le cadrage, ce qui est décisif pour un SaaS médical comme DocAgora où la protection des données de santé est prioritaire. La double barrière RLS plus contrôle applicatif réduit fortement la surface de risque d une fuite d un tenant vers un autre.

1. Performance à l échelle. Sur une base partagée, des milliers de tenants cohabitent dans les mêmes tables. Les index sur la colonne de tenant, le partitionnement des grosses tables et la mise en cache côté application maintiennent des temps de réponse stables quand le volume grimpe. PostgreSQL encaisse de très gros volumes à condition de modéliser la donnée pour le multi tenant dès le départ.
2. Migrations de structure. Le grand avantage de la base partagée est qu une évolution de schéma s applique une seule fois pour tous les tenants, sans répéter l opération client par client. Cela impose en contrepartie une rigueur sur les migrations : versionnées, testées et déployées de manière à ne casser aucun tenant en production.
3. Observabilité par tenant. Pouvoir mesurer l usage et les incidents tenant par tenant permet d anticiper la charge, de facturer à l usage si besoin et de diagnostiquer vite un problème isolé à un client sans affecter les autres.

Cette discipline rejoint celle des incréments d un projet bien mené : une structure propre dès le départ, des migrations maîtrisées et une donnée rangée. Au delà de la robustesse du produit, cette donnée structurée est un actif durable, y compris pour la visibilité, à l heure où la recherche se déplace vers des moteurs génératifs qui privilégient les sources fraîches et la donnée de qualité. Construire propre sert le produit et sa diffusion.

-71%de trafic pour les contenus IA paraphrasés sans valeur ajoutéeSource : SE Ranking, March 2026 Core Update800M+d'utilisateurs hebdomadaires de ChatGPTSource : OpenAI, 2026+40%de gain de ranking pour une architecture en cluster pilier/spokesSource : Geneo Internal Linking Study, 2025

Le cas CoProFlex : un SaaS multi tenant pour le syndic

La meilleure preuve d une architecture reste un produit en service. CoProFlex est le SaaS de gestion de syndic de copropriété que nous avons conçu et développé en interne. Le métier du syndic implique de nombreux flux administratifs, documentaires et financiers, propres à chaque cabinet et à chaque copropriété, que des outils généralistes ne savent pas couvrir. Le défi technique était double : modéliser ces flux spécifiques, et faire cohabiter sur une seule plateforme des dizaines de cabinets dont les données ne doivent jamais se croiser.

Nous avons retenu le modèle de base partagée sécurisée par Row Level Security : chaque cabinet est un tenant qui retrouve ses immeubles, ses copropriétaires, ses documents et ses suivis, avec une isolation posée dans PostgreSQL. Une évolution fonctionnelle profite à l ensemble des cabinets en un déploiement, ce qui maintient un coût d exploitation compatible avec un abonnement. La facturation est gérée via Stripe, en mode abonnement, et l ensemble repose sur la stack Next.js, TypeScript strict, Supabase et Vercel. CoProFlex illustre concrètement ce que cette architecture rend possible : un seul produit, plusieurs clients, une isolation stricte et une maintenance mutualisée.

L approche serait la même pour votre projet : on ne plaque pas un modèle d isolation générique sur votre métier, on choisit la bonne stratégie selon vos contraintes de sécurité, votre volume de tenants attendu et votre modèle économique, puis on la construit dès le premier incrément. Le multi tenant fait partie de notre standard de développement SaaS, de 40 000 à 300 000 EUR, et il est déjà inclus dans un MVP commercialisable à 40 000 à 80 000 EUR. C est précisément ce que notre diagnostic gratuit permet de cadrer : votre modèle d isolation, votre architecture de données et un budget réaliste, avec une réponse sous 24h et sans engagement.