Priorisez les modèles de tenancy et validez votre base SaaS par quatre tests : charge, migration, coût, observabilité. Prototypez sur Postgres.
Pour la plupart des applications SaaS, une base de données relationnelle compatible Postgres, en architecture multi-tenant à table partagée, est le bon point de départ. Elle passe à l'échelle à moindre coût, s'appuie sur un outillage mature et absorbe sans drame la grande majorité des charges B2B. Les deux exceptions qui doivent vous faire changer d'avis : vous avez besoin d'écritures actives-actives sur plusieurs régions, ou certains clients portent des exigences réglementaires qui imposent une isolation physique stricte. Les sections qui suivent couvrent les modèles de tenancy, la mécanique de mise à l'échelle, l'exploitation et la façon de valider votre choix avant de vous engager.
En bref :
La plupart des applications SaaS devraient démarrer sur une architecture à table partagée compatible Postgres, sauf si des écritures actives-actives multi-régions ou une isolation réglementaire stricte sont indispensables.
Le modèle de tenancy par défaut est la table partagée, pour son faible coût, sa facilité de mise à l'échelle et sa simplicité, les clients les plus gros ou les plus régulés étant déplacés vers un schéma ou une base dédiés.
Les données transactionnelles centrales profitent surtout des bases relationnelles comme Postgres, tandis que les schémas variables ou les journaux à fort volume conviennent mieux au NoSQL ou à des moteurs spécialisés, souvent dans une architecture mixte.
Une bonne mise à l'échelle passe par le partitionnement avant le sharding, le pooling de connexions et le report des traitements lents en arrière-plan, le cache venant compléter, et non remplacer, l'optimisation des accès aux données.
Valider un choix de base de données suppose des tests de charge réalistes, des répétitions de migration, une modélisation du coût sur la durée et la mise en place de l'observabilité avant la mise en production.
Tout produit SaaS multi-tenant repose sur l'un des trois modèles de tenancy, et se tromper ici coûte plus cher que n'importe quel choix de moteur de base de données que vous ferez ensuite. Le guide des modèles de tenancy de Microsoft expose les trois canoniques : une base par client, un schéma par client, et la table partagée avec une colonne tenant_id dédiée.
Une base par client donne à chaque client une base entièrement isolée. C'est l'option la plus sûre pour les secteurs très réglementés (dossiers médicaux, registres financiers), car une fuite ou un bug sur les données d'un client ne peut pas déborder sur celles d'un autre. Le coût est bien réel : la surcharge de connexions se multiplie vite, et un parc de quelques milliers de bases clientes transforme une migration de schéma de routine en problème de coordination.
Un schéma par client se situe entre les deux. Une seule instance de base, plusieurs schémas, chaque client obtenant un espace de noms logique. Cela réduit la surcharge par client par rapport à l'isolation complète tout en gardant un rayon d'explosion propre si quelque chose tourne mal dans un schéma.
La table partagée est le choix par défaut de la plupart des éditeurs SaaS, et pour de bonnes raisons :
Choisissez la table partagée par défaut. Ne déplacez un client vers son propre schéma ou sa propre base que lorsque son contrat, son cadre réglementaire ou son volume de données l'exigent réellement. La plupart des praticiens aboutissent à un modèle hybride : table partagée pour la longue traîne des petits clients, schémas ou bases dédiés réservés à vos comptes les plus gros ou les plus régulés. Ce modèle hybride revient assez souvent dans les systèmes de production pour mériter d'être anticipé dès le premier jour, même si vous lancez en table partagée pure.
La question du relationnel contre le non-relationnel ne porte pas sur la technologie la plus récente. Elle porte sur votre modèle de données, vos schémas d'accès et le niveau de cohérence dont vous avez réellement besoin. Le guide prescriptif d'AWS structure la décision autour de cinq axes : modèle de données, schémas d'accès, latence, exigences ACID et besoins multi-régions.
Les bases relationnelles comme Postgres l'emportent quand vos données ont une structure claire, que les relations entre entités comptent (des utilisateurs appartiennent à des organisations, des factures référencent des abonnements) et que vous avez besoin de garanties transactionnelles. La facturation, les permissions et l'état applicatif central y ont presque toujours leur place.
Le NoSQL et les bases documentaires prennent tout leur sens quand votre schéma est réellement variable, que vous stockez des événements ou des journaux à fort volume, ou qu'il vous faut des lectures clé-valeur inférieures à la milliseconde à très grande échelle. Le stockage de sessions, les fils d'activité et les contenus générés par les utilisateurs, souples par nature, s'accommodent souvent mieux d'un modèle documentaire que d'un modèle relationnel rigide.
La plupart des plateformes SaaS matures finissent par exploiter une architecture mixte :
pgvector pour les embeddings et les fonctions de recherche sémantiqueSi votre produit a besoin d'analytique en temps réel mêlée aux données transactionnelles, les moteurs OLTP/OLAP unifiés comme SingleStore représentent un compromis différent qui mérite l'évaluation, même s'ils ajoutent une seconde pile à exploiter au lieu de remplacer votre stockage principal.
Astuce : Avant d'adopter un moteur spécialisé, vérifiez si les extensions Postgres résolvent déjà le problème. pgvector pour les embeddings et la recherche plein texte native couvrent un nombre surprenant de cas d'usage sans ajouter un nouveau système à votre pile.
La dépendance au fournisseur est le coût silencieux de cette décision. Les API de requêtage propriétaires et les fonctionnalités disponibles seulement dans un cloud sont commodes jusqu'au jour où il faut changer de prestataire, et les migrations hors d'une couche de données propriétaire coûtent en général bien plus cher que ce que la décision initiale laissait entendre. La compatibilité Postgres, même sur un service cloud managé, garde cette porte de sortie ouverte. Si vous bâtissez votre plan de migration sur les patrons d'architecture SaaS multi-tenant dès le départ, cette portabilité est presque gratuite.
Mettre à l'échelle une base à table partagée est une suite de décisions, pas un grand choix d'architecture unique. Déroulez-les à peu près dans cet ordre à mesure que la charge augmente :
tenant_id ou par plage de dates résout la plupart des problèmes de performance bien avant que vous ayez besoin d'un véritable sharding horizontal sur des instances de bases distinctes.Le cache (Redis ou équivalent) vous fait gagner du temps à chacune des couches ci-dessus, mais c'est un correctif de performance, pas un substitut à la résolution du schéma d'accès aux données sous-jacent.
Le choix du modèle d'exploitation revient à décider quelle part du travail d'infrastructure votre équipe veut assumer, et il se décline en trois options réelles : le managé toujours actif, le serverless avec mise à l'échelle jusqu'à zéro, et l'auto-hébergement.
Les services entièrement managés (Amazon RDS, Google Cloud SQL, les offres Postgres managées) prennent en charge les correctifs, les sauvegardes et le basculement, mais vous payez la capacité provisionnée que vous l'utilisiez ou non. La définition du serverless par AWS pose ici une distinction importante : un vrai serverless qui descend à zéro et facture à la requête est opérationnellement différent d'une instance managée qui se contente de s'auto-ajuster. Les fournisseurs commercialisent les deux sous l'étiquette « serverless », et la différence pèse sur votre facture.
Les options hébergées en périphérie comme Cloudflare D1 poussent les bases SQL jusqu'à l'edge, avec une isolation par base et une réplication de lecture mondiale, ce qui convient bien aux usages cloisonnés par client ou par projet, mais ne remplace pas tel quel un stockage OLTP centralisé qui gère des jointures complexes entre clients.
Astuce : Demandez directement à tout fournisseur serverless si son modèle tarifaire facture zéro au repos. Le mot « serverless » dans le nom du produit ne garantit pas une facturation qui descend à zéro.
La plupart des éditeurs SaaS n'ont pas besoin d'écritures actives-actives multi-régions, et concevoir pour cela prématurément ajoute une vraie complexité à chaque changement de schéma que vous livrerez ensuite. Commencez par une seule région primaire, des réplicas de lecture inter-régions et un plan de basculement documenté. Réservez l'actif-actif aux produits pour lesquels une latence inférieure à 100 ms entre continents ou une résidence des données imposée par la réglementation l'exigent vraiment.
Les plateformes SQL distribuées comme Amazon Aurora DSQL annoncent des lectures et des écritures actives-actives multi-régions avec de fortes garanties de cohérence, ce qui résout le problème difficile mais ajoute une surcharge de coordination et un coût que les architectures mono-région évitent complètement.
Les principaux compromis à peser avant de passer au multi-région :
Choisir une base sur le papier et en choisir une qui survit à la production sont deux exercices différents. Déroulez cette liste de contrôle avant de graver votre décision :
Les équipes qui quittent des outils de back-office souples sous-estiment souvent cette étape. Si vous migrez d'une plateforme comme Airtable vers une base de production, les points à considérer pour la migration diffèrent de ceux d'un simple passage d'une base à une autre, puisque vous refondez aussi votre modèle de données de zéro.
Sur les projets multi-tenants que Kreante a construits, l'échec récurrent n'est pas d'avoir choisi Postgres ou d'avoir choisi le NoSQL. C'est d'avoir sauté l'étape de validation et de découvrir que le modèle de tenancy ne tient pas une fois que de vrais clients arrivent avec de vrais volumes de données. Notre chemin pratique : prototyper vite sur du Postgres managé avec une sécurité au niveau des lignes qui applique l'isolation des clients, lancer des tests de charge sur un mélange de clients réaliste, puis durcir la stratégie de sharding et de connexions à partir de ce que les tests révèlent réellement.
Cette approche met un système fonctionnel entre les mains des utilisateurs en quelques semaines. Là où elle atteint ses limites, c'est sur les topologies de sharding complexes, les vraies exigences d'actif-actif mondial ou une isolation réglementaire stricte par client. Ces situations gagnent à faire intervenir des ingénieurs qui ont déjà résolu exactement ce problème, puisque le coût d'une erreur s'aggrave avec chaque client que vous embarquez ensuite.
— Jorge Del Carpio
Pour des bases techniques plus solides, parcourez la documentation de Microsoft sur les modèles de tenancy, le guide de sélection de base de données d'AWS et ce retour d'expérience de praticien sur le choix d'une base SaaS. Pour le contexte côté croissance une fois votre plateforme en ligne, voyez cet article sur l'automatisation des tâches de croissance SaaS.
Si les décisions d'architecture ci-dessus vous semblent dépasser le cadre d'un projet de week-end, c'est une lecture juste. L'équipe de développement d'applications web et mobiles de Kreante construit et durcit exactement ces systèmes multi-tenants, du premier prototype jusqu'à l'échelle de production, et vous gardez le code dans tous les cas.
MySQL convient aux backends SaaS multi-tenants qui encaissent des écritures concurrentes de nombreux utilisateurs à la fois, tandis que SQLite donne le meilleur de lui-même dans des scénarios embarqués, mono-utilisateur ou en périphérie, plutôt que sur des charges OLTP multi-tenants centralisées.
Les grandes catégories sont le relationnel (Postgres, MySQL), le documentaire/NoSQL (MongoDB, DynamoDB), les magasins clé-valeur, les bases de séries temporelles, les moteurs de recherche, les bases vectorielles et les plateformes SQL distribuées, chacune adaptée à des schémas d'accès différents au sein d'une pile SaaS.
Cela dépend de l'implémentation : un vrai serverless qui descend à zéro peut réduire fortement les coûts au repos, mais beaucoup de produits « serverless » sont des instances managées auto-ajustables qui facturent tout de même un tarif de base, alors vérifiez quel modèle un fournisseur propose réellement.
Oui, et les configurations hybrides sont courantes : la plupart des éditeurs SaaS conservent la table partagée pour la majorité de leurs clients tout en migrant certains comptes gros ou régulés vers leur propre schéma ou leur propre base selon les besoins.
Le SaaS demeure un modèle de distribution logicielle dominant, même si la hausse des coûts d'infrastructure et des fonctions d'IA pousse les entreprises à examiner leurs choix de base de données et d'hébergement de plus près que les années précédentes pour protéger leur marge.
Pour aller plus loin
Ne laissez pas votre veille s'arrêter ici. Explorez nos autres ressources pour maîtriser votre stack technologique.
DevelopmentAnalyse pour développeurs des frameworks d'agents IA en production : graphe ou boucle, observabilité, gouvernance et prototypage en quelques semaines.
DevelopmentGuide CI/CD mobile par framework pour les équipes : quand choisir une CI managée, généraliste ou auto-hébergée, et une checklist en 3 étapes.
DevelopmentDécouvrez une planification d’architecture efficace pour réduire vos coûts de développement de 30 à 50 %. Les documents clés et les étapes à suivre.