Architecture multi-tenant : ce que ça veut dire, et ce qui devient dangereux avec l'intelligence artificielle

Les trois façons de séparer les données dans une architecture multi-tenant

La première méthode, la plus légère : une seule base de données pour tous les clients, avec une colonne qui indique à qui appartient chaque ligne. Chaque requête filtre automatiquement sur cette colonne. C'est la méthode la moins chère à construire et à faire évoluer, elle tient tant que le filtre est écrit correctement partout, sans exception, dans chaque bout de code qui touche à la base. Une seule requête oubliée et un client voit les lignes d'un autre.

La deuxième méthode : un schéma séparé par client dans la même base de données. Chaque client a ses propres tables, à l'intérieur du même moteur de base de données. La séparation est plus solide que la première méthode, elle coûte un peu plus cher à gérer parce qu'il faut faire évoluer chaque schéma en même temps, mais une erreur de filtre dans le code ne suffit plus à faire fuiter une donnée : il faudrait aussi se tromper de schéma. Cette méthode demande un peu plus de discipline dans les outils de migration, parce qu'un changement de structure doit se répéter sur chaque schéma existant, mais elle donne une garantie technique plus solide qu'une simple colonne.

La troisième méthode : une base de données entière par client, parfois même un serveur entier. C'est la plus sûre, c'est aussi la plus proche du mono-tenant, et c'est la plus chère : chaque client fait grossir votre facture d'infrastructure et le temps que vous passez à faire évoluer votre produit, parce qu'il faut répéter chaque changement sur chaque base. C'est la méthode que choisissent les secteurs les plus contraints, la banque, la santé, ou les très grands comptes qui exigent une isolation physique complète et refusent tout partage d'infrastructure, même invisible.

Aucune des trois n'est la bonne réponse dans l'absolu. Un éditeur qui vend à dix clients à 50 000 euros par an, dans un secteur réglementé, choisit souvent la troisième. Un éditeur qui vend à mille clients à cinquante euros par mois ne peut pas se permettre la même chose : il choisit la première ou la deuxième, et il compense par des tests rigoureux sur le filtre des données. Le bon choix se juge à qui sont vos clients et à ce qu'ils sont prêts à payer, pas à la méthode la plus élégante à présenter dans une documentation technique.

Pourquoi le multi-tenant redevient une question brûlante avec l'intelligence artificielle

Le sujet dormait depuis des années. Un audit de sécurité, une fois par an, vérifiait que le filtre tenait, et l'affaire était classée. Ce qui a changé : vos clients demandent maintenant que le logiciel lise leurs documents, réponde à leurs questions, résume leurs dossiers, avec un modèle de langage branché sur leurs données. Et un modèle de langage ne fonctionne pas comme une requête de base de données classique.

Une requête classique renvoie exactement ce qu'on lui demande, ligne par ligne, avec un filtre qui soit s'applique soit ne s'applique pas. Un modèle de langage construit une réponse à partir de tout ce qu'on lui donne à lire, et il n'a pas de notion native de « ce document appartient au client A, celui-là au client B ». Si le mécanisme qui choisit quels documents lui montrer se trompe, même une seule fois, le modèle répond avec ce qu'il a sous les yeux, sans savoir qu'il ne devrait pas.

Ajoutez à ça que beaucoup d'éditeurs ont construit leur architecture multi-tenant il y a plusieurs années, avant d'avoir en tête qu'un modèle irait un jour lire ces données. Le filtre qui protégeait vos tables ne protège pas forcément la recherche documentaire qu'on vient de brancher par-dessus. C'est souvent là, dans la jointure entre l'ancien système et le nouveau composant d'intelligence artificielle, que se cache le trou.

Le risque concret : une réponse qui mélange les données de deux clients

Concrètement, voici ce qui peut arriver. Un utilisateur du client A pose une question à l'assistant intégré à votre logiciel. Le système va chercher les documents pertinents pour répondre, les donne au modèle, et le modèle rédige une phrase. Si le mécanisme de recherche n'a pas correctement filtré par client, il peut ramener un document du client B dans le lot. Le modèle ne fait pas la différence : il rédige sa réponse avec ce qu'on lui a donné, et il peut citer un chiffre, un nom de contrat, une remarque interne qui appartient à un autre client.

Ce scénario arrive, et c'est celui que redoutent le plus les directeurs techniques d'éditeurs qui branchent de l'intelligence artificielle sur un produit multi-tenant existant, et c'est la première question que pose un client qui a de la maturité sur le sujet. Une fuite de ce type n'a pas besoin d'être fréquente pour faire des dégâts : un seul incident, raconté par le client qui l'a vu, suffit à casser la confiance sur l'ensemble du produit. Et contrairement à une fuite technique classique, celle-ci se voit immédiatement : le client qui la découvre n'a pas besoin d'expertise, il lit simplement ce qui s'affiche à l'écran.

