Au cours de l'année écoulée, nous avons vu le Model Context Protocol (MCP) s'imposer comme le protocole ouvert pour connecter les outils à l'IA, permettant aux utilisateurs de lire des données et d'agir. Si le MCP a ouvert la voie à la connectivité, le faire fonctionner concrètement en entreprise reste un défi pour la plupart des équipes. À lui seul, le MCP 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 cet écart de mise en œuvre en lançant le MCP Gateway, qui offre :
- Le contexte pour l'IA au travail : la qualité des outils n'est pas toujours la même. Glean fournit des index et des graphes de connaissances pour que les entreprises bénéficient d'un contexte cohérent et fiable, exploitable partout.
- Un accès sécurisé aux données et aux outils : connectez-vous en toute sécurité à des données et des outils respectant les permissions, avec des contrôles d'accès granulaires et des protections contre les injections de prompts et le code malveillant qui aident à protéger votre entreprise sur toutes les surfaces.
- Un déploiement, une administration et une visibilité centralisés : administré de façon centralisée avec des serveurs MCP distants, possibilité de déploiement auprès de tous les employés via MDM, et tableaux de bord pour rester informé de l'utilisation.
De meilleurs outils commencent par un meilleur contexte
Le MCP est un protocole, pas une couche de contexte. Lorsque vous effectuez une requête via le MCP, vous dépendez de la qualité des outils que la communauté met à disposition. La plupart des outils MCP standards interrogent séparément les API de Jira, Confluence, GitHub et Slack, chacune avec des approches de recherche différentes, une indexation incohérente et sans classement centralisé.
Une approche MCP fédérée peut diriger un modèle vers la bonne API, mais la fusion des résultats entre les sources reste réalisée par le modèle au moment de l'exécution, ce qui oblige le modèle lui-même à lever les ambiguïtés, à réconcilier et à cartographier les relations entre les systèmes. Cela consomme davantage de tokens, faute de bases de contexte adaptées.
Le serveur MCP de Glean utilise au contraire un index précalculé et un graphe de connaissances pour effectuer ce travail en amont. Imaginez une jointure précalculée sur l'ensemble des données de votre entreprise, plutôt que de résoudre cette jointure au moment de 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 aux outils MCP standards dans Claude Cowork sur environ 175 requêtes d'entreprise, en maintenant le harnais et le modèle constants et en ne changeant que la couche de contexte. Le contexte d'entreprise de Glean a été préféré environ 2,5 fois plus souvent, et les outils standards ont utilisé 30 % de tokens en plus en moyenne.
Nous avons également examiné comment cette même différence architecturale se manifeste pour les charges de travail d'ingénierie au sein d'un AI-IDE. Voici un exemple, légèrement modifié pour supprimer les données sensibles :
Responsable : l'équipe agent-builder possède le chemin de code, et le feature flag library-revamp a un responsable de fonctionnalité nommé que vous pouvez contacter directement.
Ce qui se passe réellement : l'ancienne disposition à deux onglets (Tous / Actifs) ne s'affiche que lorsque le flag revamp est désactivé. Donc si un client voit encore deux onglets, c'est que le flag revamp est évalué comme faux pour ce tenant.
Ce qu'il faut vérifier en premier, dans l'ordre :
- L'état du flag pour le tenant. Le flag revamp est passé en disponibilité générale plus tôt cette année, la plupart des tenants devraient donc être activés par défaut. Vérifiez que le client dispose d'une version suffisamment récente, et contrôlez si un override spécifique au tenant force le flag à faux pour sa cohorte.
- Le commutateur géré par le client. Les administrateurs côté client peuvent le désactiver eux-mêmes. Il vaut la peine de demander si eux (ou un administrateur précédent) l'ont désactivé.
- Les conditions de déclenchement. Même avec le revamp activé, les onglets ne s'affichent que sous certains droits de déclenchement et pas sur un viewport étroit, alors écartez ces possibilités.
- Le cache. Un flag correctement servi avec un bundle de navigateur obsolète est une fausse alerte courante. Demandez-leur de faire un rechargement forcé.
Qui contacter : d'abord le responsable de la fonctionnalité pour « ce tenant est-il censé avoir le revamp ? », puis l'équipe agent-builder pour les questions côté code.
Je n'ai pas de contexte préalable sur la responsabilité de l'interface de la bibliothèque d'agents dans ce dépôt, je préfère ne pas deviner.
Quelques premières vérifications concrètes :
- Trouver le composant : effectuez un grep sur la disposition des onglets pour localiser le fichier, puis consultez l'historique pour identifier le responsable le plus récent et toute refonte en cours.
- Vérifier la présence d'un flag : c'est généralement contrôlé par un flag, le client peut donc être sur la variante désactivée. Il vaut la peine de le confirmer avant de chercher un bug de code.
- Client et déploiement : quel client, quel déploiement ? Un déploiement obsolète peut aussi expliquer une ancienne interface.
Voulez-vous que j'approfondisse, que je trouve le composant et le responsable 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 à l'origine de l'ancienne disposition, expliqué pourquoi le client la voyait, et fourni une liste hiérarchisée de vérifications prioritaires incluant l'override du tenant et le commutateur côté client. La stack standard a reconnu la nature du problème mais s'est arrêtée en chemin : elle a refusé de nommer un responsable, a énuméré des étapes génériques et a demandé la permission de commencer à enquêter. Pour un ingénieur de l'assistance en plein tri, une réponse clôt le ticket et l'autre relance le chronomètre.
C'est là toute la différence architecturale : les index précalculés et les graphes de connaissances offrent un contexte précis et transversal aux applications que les outils MCP standards ne peuvent pas reproduire au moment de l'exécution.
Ici, le contexte désigne bien plus que la simple recherche. Le MCP Gateway expose l'ensemble des outils de Glean. Cela inclut les outils de recherche, de lecture et d'écriture, les outils personnalisés et tout serveur MCP tiers que vous intégrez, tous disponibles via le Gateway. Ainsi, Glean peut se connecter à plus de 2 000 outils, ce qui centralise tout votre contexte en un seul endroit.
Gouverné par défaut, sécurisé dès la conception
L'adoption du MCP au sein de l'entreprise progresse rapidement, avec des serveurs exécutés sur de nombreux hôtes. Placer cette activité sous une gouvernance centralisée permet aux équipes de sécurité et IT d'appliquer les mêmes protections que celles qu'elles utilisent déjà partout ailleurs.
Glean MCP Gateway standardise la façon dont le MCP est utilisé dans l'ensemble de l'organisation en fournissant un répertoire centralisé de serveurs distants que vos équipes peuvent utiliser, avec les mêmes protections que Glean applique déjà à tous les autres outils. Ainsi, tout votre contexte est rendu disponible et sécurisé en un seul endroit.
Chaque appel MCP passant par le Gateway est soumis aux quatre mêmes contrôles :
- Des connecteurs qui appliquent les autorisations. Les autorisations des systèmes sources sont héritées. Si un utilisateur ne peut pas voir un ticket Jira, il ne pourra pas le lire via le Gateway. Et s'il ne peut pas écrire dans un enregistrement en aval, il ne pourra pas non plus y écrire via le Gateway.
- Une autorisation qui s'appuie sur votre IdP. OAuth transite par le serveur d'autorisation de Glean, l'authentification des utilisateurs étant déléguée à votre fournisseur d'identité existant. L'hôte ne détient jamais qu'un jeton MCP émis par Glean. Les jetons OAuth en aval restent côté serveur, de sorte qu'une session hôte compromise n'expose aucun identifiant en aval. L'OAuth par source de données se finalise lors de la première utilisation, via un lien de connexion que le Gateway transmet à l'hôte.
- Des contrôles d'accès granulaires. Les administrateurs décident quelles équipes obtiennent quels outils et lesquels nécessitent une intervention humaine, de sorte qu'une équipe peut accéder aux outils d'écriture tandis qu'une autre ne le peut pas.
- Des modèles de sécurité IA appliqués aux appels d'outils. Les outils invoqué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é du MCP via MDM
Installer Glean MCP sur l'appareil d'un seul employé a toujours été simple. C'est quand il s'agit de le déployer sur une flotte gérée de plusieurs milliers d'appareils que les projets s'enlisent. Glean MCP Gateway simplifie cela en traitant le MCP comme n'importe quelle autre application d'entreprise, déployable via votre gestion des appareils mobiles (MDM) existante. Cela signifie :
- Glean MCP est automatiquement déployé sur 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 manière centralisée, exactement comme l'IT les applique pour toute autre application gérée.
- Les mises à jour automatiques sont activées par défaut, de sorte que les nouveaux hôtes pris en charge et les modifications de configuration sont intégrés sans que personne n'ait à réinstaller quoi que ce soit.
Ce qui arrive sur chaque appareil n'est que de la configuration. Le serveur MCP s'exécute du côté de Glean, et l'authentification se fait par utilisateur lors du premier appel, via votre fournisseur d'identité.
Une adoption que vous pouvez visualiser
Si nous avons toujours disposé de journaux d'audit, nous les intégrons désormais dans un tableau de bord d'insights centralisé afin que vous puissiez analyser l'utilisation du MCP selon :
- Les utilisateurs actifs, les appels aux serveurs MCP, les outils utilisés et le nombre moyen d'appels par utilisateur, chacun avec des écarts d'une période à l'autre.
- Les utilisateurs actifs au fil du temps (quotidiennement, hebdomadairement et mensuellement), avec l'adoption rapportée à l'utilisation globale de Glean.
- Les principales applications hôtes par utilisateurs actifs, pour voir où le trafic MCP se concentre.
- Un tableau de répartition de l'utilisation qui pivote par utilisateur, application, outil MCP ou serveur MCP, avec des filtres à sélection multiple et des ventilations par département, mettant en évidence les principaux outils par utilisation et leur attribution au serveur MCP.
Chaque métrique est également accessible via l'API Glean Insights. Les administrateurs peuvent visualiser l'utilisation du 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 de 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 tokens, sur les principaux hôtes MCP. Il rend le déploiement du MCP dans toute votre entreprise simple et sécurisé, et vous permet de le gérer via MDM comme n'importe quelle autre application, avec une sécurité intégrée et une observabilité centralisée grâce aux 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
