Ce qu'un ERP multitenant m'a appris sur l'architecture SaaS
L'isolation par tenant ressemble à une décision de base de données. C'est en réalité une discipline applicative globale. Retours d'expérience sur un ERP multitenant.
Le multitenancy s'explique d'ordinaire comme une stratégie de schéma : base partagée avec tenant_id, schéma par tenant, ou base par tenant. En pratique, la base de données est la partie facile.
L'isolation doit survivre à chaque couche
Les leçons difficiles sont venues de partout sauf de la donnée :
- Cache — une clé de cache sans scoping tenant est une fuite de données en attente
- Jobs asynchrones — les workers doivent porter le contexte tenant explicitement ; aucune requête HTTP pour l'en déduire
- Stockage fichiers — chemins, buckets et URLs signées exigent tous des frontières par tenant
- Logs — les logs fuient. Les agréger par tenant ou les nettoyer.
La modularité se rembourse
Nous avons organisé le système en domaines métier modulaires (stock, facturation, RH) avec des contrats d'API stricts. Quand les exigences divergeaient par segment client, les modules pouvaient évoluer sans entraîner tout le monolithe.
L'angle agent
Intégrer un agent LLM dans les workflows ERP a élevé l'enjeu : le périmètre de récupération de l'agent devait être borné au tenant par construction, pas par instruction de prompt. L'isolation au niveau du prompt n'est pas de l'isolation.
FAQ
Qu’est-ce que l’isolation multitenant en SaaS ?
L’isolation multitenant garantit qu’un tenant ne peut jamais accéder aux données d’un autre ni observer son activité. Elle doit tenir à chaque couche : requêtes SQL, clés de cache, jobs asynchrones, stockage fichiers, logs et périmètres de récupération des agents LLM.
Schéma par tenant ou colonne tenant_id partagée ?
Aucune option n’est universellement meilleure. La table partagée avec tenant_id est la moins chère et simplifie les migrations ; le schéma par tenant offre une isolation plus forte pour les clients exigeants, à coût opérationnel supérieur. Le choix en base compte moins que l’application du contexte tenant dans chaque couche applicative.
Comment sécuriser un agent LLM dans un système multitenant ?
Le périmètre de récupération de l’agent doit être borné au tenant par construction — imposé dans la couche données et le routage des requêtes, jamais par de simples instructions de prompt. L’isolation au niveau du prompt n’est pas de l’isolation.