Le risque grandit avec le nombre d'endroits où le modèle a accès à de la donnée : une recherche documentaire, un résumé automatique, un historique de conversation partagé entre plusieurs utilisateurs de la même entreprise, un outil qui appelle une base externe pour compléter la réponse. Chaque nouvel accès est un endroit de plus où le filtre par client doit être vérifié, pas supposé. Faites-en la liste une fois par trimestre : c'est souvent le seul moyen de se rendre compte qu'un nouveau composant a été branché sans que personne n'ait repensé le cloisonnement.

Comment on empêche une fuite entre clients dans une réponse générée

La règle de base ne change pas avec l'intelligence artificielle : le filtre par client doit s'appliquer avant que la donnée n'atteigne le modèle, jamais après. On ne demande pas au modèle de trier ce qui lui appartient une fois qu'il a tout lu, parce qu'il n'a aucun moyen fiable de le faire. On filtre la donnée à la source, exactement comme pour une requête de base classique, puis on ne donne au modèle que ce qui a déjà passé ce filtre.

Concrètement, cela veut dire que la recherche documentaire augmentée qui alimente le modèle doit porter la même contrainte de client que le reste de votre application, dans le même mécanisme, testé par les mêmes personnes. Si vos développeurs ont l'habitude d'ajouter un filtre par client sur chaque nouvelle table, ils doivent prendre la même habitude sur chaque nouvel index de recherche, chaque nouvelle collection de documents, chaque nouveau cache.

Il faut aussi tester le système en le mettant en défaut volontairement : demander à l'assistant, avec un compte du client A, une information qui n'existe que chez le client B, et vérifier qu'il ne la trouve pas. Ce test simple, répété à chaque évolution du produit, coûte quelques heures et vaut plus qu'un audit annuel qui arrive après coup. Documentez le résultat dans un endroit que vous pouvez montrer à un client qui pose la question, plutôt que de le refaire à chaque fois sans laisser de trace.

Ce qu'il faut pouvoir prouver à un client qui interroge votre multi-tenant par écrit

Passé une certaine taille de client, la question ne reste plus orale. Un service juridique ou une équipe sécurité envoie un questionnaire, parfois vingt pages, et demande une réponse écrite, engageante, signée. Ne pas pouvoir y répondre correctement fait perdre des contrats avant même la démonstration du produit. Plus votre client est grand, plus tôt cette question arrive dans le cycle de vente, parfois avant même le premier appel avec un commercial.

Ce qu'un client sérieux veut lire : comment vos données sont séparées entre clients, laquelle des trois méthodes et pourquoi, qui peut techniquement accéder aux données d'un autre client et dans quelles conditions, ce qui se passe si le modèle d'intelligence artificielle qui répond aux questions a accès à de la documentation, comment vous testez que cet accès reste cloisonné, et depuis quand ce test tourne.

Une réponse honnête vaut mieux qu'une réponse rassurante. Si votre architecture multi-tenant repose sur la première méthode, la colonne qui filtre, dites-le et expliquez comment vous compensez : tests automatisés, revues de code systématiques sur tout ce qui touche à la base. Un client technique préfère une explication précise à une formule vague du type « nos données sont sécurisées », qui ne répond à rien.

L'effet du multi-tenant sur la facture, quand le coût est à l'usage

Le multi-tenant a été pensé pour une raison d'argent : mutualiser l'infrastructure fait baisser le coût par client, et c'est ce qui permet de vendre un abonnement à un prix raisonnable plutôt qu'un projet sur mesure à chaque fois. Cet argument reste vrai avec l'intelligence artificielle, mais avec une nuance qui change la donne : les appels à un modèle de langage se facturent le plus souvent à l'usage, pas au forfait.

Concrètement, chaque question posée par un client à votre assistant a un coût réel, calculé sur ce que le modèle lit et ce qu'il écrit. Sur une architecture mono-tenant, ce coût reste isolé par client et facile à suivre. Sur une architecture multi-tenant, il faut construire un suivi séparé pour savoir quel client consomme quoi, sinon un seul client qui utilise l'assistant intensivement peut faire grimper votre facture sans que vous sachiez pourquoi, ni qui facturer en retour.

Les fournisseurs de modèles changent leurs tarifs trop souvent pour qu'on les écrive ici avec précision, mais le principe reste stable : plus votre produit fait lire de documents et écrire de réponses longues au modèle, plus le coût par client grimpe. Un suivi de consommation par client, posé dès le départ, évite la mauvaise surprise du mois où la facture double sans explication. Certains éditeurs choisissent même de répercuter ce coût variable directement sur le client le plus consommateur, plutôt que de le lisser sur l'ensemble de leur base, une fois qu'ils ont ce suivi en place.

Ce qu'on ne peut plus changer facilement une fois le choix multi-tenant fait

Le choix entre les trois méthodes de séparation se prend tôt, souvent dès les premières lignes de code du produit, et il est coûteux à revenir en arrière. Migrer d'une base partagée avec filtre par colonne vers des schémas séparés, ou vers une base par client, demande de réécrire une bonne partie de la couche qui accède aux données, de migrer chaque client existant sans interruption de service, et de tout retester.

