Comprendre les architectures d’hébergement Enterprise de Glean et Claude

L’architecture d’hébergement de l’IA en entreprise se décline en deux modèles : une plateforme qui construit une couche persistante de contexte à travers les données de votre entreprise, et une offre Enterprise d’un grand modèle de langage (LLM) autonome qui habille un produit de chat grand public avec des contrôles d’administration. Alors que neuf organisations sur dix utilisent désormais l’IA régulièrement selon l’enquête mondiale 2025 de McKinsey, la différence entre ces modèles détermine la manière dont chaque option gère la recherche, les permissions et l’automatisation à grande échelle.

Une architecture « platform-first » se connecte à vos outils existants, indexe les contenus en conservant leurs contrôles d’accès d’origine, et construit un graphe de connaissances continuellement mis à jour. Une offre Enterprise de LLM autonome ajoute l’authentification unique (SSO), le provisionnement des utilisateurs et des accords de protection des données par-dessus l’interface native du modèle.

Le choix détermine la quantité de connaissances de l’entreprise sur laquelle votre déploiement d’IA peut s’appuyer sans chargement manuel du contexte. Cet article couvre les différences architecturales spécifiques, en commençant par la manière dont chaque modèle gère les données d’entreprise.

Comment chaque architecture gère les données et le contexte en entreprise

L’écart architectural le plus important entre une plateforme d’IA de travail et une offre Enterprise de LLM autonome réside dans la façon dont chacune construit et maintient le contexte. Une approche plateforme construit ce que Glean appelle l’Enterprise Graph et le Personal Graph — une carte continuellement mise à jour des personnes, contenus, interactions et relations à travers chaque système connecté. Ce graphe alimente la recherche : lorsque vous posez une question, la plateforme comprend déjà quels documents se rattachent à quels projets, quelles personnes détiennent quelles décisions, et quels contenus vous êtes autorisé(e) à voir.

Les offres Enterprise de LLM autonomes empruntent une autre voie. Elles s’appuient sur le contexte que les utilisateurs fournissent directement dans la fenêtre de chat, complété par un ensemble plus restreint de connecteurs avec une résolution des permissions plus superficielle. Sans graphe de connaissances persistant, le modèle traite chaque conversation avec une compréhension limitée de la manière dont les informations de votre entreprise s’articulent. Dans l’évaluation 2025 de Glean, qui a comparé des réponses sur des types de requêtes d’entreprise via une notation humaine en aveugle, les réponses adossées à une plateforme ont été préférées environ 2x plus souvent que celles issues d’offres Enterprise à modèle unique. La qualité de la recherche a été le principal facteur différenciant.

Le mécanisme derrière cet écart de préférence est la recherche hybride combinée à la génération augmentée par la recherche (RAG). Plutôt que d’envoyer au modèle votre question complète et une large fenêtre de contexte, la plateforme préfiltre et classe d’abord les documents les plus pertinents, puis n’alimente l’étape de génération qu’avec des contenus cités et tenant compte des permissions.

Dans les benchmarks internes de Glean sur des déploiements en entreprise (2025), cette approche a réduit la consommation de tokens de 23% par rapport à des appels bruts au modèle. Elle ancre aussi chaque réponse dans des contenus d’entreprise à jour, plutôt que dans les données d’entraînement du modèle. Prenez la planification trimestrielle : un chef de produit demandant « Qu’ont dit les clients sur notre parcours d’onboarding le trimestre dernier ? » obtient une réponse qui s’appuie sur des tickets de support, des fils Slack et des transcriptions d’appels clients dans les systèmes connectés — avec des citations renvoyant aux sources d’origine.

Comment la sécurité et les permissions diffèrent selon les architectures d’hébergement

La différence la plus déterminante entre ces deux types d’architecture est l’endroit où l’application des permissions se fait dans le pipeline de données. Comprendre la sécurité de l’IA dans ce contexte, c’est reconnaître qu’une plateforme d’IA de travail applique des contrôles de permissions au niveau de la couche de recherche, avant que tout contenu n’atteigne le modèle de langage. Une offre Enterprise de LLM autonome gère les permissions au niveau de la couche applicative, après que le modèle a déjà traité le contexte fourni par l’utilisateur.

En pratique, une application au niveau de la recherche signifie que le modèle ne voit jamais les documents, messages ou fichiers auxquels l’utilisateur demandeur n’a pas accès. L’architecture de recherche tenant compte des permissions de Glean reflète les contrôles d’accès du système source dans chaque application connectée. Si un commercial ne peut pas consulter un document RH dans le système source, ce document n’apparaît ni dans les résultats de recherche, ni dans les réponses de l’assistant, ni dans les actions des agents.

