Architecture de la plateforme LLM

Objectifs du prototype

Prendre en charge 50 utilisateurs.
Fournir à chaque utilisateur un espace privé pour ses données.
Isoler les sessions et les contextes d'agent entre utilisateurs.

Le mode d'exécution des agents reste à définir.

Le nombre d'utilisateurs actifs simultanément, les modèles LLM, les tailles de contexte, les volumes de données, la charge des jobs et les objectifs de latence restent à définir pour le dimensionnement.

Architecture fonctionnelle

Les organes en gris clair constituent le périmètre prioritaire du démonstrateur. L'intégration commence par un premier essai LLM et stockage, puis couvre le cœur applicatif, l'identité, le contrôle d'accès et l'accès client pour valider les objectifs multiutilisateurs.

Les ports Document, Vector / Retrieval, Async Job et Tool Runtime, en gris foncé, sont prévus dans une seconde phase de développement, une fois les éléments prioritaires validés.

Identity context

Dans ce schéma, Identity context désigne les informations d'identité vérifiées et le périmètre utilisateur associés à une requête :

L'identifiant de l'utilisateur authentifié.
La référence de son espace privé.
La référence de la session applicative concernée, lorsqu'elle existe.
Les attributs d'identité utiles aux contrôles d'accès, par exemple les rôles ou groupes retenus.

L'identité provient du token validé par le Web Layer. Le broker vérifie le rattachement à l'espace et à la session, puis consulte Permissions / Quotas pour décider de l'accès. La flèche depuis Identity / Accounts représente cet apport d'identité ; elle ne prescrit pas une connexion réseau directe à Keycloak pour chaque requête.

Ce contexte permet de déterminer qui agit et dans quel espace. Il est distinct du contexte de conversation envoyé au LLM, qui contient les échanges et les données nécessaires à la tâche.

Rôle de l'API / Web Layer

Le Web Layer est une « valve », un relais bidirectionnel authentifié. Son rôle est de :

Attendre une connexion client.
Vérifier le token du client.
Transmettre les échanges dans les deux sens entre le client et les composants en aval.

Il transmet l'identité validée au broker d'autorisation et au cœur applicatif. Les contrôles de droits et l'exécution métier restent dans ces composants. Le langage et le protocole de transport restent à choisir ; légèreté et rapidité sont les contraintes de cette couche.

Stack logicielle et dimensionnement

Le travail sur les briques existantes consiste principalement en configuration et intégration. Les développements maison sont indiqués séparément. Pour chaque composant, il faut évaluer sa charge puis les ressources à lui attribuer avant de chiffrer les besoins.

La colonne de dimensionnement indique les paramètres à évaluer, sans fixer de capacités. Le chiffrage devra distinguer l'effort de mise en place des coûts d'exploitation et compter une seule fois les ressources mutualisées.

Les priorités d'intégration remontent des services vers l'accès client : LLM, stockage, cœur applicatif, identité et autorisations, puis accès web. Les numéros fixent cet ordre de travail ; les traits épais séparent les groupes. Les lignes en gris clair couvrent le périmètre prioritaire, en commençant par l'essai LLM et stockage. Les lignes en gris foncé sont réservées à la seconde phase, après validation des priorités. Le proxy web accompagne le déploiement de l'accès client.

L'Identity Store et le Primary Data Store utilisent tous deux PostgreSQL, dans deux bases distinctes.

Priorité / périmètre	Organe	Solution	Travail à réaliser	Dimensionnement à évaluer	Coûts
1 · Data Plane	LLM Port	vLLM	Choix du modèle, du format des poids et de la quantification ; configuration et intégration	Modèle, contexte et concurrence ; calcul et mémoire, GPU/VRAM si retenus	À chiffrer
2 · Data Plane	Storage Port	À préciser	Intégration du stockage	Accès au stockage ; CPU/RAM	À chiffrer
2 · Data Plane	Primary Data Store	PostgreSQL	Configuration et intégration	Volume et requêtes ; CPU/RAM, disque et I/O	À chiffrer
3 · Data Plane	Application Core	À préciser	Runtime d'agent et intégrations à définir	Exécutions actives et contexte ; CPU/RAM	À chiffrer
4 · Control Plane	Identity / Accounts	Keycloak	Configuration et intégration	Connexions et sessions ; CPU/RAM	À chiffrer
4 · Control Plane	Identity Store	PostgreSQL	Configuration et intégration	Données d'identité et accès ; CPU/RAM, disque	À chiffrer
4 · Control Plane	Permissions / Quotas	Maison envisagé, à confirmer	Définition des règles et développement	Fréquence des contrôles ; CPU/RAM	À chiffrer
4 · Contrôle d'accès	Privacy / Authorization Broker	À préciser	Définir les contrôles d'accès et l'isolation par utilisateur	Fréquence des contrôles ; CPU/RAM	À chiffrer
5 · Accès web	API / Web Layer	Maison, langage à définir	Développement du relais authentifié bidirectionnel	Connexions, trafic et latence du relais ; CPU/RAM et réseau	À chiffrer
5 · Accès web	Proxy web	Nginx	Configuration et intégration	Connexions et trafic ; CPU/RAM et réseau	À chiffrer
5 · Accès web	Client / Frontend	À préciser	Solution et périmètre à définir	Sessions et volume des échanges	À chiffrer
Seconde phase · Data Plane	Document Port	RustFS	Configuration et intégration	Volume, croissance et redondance ; disque et réseau	À chiffrer
Seconde phase · Data Plane	Vector / Retrieval Port	Qdrant	Configuration et intégration	Nombre et dimensions des vecteurs, requêtes ; RAM et disque	À chiffrer
Seconde phase · Data Plane	Async Job Port — exécution	Celery	Configuration des workers et des files	Jobs simultanés et durée ; CPU/RAM des workers	À chiffrer
Seconde phase · Data Plane	Async Job Port — messagerie	RabbitMQ envisagé	Configuration du broker et des files	Débit, taille et rétention des messages ; CPU/RAM et disque	À chiffrer
Seconde phase · Data Plane	Async Job Port — ordonnancement	Maison sur Celery	Développement des règles d'ordonnancement métier	Cadence et nombre de jobs planifiés ; CPU/RAM	À chiffrer
Seconde phase · Data Plane	Tool Runtime Port	À préciser	MCP custom envisagés : client et droits par utilisateur	Connexions, appels et délais externes ; CPU/RAM et réseau	À chiffrer

Générer les rendus

make mermaid génère les SVG des blocs Mermaid dans var/output/architecture-<n>.svg.
make html régénère les SVG puis produit var/output/architecture.html, avec le diagramme intégré au texte et au tableau.
make format formate les scripts et la documentation.

Prérequis : Make, Node.js, pnpm, uv et un navigateur Chromium présent sur le PATH. La cible installe les dépendances Node si node_modules/ manque ; uv fournit la dépendance Python-Markdown du générateur HTML. Le rendu Mermaid charge Mermaid et ELK depuis jsdelivr et nécessite donc un accès réseau. Les fichiers de var/output/ sont ignorés par Git.