Latet
Bientôt disponible

Latet Enterprise

Latet remplace les secrets et les données personnelles des requêtes de vos agents IA par des valeurs factices réalistes, avant qu'elles ne partent. Avec Latet Enterprise, c'est votre équipe sécurité qui décide : elle fixe des règles que personne ne peut assouplir, se prononce sur chaque modification qui les affaiblirait et reçoit des événements et des rapports pour son SIEM et ses audits. Le tout tourne sur un serveur à l'intérieur de votre réseau.

S'inscrire sur la liste d'attente Écrire à info@latet.ai

Où il tourne

Latet Enterprise tourne sur votre propre serveur, dans votre réseau. Il n'y a pas de cloud Latet, et le serveur ne contacte jamais Latet.

Votre réseau
Ordinateurs Claude Code, Codex, OpenCode et d'autres agents
CI et programmes chacun avec sa propre clé d'API
Serveur Latet masque chaque requête et remet les vraies valeurs dans chaque réponse
Fournisseurs d'IA ceux que vos agents utilisent déjà
Connexion directe : bloquée
Pare-feu
Avec la règle du pare-feu en place, seul le serveur Latet atteint les fournisseurs d'IA.
  • C'est le serveur qui masque. Les ordinateurs et les programmes envoient leurs requêtes d'IA au serveur Latet en HTTPS, et le serveur masque lui-même chacune d'elles. Il ne s'en remet jamais à un ordinateur pour le faire.
  • Aucun appel à Latet. Le serveur se connecte aux fournisseurs d'IA et aux systèmes auxquels vous le reliez, comme votre fournisseur d'identité et votre SIEM. La licence est un fichier signé, vérifié hors ligne.
  • Votre point de contrôle, avec votre pare-feu. Le serveur devient votre point de contrôle dès que votre pare-feu n'autorise que lui à joindre les fournisseurs d'IA ; un ordinateur qui les joint directement le contourne. La documentation donne un exemple de règle. Latet ne vérifie pas qu'elle est en place.
Détails techniques
  • Déploiement. Des instances sans état tournent derrière votre répartiteur de charge, avec PostgreSQL et Valkey, en conteneur ou en tant que service systemd ou Windows.
  • Chiffrement. Dans PostgreSQL, les valeurs, les textes et les images de chaque personne et de chaque clé d'API sont scellés avec une clé qui leur est propre, et ces clés avec une clé maîtresse. Les noms de compte et les adresses e-mail sont stockés en clair.
  • La clé maîtresse. Le serveur la lit dans un fichier ou une variable d'environnement. Gardez-en une copie à l'écart des sauvegardes de la base de données.
  • Builds. Chaque version est produite par un workflow qui ajoute des attestations de provenance de build et un SBOM CycloneDX.

Contrôle

Votre équipe sécurité définit en un seul endroit les règles communes à tous, avec un plancher sous lequel personne ne peut descendre, et se prononce sur les modifications qui réduiraient la protection.

Des règles pour tous

  • Une seule définition, pour tous. Termes, listes, reconnaisseurs, règles de champ et niveaux de protection se définissent sur le serveur et s'appliquent à chaque personne et à chaque clé d'API ; chacun y ajoute les siens.
  • Un plancher, pas un plafond. Les réglages de chacun s'ajoutent à votre politique. Une modification qui passerait sous ce plancher est refusée, qu'elle vienne du tableau de bord, de la ligne de commande ou d'un import, et le message de refus indique le réglage verrouillé par votre entreprise.
  • Visibles par tous. Dans le tableau de bord, chacun voit les réglages verrouillés, marqués d'un cadenas.
  • Sur le serveur, tout de suite. La politique est dans la base de données du serveur et s'applique aussitôt à chaque personne et à chaque clé d'API.
Détails techniques
  • Format. La politique reprend le format du fichier de règles de Latet : vous pouvez partir d'un export des règles que vous utilisez déjà.
  • Sans serveur. Votre outil de gestion des appareils installe un fichier de politique là où seuls les administrateurs peuvent écrire : C:\ProgramData\Latet\policy.yaml, /Library/Application Support/Latet/policy.yaml ou /etc/latet/policy.yaml.
  • La limite d'un fichier. Quiconque est administrateur de son propre ordinateur peut le supprimer. Pour un plancher qui tienne, il faut le serveur et la règle du pare-feu.

