Copilote SaaS multi-tenant : conserver le client jusqu’au résultat

Le client A demande le montant de sa pièce R32 et reçoit 120. Le client B possède aussi une pièce R32, mais son montant vaut 900. Une recherche correctement filtrée peut distinguer les deux ; un cache indexé seulement par question et identifiant peut ensuite remettre la réponse de A à B. Le risque est double : montant incorrect pour B et divulgation d’une valeur appartenant à A.

En pratique, l’isolation doit suivre le contexte client jusqu’aux réponses conservées, travaux différés et consommations attribuées. Ce contexte provient du service qui établit l’utilisateur et son espace ; le modèle ne le choisit pas. Le développement d’une fonctionnalité IA dans un SaaS doit maintenir cette frontière et les droits internes du client, même lorsqu’une assistance utilise des composants mutualisés.

Deux clients possèdent ici une pièce R32, mais ses montants et ses lecteurs autorisés diffèrent. Dix-huit scénarios manuscrits suivent cette ambiguïté à travers un cache et une file SQLite locale, avec trois utilisateurs fictifs. Aucun modèle, broker, cloud ou mécanisme d’authentification réel n’est exécuté. L’expertise IA sur mesure de Dawap sert à prolonger ces contrôles applicatifs dans le produit : transmettre l’origine du travail, vérifier les droits courants et rattacher chaque consommation au client concerné.

Pour qui le copilote traverse des ressources partagées

Cartographier les données dérivées qui restent après la lecture

Un copilote peut conserver davantage que les documents qu’il consulte : extraits, résumés, brouillons, réponses en cache et événements de diagnostic. Ces objets sont issus d’un espace client et peuvent transporter ses informations. Les partager parce qu’ils ne sont plus dans la table source ferait perdre la frontière initiale. L’inventaire doit nommer leur propriétaire, leurs lecteurs possibles et leur durée de conservation.

Ce travail concerne le responsable produit, les développeurs et l’exploitation. La revue ne commence pas par le choix d’un modèle ; elle suit une demande depuis l’écran jusqu’au stockage de son résultat. Elle examine aussi les chemins moins visibles : export, notification, reprise après incident et outil de support. Un test favorable sur la seule réponse interactive ne permet pas de déclarer tous ces objets isolés.

Choisir les frontières selon les composants réellement mutualisés

La référence AWS sur les stratégies d’isolation SaaS distingue notamment modèles silo, pool et bridge. Un service peut mutualiser certaines ressources et en séparer d’autres. Le choix doit être précisé composant par composant ; le nom général de l’architecture ne prouve pas que cache, recherche ou traitement IA respectent la même frontière.

Notre banc utilise un stockage commun avec filtrage applicatif. Il ne démontre ni isolation réseau ni politique IAM, et ne remplace pas une recette de l’infrastructure retenue. Si un client exige une séparation différente pour ses données ou traitements, cette exigence doit être évaluée sur les interfaces disponibles. L’ajout d’un tenant_id dans quelques objets ne suffit pas à promettre une séparation physique des ressources.

Établir le client hors des arguments du modèle

Conserver la provenance du contexte

La personne authentifiée peut appartenir à un ou plusieurs espaces selon le produit. Le service doit établir l’espace actif et vérifier ce choix avec son modèle d’habilitation. Le contexte transmis aux outils porte ensuite sujet et tenant vérifiés. Un nom de client présent dans une pièce ou une proposition du modèle peut servir à comprendre la demande ; il ne devient pas un contexte d’accès.

La référence AWS sur identité et isolation relie ce contexte aux règles appliquées par les éléments aval. Le banc fixe l’identité d’entrée à la main : Alice appartient à A, Bob à B et Charlie à A. Il ne fournit aucune preuve d’authentification. La recette réelle devra inclure session, changement d’espace et transmission entre services.

Refuser le tenant proposé comme un paramètre ordinaire

T32-03 présente le contexte d’Alice et un argument tenant=B. Le contrôleur renvoie tenant_argument_denied. Il refuse même une valeur qui pourrait être identique au tenant courant, parce que ce champ n’appartient pas au contrat de proposition du banc. Le modèle prépare la question et l’objet ; le service conserve la responsabilité de l’espace dans lequel ces arguments seront interprétés.

