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, FileVault sur disque, 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 │ Ragnight │
│ (chat UI) │ (API gw) │ (RAG, KB) │
└──────┬───────┴──────┬──────┴──────┬───────┘
│ │ │
└──────────────┴─────────────┘
│
┌────────┴────────┐
│ Ollama │ Modèles locaux
│ (Gemma 4 ...) │ GPU/Apple Silicon
└─────────────────┘
Postgres (chiffré at-rest, FileVault)
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é
Chaque 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.eu/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