Un SaaS multi-tenant ressemble, vu de l'extérieur, à une application unique ; à l'intérieur, c'est une discipline qui porte les données de milliers d'entreprises sur un même cœur, sans jamais les laisser se toucher. C'est aussi le thème immuable du webinaire d'ingénierie que Corex360 organise chaque mois : comment bâtir un système avec une seule base de code, une seule infrastructure, mais qui donne à chaque tenant le sentiment d'avoir son propre monde.
Isolation : par schéma ou par ligne ?
La première décision, et la plus critique, est celle de l'isolation des données. Deux grandes approches existent : un schéma distinct par tenant (schema-per-tenant) ou l'étiquetage de chaque ligne d'une table partagée par un tenant_id (row-level). L'approche par schéma offre une séparation physique forte et des sauvegardes simples, mais gérer des dizaines de milliers de schémas alourdit les migrations. L'approche par ligne est légère sur le plan opérationnel et passe bien à l'échelle ; mais une seule condition WHERE manquante est une catastrophe. En pratique, c'est l'hybride qui l'emporte : isolation par ligne pour la plupart des modules + politiques de sécurité au niveau ligne (RLS) imposées au niveau de la base de données, et séparation logique pour les grands tenants entreprise.
L'essentiel est d'imposer l'isolation à la couche la plus basse possible, et non en se fiant au code applicatif. Un développeur qui oublie d'ajouter à la main le filtre tenant_id à chaque requête finira un jour par laisser fuir les données d'un autre tenant. C'est pourquoi le filtre est enfoui dans la politique de la base de données et dans la couche de requête commune ; même s'il voulait le contourner, le développeur ne le pourrait pas.
Dans une architecture multi-tenant, la sécurité n'est pas une fonctionnalité mais un comportement par défaut ; pas une exception, mais la règle.
Un cœur unique, une synchronisation temps réel
Dans Corex360, un message arrivé de WhatsApp doit apparaître simultanément dans la boîte de réception, sur la fiche CRM et sur le tableau de bord BI. Nous résolvons cela non pas en interrogeant sans cesse chaque écran, mais grâce à une colonne vertébrale pilotée par les événements (event-driven) : quand quelque chose se produit — nouveau message, facture émise, véhicule en mouvement — le système publie un événement, les modules concernés l'écoutent et se mettent à jour. Même lorsqu'un cœur unique sert des milliers de tenants, les événements de chaque tenant ne circulent qu'à l'intérieur de ses propres frontières.
Cette architecture maintient les modules faiblement couplés. Le module de suivi des véhicules n'a pas besoin de connaître la structure interne du module de stock ; tous deux parlent le même langage d'événements. Ajouter un nouveau module ne consiste pas à réécrire le cœur, mais à greffer un nouvel auditeur sur le flux. Le secret du passage à l'échelle n'est pas de gérer la taille, mais l'indépendance.
Droits par tenant et KVKK/GDPR
En Turquie le KVKK, en Europe le GDPR — tous deux exigent une réponse claire à la question « à qui appartient la donnée et qui peut la voir ». Dans un système multi-tenant, cela signifie une autorisation à deux niveaux : d'abord la frontière du tenant (l'utilisateur d'une entreprise ne peut jamais accéder aux données d'une autre), puis les rôles internes au tenant (le chef d'équipe terrain voit les données des véhicules, le comptable les factures, sans que tout le monde voie tout).
Le visage concret de la conformité, c'est l'auditabilité : qui a accédé à quelle donnée, et quand ; lorsque la suppression des données d'un tenant est demandée, l'effacement réel et exclusif des traces de ce seul tenant ; la possibilité d'appliquer des durées de conservation par tenant. Une bonne architecture multi-tenant ne porte pas le KVKK comme une couche de conformité collée après coup, mais comme la conséquence naturelle de la décision d'isolation.
