LibreChat : fiche

L'essentiel

Licence MIT, sans clause de branding : utilisable telle quelle dans une Box commercialisée ¹.
Modèle d'accès plus fin qu'Open WebUI : « every shareable entity in the app (agents, prompts, MCP servers, remote agents, files, conversations) has its own Access Control List (ACL) » avec Viewer / Editor / Owner, rôles ADMIN / USER et rôles custom, distinction SHARE (vers des utilisateurs ou groupes) et SHARE_PUBLIC ².
Groupes Entra ID synchronisés depuis Microsoft Graph à la connexion (Azure OIDC avec réutilisation du jeton), chaque groupe gardant son Object ID Entra en idOnTheSource : le mapping identité → droits est natif.
RAG en service séparé (FastAPI + LangChain sur PostgreSQL/pgvector), remplaçable par le RAG de la Box ; défauts 1 500 caractères / 100 de chevauchement ³.
Limites : pas de connecteur SharePoint/Drive natif trouvé ; isolation des vecteurs par utilisateur non décrite dans la doc (à vérifier dans le code) ; communauté plus petite ; version en release candidate (v0.8.8-rc3).

Licence et maturité

MIT ; environ 44 000 étoiles GitHub ; v0.8.8-rc3 au 16/09/2026 ; déploiement Docker Compose ¹ Communauté. Le rythme de release et la taille de la communauté sont inférieurs à Open WebUI, ce qui signifie aussi moins d'advisories publiées : ce n'est pas une preuve de sécurité, seulement une exposition moindre.

Contrôle d'accès

Trois couches documentées ² :

Rôles : ADMIN et USER, plus des rôles custom ; des « system grants » portent les capacités d'administration.
ACL par ressource : chaque agent, prompt, serveur MCP, fichier, conversation a sa liste d'accès avec les niveaux Viewer, Editor, Owner. C'est plus fin que les grants read/write d'Open WebUI et surtout applicable aux fichiers.
Partage gouverné : « you can allow a role to share agents with specific users or groups (SHARE) without letting them make agents visible to everyone (SHARE_PUBLIC) ». Une demande communautaire (#11267) vise à restreindre le partage aux groupes dont l'utilisateur est membre.

Groupes Entra ID : « synced from Microsoft Graph when a user logs in via Azure OIDC with token reuse enabled. Each synced group stores its Entra Object ID as idOnTheSource ». Pour un cabinet sous Microsoft 365, cela permet de créer les groupes « dossier-A », « associes » dans Entra et de les voir apparaître dans LibreChat sans double saisie.

RAG API

Service séparé : PostgreSQL + pgvector, LangChain, FastAPI ; CHUNK_SIZE 1 500 et CHUNK_OVERLAP 100 par défaut ; EMBEDDINGS_PROVIDER openai / azure / huggingface / huggingfacetei / ollama (donc un modèle local via Ollama ou TEI) ; RAG_USE_FULL_CONTEXT ; images Docker « lite » (embeddings distants) et complète ³. La séparation en service est un avantage : on peut remplacer la RAG API par le service RAG de la Box en conservant l'interface, ou brancher le RAG via des agents (« File Context »).

Point à vérifier dans le code : comment la RAG API isole les vecteurs d'un utilisateur ou d'un fichier (par identifiant de fichier dans les métadonnées, a priori), et si une requête peut cibler un fichier hors ACL.

SSO

OAuth2/OIDC, LDAP, Entra ID (avec découverte de groupes Graph) ¹ ². Compatible avec Authentik, Keycloak et Entra ID (identité).

Limites

Pas de connecteur SharePoint/Drive natif trouvé dans le README ; l'ingestion passe par upload ou par un service externe.
Isolation des vecteurs non documentée.
Pas de RAG hybride ni de reranker documentés dans la RAG API (à vérifier).
Version en release candidate au moment de la lecture.
Interface orientée « agents » et fournisseurs multiples, plus riche que nécessaire pour un cabinet.

Quand préférer LibreChat

Une Box en marque blanche (MIT, pas de clause de branding).
Un cabinet sous Microsoft 365 qui veut ses groupes Entra reflétés sans double saisie.
Un besoin d'ACL au niveau des fichiers et des conversations dans l'interface elle-même.
Après le POC, si Q-005 conclut qu'Open WebUI ne suffit pas.

Questions ouvertes

Q-005Open WebUI est-il suffisant comme interface, ou faut-il LibreChat ou une interface propriétaire ?MoyenneEn cours