C'est pour ça que la question mérite d'être posée avant d'ajouter de l'intelligence artificielle à un produit multi-tenant existant, plutôt qu'après coup. Si votre architecture actuelle repose sur un filtre fragile et que vous vous apprêtez à brancher un assistant qui lit les documents de vos clients, le bon moment pour renforcer le cloisonnement, c'est avant de lancer la fonctionnalité, pas après le premier incident.

Ce qui reste flexible, en revanche : la partie intelligence artificielle elle-même. On peut changer de modèle, ajuster la recherche documentaire, revoir les instructions envoyées au modèle, sans toucher à la structure de séparation des données sous-jacente. C'est justement pour ça qu'il vaut mieux que ces deux couches restent bien distinctes dans votre code : la séparation par client d'un côté, la logique d'intelligence artificielle de l'autre.

Multi-tenant ou mono-tenant : comment trancher pour votre produit

La réponse dépend moins de la technique que de qui sont vos clients. Si vous vendez à des dizaines ou des centaines d'entreprises à un tarif mensuel modeste, le multi-tenant s'impose : vous ne pouvez pas vous permettre une infrastructure par client. Si vous vendez à une poignée de grands comptes, à un tarif élevé, avec des exigences de sécurité fortes, le mono-tenant reste une option raisonnable, parfois même attendue par le client.

Certains éditeurs choisissent un entre-deux : multi-tenant pour la majorité des clients, avec une option d'instance dédiée réservée aux comptes qui l'exigent et qui sont prêts à la payer. Cette solution demande de maintenir deux façons de déployer le produit, ce qui a un coût d'ingénierie réel, mais elle évite de refuser un contrat important pour une raison d'architecture. Le risque se situe ailleurs que dans le coût de cette double maintenance : il est de laisser le multi-tenant standard hériter en douce de raccourcis pensés uniquement pour l'instance dédiée, ce qui affaiblit le cloisonnement du plus grand nombre.

Nous accompagnons régulièrement des éditeurs qui se posent cette question au moment où ils veulent ajouter de l'intelligence artificielle générative à leur produit, et où le sujet du cloisonnement des données revient sur la table pour la première fois depuis des années. C'est un bon moment pour trancher, parce que la fonctionnalité qui arrive rend la question visible pour tout le monde, y compris pour vos clients.

Les questions à poser à un fournisseur avant de signer

Si vous achetez un composant ou une brique d'intelligence artificielle à brancher sur votre produit multi-tenant plutôt que de la construire vous-même, posez ces questions avant de signer : comment le composant sait-il à quel client appartient chaque demande, où cette information circule-t-elle, et qui peut la voir à part vous et votre client. Une réponse évasive sur ce point, du type « c'est géré automatiquement », mérite d'être creusée avant de signer quoi que ce soit.

Demandez aussi ce qui se passe si deux clients envoient des demandes en même temps : est-ce que leurs données passent par les mêmes files d'attente, les mêmes caches, avec un risque de croisement si le système est mal écrit sous forte charge. Un fournisseur sérieux a déjà réfléchi à cette question et peut y répondre sans détour. Si la réponse tarde ou reste technique sans jamais aborder le cas des deux clients simultanés, c'est probablement que la question ne lui a jamais été posée avant vous.

Enfin, demandez comment le fournisseur teste le cloisonnement, à quelle fréquence, et s'il accepte que vous fassiez vous-même un test de fuite entre deux comptes différents avant de signer un contrat engageant. Un fournisseur qui refuse ce test, ou qui le trouve étrange, n'a probablement jamais eu besoin d'y répondre sérieusement jusque-là. Un simple compte-rendu de test, même informel, vaut mieux qu'une promesse orale répétée à chaque relance.

Ce que nous construisons chez Techmind sur ces sujets

Nous développons des briques d'intelligence artificielle directement dans des produits multi-tenant existants, avec les équipes techniques de l'éditeur, en respectant le cloisonnement déjà en place plutôt qu'en le contournant. Pour Cortex OS, nous avons intégré un moteur d'intelligence artificielle générative dans le produit sans que l'éditeur perde la main sur son code ni sur la façon dont les données de ses propres clients restent séparées.

Deux façons de travailler ensemble, selon ce que vous cherchez. Nous développons dans votre dépôt de code, avec vos développeurs, quand la fonctionnalité doit s'intégrer en profondeur dans votre architecture existante. Ou nous construisons un composant autonome que vous branchez et que vous revendez sous votre propre marque, quand vous voulez garder la maîtrise du planning sans mobiliser toute votre équipe.

Ce chapitre fait partie de notre guide sur l'intelligence artificielle dans un logiciel vendu en SaaS, où nous détaillons aussi comment protéger l'hébergement des données de vos clients et comment vérifier ce qu'un modèle invente quand il n'a pas la bonne information sous les yeux. Les deux chapitres se lisent dans n'importe quel ordre, selon la question qui vous occupe en ce moment.