Knowledge Engineering
Comprendre/structurer/exploiter les connaissances

Comment créer un graphe de connaissances : méthode et exemple pratique

Créer un graphe de connaissances consiste à représenter des entités et les relations qui les unissent.

Exemple :

Marie → possède → Compétence SEO
Formation SEO intermédiaire → développe → Compétence SEO intermédiaire
Certification SEO → exige → Compétence SEO avancée

Contrairement à une simple liste ou à un tableau, le graphe permet de parcourir plusieurs relations.

Il peut répondre à des questions comme :

Un graphe utile n’est pas celui qui contient le plus de nœuds. C’est celui qui représente les relations nécessaires aux questions du système.

Ce guide présente une méthode indépendante d’un outil particulier.

Cas pratique

Nous allons créer un graphe capable de recommander un parcours de formation.

Le système devra relier :

Étape 1 — Définir les questions

Commencez par les requêtes attendues.

  1. Quelles compétences Marie possède-t-elle ?
  2. Quelle formation exige cette compétence ?
  3. Quelle formation développe le niveau suivant ?
  4. Quelle certification valide le niveau avancé ?
  5. Quelles sessions sont disponibles ?
  6. Qui anime chaque session ?
  7. Quelle source confirme le prérequis ?

Ces questions déterminent les entités et relations à représenter.

Étape 2 — Définir le périmètre

Le premier graphe couvrira uniquement :

Il ne couvrira pas encore :

Un périmètre limité facilite les tests.

Étape 3 — Identifier les types de nœuds

Les nœuds représentent les entités.

Pour notre projet :

Participant
Competence
Formation
Certification
Session
Formateur
Document

Chaque type doit être défini.

Participant

Personne susceptible de suivre une formation.

Compétence

Capacité possédée ou développée.

Formation

Programme pédagogique visant une ou plusieurs compétences.

Session

Mise en œuvre datée d’une formation.

Certification

Dispositif validant une compétence ou un niveau.

Document

Source justifiant une information.

Étape 4 — Définir les relations

Les relations doivent être précises.

Participant → POSSEDE → Competence
Formation → DEVELOPPE → Competence
Formation → EXIGE → Competence
Certification → VALIDE → Competence
Session → MET_EN_OEUVRE → Formation
Formateur → ANIME → Session
Relation → JUSTIFIEE_PAR → Document

Évitez une relation générique comme :

EST_LIE_A

Elle n’indique pas la nature du lien.

Étape 5 — Construire un dictionnaire du graphe

Documentez les nœuds.

TypeIdentifiantPropriétés principales
Participantparticipant_idnom, email
Compétencecompetence_idlibellé, niveau
Formationformation_idtitre, durée
Sessionsession_iddate, capacité
Certificationcertification_idtitre, organisme
Formateurformateur_idnom
Documentdocument_idtitre, version, date

Documentez également les relations.

RelationSujetObjetSignification
POSSEDEParticipantCompétenceCompétence détenue
DEVELOPPEFormationCompétenceCompétence visée
EXIGEFormationCompétencePrérequis
VALIDECertificationCompétenceCompétence certifiée
ANIMEFormateurSessionAnimation d’une session
MET_EN_OEUVRESessionFormationFormation réalisée

Ce dictionnaire joue le rôle d’un schéma ou d’une ontologie légère.

Étape 6 — Choisir les identifiants

Chaque entité doit posséder un identifiant stable.

Exemples :

participant:marie-dupont
competence:seo-debutant
formation:seo-intermediaire
session:seo-intermediaire-2026-10

Évitez d’utiliser uniquement le nom affiché.

Deux personnes peuvent porter le même nom.

Deux formations peuvent posséder des titres proches.

Étape 7 — Préparer les données

Un tableur peut suffire pour préparer le premier import.

Participants

participant_idnom
P001Marie Dupont
P002Jacques Martin

Compétences

competence_idlibelléniveau
C001SEODébutant
C002SEOIntermédiaire
C003SEOAvancé

Formations

formation_idtitredurée
F001Formation SEO intermédiaire14
F002Formation SEO avancée21

Relations

sujetrelationobjet
P001POSSEDEC001
F001EXIGEC001
F001DEVELOPPEC002
F002EXIGEC002
F002DEVELOPPEC003

Cette structure en triplets est facilement transformable en graphe.

Étape 8 — Créer les premiers nœuds

Représentation conceptuelle :

