Mémoire des agents IA : la stratégie de Glean
Comment Glean veut donner du contexte aux agents IA sans enfermer les entreprises. Analyse de sa stratégie, de ses choix techniques et de ses limites.
Mémoire des agents IA : pourquoi Glean veut rester remplaçable
Un agent d'IA peut rédiger un compte rendu, retrouver une procédure ou préparer une réponse client. Mais, dans une entreprise, ces tâches ne se résument pas à produire du texte : il faut savoir qui a accès à quoi, comprendre comment les équipes travaillent et retrouver l'information dans une série d'outils différents. Sans ce contexte, même le meilleur modèle peut "inventer" une réponse ou, plus banalement, mobiliser des ressources coûteuses pour retrouver ce qu'il aurait dû avoir sous la main.
C'est là que Glean se place. D'abord connue comme moteur de recherche interne, l'entreprise cherche maintenant à fournir une couche de contexte et de "mémoire" aux assistants et aux agents d'IA. Son dirigeant, Arvind Jain, défend une idée volontairement tranchée : Glean devrait être facile à remplacer, et les entreprises devraient garder la main sur la mémoire que leurs outils accumulent.
Derrière, il y a une question qui revient sans cesse côté directions informatiques : faut-il choisir un assistant unique, ou construire une infrastructure de contexte réutilisable par plusieurs modèles ? Voici ce que la stratégie de Glean change, ce qu'elle peut apporter, et ce qu'il faut vérifier avant de copier l'approche.
De la recherche interne à la couche de contexte
Glean est née d'un problème très concret, pas d'une démonstration de technologie. Chez Rubrik, que Jain a cofondée, la croissance rendait l'information interne de plus en plus difficile à retrouver : les documents existaient, mais les équipes ne savaient pas toujours où chercher, ni quelle source était la plus à jour. Son passage chez Google, sur la recherche, Maps et YouTube, l'a conduit à appliquer des techniques de recherche à la réalité des entreprises.
Lancée en 2019, Glean s'est d'abord branchée sur des systèmes déjà utilisés par ses clients : des outils de gestion de la relation client comme Salesforce ou HubSpot, des plateformes de développement comme GitHub, le suivi de projets comme Jira, et aussi des applications RH et informatiques. L'idée était d'indexer sans forcer les équipes à remplacer tout l'empilement logiciel.
Un moteur de recherche ne suffit plus
Un moteur interne répond surtout à une question : où se trouve l'information pertinente ? Un assistant d'IA doit aller plus loin. Il faut aussi déterminer si l'utilisateur a le droit de consulter l'information, comprendre comment elle se relie à d'autres éléments, puis fournir au modèle un contenu utilisable.
Glean se présente aujourd'hui comme un assistant de travail et une plateforme d'agents. Mais elle peut aussi fonctionner comme une couche de contexte "en arrière-plan" : l'utilisateur continue à travailler avec un outil comme Claude, tandis que celui-ci interroge Glean pour récupérer des informations liées à l'environnement de l'entreprise.
Cette distinction compte. Beaucoup d'organisations n'ont pas envie d'ajouter une interface de plus à leur parc logiciel. Elles veulent plutôt améliorer les assistants déjà utilisés en leur donnant des données plus fiables et des règles d'accès cohérentes. Dans ce cas, la valeur se déplace : de la simple conversation vers l'infrastructure qui prépare ce que le modèle reçoit.
Relier les informations sans tout centraliser
Selon Jain, Glean construit des graphes de connaissances : personnes, concepts, processus. Le but n'est pas de traiter chaque document comme un bloc isolé. Une procédure peut être rattachée à une équipe, à un projet, à un responsable, et à des échanges qui éclairent son usage "sur le terrain".
Ce n'est pas forcément synonyme d'une copie de toutes les données dans une base unique. En revanche, l'entreprise doit savoir précisément ce qui est indexé, ce qui est conservé, ce qui est transmis au modèle et pendant combien de temps.
Pour une entreprise française ou européenne, ce n'est pas un détail administratif. Ces choix touchent à la sécurité, à la conservation des données, aux contrats avec les fournisseurs et aux obligations liées au RGPD. Un graphe de connaissances peut faciliter l'accès, mais il rend aussi indispensable une cartographie claire des données et des permissions.
Pourquoi le contexte change l'économie des agents
Le modèle d'IA choisi fait souvent figure de décision "structurante". Dans la vraie vie, le coût total dépend aussi du nombre d'appels, de la quantité de contexte envoyée, de la latence, et du travail nécessaire pour fiabiliser les réponses. Un modèle puissant peut coûter cher si, à chaque question, il doit chercher dans beaucoup de systèmes ou ingérer de longs extraits.
Arvind Jain affirme que, pour 85 à 90 % des tâches d'entreprise traitées via Glean, la société préfère utiliser un autre modèle que Claude, jugé coûteux. Il soutient que certains modèles GPT coûtent beaucoup moins cher tout en suffisant pour ces usages. Attention : ce n'est pas une comparaison indépendante de l'ensemble des modèles, mais une lecture "par cas" basée sur ce que Glean rencontre dans son produit.
Donner les bons éléments au bon modèle
Dans cette approche, le modèle n'est qu'un composant. Le système peut chercher l'information pertinente, vérifier les droits, préparer un contexte plus court, puis seulement ensuite demander au modèle de résumer, classer ou rédiger.
Concrètement, ça ouvre plusieurs leviers :
- réserver les modèles plus coûteux aux tâches qui ont vraiment besoin de leur capacité de raisonnement ou de génération ;
- utiliser des modèles moins chers pour la classification, l'extraction et les demandes plus courantes ;
- réduire ce qu'on envoie au modèle en ne lui donnant d'abord que les passages les plus utiles ;
- changer de modèle sans refaire toute l'intégration aux outils de l'entreprise.
Dans un groupe qui traite des milliers de requêtes par jour, gagner quelques "unités" par requête peut vite compter. Mais une baisse de consommation ne suffit pas à prédire la facture : il faut aussi regarder les coûts d'indexation, d'infrastructure, de supervision, d'intégration et de contrôle de qualité.
Des gains annoncés à vérifier dans votre propre environnement
Jain cite des résultats : avec du contexte fourni à Claude, le système serait deux fois plus rapide, utiliserait deux fois moins de jetons et verrait certaines réponses préférées apparaître cinq fois plus souvent. Ce sont des chiffres rapportés par Glean. Ils ne garantissent pas le même effet partout : ni sur tous les modèles, ni dans toutes les entreprises, ni pour tous les types de tâches.
La bonne méthode consiste à tester sur un échantillon représentatif du travail réel. Par exemple : retrouver une procédure interne, préparer un résumé de compte client, répondre à une question sur un projet. Pour chaque cas, comparez au moins :
- la justesse et l'exhaustivité de la réponse ;
- la latence ressentie par l'utilisateur ;
- le coût moyen par tâche, y compris ce qui se passe "autour" (indexation, recherche, préparation du contexte) ;
- la capacité à citer les sources et à signaler les incertitudes ;
- le respect des droits d'accès et des règles de conservation.
Un test centré uniquement sur la qualité rédactionnelle ne suffit pas. Une réponse fluide, mais basée sur un document périmé, reste une mauvaise réponse. Et gagner en vitesse ne compense pas une fuite de données, ni une hausse du taux d'erreur quand la décision peut avoir des conséquences.
Une mémoire qui ne doit pas devenir une prison
Les assistants apprennent progressivement les préférences d'un utilisateur : niveau de détail attendu, façon de structurer un document, tâches qu'il délègue. Les agents peuvent aussi évoluer grâce aux retours humains. Ça rend l'outil plus utile, mais ça pose une question simple : qui "possède" cette mémoire, qui peut y accéder, et peut-on la transférer vers un autre fournisseur ?
Jain oppose deux modèles. Dans certains cas, la mémoire reste liée au fournisseur. Glean veut au contraire la stocker dans un format standard, contrôlé par l'entreprise. Le dirigeant résume l'objectif avec une formule volontairement nette : « Notre objectif est de pouvoir être remplacés très facilement. »
La portabilité, un choix d'architecture
On ne rend pas une mémoire "portable" avec une clause sur un papier. Cela dépend de détails techniques et organisationnels : format des données, documentation, export possible, gestion des identifiants, historique des consentements, capacité à reconstituer les relations entre éléments.
Si vous évaluez cette approche, demandez des réponses concrètes :
- Peut-on exporter les préférences, les retours et les données de mémoire dans un format documenté ?
- Peut-on les réutiliser avec un autre assistant ou un autre fournisseur ?
- Les données exportées gardent-elles leur contexte et leur provenance ?
- Que se passe-t-il à la fin du contrat, notamment pour les copies, les journaux et les sauvegardes ?
- Les informations apprises à partir des retours humains peuvent-elles être supprimées ou corrigées ?
Il y a un compromis. Un format vraiment portable peut limiter certaines fonctions propriétaires ou demander plus de travail d'intégration. À l'inverse, une mémoire très optimisée pour un assistant précis peut améliorer l'expérience tout en rendant un changement plus cher. Le bon choix dépend donc de votre tolérance à la dépendance, et de la valeur réelle que vous mettez dans la continuité.
Les permissions ne doivent pas dépendre du modèle
Sur la confidentialité, Jain affirme que Glean reprend les permissions déjà définies dans les systèmes de l'entreprise. Un salarié ne devrait pas pouvoir, via l'assistant, accéder à la boîte de réception d'un collègue s'il n'en a pas les droits. Et ces contrôles seraient programmatiques plutôt que confiés au modèle, dont les réponses peuvent être approximatives.
Autrement dit : le modèle aide à interpréter une demande, mais il ne doit pas décider seul de l'autorisation d'accès. Les permissions doivent s'appuyer sur des mécanismes explicites, testables et audités. Reste un point à vérifier : la propagation quand les données sont indexées, résumées ou mises en cache. Une règle correcte à la source ne garantit rien si une copie dérivée s'en affranchit.
Jain distingue aussi les informations personnelles (par exemple des messages LinkedIn) des données de l'entreprise. Selon lui, ces données restent attachées à l'employé et ne deviennent pas des informations de l'organisation. C'est une intention ; il faut ensuite la traduire en règles opérationnelles : quelles données sont collectées, pour quelles fins, avec quel consentement, et pendant combien de temps. En pratique, le RGPD impose de documenter ces choix, pas seulement de les annoncer.
Ce que cette stratégie implique pour les entreprises
L'idée portée par Glean est simple : les systèmes "officiels" ne contiennent qu'une partie du savoir utile. Jain estime que 80 à 90 % de la façon dont le travail se fait réellement vit dans la tête des personnes, plutôt que dans les bases ou les documents. Les habitudes du quotidien révèlent des exceptions, des raccourcis, des détails que les procédures formelles ne décrivent pas toujours.
C'est plausible, mais il faut rester prudent. Les échanges peuvent aussi contenir des informations personnelles, des données confidentielles, ou des opinions qui n'ont pas vocation à alimenter une mémoire collective. Tout accroître en "contexte" peut améliorer certains agents, mais ça ne justifie pas de collecter toutes les conversations.
Commencer par un problème mesurable
Pour une direction métier ou une DSI, la question utile n'est pas "faut-il une IA qui connaît tout ?". C'est plutôt : quelle tâche coûte aujourd'hui du temps parce que l'information est dispersée, difficile à retrouver, ou détenue par quelques personnes ?
Un déploiement raisonnable peut suivre quatre étapes :
- Choisir un cas d'usage bien délimité. Par exemple, retrouver des procédures informatiques ou préparer le contexte d'un dossier client, plutôt que d'ouvrir d'emblée l'accès à toutes les données de l'entreprise.
- Cartographier les sources et les droits. Identifier les applications concernées, les propriétaires des données, les règles d'accès et ce qui ne doit pas être indexé.
- Construire une base de comparaison. Mesurer le temps de recherche, le taux de réponses correctes, le taux d'erreur et le coût avant déploiement.
- Tester sur des utilisateurs et des cas réels. Vérifier les réponses, les citations, les refus d'accès et le comportement quand l'information manque.
Cette façon de procéder évite de confondre une démonstration et une valeur opérationnelle. Un assistant impressionnant en présentation peut s'écrouler dès qu'il rencontre des données anciennes, des noms ambigus ou des permissions héritées de plusieurs systèmes.
La croissance révèle un autre problème : l'organisation
Glean annonce plus de 1 000 grands clients, plusieurs millions d'utilisateurs et environ 1 500 employés. Jain explique aussi que l'entreprise a dépassé 300 millions de dollars de revenus récurrents annualisés, quinze mois après avoir atteint 100 millions. Ces chiffres montrent une croissance rapide, mais ne disent rien, à eux seuls, de la rentabilité ni de la qualité d'exécution.
Le dirigeant insiste sur le bouche-à-oreille : des utilisateurs changeraient d'employeur et feraient connaître le produit. Pour passer à l'échelle, il cite le recrutement et l'alignement des équipes comme difficulté principale. En clair : la technologie ne supprime pas les problèmes d'organisation. Elle peut même les rendre plus visibles.
Cette nuance dépasse Glean. Quand une entreprise grandit, l'information se fragmente et la coordination coûte plus cher. Une couche de recherche ou des agents peuvent réduire certaines frictions, mais ils ne remplacent ni des responsabilités claires ni des processus maintenus dans le temps. Si personne ne sait quelle source fait autorité, l'IA ne fera pas disparaître l'ambiguïté : elle la restituera plus vite.
Une entreprise en croissance, sans projet immédiat d'introduction en Bourse
Jain a déclaré à TNW que Glean n'avait pas de nouvelle levée de fonds prévue ni de calendrier concret d'introduction en Bourse. Selon lui, l'entreprise pourrait entrer en Bourse si elle le voulait, à condition de préparer ses processus internes, mais le secteur de l'IA évolue trop vite pour faire de cette stabilité une priorité aujourd'hui.
Ce raisonnement est cohérent avec un marché où les coûts, les modèles et les attentes clients bougent rapidement. Mais il ne permet pas de conclure sur la suite. Pour les clients, le sujet pratique reste la continuité : quelles garanties contractuelles, quelles options d'export et quels scénarios de réversibilité existent si le fournisseur change de trajectoire ?
Ce qu'il faut retenir
La proposition de Glean ne consiste pas seulement à "ajouter un chatbot". Elle vise à organiser le contexte, appliquer les permissions et fournir au modèle ce dont il a besoin, tout en cherchant à rendre la mémoire portable.
C'est une approche intéressante si elle réduit les coûts et améliore la qualité sans créer une dépendance opaque. Avant de l'adopter, mesurez les gains sur vos tâches réelles, vérifiez comment les droits se propagent, et exigez des garanties vérifiables sur l'export des données. La vraie question n'est pas "quel modèle impressionne le plus". C'est : quelle combinaison de données, de règles et de modèles produit des résultats fiables, à un coût acceptable, et suffisamment flexible pour évoluer demain.