MCP + la recherche fédérée sont-ils en train de tuer l’index ?

Aujourd’hui, la recherche fédérée fait son retour, portée par de nouveaux connecteurs d’OpenAI, de Google Agentspace, et par des protocoles ouverts comme le Model Context Protocol (MCP).  ; De nombreuses entreprises se demandent désormais : les LLMs ont-ils trouvé un raccourci pour ancrer les agents dans le contexte de l’entreprise, changeant fondamentalement le besoin d’un index ?

Quand nous avons lancé Glean, la recherche grand public avait atteint un haut niveau de maturité — s’appuyant sur des décennies d’avancées en recherche d’information et en machine learning à grande échelle. La recherche en entreprise, à l’inverse, restait un problème non résolu. La connaissance de l’organisation était fragmentée à travers des centaines d’applications SaaS, chacune avec son propre modèle de données et ses schémas d’accès. Obtenir de la pertinence impliquait souvent un tuning lourd, tout en produisant malgré tout des résultats de faible qualité.

Dès le départ, nous avons estimé que les utilisateurs en entreprise méritent une recherche à la hauteur de la vitesse, de la précision et de l’intuitivité de la recherche grand public. Cependant, nous avons compris que ce standard ne pouvait pas être atteint avec la recherche fédérée. La recherche fédérée génère des résultats partiels et sujets à la latence, en raison des incompatibilités de modèles de données et de l’absence d’un classement unifié.

À l’inverse, une véritable recherche en entreprise exige une infrastructure fondamentale et du machine learning appliqué : connecteurs, crawlers, normalisation des données, index sensibles aux permissions, graphes de connaissances et un moteur de ranking ajusté au contexte de l’entreprise.  ;

Au fil des années, Glean a massivement investi dans la construction de cette stack — en menant des centaines d’expériences A/B, en adaptant notre architecture pour prendre en charge de nouvelles modalités de données et l’évolution des limites de débit des API, et en passant continuellement à l’échelle face à la complexité croissante des écosystèmes SaaS modernes.  ; ;  ;

Les LLMs ont transformé notre manière d’interagir avec l’information — mais plutôt que de rendre les index obsolètes, ils les ont rendus encore plus essentiels. Les index restent le moyen le plus rentable et le plus performant d’ancrer des systèmes intelligents dans la connaissance de l’entreprise.

Les limites de la recherche fédérée  ;

La recherche fédérée envoie les requêtes des utilisateurs vers plusieurs sources de données externes — comme Google Drive, Jira ou Salesforce — en temps réel. Chaque source exécute la requête de manière indépendante et renvoie ses propres résultats. Enfin, le système fédéré agrège ces résultats dans une liste unique pour l’utilisateur. Cela semble simple, mais c’est une solution sous-optimale dans les grands environnements d’entreprise.

1. Plusieurs appels d’API, tous à des vitesses différentes

La recherche fédérée exige d’appeler chaque application individuellement en parallèle — et d’attendre que toutes les réponses reviennent avant d’afficher les résultats. En entreprise, cela peut vouloir dire interroger des dizaines de sources. Comme chaque API répond à son propre rythme, vous n’êtes jamais plus rapide que le système le plus lent. Résultat : une expérience de recherche lente et inconstante.

2. Limitée aux données authentifiées par l’utilisateur

La plupart des systèmes fédérés ne renvoient que les résultats que l’utilisateur actuel est autorisé à voir via l’API. Cela signifie que vous êtes souvent limité au périmètre de données personnelles de cet utilisateur, en passant à côté du contexte organisationnel plus large qui fait la valeur de la recherche — comme la popularité des documents, les signaux de collaboration, et qui d’autre dans l’entreprise interagit avec ce contenu. Sans ces métadonnées, le contenu perd en pertinence. L’avantage de l’authentification utilisateur, c’est qu’elle facilite une recherche avec permissions  l’inconvénient, c’est qu’il manque un contexte clé.  ;

3. Des API de recherche incohérentes et de faible qualité

Chaque application tierce a sa propre API, souvent conçue pour une récupération basique — pas pour une recherche de niveau entreprise. Beaucoup sont lentes, incomplètes ou peu maintenues. Ces API ne sont pas optimisées pour la pertinence de recherche  elles sont souvent proposées par commodité, pas comme produit cœur. La plupart des entreprises SaaS ne prétendent pas être expertes en recherche, et certaines se limitent à une simple recherche par mots-clés.

4. Un ranking simple, basé sur des règles

En l’absence d’un index centralisé, les systèmes fédérés ne peuvent pas normaliser les données entre les sources. Cela rend impossible l’application d’un modèle de classement cohérent. À la place, on se retrouve avec une logique simpliste, basée sur des règles, incapable de raisonner à travers des formats de données hétérogènes. Vous pouvez choisir de prioriser certaines sources de données par rapport à d’autres, via de simples heuristiques fondées sur les schémas de requêtes.  ;

