Ce qui n'existe pas

Cette page liste ce que Lemniscate ne fait pas. Elle a deux parties : les engagements négatifs du produit, repris du livre blanc sécurité V3 (section 11.3), puis les surfaces héritées d’un autre projet, qui s’affichent dans le produit et n’aboutissent pas.

Aucun index du code source

Lemniscate ne construit aucun index du code source. L’agent explore le dépôt à la demande : il liste les dossiers, cherche un motif dans les fichiers et lit ceux dont il a besoin, pendant la session (livre blanc sécurité V3, sections 3.2 et 11.3).

Il n’existe donc aucune copie dérivée et persistante du code : ni base d’embeddings, ni carte du dépôt conservée d’une session à l’autre. Le code source se trouve sur le poste et dans la copie de travail du bac à sable, qui est détruite avec lui (livre blanc sécurité V3, section 8.3).

Aucun modèle d’embeddings n’est à déclarer, et aucun réglage n’active une indexation. Si un écran du produit vous a mené ici en proposant d’ajouter un modèle d’embeddings, aucune action n’est attendue de votre part.

Les autres engagements négatifs

Chacun de ces engagements correspond à une absence de code, qu’un audit peut constater (livre blanc sécurité V3, sections 3.3 et 11.3).

Aucune donnée envoyée à l’éditeur

Le produit n’envoie rien à l’éditeur : ni télémétrie, ni rapport d’erreur, ni vérification de licence. Il ne contient pas de fonction de remontée d’usage. Aucun composant n’a de destination hors de votre périmètre, et vous pouvez le constater sur votre réseau avec la matrice de flux (livre blanc sécurité V3, sections 1.3 et 3.3). Le détail des flux est dans Où passent les données.

Aucun entraînement sur votre code

Aucune donnée du client ne sert à entraîner ni à ajuster un modèle. Le modèle est le vôtre, servi par votre moteur d’inférence ; le produit ne lui transmet que le contexte d’une requête, le temps de cette requête (livre blanc sécurité V3, sections 1.3 et 8.3).

Ni identité, ni secret, ni réseau pour l’agent

L’agent n’a pas de compte et aucune identité sur la forge. Aucune clé, aucun jeton et aucune variable d’environnement du poste ne sont montés dans le bac à sable. Le bac à sable n’a pas d’interface réseau : aucune destination n’est joignable, ni externe ni interne (livre blanc sécurité V3, sections 4.1 et 4.3).

L’agent ne pousse donc rien. Vous intégrez la différence validée sous votre propre identité, par vos outils habituels et dans vos circuits de revue.

Aucun canal direct du poste vers une machine d’exécution

Le poste ne parle qu’à la passerelle : c’est son seul flux lié à Lemniscate. Aucune route n’existe entre le poste et l’hôte d’exécution ni entre le poste et le moteur d’inférence, et l’extension ne connaît que l’adresse de la passerelle. Le canal de contrôle vers l’hôte d’exécution est ouvert par la passerelle, et par elle seule (livre blanc sécurité V3, section 3.3).

Aucune commande ne relie donc un poste à une session qui s’exécute sur une autre machine, et aucun poste ne sert de session à un autre poste.

Aucune modification sans votre validation

Rien n’est appliqué à votre dépôt sans décision humaine. Chaque écriture retenue vous est présentée sous forme de différence, et vous l’acceptez ou la refusez (livre blanc sécurité V3, sections 4.1 et 5.4). Le déroulé est dans Le cycle d’une session agentique.

Aucune mise à jour automatique, aucun service externe

Ni les services de la passerelle ni les extensions ne se mettent à jour seuls. Une mise à jour est livrée par l’éditeur, par votre registre privé ou sur média, puis vérifiée et appliquée par votre équipe ; la version précédente est conservée pour un retour arrière (livre blanc sécurité V3, section 9.3).

Le produit fonctionne sans aucun service externe : le mode isolé n’a aucune connexion à l’éditeur (livre blanc sécurité V3, section 3.4).

Les surfaces héritées

Lemniscate est issu d’un autre projet. Ce projet s’accompagnait d’un service en ligne, un plan de contrôle et un registre de contenus partagés, et une partie du code du poste sait encore lui parler.

Ce service n’est pas opéré. Les commandes, les réglages et les écrans qui en dépendent existent dans le produit : ils s’affichent, ils s’autocomplètent, ils apparaissent dans l’aide. Ils n’aboutissent pas.

Les sections suivantes les nomment, parce que ces chemins échouent tard, avec des messages qui ressemblent à des erreurs de configuration.

Comment le constater

Le constat se lit dans le dépôt :

• l’adresse du plan de contrôle de l’éditeur vit dans core/control-plane/adressesDeLEditeur/ ; dans une installation qui ne désigne aucun plan de contrôle, les champs d’adresse portent une sentinelle qu’aucun client HTTP ne sait joindre ;
• le dépôt ne contient aucune moitié serveur de ce service ;
• l’artefact construit pour une installation chez un client (profil on-premise) remplace les modules qui parlent à ce service par des jumeaux absents, qui refusent en nommant leur cause (packageRegistry, depotDeSession et sessionsHebergees dans extensions/cli/src, core/egress).

Côté CLI

