Comment fonctionnent les graphes de connaissances et pourquoi ils sont la clé du contexte pour l’IA d’entreprise

Créer des agents capables d’agir de manière fiable en entreprise exige des systèmes qui reproduisent la façon dont les humains donnent du sens à l’information — en reliant ce qu’ils lisent aux personnes, processus, outils, projets et stratégies qui les entourent. Ces associations sont naturelles pour les humains  c’est ainsi que nous démêlons la complexité et les informations contradictoires afin de prendre des décisions. Pour que les LLMs fassent de même, ils ne doivent pas seulement raisonner comme des humains — ils doivent utiliser la connaissance comme des humains. C’est pourquoi le socle de tout excellent moteur agentique est un graphe de connaissances qui fournit aux modèles le bon contexte.

Chez Glean, nous avons enrichi notre graphe de connaissances d’une nouvelle couche — un graphe personnel — qui comprend mieux le contexte humain au travail. Il pousse la personnalisation au-delà de l’historique de chat en comprenant votre manière d’aborder différents types de tâches et en adaptant l’IA en conséquence. Ensemble, ces graphes, associés à l’architecture de recherche hybride de Glean, forment le system of context : un reflet de la façon dont chaque organisation fonctionne, qui permet à l’IA de mieux travailler pour toutes les personnes qui y évoluent.

Qu’est-ce qu’un graphe de connaissances ?

Un graphe de connaissances est une représentation structurée de l’information qui capture les entités et les relations entre elles dans un format lisible par machine. En contexte d’entreprise, les graphes de connaissances servent de couche d’abstraction fondamentale, reliant des données fragmentées — personnes, documents, outils, projets et systèmes — en un réseau cohérent. Contrairement aux index de recherche, les graphes de connaissances se concentrent non seulement sur le contenu, mais aussi sur les relations, comme celles entre des clients et des tickets de support, ce qui les rend particulièrement adaptés pour ancrer les systèmes d’IA d’entreprise dans une connaissance contextualisée.

Au cœur d’un graphe de connaissances se trouve la structure en triplets : (sujet, prédicat, objet). Elle encode des faits ou des relations spécifiques, comme (Ingénieur A, est responsable de, Ticket Jira B) ou (Document X, référence, Projet Y). Ces triplets sémantiques constituent les arêtes d’un graphe, qui peut être parcouru pour inférer des connaissances supplémentaires ou résoudre des requêtes complexes. En entreprise, cela permet de faire émerger des informations fines à travers les silos organisationnels — par exemple, identifier comment une sortie produit se rattache à des documents de roadmap, des contributeurs, des dossiers de support et des retours clients.

L’expressivité d’un graphe de connaissances inclut des faits supplémentaires au-delà des relations. Des propriétés d’arête — telles que des horodatages, des contrôles d’accès, des scores de confiance ou la provenance — peuvent être associées à chaque relation, permettant aux systèmes de raisonner à partir de métadonnées essentielles à la gouvernance d’entreprise. Par exemple, le graphe peut non seulement représenter que (Employé A, reporte à, Manager B), mais aussi suivre depuis quand cette relation hiérarchique existe, ou si l’information a été déduite d’un calendrier, d’un annuaire ou d’un fil d’e-mails. L’ensemble du graphe dans Glean est conçu avec des contrôles d’accès à granularité fine afin que les employés ne puissent voir que les données déjà partagées avec eux dans le système source.

En pratique, les graphes de connaissances d’entreprise permettent la recherche d’informations à travers des silos de données et évitent les hallucinations courantes de la recherche sémantique. Ils constituent la colonne vertébrale de l’intelligence contextuelle — permettant aux agents et assistants IA de comprendre comment les données s’articulent entre elles.

Comment fonctionnent les graphes de connaissances

