Le problème avec les explications habituelles
Quand on parle de Knowledge Graph (graphe de connaissance) à un DSI ou un directeur R&D, la conversation dure en général 4 minutes avant de se perdre dans des termes comme "ontologie", "triplet RDF" ou "inférence sémantique".
Ce n'est pas leur faute. Personne ne part de l'usage réel. Alors on va faire autrement.
Commençons par ce que vous connaissez déjà
Imaginez que vous cherchez, dans les archives de votre entreprise, la réponse à cette question :
"Quelles dérogations réglementaires ont été accordées sur ce type de composant, par quel organisme, dans quelles conditions ?"
Vous avez deux options.
Option A — La recherche documentaire classique. Vous tapez des mots-clés dans votre GED ou votre SharePoint. Vous obtenez une liste de documents. Vous ouvrez chacun. Vous lisez. Vous cherchez la dérogation. Vous vérifiez si elle correspond à votre composant. Vous notez. Vous recommencez. Résultat : 3 jours de travail pour un ingénieur expérimenté — et encore, si les documents de 2012 utilisaient un terme différent de ceux de 2019, certaines dérogations passeront à travers.
Option B — Une base de données classique. Vous avez une table "dérogations" avec des colonnes. Vous faites une requête SQL. Ça marche en 2 secondes. Problème : vos archives ne sont pas dans une base de données structurée. Elles sont dans des PDF, des Word, des emails, des rapports. Et personne ne les a ressaisies dans une table.
Le Knowledge Graph est la troisième option — celle qui n'existait pas vraiment avant.
Ce qu'est un graphe de connaissance
Un graphe de connaissance lit vos documents et en extrait des entités (un composant, un organisme, une dérogation, une condition) et des relations entre ces entités. Ce qu'il construit ressemble à ça :
[Dérogation D-142] —accordée par→ [DGAC] [Dérogation D-142] —porte sur→ [Composant C-SW-38B] [Dérogation D-142] —condition→ [Audit annuel requis] [Dérogation D-142] —date→ [14 mars 2017] [Dérogation D-142] —référence→ [Document REF-2017-0892, section 4.3]
Quand vous posez votre question en langage naturel, le système traduit votre question en une traversée de ce graphe. Il remonte les relations. Il trouve les réponses. Il cite ses sources — pas "d'après les documents disponibles", mais "selon le document REF-2017-0892, section 4.3, validé le 14 mars 2017 par la DGAC".
En quoi c'est différent d'un LLM (ChatGPT, Copilot, etc.)
Un LLM (modèle de langage) a appris à produire du texte plausible à partir de milliards de documents. Quand vous lui posez une question, il génère une réponse qui ressemble à ce que dirait quelqu'un de compétent sur le sujet. Le problème : il "remplit les trous". Sur des corpus réglementaires spécialisés, cette complétion est régulièrement incorrecte — et elle a l'air correcte. C'est ce qu'on appelle une hallucination.
Un graphe de connaissance ne "remplit" rien. Il traverse des relations qui ont été explicitement établies. Si la relation n'existe pas dans le graphe, il dit "aucun résultat trouvé" — pas "voici ma meilleure estimation".
| LLM généraliste | Knowledge Graph | |
|---|---|---|
| Source de la réponse | Statistiques d'apprentissage | Relations explicites dans les données |
| Traçabilité | « D'après les sources disponibles… » | Document source + section + date |
| Erreur possible | Oui, souvent indétectable | Non — absence de résultat si inconnu |
| Cohérence | Variable selon les sessions | Identique à chaque requête |
| Conformité GxP / ITAR | Non compatible structurellement | Compatible par construction |
Ce que le graphe ne fait pas
Il ne génère pas de texte. Il ne rédige pas de rapport. Il ne résume pas. Il répond à des requêtes structurées et cite ses sources. Pour la génération de texte, un LLM peut intervenir en aval — mais comme rédacteur d'un résultat déjà validé par le graphe, pas comme source de la réponse.
Il ne remplace pas l'expert. Il libère l'expert du travail de recherche documentaire pour qu'il puisse faire ce pour quoi il a été formé : analyser, décider, argumenter.
Il ne fonctionne pas sur n'importe quel corpus. Construire un graphe de connaissance demande de la modélisation (qu'est-ce qu'une entité ? quelles relations ?) et du travail d'ingestion. Ce n'est pas un "plug and play". C'est un projet d'infrastructure.
Ce que ça change concrètement
Voici trois questions types dans des environnements industriels réglementés, et ce que chaque approche produit.
Question 1 : "Quelles substances actives fongicides ont une restriction sur vigne mise à jour depuis le 1er janvier 2022 ?"
- RAG sur même corpus : 3 minutes, 2 erreurs sur 7 résultats (confusion entre substances proches)
- Graphe : 4 secondes, 0 erreur, source ANSES paragraphée pour chaque résultat
Question 2 : "Quels signaux de classe hépatotoxicité sévère sur notre molécule depuis 2020, croisés avec les publications EMA sur la même classe thérapeutique ?"
- RAG : résultat partiel, 3 signaux manquants (termes voisins dans des PSUR en 2 langues), aucune source primaire
- Graphe : 7 secondes, 0 signal manquant, référence PSUR + section + date de validation pour chaque résultat
Question 3 : "Tous les précédents de corrosion sous contrainte sur tuyauteries de catégorie 1 depuis 2015, par tranche, avec l'intervention réalisée et le résultat à 6 mois ?"
- Recherche documentaire classique : 3 semaines de travail estimées
- Graphe : 9 secondes, 14 précédents avec référence documentaire, tranche, date, intervention et statut
La question à se poser
Si votre organisation passe régulièrement plusieurs semaines à retrouver des informations qui ont déjà été produites — et que ces informations engagent la conformité réglementaire, la sécurité, ou la responsabilité juridique — alors la question n'est pas "est-ce qu'un Knowledge Graph peut nous aider ?"
La question est : "combien nous coûte de ne pas en avoir ?"