Point clé
Pour tenir la route dans un SaaS multilocataire, vos fonctionnalités IA ont besoin d'isolation des locataires, d'une récupération qui respecte les permissions, d'évaluations et d'un contrôle des coûts intégrés à votre modèle de données. Pas d'un chatbot greffé à côté.
Vos clients ont commencé à le demander. Certains en appel de vente. D’autres dans les sondages de désabonnement. Quelques-uns vous ont déjà montré ce qu’un concurrent a lancé.
La réponse rapide, c’est un widget de clavardage qui envoie les questions à un modèle avec quelques documents d’aide en pièce jointe. Il suffit d’un sprint. Le widget finit aussi, souvent, par servir une semaine avant d’être ignoré, parce qu’il ne sait rien des données du client et ne peut rien faire dans le produit.
Les fonctionnalités que les clients utilisent vraiment, semaine après semaine, sont différentes. Elles répondent à des questions sur les propres dossiers du client. Elles agissent dans l’application. Elles se retrouvent donc en plein cœur de votre modèle de données, de votre système de permissions et de votre architecture multilocataire. C’est aussi ce qui les rend difficiles.
Pourquoi les équipes restent bloquées
La génération augmentée par récupération (RAG) a l’air simple. Vous transformez votre contenu en plongements (embeddings), vous les stockez dans une base vectorielle, vous récupérez les extraits pertinents et vous les passez à un modèle. Les tutoriels en font le tour en vingt minutes.
Ces tutoriels supposent un seul utilisateur et un seul jeu de données. Votre produit compte des milliers de locataires (tenants), chacun avec ses propres données, et à l’intérieur de chaque locataire, des utilisateurs qui ne voient pas tous les mêmes choses. Un système de récupération qui ignore ces frontières, c’est une fuite de données qui n’attend que la bonne requête.
Les agents ajoutent une couche de plus. Dès qu’un modèle peut appeler vos API, chaque question de permissions que vous avez réglée pour votre interface revient sur la table. Cet utilisateur peut-il supprimer cet enregistrement? L’agent devrait-il avoir le droit de le faire, même si l’utilisateur l’a?
Vos développeurs sont tout à fait capables d’apprendre cela. Mais ils portent aussi la feuille de route, et ces décisions coûtent cher quand elles sont mal prises dans la première version.
Ce que nous construisons
Une récupération avec isolation des locataires
L’isolation passe en premier, avant tout le reste.
Selon votre échelle et vos exigences de conformité, nous isolons les locataires avec des index ou des espaces de noms séparés, ou avec un index partagé et des filtres de métadonnées obligatoires appliqués dans la couche de requête. Ce choix influe sur le coût, la performance et la difficulté de prouver l’isolation à un auditeur. Nous le faisons donc avec vous, selon la répartition réelle de vos locataires.
Dans tous les cas, la frontière entre locataires est appliquée dans du code que votre application contrôle. Elle ne dépend jamais du fait que le modèle suive des instructions. Le modèle ne voit jamais un résultat de requête qui a franchi la frontière d’un locataire, parce que la couche de récupération n’en retourne jamais.
Une récupération qui respecte les permissions
L’isolation des locataires ne suffit pas à elle seule. À l’intérieur d’un même locataire, un représentant des ventes ne devrait pas récupérer des documents RH simplement parce qu’ils sont dans le même espace de travail.
Nous transposons votre modèle de permissions existant dans la récupération. Chaque extrait indexé garde les métadonnées d’accès de son enregistrement source. Au moment de la requête, la récupération filtre selon ce que l’utilisateur courant peut voir, avec les mêmes règles que votre application applique déjà. Quand les permissions changent dans votre application, l’index en tient compte.
C’est la partie que la plupart des équipes sous-estiment. Pour bien la faire, il faut comprendre votre système d’autorisation en détail, y compris les cas limites comme les liens partagés, les enregistrements archivés et l’héritage des rôles.
La qualité de la récupération
Une fois la récupération sécuritaire, elle doit être bonne. Nous ajustons le découpage selon vos types de contenu, puisqu’un contrat, un billet de support et une fiche produit ne se traitent pas de la même façon. La plupart des produits gagnent à utiliser une recherche hybride qui combine similarité vectorielle et correspondance par mots-clés, avec une étape de reclassement. Nous mesurons la qualité de la récupération directement, avec des jeux d’évaluation distincts de ceux qui mesurent la qualité des réponses. Vous savez ainsi si une mauvaise réponse vient d’un mauvais contexte ou du modèle.
Des agents dans le produit qui posent de vraies actions
La couche d’agents transforme les capacités de votre produit en outils que le modèle peut appeler. Chaque outil a un schéma typé, une description claire et une implémentation côté serveur qui passe par votre logique d’affaires et vos vérifications d’autorisation existantes.
L’agent agit au nom de l’utilisateur, avec ses permissions. Si l’utilisateur ne peut pas archiver un projet dans l’interface, l’agent ne le peut pas non plus. C’est la couche d’outils qui l’impose, pas le prompt.
Pour les actions qui modifient des données, nous intégrons une confirmation dans l’interface. L’agent propose ce qu’il s’apprête à faire et l’utilisateur confirme. Les actions en lecture seule peuvent s’exécuter immédiatement. Les actions destructrices ou en masse ont une étape de plus. Chaque appel d’outil est journalisé avec l’utilisateur, le locataire, les entrées et le résultat.
L’infrastructure de soutien
Derrière les fonctionnalités, il y a l’infrastructure que vous exploiterez longtemps après le lancement :
- Un pipeline de plongements qui indexe les enregistrements nouveaux et modifiés de façon incrémentale, avec un remplissage rétroactif pour les locataires existants
- Un stockage vectoriel dimensionné pour vos données, souvent dans une base de données que vous exploitez déjà, comme Postgres avec pgvector
- Des évaluations de la récupération, de la qualité des réponses et de l’utilisation des outils, exécutées dans la CI à chaque changement
- Des contrôles de coûts, dont le suivi de l’utilisation par locataire, des limites de débit et un routage des modèles pour que les requêtes simples passent par des modèles moins chers
Où les humains gardent le contrôle
Vos utilisateurs gardent le contrôle de leurs données. Les agents proposent, et les utilisateurs confirment avant que quoi que ce soit change. Votre équipe garde le contrôle du système, avec un interrupteur d’urgence par fonctionnalité et par locataire, des tableaux de bord d’utilisation et des traces pour chaque requête. Quand un client demande pourquoi l’assistant a dit quelque chose, le support peut le vérifier.
Ce que veut dire « prêt pour la production »
Une démo répond à des questions sur des données d’exemple pour un seul utilisateur. Une fonctionnalité en production le fait pour chaque locataire et chaque rôle, sous charge, à un coût prévisible. Elle doit aussi passer votre revue de sécurité.
Il faut donc une isolation que vous pouvez démontrer, des permissions que vous pouvez tester et des évaluations qui attrapent les régressions avant vos clients. Il faut aussi que l’index reste synchronisé avec vos données, et que la fonctionnalité se dégrade proprement quand un fournisseur de modèles connaît une mauvaise journée.
Votre part
Dites-nous quelle fonctionnalité vous voulez et quel problème elle règle pour vos clients. Donnez-nous l’accès au dépôt et un responsable produit qui peut approuver la spécification et les parcours de confirmation. Il nous faudra environ une heure avec la personne qui connaît le mieux votre modèle d’autorisation.
Comment se déroule le développement
Vous décrivez la fonctionnalité. Nous en définissons la portée avec vous et convenons d’un prix fixe lié aux livrables, avant le début des travaux.
Des agents IA réalisent le travail sous la supervision d’ingénieurs seniors, responsables de l’architecture, de la conception de la multilocation et des permissions, et de chaque revue de code. Le résultat : du code prêt pour la production dans votre dépôt, conforme à vos conventions, documenté et remis à votre équipe pour qu’elle puisse le maintenir et le faire évoluer. Vos développeurs restent sur la feuille de route pendant le projet, et le code et l’infrastructure vous appartiennent dès le premier jour.
La livraison prend de quelques jours à quelques semaines, selon la portée.
Questions fréquentes
Faut-il une nouvelle base de données pour les vecteurs?
Souvent, non. Si vous utilisez Postgres, pgvector suffit pour bien des charges de travail. Nous recommandons une base vectorielle dédiée seulement quand votre échelle ou vos types de requêtes l'exigent.
Comment prouvez-vous l'isolation des locataires à nos clients?
L'isolation est appliquée dans la couche de récupération et couverte par des tests automatisés qui tentent de franchir les frontières entre locataires. Nous documentons la conception pour que votre équipe de sécurité puisse l'expliquer à vos clients.
Combien cela coûte-t-il à exploiter?
Cela dépend de l'utilisation et du modèle choisi. Nous intégrons le suivi des coûts par locataire dès le départ, pour que vous puissiez fixer le prix de la fonctionnalité avec de vrais chiffres.
Pouvons-nous construire les agents d'abord et ajouter le RAG plus tard?
Oui. La couche d'outils et la couche de récupération sont distinctes. Bien des produits commencent avec des agents qui agissent sur des données structurées, puis ajoutent la recherche documentaire dans une deuxième phase.