La création d’un graphe de connaissances en entreprise commence par l’extraction et l’identification d’entités pertinentes à partir d’entrées en langage naturel. Prenons l’exemple du mot « Reddit ». Cela peut sembler simple, mais « Reddit » peut désigner des entités totalement différentes selon le contexte. Si le terme est mentionné par un chargé de compte au sein de l’organisation commerciale, il renverra probablement à un client. Dans une conversation marketing, il peut faire référence aux dépenses publicitaires sur le réseau social « Reddit ». Désambiguïser ces sens nécessite une annotation sensible au contexte, qui prend en compte le rôle de l’utilisateur, son intention et le contenu environnant, afin d’identifier correctement l’entité et de la cartographier dans le graphe de connaissances.

Une fois l’entité annotée, l’étape suivante consiste à comprendre l’intention derrière la requête. Cela implique de traduire la requête en langage naturel en une représentation structurée pouvant être exécutée de manière programmatique. Traditionnellement, cela passait par un apprentissage semi-automatisé. Des opérateurs humains initiaient des modèles de requêtes connus — comme « trouver un libellé Jira » — et s’en servaient pour identifier des intentions fréquentes. Ces requêtes de départ étaient ensuite étendues en analysant les journaux de requêtes afin de découvrir d’autres formulations renvoyant à la même intention. Ce processus ressemble à un appariement de motifs à grande échelle, où l’intention est reliée à des entités et à des types de requêtes connus sur la base de structures récurrentes dans le langage.  ;

La troisième phase consiste à prendre l’intention structurée et à exécuter l’action appropriée, souvent en interrogeant le graphe de connaissances. Par exemple, une requête structurée du type « trouver les libellés Jira utilisés par Reddit » peut être émise pour récupérer les informations pertinentes. Cette étape d’exécution est précisément là où la structure du graphe devient essentielle : elle permet au système de récupérer des informations précises en parcourant les relations entre les entités du graphe.

Avec l’arrivée des LLMs, les deux premières phases — l’annotation des entités et la reconnaissance de l’intention — sont devenues nettement plus puissantes et automatisées. Les LLMs excellent dans l’analyse du langage naturel, réduisant le besoin de créer manuellement des motifs et de recourir à une désambiguïsation basée sur des règles.  ;

Chez Glean, nous avons étendu notre graphe pour prendre en charge des milliers d’arêtes avec l’aide des LLMs. Même avec les LLMs, créer des graphes de connaissances n’a rien d’évident. Nous y reviendrons plus loin.

Là où les LLMs montrent leurs limites dans les cas d’usage d’IA en entreprise  ;

Les LLMs sont efficaces pour capturer de larges associations sémantiques dans leur fenêtre de contexte, mais ils peinent avec le raisonnement multi-sauts, le langage propre à l’entreprise, ainsi qu’avec la compréhension des processus ou des schémas d’usage. En conséquence, l’extraction de données basée sur les LLMs a tendance à être intrinsèquement « lossy ».

Pris isolément, les LLMs peinent à rappeler des faits avec précision et à traiter les tâches qui exigent une énumération — comme répondre à « Qui a contribué au projet X ? » ou « Liste tous les labels Jira du client ABC ». De plus, les LLMs peuvent mal interpréter le langage naturel ou mal classifier l’intention de l’utilisateur — des problèmes liés à des ratés en NLP. C’est là que les graphes de connaissances entrent en jeu : en ancrant les réponses dans des relations structurées et des entités vérifiées, ils contribuent à réduire l’ambiguïté et à améliorer la fiabilité.

Les LLMs (sur)pondèrent la proximité des termes

Dans les environnements d’entreprise, les LLMs ont souvent du mal à être précis, en surpondérant la proximité des termes. Prenons, par exemple, une utilisatrice fictive, Jennifer Armstrong, responsable field marketing. Lors d’une requête récente, Jennifer a été identifiée à tort comme Head of Customer Supplier and Employee Experience. En retraçant l’origine du problème, on constate que le LLM avait mal interprété un message Slack au sujet d’un événement qu’elle avait organisé, lui attribuant un titre incorrect.  ;

Les LLMs confondent des entités aux noms similaires

