La plupart des guides sur les meilleures pratiques d’architecture SaaS multi-locataire ressemblent à des listes de contrôle d’ingénierie, c’est pourquoi elles sont si faciles à ignorer dans la salle du conseil. L’aspect le plus important que ces listes de contrôle omettent est que votre architecture est également une ligne dans votre compte de résultat. Votre modèle de locataire, vos niveaux de stockage, votre pile d’inférence, vos couches de mise en cache et votre facture d’observabilité se combinent pour fixer le plafond de votre marge brute. Une fois que vous l’atteignez, aucune quantité d’héroïsme commercial ne pourra la relever.
Les chiffres sont inconfortables car les entreprises traditionnelles de Software-as-a-Service (SaaS) fonctionnent avec une marge brute de 70 à 85 %, tandis que le SaaS à forte composante IA se situe à un niveau structurellement plus bas, environ 50 à 65 %. Cet écart dépend rarement de la qualité du code écrit par votre équipe. Il s’agit de cinq paris architecturaux que vous faites tôt et qu’il devient douloureux d’annuler plus tard. Chez Redwerk, nous développons des produits SaaS depuis 2005, et nous pouvons généralement vous dire où se situe votre plafond avant même de voir vos tableaux de bord. Aujourd’hui, nos architectes logiciels vous expliqueront les cinq paris qui détermineront où le vôtre atterrira.
Pourquoi les meilleures pratiques d'architecture SaaS multi-locataire sont une conversation de DAF
Lorsque votre Directeur Financier (DAF) examine votre marge brute SaaS, il voit trois éléments :
- Ce que vous facturez
- Ce qu’il en coûte pour livrer le produit
- Comment ces deux éléments évoluent avec votre nombre de clients
Cependant, lorsque votre Directeur Technique (CTO) examine votre architecture, il voit les modèles de locataires, les modèles de données, les flux de calcul et les coûts d’infrastructure. Ce sont les mêmes conversations dans deux langues différentes, et la plupart des entreprises ne font la traduction entre les deux que lors de la vérification préalable (due diligence), lorsqu’il est trop tard pour changer grand-chose.
C’est le fossé que nous voulons combler aujourd’hui, et nous commencerons par citer les recherches de Bessemer Venture Partners dans les rapports State of AI, qui révèlent que la plupart des entreprises exploitant l’IA perdent six points de marge brute ou plus directement à cause de choix d’infrastructure, l’écart entre les plus performants et les moins performants suivant de près la maturité de l’infrastructure.
Nous définirons un pari comme une décision à faible possibilité de retour en arrière et à fort impact, prise dans l’incertitude. Les cinq paris ci-dessous définissent votre plafond de marge, et chacun s’accompagne de trois éléments que votre conseil d’administration finira par demander : le calcul de la marge, le coût de retour en arrière, et le signal qui vous indique que vous avez déjà parié faux.
Pari n°1 : Votre modèle de locataire est le plus grand levier de l'architecture SaaS multi-locataire
C’est la décision fondamentale, et celle que nous voyons le plus souvent regretter par les équipes. Vous avez trois options réalistes :
- Modèle mutualisé (où plusieurs locataires partagent une seule instance d’application)
La multi-location mutualisée offre la marge brute que les investisseurs aiment, car les coûts augmentent de manière sous-linéaire à mesure que vous ajoutez des clients. Vous pouvez atteindre 75 à 85 % sans transpirer. Cependant, le hic est que votre premier client d’entreprise réglementé demandera une véritable isolation des données, et si vous n’avez pas de réponse, vous perdrez l’affaire ou ajouterez un compromis qui pollue l’architecture pour tous les autres. - Modèle isolé (où chaque locataire a sa propre pile dédiée)
La multi-location isolée est l’inverse de la mutualisée. Les ventes aux entreprises deviennent plus faciles car l’isolation est intégrée, mais votre coût des marchandises vendues (COGS) augmente désormais de manière à peu près linéaire avec chaque nouveau client. En pratique, les SaaS fortement isolés plafonnent autour de 60 à 68 % de marge brute une fois que la part des entreprises dépasse 40 % des revenus. - Modèle hybride “Mutualisé de mutualisés” (où vous regroupez les locataires par niveau ou par profil de conformité)
Le modèle hybride est celui où la plupart des scale-ups réussies atterrissent, et où la plupart d’entre elles aimeraient avoir commencé. Vous mutualisez agressivement votre niveau de self-service, isolez les clients réglementés ou les plus importants, et faites fonctionner le tout à partir de plans de contrôle partagés. AWS publie des orientations de référence solides sur ce compromis dans son SaaS Lens for the Well-Architected Framework, et cela vaut la peine d’être lu avant de choisir une voie.
Regardons comment ce pari se déroule pour une entreprise dans des conditions réelles :
- Mathématiques des marges : Passer d’un modèle purement isolé à un modèle hybride bien conçu permet de récupérer couramment 8 à 12 points de marge brute. Sur une entreprise avec 20 millions de dollars de revenus annuels récurrents (ARR), cela représente 1,6 à 2,4 millions de dollars qui tombent au bas de la ligne chaque année.
- Coût de réversibilité : Élevé car une ré-architecture complète prend généralement 6 à 12 mois de temps d’ingénierie, plus des fenêtres de migration locataire par locataire.
- Signal que vous avez parié faux : Votre marge brute stagne tandis que l’ARR continue de croître, votre facture d’hébergement évolue au même rythme que le nombre de locataires, et les rapports COGS par locataire montrent que les clients de la longue traîne brûlent plus de 100 % de leurs revenus mensuels récurrents (MRR).
Pari n°2 : Partitionnement des données et hiérarchisation du stockage pour un SaaS évolutif
Une fois que vous avez choisi un modèle de locataire, vous devez décider comment partitionner les données sous-jacentes. Les options réalistes sont :
- Une base de données partagée avec une colonne identifiant le locataire
- Une approche schéma-par-locataire au sein d’une base de données partagée
- Une configuration complète base de données-par-locataire. Chacune échange l’isolation contre l’économie
Le levier de marge le plus important que la plupart des équipes ignorent est la hiérarchisation du stockage. Le stockage objet cloud devient considérablement moins cher à mesure que l’on passe des niveaux chauds aux niveaux tièdes, puis aux niveaux froids, mais la plupart des entreprises SaaS que nous auditons paient des tarifs de niveau chaud pour 100 % de leurs données, y compris des journaux de 2022 qui n’ont pas été interrogés depuis 18 mois. Corriger cela n’est pas un travail d’ingénierie glamour, mais cela rapporte.
- Calcul de la marge : Les règles de cycle de vie appropriées sur une facture de stockage réduisent généralement les coûts de 40 à 60 % sans impact visible pour l’utilisateur. Une facture Amazon Simple Storage Service (S3) de 180 000 $ par mois s’élève généralement à environ 75 000 $ après hiérarchisation.
- Coût de retour en arrière : Moyen, car la migration des données coûte des cycles d’ingénierie, mais c’est une quantité connue et généralement un projet d’un trimestre.
- Signal que vous avez parié faux : La croissance du stockage dépasse la croissance des revenus, la latence p95 augmente avec le nombre de locataires plutôt qu’avec le volume des requêtes, et vous avez eu au moins un incident de ‘voisin bruyant’ qui vous a obligé à surprovisionner.
Pari n°3 : L'architecture des coûts d'inférence est la nouvelle ligne budgétaire de la scalabilité SaaS
C’est le pari que la plupart des entreprises développant des SaaS en 2024 et 2025 n’avaient pas dans leur budget. Si vous avez lancé une fonctionnalité d’IA au cours des 24 derniers mois, les coûts d’inférence constituent désormais une dépense réelle et croissante de vos coûts variables (COGS), et leur comportement diffère de tout le reste de votre infrastructure.
Bain Capital Ventures rapporte que les coûts de calcul pour les produits basés sur l’IA s’élèvent à environ une à trois fois leurs coûts d’hébergement logiciel, ce qui, sur un compte de résultat SaaS traditionnel, fait la différence entre une excellente marge et une marge médiocre. L’étude ICONIQ Capital’s 2026 State of AI place l’inférence à environ 23 % du chiffre d’affaires pour les entreprises B2B d’IA en phase de croissance, et cette part ne diminue pas significativement à mesure qu’elles se développent.
Les choix architecturaux qui comptent ici sont concrets : le routage des modèles (essayer d’abord un modèle peu coûteux, se rabattre sur un modèle plus performant uniquement si nécessaire), la mise en cache sémantique afin que les requêtes similaires ne frappent pas le modèle deux fois, la Génération Augmentée par Récupération (RAG) plutôt que le fine-tuning lorsque vos données changent souvent, et des budgets de jetons par locataire qui empêchent un utilisateur intensif de grignoter votre marge.
- Les calculs de marge : Une fonctionnalité d’IA bien architecturée coûte généralement 5 à 8 points de marge brute. Une fonctionnalité naïve en coûte 15 à 22.
- Coût de réversibilité : Moyen, car la mise en cache et le routage peuvent être ajoutés a posteriori, mais l’architecture des prompts et la conception de la récupération des données sont plus tenaces qu’il n’y paraît.
- Signal que vous avez fait le mauvais choix : Le coût marginal des COGS augmente considérablement avec les utilisateurs intensifs, l’économie unitaire s’inverse pour vos 10 % de comptes les plus actifs, et votre équipe financière ne peut pas vous indiquer le coût d’inférence par locataire lorsque vous le demandez.
Si votre pile d’IA est construite sur des appels chaînés et que votre équipe débat des frameworks d’orchestration, consultez notre analyse approfondie de LangChain vs LangGraph, qui s’inscrit parfaitement dans cette décision.
Pari n°4 : La mise en cache est un levier de revenus, pas seulement un outil de performance
La plupart des équipes d’ingénierie abordent la mise en cache comme un problème de latence. Votre DAF la considérerait comme un levier de marge brute de 8 points s’il savait comment poser la question. Chaque requête que vous servez depuis un cache est une requête que votre backend n’a pas eu à calculer, ce qui signifie moins de temps processeur (CPU), moins de lectures de base de données, moins de trafic sortant, et des factures d’invocation de modèle plus faibles si vous utilisez l’IA.
Une hiérarchie de cache bien conçue pour le SaaS multi-locataire ressemble à ceci :
- Un cache périphérique pour les actifs publics et à évolution lente
- Un cache au niveau applicatif pour les données par locataire
- Des réplicas de lecture de base de données pour les modèles de requêtes lourds
- Un cache sémantique, si vous avez des fonctionnalités IA
Obtenir une invalidation sensible au locataire est la partie difficile, et celle qui vous fait économiser une fortune lorsque vous le faites tôt.
- Calcul de la marge : La mise en cache sensible au locataire sur les charges de travail à forte lecture réduit couramment les coûts de calcul de 20 à 40 %, et la mise en cache sémantique sur les points d’accès IA peut réduire les dépenses d’inférence de 30 à 50 % une fois le trafic stabilisé.
- Coût de retour en arrière : Faible, car la mise en cache est presque toujours additive, et vous pouvez l’introduire par couches sans réécriture.
- Signal que vous avez parié faux : Votre facture de calcul augmente plus rapidement que vos utilisateurs actifs mensuels (MAU), la latence p95 augmente plus rapidement que le trafic, et votre taux de succès de cache sur les points d’accès chauds est inférieur à 60 %.
Pari n°5 : Dépenses d'observabilité en pourcentage du coût des marchandises vendues (COGS) dans votre architecture SaaS
Voici le pari que personne ne met au tableau, car cela ressemble à une décision d’approvisionnement. Une fois que vous dépassez environ 5 millions de dollars de revenus annuels récurrents (ARR), les outils d’observabilité commencent discrètement à engloutir 5 à 10 % des revenus. Nous avons audité des entreprises où la facture d’observabilité apparaissait dans le rapport mensuel du conseil d’administration, et pourtant personne ne la qualifiait de problème de marge.
Les décisions importantes sont la stratégie d’échantillonnage (vous n’avez pas besoin de 100 % des traces avec 100 % de rétention), les fenêtres de rétention par niveaux (7 jours chauds, 30 jours tièdes, 90 jours archivés conviennent à la plupart des équipes), et une vision claire des outils qui justifient réellement leur coût. Quatre outils qui se chevauchent sont presque toujours deux de trop.
- Calcul de la marge : L’observabilité peut représenter 3 % des revenus ou 10 % des revenus tout en offrant globalement la même valeur opérationnelle. C’est un changement de marge brute de 7 points pour ce qui est, fondamentalement, une décision d’approvisionnement et de configuration.
- Coût de retour en arrière : Faible à moyen, car les migrations d’outils sont pénibles, mais ce sont des projets limités, généralement un trimestre au maximum.
- Signal que vous avez parié faux : La croissance de la facture d’observabilité a dépassé la croissance des revenus, vous utilisez quatre outils ou plus qui se chevauchent, et votre équipe ne se souvient plus de ce que la moitié d’entre eux surveillent réellement.
Test de résistance de 30 minutes pour vos meilleures pratiques d'architecture SaaS
Avant de faire appel à qui que ce soit (y compris nous), effectuez ce test de résistance rapide. Répondez aux six questions avec des chiffres précis, et votre architecture SaaS est probablement en bon état. Si vous bloquez sur deux questions ou plus, une analyse plus approfondie s’impose.
- Pouvez-vous produire les COGS par locataire en moins de 10 minutes ?
- Vos 10 utilisateurs les plus actifs ont-ils une marge unitaire positive après les coûts d’inférence ?
- Quel pourcentage de votre stockage est actuellement en « hot-tier », et devrait-il l’être ?
- Quel est votre taux de succès de cache sur vos cinq points d’accès les plus importants ?
- Quel pourcentage de votre chiffre d’affaires dépensez-vous en outils d’observabilité ?
- Combien de temps faudrait-il pour déplacer un client d’un modèle de tenancy à un autre ?
Si vous préférez qu’un autre regard examine vos réponses, notre équipe de conseil en développement logiciel réalise ce type d’audit d’architecture et de marge dans le cadre d’une mission à périmètre fixe. Votre architecture a déjà déterminé votre plafond de marge brute, que quelqu’un de l’équipe l’ait dit à voix haute ou non. Cependant, si vous souhaitez approfondir et voir ce que vous pouvez réellement changer, contactez-nous. Notre équipe pourra vous indiquer où se situe ce plafond, s’il vaut la peine de le déplacer et quel en serait le coût.
FAQ
Quelles sont les meilleures pratiques pour une architecture SaaS multi-locataire ?
Les pratiques qui comptent réellement sont liées à la marge brute :
- Choisissez un modèle de tenancy adapté à votre clientèle (mutualisé, isolé ou hybride)
- Organisez votre stockage par niveaux pour qu’il corresponde aux modèles d’accès
- Concevez l’inférence IA avec routage et mise en cache dès le départ
- Considérez la mise en cache comme un levier économique
- Maintenez les dépenses d’observabilité en dessous de 5 % du chiffre d’affaires
Tout le reste est un prérequis standard.
Quel est l'impact de l'architecture SaaS sur la marge brute ?
Votre architecture fixe le plafond de la marge brute en déterminant comment les COGS évoluent avec le nombre de clients et l’intensité d’utilisation. La multi-tenancy mutualisée peut soutenir une marge brute de 75-85 % à l’échelle, tandis que les modèles entièrement isolés plafonnent généralement autour de 60-68 %. Les fonctionnalités d’IA ajoutent une nouvelle couche de coûts variables qui réduit la marge de 15 à 22 points si l’inférence est conçue de manière naïve, et seulement de 5 à 8 points si elle est bien pensée.
Quelle est la différence entre la multi-tenancy mutualisée, isolée et hybride ?
La multi-tenancy mutualisée signifie que de nombreux clients partagent une seule instance d’application, maximisant ainsi l’efficacité mais rendant l’isolation stricte plus difficile. La multi-tenancy isolée donne à chaque client sa propre pile technologique, ce qui simplifie la conformité mais fait croître les COGS linéairement avec le nombre de clients. La multi-tenancy hybride regroupe les clients en pools par niveau ou par besoin de conformité, vous offrant la plupart des avantages économiques du mutualisé tout en isolant les clients qui en ont réellement besoin.
Quelle marge brute une solution SaaS multi-locataire devrait-elle viser en 2026 ?
Les produits SaaS traditionnels devraient viser une marge brute de 70 à 85 % à l’échelle, les produits axés sur les entreprises atteignant le haut de cette fourchette. Les produits SaaS fortement axés sur l’IA fonctionnent généralement à 50-65 % en raison des coûts d’inférence, et des recherches récentes d’ICONIQ suggèrent que la société B2B d’IA médiane se situera autour de 52 % en 2026, à moins qu’elle ne s’oppose activement à ce plafond.
Quand faut-il refondre une architecture pour la multi-tenancy ?
Refondez votre architecture lorsque votre marge brute stagne malgré la croissance de l’ARR, lorsque les rapports COGS par locataire révèlent que les clients de la longue traîne consomment leur propre MRR, ou lorsque votre modèle de tenancy bloque un segment d’affaires que vous souhaitez débloquer. Une refonte de 9 à 12 mois est coûteuse, mais un gain de marge de 10 points sur une entreprise avec 20 millions de dollars d’ARR la rentabilise environ trois fois dès la première année.
Découvrez comment nous avons aidé le logiciel Project Science de Complete Network à améliorer de 80 % la maintenabilité de son code
