Glean Waldo vs. l’IA traditionnelle : comparaison des coûts, de la latence et de la qualité

Les modèles de recherche agentiques réduisent les coûts et la latence de l’IA en entreprise en séparant la planification de la recherche de la génération de réponse — en laissant un petit modèle spécialisé gérer l’étape de recherche avant qu’un modèle de raisonnement plus puissant produise la réponse finale. Résultat : des réponses plus rapides, une consommation de tokens plus faible et aucune perte de qualité des réponses.

Séparer la recherche du raisonnement est important, car la plupart des systèmes d’IA en entreprise aujourd’hui font passer chaque requête par un seul grand modèle de langage, que la tâche nécessite un raisonnement approfondi ou une simple récupération d’informations. Cette approche « taille unique » fait grimper les coûts par requête et ajoute des secondes de latence qui se cumulent sur des milliers d’interactions quotidiennes.

Glean — la plateforme Work AI — a développé Waldo, un modèle de recherche agentique post-entraîné sur NVIDIA Nemotron 3 Nano spécifiquement pour la recherche en entreprise, afin de démontrer ce schéma en production. Il planifie la recherche — en décidant quels outils appeler, quelles preuves collecter et comment décomposer une question — puis ne fait appel à un modèle frontier que pour la réponse finale. Dans les benchmarks publiés par Glean (2026, mesurés sur des déploiements en entreprise), l’architecture offre environ 50 % de latence de bout en bout en moins, approximativement 25 % de tokens consommés en moins et aucune baisse mesurable de la qualité des réponses.

Qu’est-ce qu’un modèle de recherche agentique et pourquoi est-ce important pour l’IA en entreprise ?

Un modèle de recherche agentique est un modèle conçu à dessein qui prend en charge l’étape de récupération dans un pipeline d’IA, en séparant le travail consistant à trouver les informations pertinentes du travail consistant à générer une réponse. Cette approche de RAG agentique est importante, car la plupart des architectures d’entreprise gaspillent du calcul et du temps en obligeant un seul grand modèle à faire les deux.

Le modèle de recherche décompose chaque requête en sous-tâches — en décidant quelles sources de données interroger, quels termes de recherche utiliser et quels résultats sont pertinents — avant de transmettre des preuves sélectionnées à un modèle de raisonnement plus puissant. La plupart des architectures d’IA en entreprise aujourd’hui omettent entièrement cette séparation.

Chaque requête, de « Quelle est notre politique de retour ? » à « Résume les changements de pipeline du trimestre dernier dans toute la région EMEA », passe de bout en bout par le même modèle frontier. Les recherches simples consomment la même puissance de calcul qu’une analyse complexe.

Les pénalités en coût et en latence sont prévisibles : une latence par appel d’environ trois secondes au 50e percentile (benchmarks publiés par Glean, 2026), et des budgets de tokens gonflés par du raisonnement de récupération pour lequel le grand modèle n’a jamais été optimisé.

L’alternative composable — utiliser le bon modèle à chaque étape — reflète la direction que prend l’architecture d’IA en entreprise. Waldo, par exemple, gère la planification de la récupération en environ 250 millisecondes par appel (contre approximativement trois secondes pour le modèle de raisonnement par défaut), puis n’achemine vers un modèle frontier que les preuves collectées pour la génération de la réponse.

L’analyste Forrester Rowan Curran a souligné en 2026 l’attrait croissant de « modèles plus orientés pour des tâches au sein de workflows agentiques globaux » (AI Business, mai 2026). Des modèles spécialisés travaillant aux côtés de modèles généralistes, chacun faisant ce qu’il fait le mieux, apportent des gains mesurables en coût et en vitesse sans compromettre la qualité.

Comment un modèle de recherche spécialisé réduit-il la latence par rapport aux approches traditionnelles ?

Un modèle de recherche conçu à dessein réduit le temps de réponse de bout en bout en gérant la décomposition des requêtes, le routage des outils et la collecte de preuves sans invoquer un calcul de raisonnement lourd. En production, l’étape de recherche s’exécute en environ 250 millisecondes au 50e percentile — contre approximativement trois secondes pour un modèle frontier (benchmarks internes de Glean, 2026).

La différence de vitesse compte surtout au niveau de la couche d’orchestration. Un pipeline traditionnel envoie la requête complète à un grand modèle, qui décide ensuite quoi chercher, analyse les résultats et génère une réponse — le tout en un seul passage. Comme le nombre de tokens impacte directement la latence, cette approche en un seul passage amplifie les délais à chaque étape. Un modèle de recherche spécialisé découpe cette séquence.

