Glean MCP Gateway : le contexte dont l'IA a besoin pour se mettre au travail

Cette dernière année, nous avons vu le Model Context Protocol (MCP) gagner en adoption en tant que protocole ouvert pour connecter les outils à l’IA, permettant aux utilisateurs de lire des données et de passer à l’action. Si MCP a ouvert la porte à la connectivité, le faire réellement fonctionner en entreprise reste un défi pour la plupart des équipes. MCP, à lui seul, ne peut pas fournir un contexte efficace, faire évoluer les outils en toute sécurité et observer la manière dont ces outils sont utilisés. 

Aujourd’hui, Glean aide les entreprises à combler l’écart de mise en œuvre en lançant le MCP Gateway, qui offre :

• Du contexte pour l’IA au travail : La qualité des outils n’est pas uniforme. Glean fournit des index et des graphes de connaissances afin que les entreprises disposent d’un contexte cohérent et fiable, utilisable partout.
• Un accès sécurisé aux données et aux outils : Connectez-vous de manière sécurisée à des données et à des outils dont les autorisations sont appliquées, avec des contrôles d’accès granulaires et des protections contre l’injection de prompts et le code malveillant, pour aider à protéger votre entreprise sur toutes les surfaces.
• Déploiement, administration et visibilité centralisés : Administré de façon centralisée avec des serveurs MCP distants, la capacité de déployer à l’ensemble des employés via MDM, et des tableaux de bord pour rester informé de l’usage.

De meilleurs outils commencent par un meilleur contexte

MCP est un protocole, pas une couche de contexte. Quand vous interrogez via MCP, vous dépendez de la qualité des outils fournis par la communauté. La plupart des outils MCP prêts à l’emploi interrogent séparément les API de Jira, Confluence, GitHub et Slack, chacun avec des approches de recherche différentes, une indexation incohérente et aucun classement centralisé.

Une approche MCP fédérée peut acheminer un modèle vers la bonne API, mais l’agrégation des résultats entre les sources se fait toujours par le modèle à l’exécution, ce qui exige du modèle lui-même qu’il désambiguïse, réconcilie et cartographie les relations entre les systèmes. Cela consomme davantage de tokens, car les fondations de contexte adéquates ne sont pas en place.

Le serveur MCP de Glean utilise à la place un index pré-calculé et un graphe de connaissances pour effectuer ce travail en amont. Considérez cela comme une jointure pré-calculée sur l’ensemble des données de votre entreprise, plutôt que de résoudre cette jointure à l’exécution.

Cette approche fait une différence considérable en termes d’efficacité des tokens et de qualité des réponses. Plus tôt ce mois-ci, nous avons comparé Glean à des outils MCP prêts à l’emploi dans Claude Cowork sur ~175 requêtes d’entreprise, en conservant le harnais et le modèle constants et en ne remplaçant que la couche de contexte. Le contexte d’entreprise de Glean a été préféré ~2,5x plus souvent, et les outils prêts à l’emploi ont utilisé en moyenne 30 % de tokens en plus.

Nous avons également examiné comment cette même différence d’architecture se manifeste pour des charges de travail d’ingénierie au sein d’un AI-IDE. Voici un exemple, légèrement modifié pour supprimer des données sensibles : 

Le client indique que l’UI de la bibliothèque d’agents affiche toujours l’ancienne mise en page à 2 onglets. Qui en est propriétaire et que dois-je vérifier en premier ?

Glean

Responsable : l’équipe agent-builder est propriétaire du chemin de code, et le feature flag library-revamp a un seul propriétaire de fonctionnalité nommé que vous pouvez contacter directement.

Ce qui se passe réellement : l’ancienne mise en page à deux onglets (Tous / Actifs) ne s’affiche que lorsque le flag revamp est désactivé. Donc si un client voit encore deux onglets, le flag revamp s’évalue à false pour ce tenant.

Ce qu’il faut vérifier en premier, dans l’ordre :