Un problème similaire survient avec les noms de produits. Claude 3.7 Sonnet et Claude 3.5 Sonnet v2 sont des modèles distincts, mais les LLMs confondent fréquemment les deux, fusionnant leurs fonctionnalités ou leur documentation dans une réponse unique et erronée. Sans désambiguïsation structurelle, même des différences subtiles entre des versions de modèle sont faciles à déformer.

Les LLMs peinent avec les requêtes déterministes

Les graphes de connaissances aident à atténuer ces problèmes en ancrant les requêtes sur des entités connues et structurées. Comme l’illustre le schéma suivant, lorsqu’on demande « Liste tous les account executives en Asie », le graphe de connaissances peut identifier les termes de la requête « account executives » comme un rôle précis, plutôt que comme une description générale, et « Asie » comme une localisation. Avec ces informations, le système peut ensuite exécuter une requête structurée exhaustive et déterministe pour tous les employés ayant le rôle Account Executive et une localisation en Asie. C’est quelque chose que les LLMs seuls ont du mal à faire de manière constante.

Les LLMs ont du mal avec les relations entre entités

Dans des tâches plus complexes — comme répondre à « Où dois-je déposer des demandes de fonctionnalités pour Reddit ? » — les LLMs doivent lever l’ambiguïté entre Reddit la plateforme sociale et Reddit le client enterprise, reconnaître que le processus implique Jira, puis enchaîner ces compréhensions dans un workflow cohérent. Ce niveau de raisonnement relationnel et d’inférence multi-sauts est difficile à obtenir de façon fiable sans un graphe de connaissances lisible par machine, qui cartographie ensemble ces entités, ces rôles et ces systèmes.

La fiabilité des LLMs s’inscrit sur un continuum. Pour le rappel de faits simples, les LLMs peuvent fournir des réponses fiables et correctes — parfois 100% du temps, surtout lorsque la réponse est explicite et située à proximité dans un contexte accessible. Pour des inférences plus complexes, multi-sauts ou indirectes (« Montre tous les codebases des projets pilotés par X et livrés au T1 2025 »), les LLMs deviennent moins fiables. Il leur arrive de répondre correctement si tout s’aligne, mais ils hallucinent souvent ou manquent des connexions. Il existe une longue traîne de questions difficiles ou nuancées qui se situent en dehors de la zone où les LLMs sont robustes — c’est là que les performances chutent nettement et que les graphes de connaissances dominent.  ;

Transformer le travail grâce aux graphes de connaissances

L’une des questions les plus difficiles — mais aussi les plus fréquentes — auxquelles tout dirigeant doit répondre est : « Où en est le projet X par rapport à ses OKRs ? » C’est une question à forte valeur et forte intention, difficile à traiter dans la plupart des systèmes, en particulier dans un contexte d’ingénierie. Pour répondre avec précision, le système doit corréler plusieurs sources de données — en particulier les contributions au code — et les relier aux objectifs et résultats clés définis pour un projet donné. Cette corrélation permet d’évaluer si un projet est au rouge, au jaune ou au vert.

Le défi consiste à déterminer quels changements de code sont pertinents pour quels OKRs. Les LLMs peinent ici, car ce n’est pas une tâche qui consiste à interpréter un langage narratif. Le code est concis, structuré et manque souvent d’annotations directes qui le rattachent soit à des projets, soit à des objectifs business. Le volume de changements est également important — des milliers de commits peuvent exister dans un codebase, et seule une petite fraction peut concerner une initiative spécifique.

Si les LLMs excellent pour résumer l’avancement ou générer du texte une fois que les bons signaux sont identifiés, ils sont en revanche mal adaptés pour faire émerger ces signaux au départ. Pour cela, il faut un système capable de cartographier des artefacts de code — tels que des répertoires, des fichiers ou des composants — vers des projets spécifiques. Cela implique des processus hors ligne, des métadonnées de projet et des heuristiques comme la structure des répertoires (p. ex., un dossier docubuilder/) — autant de composants essentiels qui alimentent un graphe de connaissances.  ;