Une application multi-espace peut proposer un changement de client dans l’écran. Ce changement doit emprunter un parcours explicite, avec vérification des droits et traitement des tâches déjà ouvertes. Reprendre silencieusement un travail de A après sélection de B mélange contexte de consultation et contexte d’origine. Chaque opération doit conserver le client auquel elle appartient, au lieu de lire une variable globale « espace courant » au dernier moment.

Lire une ressource avec sa frontière de tenant

Utiliser une clé qui identifie réellement la pièce

Exemple concret : la clé de la table est le couple tenant, id. Les deux lignes R32 restent distinctes et contiennent 120 pour A, 900 pour B. La requête de lecture impose WHERE tenant=? AND id=? avec le tenant du contexte contrôlé. T32-01 et T32-02 retrouvent donc chacun leur valeur. Un identifiant métier local ne doit pas être interprété comme un identifiant global dans le nouvel outil.

SELECT revision, amount
FROM document
WHERE tenant = ? AND id = ?

T32-04 demande BX depuis A, alors que cette pièce existe seulement chez B. resource_missing ne renvoie ni son montant ni un autre objet « ressemblant ». Le banc ne prouve pas une protection contre tout canal d’énumération ; il vérifie l’absence de cette lecture croisée. La réponse publique et ses détails doivent être choisis pour ne pas révéler inutilement l’existence des ressources d’un autre client.

Distinguer barrière applicative et politique du moteur

Le filtre de notre requête est appliqué par le contrôleur. Une autre requête sans ce filtre pourrait lire les deux tenants : aucune barrière moteur ne l’empêche dans cette recette SQLite. La documentation PostgreSQL 18 sur les politiques de sécurité des lignes décrit un mécanisme différent, avec ses conditions : propriétaires de table et rôles BYPASSRLS peuvent notamment contourner les politiques selon leur configuration.

Une production qui utilise ce mécanisme doit le tester avec le rôle réellement employé, ses vues et ses fonctions. Une configuration d’identité de session doit aussi être établie et réinitialisée correctement dans les connexions mutualisées. Notre résultat ne valide aucun de ces chemins. Le choix d’une protection supplémentaire peut réduire le risque d’oubli applicatif, mais ne remplace pas l’autorisation sur cache, file et résultat dérivé.

Ne pas partager une réponse au-delà des droits

Rattacher l’entrée de cache à son périmètre de lecture

Le cache du banc utilise tenant, utilisateur, révision des droits, révision de source et question. La répétition nominale de T32-01 pour Alice reçoit cache_hit et 120. T32-05 le remplit avec Alice, puis pose la même question pour Bob sur R32 : cache_miss retrouve 900 depuis B. Une clé limitée à amount:R32 aurait fusionné précisément les deux valeurs que le filtre SQL avait séparées.

Cette stratégie par utilisateur est volontairement prudente et peut réduire la mutualisation. Une autre architecture peut partager une réponse entre personnes possédant un périmètre équivalent, mais cette équivalence doit être établie et invalidée correctement. Ne remplacez pas le sujet par le seul tenant sans avoir couvert les droits internes. Le cache contient une réponse calculée ; son origine ne rend pas ses lecteurs automatiquement autorisés.

Vérifier le droit courant avant de consulter le cache

Charlie appartient à A, mais n’a pas le droit de lire la pièce. T32-06 reçoit permission_denied après remplissage du cache par Alice. T32-08 retire ensuite la permission d’Alice : sa réponse encore stockée ne lui est plus servie. Le contrôle précède la recherche en cache. Sans cet ordre, une ancienne réponse pourrait devenir une voie d’accès lorsque la lecture de source est désormais interdite.

T32-07 modifie la révision des droits tout en conservant la permission : une nouvelle clé produit cache_miss et retrouve 120. T32-17 modifie la source à la révision 2, montant 130 : le contrôleur ne sert pas l’ancienne valeur. Il lit la révision courante en base avant le cache, choix possible dans ce petit banc. Un système utilisant invalidation asynchrone ou TTL doit documenter et éprouver sa propre fenêtre de fraîcheur.