• État du flag pour le tenant. Le flag revamp est passé en GA plus tôt cette année, donc la plupart des tenants devraient être activés par défaut. Confirmez que le client est sur une version suffisamment récente et vérifiez si une substitution spécifique au tenant force le flag à false pour leur cohorte.
• Bascule gérée côté client. Les admins côté client peuvent l’activer/désactiver eux-mêmes. Cela vaut la peine de demander si eux (ou un ancien admin) l’ont désactivée.
• Garde-fous de déclenchement. Même avec le revamp activé, les onglets ne s’affichent que sous certains droits de déclenchement et pas sur une fenêtre étroite, donc éliminez ces hypothèses.
• Cache. Un flag correctement servi avec un bundle navigateur obsolète est une fausse alerte fréquente. Demandez-leur de faire un rechargement forcé.

Qui contacter : d’abord le propriétaire de la fonctionnalité pour « ce tenant est-il censé être sur le revamp ? », puis l’équipe agent-builder pour les questions côté code.

Stack prêt à l’emploi

Je n’ai pas de contexte préalable sur le propriétaire de l’UI de la bibliothèque d’agents dans ce repo, je préfère ne pas deviner.

Quelques vérifications concrètes en premier :

• Trouver le composant : grep sur la mise en page des onglets pour localiser le fichier, puis vérifier l’historique pour le propriétaire le plus récent et toute refonte en cours.
• Vérifier s’il y a un flag : c’est généralement derrière un flag, donc le client peut être sur la variante désactivée. À confirmer avant de poursuivre une piste de bug côté code.
• Client et déploiement : quel client, quel déploiement ? Un déploiement obsolète peut aussi expliquer une UI ancienne.

Voulez-vous que j’explore, que je trouve le composant et le propriétaire actuel, ou que je vérifie d’abord s’il s’agit d’un problème de déploiement de feature flag ?

Glean MCP a répondu à la question. Il a nommé le responsable, identifié le flag exact derrière l’ancienne mise en page, expliqué pourquoi le client la voyait et fourni une liste de vérifications priorisée, incluant la substitution du tenant et la bascule côté client. La stack prête à l’emploi a reconnu la nature du problème mais s’est arrêtée avant d’aller au bout : elle a refusé de nommer un responsable, listé des étapes génériques et demandé l’autorisation de commencer l’investigation. Pour un ingénieur support en plein triage, une réponse clôt le ticket et l’autre relance le chronomètre.

Voilà la différence d’architecture : des index pré-calculés et des graphes de connaissances fournissent un contexte précis, inter-applications, que les outils MCP prêts à l’emploi ne peuvent pas reproduire à l’exécution.

Ici, « contexte » signifie aussi bien plus que la recherche. Le MCP Gateway expose toute la surface d’outils de Glean. Cela inclut la recherche, les outils de lecture et d’écriture, les outils personnalisés, ainsi que tous les serveurs MCP tiers que vous apportez, tous disponibles via le Gateway. Cela permet à Glean de se connecter à plus de 2 000 outils, de sorte que tout votre contexte se trouve au même endroit.

Gouverné par défaut, sécurisé par conception

L’adoption de MCP au sein de l’entreprise s’accélère, avec des serveurs qui s’exécutent sur de nombreux hôtes. Placer cette activité sous une gouvernance centralisée permet aux équipes sécurité et IT d’appliquer les mêmes protections qu’elles utilisent déjà partout ailleurs. 

Glean MCP Gateway standardise l’usage de MCP au sein de l’organisation en fournissant un répertoire centralisé des serveurs distants que vos équipes peuvent utiliser, avec les mêmes protections que Glean applique déjà à tous les autres outils. Ainsi, l’ensemble de votre contexte est disponible et sécurisé au même endroit.

Chaque appel MCP via le Gateway passe par les quatre contrôles suivants :

