L'architecture multi-locataire expliquée sans jargon : un guide pour fondateurs

À un moment ou un autre, en construisant un produit logiciel, un développeur vous lancera le mot « multi-locataire », observera votre visage et supposera que vous avez compris. Vous avez sans doute hoché la tête. La plupart des fondateurs le font. Mais c'est l'une de ces décisions précoces qui fixe en silence le plafond : la vitesse à laquelle vous pouvez grandir, le coût auquel vous pouvez fonctionner et l'ampleur des dégâts possibles si un client voit un jour des données qui ne sont pas les siennes. Cela mérite dix minutes de votre attention maintenant, car y revenir plus tard coûte très cher.

Je me suis assis face à beaucoup de fondateurs non techniques — des personnes avec une idée affûtée de produit SaaS et sans intérêt particulier pour les bases de données. La bonne nouvelle, c'est que vous n'avez pas besoin d'apprendre à coder pour bien prendre cette décision. Il vous faut un modèle mental clair et une courte liste de questions. C'est exactement ce qu'est ce guide. Pas de mots à la mode, pas de schémas d'architecture que vous ne regarderez plus jamais, juste ce que votre développeur aimerait que vous compreniez avant la première ligne de code.

Si vous ne retenez qu'une idée, que ce soit celle-ci : la multi-location n'est pas une fonctionnalité que l'on ajoute plus tard. C'est une fondation. On peut repeindre une maison, mais on ne change pas facilement ce sur quoi elle repose une fois les murs montés.

Ce que « multi-locataire » signifie réellement

Imaginez un immeuble d'habitation. Chaque locataire a son propre appartement — sa propre clé, ses propres meubles, sa propre porte. Mais tous partagent la même structure : les fondations, la plomberie, le toit, l'ascenseur. Le propriétaire entretient un immeuble, pas cinquante maisons distinctes, et c'est ce qui rend le loyer abordable. Le logiciel multi-locataire fonctionne exactement ainsi. Une seule application sert de nombreux clients — des « locataires » — et chacun la vit comme son espace privé, bien qu'ils tournent tous sur le même système partagé en dessous.

L'approche inverse est le mono-locataire : chaque client reçoit sa propre copie séparée du logiciel, comme si l'on construisait une maison individuelle neuve pour chacun. Plus privé, plus personnalisable — et nettement plus coûteux à construire, à exploiter et à mettre à jour, car vous entretenez désormais cinquante maisons au lieu d'un immeuble.

Presque tous les produits que vous utilisez au quotidien sont multi-locataires. Votre messagerie, votre outil de comptabilité, votre système de réservation, le CRM dans lequel vit votre équipe commerciale. Vous et mille autres entreprises partagez le même logiciel sous-jacent, et aucun de vous ne voit jamais les autres. Cette invisibilité — cette séparation nette — est tout l'art de la multi-location.

Pourquoi cette décision touche toute votre entreprise

Il est tentant de classer cela sous « détail technique dont mon développeur s'occupe ». Mais le modèle que vous choisissez se répercute directement sur les aspects de l'entreprise qui vous tiennent vraiment à cœur : votre facture mensuelle d'hébergement, la rapidité avec laquelle vous pouvez livrer une nouvelle fonctionnalité à tous, ce que vous pouvez promettre à un acheteur grand compte inquiet, et l'ampleur des dégâts qu'un seul bug peut causer.

Lorsque vous corrigez un bug ou publiez une fonctionnalité dans un produit multi-locataire bien construit, tous les clients la reçoivent d'un coup, par une seule mise à jour. Dans un monde mono-locataire, vous déploieriez ce changement sur cinquante installations distinctes, chacune peut-être un peu différente à ce stade. L'une, c'est un mardi après-midi. L'autre, c'est un projet. Multipliez cela sur des années de mises à jour et vous comprendrez pourquoi l'industrie du SaaS repose sur la multi-location.

Le revers, c'est que partager l'infrastructure élève les enjeux de la séparation. Dans un immeuble, une fuite de plomberie peut toucher plus d'un appartement. Dans un logiciel multi-locataire, une erreur dans la manière de séparer les locataires ne gêne pas un seul client — elle peut exposer les données de tout le monde d'un coup. Ce n'est pas une raison d'éviter la multi-location. C'est la raison de la construire correctement, avec quelqu'un qui l'a déjà fait.

Les trois façons de séparer les locataires