Revalider le travail après une attente

Conserver l’origine dans l’objet de travail

Un travail en attente porte le tenant, la personne, l’identifiant de demande et les révisions de droits et de source utilisées à son admission. L’exécuteur ne doit pas inventer ces éléments en lisant le prompt du travail. Le registre de référence garde l’origine ; le payload éventuellement transmis doit être confronté à cette origine. Cette règle reste nécessaire lorsque le traitement est repris sur une autre instance.

Dans T32-09, un travail stocké chez A arrive à un travailleur configuré pour B. worker_tenant_denied arrête la préparation. T32-16 modifie seulement payload_tenant à B dans le travail de A : payload_tenant_denied refuse également. Ces mutations sont produites volontairement dans la base de laboratoire. Elles ne représentent pas un test de sécurité d’un broker ; elles précisent la frontière attendue à l’exécution.

Relire les conditions qui ont pu changer

Deuxième cas concret : Alice met R32 en attente à la révision 1 et au montant 120. La source passe ensuite à 130, révision 2. T32-10 reçoit source_stale et ne prépare pas l’ancien résultat. T32-11 retire son droit pendant l’attente : permission_denied bloque le même type de travail. L’admission initiale ne fige donc ni la donnée ni la permission jusqu’à une exécution future.

Le travail refusé garde ici vingt unités en réserve. Le laboratoire ne simule pas le processus de résolution ou de libération ; l’exposition reste visible en attente de rapprochement. En production, il faut attribuer ces travaux et définir leur sortie : annulation confirmée, nouvelle proposition ou revue humaine. Les laisser indéfiniment bloqués protégerait une lecture tout en dégradant le service et la capacité disponible du client.

Distinguer doublon et requête d’un autre client

Porter l’idempotence dans la bonne frontière

Le même identifiant Q32 peut être utilisé chez A et B sans désigner le même travail. La clé de la file est donc tenant, request_id. T32-12 rediffuse Q32 pour Alice : duplicate_job conserve une seule ligne et une réservation de vingt. T32-13 utilise Q32 pour Bob après l’admission d’Alice : job_enqueued crée un second travail, avec une réserve distincte de vingt chez B.

La décision et la réserve sont écrites dans une transaction SQLite. Cette recette séquentielle ne teste pas une course entre deux producteurs. Le protocole réel doit traiter conflit de clé, rediffusion après commit et message perdu après admission. Il faut rendre le résultat récupérable sans réserver deux fois, et vérifier que l’opération distante possède elle aussi la garantie nécessaire lorsque le travail produit un effet métier.

Définir ce que signifie « la même demande »

Notre banc vérifie seulement la rediffusion du même Q32 dans un parcours fixe. Il ne compare pas deux payloads différents possédant cette clé. Une production doit associer empreinte de demande et identifiant, puis refuser une réutilisation incompatible au lieu de restituer arbitrairement le premier résultat. Cette nuance distingue idempotence vérifiée et simple collision d’identifiants dans une table.

La restitution d’un ancien résultat demande également un droit courant. Une clé connue ne donne pas le droit de récupérer le travail d’un collègue ou d’un autre tenant. L’autorisation doit donc être vérifiée avant de servir un doublon, puis à nouveau lors d’un effet encore à exécuter. Une optimisation de rediffusion ne doit pas créer une voie de consultation plus large que l’opération normale.

Attribuer quota, réserve et coût au bon client

Séparer les registres même lorsque le service est partagé

Chaque tenant possède un plafond fictif de cinquante unités. L’admission réserve vingt ; la préparation locale réussie constate douze. T32-14 initialise quarante unités consommées chez A : le prochain travail serait trop coûteux et reçoit tenant_quota_denied. T32-15 conserve cet état de A et admet Bob chez B. L’état de A reste spent=40, held=0 ; B passe à held=20.