Approbations centralisées

  • Votre équipe sécurité décide. Quand votre politique le prévoit, une modification qui réduirait la protection, comme laisser passer une valeur en clair ou désactiver une règle, est soumise aux personnes qui ont le rôle sécurité.
  • Aucune valeur dans la demande. Une demande d'approbation indique le réglage qu'elle modifierait, jamais une valeur.
  • Clair pour la personne qui attend. Elle voit qui décide.
  • Le Relecteur en direct, si vous le souhaitez. Le Relecteur en direct retient chaque nouveau texte jusqu'à ce que quelqu'un l'approuve. Votre entreprise peut confier cette approbation à l'équipe sécurité plutôt qu'à chaque personne. Chacun en est informé.

Preuves

Latet Enterprise envoie des événements à votre SIEM et produit des rapports pour vos audits. Ils contiennent des décomptes et des catégories, jamais une valeur.

Des événements pour votre SIEM

  • Splunk. Les événements partent vers le HTTP Event Collector (HEC) de Splunk.
  • Syslog. Les événements partent en messages RFC 5424 sur TLS, vers rsyslog, syslog-ng ou un collecteur placé devant Microsoft Sentinel.
  • Webhook. Chaque événement part en JSON, en HTTPS, vers l'adresse de votre choix, avec les en-têtes dont le destinataire a besoin. Cela fonctionne avec Elastic, avec Microsoft Sentinel via une Logic App, et avec des collecteurs comme Vector ou Fluent Bit.
  • Jamais bloquant. L'envoi d'un événement ne retient jamais la requête d'un agent. Les événements attendent dans une file et sont renvoyés si votre SIEM ne répond pas.
Détails techniques
  • Types d'événement. exchange, stopped, approval, change, policy, sync, sign-in, license, et admin pour le journal d'administration.
  • Livraison. Chaque événement est livré au moins une fois, dans l'ordre, par lots de 500 au plus qu'envoie une seule instance à la fois. Après un échec au milieu d'un lot, une partie peut arriver deux fois : l'id de chaque événement permet de repérer les doublons.
  • Nouvelles tentatives. Si le destinataire ne répond pas, Latet réessaie après 5 secondes, 10 secondes, 30 secondes et une minute, puis toutes les 5 minutes. Les événements attendent dans l'ordre, même après un redémarrage.
  • Secrets. Les jetons et les clés sont scellés dans la base de données du serveur. Un webhook doté d'un secret est signé (x-latet-signature), et http:// est refusé, sauf vers le serveur lui-même.
Un événement : des décomptes, jamais une valeur
{
  "v": 1,
  "id": "3f9a0c1d2e4b4c6f8a1b2c3d4e5f6071",
  "ts": "2026-11-03T09:12:44Z",
  "type": "exchange",
  "identity": null,
  "kind": "person",
  "group": "g_payments",
  "agent": "claude-code",
  "project": "billing-api",
  "masked": {"EMAIL": 3, "IBAN": 1},
  "stopped": 0,
  "reason": null,
  "outcome": null,
  "by": null,
  "rule": null
}

Trois adresses e-mail et un IBAN ont été masqués dans cet échange. L'événement indique combien et de quel type, jamais lesquels. Tant que les rapports sont établis par groupe, ce qui est le réglage par défaut, identity reste à null.

Rapports

  • Dans le tableau de bord. Filtrez par période, groupe, projet, agent ou catégorie, suivez l'évolution dans le temps et exportez en CSV ou en JSON.
  • Indépendants de l'historique. Les rapports viennent d'un journal d'événements à part, avec sa propre durée de conservation : ils fonctionnent même quand l'historique est désactivé.

Journal d'administration

  • Qui a fait quoi. Chaque action d'administration est enregistrée avec son auteur, sa nature, sa cible, sa date et l'adresse d'origine, mais jamais une valeur. Le journal est conservé 365 jours, sauf si vous en décidez autrement.
  • Les modifications se voient. Chaque entrée porte l'empreinte de la précédente. latet server log verify, une vérification toutes les heures et latet server status indiquent si la chaîne est intacte.
  • Aussi dans votre SIEM. Une chaîne d'empreintes révèle une modification mais ne l'empêche pas : qui peut écrire dans la base de données peut réécrire toute la chaîne. C'est pourquoi le journal part aussi vers votre SIEM.
  • Sur chaque serveur. Le journal existe sur chaque serveur Latet, dès la Community Edition. Enterprise l'ajoute aux rapports et au SIEM.