Quand les développeurs débattent de la multi-location, ils débattent en général de à quel point les données de chaque locataire doivent être séparées. Il existe trois approches courantes, situées sur une échelle glissante allant de « partage maximal, coût minimal » à « séparation maximale, coût maximal ». Vous n'avez pas à en choisir une vous-même — mais vous devriez comprendre le compromis que votre développeur fait en votre nom.

1. Base de données partagée, tables partagées

Les données de tous résident dans la même base de données, dans les mêmes tables, avec une étiquette cachée — un « identifiant de locataire » — qui marque quelles lignes appartiennent à qui. Le logiciel est chargé de toujours filtrer selon cette étiquette, afin que le client A ne voie jamais que les lignes du client A. C'est le modèle le plus économique et le plus évolutif, celui qu'utilisent la plupart des jeunes produits SaaS. Le hic : la séparation vit dans le code, donc un seul filtre oublié suffit à faire fuiter les données. Cela exige une ingénierie soignée et rigoureuse.

2. Base de données partagée, compartiments séparés

Une seule base de données, mais chaque locataire y reçoit sa propre section cloisonnée (les développeurs les appellent des « schémas »). Séparation plus forte que le premier modèle, toujours raisonnablement efficace, et plus simple, par exemple, pour exporter ou supprimer proprement les données d'un client. Le compromis : davantage de pièces mobiles à gérer à mesure que vous montez vers des centaines et des milliers de locataires.

3. Une base de données distincte par locataire

Chaque client reçoit sa propre base de données dédiée — ce qui se rapproche le plus de lui offrir une maison privée tout en partageant l'application. C'est l'isolation la plus forte et l'histoire la plus facile à raconter à un acheteur grand compte soucieux de sécurité. C'est aussi la plus coûteuse à exploiter et à administrer, si bien qu'elle tend à être réservée aux clients à forte valeur, aux secteurs réglementés ou aux produits où une confusion de données serait catastrophique.

Ce que vous ne pouvez pas rater : l'isolation

S'il y a un endroit où dépenser votre inquiétude, c'est ici. L'isolation des locataires est la garantie que le client A ne pourra jamais, en aucune circonstance, voir, modifier ni même soupçonner l'existence des données du client B. Cela paraît évident. C'est aussi la source la plus fréquente de bugs graves dans les produits multi-locataires, car la défaillance est silencieuse — tout a l'air en ordre, jusqu'au jour où quelqu'un ouvre un rapport et y voit les clients d'un inconnu.

La raison en est structurelle. Dans le modèle le moins cher, chaque requête à la base de données doit penser à filtrer par locataire. Faites-le bien dix mille fois et mal une seule, et vous avez une fuite. C'est pourquoi les équipes expérimentées ne comptent pas sur la mémoire des développeurs — elles intègrent l'isolation dans la fondation, de sorte qu'oublier devienne impossible plutôt que simplement improbable. Vous n'avez pas besoin de comprendre comment elles s'y prennent. Vous devez demander si elles le font.

Il existe aussi un cousin plus discret de ce problème : le « voisin bruyant ». Comme les locataires partagent l'infrastructure, un client qui fait quelque chose de lourd — un import géant, un rapport incontrôlé — peut ralentir le système pour tous les autres, de la même façon qu'un appartement avec tous les robinets ouverts peut faire chuter la pression d'eau dans tout l'immeuble. Une bonne conception multi-locataire le prévoit avec des limites et un partage équitable. Cela vaut la peine de poser la question, surtout si vous attendez quelques très grands clients.

Quand le mono-locataire est vraiment le bon choix

La multi-location est le choix par défaut du SaaS, mais ce n'est pas une religion. Il existe de bonnes raisons de donner à un client sa propre copie séparée, et un bon conseiller vous dira quand vous êtes tombé sur l'une d'elles, plutôt que de tout forcer dans le modèle partagé.

• Un client d'un secteur réglementé — santé, finance, administration — dont les règles de conformité exigent de fait que ses données résident dans un lieu séparé de manière démontrable.
• Un unique grand client qui paie assez pour qu'une configuration dédiée en vaille la peine, et qui souhaite une personnalisation poussée que vous ne voulez pas voir déborder sur l'expérience des autres.
• Des données si sensibles que le coût d'une fuite inter-locataires mettrait fin à l'entreprise, rendant l'isolation maximale digne de la dépense supplémentaire.
• Une exigence d'installation sur site (on-premise), où le logiciel doit tourner à l'intérieur des murs du client plutôt que dans votre cloud.