Une fois ces associations établies, les relations structurées qui en résultent doivent être exposées dans le chemin de serving pour un usage à l’exécution. C’est là que le graphe de connaissances devient critique  il fournit une représentation structurée qui peut être interrogée rapidement au run-time.

Pour vous aider à repenser davantage l’impact des graphes de connaissances dans l’IA en entreprise, voici quelques exemples supplémentaires :  ;

Cette question s’appuie sur un raisonnement multi-étapes pour analyser les données clients, les fonctionnalités produit et les tickets de support.

IT : quelle panne système déclenche plusieurs alertes redondantes sur nos services, et comment réduire le bruit  ; ?

Cette question mobilise la compréhension des outils d’infrastructure et du planning d’astreinte, associe les logs à différents services et identifie les redondances pour réduire le bruit.  ; ;  ;

RH : fournissez-moi une liste personnalisée et à jour des activités d’onboarding des employés.

Les graphes de connaissances peuvent accélérer l’onboarding en capturant les activités d’une équipe avec un contexte clé — comme les outils, les procédures et la documentation — et en utilisant ces informations pour aider un LLM à générer une liste priorisée et toujours à jour des tâches d’onboarding.

Personnel : aidez-moi à rédiger mon auto-évaluation pour mon entretien d’évaluation.

Les graphes de connaissances peuvent faire ressortir une liste complète des activités d’un employé — ainsi que des éléments de contexte importants comme l’équipe, les objectifs et les collaborateurs. Associés aux LLMs, ils peuvent accélérer de manière significative le processus de rédaction et d’amélioration d’une auto-évaluation de grande qualité.

Les aspects les plus difficiles des graphes de connaissances en entreprise

Dans les entreprises, construire un graphe de connaissances de haute qualité est fondamentalement différent — et, à certains égards, plus complexe — que de bâtir des graphes de connaissances comme ceux de Google ou Bing. Les principaux défis sont la sensibilité liée à la confidentialité, le besoin d’algorithmes scalables et la difficulté d’identifier les entités et faits clés lorsqu’on ne dispose que d’un ensemble relativement restreint de documents — et qu’une revue manuelle n’est pas envisageable.

Contrairement aux données du web public, les informations d’entreprise contiennent souvent des contenus sensibles, confidentiels ou réglementés qui ne peuvent pas être librement consultés, examinés manuellement ou exposés à une équipe d’annotateurs humains (comme c’est courant dans les projets de graphes publics). Chaque étape de l’extraction d’entités doit respecter les limites de confidentialité, contractuelles et juridiques de l’organisation. Le graphe doit être structuré pour permettre aux employés d’avoir des niveaux d’accès différents aux données — un besoin dont les graphes grand public n’ont pas à tenir compte. Dans les environnements publics, les équipes peuvent sélectionner manuellement des faits importants en explorant d’immenses volumes de données accessibles publiquement.  ;

En entreprise, « mettre les mains dans la donnée » via une revue manuelle est soit interdit, soit impraticable à grande échelle en raison de la confidentialité et des volumes. La construction manuelle d’un graphe ne passe pas à l’échelle pour des milliers de clients entreprises diversifiés, chacun avec ses propres données, son vocabulaire et ses sensibilités de sécurité. Une méthode algorithmique et automatisée est indispensable pour traiter les corpus de tous les clients sans intervention humaine et s’adapter dynamiquement à l’arrivée de nouvelles données. Le processus d’extraction, sans inspection directe, implique les étapes suivantes en IA d’entreprise :

1. Extraction automatisée de noms : commencez par exécuter des algorithmes (p. ex., extraction de groupes nominaux en NLP) sur le corpus afin d’en extraire toutes les entités potentielles — automatiquement et sans revue humaine des données.
2. Filtrage par fréquence et proéminence : tous les termes fréquemment mentionnés ne sont pas importants. Après l’extraction initiale, les termes courants (« table », « espagnol ») sont filtrés à l’aide de méthodes statistiques et heuristiques.
3. Preuves de l’importance d’une entité : pour promouvoir une entité dans le graphe de connaissances, des signaux supplémentaires sont utilisés pour déterminer sa proéminence, notamment :  ;
   
   1. Présence dans les titres de documents clés
   2. Liens fréquents entre des ressources largement utilisées
   3. Occurrence dans les fichiers les plus partagés ou consultés  ;