Le quota du banc limite une admission par attribution de consommation. Il ne garantit pas une latence indépendante entre tenants ou un partage équitable du processeur. La référence AWS sur le modèle pool distingue notamment risque de noisy neighbor et difficulté d’attribution des coûts. Un test de charge et une politique de files sont nécessaires pour éprouver cette autre dimension.

Relier les coûts dérivés à la mission d’origine

Les retries, travaux annulés et consommations inconnues doivent rester rattachés au client d’origine. Une reprise effectuée par le support ne transforme pas une dépense de A en dépense de B parce que l’opérateur a changé d’écran. Le registre conserve mission, tentative et attribution. La clôture d’une réserve doit être justifiée par un résultat ou une décision de rapprochement, plutôt que par la disparition du message de la file.

Les coûts mutualisés demandent une méthode distincte de répartition si le produit veut calculer sa marge ou facturer des usages. Notre exemple ne calcule ni stockage, ni indexation, ni prix de modèle et ne constitue pas un moteur de facturation. Le budget d’exécution d’un agent précise les réserves et inconnues à conserver avant de construire ces vues économiques.

Dix-huit scénarios d’isolation et leurs résultats

Alterner les clients et modifier les conditions

Chaque ligne ci-dessous démarre dans une copie indépendante du laboratoire. Les étapes préparatoires remplissent un cache, placent un travail en attente ou changent une permission. Les résultats sont ceux du contrôleur exécuté, sans sortie de modèle évaluée. Les montants sont des valeurs de pièces fictives ; les réserves sont des unités de politique sans rapport avec ces montants. Aucun résultat n’est envoyé dans un SI.

Une matrice de recette doit couvrir aussi les chemins absents de ce banc : nouvelle connexion mutualisée, recherche vectorielle, pièce jointe, export, notification et accès de support. Le succès des dix-huit scénarios ne certifie aucun environnement. Leur rôle est de donner des décisions vérifiables à comparer avec le parcours réellement déployé, en gardant visibles les composants et garanties qui n’ont pas encore été éprouvés.

Garder les chemins favorables dans la recette

Refuser toute lecture inter-client est nécessaire, mais une application qui ne sert plus aucune réponse n’est pas exploitable. Le parcours doit continuer pour Bob après le cache d’Alice et pour B lorsque le quota de A est épuisé. T32-18 garde aussi la préparation nominale, avec consommation rapprochée et réserve libérée. Ces cas évitent une correction qui confondrait isolation et fermeture complète de la fonctionnalité.

Les scénarios sont choisis pour couvrir des frontières, sans fréquence représentative d’usage. Ils ne permettent pas de calculer un taux de fuite, un taux de succès de modèle ou une proportion de reprises client. Une recette de sécurité et un suivi de service demandent d’autres populations, preuves et environnements. Conservez cette distinction lorsque vous présentez les résultats au propriétaire produit ou à un client qui évalue la nouvelle capacité.

Diagnostiquer un incident sans ouvrir les autres espaces

Rendre le tenant visible dans les traces autorisées

Le support doit retrouver demande, tentative, révisions et motif de refus pour un client donné. Ces identifiants évitent de recopier toutes les pièces dans les journaux. Les outils de diagnostic possèdent eux-mêmes un périmètre d’accès et des responsabilités. Une recherche globale de prompts à partir d’un ticket client pourrait exposer les données des autres tenants alors que les réponses du produit sont correctement filtrées.

Choisissez les informations nécessaires à l’investigation : provenance du contexte, clé de cache, travail enregistré à l’admission, révision de permission et consommation attribuée. N’exposez pas secrets ou documents bruts dans une métrique accessible à toute l’équipe. La trace doit expliquer une frontière refusée sans fournir le contenu protégé derrière cette frontière. La rétention et les procédures d’accès doivent être fixées pour ces données dérivées.

Limiter l’incident à la capacité et au client concernés

Une réserve bloquée chez A peut demander une suspension de ses nouveaux travaux, sans supprimer arbitrairement la capacité de B. À l’inverse, une panne du composant partagé peut justifier une fermeture plus large. Le service doit distinguer ces causes avant d’appliquer la mesure. La coupure d’une fonction doit conserver les travaux ouverts et leurs propriétaires pour préparer une réouverture cohérente.

