Architecture

Lemniscate fournit l’environnement d’exécution confiné des agents de code, déployé dans votre périmètre. L’architecture de référence sépare quatre rôles : le poste du développeur, les services de la passerelle, l’exécution des agents et l’inférence. Lemniscate fournit les trois premiers et se raccorde à votre moteur d’inférence (livre blanc sécurité V3, section 3).

La passerelle est le seul composant qui parle à tous les autres. Elle tient les politiques, le journal et la révocation.

Le tableau d’ensemble

Les quatre rôles et les zones de confiance

Chaque rôle occupe une machine, physique ou virtuelle, avec une surface d’exposition connue (livre blanc sécurité V3, section 3.1).

Rôle	Ce qu’il porte	Ce qui le borne
Poste du développeur	l’extension seule : VS Code, JetBrains ou terminal	elle transmet la consigne, présente les différences et les demandes de validation, et ne connaît que l’adresse de la passerelle
Hôte des services de la passerelle	la passerelle, la base et la console d’administration	la passerelle est la seule interface exposée aux postes
Hôte d’exécution	un bac à sable par session, avec une copie de travail du dépôt	distinct de l’hôte de la passerelle, sans état entre deux sessions, un seul canal de contrôle entrant, ouvert par la passerelle
Serveur d’inférence	le moteur d’inférence et le modèle à poids ouverts	joint par la passerelle seule

Le périmètre de confiance du produit se réduit à deux composants : la passerelle et le bac à sable. Le modèle et l’agent en sont exclus. Ils sont traités comme des composants non fiables, et aucun droit ne repose sur leur comportement.

L’annuaire et le SIEM sont les vôtres. La passerelle s’y raccorde pour l’authentification (OpenID Connect) et pour l’export des journaux.

Les flux réseau autorisés et interdits

La matrice des flux tient sur huit lignes (livre blanc sécurité V3, section 3.3). Quatre flux sont autorisés, tous internes au périmètre. Quatre sont interdits par construction.

Statut	Flux	Détail
Autorisé	Poste vers passerelle	TLS ; seul flux du poste lié à Lemniscate
Autorisé	Passerelle vers hôte d’exécution	canal de contrôle unique, ouvert par la passerelle ; aucun flux dans l’autre sens
Autorisé	Passerelle vers moteur d’inférence	TLS et filtrage réseau ; seul l’hôte de la passerelle est autorisé à joindre le moteur
Autorisé	Passerelle vers annuaire et SIEM	authentification et export des journaux ; adresses fixées par vous
Interdit	Bac à sable vers tout réseau	aucune interface réseau, aucune résolution de noms
Interdit	Poste vers hôte d’exécution ou moteur	aucune route ; l’extension ne connaît que l’adresse de la passerelle
Interdit	Tout composant vers Internet	aucun flux sortant du périmètre, aucune télémétrie
Interdit	Hôte d’exécution vers tout composant	l’hôte ne prend pas l’initiative d’une connexion

Les bacs à sable sont créés sans interface réseau, aucune route n’existe entre le poste et l’hôte d’exécution ou le moteur, aucun composant ne dispose d’une adresse externe, et l’hôte d’exécution n’est pas client d’un autre composant.

L’accès au moteur d’inférence est contrôlé au niveau réseau : le moteur n’écoute que sur le réseau interne du serveur d’inférence, et votre filtrage n’autorise que l’hôte de la passerelle. Vous pouvez vérifier la matrice avec vos propres sondes. Un flux observé hors de cette matrice se traite comme un incident. Le détail de ce qui circule sur chaque flux est dans Où passent les données.

Le raccordement à l’existant

Lemniscate se pose à côté de ce qui est en place (livre blanc sécurité V3, section 3.4). La passerelle se raccorde à tout moteur d’inférence qui expose une API compatible OpenAI, avec le modèle à poids ouverts que vous retenez. L’annuaire et le SIEM sont les vôtres.

Deux déploiements en découlent :

• intégré à votre stack : vous gardez votre agent, votre proxy de modèles et votre moteur d’inférence, et Lemniscate ajoute l’exécution confinée, les politiques, le journal et la révocation ; voir Intégrer Lemniscate à votre stack ;
• assistant de code complet : Lemniscate fournit aussi l’extension, l’agent, la passerelle d’accès aux modèles et la mise en place du serveur d’inférence ; voir Installer l’assistant complet.

Les quatre modes de déploiement

Le même produit se déploie dans quatre modes (livre blanc sécurité V3, section 3.4).

Mode	Ce qui le caractérise
D01, connecté	réseau interne classique ; mises à jour par votre registre privé
D02, isolé	aucune connexion ; livraison et mises à jour par archive signée sur média, vérifiables hors ligne
D03, sensible ou Diffusion Restreinte	hôte d’exécution dédié ; rien n’est exécuté sur les postes, aucun moteur de conteneurs n’y est requis
D04, classifié	enclave dédiée ; pièces fournies en appui de votre homologation

L’homologation reste une décision de votre autorité. Les pièces que l’éditeur fournit à l’appui sont décrites dans Posture de conformité.

L’hôte d’exécution dédié est le mode de référence. Une variante exécute le bac à sable sur le poste, dans un conteneur sans privilège et sans réseau ; elle convient aux socles de poste qui admettent déjà un moteur de conteneurs. Les deux sont comparés dans Les garde-fous d’exécution.

core, la logique de l’extension

La logique commune aux trois formes de l’extension vit dans core/ : le dialogue avec la passerelle pour les appels de modèles (core/llm), les outils que l’agent peut demander (core/tools), les fournisseurs de contexte (core/context), le chargement de la configuration (core/config) et le protocole de messages qui relie le tout (core/protocol).

