Multi-tenancy expliqué :1 base de données, 1 000 clients

Multi-tenancy expliqué : la multi-tenancy, c'est plusieurs clients qui partagent une seule base de données, chacun ne pouvant voir que ses propres données. C'est ainsi qu'un fondateur solo sert 1 000 organisations depuis une seule application sans rien reconstruire, et cela fonctionne grâce à une colonne qui doit figurer sur chaque table dès le premier jour : organization_id.

Si vous construisez un SaaS avec l'IA, c'est l'une des rares décisions d'architecture que vous ne pourrez pas corriger à bas prix plus tard. Voici ce qu'est la multi-tenancy, pourquoi le mauvais choix coûte des mois, et les règles exactes à donner à votre IA pour qu'elle le fasse correctement.

Multi-tenancy expliqué : l'analogie de l'immeuble d'appartements

Voyez votre SaaS comme un bâtiment. Chaque client est un locataire. Vous avez deux options.

Vous pouvez construire une maison séparée pour chaque client. Chaque maison a besoin de ses propres fondations, sa plomberie, son entretien. Dix clients, dix maisons. Mille clients, mille maisons, et quand vous voulez moderniser la cuisine, vous rénovez mille cuisines.

Ou vous construisez un seul immeuble. Une seule fondation, une seule plomberie, une seule équipe d'entretien. Chaque locataire a son propre appartement, sa propre serrure, sa propre clé. Personne ne peut entrer chez un voisin, mais vous n'entretenez qu'un seul bâtiment.

La multi-tenancy, c'est l'immeuble. Une application, une base de données, un déploiement, au service de chaque client, chacun ne voyant que ses propres données. C'est l'architecture standard de presque tous les produits SaaS que vous utilisez, et c'est ce qui rend possible l'économie d'un SaaS à l'échelle d'un solo.

Les trois façons de servir 1 000 clients

Techniquement, il y a trois approches. Une seule a du sens pour un fondateur solo :

La troisième option est celle sur laquelle le secteur a convergé, et c'est le sujet de cet article. Une seule base à maintenir. Un seul changement à exécuter quand vous améliorez quelque chose. Une seule sauvegarde. Et vous pouvez passer de 1 à 10 000 clients sans changer de schéma.

La colonne dont chaque table a besoin

Voici la règle d'or : chaque table qui stocke des données clients doit avoir une colonne organization_id. Pas « devrait avoir ». Pas « on peut l'ajouter plus tard ». Doit avoir, dès le premier jour.

Pas besoin d'écrire du code pour comprendre. Conceptuellement, chaque ligne de votre base reçoit une étiquette indiquant à quel client elle appartient. Dans la table des tâches d'un gestionnaire de tâches, « Concevoir la page d'accueil » porte l'étiquette d'Acme ; « Revoir les chiffres du T3 » porte celle de TechStart. Chaque fois que l'application lit des données, elle ne demande que les lignes portant l'étiquette du client courant. Chaque fois qu'elle écrit des données, elle appose cette étiquette sur la nouvelle ligne. Acme voit les tâches d'Acme. TechStart voit celles de TechStart. L'étiquette est la clé de l'appartement.

Cela semble fastidieux. C'est aussi la fondation qui fait tenir tout le reste, y compris la couche de sécurité qui l'applique automatiquement au niveau de la base de données, et qui mérite (et aura) son propre article.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

« Mais je n'ai qu'un seul client pour l'instant »

Je l'entends constamment. Voici le film qui se déroule quand on saute la multi-tenancy :

• Jour 1 : vous construisez pour un client. Tout fonctionne. Pas besoin d'étiquettes : toutes les données lui appartiennent de toute façon.
• Jour 30 : vous décrochez un deuxième client. Les deux clients voient maintenant les données de l'autre. Panique. Poser l'étiquette sur chaque table après coup représente environ trois semaines de travail, une interruption de la production et des clients furieux.
• L'autre film : vous construisez avec organization_id dès le jour 1. Au jour 30, le deuxième client fonctionne tout simplement. Au jour 300, vous avez 100 clients et n'avez fait aucun changement dans la base de données.

Un ami à moi a construit son SaaS sans multi-tenancy. Arrivé à son 10e client, il a passé trois mois à reconstruire toute sa base de données. Trois mois sans nouvelle fonctionnalité pendant que les clients attendaient. Ne soyez pas cette personne.

C'est aussi pourquoi je martèle l'importance de concevoir la base de données avant de prompter : les décisions qui ne coûtent presque rien le premier jour (une colonne, une habitude) deviennent brutalement chères au jour 300.

Les trois règles qui gardent tout rapide et sûr

Règle 1 : étiquetez chaque table, sans exception. Dès qu'une table n'a pas organization_id, cette table est une fuite de données en attente. Quand vous briefez votre IA, faites-en une instruction permanente, pas une demande ponctuelle : c'est exactement le genre de règle qui relève de vos décisions de niveau architecte, car l'IA la sautera volontiers si vous n'insistez pas.

Règle 2 : indexez l'étiquette. Un index est l'annuaire de la base de données : il lui permet de sauter directement aux lignes d'un client au lieu de lire chaque ligne pour vérifier l'étiquette. La différence n'est pas théorique : avec 1 million de lignes réparties sur 1 000 organisations, une recherche sans index prend environ 2 000 millisecondes. Avec un index, la même recherche en prend environ 5. Demandez à votre IA d'ajouter un index sur organization_id pour chaque table qu'elle crée.

Règle 3 : ne faites jamais confiance au navigateur pour dire qui demande. L'identité du client doit provenir de la session de connexion côté serveur, jamais de quelque chose qu'envoie le navigateur. Si un utilisateur malveillant peut dire à votre application « je suis l'organisation X », il peut lire les données de l'organisation X. Le serveur sait qui est connecté ; c'est la seule source de vérité.

Trois règles. Une colonne. C'est la différence entre une démo et un produit que vous pouvez vendre à votre deuxième, votre dixième et votre millième client.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Que signifie la multi-tenancy en termes simples ?

Plusieurs clients (locataires) partagent une seule application et une seule base de données, mais chacun ne voit que ses propres données. Comme un immeuble : une structure, de nombreux appartements privés, une clé par locataire. C'est l'architecture standard des produits SaaS.

Ai-je besoin de la multi-tenancy si je n'ai qu'un seul client ?

Oui, c'est précisément le moment où elle ne coûte rien. Ajouter une colonne organization_id dès le premier jour ne vous coûte rien. La rattraper après l'arrivée du deuxième client coûte des semaines ; un fondateur que je connais a passé trois mois à tout reconstruire au dixième client. Intégrez-la dès la première table.

L'IA peut-elle mettre en place la multi-tenancy pour moi si je ne sais pas coder ?

Oui, si vous lui donnez la règle explicitement : « chaque table qui stocke des données clients doit avoir une colonne organization_id, avec un index, et chaque requête doit filtrer dessus ». Les outils d'IA suivent ce schéma de façon fiable quand on le leur demande, et le sautent de manière imprévisible sinon. Vous fournissez la règle ; l'IA fournit l'implémentation.

Une base partagée est-elle assez sûre pour les données clients ?

Oui, quand c'est bien fait. L'étiquette organization_id plus la sécurité au niveau de la base (la sécurité au niveau des lignes, qui applique automatiquement l'étiquette à chaque requête) est la manière dont pratiquement tous les SaaS modernes gèrent l'isolation, la même approche qui sert des produits avec des milliers d'organisations. L'option risquée, c'est la version à moitié construite : base partagée, pas d'étiquettes, pas d'application de la règle.