Les noms propres à votre entreprise

Latet repère ce qui a un format reconnaissable : clés, adresses e-mail, IBAN, numéros d'identité. Les noms de vos clients et les noms de code de vos projets n'en ont pas. Latet Enterprise les reprend de vos propres systèmes et les masque comme n'importe quelle autre valeur, sans que personne ait à les saisir.

  • Depuis un fichier ou une URL. Latet lit à intervalles réguliers une liste en CSV, JSON ou YAML, que n'importe quel système peut produire.
  • Depuis Microsoft Entra ID. Latet reprend les noms et adresses e-mail des personnes, ainsi que les noms des groupes, via Microsoft Graph.
  • Depuis LDAP et Active Directory. Latet lit les noms directement dans votre annuaire.
  • Depuis un CRM, sur demande. HubSpot ou Salesforce sont proposés quand un client le demande.
Détails techniques
  • Types de termes. Chaque source associe ses champs à des types comme CLIENT, PERSON et PROJECT.
  • Scellés. Les termes synchronisés sont conservés scellés dans PostgreSQL, pas dans un fichier de réglages : une liste de clients est sensible en soi.
  • Supprimés à la source. Un terme qui disparaît de sa source reste masqué, signalé comme absent, jusqu'à ce qu'une personne ayant le rôle sécurité le supprime.

Connexion et rôles

Chacun se connecte avec votre fournisseur d'identité, et les comptes restent synchronisés avec lui.

  • Authentification unique avec OIDC. Elle fonctionne avec Microsoft Entra ID, Google, Okta, Keycloak, Authentik, Auth0 et d'autres fournisseurs OIDC. SAML 2.0 est proposé sur demande.
  • Comptes via SCIM 2.0. Votre fournisseur d'identité crée et désactive les comptes. Seuls les membres du groupe que vous choisissez, par exemple latet-users, en reçoivent un.
  • Désactivé, donc déconnecté. Désactiver le compte d'une personne ferme aussitôt ses sessions et invalide ses jetons sur toutes les instances, et libère sa place.
  • Groupes et rôles. Les groupes viennent de votre fournisseur d'identité ou sont créés à la main. Les rôles s'attribuent à des personnes ou à des groupes.
Détails techniques
  • OIDC. Latet utilise le flux de code d'autorisation avec PKCE. Le secret client est scellé avec la clé maîtresse, et les groupes du jeton correspondent aux groupes de Latet.
  • SCIM. Le serveur expose /scim/v2/Users et /scim/v2/Groups, la partie de SCIM 2.0 qu'utilisent Entra ID et Okta.
Rôles
Rôle Voit Décide
Utilisateur ses propres données et les clés d'API qu'il contrôle ses propres réglages, au-dessus du plancher, et ceux des clés d'API qu'il contrôle
Responsable de groupe les rapports de ses groupes rien
Sécurité tous les rapports la politique, les termes, les approbations, le SIEM
Auditeur les rapports, l'historique de la politique et le journal d'administration, en lecture seule rien
Administrateur les personnes, les groupes et les clés d'API la connexion, les rôles, la licence, les clés d'API et qui les contrôle

La confidentialité au sein de l'entreprise

Latet tient les valeurs de chacun à l'écart des fournisseurs d'IA, et aussi de vos administrateurs.

  • Les données de chacun lui appartiennent. Personne ne voit les valeurs ou les textes d'une autre personne, administrateurs compris. Le coffre-fort, l'historique et les approbations de chacun ne sont qu'à lui.
  • Des rapports sans contenu. Les rapports et les événements SIEM contiennent des décomptes, des catégories, des identifiants de règle, l'agent, le projet, le groupe et le résultat, mais jamais de valeur, de texte ni de valeur factice.
  • Une exception, choisie ouvertement. Si l'équipe sécurité approuve les textes du Relecteur en direct, la personne qui approuve voit chaque texte, valeurs comprises. Votre entreprise le décide et en informe chacun.
  • Des rapports par groupe, par défaut. Les rapports par personne, sous pseudonyme ou nominatifs, sont une option que votre entreprise active, après un accord avec ses salariés quand la loi l'exige.
Détails techniques
  • Quand la loi exige un accord. En Italie, l'art. 4 du Statuto dei lavoratori (L. 300/1970) ; en Allemagne, la codécision du comité d'entreprise (BetrVG, § 87, al. 1, n° 6).

Ce qu'obtient un auditeur