Remarquez le schéma : le mono-locataire est l'exception vers laquelle vous tendez délibérément, en général pour un client précis à forte valeur, pas le choix par défaut sur lequel vous bâtissez toute l'entreprise. Si un développeur propose le mono-locataire pour votre produit standard dès le premier jour, demandez-lui de vous expliquer pourquoi — cela signifie en général un coût d'exploitation bien plus élevé et des mises à jour plus lentes, et vous voulez que ce soit un choix, pas un accident.

Les questions à poser avant que quiconque n'écrive du code

Vous n'avez pas à concevoir l'architecture. Vous devez vous assurer que la personne qui le fait a réfléchi aux bonnes choses. Voici la courte liste que je voudrais qu'un fondateur non technique apporte à cette première conversation — imprimez-la, posez-la, observez avec quelle assurance on y répond.

1. 1
   Comment allez-vous séparer les données des locataires ?

   Vous guettez une réponse structurelle — le système l'impose — et non « on fera attention ». C'est la question non négociable.
2. 2
   Quel modèle utilisons-nous, et pourquoi ?

   Tables partagées, compartiments séparés ou base de données par locataire. Il n'y a pas de mauvaise réponse, mais il devrait y avoir une raison adaptée à vos clients et à votre budget.
3. 3
   Pourrons-nous offrir une isolation dédiée à un grand client plus tard ?

   Même si vous démarrez entièrement partagé, la conception devrait laisser la place d'offrir à un grand client ou à un client réglementé une séparation plus forte sans refonte.
4. 4
   Que se passe-t-il quand un client devient énorme ?

   Comment le système empêche-t-il un locataire lourd de ralentir tous les autres ? Vous voulez entendre que les scénarios de voisin bruyant ont été envisagés.
5. 5
   Comment exporter ou supprimer proprement les données d'un client ?

   Les clients partent, et la loi sur la protection des données exige que vous supprimiez leurs données sur demande. Cela devrait être une opération simple et bien maîtrisée, pas une panique.

Vous ne notez pas le détail technique des réponses. Vous vérifiez qu'aucune de ces questions n'arrive comme une surprise. Une équipe qui a déjà construit du logiciel multi-locataire aura des réponses nettes, presque blasées, aux cinq. Une hésitation sur la première ou la troisième est le signal de ralentir et de creuser.

Un court exemple, inspiré du réel

Un fondateur est venu nous voir avec un prototype fonctionnel d'un outil de prise de rendez-vous destiné aux petites cliniques. Il avait déjà trois clients payants — et un problème silencieux. Pour aller vite sur le marché, le premier développeur avait donné à chaque clinique sa propre copie séparée de l'application. Trois clients, trois installations, trois versions légèrement différentes, car chacune avait demandé un petit ajustement en chemin.

À trois, cela fonctionnait à merveille. Le cauchemar du fondateur, c'était la pensée de trente. Chaque correction de bug imposait de se connecter à trois endroits. Chaque nouvelle fonctionnalité imposait trois déploiements et trois choses à tester. Mettre en place une nouvelle clinique prenait près d'une semaine à la main. Le modèle qui les avait menés au lancement plafonnait désormais leur croissance — exactement le problème de fondation dont parle tout cet article.

Nous n'avons pas tout arraché dans une réécriture spectaculaire. Nous avons reconstruit le cœur sur une fondation multi-locataire partagée, avec l'isolation imposée au niveau du système, conservé les personnalisations par clinique sous forme de réglages configurables plutôt que de bases de code séparées, et migré les trois cliniques existantes une par une, en parallèle, pour que personne ne connaisse une journée de bascule angoissante. La mise en service d'une nouvelle clinique est passée d'une semaine de travail manuel à une inscription en libre-service. Les nouvelles fonctionnalités atteignent désormais chaque client depuis une seule publication.

Les chiffres ici sont indicatifs, pas une promesse — chaque produit est différent —, mais la forme est typique : la refonte a coûté de l'argent réel et quelques mois, et elle s'est remboursée dès la première poignée de nouveaux clients qu'ils ont soudain pu intégrer sans lever le petit doigt. La leçon que le fondateur en a tirée était la moins chère : s'ils avaient posé les cinq questions au départ, il n'y aurait rien eu à reconstruire.

Questions fréquentes