Sécurité by design, pas en option
L'architecture LMbox est pensée d'abord pour que vos données ne sortent jamais. Voici comment, concrètement.
100 % on-premise
Aucune connexion sortante par défaut. La Box fonctionne dans votre LAN, isolable en air-gap si besoin. Vos données ne transitent JAMAIS par un service tiers.
Chiffrement bout-en-bout
TLS interne, LUKS sur disque avec TPM 2.0, Postgres chiffré at-rest, sauvegardes Restic chiffrées. Les clés restent chez vous, jamais chez nous.
SSO entreprise
Intégration native Active Directory, Azure AD, Okta, Google Workspace via OIDC. Authentik en frontal pour les autorisations fines par groupe.
Audit logs
Toute interaction tracée et signée : qui a posé quoi, quand, à quel modèle, avec quelles sources. Rétention configurable selon votre politique.
Une Box, des couches
┌──────────────────────────────────────────────────────┐
│ Internet ❌ pas d'accès │
└──────────────────────────────────────────────────────┘
│
┌────────┴────────┐
│ Firewall LAN │ Port 443 entrant uniquement
└────────┬────────┘
│
┌─────────────────┴─────────────────┐
│ Reverse proxy + TLS (Caddy) │ Cert. CA entreprise
└─────────────────┬─────────────────┘
│
┌─────────────────┴─────────────────┐
│ SSO Authentik (OIDC vers AD) │ Auth + autorisation
└─────────────────┬─────────────────┘
│
┌──────────────┬──────┴──────┬──────────────┐
│ Open WebUI │ LiteLLM │ lmbox-rag │
│ (chat UI) │ (API gw) │ (RAG, KB) │
└──────┬───────┴──────┬──────┴──────┬───────┘
│ │ │
└──────────────┴─────────────┘
│
┌────────┴────────┐
│ Ollama │ Modèles locaux
│ (Gemma 4 ...) │ Ryzen 9 7950X CPU / RTX Pro 6000 GPU
└─────────────────┘
Postgres (chiffré at-rest, LUKS + TPM 2.0)
Audit logs centralisés (rétention configurable)
Sauvegardes Restic chiffrées vers NAS interneLMbox vs services cloud d'IA générative
| Critère | LMbox (on-prem) | ChatGPT / Claude / Gemini cloud |
|---|---|---|
| Où vivent vos données ? | Dans votre datacenter | Datacenters US/UE éditeur |
| Données en transit | LAN interne, TLS | Internet vers cloud public |
| Données au repos | Vos disques, vos clés | Disques éditeur, leurs clés |
| SSO entreprise | Natif (OIDC/SAML) | Selon plan |
| Clés de chiffrement | Sous votre contrôle | Géré par l'éditeur |
| Audit logs | Complets, à vous | Partiels, leur périmètre |
| Base légale RGPD | Traitement interne (article 6) | Sous-traitance + DPA |
| Notification de violation | Vous décidez | Selon SLA éditeur |
| Lock-in fournisseur | Aucun, vous gardez tout | Élevé |
Notre roadmap conformité
Quatre couches déterministes empêchent l'agent d'inventer.
« Et si l'IA dit n'importe quoi ? » est la question des cabinets d'avocats et des Compliance Officers. La réponse honnête n'est pas « notre modèle est meilleur ». Les LLM hallucinent - tous, du Mistral-7B au GPT-4. La réponse LMbox est architecturale : quatre couches indépendantes, chacune capable de bloquer l'hallucination, câblées en parallèle sur chaque agent du catalogue.
Layer A - Citation Verifier
Chaque référence émise par l'agent (arrêt de Cassation, article de Code, loi, décret, règlement UE, pièce du dossier) est extraite par 11 familles de regex et vérifiée contre Légifrance + EUR-Lex. Une référence introuvable → CRITICAL. Une référence malformée (« 12 jav 2024 ») → CRITICAL. 11 familles, 7 codes français mappés, cache LRU + rate-limit production-grade.
lmbox agent verify
Layer B - Runtime Guard
Garde-fou en temps réel sur le stream LLM : dès qu'une citation hallucinante est complète dans la sortie, la génération est coupée (strict) ou annotée inline (annotate) ou journalisée pour observabilité (warn). Plus besoin d'attendre la fin du brief pour découvrir l'erreur - 200 ms après le token problématique, l'agent est arrêté.
lmbox agent run --guard strict
Layer C - Structured Output
Chaque agent déclare un JSON Schema dans son manifest (draft 2020-12). Toute sortie est validée + re-promptée si invalide (jusqu'à 2 retries). Un linter à 7 règles attrape les bugs de design schéma à l'écriture, avant déploiement. Plus de dérive de forme entre agents et pipelines downstream.
lmbox agent lint-schema --strict
Layer D - Source Grounding
Chaque identifiant cité dans la sortie (document_id, protocol_id, source_id) DOIT venir d'un tool call de ce turn. Si l'agent prétend citer interne-2019-453 sans avoir appelé search_dossiers_internes qui le retourne, c'est rejeté. La couche architecturale qui rend physiquement impossible une source inventée.
lmbox agent check-grounding
L'agent invente « Cass. Com., 12 janvier 2024, n° 22-15.487 »
Cet arrêt n'existe pas. Mais sa forme est parfaite : juridiction valide, mois valide, format pourvoi valide. Aucun œil humain ne va le détecter dans une conclusion de 30 pages. Voici comment les 4 couches l'attrapent - chacune indépendamment :
-
A
Layer A appelle Légifrance live, ne trouve pas l'arrêt →
CRITICAL: external_not_found. Suffisant à lui seul pour faire échouer la suite golden et bloquer le déploiement. - B Layer B attrape le résultat de Layer A en cours de stream : dès que la citation est complète + suivie de 40 caractères, le verifier la passe à Légifrance. Si NOT_FOUND, la génération s'arrête. L'avocat ne lit jamais le brief contaminé.
-
C
Layer C exige (dans le schéma Conclusions Drafter) que toute jurisprudence citée dans le markdown apparaisse aussi dans
cited_jurisprudence[]avec un source_id. Une citation inline sans entrée métadonnée → schéma invalide, repair loop, échec si non corrigé. -
D
Layer D vérifie que le source_id revendiqué vient d'un tool call de ce turn. Sans appel à
search_jurisprudencequi aurait retourné cet identifiant, le source_id est par construction faux → bloqué.
Architecture détaillée : les 4 ADRs (002 → 005) publiées sur GitHub décrivent le design, les trade-offs, les modes de défaillance et les références au code.
Lire les ADRsChaque action du portail est cryptographiquement chaînée.
Chaque entrée du journal d'audit LMbox est hashée en SHA-256 avec le hash de l'entrée précédente. Le RSSI peut prouver à un auditeur SOC 2 ou à la CNIL qu'aucune ligne n'a été supprimée, modifiée, ou insérée - y compris par un administrateur LMbox.
chain_hash[N] = SHA-256(
chain_hash[N-1]
|| canonical(payload[N])
)
genesis = SHA-256(
"lmbox.ai/audit-chain/v1"
|| "customer=" + customer.id
|| "created=" + customer.created_at
)
-
Détection d'insertion / suppression
Modifier ou supprimer une ligne brise le chaînage : toutes les entrées suivantes deviennent invalides au prochain verify_chain.
-
Genesis par client
Chaque tenant a sa propre chaîne - deux clients ne partagent jamais le même préfixe. Aucune fuite cross-tenant possible.
-
Vérifiable en 1 clic
Le RSSI clique « Vérifier la chaîne » dans le portail. LMbox re-walk les N entrées en quelques secondes et affiche un bandeau vert ou rouge - opposable.
Voir la chaîne d'audit en live : ouvrez la démo publique, cliquez « Journal » dans le portail, puis « Vérifier la chaîne ». 200 entrées chaînées en 3 secondes.
Ouvrir la démoConnecter SharePoint, Salesforce, Jira à LMbox - est-ce une faille de souveraineté ?
Non - mais c'est un sujet où il faut être précis. LMbox ne déplace pas vos données. Il les lit là où vous les avez déjà mises. La souveraineté du stockage dépend de votre choix d'éditeur SaaS, antérieur à LMbox. La souveraineté du modèle IA, de l'indexation et de l'audit, c'est ce que LMbox apporte - et personne d'autre ne peut le dire pour vos données existantes.
Les 4 couches d'un système IA - qui contrôle quoi
| Couche | Question | Qui contrôle |
|---|---|---|
| 1. Stockage | Où sont les documents source ? | Votre choix antérieur (M365, Salesforce, on-prem, ...) |
| 2. Indexation / RAG | Qui lit et fait l'embedding ? | LMbox - local, on-prem, sur la box |
| 3. Inférence IA | Où le modèle tourne ? | LMbox - modèle local, jamais d'API externe |
| 4. Audit | Qui garde la trace ? | LMbox - chaîne SHA-256 vérifiable |
Trois cas de figure typiques
Connecteurs SaaS purs (Salesforce, HubSpot, Notion, Slack, Drive, Teams)
Vos données sont déjà dans le cloud du vendeur - choix antérieur à LMbox. On lit en local via OAuth, sans rien déplacer. Souveraineté côté IA, pas côté stockage.
Connecteurs hybrides en version cloud (SharePoint Online, Confluence Cloud, Jira Cloud)
Le vendeur propose une version self-hosted, vous avez choisi la cloud. LMbox lit en local. Si la souveraineté du stockage devient critique, migrez vers la variante self-hosted - LMbox la supporte sans changement.
Connecteurs hybrides en self-hosted (SharePoint Server, Confluence DC, GitLab self-managed)
Stack 100 % on-prem de bout en bout. Aucune donnée ne quitte votre DC. Argument SecNumCloud, défense, HDS strict - opposable à un auditeur sans réserve.
Les 7 contrôles techniques en place
-
Credentials chiffrés at-rest
Les tokens OAuth des connecteurs sont stockés via Rails 8 attribute encryption (AES-GCM, clé hors base). Un dump Postgres ne révèle jamais un token utilisable.
-
Scrubbing après push
Une fois le credential transmis à la box, le sous-champ `credentials` est wipe côté cloud. Le digest reste pour rotation future ; la valeur en clair disparaît.
-
Chaque accès trace dans l'audit chain
Lire un document SharePoint génère une entrée d'audit hashée SHA-256. Le RSSI peut re-walker la chaîne à tout instant et prouver qu'aucune lecture n'a été dissimulée.
-
Heartbeat outbound-only
La box ne reçoit aucune connexion entrante. Toute commande cloud → box passe par le heartbeat sortant que la box initie. Pas de surface d'attaque externe.
-
Scope minimum sur l'App Registration
Documentation explicite par cas d'usage : pour NDA Reviewer, `Sites.Selected` au lieu de `Sites.Read.All`. Le partenaire intégrateur affine le scope avec le client.
-
Rotation des tokens
Procédure documentée pour rotation périodique (90 jours typique) et révocation immédiate au départ d'un utilisateur. Géré côté Azure AD / Google Workspace / etc.
-
RAG en lecture seule
Aucun connecteur n'écrit dans la source. Pas de risque d'injection malveillante dans une bibliothèque partagée. Si un agent doit écrire (0.5+), validation humaine explicite requise.
Recommandation pour souveraineté maximale : si vous êtes en secteur régulé (défense, HDS strict, banque ACPR-sensible), privilégiez les variantes self-hosted des connecteurs hybrides : SharePoint Server, Confluence Data Center, GitLab self-managed, Outlook/Exchange on-prem. LMbox les supporte nativement et vous obtenez la stack 100 % on-prem. Voir le catalogue connecteurs
Une question sécurité ou conformité ?
Notre équipe peut répondre à un questionnaire DSI, fournir un dossier d'architecture détaillé, ou organiser une visio avec votre RSSI.
Échanger avec un expert