Le modèle de recherche décompose la question en sous-requêtes, sélectionne les bonnes sources de données, évalue les résultats intermédiaires et construit un paquet de preuves sélectionnées avant même d’appeler le modèle de raisonnement. Ce transfert élimine le goulot d’étranglement le plus lent : attendre qu’un grand modèle fasse un travail qu’un modèle plus petit et optimisé exécute plus vite.

L’effet cumulatif est là où la réduction de latence devient une métrique business. Prenons une entreprise de 10 000 employés, chacun effectuant cinq à 10 requêtes par jour via un assistant IA. Réduire ne serait-ce que d’une seconde chaque interaction, à ce volume, représente des milliers d’heures récupérées par trimestre.

Waldo atteint environ 50 % de latence de bout en bout en moins en terminant toute l’étape de planification de la récupération avant que le modèle frontier ne commence à générer.

Pour un ingénieur support qui qualifie des tickets ou un commercial qui se prépare à un appel, la différence entre trois secondes d’attente et une réponse en moins d’une seconde détermine si l’outil sera utilisé, ou non.

Pourquoi la consommation de tokens diminue-t-elle sans sacrifier la qualité des réponses ?

Lorsqu’un seul grand modèle gère à la fois la récupération et la génération, il lit bien plus de texte que nécessaire — il parcourt des documents, filtre les passages non pertinents, re-classe les candidats et raisonne sur les preuves à inclure. À l’échelle de l’entreprise, cette surcharge de tokens se traduit directement en coût de calcul. Séparer l’étape de recherche de l’étape de génération élimine l’essentiel de ce gaspillage.

Un modèle de recherche spécialisé prétraite la charge de travail de récupération : il décompose la question initiale, interroge les bonnes sources, évalue si les preuves collectées sont suffisantes et assemble uniquement les passages pertinents dans une fenêtre de contexte compacte. Le modèle de raisonnement reçoit un paquet de preuves étroitement ciblé plutôt qu’un ensemble tentaculaire de résultats de recherche bruts.

Le résultat mesuré est d’environ 25 % de tokens en moins par requête. La réponse conserve la même longueur  l’entrée du modèle de raisonnement est simplement plus propre.

La qualité des réponses se maintient parce que le modèle de recherche est post-entraîné spécifiquement pour les tâches de récupération en entreprise. Waldo, construit sur NVIDIA Nemotron 3 Nano, a appris à évaluer la pertinence et la suffisance des preuves lors du post-entraînement — des compétences qu’un modèle généraliste ne développe que de manière incidente.

Bradley Shimmin du Futurum Group a observé en 2026 que les entreprises disposant d’une expertise métier peuvent « transformer cette connaissance en cash en utilisant un modèle ciblé » (AI Business, mai 2026). En pratique, le modèle de recherche sait quand il a rassemblé suffisamment de preuves pour arrêter de chercher et quand il doit lancer une autre requête — un jugement que le plus souvent, un modèle générique tranche en sur-récupérant.

Qu’est-ce qui rend cette architecture différente de la génération augmentée par récupération standard ?

La génération augmentée par récupération (RAG) standard et la planification de recherche agentique associent toutes deux la récupération à un modèle de langage, mais elles diffèrent par le niveau d’intelligence intégré à l’étape de récupération. L’écart entre les deux détermine l’efficacité avec laquelle un système d’IA d’entreprise utilise le calcul, les tokens et le temps.

Le RAG standard exécute une recherche unique et statique, sans capacité à affiner les résultats

Un pipeline RAG classique suit une séquence fixe : vectoriser la requête, récupérer les documents top-k depuis un vector store, concaténer ces résultats, puis envoyer le texte combiné à un modèle de langage pour générer la réponse. L’étape de récupération est statique : elle s’exécute une seule fois, sans possibilité d’affiner la recherche, d’essayer des requêtes alternatives ou d’évaluer si les documents renvoyés répondent réellement à la question.

Cette rigidité crée un mode d’échec spécifique. Lorsque la récupération renvoie des résultats bruités ou incomplets, le modèle de langage compense en « raisonnant » davantage sur un prompt gonflé.

Un commercial qui demande « Quelles objections sur les prix avons-nous rencontrées en EMEA le trimestre dernier ? » déclenche une unique recherche vectorielle qui peut faire remonter des documents liés de manière indirecte. Le modèle dépense alors des tokens à parcourir un contexte non pertinent pour construire une réponse — ou pire, fabule à partir de fragments qui semblaient pertinents mais ne l’étaient pas.

