Plateforme IA multi-assistants

Plateforme IA multi-assistants.

Une seule plateforme, plusieurs clients indépendants, plusieurs contraintes de livraison

Année.

2025

Employeur.

Sagacify

Rôle.

Lead Technique

Contexte.

Plusieurs organisations clientes avaient besoin d'une interface conversationnelle interne, pour que leurs équipes obtiennent des réponses et exécutent des tâches sur leurs propres données, sans que ces données ne quittent jamais leur infrastructure. Chacune avait une contrainte de livraison différente : une web app autonome, un widget embarquable sur un site existant, ou une intégration SharePoint dédiée pour l'intranet d'un client.

Challenge.

Porter l'ensemble de la plateforme (API, frontend, livraison temps réel, et chaque intégration spécifique à un client) derrière plusieurs assistants à l'identité indépendante, tout en gardant le coût d'onboarding d'un nouveau client, ou d'un nouvel assistant pour un client existant, assez bas pour qu'une petite équipe puisse le tenir.

Décisions et compromis.

  • Couche de Streaming Partagée : Redis Pub/Sub encapsulé dans un petit service basé sur un EventEmitter, pour que le reste de l'API puisse s'abonner à un canal sans toucher directement au client Redis. Il retransmet en direct la réponse de chaque assistant à l'utilisateur, au fur et à mesure qu'elle est générée, et la même couche de streaming sert la web app, le widget embarquable et l'intégration SharePoint indifféremment : aucun des trois n'a eu besoin de sa propre version.

  • Deux Versions d'Assistants : Sous le capot, les assistants existent en deux versions : une conversationnelle simple pour du chat libre, et une structurée, construite autour d'un formulaire en plusieurs étapes avec des entrées et sorties typées à chaque étape. Mettre en place un nouvel assistant structuré revient surtout à décrire ce formulaire sous forme de données, en réutilisant le même jeu de types d'entrée (texte, liste déroulante, upload de fichier, etc.) plutôt qu'à construire de nouveaux composants chaque fois.

  • Identité Fédérée par Client : Keycloak se place devant l'Active Directory propre à chaque client plutôt qu'une intégration sur mesure par client, si bien qu'onboarder les utilisateurs d'une nouvelle organisation est une étape de configuration plutôt que du nouveau code d'authentification, quel que soit le fournisseur d'identité déjà en place.

  • Couche de Livraison Flexible : La livraison s'adapte à l'endroit où le client a besoin de faire vivre l'assistant : une web app autonome, un web component agnostique embarquable sur n'importe quelle page existante, ou un widget SharePoint SPFx pour un intranet. Supporter les trois a demandé d'investir dans une couche d'intégration flexible unique, plutôt que de construire un cas particulier chaque fois que les contraintes d'un client ne correspondaient pas aux autres.

  • Fonctionnalités Activables à la Demande : Des fonctionnalités comme l'upload de documents ou la saisie vocale sont derrière des feature flags, pour pouvoir être activées par assistant sans déploiement, dès qu'un cas d'usage client le justifie réellement.

Résultat.

Plusieurs assistants indépendants tournent en production sur cette plateforme, avec une console admin donnant aux clients des graphiques d'usage quotidiens et une table de feedback où chaque retour renvoie exactement à la conversation dont il provient.

Stack.

Redis Pub/Sub pour le streaming en direct, Keycloak pour l'identité, SharePoint SPFx pour la livraison sur l'intranet.

TypeScript

React

Shadcn UI

Tailwind CSS

React Hook Form

React Query

Zod

Fastify

Objection.js

Unit Testing

Keycloak

AWS

Redis

Terraform