(:Participant {
  id: "P001",
  nom: "Marie Dupont"
})
(:Competence {
  id: "C001",
  domaine: "SEO",
  niveau: "Débutant"
})
(:Formation {
  id: "F001",
  titre: "Formation SEO intermédiaire",
  dureeHeures: 14
})

La syntaxe exacte dépend de la technologie choisie.

Étape 9 — Créer les relations

Marie
  → POSSEDE
  → Compétence SEO débutant
Formation SEO intermédiaire
  → EXIGE
  → Compétence SEO débutant
Formation SEO intermédiaire
  → DEVELOPPE
  → Compétence SEO intermédiaire
Formation SEO avancée
  → EXIGE
  → Compétence SEO intermédiaire
Formation SEO avancée
  → DEVELOPPE
  → Compétence SEO avancée

Le graphe forme désormais un parcours.

Étape 10 — Ajouter des propriétés aux relations

Une relation peut posséder son propre contexte.

Exemple :

Marie → POSSEDE → Compétence SEO débutant

Propriétés :

dateValidation : 2026-04-12
source : Evaluation 458
statut : Validé

Autre exemple :

Formation SEO avancée → EXIGE → Compétence SEO intermédiaire

Propriétés :

obligatoire : true
version : 2.1
dateEffet : 2026-01-01

Les propriétés permettent de représenter le temps et la provenance.

Étape 11 — Ajouter les documents sources

Créez des nœuds Document.

CatalogueFormation2026
ReglementPedagogique2026
EvaluationMarie458

Relations :

Formation SEO avancée
  → DECRITE_DANS
  → CatalogueFormation2026
Prérequis intermédiaire
  → JUSTIFIE_PAR
  → ReglementPedagogique2026
Compétence SEO débutant de Marie
  → VALIDEE_PAR
  → EvaluationMarie458

Le graphe devient traçable.

Étape 12 — Représenter le temps

Une relation peut cesser d’être vraie.

Exemple :

Paul → ANIME → Session SEO octobre

Cette relation concerne une session précise.

Pour un emploi :

Marie → TRAVAILLE_POUR → Entreprise Alpha

ajoutez :

dateDebut
dateFin
statut

Sans dimension temporelle, le système pourrait présenter une ancienne relation comme actuelle.

Étape 13 — Résoudre les identités

Une même entité peut apparaître sous plusieurs formes :

Marie Dupont
M. Dupont
Marie D.

Le système doit déterminer s’il s’agit de la même personne.

Utilisez plusieurs critères :

Exemple de problème

Marie Dupont

peut désigner deux personnes différentes.

Fusionner automatiquement les deux créerait de fausses relations.

Table de correspondance

MentionEntité résolueConfiance
Marie D.P0010,90
Mme DupontNon résolu0,45
marie@example.frP0011,00

Les cas ambigus doivent être examinés ou conservés comme non résolus.

Étape 14 — Détecter les doublons

Doublons possibles :

Formation SEO avancée
Formation avancée SEO
SEO avancé

Avant la fusion, vérifiez :

Deux noms proches ne désignent pas nécessairement le même contenu.

Étape 15 — Définir les contraintes

Exemples :

Un participant doit posséder un identifiant unique.
Une session met en œuvre exactement une formation.
Une formation développe au moins une compétence.
Une relation EXIGE relie une formation à une compétence.

Les contraintes peuvent être appliquées :

Étape 16 — Interroger le graphe

Question 1

Quelles compétences Marie possède-t-elle ?

Motif :

Marie
  → POSSEDE
  → Competence

Question 2

Quelles formations Marie peut-elle suivre ?

Motif :

Marie
  → POSSEDE
  → Competence
  ← EXIGE
  ← Formation

Question 3

Quel parcours conduit à la certification ?

Motif :

Participant
  → POSSEDE
  → Competence
  ← EXIGE
  ← Formation
  → DEVELOPPE
  → Competence suivante
  ← VALIDE
  ← Certification

Le graphe peut suivre plusieurs étapes.

Exemple conceptuel en Cypher

MATCH (p:Participant {id: "P001"})-[:POSSEDE]->(c:Competence)
MATCH (f:Formation)-[:EXIGE]->(c)
RETURN p.nom, f.titre

Cette requête cherche les formations dont Marie possède déjà le prérequis.

Requête de parcours

MATCH path =
  (p:Participant {id: "P001"})
  -[:POSSEDE]->
  (:Competence)
  <-[:EXIGE]-
  (:Formation)
  -[:DEVELOPPE]->
  (:Competence)