Les pénalités de coût et de latence sont le symptôme d’une récupération faible, pas d’un raisonnement faible.

La planification de recherche agentique ajoute une couche de récupération dynamique que le RAG standard n’a pas

Un modèle de recherche agentique introduit une couche de planification entre la requête et l’étape de récupération. Au lieu d’une seule recherche vectorielle, le modèle de recherche décompose la question en sous-tâches — une approche que des entreprises comme Morgan Stanley et ServiceNow déploient déjà en production —, sélectionne des stratégies de récupération pour chacune, lit des résultats intermédiaires et décide de manière dynamique s’il faut relancer une recherche ou passer à la génération. Pour la question sur les prix en EMEA, un planificateur agentique pourrait d’abord identifier les enregistrements de deals pertinents, puis rechercher les notes d’objections dans ces enregistrements, puis vérifier que les résultats couvrent la bonne période — trois récupérations ciblées plutôt qu’un seul balayage large.

Le principe architectural est la spécialisation des modèles par découplage. Un planificateur compact et rapide prend en charge le travail de recherche itératif — offrant une meilleure localité de cache et un calcul par étape plus faible — tandis qu’un modèle de raisonnement « frontier » se concentre exclusivement sur la synthèse des preuves sélectionnées pour produire une réponse finale. L’implémentation de Glean associe Waldo comme planificateur de recherche au meilleur modèle de raisonnement disponible au moment de la génération.

Cette composabilité signifie que vous pouvez mettre à niveau le modèle de raisonnement indépendamment sans reconstruire l’infrastructure de récupération, et que chaque composant opère dans l’enveloppe de performance pour laquelle il a été conçu.

Comment cette approche affecte-t-elle le coût de l’IA en entreprise à grande échelle ?

Le coût de l’IA en entreprise est déterminé par deux variables : le nombre de tokens traités par requête et la taille du modèle qui les traite. Un modèle de recherche spécialisé réduit les deux — un schéma cohérent avec des tendances plus larges du marché, où l’analyse de 2,4 milliards d’appels d’API d’entreprise montre que le routage multi-modèles réduit déjà les coûts d’IA « blended » de 67% d’une année sur l’autre — en exécutant la planification de la récupération sur un modèle de base compact et en transmettant moins de tokens, plus ciblés, au modèle de raisonnement.

Une réduction de 25% des tokens par requête, multipliée sur 10 000 employés effectuant plusieurs requêtes par jour, se traduit par des économies mensuelles substantielles en calcul — réduisant ce que certains analystes appellent le coût caché de l’IA.

L’histoire des coûts va au-delà des simples calculs de tokens. Lorsque la récupération est faible, les organisations compensent en sur-dimensionnant l’infrastructure — fenêtres de contexte plus larges, modèles plus puissants, couches de re-ranking supplémentaires — afin de maintenir une qualité de réponse acceptable. Cette surcharge d’infrastructure suit sa propre courbe de coût, qui augmente linéairement (voire pire) avec le nombre d’utilisateurs.

Une architecture découplée change la trajectoire des coûts. Le modèle de recherche gère le travail de récupération à fort volume et de complexité plus faible pour une fraction du coût par token d’un modèle « frontier ». Le modèle « frontier » n’est appelé qu’une seule fois par requête, avec un paquet de preuves pré-filtré.

Pour la planification budgétaire, la différence se situe entre un modèle de coût qui croît de façon prévisible et un modèle qui s’emballe à chaque nouvel utilisateur ou nouveau cas d’usage. L’Agentic Engine de Glean implémente cette séparation au niveau de la plateforme — Waldo gère la décomposition des requêtes et la collecte de preuves, puis route vers le modèle de raisonnement approprié — offrant aux équipes un moyen d’augmenter l’usage de l’IA sans réécrire l’infrastructure.

Où un système de contexte s’inscrit-il dans cette architecture ?

Un modèle de recherche spécialisé n’est aussi performant que le contexte auquel il peut accéder. La vitesse et l’efficacité au niveau de la couche de récupération comptent peu si le modèle effectue ses recherches sur des données incomplètes, obsolètes ou mal connectées. La plupart des architectures d’IA en entreprise ne disposent pas d’une représentation profonde et structurée de la manière dont les personnes, les contenus et les interactions sont liés entre eux.