Les offres Enterprise autonomes traitent la sécurité via des accords de protection des données contractuels, le provisionnement en authentification unique (SSO) et des engagements de rétention zéro jour avec le fournisseur de LLM. Ces protections comptent — et comme le souligne la recherche 2025 de Forrester sur la gestion de la posture de sécurité de l’IA, les entreprises font face à une exposition croissante due à la dérive des modèles, à l’injection de prompts et aux fuites de données — mais elles régissent ce qui arrive aux données après leur entrée dans la fenêtre de contexte du modèle, pas le fait qu’elles y entrent ou non.

Les deux types d’architecture partagent des fonctionnalités de conformité de base : certification SOC 2, chiffrement de bout en bout en transit et au repos, et journalisation d’audit pour la visibilité des administrateurs. Pour les organisations de secteurs réglementés comme la santé ou les services financiers, la distinction entre l’application des permissions au niveau de la recherche et au niveau applicatif affecte directement la posture de conformité. Selon le rapport 2026 State of AI de Deloitte, seule une entreprise sur cinq dispose d’un modèle de gouvernance mature pour des agents d’IA autonomes — un écart qui rend l’application structurelle des permissions encore plus critique. Un système hospitalier soumis à HIPAA, par exemple, a besoin de l’assurance que les dossiers patients dans les systèmes connectés ne seront jamais exposés à des membres du personnel en dehors de l’équipe de soins. Le filtrage au niveau de la recherche fournit cette garantie structurelle sans s’appuyer sur une gestion manuelle du contexte par les utilisateurs.

Comment l’étendue des intégrations façonne la valeur du déploiement

Le nombre et la profondeur des connexions entre une plateforme d’IA et vos outils existants déterminent la quantité de connaissances organisationnelles dont le système peut s’appuyer lorsqu’il répond à des questions ou exécute des tâches. Une plateforme d’IA pour le travail se connecte généralement à 100 applications d’entreprise ou plus dès le départ, couvrant des suites de productivité, des CRM, des outils de gestion de projet, des plateformes développeurs et des systèmes de gestion des services informatiques.

Les offres entreprise LLM autonomes proposent un ensemble de connecteurs plus restreint, souvent concentré dans l’écosystème d’un seul fournisseur. Un forfait basé sur le modèle d’un grand fournisseur cloud, par exemple, peut bien s’intégrer à la suite de productivité de ce fournisseur, mais nécessiter du développement sur mesure pour extraire des données d’outils tiers. L’écart compte particulièrement lorsque les employés travaillent au quotidien dans plusieurs écosystèmes — et savoir comment évaluer les fournisseurs d’IA sur la qualité des connecteurs devient essentiel lorsque l’on passe de Google Workspace pour les documents, Salesforce pour les dossiers clients, Jira pour les tickets d’ingénierie et Slack pour les conversations.

La profondeur d’intégration compte autant que l’étendue. Des connecteurs superficiels indexent les titres et les métadonnées, ce qui aide pour une recherche basique mais manque les relations entre les documents, les listes de contrôle d’accès et la structure du contenu qui rendent les réponses exactes. Les connecteurs de Glean indexent la structure des documents, les hiérarchies d’autorisations et les relations de contenu dans chaque système source, et injectent ce contexte dans l’Enterprise Graph.

Prenons le cas d’un responsable ingénierie qui enquête sur un incident en production. Des connecteurs profonds permettent à la plateforme d’extraire le ticket Jira pertinent, la pull request GitHub associée, le fil Slack où l’ingénieur d’astreinte a décrit la cause racine, et le runbook Confluence qui documente la correction — le tout filtré selon ce que ce responsable est autorisé à voir. Les API et les outils développeurs de Glean vont encore plus loin, en permettant aux équipes d’intégrer la recherche et des actions dans des workflows internes personnalisés, sans devoir reconstruire de zéro l’infrastructure de connecteurs et d’autorisations.

Comment chaque approche gère la flexibilité des modèles et l’efficacité des tokens

Se verrouiller sur une seule famille de modèles crée une dépendance dont le coût de sortie augmente avec le temps. À mesure que votre organisation construit des workflows, affine des prompts et forme les employés autour du comportement d’un modèle, passer à un autre modèle implique de retravailler tous ces investissements. Une plateforme d’IA pour le travail évite cela en abstrahant la couche modèle des couches données et gouvernance.

Le Model Hub de Glean donne aux équipes la possibilité de sélectionner le meilleur modèle pour chaque cas d’usage depuis un catalogue qui inclut des modèles de plusieurs fournisseurs. Une équipe juridique qui résume des contrats peut choisir un modèle optimisé pour l’analyse de documents à long contexte, tandis qu’une équipe support qui trie des tickets utilise un modèle plus rapide, calibré pour la classification. Lorsqu’un nouveau modèle offrant de meilleures capacités de raisonnement devient disponible, les équipes peuvent l’adopter sans migrer les connecteurs de données, reconstruire les mappings d’autorisations ou réentraîner des agents. La couche données, les politiques de gouvernance et l’Enterprise Graph restent en place.

