Où passent les données

Lemniscate s’exécute intégralement dans votre périmètre, et aucun flux n’en sort. Cette page décrit où vit chaque catégorie de données, par quels flux elle circule entre les composants, et comment vous le vérifiez vous-même.

Les flux entre composants

Quatre flux sont autorisés, tous internes au périmètre (livre blanc sécurité V3, section 3.3). Chacun porte une catégorie de données connue.

Flux	Ce qui y circule
Poste vers passerelle	la consigne du développeur, ses décisions de validation, les différences à présenter
Passerelle vers hôte d’exécution	le canal de contrôle de la session : copie de travail du dépôt, commandes, résultats
Passerelle vers moteur d’inférence	le contexte transmis au modèle, le temps de la requête
Passerelle vers annuaire et SIEM	l’authentification et l’export des journaux

Quatre flux sont interdits par construction : du bac à sable vers tout réseau, du poste vers l’hôte d’exécution ou le moteur, de tout composant vers Internet, et de l’hôte d’exécution vers tout composant. La matrice complète, avec le détail de chaque ligne, est dans Architecture.

La cartographie des données

Six catégories de données, chacune avec un lieu et une durée connus (livre blanc sécurité V3, section 8.3).

Catégorie	Où elle vit	Durée
Code source du dépôt	le poste, et la copie de travail dans le bac à sable ; aucun index, aucune copie dérivée	la copie est détruite avec le bac à sable
Contexte transmis au modèle	entre la passerelle et le moteur d’inférence	le temps de la requête ; non conservé par défaut
Contenu des sessions	la base, chez vous, si vous activez sa conservation	rétention et chiffrement distincts, que vous fixez
Métadonnées d’usage	la base, chez vous : utilisateur, date, type d’action, fichiers, modèle	conservées
Secrets et identifiants	exclus du contexte, détectés à la passerelle	non journalisés en clair
Identités et groupes	votre annuaire, où ils sont lus	celle de votre annuaire

Les seules données persistantes par défaut sont les métadonnées d’usage. Le contenu des sessions n’est conservé que si vous le décidez. Par défaut, le journal ne contient ni les requêtes ni le code : il ne crée pas de copie du code source.

Le code est lu par exploration du dépôt à la demande. Lemniscate ne construit aucun index du code source, et n’entraîne ni n’ajuste aucun modèle sur votre code (livre blanc sécurité V3, section 11.3).

Toutes les données sont localisées chez vous. Vous répondez donc vous-même, avec vos procédures, à l’exercice des droits prévus par le RGPD. L’éditeur ne reçoit aucune donnée, et le produit ne contient aucun mécanisme qui le lui permettrait.

Entre la session et le modèle

Tout ce qui part vers le modèle traverse la passerelle (livre blanc sécurité V3, section 8.2).

• Le moteur d’inférence n’écoute que sur le réseau interne du serveur d’inférence.
• Votre filtrage réseau n’autorise que l’hôte de la passerelle à le joindre.
• Les extensions et les bacs à sable ne connaissent pas son adresse.
• La passerelle détecte les secrets avant transmission.

La détection de secrets repose sur des motifs connus (clés de fournisseurs d’infrastructure, jetons d’accès, clés privées, chaînes de connexion) et sur une détection par entropie. La politique fixe la réponse : bloquer, masquer ou alerter. Le blocage est la valeur par défaut.

Dans le bac à sable, l’agent ne voit que la copie de travail du dépôt, diminuée des fichiers désignés par les exclusions de contexte : fichiers d’environnement, répertoires de secrets, certificats. Le répertoire personnel du développeur, ses clés, ses identifiants de forge et ses variables d’environnement n’y sont pas montés ; voir Les garde-fous d’exécution.

Quand le moteur d’inférence est le vôtre, la provenance des poids du modèle reste sous votre responsabilité. Le livre blanc recommande le format safetensors, qui exclut l’exécution de code au chargement, et la vérification d’empreinte des poids.

Ce qui n’est pas émis

Aucun composant n’a de destination hors de votre périmètre (livre blanc sécurité V3, sections 1.3 et 11.3).

Ce qui n’est pas émis	Détail
Télémétrie produit	aucun événement d’usage ni rapport d’erreur
Vérification de version	aucun appel pour savoir si une mise à jour existe
Vérification de licence	aucun appel à l’éditeur
Sonde de démarrage	aucun appel au chargement des modules

Ni les services ni les extensions ne se mettent à jour seuls : une mise à jour est vérifiée puis appliquée par votre équipe. Le réglage allowAnonymousTelemetry, que la configuration du poste accepte, n’ouvre aucun envoi dans l’artefact on-premise : le code capable d’émettre n’y est pas.

Les deux premières lignes du tableau, dessinées avec les flux qui existent :

Trois choses se voient sur ce dessin.