L’Enterprise Graph de Glean (une carte structurée des relations à travers les données et les personnes d’une organisation) et le Personal Graph (une couche spécifique à l’utilisateur qui adapte cette carte au rôle, à l’activité et à l’historique d’interactions de chacun) fournissent cette couche. L’Enterprise Graph construit un graphe de connaissances complet qui relie les documents aux projets, les projets aux équipes, les équipes aux individus, et suit l’évolution de ces connexions. Ensemble, ils offrent au modèle de recherche une vue structurée de la connaissance de l’entreprise plutôt qu’un simple index plat de documents.

Lorsqu’un chef de produit interroge le calendrier de lancement d’une fonctionnalité, le modèle de recherche ne se contente pas de trouver des documents contenant ces mots-clés. Il suit les relations — la spécification de la fonctionnalité, le plan de projet associé, le canal Slack de l’équipe, la dernière mise à jour de statut — et rassemble des preuves qui reflètent le fonctionnement réel de l’organisation.

La recherche interne de Glean (2026) montre que la qualité de recherche s’améliore de 20% au cours des six premiers mois, à mesure que l’Enterprise Graph apprend des interactions des utilisateurs — une boucle de rétroaction auto-renforçante que les systèmes de récupération statiques n’ont pas. Le raisonnement agentique, qui utilise cette couche de contexte pour planifier des recherches en plusieurs étapes, offre une augmentation de 24% de la pertinence des réponses et des actions par rapport au RAG standard seul (recherche interne de Glean, 2026).

La prise en compte des permissions est appliquée en amont de tout appel au modèle — une approche qui dépend de la construction de la bonne structure de permissions, et non appliqué comme filtre après la génération des résultats. Chaque document récupéré via les 100+ connecteurs natifs de Glean respecte les contrôles d’accès existants de l’utilisateur — une contrainte essentielle pour la gouvernance et pour la qualité des réponses, puisque des résultats non autorisés introduisent du bruit que le modèle doit ensuite ignorer.

Associée à une rétention contractuelle des données à zéro jour avec les fournisseurs de LLM et à des pistes d’audit intégrées, l’architecture considère la sécurité comme une propriété structurelle plutôt que comme une fonctionnalité ajoutée a posteriori. Un planificateur spécialisé, une couche de contexte approfondie et un modèle de raisonnement de pointe produisent des réponses plus rapides, moins coûteuses et plus précises. Chaque composant prend en charge le travail pour lequel il a été conçu — le modèle de recherche récupère, la couche de contexte filtre selon les permissions et la pertinence, et le modèle de raisonnement synthétise.

Comment évaluer si l’architecture IA de votre entreprise est optimisée en termes de coût, de latence et de qualité

Évaluez trois dimensions — la spécialisation des tâches, l’adaptabilité de la récupération et l’architecture de gouvernance — afin de déterminer si votre système d’IA dépense efficacement la puissance de calcul et fournit les réponses les plus rapides et de la plus haute qualité que vos données peuvent prendre en charge.

Commencez par auditer votre pipeline actuel. Si un seul modèle gère à la fois la récupération et le raisonnement pour chaque requête, vous dépensez presque certainement trop en calcul et vos performances en latence sont insuffisantes.

La première étape de diagnostic consiste à mesurer séparément la latence P50 et P95 pour la phase de recherche et la phase de génération. Si les deux valeurs sont élevées, le goulot d’étranglement provient probablement d’une architecture monolithique où un modèle fait tout.

Ensuite, calculez votre coût en tokens par requête et multipliez-le par votre base d’utilisateurs actifs. Une requête qui consomme 4 000 tokens coûte nettement plus cher avec 10 000 utilisateurs actifs quotidiens qu’avec 500. Vérifiez si votre étape de récupération est statique — une seule recherche vectorielle sans capacité d’affiner ni d’itérer — ou adaptative, avec une planification en plusieurs étapes qui s’ajuste en fonction des résultats intermédiaires.

Une récupération statique est le signe que votre système compense une recherche faible par un raisonnement coûteux.

Trois autres facteurs distinguent une architecture optimisée d’une architecture qui se contente de fonctionner :