Les offres entreprise à modèle unique lient chaque cas d’usage aux forces et aux limites d’une seule famille de modèles. Si ce modèle est insuffisant pour une tâche spécifique, comme l’extraction de données structurées à partir de rapports financiers, la solution de contournement est le prompt engineering plutôt que la sélection d’un modèle. Selon une enquête Gartner 2024 sur les stratégies de déploiement de l’IA, 56% des responsables de l’IA en entreprise ont cité la flexibilité des modèles parmi les trois principales exigences de leur infrastructure IA.

L’abstraction des modèles réduit également le gaspillage de tokens. Lorsque le système de retrieval de la plateforme pré-filtre et classe les contenus pertinents avant de les envoyer au modèle, le prompt ne contient que ce dont le modèle a besoin, et non tout ce à quoi l’utilisateur pourrait accéder. Cette précision dans la sélection du contexte signifie moins de tokens consommés par requête et des coûts d’inférence plus faibles à grande échelle.

Comment les capacités agentiques diffèrent entre les architectures plateforme et autonomes

L’IA agentique décrit des systèmes capables de planifier une séquence d’étapes, de s’adapter lorsque des résultats intermédiaires modifient le plan, et d’agir dans plusieurs outils pour mener une tâche à bien. L’architecture de raisonnement agentique sous-jacente à l’agent détermine ce qu’il peut voir, où il peut agir et qui contrôle ses limites.

Une plateforme d’IA pour le travail dotée d’un moteur agentique peut orchestrer des workflows multi-étapes dans l’ensemble des systèmes d’entreprise connectés. L’Agentic Engine de Glean planifie et exécute des tâches couvrant plusieurs outils, grâce à des agents IA qui peuvent être créés et déployés sans code. Un agent achats, par exemple, peut recevoir une demande d’achat dans Slack, consulter les conditions contractuelles du fournisseur dans le système de gestion documentaire, vérifier la disponibilité budgétaire dans la plateforme finance, rédiger une demande d’approbation et l’acheminer vers le bon manager en fonction de la hiérarchie d’approbation de l’organisation.

Chaque étape respecte les mêmes limites d’autorisations que la recherche et les réponses de l’assistant, de sorte que l’agent n’accède jamais à des données et n’exécute jamais d’actions en dehors des autorisations de l’utilisateur demandeur.

Les offres entreprise LLM autonomes peuvent proposer des fonctionnalités proches d’agents, mais ces fonctionnalités opèrent dans l’interface propre du modèle plutôt qu’à travers vos systèmes connectés. Un agent construit sur une offre autonome peut raisonner sur un prompt complexe et générer un plan multi-étapes, mais l’exécution de chaque étape exige généralement que l’utilisateur copie manuellement les sorties dans d’autres outils. Selon l’étude Menlo Ventures 2025 sur l’IA en entreprise, seuls 16% des déploiements en entreprise qualifient de véritables agents — des systèmes où un LLM planifie, exécute et s’adapte — tandis que la plupart restent construits autour de workflows à séquence fixe.

L’écart de gouvernance est tout aussi important. La gouvernance des agents — c’est-à-dire qui peut créer des agents, à quelles données ces agents accèdent et quelles actions ils peuvent effectuer — requiert la même infrastructure consciente des autorisations qui ancre la recherche et les fonctionnalités d’assistant. Sans enforcement des autorisations au niveau du retrieval, les créateurs d’agents doivent configurer manuellement les limites d’accès pour chaque workflow, ce qui génère une charge de maintenance et un risque de conformité à mesure que l’organisation étend son usage des agents IA. Explorer les applications concrètes des agents IA en entreprise illustre pourquoi cette couche de gouvernance est essentielle dans tous les départements.

Comment évaluer l’architecture d’hébergement adaptée à votre organisation

Commencez votre évaluation à partir de trois éléments : votre périmètre d’intégration, la complexité de vos autorisations et vos objectifs de maturité en IA. Chaque élément renvoie à un ensemble différent d’exigences d’architecture, et trouver la bonne plateforme IA dépend de l’alignement de ces facteurs avec les besoins de votre organisation.

Périmètre d’intégration. Comptabilisez les outils SaaS que vos équipes utilisent au quotidien. Les organisations qui exploitent 15 outils ou plus répartis entre la productivité, le CRM, l’ingénierie, le support et les systèmes RH tirent le plus de valeur d’une plateforme qui s’y connecte nativement. Si votre stack est concentrée dans l’écosystème d’un seul fournisseur, une offre autonome au sein de cet écosystème peut couvrir vos besoins immédiats.

