Multi-tenant dès le premier jour

Presque toutes les réécritures de SaaS qu'on nous a appelés à sauver remontent aux trois mêmes mots prononcés par l'équipe d'origine dès le premier mois : « on ajoutera ça plus tard ». La multi-location, le contrôle d'accès par rôle, la vraie facturation. On a l'impression que ce sont des choses qu'on greffe une fois qu'on a des clients. C'est tout le contraire — ce sont la forme même du bâtiment, et on ne peut pas changer les fondations une fois les murs montés sans tout démolir.

Nous avons construit des plateformes qui tournent aujourd'hui dans plus de 40 pays sur une seule base de code. La raison qui a rendu cela possible est aussi ennuyeuse qu'unanime : la location, l'accès et la facturation ont été décidés dès le premier jour, avant la première fonctionnalité. Voici à quoi ressemblent ces décisions, et ce qu'il en coûte de les reporter.

01Pourquoi les équipes l'esquivent (et pourquoi c'est un piège)

La pression est réelle. Vous avez un seul client pilote, une démo la semaine prochaine, et un backlog de fonctionnalités qui ressemblent vraiment au produit. La multi-location est invisible pour ce premier client — il ne peut pas la voir, alors elle a des airs de fioriture superflue. L'équipe construit donc une application mono-locataire « pour l'instant » et promet de la généraliser plus tard.

Le piège, c'est que « mono-locataire pour l'instant » fait fuiter une hypothèse dans chaque couche : qu'il existe exactement une seule organisation au monde. Cette hypothèse finit dans vos requêtes, votre authentification, vos caches, vos tâches d'arrière-plan, vos chemins de fichiers. La retirer plus tard n'est pas un refactoring — c'est une réécriture, parce que l'hypothèse n'est pas à un seul endroit, elle est partout.

02Le locataire est la première colonne

Notre règle est simple : chaque ligne qui appartient à un client porte un tenant_id, et il n'existe aucun chemin de code capable de faire une requête sans lui. Pas une convention que les gens se rappellent — une contrainte que la base de données et le framework imposent, de sorte que l'oublier devient impossible plutôt que simplement déconseillé.

La version la plus propre que nous utilisons s'appuie sur la base de données elle-même. Les politiques de sécurité au niveau des lignes signifient que la frontière entre locataires est imposée une couche en dessous du code applicatif, là où un bug d'ORM ou une clause WHERE oubliée ne peut pas faire fuiter les données d'un client vers un autre. L'application définit le locataire courant sur la connexion ; la base de données refuse de renvoyer quoi que ce soit d'autre.

-- the boundary lives below the app, not inside it
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- app sets the tenant per request; a forgotten WHERE
-- clause now returns zero rows instead of someone else's data
SET app.tenant = 'a91f…';
SELECT * FROM orders;   -- only this tenant's orders, always

Cette unique décision retire de votre liste de soucis, et de façon permanente, toute une catégorie de bugs catastrophiques — la fuite de données entre locataires. Ce sont les deux jours de travail au plus fort effet de levier de tout le projet.

03Le RBAC n'est pas une page de paramètres

Le deuxième « plus tard » qui se transforme en réécriture, c'est le contrôle d'accès. Les équipes livrent avec un monde implicite à deux rôles — admin et utilisateur — codé en dur dans des instructions if éparpillées dans toute la base de code. Puis un client grand compte demande un rôle « facturation uniquement », ou un « auditeur en lecture seule », et vous découvrez de la logique de permissions à deux cents endroits.

Nous modélisons les permissions comme des données dès le départ : les rôles, les permissions et les attributions entre eux vivent dans des tables, et chaque action protégée pose une question à une autorité centrale unique : « cet acteur peut-il faire cette chose sur cette ressource, dans ce locataire ? ». Ajouter un rôle devient une ligne, pas une release. C'est ce qui permet à une plateforme de dire oui à l'organigramme du client grand compte sans toucher au code applicatif.

• Les permissions sont des verbes sur des ressources — invoice:read, invoice:void — pas des niveaux vagues comme « manager ».
• Les rôles sont des assemblages de permissions qu'un locataire peut composer, de sorte que deux clients peuvent entendre des choses différentes par « admin ».
• Chaque vérification passe par une seule porte. Une logique d'autorisation à un seul endroit est auditable ; des instructions if éparpillées sont un passif.

04La facturation est un produit, pas de la tuyauterie

La facturation est là où « on l'ajoutera plus tard » fait le plus mal, parce qu'au moment où vous l'ajoutez vous avez des clients sur des accords passés à la poignée de main, des données incohérentes sur qui doit quoi, et aucun concept propre d'abonnement. Rattraper la facturation, c'est réconcilier de l'argent, et c'est le seul endroit où un bug n'est pas seulement gênant — c'est un remboursement, un litige, ou un problème de conformité.

Nous concevons le modèle de facturation en même temps que le modèle de locataire : plans, abonnements, usage, factures, et le cycle de vie qui les relie. Même si les premiers clients sont facturés manuellement, le modèle de données est là dès le premier jour, de sorte qu'activer plus tard des plans en libre-service est une fonctionnalité, pas une migration de tout l'historique de votre chiffre d'affaires.

05Quarante pays, une seule base de code

Atteindre plus de 40 pays a des airs d'histoire de mise à l'échelle. C'est en réalité une histoire de configuration. La plateforme n'a pas de branches de code spécifiques à chaque pays — elle a un modèle de locataire assez riche pour exprimer comme des données ce qui diffère d'une région à l'autre : devise, règles fiscales, langue, formats de date, mentions légales sur une facture.

Quand la frontière entre « code » et « configuration » est tracée correctement dès le premier jour, un nouveau pays est une tâche d'onboarding, pas un projet d'ingénierie. Quand elle est mal tracée, chaque nouveau marché est un fork, et en moins d'un an vous maintenez une douzaine de versions subtilement différentes de la même application et vous livrez chaque correctif une douzaine de fois. Le résultat « une seule base de code » découle de décisions prises avant le premier client.

06La checklist du premier jour

Si vous démarrez une plateforme SaaS ce trimestre, voici les décisions à prendre avant d'écrire la moindre fonctionnalité — non parce qu'elles sont urgentes, mais parce qu'elles sont irréversibles :

1. Mettez un tenant_id sur tout et imposez-le en dessous de l'application. Sécurité au niveau des lignes ou équivalent. Rendez une requête inter-locataires impossible, pas improbable.
2. Modélisez les permissions comme des données. Rôles et attributions dans des tables, une seule porte d'autorisation centrale. Ajouter un rôle devrait être une ligne.
3. Construisez tôt le modèle de données de facturation. Plans, abonnements, factures — même si vous facturez à la main au début. Ne rattrapez pas l'argent après coup.
4. Séparez le code de la configuration. Tout ce qui varie selon le client ou la région est une donnée. Le pays numéro 41 devrait être un formulaire d'onboarding.
5. Écrivez d'abord le chemin de provisionnement de locataire. Créer proprement un nouveau locataire, avec des valeurs par défaut sensées, est votre opération la plus exécutée. Automatisez-la dès le premier jour.

Rien de tout cela n'est exotique. C'est quelques semaines de discipline au départ en échange de ne jamais avoir à faire la réécriture. Les équipes qui atteignent 40 pays sur une seule base de code n'ont pas eu de chance — elles ont simplement refusé de dire « plus tard » à propos des trois choses qui ne peuvent pas être ajoutées plus tard.