Ce que vos auditeurs peuvent vérifier par eux-mêmes.

  • Un rôle en lecture seule. Les auditeurs voient les rapports, l'historique de la politique et le journal d'administration, et ne modifient rien.
  • Des chiffres par période. Les rapports indiquent combien de valeurs ont été masquées et de quels types, combien de requêtes ont été bloquées et combien de modifications ont été approuvées, par groupe, projet et agent, mais jamais une valeur.
  • Qui a changé quoi. L'historique de la politique, le journal d'administration et les événements d'approbation montrent qui a changé quelle règle et qui l'a approuvée.
  • Un journal vérifiable. La chaîne d'empreintes se contrôle avec latet server log verify.
  • De quoi nourrir une AIPD. La documentation dit ce que Latet conserve, où, ce qui est scellé et ce qui est en clair, et pendant combien de temps.
Ce que ces preuves couvrent
Référentiel Articles et mesures
RGPD Pseudonymisation (art. 4, point 5), protection des données dès la conception (art. 25), sécurité du traitement (art. 32, par. 1, point a)
ISO/IEC 27001:2022, annexe A 8.11 masquage des données, 8.12 prévention des fuites de données, 8.15 journalisation, 8.16 activités de surveillance

Latet réduit l'exposition ; votre conformité dépend de vos propres mesures.

La licence

Le serveur fait partie de la Community Edition, gratuit pour toute entreprise, avec un journal d'administration. Latet Enterprise ajoute tout le reste de cette page, y compris les règles communes à tous.

Qui en a besoin. Une entreprise qui utilise les fonctions Enterprise en production a besoin d'une licence Latet Enterprise. Développer et tester avec elles est gratuit, et la Community Edition, serveur compris, reste gratuite pour toute entreprise, quelle que soit sa taille.

Vérifiée uniquement par les fonctions Enterprise. La Community Edition n'a pas de clé de licence et ne vérifie rien. Seules les fonctions Enterprise lisent le fichier de licence, hors ligne.

Qui est compté

Comme dans Jira, chaque compte actif ayant accès à Latet est compté, qu'il ait servi ou non ce mois-là. Une personne ne compte qu'une fois, quel que soit le nombre de ses ordinateurs et de ses groupes. Chaque clé d'API active compte pour un utilisateur. Désactiver un compte libère aussitôt sa place.

Le fichier de licence

Il est signé avec Ed25519 et vérifié hors ligne, sans activation. Il indique votre entreprise, le nombre d'utilisateurs achetés, les fonctions et la date de fin, que latet license show et latet doctor affichent.

L'essai

Développer et tester avec les fonctions Enterprise ne nécessite aucune licence. Pour les essayer d'abord en conditions réelles, une entreprise peut demander un fichier de licence d'essai, valable 32 jours.

Si le renouvellement tarde

  1. 30 jours avant l'échéance Un avertissement

    Les administrateurs voient un avertissement dans le tableau de bord et dans latet doctor.

  2. L'échéance Rien ne change encore

    Pendant 30 jours de plus, tout continue de fonctionner comme avant.

  3. 30 jours après l'échéance Plus rien de nouveau

    Latet cesse de produire pour vous de nouveaux rapports et exports, des événements SIEM et des synchronisations de termes. Les termes déjà synchronisés restent masqués.

  • La protection ne s'arrête jamais. Les règles verrouillées le restent, les approbations suivent leur circuit et chacun peut toujours se connecter.
  • Plus d'utilisateurs que prévu. L'avertissement arrive tout de suite, puis viennent les mêmes 30 jours et la même pause.

Latet continue de protéger pour que personne ne reste exposé, mais la licence reste nécessaire. Une entreprise qui continue d'utiliser Latet Enterprise après l'échéance la renouvelle, et une entreprise qui dépasse le nombre d'utilisateurs achetés paie les utilisateurs supplémentaires.

Les conditions complètes

Contact

Pour parler du cas de votre entreprise, écrivez à info@latet.ai. Indiquez combien de personnes utiliseraient Latet, quel fournisseur d'identité et quel SIEM vous utilisez, et avec quels agents travaille votre entreprise.

Recevez un message quand Latet Enterprise sera disponible

Laissez votre adresse e-mail : vous recevrez un seul message quand Latet Enterprise sera disponible, et rien d'autre.

Comment l'adresse est conservée

Des questions sur Latet Enterprise ?

Écrivez à cette adresse :

info@latet.ai

Écrire un e-mail