4. Extraction sélective de propriétés et identification des prédicats : pour chaque entité mise en avant, des algorithmes extraient des termes descriptifs et des relations possibles (prédicats), en priorisant là encore les faits pour lesquels il existe des preuves solides et reproductibles (p. ex., « document rédigé par une personne », « projet dirigé par »).
5. Affinage continu, algorithmique : comme personne ne lit les données privées, le système améliore itérativement ses filtres afin de réduire le risque de sur-inclusion (fuite ou gonflement du graphe avec des entités à faible valeur) et de s’adapter à de nouvelles structures de données ou à de nouveaux signaux dans chaque entreprise.

Chez Glean, nous avons conçu une architecture de crawler en temps réel qui alimente à la fois la recherche sémantique et la recherche lexicale, en ingérant en continu le contenu et les métadonnées de l’entreprise. Cette même infrastructure alimente notre graphe de connaissances — et nous fournit une base solide. Au cours des six dernières années, nous avons affiné ce graphe avec des algorithmes conçus sur mesure pour prendre en charge un raisonnement de plus en plus complexe et des workflows d’entreprise requis par les agents.

Enrichir le graphe de connaissances avec le graphe personnel

Nous avons récemment ajouté une nouvelle dimension au graphe de connaissances d’entreprise : le graphe personnel, qui capture l’activité des employés pour comprendre sur quoi chacun travaille et l’impact de ses efforts. L’objectif est de modéliser le travail réel — identifier les projets actifs, les schémas de collaboration et les tâches en cours — afin que Glean puisse commencer à offrir une assistance proactive, par exemple en faisant remonter les priorités, en signalant les conflits et en aidant les utilisateurs à rester organisés.

Mais le graphe personnel va au-delà du simple réglage de la pertinence ou de la capture de l’historique d’interactions dans Glean. Il sert de fondation à la personnalisation de l’expérience Glean — en alimentant les réponses de Assistant et en orientant des agents conscients du contexte. Contrairement aux systèmes de mémoire des outils de chat IA classiques qui s’appuient sur l’historique de session, le graphe personnel considère de manière holistique l’activité numérique d’un individu, à travers les outils, les systèmes et le temps.

Pour prendre cela en charge, nous avons étendu notre infrastructure de crawling, en capturant des données bien plus granulaires, y compris les comportements de lecture et les signaux de consommation passive, afin de générer des flux denses, en temps réel, d’activité numérique. Cela constitue le socle pour comprendre le contexte de travail d’un utilisateur au moment où il se déroule.  ;

Une raison clé pour laquelle nous pouvons désormais construire des graphes personnels est le progrès du raisonnement des LLMs. Le machine learning classique a eu du mal à unifier les signaux d’activité en raison de l’absence d’identifiants directs entre des sources disparates (relier une invitation de calendrier à des modifications d’un document associé). Les LLMs peuvent traiter des flux d’activité chronologiques et raisonner dessus pour regrouper des actions liées en unités logiques : des tâches, des projets ou des clusters thématiques de travail — même en présence de signaux clairsemés et de changements de tâche.

Chez Glean, nous regroupons chaque action atomique (« création du doc X », « participation à la réunion Y », « exécution de l’outil interne Z ») en sous-tâches, puis les consolidons en tâches de plus haut niveau, avec des libellés tenant compte du contexte comme « rédigé une note produit » ou « répondu à une demande juridique ». Le système agrège ensuite les tâches liées par thématique — par exemple plusieurs documents associés à un lancement produit — et les rattache à des objectifs organisationnels comme les OKR. En analysant les schémas de collaboration (interactions récurrentes dans les commentaires, canaux Slack partagés), le graphe personnel révèle non seulement ce qui est fait, mais aussi qui travaille ensemble et comment — afin de produire une vision plus complète de la dynamique de travail au sein de l’entreprise.