• Ces flux ne s’arrêtent pas à une frontière : ils s’arrêtent au départ. La couche inerte est dans l’artefact du poste, pas à sa sortie ; c’est pourquoi elle est dessinée dedans. La croix n’est pas un pare-feu : il n’y a pas de drapeau à rallumer, et pas de règle réseau à écrire pour les empêcher.
• Le poste n’a qu’une destination, la passerelle. La règle de pare-feu des postes s’écrit en une ligne.
• Aucune flèche ne quitte le périmètre. Le moteur d’inférence est dans votre réseau, et la passerelle est seule à le joindre.

Le profil de construction

L’absence d’émission ne tient pas à un réglage : elle tient à la façon dont l’artefact est construit. Le produit se construit selon un profil de déploiement, choisi au moment de la construction et non à l’exécution. L’artefact installé dans votre périmètre est construit en profil on-premise. Le profil se lit dans l’argument --profile= de la construction ou, à défaut, dans la variable LEMNISCATE_DEPLOYMENT_PROFILE. Une valeur inconnue fait échouer la construction.

Le profil on-premise est le défaut : lancer la construction sans préciser de profil produit cet artefact. Un oubli de configuration ne peut donc pas produire un artefact qui émet.

Dans l’artefact on-premise, la couche de sortie réseau est inerte : elle n’est pas désactivée par un drapeau que l’on pourrait réactiver. L’implémentation inerte est celle que le code importe par défaut, et il n’y a donc rien à exécuter pour l’obtenir. Cet engagement correspond à une absence de code, constatable lors d’un audit.

Comment le vérifier

Deux vérifications se complètent : l’observation de votre réseau, et l’inspection de l’artefact livré.

Sur votre réseau

Le livre blanc propose trois vérifications que vous conduisez avec vos propres sondes (livre blanc sécurité V3, section 12.1) :

• observer le réseau, et constater qu’aucun flux n’existe hors de la matrice des flux ;
• tenter une sortie réseau depuis un bac à sable ;
• tenter une lecture hors de la copie du dépôt.

Sur l’artefact livré

La vérification porte sur l’artefact livré et non sur le code source : un script inspecte le bundle construit et échoue si l’un des symboles ou l’une des bibliothèques qu’il surveille y subsiste. Il applique quatre contrôles : les symboles interdits dans le texte des artefacts, les entrées des fichiers de construction, l’inventaire des unités déployables, et les appels de frontière au chargement d’un module. Les deux derniers lisent les sources, parce qu’un appel écrit chez l’appelant ne se voit pas dans la liste des dépendances du bundle.

npm run build --prefix extensions/cli
npm run esbuild-base --prefix extensions/vscode
(cd gui && NODE_OPTIONS=--max-old-space-size=6144 npx vite build)
npm run build --prefix llm-gateway
npm run build --prefix gateway-admin

Le contrôle inspecte six unités : les cinq ci-dessus et le greffon JetBrains (intellij). Sans l’option --composant, il les inspecte toutes. Un composant qu’on n’a pas construit n’est pas jugé conforme : il est signalé comme absent, et le contrôle échoue. Un artefact construit dans un autre profil est lui aussi signalé, comme indéterminé.

node scripts/verify-onprem-artifact.mjs \
  --composant cli --composant vscode --composant gui \
  --composant llm-gateway --composant gateway-admin

Cette commande, celle de l’intégration continue, nomme cinq composants. Le même contrôle s’exécute sur chaque proposition de modification du produit, avec ces cinq composants ; le greffon JetBrains s’inspecte de la même façon, en dehors de l’intégration continue. Une régression qui réintroduirait un appel sortant dans ces cinq composants ne peut pas être fusionnée sans faire échouer ce contrôle.

Le tutoriel Vérifier qu’aucune donnée ne sort conduit cette vérification pas à pas.

Ce que ce diagramme ne montre pas

• Les autres frontières de sortie du poste. core/egress est du code Node ; il ne couvre donc ni l’interface affichée dans l’IDE, ni le programme en ligne de commande. Ces deux-là ont leur propre frontière, inerte en on-premise de la même façon. Le dessin en montre une, il y en a trois.
• Le greffon JetBrains est la quatrième, et il fonctionne autrement. Il est écrit en Kotlin : la substitution de module, qui est un mécanisme JavaScript, ne l’atteint pas. Son équivalent est un profil de construction (-PprofilDeploiement, cloisonne par défaut) qui choisit un jeu de sources, et le résultat est le même : en profil cloisonné, la bibliothèque de rapport d’erreur n’est pas dans l’archive livrée. Le contrôle d’artefact ouvre cette archive, jusqu’aux fichiers .jar qu’elle contient, et l’inspecte comme les cinq autres unités.
• La portée du contrôle d’artefact. Il atteste l’absence d’une liste fermée de bibliothèques et de symboles nommés. L’absence de flux sortant se constate sur votre réseau, par les vérifications de la section précédente.
• L’annuaire et le SIEM, vers lesquels la passerelle s’authentifie et exporte les journaux. Ils sont dans votre périmètre, à des adresses que vous fixez.
• La configuration réseau de la passerelle elle-même : quelles autorités elle reconnaît, quel certificat elle présente. C’est le sujet de La chaîne de confiance.