Le défaut, et pourquoi nous l'avons quitté
L'architecture par défaut d'un logiciel vendu à de nombreux clients est le multi-tenant : une application, une base de données, une colonne qui dit à qui appartient chaque ligne. C'est moins cher à faire tourner et plus simple à mettre à jour, et c'est ce que fait presque tout SaaS. Cela veut aussi dire que les données de chaque client sont dans la même table que celles de tous les autres, séparées par un filtre qui doit être juste sur chaque requête, pour toujours.
Pour une régie, un bailleur ou une caisse, cette phrase est tout le problème. Leur responsable sécurité demandera où sont les données, qui d'autre est sur le même serveur, ce qui se passe si la charge ou l'incident d'un autre client les atteint. Avec un multi-tenant, les réponses honnêtes sont « dans la même table », « tout le monde » et « ça dépend ». Nous ne voulions pas donner ces réponses, alors nous avons construit autrement.
Ce qu'est une instance
Chaque client reçoit sa propre release de l'application, le même code que tout le monde, construit et déployé pour lui, sa propre base PostgreSQL et son propre tunnel vers le réseau, de sorte que l'instance n'a pas de surface publique au-delà de celle qu'elle sert. Rien n'est partagé à l'exécution : ni processus, ni table, ni connexion. Une requête ne peut pas atteindre les lignes d'un autre client parce qu'il n'y a pas de lignes d'un autre client à atteindre.
Le code est partagé ; le système qui tourne ne l'est pas. C'est la distinction qui compte pour un questionnaire : à « nos données sont-elles isolées ? », la réponse est oui parce que c'est construit ainsi, pas parce qu'un règlement le dit.
Ce que ça coûte, et ce que ça épargne
Cela nous coûte un déploiement par client au lieu d'un seul, et une flotte à surveiller au lieu d'un serveur. Nous le payons en automatisation : chaque instance est décrite dans un seul manifeste, construite de la même façon, mise à jour dans la même fenêtre, surveillée sur le même écran. Le coût est réel mais il est le nôtre, et il ne grandit pas avec le nombre de pages qu'un client publie.
Cela épargne trois choses au client. Une panne ou une charge folle chez un autre client lui est invisible. Un incident de sécurité, s'il devait arriver, a un rayon d'un. Et la fin du contrat est une restitution, pas une extraction : sa base est une base, exportée en SQL avec les médias et le dictionnaire de données, et l'instance est effacée avec un procès-verbal. Il n'y a pas de « vos lignes parmi les nôtres » à démêler.
Quand le multi-tenant a quand même raison
Le multi-tenant est la bonne réponse pour un produit à des milliers de petits clients et sans questionnaire : Wodloop, notre logiciel de gestion de box, en est un, et il serait absurde de faire tourner une base par salle de CrossFit. La règle n'est pas « jamais de multi-tenant » ; c'est « l'architecture suit l'acheteur ». Un opérateur public achète de l'isolation, une restitution et une réponse claire à un responsable sécurité. Ça vaut un déploiement.
Ça façonne aussi le produit : parce que chaque client est une instance, un client peut avoir son propre jeu de modules, son propre domaine, sa propre connexion unique, son propre rythme de mise à jour quand une règle change pour lui seul. Ce sont des fonctionnalités qu'un multi-tenant vend sous l'étiquette « entreprise » ; ici c'est ce que l'architecture est déjà.