Un compte chez l’éditeur. Il n’existe aucun service d’identité opéré par l’éditeur, et lemni login ne s’y adresse pas : la commande demande à votre déploiement où se trouve votre annuaire d’entreprise, et connecte une personne nommée contre lui. Face à un déploiement qui n’en publie aucun, elle refuse en une phrase qui nomme l’administrateur à qui s’adresser. lemni logout efface la session enregistrée sur le poste.

Ce qui n’existe pas est le compte chez l’éditeur, pas la connexion.

Un contenu publié. Les drapeaux --rule, --prompt, --mcp, --agent et --config acceptent un identifiant propriétaire/paquet, qui désigne une ressource publiée dans un annuaire en ligne. Cet annuaire n’est pas opéré. Un tel identifiant arrête la session avec un refus qui nomme ce qui a été demandé et la forme locale qui le remplace.

Chacun de ces drapeaux a une forme locale, qui fonctionne : un chemin de fichier pour les cinq ; du texte donné directement pour --rule et --prompt ; une adresse pour --mcp ; le nom d’un agent découvert dans .lemniscate/agents/ du projet ou de votre répertoire personnel pour --agent.

--org <slug> désigne une organisation auprès du plan de contrôle et ne se résout pas ici. --model <nom> nomme un modèle que votre configuration déclare ; il se résout localement et fonctionne.

Une exécution hébergée. lemni remote crée un environnement de travail par un service central, et lemni remote --id demande à ce même service le tunnel d’une session en cours. L’artefact on-premise refuse ces deux chemins en nommant leur cause.

Le dépôt d’une session hors du périmètre. Le projet d’origine déposait la conversation et la différence d’une session vers un stockage géré par son éditeur, et y téléversait captures et journaux. L’artefact on-premise ne porte pas ces chemins. Une session se reconstitue depuis les journaux tenus par les services de la passerelle (livre blanc sécurité V3, section 7).

La mise à jour depuis le poste. /update n’installe rien : Lemniscate n’est pas publié sur npm, et l’artefact on-premise ne rapporte aucune version à installer. Une mise à jour vous est livrée, puis votre équipe la vérifie et l’applique ; voir Aucune mise à jour automatique.

Un repli moins visible. La commande racine lemni lit un fichier ~/.lemniscate/workstation.yaml. En son absence, et sans session ouverte, la résolution de configuration retombe sur une configuration par défaut distante, qu’elle demande à l’API absente, et le démarrage échoue. Ce n’est pas un défaut de la configuration locale : c’est le repli qui part chercher ailleurs. Un fichier de configuration local rend le CLI autonome.

Côté extension VS Code

Les agents en arrière-plan. Le mode background et les actions qui l’accompagnent (créer un agent, lister les agents) passent par le client du plan de contrôle. Le chemin exige aussi un dépôt hébergé sur GitHub.

La connexion au compte. Le fournisseur d’authentification et le gestionnaire de liens lemniscate:// sont enregistrés au démarrage de l’extension, ce qui rend l’entrée visible. La création d’une session refuse et dit pourquoi : sa cible est le service non opéré.

Côté configuration

Le bloc uses:. Le schéma de workstation.yaml accepte partout la forme uses: propriétaire/paquet, avec with: et override:, pour réutiliser un bloc publié ailleurs. La résolution d’un tel identifiant appelle le registre du plan de contrôle.

La même clé a une forme locale, qui fonctionne : un identifiant qui commence par ., / ou ~, ou qui porte le protocole file://, désigne un fichier du poste et ne sort pas de la machine. Tout le reste est lu comme un identifiant de paquet. La clé s’écrit de la même façon dans les deux cas :

models:
  # Chemin local : résolu sur le poste.
  - uses: ./blocs/relais-interne.yaml
  # Identifiant de paquet : aucun annuaire ne le résout ici.
  - uses: proprietaire/paquet

L’autocomplétion des modèles. L’éditeur propose une liste figée d’identifiants de modèles courants quand vous écrivez uses: sous models:. Cette liste est injectée dans le schéma JSON, donc elle apparaît dans l’IDE, mais chaque entrée serait résolue par le registre distant. Une suggestion acceptée ne produit pas une configuration valide.

provider: free-trial. L’essai gratuit qui passait par le proxy du projet d’origine n’est plus supporté. Les modèles qui le déclarent sont retirés au chargement.

Ce qui n’est pas concerné

Les services de la passerelle, llm-gateway, gateway-db et gateway-admin, n’ont rien à voir avec ce service hérité. Ils sont livrés au client, tournent chez lui, et ne dépendent d’aucun plan de contrôle de l’éditeur. Leur configuration vit dans leur base, pas dans un registre distant.

« Une partie du produit parle à un service qui n’existe pas » ne veut pas dire « le produit dépend d’un service qui n’existe pas ». Le chemin qui va de l’éditeur de code au modèle de langage, en passant par la passerelle, est autonome de bout en bout ; voir Le rôle de la passerelle et Architecture.

Comment reconnaître un nouveau cas

Trois signaux, dans le code comme à l’usage :

1. la surface parle d’organisation, de compte, d’assistant partagé, de registre ou d’agent distant ;
2. son chemin d’exécution traverse le client du plan de contrôle de l’éditeur (core/control-plane/client.ts), et non la politique d’organisation que la passerelle du client sert ;
3. elle demande un identifiant de la forme propriétaire/paquet.

Une surface qui coche ces cases n’aboutit pas, quelle que soit la configuration locale.