Installer l'assistant de code complet

Lemniscate fournit l’environnement d’exécution confiné des agents de code, déployé dans votre périmètre. Là où aucun agent, aucun proxy de modèles et aucun moteur d’inférence ne sont en place, Lemniscate fournit aussi l’extension pour VS Code, JetBrains et le terminal, l’agent, la passerelle d’accès aux modèles et la mise en place du serveur d’inférence. Cette page présente ce qui s’installe, sur quelle machine, et vous oriente vers la page qui traite chaque élément.

Si vous disposez déjà d’un agent, d’un proxy de modèles et d’un moteur d’inférence, le parcours qui vous concerne est Intégrer Lemniscate à votre stack.

Les quatre rôles

L’architecture de référence sépare quatre rôles, chacun sur une machine physique ou virtuelle (livre blanc sécurité V3, section 3.1).

Rôle	Ce qu’il porte	Ce qu’il joint
Poste du développeur	L’extension seule : consigne, différences, demandes de validation.	La passerelle, en TLS, et rien d’autre.
Services de la passerelle	La passerelle, sa base et la console d’administration.	L’hôte d’exécution, le moteur, l’annuaire, le SIEM.
Hôte d’exécution	Un bac à sable par session, sans réseau, avec une copie du dépôt.	Rien : il ne prend jamais l’initiative d’une connexion.
Serveur d’inférence	Le moteur et un modèle à poids ouverts.	Rien : seul l’hôte de la passerelle le joint.

Aucun de ces flux ne sort de votre périmètre, et aucun composant n’envoie de donnée à l’éditeur (livre blanc sécurité V3, sections 3.3 et 11.3).

L’ordre de mise en place

Chaque rôle dépend de celui qui le précède dans cette liste.

1. Le serveur d’inférence. La passerelle ne sert rien tant qu’aucun moteur ne répond derrière elle.
2. Les services de la passerelle. La base, puis la passerelle et la console. Vous y déclarez le moteur, les comptes ou l’annuaire, et la politique de chaque projet.
3. L’hôte d’exécution. La passerelle y ouvre un bac à sable par session.
4. Les postes. L’extension ne connaît que l’adresse de la passerelle.

L’installation et chaque mise à jour partent d’artefacts signés, livrés par registre privé ou sur média, et sont appliquées par votre équipe. Ni les services ni les extensions ne se mettent à jour seuls (livre blanc sécurité V3, section 9.3).

Le serveur d’inférence

La passerelle se raccorde à tout moteur qui expose une API compatible OpenAI (livre blanc sécurité V3, section 3.4). Le modèle est à poids ouverts, et vous le remplacez sans que les garanties de session changent : elles sont tenues par la passerelle et le bac à sable, pas par le modèle. Pour les sessions agent, le livre blanc recommande un indice d’intelligence Artificial Analysis de 34 au moins, comme critère d’efficacité et non de sécurité (section 8.1). Il recommande aussi le format safetensors et la vérification d’empreinte des poids (section 8.2).

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 à le joindre. Ni les extensions ni les bacs à sable ne connaissent son adresse.

Une fois le moteur en service, vous le déclarez à la passerelle : Déclarer un modèle servi par la passerelle.

Les services de la passerelle

La passerelle authentifie le développeur, applique la politique du projet, pilote la session, journalise et révoque. La base conserve les comptes, les politiques et le journal. La console est réservée aux administrateurs (livre blanc sécurité V3, section 06).

• Découvrir la passerelle monte les trois services sur un poste et y route un premier appel. C’est un montage de découverte, pas une procédure de production.
• Ouvrir la console d’administration décrit la première ouverture d’une console installée.
• Régler la politique des postes depuis la console décrit ce que l’administrateur autorise et retire.
• La passerelle refuse de démarrer traite chaque message d’arrêt au démarrage.

L’hôte d’exécution

Le bac à sable s’exécute sur un hôte dédié ou sur le poste (livre blanc sécurité V3, section 4.4).

L’hôte d’exécution dédié est le mode de référence. Les bacs à sable s’y exécutent sur une machine distincte de celle de la passerelle, aucun moteur de conteneurs n’est requis sur les postes, et l’environnement d’exécution est unique et durci par l’administrateur. Ce mode est retenu pour les périmètres sensibles et Diffusion Restreinte.

La variante exécute le bac à sable sur le poste, dans un conteneur sans privilège et sans réseau. Elle convient quand le socle des postes admet déjà un moteur de conteneurs. Ce que le poste doit alors fournir est décrit dans Préparer le conteneur de session du terminal.

Le choix se fait par périmètre, avec votre responsable de la sécurité.

Les postes

L’archive de livraison contient les trois formes de l’extension.

• VS Code : Votre première session dans VS Code va de l’archive reçue à une première réponse sur votre code.
• JetBrains : Modifier du code avec Lemniscate dans une IDE JetBrains.
• Terminal : la commande lemni, décrite dans Commandes du CLI.

Chaque développeur reçoit de l’administrateur l’adresse de la passerelle et de quoi s’y authentifier : Donner une clé d’API à une équipe.

Par où commencer

• Vous administrez le déploiement : commencez par Découvrir la passerelle.
• Vous êtes développeur et la passerelle de votre organisation répond : suivez Votre première session dans VS Code.
• Vous êtes responsable de la sécurité : Vérifier qu’aucune donnée ne sort établit, sur les artefacts livrés, qu’ils n’émettent rien.

Une fois la première session obtenue, Déléguer une tâche à un sous-agent montre comment confier une partie du travail à un agent secondaire.