• Application des permissions au niveau de la couche de récupération. Si les contrôles d’accès sont appliqués après la génération des résultats, chaque document non autorisé qui atteint le modèle gaspille des tokens et introduit des vecteurs potentiels d’hallucination. Glean applique les permissions en amont, avant que tout modèle ne traite le contenu.
• Composabilité entre les composants du modèle. Pouvez-vous remplacer le modèle de raisonnement sans reconstruire votre infrastructure de recherche ? Si vos étapes de récupération et de génération sont étroitement couplées, chaque mise à niveau de modèle devient un projet de changement de plateforme. L’architecture de Glean permet aux équipes de mettre à jour le modèle de raisonnement indépendamment du planificateur de recherche et de la couche de contexte.
• La gouvernance comme architecture, pas comme arrière-pensée. Gouvernance active des données et de l’IA, y compris les pistes d’audit, les contrôles de résidence des données et la rétention contractuelle des données à zéro jour avec les fournisseurs de LLM, ne sont pas optionnels à l’échelle de l’entreprise. Ce doivent être des propriétés structurelles de la plateforme, pas des fonctionnalités que vous négociez séparément.

Questions fréquentes

Comment un modèle de recherche agentique maintient-il la qualité des réponses tout en utilisant moins de tokens ?

Le modèle de recherche est post-entraîné spécifiquement pour la récupération en entreprise — il décompose les questions, évalue la pertinence des preuves et détermine si les informations sont suffisantes avant de transmettre les résultats à un modèle de raisonnement. Moins de tokens atteignent le modèle de raisonnement, mais ceux qui arrivent sont de meilleure qualité. Résultat : une fenêtre de contexte plus resserrée et plus pertinente, qui produit des réponses aussi précises que celles générées à partir d’une entrée plus large et non filtrée.

Quelles sont les implications en termes de coût de l’ajout d’un modèle de recherche spécialisé à une stack IA existante ?

L’ajout d’une couche de recherche spécialisée réduit la charge en tokens par requête sur votre modèle de raisonnement d’environ 25 %, ce qui se traduit par des économies de calcul significatives à l’échelle de l’entreprise. Le modèle de recherche lui-même s’exécute sur une architecture compacte  son coût par appel représente donc une fraction de celui d’un modèle de pointe. L’effet net est un coût total par requête plus faible, et non une dépense supplémentaire.

Quels cas d’usage bénéficient le plus de cette approche ?

Les cas d’usage avec un volume élevé de requêtes et des réponses sensibles au temps observent les gains les plus importants. La résolution de tickets de support, où les agents ont besoin d’un accès rapide à la documentation produit et à l’historique des dossiers, en est un exemple clair.

La préparation commerciale — rassembler le contexte du compte, le positionnement concurrentiel et les interactions récentes avant une réunion — en est un autre. L’onboarding des employés et la découverte des connaissances internes en bénéficient également, car les nouveaux arrivants génèrent un volume élevé de requêtes larges et exploratoires qu’un modèle de recherche agentique gère plus efficacement qu’un pipeline statique.

Comment cette architecture gère-t-elle la sécurité des données et la gouvernance à l’échelle de l’entreprise ?

Les permissions sont appliquées au niveau de la couche de récupération, en amont de tout appel au modèle, de sorte que les utilisateurs ne voient que les résultats auxquels ils sont autorisés à accéder. Glean maintient une rétention contractuelle des données à zéro jour avec les fournisseurs de LLM, ce qui signifie qu’aucune requête ni aucun contenu de document n’est stocké par le fournisseur de modèle. Des pistes d’audit intégrées et des contrôles de résidence des données sont des propriétés structurelles de la plateforme.

Cette approche est-elle limitée à la recherche, ou s’étend-elle aux workflows agentiques ?

L’architecture s’étend au-delà de la recherche, jusqu’aux workflows agentiques en plusieurs étapes. Les agents IA en entreprise démontrent déjà ce schéma. La même couche de planification qui décompose une requête de recherche peut orchestrer des séquences d’actions — extraire des données d’un système, écrire dans un autre, déclencher une notification — avec la même gouvernance tenant compte des permissions. Les Glean Agents utilisent ce schéma pour automatiser des tâches récurrentes comme la génération de rapports, les mises à jour de statut et l’orchestration de processus, avec une supervision humaine intégrée au workflow à des points de contrôle configurables.

L’écart entre une IA d’entreprise qui fonctionne et une IA d’entreprise qui fonctionne efficacement tient à l’architecture — plus précisément, à la capacité de votre système à utiliser le bon modèle à chaque étape du cycle de vie d’une requête. Des modèles de recherche spécialisés, associés à un contexte organisationnel approfondi et à un raisonnement de pointe, apportent des gains mesurables en coût, en latence et en qualité des réponses, sans imposer de compromis entre eux. Demander une démo pour découvrir comment Glean et l’IA peuvent transformer votre environnement de travail.