Réponse courte. Un SaaS multi-tenant est une seule version du code qui sert tous les clients, chacun dans un espace étanche qu'on appelle un tenant. L'étanchéité ne vient pas d'une case à cocher : elle vient du tenant lu dans le jeton de connexion, jamais dans l'URL, d'un identifiant de tenant dans chaque table avec des politiques de lignes dans la base qui filtrent même quand le code oublie, et de tests qui tentent de lire un autre client à chaque livraison. Les données de la masse partagent une base ; les deux ou trois grands comptes qui l'exigent ont leur base dédiée, déplacés par un routeur de données sans changer une ligne du code. Les plans sont des données du tenant que le code lit, pas des versions différentes ; les quotas s'appliquent dans la couche d'autorisation ; les migrations partent par vagues et se renversent. Seize semaines, dont deux pour écrire le modèle de tenant avant tout code.
Ce guide s'adresse au fondateur installé en France qui veut vendre un logiciel par abonnement à des pharmacies, des écoles ou des agences en Algérie, à l'entreprise dont le prestataire a « dupliqué le projet » pour chaque client et qui en maintient quatorze copies, et à celui qui lit « architecture multi-tenant » dans un devis sans savoir ce que cela doit contenir. Il ne traite pas du modèle d'abonnement ni du paiement, décrits dans le guide sur le lancement d'un SaaS en Algérie en 2027 ; il traite de ce qui se construit pour que cent clients tiennent sur une seule installation sans se voir.
Ce que les chiffres disent
Les trois textes qui comptent sont publics. Amazon Web Services, dans sa lentille SaaS du cadre Well-Architected, nomme trois modèles : le silo, où chaque tenant a des ressources dédiées, par exemple sa propre base, tout en partageant identité, inscription et exploitation ; le pool, « la notion plus classique de multi-tenant », où les tenants partagent calcul, stockage et messagerie ; et le bridge, le mode mixte où certaines parties sont en silo et d'autres en pool, le profil réglementaire des données et le risque de voisin bruyant poussant un service vers le silo. Ce vocabulaire se transpose tel quel : la question d'un SaaS algérien n'est pas « silo ou pool » mais « quoi en silo, quoi en pool, et comment passer de l'un à l'autre sans réécrire ».
PostgreSQL, la base que nous utilisons pour la plupart des SaaS, documente la sécurité au niveau des lignes : une fois activée sur une table, « si aucune politique n'existe, une politique de refus par défaut s'applique » et aucune ligne n'est visible ; les superutilisateurs et les rôles marqués BYPASSRLS la contournent toujours, et le propriétaire de la table aussi, sauf si on la force ; la documentation prévient que les contraintes d'intégrité contournent les politiques et peuvent créer des canaux cachés. Ce sont des détails qui décident de la sécurité réelle : une politique de lignes activée mais non forcée, avec une application connectée en propriétaire, ne protège rien. L'OWASP, dans son Top 10 des API de 2023, place en première position la rupture d'autorisation au niveau des objets : un attaquant change un identifiant dans la requête et accède aux données d'un autre ; la parade est de vérifier l'autorisation « sur chaque fonction qui accède à un enregistrement à partir d'un identifiant fourni par le client », de préférer des identifiants aléatoires imprévisibles, et d'écrire des tests.
Le cas de mars 2026 le dit mieux qu'une règle. Un avis de sécurité publié le 8 mars 2026 pour OneUptime, une plateforme de supervision open source, décrit un en-tête HTTP que le client pouvait poser lui-même et qui désactivait le filtrage par tenant ; combiné à un en-tête d'identifiant de projet choisi, un utilisateur ordinaire listait et modifiait les projets d'autres clients et lisait le hachage de mot de passe et le jeton de réinitialisation de leur créateur, jusqu'à prendre le compte ; score 9,9 sur 10, corrigé dans la version suivante. Côté algérien, le terrain grandit : selon le directeur des startups au ministère de l'Économie de la connaissance, sur Radio Algérie le 11 février 2026, plus de 1 100 startups ont été labellisées depuis 2020, une dizaine seulement ont cessé, un label Scale-up existe depuis décembre 2025 et le ministère vise une quinzaine de scale-ups labellisées en 2026 ; d'autres sources avancent des comptes différents, et nous retenons le chiffre du ministère. Beaucoup de ces startups vendent un logiciel par abonnement, et c'est leur architecture qui décide si le centième client coûte autant que le premier. Ce que nous n'avons pas trouvé : un décompte des SaaS algériens ni une mesure de leur architecture ; ce guide parle de ce que nous construisons, pas d'une statistique.
La vie d'une requête dans un SaaS multi-tenant, en six moments
L'architecture ne se décrit pas par ses schémas de base mais par ce qui arrive à une requête, de la connexion d'un utilisateur à la ligne de journal qui alimentera sa facture.
La connexion émet un jeton qui porte l'identité de l'utilisateur, le tenant auquel il appartient et son rôle dans ce tenant ; la connexion elle-même, par numéro de téléphone ou par e-mail, suit le guide sur l'authentification par OTP, et un même utilisateur, un comptable par exemple, peut appartenir à plusieurs tenants et en choisir un à la connexion. Le tenant résolu est le moment qui décide de la sécurité : il vient du jeton, ou d'un sous-domaine vérifié contre le jeton, jamais d'un paramètre d'URL, d'un champ de formulaire ou d'un en-tête que le client peut écrire ; la faille de mars 2026 est exactement un en-tête que le client pouvait poser. Le contexte posé attache le tenant à la requête et le transmet à la session de base de données sous forme de variable ; tout ce qui suit, code, files, fichiers, le voit sans le redemander, et c'est ce qui empêche la ligne oubliée.
L'autorisation vérifie trois choses et refuse si l'une manque : le rôle de l'utilisateur dans ce tenant, le plan souscrit par le tenant, et les quotas qui lui restent ; c'est ici, et non dans l'écran, que le plan essentiel est empêché d'exporter dix mille lignes. La requête à la base touche des tables qui portent toutes une colonne de tenant, avec un index qui commence par elle, et des politiques de lignes activées et forcées : si un développeur oublie la clause de filtrage, la base la rajoute ; la politique est un filet, pas la première ligne de défense, et elle se teste avec un rôle qui n'est pas propriétaire. Le journal et la mesure écrivent chaque action avec son tenant : usage, erreurs, stockage, envois ; c'est ce journal qui alimente les compteurs de quotas, la facture en dinars et l'écran qui dit quel tenant consomme quoi, dans l'esprit du guide sur le tableau de bord.
Le SaaS multi-tenant, en cinq couches
Derrière les six moments, cinq couches, et celle du milieu est ce qui distingue un SaaS d'une collection de copies.
L'identité et les tenants : des comptes, des tenants, des membres, des rôles, des invitations, et la règle qu'un utilisateur peut appartenir à plusieurs tenants ; un tenant a ses administrateurs, qui invitent et retirent sans passer par le support. Les plans et quotas : des paliers, des fonctionnalités activées par palier, des limites et des compteurs ; le plan est une donnée du tenant que le code lit à chaque requête, jamais une version différente du code, et c'est ce qui permet de changer un client de plan en une minute. L'application : une seule version du code pour tous, avec le tenant comme contexte dans chaque requête, chaque tâche de fond, chaque fichier stocké ; une mise à jour sert tout le monde, et les fonctionnalités réservées à un palier sont des interrupteurs, pas des branches de code.
Les données : une base partagée avec politiques de lignes pour la masse, un schéma ou une base dédiée pour les grands comptes qui l'exigent, un routeur qui sait où vit chaque tenant, et, quel que soit le modèle, la sauvegarde, l'export et la suppression d'un tenant comme opérations unitaires. L'exploitation : un déploiement unique, des migrations par vagues, une supervision par tenant et une protection contre le voisin bruyant, files de travail et limites de débit par tenant ; on sait quel tenant consomme quoi, et on l'isole avant qu'il ralentisse les autres. Les couches du dessous décident du prix d'exploitation que décrit le guide sur la vie d'une application ; les couches du dessus décident de ce qu'on peut vendre, et le guide sur le SaaS en 2027 décrit comment on le vend.
«Un SaaS, c'est une seule version du code et le tenant comme contexte partout ; tout le reste est une collection de copies qu'on finit par ne plus oser toucher.»
Un exemple chiffré
Un exemple sur des hypothèses de marché, avec une mécanique qui n'en est pas : un SaaS vertical, deux ans après le lancement.
120 clients actifs sur une seule installation : des pharmacies, des cabinets, des boutiques, chacun avec ses utilisateurs, ses données, ses réglages, et aucun ne sait que les autres existent. 3 plans, essentiel, pro et entreprise : les fonctionnalités, le nombre d'utilisateurs, le stockage et les envois de messages viennent du plan ; passer un client du plan pro au plan entreprise est une écriture dans sa fiche, pas un déploiement. 2 clients sur base dédiée : un groupe de cliniques et un distributeur qui l'ont exigé au contrat, pour la restauration indépendante et la séparation visible ; le routeur de données les a déplacés hors de la base partagée en une opération, sans qu'une ligne du code change, et ils paient le plan entreprise qui couvre ce coût fixe.
Zéro installation par client est le résultat qui ne dépend d'aucune hypothèse : une mise à jour par semaine, la même pour les 120, déployée en quelques minutes, avec les migrations testées sur une copie de production et passées par vagues ; un client en lecture seule pendant trois minutes, jamais cent clients à mettre à jour un par un. Ce que l'exemple montre : avec le tenant comme contexte, le cent-vingtième client coûte un enregistrement dans la base et une ligne dans la supervision ; avec une copie par client, il coûte un serveur, un déploiement et une place dans la liste des choses qu'on n'ose plus toucher. Les hypothèses à vérifier chez vous : combien de clients, quelle part exigera sa base, et combien d'utilisateurs par client ; les deux premières semaines du projet y répondent.
Six façons de loger les données des clients
Six modèles, et un seul critère pour les juger : aucun ne doit changer le code de l'application.
La base partagée aux lignes protégées est le cas par défaut, des dizaines aux milliers de clients de taille ordinaire : une colonne de tenant dans chaque table, des politiques de lignes activées et forcées, et un test à chaque livraison qui tente de lire un autre tenant et doit échouer. Le schéma par client donne une séparation visible sans base dédiée ; il impose de répéter chaque migration sur chaque schéma et de gérer les connexions, et les retours de praticiens le disent lourd au-delà de quelques centaines de clients ; nous le réservons aux cas où un client veut voir sa séparation sans payer une base. La base par client est le silo d'AWS : grands comptes, données réglementées, contrat qui l'exige, besoin de restaurer un seul client ; coût fixe par client, sauvegardes et migrations multipliées, et un routeur qui sait quelle base sert quel tenant.
L'instance par client va plus loin : son propre serveur, son propre domaine, parfois son propre pays d'hébergement, mais identité, mise à jour et supervision restent partagées, sinon ce n'est plus un SaaS mais une série de projets, et le paiement de l'hébergement en devise suit le guide sur le paiement du cloud depuis l'Algérie. Le mixte est le cas réel de la plupart des SaaS après deux ans : la masse partage, deux ou trois grands comptes sont isolés, et seule la couche de données sait où vit chacun ; c'est le bridge d'AWS, et c'est ce que l'exemple chiffré décrit. L'installation chez le client est rare, une administration ou un groupe qui refuse le cloud ; c'est un paquet installable, des versions à suivre et un support différent, à facturer comme tel. La première ligne couvre la plupart des SaaS algériens en 2027 ; la cinquième est ce qu'ils deviennent quand un grand compte signe.
Six situations qui cassent un SaaS multi-tenant
Six situations que nous voyons sur les SaaS que nous reprenons, et ce que l'architecture fait contre chacune.
La fuite entre clients coûte la confiance : un utilisateur change un identifiant dans l'URL et voit les factures d'un autre client ; le tenant lu dans le jeton, la vérification sur chaque objet, les politiques de lignes en filet, des identifiants aléatoires et un test automatisé qui tente la fuite à chaque livraison la rendent improbable, et c'est l'ordre dans lequel l'OWASP les recommande. Le voisin bruyant : un client lance un export de deux millions de lignes à dix heures et ralentit tous les autres ; files de travail par tenant, limites de débit, exports asynchrones livrés par lien, quotas par plan, alerte par tenant. La migration qui casse un client : un changement de schéma passe pour 119 clients et échoue sur le 120e qui a des données anciennes ; migrations testées sur une copie de production, déployées par vagues, réversibles, le client en lecture seule le temps de la migration.
Le client qui veut ses données part, ou veut une copie, ou veut tout effacer ; export complet par tenant dans un format lisible, suppression d'un tenant en une opération journalisée, et le délai écrit au contrat, ce qui est aussi ce que le guide sur l'application bloquée chez un développeur disparu demande pour vos propres données. Le grand compte qui exige sa base signe à condition d'avoir sa base, son domaine, parfois son pays d'hébergement ; le routeur de données le déplace sans toucher au code, et le plan entreprise paie le coût fixe. Le plan qui ne limite rien : le plan essentiel consomme autant de stockage et d'envois que le plan entreprise, et les coûts montent avec les clients qui paient le moins ; compteurs par tenant alimentés par le journal, limites appliquées dans la couche d'autorisation, dépassement visible au client avec le bouton pour changer de plan. La première coûte la confiance, les cinq autres coûtent de l'argent ou des clients, et aucune ne se répare dans l'urgence.
«Le tenant vient du jeton, et de rien que le client puisse écrire.»
Vu ailleurs : AWS, PostgreSQL, OWASP, OneUptime, et ce qui se transpose
Quatre textes publics disent l'essentiel. AWS donne le vocabulaire, silo, pool, bridge, et la règle que la décision se prend ressource par ressource et non pour tout le système ; ce qui se transpose, c'est de décider la première semaine quoi partager et quoi isoler, et de construire le routeur de données qui permettra de changer d'avis pour un client sans réécrire. PostgreSQL dit ce que vaut une politique de lignes : tout est refusé par défaut une fois activée, les superutilisateurs et le propriétaire passent au travers sauf si on force, et les contraintes d'intégrité peuvent fuir ; ce qui se transpose, c'est que l'application se connecte avec un rôle qui n'est pas propriétaire, que la politique est forcée, et qu'un test la vérifie avec ce rôle-là.
L'OWASP dit où regarder : l'identifiant d'objet fourni par le client est la première cause de fuite entre clients, et la réponse est une vérification à chaque accès, des identifiants imprévisibles et des tests ; ce qui se transpose, c'est que « multi-tenant » dans un devis doit s'accompagner de « tests de fuite entre tenants à chaque livraison ». Le cas OneUptime de mars 2026 dit la forme que prend l'erreur dans la vraie vie : pas une base mal conçue, mais un en-tête que le client pouvait poser et qui désactivait le filtrage ; ce qui se transpose, c'est la règle du moment 02, le tenant vient du jeton et de rien d'autre. Ce que ces textes ne disent pas : quelle part de vos clients exigera sa base, et à quel prix vous la vendez ; c'est le pilote de la semaine 12 et le guide sur le SaaS en 2027 qui y répondent.
Les règles d'un SaaS multi-tenant qui tient
Six règles, écrites la première semaine et relues à chaque livraison. Une seule version du code : les plans sont des interrupteurs lus dans la fiche du tenant, jamais des branches ; une fonction demandée par un client se construit pour tous et s'active pour lui. Le tenant vient du jeton, ou d'un sous-domaine vérifié contre le jeton, et de rien que le client puisse écrire. Chaque table porte le tenant, l'index commence par lui, et les politiques de lignes sont activées, forcées et testées avec le rôle de l'application. Un test de fuite à chaque livraison : un utilisateur du tenant A tente de lire, modifier et supprimer dans le tenant B par tous les points d'entrée, et la livraison est refusée s'il y arrive une fois. Les opérations par tenant existent avant le premier client : export, suppression, restauration, déplacement vers une base dédiée. Les comptes, le code, les domaines et l'hébergement sont au nom de l'entreprise, pas du prestataire, et le code est livré dans un dépôt que vous possédez.
Une septième règle porte sur le cahier des charges : « architecture multi-tenant » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « une seule version du code sert tous les clients ; le tenant est résolu depuis le jeton ; chaque table porte tenant_id avec politiques de lignes forcées ; un test automatisé de fuite entre tenants fait partie de la recette ; l'export, la suppression et le déplacement d'un tenant vers une base dédiée sont des opérations livrées ; les plans et quotas s'appliquent dans la couche d'autorisation », et elle se vérifie à la recette, comme le recommande le guide sur le cahier des charges. Un devis qui écrit « multi-tenant » sans ces six lignes a chiffré une application à un seul client qu'on copiera.
Six SaaS verticaux, ce qui est partagé et ce qui est isolé
Six SaaS que nous construisons souvent, et pour chacun le modèle de données retenu la première semaine.
- Le SaaS pour pharmacies ou commerces. Base partagée, un tenant par officine, trois plans ; l'intégration avec la caisse et la comptabilité de chaque client suit le guide sur l'intégration des logiciels existants, avec un connecteur par tenant.
- Le SaaS pour écoles privées. Base partagée, un tenant par établissement, des parents qui appartiennent à plusieurs tenants quand ils ont des enfants dans deux écoles ; export complet exigé à chaque fin d'année.
- Le SaaS pour cliniques et cabinets. Base partagée pour les cabinets, base dédiée pour les groupes qui l'exigent ; politiques de lignes forcées et journal d'accès par tenant, parce que ce sont des données de santé.
- Le SaaS pour agences immobilières. Base partagée ; un propriétaire en France peut être membre de plusieurs agences ; l'espace propriétaire décrit dans le guide dédié est une vue filtrée par tenant et par bien.
- Le SaaS pour distributeurs. Base partagée pour la plupart, instance dédiée pour l'importateur qui a son ERP et son domaine ; le portail B2B de chaque distributeur, décrit dans le guide dédié, est un tenant avec ses détaillants comme membres.
- Le SaaS avec agent IA. Un agent WhatsApp par tenant sur la même plateforme, numéro et modèles au nom de chaque client, connaissances et journaux séparés par tenant ; l'architecture de l'agent suit le guide dédié.
Le calendrier 2027
Le calendrier est celui d'un SaaS multi-tenant en seize semaines, dont deux sans code et deux de pilote avec cinq clients réels sur la même installation.
Les semaines 0 à 2 écrivent le modèle de tenant : qui est un tenant, qui est membre, quels rôles, quels plans avec quelles limites, quel modèle de données par défaut et quel chemin vers la base dédiée ; un SaaS dont ce modèle est écrit après le code devient une collection de copies. Les semaines 2 à 4 construisent l'identité : inscription d'un tenant, invitations, rôles, connexion par téléphone ou e-mail, appartenance à plusieurs tenants. Les semaines 4 à 8 construisent le cœur métier avec le tenant partout : colonne de tenant dans chaque table et chaque file, politiques de lignes forcées, et le test de fuite qui tourne à chaque livraison dès la première. Les semaines 8 à 10 posent les plans, quotas et la facturation : paliers, interrupteurs par palier, compteurs, dépassements, factures en dinars et rappel avant échéance, sur le modèle décrit dans le guide sur le SaaS en 2027.
Les semaines 10 à 12 installent l'exploitation : migrations par vagues, sauvegarde et export par tenant, supervision par tenant, limites de débit, et le routeur de données testé en déplaçant un tenant de test vers une base dédiée et retour. Les semaines 12 à 14 sont le pilote : cinq clients réels sur la même installation, l'usage mesuré par tenant, et le premier grand compte isolé si l'un des cinq l'exige ; c'est le premier moment où deux clients partagent vraiment la même base. Les semaines 14 à 16 ouvrent : inscription en libre-service, onboarding automatique, premier plan payant, supervision en routine. Les startups qui visent le label, décrit dans le guide sur le label startup, ont intérêt à arriver au dossier avec ce pilote fait plutôt qu'avec une maquette.
Ce qui fait échouer un SaaS multi-tenant
Les SaaS que nous reprenons échouent presque toujours pour l'une de ces raisons.
- Une copie du code par client. Le troisième client a eu sa fonction, le quatorzième a sa version ; plus personne ne peut tout mettre à jour.
- Le tenant dans l'URL ou dans un en-tête. Un identifiant changé, et un client voit l'autre ; c'est la faille de mars 2026, et elle ne se répare que par une réécriture de l'autorisation.
- Les politiques de lignes activées mais pas forcées. L'application se connecte en propriétaire et passe au travers ; la sécurité n'existe que sur le papier.
- Aucun test de fuite. La fuite se découvre quand un client l'écrit sur les réseaux, pas à la recette.
- Le plan comme version du code. Trois plans, trois branches, et chaque correction se fait trois fois.
- Pas d'export ni de suppression par tenant. Le premier client qui part met trois semaines à récupérer ses données et le dit à tous les autres.
- Le grand compte traité par une copie. On duplique le SaaS pour lui ; six mois plus tard il a sa propre version et ses propres bugs.
Questions fréquentes
Les questions que nous recevons de fondateurs installés en France, d'entreprises qui reprennent un logiciel copié et d'équipes qui comparent des devis.
- Multi-tenant ou une installation par client : lequel choisir ?
- Multi-tenant pour tout SaaS vendu par abonnement : une seule version du code, le tenant comme contexte, et un routeur de données qui permet de donner une base dédiée aux deux ou trois clients qui l'exigent. L'installation par client est un produit différent, à facturer comme tel, et elle ne doit jamais être la réponse à une demande de fonction.
- Base partagée ou base par client ?
- Base partagée avec politiques de lignes forcées par défaut, pour la masse ; base dédiée pour les grands comptes, les données réglementées et les contrats qui l'exigent, déplacés par le routeur de données sans changer le code. La plupart des SaaS algériens finissent en mixte après deux ans, et l'architecture doit le prévoir dès la première semaine.
- Comment être sûr qu’un client ne voit pas les données d’un autre ?
- Par quatre couches qui se cumulent : le tenant lu dans le jeton et jamais dans la requête, la vérification d'autorisation sur chaque objet, les politiques de lignes activées et forcées dans la base avec un rôle applicatif qui n'est pas propriétaire, et un test automatisé qui tente la fuite à chaque livraison. Un devis qui ne mentionne pas le test n'a pas prévu les trois autres.
- Un client demande une fonction que les autres ne veulent pas. On copie ?
- Non : la fonction se construit dans la version unique et s'active pour ce client par un interrupteur de plan ou de tenant. Si elle est vraiment spécifique, elle est facturée comme développement et activée pour lui seul ; le code reste un. La copie est ce qui transforme un SaaS en quatorze projets.
- Que se passe-t-il quand un client part ?
- Il reçoit un export complet de ses données dans un format lisible, et son tenant est supprimé en une opération journalisée dans le délai écrit au contrat. Ces deux opérations existent avant le premier client ; elles sont la preuve que les données étaient bien séparées.
- Combien de temps pour construire un SaaS multi-tenant ?
- Seize semaines pour un SaaS vertical, dont deux pour écrire le modèle de tenant avant tout code, quatre pour le cœur métier avec le tenant partout, et deux de pilote avec cinq clients réels sur la même installation. Le modèle d'abonnement et le paiement se préparent en parallèle.