• Connecteurs avec application des autorisations. Les autorisations du système source sont héritées. Si un utilisateur ne peut pas voir un ticket Jira, il ne peut pas le lire via le Gateway. S’il ne peut pas écrire dans un enregistrement en aval, il ne peut pas non plus y écrire via le Gateway.
• Autorisation qui utilise votre IdP. OAuth passe par le serveur d’autorisation de Glean, avec une authentification utilisateur déléguée à votre fournisseur d’identité existant. L’hôte ne détient qu’un jeton MCP émis par Glean. Les jetons OAuth en aval restent côté serveur, de sorte qu’une session d’hôte compromise n’expose aucun identifiant en aval. OAuth par source de données s’effectue lors de la première utilisation via un lien de connexion que le Gateway remet à l’hôte.
• Contrôles d’accès granulaires. Les administrateurs décident quelles équipes ont accès à quels outils et lesquels nécessitent un humain dans la boucle, afin qu’une équipe puisse accéder aux outils d’écriture tandis qu’une autre ne le peut pas.
• Modèles de sécurité IA appliqués aux appels d’outils. Les outils appelés via le Gateway sont vérifiés contre l’injection de prompt, le code malveillant et les contenus toxiques, afin de garantir un fonctionnement sûr sur différentes surfaces.

Déploiement centralisé de MCP via MDM

Installer Glean MCP sur l’appareil d’un seul employé a toujours été simple. Le déployer sur une flotte gérée de milliers d’appareils, c’est là que les projets se bloquent. Glean MCP Gateway rationalise cela en traitant MCP comme n’importe quelle autre application d’entreprise, le rendant déployable via votre solution de Mobile Device Management (MDM) existante. Cela signifie :

• Glean MCP est automatiquement poussé vers chaque appareil géré, sans configuration par utilisateur. 
• Les employés sont intégrés sans configuration manuelle. 
• Les politiques de sécurité et d’appareils sont appliquées de façon centralisée, comme l’IT le fait pour toutes les autres applications gérées. 
• Les mises à jour automatiques sont activées par défaut, de sorte que les nouveaux hôtes pris en charge et les changements de configuration sont déployés sans que quiconque ait à réinstaller.

Ce qui est déployé sur chaque appareil, c’est uniquement la configuration. Le serveur MCP s’exécute côté Glean, et l’authentification a lieu par utilisateur lors du premier appel via votre fournisseur d’identité.

Une adoption visible

Alors que nous avons toujours eu des journaux d’audit, nous les intégrons désormais dans un tableau de bord d’insights centralisé afin que vous puissiez analyser l’usage de MCP selon :

• Utilisateurs actifs, appels aux serveurs MCP, outils utilisés et nombre moyen d’appels par utilisateur, chacun avec des variations période sur période.
• Utilisateurs actifs dans le temps (quotidien, hebdomadaire et mensuel), avec l’adoption comparée à l’usage global de Glean.
• Principales applications hôtes par utilisateurs actifs, pour voir où le trafic MCP est concentré.
• Un tableau Usage Breakdown qui pivote par utilisateur, application, outil MCP ou serveur MCP, avec des filtres multi-sélection et des ventilations par département, faisant ressortir les principaux outils par usage et leur attribution au serveur MCP.

Chaque métrique est également accessible via l’API Glean Insights. Les administrateurs peuvent voir l’usage de MCP dans un tableau de bord d’insights centralisé, aux côtés du reste de leurs données d’adoption de Glean. Il s’agit d’une télémétrie d’adoption.

Disponible dès maintenant

Glean MCP Gateway vous permet d’accéder à un contexte d’entreprise complet, performant et économe en jetons, sur les principaux hôtes MCP. Il rend le déploiement de MCP dans votre entreprise simple et sécurisé, et vous permet de le gérer via MDM comme n’importe quelle application, avec une sécurité intégrée et une observabilité centralisée via les tableaux de bord Insights.

Pour en savoir plus, demandez une démo de Glean dès aujourd’hui.

Auteurs : Aditya Kumar, David Hamilton, Harshi Murthy, Mohit Gupta, Roshan Dheram, Daniel Martinho