RETURN path

La syntaxe doit être adaptée au modèle technique et à la version du moteur utilisé.

Étape 17 — Produire une réponse explicable

Le système ne doit pas seulement retourner le nom d’une formation.

Il peut afficher :

Formation recommandée :
Formation SEO intermédiaire.

Pourquoi ?
- Marie possède la compétence SEO débutant.
- Cette compétence est le prérequis de la formation intermédiaire.
- La formation intermédiaire développe le niveau nécessaire à la formation avancée.

Sources :
- Évaluation 458.
- Catalogue des formations 2026.
- Règlement pédagogique 2.1.

Le chemin du graphe fournit l’explication.

Étape 18 — Tester la qualité

Test de nœuds

Les entités possèdent-elles les bons types ?

Test de relations

Les relations sont-elles exactes ?

Test d’identité

Les doublons sont-ils correctement traités ?

Test de provenance

Chaque relation critique possède-t-elle une source ?

Test temporel

Les relations anciennes sont-elles identifiées ?

Test de parcours

Le système retrouve-t-il le chemin attendu ?

Test d’absence

Le système distingue-t-il :

Exemple de jeu de tests

QuestionRésultat attendu
Que possède Marie ?SEO débutant
Quelle formation peut-elle suivre ?SEO intermédiaire
Quelle formation ne peut-elle pas encore suivre ?SEO avancée
Pourquoi ?Niveau intermédiaire manquant
Quelle source valide son niveau ?Évaluation 458

Étape 19 — Relier le graphe aux documents

Le graphe fournit la structure.

Les documents fournissent les explications détaillées.

Architecture :

Question
  ↓
Recherche dans le graphe
  ↓
Identification des entités et relations
  ↓
Récupération des documents sources
  ↓
LLM
  ↓
Réponse expliquée

Cette combinaison constitue une forme de GraphRAG.

Étape 20 — Organiser la mise à jour

Définissez comment traiter :

Exemple de changement

Ancienne règle :

Formation avancée exige le niveau débutant.

Nouvelle règle :

Formation avancée exige le niveau intermédiaire.

Ne remplacez pas nécessairement la relation sans historique.

Conservez :

Quelle technologie choisir ?

Fichiers ou tableurs

Adaptés à :

RDF

Adapté à :

Base graphe de propriétés

Adaptée à :

Base SQL avec tables de relations

Possible lorsque :

L’outil doit être choisi après les questions et le modèle.

Architecture minimale

Tableur des entités
+
Tableur des relations
+
Identifiants stables
+
Jeu de requêtes
+
Tests

Architecture avancée

Documents
+
Pipeline d’extraction
+
Ontologie
+
Graphe
+
Index vectoriel
+
Moteur de règles
+
LLM
+
Évaluation

Erreurs fréquentes

Créer le graphe avant les questions

Le modèle contient de nombreuses relations inutiles.

Transformer chaque mot en nœud

Seules les entités utiles doivent être représentées.

Utiliser EST_LIE_A

La relation ne fournit pas assez de sens.

Ne pas définir d’identifiants

Les doublons deviennent difficiles à gérer.

Fusionner selon le nom uniquement

Les homonymes sont confondus.

Oublier les sources

Les relations ne peuvent plus être vérifiées.

Oublier les dates

Les anciennes connaissances apparaissent comme actuelles.

Laisser un LLM valider ses propres extractions

Le contrôle doit utiliser des règles, des sources ou une validation humaine.

Ne pas comparer avec une solution simple

Un tableau ou une base SQL peut parfois suffire.

Checklist finale

À retenir

  1. Un graphe de connaissances commence par des questions.
  2. Les nœuds représentent les entités.
  3. Les relations doivent être précises.
  4. Les identifiants doivent être stables.
  5. Le dictionnaire du graphe documente le modèle.
  6. Les propriétés ajoutent le contexte.
  7. La provenance permet de vérifier les connaissances.
  8. Les dates évitent d’utiliser des relations obsolètes.
  9. La résolution d’entités constitue une étape critique.
  10. Les contraintes améliorent la cohérence.
  11. Les chemins du graphe peuvent expliquer une recommandation.
  12. Le graphe doit être étendu progressivement.

Continuer

Comprendre les graphes de connaissances

Comparer une ontologie et un graphe de connaissances

Découvrir GraphRAG