Dans l’exemple de recherche fédérée, je pourrais choisir de pondérer les résultats uniquement en fonction de leur source de données. Mais cela risque d’exclure des résultats très pertinents — simplement parce qu’ils proviennent d’une source moins prioritaire — ce qui signifie qu’ils pourraient ne pas entrer dans la fenêtre de contexte du LLM au moment de générer une réponse.

5. Le filtrage subit la loi du plus petit dénominateur commun

Si l’un des systèmes connectés ne prend pas en charge un filtre spécifique — par exemple, filtrer par date de dernière modification — alors ce filtre ne peut pas être appliqué à l’ensemble des résultats. Cela crée un effet de plus petit dénominateur commun, où les limites de l’API la plus faible définissent les capacités de votre expérience de recherche.

Même si la recherche fédérée suscite un intérêt renouvelé grâce à MCP qui simplifie la façon dont les systèmes se connectent, elle n’améliore pas pour autant la qualité des résultats de recherche — ce qui est critique lorsque ces résultats sont transmis aux LLMs. MCP est un protocole de communication — une sorte de « port USB‑C » pour les apps d’IA qui permet l’interopérabilité — mais il ne traite pas la pertinence. Chez Glean, nous voyons MCP comme un moyen puissant d’étendre notre système de contexte à des agents construits partout, en les ancrant de manière sécurisée dans les données de l’entreprise. C’est pourquoi nous avons investi dans des serveurs MCP hébergés et adopté l’interopérabilité des agents — afin de rendre notre moteur de recherche et de raisonnement disponible partout où les agents s’exécutent.

En quoi les index font la différence

L’analogie la plus simple pour un index, c’est l’index à la fin d’un livre : il met en correspondance des termes et des emplacements, rendant l’information facile à trouver. C’est la base de la recherche traditionnelle par mots-clés — et cela joue encore un rôle crucial. Mais avec l’avènement de modèles de langage comme BERT, la recherche en entreprise a évolué. Ces modèles ont apporté une compréhension plus profonde du langage en encodant le sens dans des vecteurs de haute dimension — nous faisant passer de la recherche par correspondance exacte à une compréhension sémantique.

Comme toute structure de données, les index nous permettent de comprendre et d’utiliser les données sous-jacentes pour une récupération rapide et efficace.

Les index pour la recherche en entreprise sont un sujet à part entière et s’accompagnent des systèmes complexes et des défis scientifiques suivants :

1. Crawlers personnalisés

Vous devez déterminer quoi crawler, comment respecter les limites de débit (rate limits) et comment extraire non seulement le contenu, mais aussi les autorisations et les métadonnées. Les crawlers doivent être priorisés intelligemment — les données d’autorisations comptent souvent plus que le contenu — et intégrer une logique de backoff et de retry pour gérer proprement le throttling et les défaillances d’API.  ;

2. Indexation et classement adaptés à l’entreprise

Les méthodes lexicales comme BM25 et TF-IDF supposent des données homogènes — ce qui manque aux applications d’entreprise, par nature diverses. Une recherche efficace exige de concevoir et d’affiner des algorithmes d’indexation adaptés aux complexités des contenus d’entreprise. Par exemple, les commentaires sont des contenus de moindre valeur dont la pertinence décroît plus vite dans le temps, et les messages sans titre dans Slack nécessitent une logique spécifique. Cela signifie que l’algorithme d’indexation doit comprendre la conception et la valeur de chaque application.

La recherche sémantique a été fondatrice pour la recherche en entreprise. Elle a permis aux systèmes de recherche d’aller au-delà des mots-clés au sens littéral, en apprenant comment des noms internes se rattachent à des concepts. Chez Glean, nous appelons en interne notre « query engine » “Scholastic” plutôt que le magazine pour enfants  la recherche sémantique est capable d’établir cette association. En s’entraînant sur un corpus d’entreprise unique, les index sémantiques peuvent retrouver du contenu qu’une recherche fédérée manquerait.  ;

3. Compréhension au niveau des entités grâce aux knowledge graphs

Un index à lui seul ne capture pas les relations. Savoir simplement qu’un terme apparaît dans un document ne suffit pas : il faut comprendre à quoi ce terme fait référence. Est-ce un client ? Une technologie ? Un collègue ?

Les humains établissent naturellement ce type d’associations lorsqu’ils lisent du contenu, mais les LLMs ont besoin d’un contexte structuré pour faire de même. Sans cela, ils peuvent confondre des termes qui se ressemblent et tirer des conclusions erronées. C’est fréquent en entreprise avec les noms de produits ou leurs versions — comme Gemini 2.5 Pro vs. Gemini 2.0 Flash. Un LLM peut par inadvertance confondre les deux, ce qui conduit à des réponses inexactes.

