Le graphe de connaissances, sans le jargon
Un moteur de recherche retrouve des documents. Un graphe relie ce qu'ils contiennent, et répond à des questions qu'aucun document ne contient à lui seul.
En bref
Un graphe de connaissances d'entreprise représente vos clients, contrats, projets et incidents comme des objets reliés entre eux, et non comme des fichiers à retrouver. Il est construit automatiquement à partir de vos sources existantes, et il répond aux questions qui traversent plusieurs systèmes, ce qu'une recherche documentaire ne sait pas faire.
Quel problème un graphe de connaissances résout-il ?
Prenez une question ordinaire de comité de direction :
Quels clients ont un contrat qui expire ce trimestre et un incident non résolu ?
Aucun fichier de votre entreprise ne contient cette réponse. Les contrats sont dans un tableur ou un espace documentaire. Les incidents sont dans un outil de support. Les clients sont dans le CRM. La réponse existe, mais elle est répartie sur trois systèmes qui ne se parlent pas.
Un moteur de recherche interne vous rendra les documents où figurent les mots « contrat » et « incident ». Il ne peut pas faire le rapprochement, parce qu'il travaille sur des documents, pas sur ce qu'ils décrivent. Une gestion électronique de documents (GED) classe mieux, mais elle classe toujours des fichiers.
Qu'est-ce qu'un graphe de connaissances, concrètement ?
Un graphe représente votre entreprise comme un réseau d'objets reliés. Un client, un contrat, un projet, un incident, une personne deviennent des objets à part entière. Les liens entre eux deviennent des relations explicites : ce contrat appartient à ce client, cet incident concerne ce projet, cette personne est responsable de ce compte.
La différence tient en une phrase : au lieu de stocker des documents qui parlent de vos clients, on stocke vos clients, et on garde la trace des documents qui les décrivent.
À partir de là, la question du comité devient un parcours. On part des contrats dont la date tombe dans le trimestre, on remonte au client, on redescend vers ses incidents, on garde ceux qui sont ouverts. Le chemin traverse trois systèmes d'origine sans que personne ait à les ouvrir.
En quoi est-ce différent d'un moteur de recherche documentaire ?
La comparaison la plus utile porte sur ce que chaque approche stocke, et donc sur ce qu'elle sait rendre.
| Recherche documentaire | Recherche sémantique seule | Graphe de connaissances | |
|---|---|---|---|
| Ce qui est stocké | Des fichiers et leurs mots | Des passages de texte et leur sens | Des objets métier et leurs relations |
| Question type | « Où est le contrat Dupont ? » | « Que dit-on de la garantie ? » | « Quels clients cumulent un contrat qui expire et un incident ouvert ? » |
| Croiser trois systèmes | Non | Non | Oui, par parcours de relations |
| Réponse rattachée à sa source | Le fichier trouvé | Le passage retrouvé | L'objet, et tous les documents qui le décrivent |
| Ce qui casse à l'usage | Les synonymes et le vocabulaire maison | Les questions qui demandent un calcul ou un croisement | Un modèle métier mal nommé au départ |
La troisième colonne ne remplace pas les deux premières, elle les contient. Omniscient fait les trois, et choisit selon ce que la question demande.
Pourquoi parle-t-on de RAG, et pourquoi ce n'est pas la même chose ?
Le terme RAG, pour génération augmentée par la recherche, désigne le fait de retrouver des passages de documents et de les donner à lire à un grand modèle de langage, souvent appelé LLM, avant qu'il ne rédige. C'est une brique utile, et la plateforme la met en oeuvre.
Elle ne suffit pas. Un RAG classique retrouve des passages qui ressemblent à la question. Si la réponse suppose de compter, de croiser deux listes ou de suivre une chaîne de responsabilités, aucun passage ne la contient, et le modèle comblera le vide par une formulation plausible. Le graphe est ce qui donne au modèle une réponse à rédiger plutôt qu'une réponse à inventer.
Ce que ça change concrètement
Les questions transversales deviennent possibles. Ce sont précisément celles qui comptent en pilotage, et celles qu'aucun outil ne sait traiter aujourd'hui dans la plupart des entreprises.
Les réponses sont vérifiables. Chaque objet du graphe conserve les documents dont il est issu. Une réponse renvoie donc à la source qui la justifie, et cette source s'ouvre en un clic. C'est ce qui sépare une information utilisable d'une affirmation qu'il faut croire sur parole.
La structure se découvre visuellement. On part d'une entité, on suit ses liens, on filtre par type d'objet ou de relation. Beaucoup de choses se voient ainsi avant même d'être demandées : un client rattaché à un projet que personne ne suivait, un fournisseur présent dans deux contrats sans lien apparent.
Comment le graphe se construit-il ?
Il ne se construit pas à la main. Vos sources existantes l'alimentent.
Un pipeline se dessine dans l'interface : on choisit une source, on décrit ce qu'on veut en tirer, on planifie la fréquence. Le moteur lit les fichiers, extrait les entités et les relations, dédoublonne, puis charge le résultat dans le graphe.
Les sources sont celles que vous avez déjà : dossiers de fichiers déposés, fichiers structurés au format CSV ou Excel, bases SQL, API REST, Google Drive, SharePoint, HubSpot, Notion. Les documents bureautiques sont lus en profondeur, PDF, Word, PowerPoint et Excel compris, y compris le texte contenu dans les images.
L'extraction des entités et des relations s'appuie sur un modèle de langage, guidé par vos propres catégories métier. Vous décidez de ce qui est un objet dans votre entreprise, le moteur s'en tient à cette définition.
Le modèle vous appartient
Un graphe utile ressemble à votre métier, pas à un modèle générique. Un cabinet de conseil, un industriel et un éditeur de logiciel n'ont pas les mêmes objets ni les mêmes liens.
Le modèle est donc ouvert : vous ajoutez vos types d'entités et vos types de relations sans développement. Ce qui est structurant chez vous le devient dans le graphe.
Que faut-il pour se lancer ?
Une mise en route réaliste suppose trois choses.
- Identifier les sources qui comptent. Rarement toutes, souvent trois ou quatre. Le graphe se construit par incréments, pas en une fois.
- Nommer les objets de votre métier. C'est le travail le plus structurant, et il se fait avec vos équipes, pas à leur place. Une heure de discussion vaut mieux qu'un modèle importé.
- Vérifier les premiers résultats. Une extraction se règle. Les premières passes servent à ajuster ce que le moteur considère comme une entité.
Rien de tout cela ne demande de compétence en science des données. C'est une raison pour laquelle l'approche convient à une PME ou à une ETI qui n'a pas d'équipe dédiée.
La suite
Le graphe n'est pas une fin en soi. C'est le socle sur lequel reposent les autres usages de la plateforme : l'assistant qui répond en français avec ses sources, les automatisations qui déclenchent des actions, les agents spécialisés par métier, et les modèles prédictifs qui apprennent la forme habituelle de votre entreprise pour signaler ce qui s'en écarte.
Tous lisent le même graphe et respectent le même modèle de droits. C'est ce qui évite d'empiler quatre outils qui ne savent rien les uns des autres. Et tous peuvent tourner sur votre propre infrastructure si vos données ne doivent pas sortir.
Pour voir le détail de chaque module, la page fonctionnalités les décrit un par un.