Construire le graphe personnel n’est pas trivial. D’abord, tout travail significatif n’est pas numérique (réunions et échanges en présentiel). Et même pour l’activité digitale, déduire l’intention réelle (une modification de doc correspond-elle à une refonte majeure, à une correction ou à une simple amélioration ?) n’est parfois possible que si l’utilisateur la précise explicitement (« First Draft » dans le titre du doc). Cela peut rendre difficile l’identification des bons signaux lors de la construction du graphe personnel.

Notre architecture de crawler nous donne ici une avance décisive. En effet, chaque source de données a son propre schéma (ce que signifie « commentaire » varie selon Jira, GDocs, l’e-mail, etc.). Créer un langage commun, indépendant des sources, ainsi qu’une base de données chronologique est indispensable pour rendre possible un raisonnement multi-sources dans l’entreprise. Cela n’est possible qu’en indexant d’abord vos données  la recherche fédérée ne fournit pas la structure ni les signaux nécessaires pour relier les points entre les sources.  ;

Nous exploitons déjà le graphe personnel chez Glean — avec des agents de démarrage rapide capables d’aider les utilisateurs à résumer ce sur quoi ils ont travaillé la semaine dernière ou à se préparer aux évaluations de performance. Ces agents nous fournissent une boucle de feedback qui nous permet d’itérer en continu sur le graphe personnel.  ;

La vision plus large du contexte chez Glean est ce qui nous permet de déployer l’IA de façon transverse dans toute l’entreprise. Glean ne se contente pas de répondre aux questions : il apprend votre façon de travailler et s’adapte avec vous pour devenir votre assistant IA expert, personnalisé, ainsi qu’une plateforme d’agents.

Le système de contexte dans l’IA d’entreprise

Lorsque nous réunissons le graphe de connaissances d’entreprise et le graphe personnel, nous ne sommes pas seulement en mesure de soutenir des décisions complexes et à fort enjeu — nous pouvons le faire d’une manière qui paraît personnelle, à la fois pour l’organisation et pour les individus qui la composent.

À mesure que nous pensons l’avenir des assistants et des agents en entreprise, la personnalisation ne peut pas s’arrêter à l’adaptation des réponses. Ces systèmes doivent anticiper les besoins — lever les blocages avant qu’ils ne deviennent des problèmes, mettre en lumière des initiatives au point mort — et accompagner activement les utilisateurs vers leurs objectifs. C’est là que nous allons.

Jusqu’ici, nous nous sommes concentrés sur deux couches clés : les données d’entreprise et les personnes — sans doute les actifs les plus importants de toute organisation. Mais il existe une troisième couche : les processus — la façon dont le travail est réellement accompli, à la fois par les personnes et, de plus en plus, par les agents.

Les processus peuvent être profondément personnels, façonnés par ceux qui les conçoivent. Mais beaucoup fonctionnent aussi en arrière-plan, indépendamment d’un individu en particulier. Nous apprenons des deux. En observant comment les personnes travaillent avec les données, les systèmes et les outils, et comment les agents sont utilisés, nous commençons à faire émerger et à modéliser ces processus comme faisant partie du système lui-même.

Cette vision en évolution crée une nouvelle couche de contexte — une couche qui ne se situe pas à part des données et des personnes, mais s’appuie sur elles. Une fois que vous voyez cette toile en mouvement, vous réalisez que le système de contexte ne sert pas seulement à organiser l’information : il s’agit d’orchestrer une intelligence contextuelle. Les données sont le point de départ, mais ce qui en ressort, c’est un réseau qui s’adapte en continu, apprend, et apporte le bon contexte à chaque interaction IA.

Vu sous cet angle, cela devient évident : les LLMs ne sont pas la seule puissance cognitive des systèmes d’agents. Le système de contexte l’est aussi.