Paradoxalement, une infrastructure entièrement mutualisée peut rendre l’isolation des données plus exigeante tout en simplifiant la supervision. Cette vue globale ne doit pas devenir un droit global dans le parcours d’un opérateur. Les actions de support sensibles nécessitent un contexte explicite et une trace adaptée. La résolution d’un incident n’autorise pas à déplacer un travail dans un autre tenant pour contourner ses refus ou son quota.

Erreurs fréquentes dans un copilote multi-client

Étendre au cache une permission qui ne vaut que pour la source

La première erreur consiste à considérer le cache comme un contenu neutre parce qu’il contient une réponse du modèle. Cette réponse peut reprendre un prix, un contact ou une procédure privée. Elle conserve donc une frontière de lecture. Le nom d’une question et un identifiant local de document sont insuffisants lorsque deux clients ou deux périmètres internes peuvent produire des réponses différentes.

La deuxième erreur est d’invalider seulement les données, sans traiter les droits. Le montant peut être toujours exact et l’utilisateur ne plus être habilité. Les révisions ont des rôles distincts : source, permission, configuration et éventuellement modèle. Une clé très détaillée ne protège pas l’accès si la permission courante n’est jamais vérifiée. La recette doit provoquer chaque changement indépendamment pour localiser la condition manquante.

Réutiliser un contexte de travailleur ou un identifiant global

Un travailleur longuement actif peut traiter successivement A et B. S’il conserve une variable de contexte entre deux travaux, la deuxième mission risque d’utiliser les droits ou réserves de la première. L’exécuteur doit établir son contexte à partir du travail enregistré à l’admission et vérifier les conditions courantes, puis nettoyer ce qui ne doit pas être réutilisé. Les connexions mutualisées et objets de session méritent une recette particulière.

Une clé de déduplication globale peut également supprimer le travail de B parce que A possède déjà Q32. Ce défaut ne ressemble pas à une fuite, mais viole la séparation du service rendu. Il faut tester refus, mauvaise attribution et disparition de travail, pas uniquement les valeurs visibles dans une réponse. Les quotas et historiques doivent rester explicables pour chaque client après rediffusion ou reprise.

Plan d’action pour une recette de bout en bout

Commencez avec deux clients qui possèdent volontairement des objets aux identifiants identiques et aux valeurs opposées. Ajoutez deux personnes d’un même client avec des droits différents. Ce petit jeu rend visibles les confusions qu’un test sur identifiants globalement uniques pourrait manquer. La sortie attendue doit nommer les valeurs autorisées, les refus et les consommations, sans demander au modèle de confirmer lui-même l’absence de fuite.

1. Établir la source du contexte client. Reliez identité authentifiée, espace actif et permissions métier. Interdisez leur remplacement par les arguments du modèle. Définissez changement d’espace, délégation et contexte de support avant de raccorder les outils. Conservez la provenance dans une trace accessible aux personnes autorisées à investiguer.
2. Suivre les objets créés par l’assistance. Inventoriez sources, extraits, réponses, caches, brouillons et notifications. Attribuez tenant, lecteur et propriétaire à chaque entrée et sortie. Décidez ce qui peut être mutualisé et selon quelle équivalence de droits ; documentez les garanties supplémentaires fournies par le stockage et celles qui restent applicatives.
3. Éprouver attente et rediffusion. Changez source et permission entre admission et exécution. Présentez le mauvais tenant au travailleur, puis rediffusez la même demande et utilisez son identifiant chez l’autre client. Vérifiez travail conservé, refus attribué et réserve rapprochée. Ajoutez des payloads incompatibles pour la même clé dans la recette réelle.
4. Contrôler consommation et partage de capacité. Épuisez le quota de A et confirmez ce qui reste admissible chez B. Rattachez retries et réserves inconnues à leur mission d’origine. Testez ensuite la charge et les files partagées, car une bonne attribution comptable ne garantit ni équité d’exécution ni absence de perturbation entre clients.
5. Rendre l’incident et la réouverture opérables. Vérifiez les accès de support, les données de diagnostic et les moyens de suspendre une capacité. Nommez qui résout les travaux refusés et les réserves ouvertes. Conservez une preuve datée sur le périmètre réellement testé, avec les limites qui empêchent encore l’ouverture à une population plus large.