Le code est lu par exploration du dépôt à la demande. Lemniscate ne construit aucun index du code source : il n’existe pas de copie dérivée et persistante du code à protéger (livre blanc sécurité V3, sections 3.2 et 11.3).

Les enveloppes ne réimplémentent aucune de ces fonctions. Ce qui change d’une enveloppe à l’autre est la façon dont core est hébergé :

Enveloppe	Hébergement de core
VS Code	dans le processus de l’extension, par un messager en mémoire
JetBrains	dans un sous-processus séparé, dialogue en JSON sur l’entrée et la sortie standard
CLI lemni	lié au programme à la construction

Côté VS Code, VsCodeExtension.ts instancie core derrière un InProcessMessenger : un appel de fonction, sans frontière de processus.

Côté JetBrains, le plugin est en Kotlin et ne peut pas charger du TypeScript. core est donc empaqueté séparément dans binary/, que CoreMessenger.kt lance comme sous-processus et à qui il envoie des messages JSON portant un messageId, un messageType et une charge utile. Les réponses reviennent par le même canal ; celles qui concernent l’interface sont réémises vers le navigateur embarqué. La variable d’environnement USE_TCP bascule ce canal sur une connexion TCP, pour le débogage.

Côté CLI, la construction d’extensions/cli résout core/ et packages/* par alias : le programme publié contient la logique et ne la charge pas depuis ailleurs.

gui, une interface pour deux IDE

gui/ est une application React : l’écran complet du produit dans l’IDE, avec la conversation, l’agent, l’historique et la page de réglages. Ce n’est pas une bibliothèque de composants.

Les deux extensions l’embarquent. L’empaquetage de l’extension VS Code construit gui/ et vérifie la présence du bundle avant de produire le VSIX ; le plugin JetBrains sert le même bundle depuis ses ressources, dans un navigateur embarqué JCEF.

L’interface sait dans quel IDE elle tourne parce que la page qui la charge l’écrit dans le stockage local, sous la clé ide : vscode d’un côté, jetbrains de l’autre. gui lit cette valeur pour adapter les raccourcis clavier et quelques écrans.

Le CLI n’utilise pas gui : son interface est celle du terminal.

Les services de la passerelle

Les trois services sont installés chez vous, sur un hôte distinct de l’hôte d’exécution et du serveur d’inférence (livre blanc sécurité V3, section 6). La passerelle est le point d’application de toutes les politiques ; la base et la console la servent.

llm-gateway, la passerelle

Un serveur Hono. Le relais d’inférence est une route, ALL /:endpoint/* : le premier segment du chemin nomme un endpoint configuré en base ; le reste, chemin et chaîne de requête, est réémis vers l’URL de base du moteur d’inférence associé. D’autres routes sont posées avant ce relais, sous des préfixes réservés (/ide/ pour ce que le poste demande à la passerelle, la documentation hors ligne, l’exécution de commandes) ; un endpoint ne peut pas porter l’un de ces noms.

Avant de relayer, la passerelle enchaîne des contrôles dans un ordre fixe : vérification de l’identité de l’appelant, liste de révocation, résolution de l’endpoint, licence du déploiement, politique d’autorisation, droit de consommer, clé du moteur si celui-ci en déclare une, puis relais. Un endpoint inconnu est refusé sans que le droit de consommer soit consulté.

Elle n’impose aucun schéma au corps de la requête. Un corps qui se lit en JSON voit son champ model remplacé par celui de l’endpoint ; un corps qu’elle ne sait pas lire part inchangé. Une réponse en text/event-stream est relayée au fil de l’eau.

gateway-db, la base

Une base PostgreSQL. Elle porte la configuration que la console écrit (moteurs d’inférence déclarés, modèles, endpoints publiés, politique), la liste de révocation, le journal des décisions d’autorisation, les actes d’agent déposés par les postes et request_logs, une ligne par requête relayée.

Elle ne porte pas la clé d’accès à un moteur d’inférence. Pour chaque moteur déclaré, elle enregistre le nom de la variable d’environnement qui porte la clé et l’en-tête HTTP dans lequel la poser. La clé elle-même n’existe que dans l’environnement du processus llm-gateway.

gateway-admin, la console

Une application React servie par son propre serveur, réservée aux administrateurs. Dans une installation chez un client, elle montre trois onglets : les endpoints (Endpoints), la politique (Policy) et les actes de l’agent (Audit). Voir Ouvrir la console d’administration. C’est par elle que passent la déclaration d’un moteur ou d’un modèle, la publication d’un endpoint et l’écriture de la politique.

La console écrit directement dans la base, avec sa propre chaîne de connexion. Elle ne passe pas par la passerelle, et la passerelle ne lui parle pas. Le couplage entre les deux services est la base.

La passerelle relit la base à chaque requête, sans cache : un changement fait dans la console prend effet sur la requête suivante, sans redémarrage.

Ce que le diagramme ne montre pas

• La variante où le bac à sable s’exécute sur le poste. Le dessin montre le mode de référence, l’hôte d’exécution dédié.
• Le cycle d’une session : authentification, politique du projet, ouverture du bac à sable, travail de l’agent, différence et validation. Il est décrit dans Le cycle d’une session agentique.
• Ce que la passerelle fait d’un appel de modèle, contrôle par contrôle ; voir Le rôle de la passerelle.
• Les fonctions héritées du projet dont Lemniscate est issu et qui n’aboutissent pas ; voir Ce qui n’existe pas.