4. Expérimentation continue

La recherche n’est pas statique. Vous devez mener des expérimentations en production pour améliorer les résultats de recherche et des agents. De plus, il y a toujours de nouvelles entités et de nouveaux points de données à intégrer à l’expérience de recherche.

Chez Glean, nous avons mené des centaines d’expériences afin de définir des solutions aux problématiques suivantes : l’autorité, les déploiements « cold-start », et l’évolution des schémas de recherche avec l’essor de la recherche sémantique et des agents :

• Déploiement cold-start : Nous amorçons de nouveaux environnements avec des données d’entraînement publiques et synthétiques de haute qualité afin de délivrer de la valeur dès le premier jour.
• Classement sensible à la thématique : Met en avant des contenus intemporels comme les politiques RH, même s’ils sont anciens ou consultés rarement.
• Boucles d’étalonnage : Nous affinons en continu nos modèles de classement auto-apprenants pour nous adapter à l’évolution des comportements, des cas d’usage et des schémas de requêtes.

Ces dernières années, nous avons vu les schémas de recherche en entreprise évoluer. Les requêtes courtes par mots-clés ont évolué vers des questions plus longues, plus ouvertes — portées par l’essor de l’IA. De nouveaux schémas de requêtes et d’agents émergent aussi : énumération, gestion de tickets, recherche d’experts, customer 360s, et bien plus — reflétant la diversité des façons dont les équipes utilisent l’IA au travail. À mesure que les manières de générer des données et d’interagir avec elles se multiplient, l’intelligence de recherche sous-jacente doit elle aussi évoluer.

Le rôle des index avec les LLMs

Même avec des LLMs puissants, s’appuyer sur des données d’entreprise indexées — plutôt que d’entraîner des modèles dessus — offre une approche plus sûre et plus flexible. L’indexation étend les connaissances d’un modèle sans intégrer directement des données sensibles dans le modèle, en maintenant la sécurité des informations et leur gouvernance grâce à une récupération tenant compte des autorisations. Contrairement aux modèles fine-tunés, qui deviennent statiques et difficiles à mettre à jour, les données indexées restent en temps réel et réactives aux changements — garantissant des résultats conformes et à jour. Les LLMs seuls ne suffisent pas pour une IA d’entreprise sécurisée.

On observe également une tendance croissante vers des fenêtres de contexte plus larges, donnant aux LLMs accès à davantage de données au moment de prendre des décisions. Une question revient souvent : si le modèle peut voir plus, la précision de la recherche a-t-elle encore de l’importance ? Chez Glean, nous avons constaté que oui. Les grandes fenêtres de contexte ne corrigent pas des entrées de mauvaise qualité — lorsque des informations contradictoires ou non pertinentes sont entassées, cela conduit souvent à de la confusion et à des réponses inexactes. Ce n’est pas seulement une question de volume de données fourni : il s’agit de sélectionner le bon contexte. Cela devient encore plus important à mesure que l’on évolue de la recherche d’informations vers des cas d’usage agentiques. La meilleure façon d’obtenir des résultats déterministes d’un agent est de fournir exactement la bonne information au LLM à chaque étape de l’agent.  ;

Nous avons aussi observé un intérêt pour l’association de connecteurs fédérés avec du deep reasoning. Même si le deep reasoning peut aider à masquer la latence de la recherche fédérée et permettre des appels LLM plus itératifs, c’est un contournement coûteux. Lorsque les données sont déjà indexées, les modèles peuvent répondre plus vite et raisonner plus en profondeur dans le même laps de temps. Sans cela, le LLM passe du temps à attendre des endpoints fédérés lents et compense l’imprécision par des cycles de raisonnement excessifs — ce qu’une recherche indexée évite.

Avec le passage des assistants aux agents, l’ancrage dans les données d’entreprise devient encore plus important, car les agents effectuent des actions autonomes. L’index n’est qu’une pièce du puzzle : ce qui apporte le contexte aux agents, c’est la création de graphes de connaissances au-dessus de l’index. C’est essentiel pour les utilisateurs en entreprise qui veulent une manière simple d’utiliser des agents — en les guidant via des instructions en langage naturel, tandis que le moteur de raisonnement agentique orchestre tout le contexte, les actions et les déclencheurs back-end.  ;

Vous ne pouvez pas parvenir à cette expérience fluide sans un index centralisé couvrant l’ensemble des données d’entreprise horizontales. Oublier cet index, c’est recréer pour l’IA les mêmes silos de données que ceux apparus avec le SaaS — ou vous enfermer dans un jeu de données restreint et bientôt obsolète pour chaque agent.