Complexité des autorisations. Cartographiez la façon dont les contrôles d’accès varient selon les équipes, les rôles et les zones géographiques. Les organisations avec des autorisations à plusieurs niveaux — par exemple une entreprise internationale où les équipes régionales voient des données client différentes — ont besoin d’une application des autorisations au niveau de la récupération (retrieval) pour maintenir la conformité, sans configuration manuelle pour chaque workflow IA.

Objectifs de maturité en IA. Situez votre point de départ et votre objectif. La plupart des organisations suivent une progression : search (trouver des informations) mène à ask (obtenir des réponses ancrées dans la connaissance de l’entreprise), qui mène à act (des agents qui exécutent des tâches à travers les systèmes). Une architecture de plateforme prend en charge l’ensemble de cette progression. Une offre autonome sert très bien l’étape ask, mais nécessite des outils supplémentaires pour search et act.

Les deux architectures ne s’excluent pas mutuellement. Le MCP Gateway de Glean permet aux LLM autonomes d’interroger directement la couche de connaissance de la plateforme. Ainsi, les organisations qui utilisent déjà une offre autonome peuvent ajouter une couche structurée de connaissance et d’autorisations sans remplacer leur investissement existant dans les modèles. La question d’évaluation passe de « lequel choisir » à « quelle combinaison correspond à votre stack actuelle et à l’objectif où vous voulez être dans 12 mois ».

Questions fréquentes

Une plateforme Work AI peut-elle être déployée on-premises ou uniquement dans le cloud ?

La plupart des plateformes Work AI proposent des déploiements hébergés dans le cloud, mais certaines prennent aussi en charge des configurations on-premises ou hybrides pour les organisations avec des exigences strictes de résidence des données. Glean, par exemple, s’exécute dans le propre tenant cloud du client et se connecte aux outils existants via plus de 100 connecteurs préconfigurés, en conservant les données au sein de votre périmètre de sécurité. Le bon modèle de déploiement dépend de vos besoins de conformité, de votre infrastructure IT et du niveau de contrôle dont vous avez besoin sur les flux de données.

Quelles sont les implications de sécurité de choisir une architecture de plateforme plutôt qu’un LLM autonome ?

Une architecture de plateforme superpose la sécurité à chaque interaction plutôt que de s’appuyer sur le seul modèle. Glean applique un accès tenant compte des autorisations au moment de la requête, afin que les employés ne voient que des réponses issues de contenus auxquels ils ont déjà accès. Un LLM autonome, à l’inverse, vous oblige généralement à construire et à maintenir séparément ces contrôles d’accès.

Comment une offre entreprise LLM autonome gère-t-elle l’hébergement ?

Les offres entreprise LLM autonomes hébergent généralement le modèle sur l’infrastructure du fournisseur, dans un environnement dédié ou isolé. Le fournisseur gère la disponibilité, la montée en charge et les mises à jour du modèle, tandis que votre équipe gère les pipelines de données, les politiques d’accès et les intégrations avec les outils internes. Vous conservez moins de contrôle sur l’architecture par rapport à une plateforme qui s’intègre directement à votre stack existante.

Une approche plateforme prend-elle en charge la scalabilité pour les grandes entreprises ?

Oui. Une plateforme comme Glean est conçue pour passer à l’échelle entre départements, outils et zones géographiques, sans nécessiter de déploiements séparés pour chaque équipe. L’Enterprise Graph indexe la connaissance issue de chaque source connectée : ajouter de nouvelles équipes ou de nouvelles sources de données étend la couverture plutôt que de créer des systèmes parallèles. Les grandes organisations bénéficient d’une couche de connaissance unique et unifiée qui grandit avec l’entreprise.

Les deux architectures peuvent-elles fonctionner ensemble ?

Oui. De nombreuses entreprises associent un LLM autonome pour des tâches spécialisées — comme la génération de code ou la rédaction de documents — à une plateforme comme Glean, qui fournit une recherche et une récupération étendues, tenant compte des autorisations, dans l’ensemble de l’organisation. Cette combinaison vous permet d’utiliser le meilleur modèle pour chaque tâche, tout en gardant la connaissance de l’entreprise accessible, gouvernée et ancrée dans les données réelles de votre société.

Choisir la bonne architecture d’hébergement n’est pas une décision binaire. Vous pouvez combiner une plateforme d’IA de travail avec des LLM autonomes afin d’associer chaque cas d’usage à l’outil adapté, en trouvant le bon équilibre entre sécurité, scalabilité et profondeur d’intégration. Demandez une démo pour découvrir comment Glean et l’IA peuvent transformer votre environnement de travail.