Le coût caché d’une isolation mal définie apparaît souvent après le prototype : invalidation de cache, reprise des files, reconstruction des historiques et réponse aux incidents. Prévoir ces responsabilités tôt permet de discuter les compromis du produit avant que les clients dépendent de l’assistance. Il ne faut pas mesurer seulement le coût de génération ; le fonctionnement partagé implique une charge de contrôle, d’instrumentation et de maintenance.

Le contrat d’exécution fixe l’entrée : sujet et tenant établis par le service, pièce et révisions. Sa sortie décrit préparation locale, refus ou exposition encore réservée. Le propriétaire produit attribue la responsabilité des travaux bloqués ; l’instrumentation relie motif, client et demande sans copier le document. Le repli conserve la consultation classique dans les droits courants. La recette rejoue ces transitions avec les connexions et outils effectivement utilisés.

Guides pour écran, identité, retour et budget

Relier la suggestion à son utilisateur et à son contexte

Le copilote intégré à l’écran métier relie sources, corrections et décisions de la personne. La transmission de l’identité et des droits délégués examine la frontière entre utilisateur et compte technique. Le contexte tenant complète ces conditions lorsque la même application sert plusieurs clients.

La lecture d’un objet peut être dans le bon tenant et rester interdite à la personne. Une délégation valide peut aussi porter une proposition sur une source ancienne. Ces dimensions doivent se rencontrer au point où l’application consulte, prépare ou applique le résultat. Le parcours utilisateur conserve une explication adaptée à la reprise, sans afficher les secrets ou politiques internes des services.

Conserver l’origine du retour et de la consommation

Le retour utilisateur après correction d’une suggestion doit lui aussi rester dans le bon périmètre. Une correction propre à A ne devient pas automatiquement une référence pour B. Son exploitation demande qualification, provenance et droits, avant de décider si elle peut contribuer à un jeu d’évaluation ou à une évolution commune.

Le registre de consommation doit suivre la même origine lors des reprises. L’exploitation peut relier ces événements par identifiants sans fusionner leur contenu ni leurs autorisations. Cette cohérence évite qu’un écran bien isolé repose sur des objets dérivés partagés sans décision explicite. Le produit gagne une frontière compréhensible pour les développeurs comme pour les personnes chargées des clients.

Conclusion : isoler le parcours complet du client

Une réponse peut être correctement filtrée au départ et perdre son isolation dans un cache, une file ou une reprise. Le contexte client doit donc rester établi par le service et attaché aux objets dérivés. Les droits courants continuent de décider leur lecture. L’identifiant d’une pièce, d’une demande ou d’une personne ne doit pas devenir une frontière implicite qu’un composant partagé interprète autrement.

Les dix-huit scénarios distinguent ces transitions sur deux clients fictifs. Bob retrouve 900 après le cache d’Alice à 120 ; Charlie reste refusé dans le même tenant. Une source ou une permission modifiée bloque la préparation en attente, et le quota de A n’efface pas le travail admissible de B. Ces résultats valident le contrôleur local, sans certifier un SaaS, une politique RLS ou une infrastructure cloud.

Le développement d’un copilote IA dans une application métier doit compléter cette recette avec les interfaces et les chemins effectivement partagés. Le contrat inclut cache, rediffusion, quota, support et réouverture. La qualité du service dépend aussi de ce qu’il conserve et de ce qu’il refuse après une attente, lorsque les conditions initiales ne suffisent plus.

Avant d’ouvrir un copilote à plusieurs clients, l’expertise IA sur mesure de Dawap peut vous aider à éprouver une même référence présente dans deux comptes. La recette doit traverser lecture, cache et travail différé, puis révoquer un droit pendant l’attente et faire changer de client au travailleur. Les refus doivent rester explicables sans révéler la pièce protégée ; les quotas et réserves doivent conserver leur attribution après chaque reprise.