Méthode d’ingénierie des connaissances : comment mener un projet de Knowledge Engineering ?

Un projet d’ingénierie des connaissances ne commence pas par le choix d’un logiciel, d’un modèle de langage ou d’une base de données.

Il commence par un problème précis.

Le système doit-il :

• répondre à des questions ;
• recommander une action ;
• vérifier une conformité ;
• diagnostiquer une panne ;
• organiser des documents ;
• transmettre une expertise ;
• alimenter un LLM ;
• construire un graphe de connaissances ?

La méthode consiste ensuite à identifier les connaissances nécessaires, à les recueillir, à les représenter, à les tester et à les maintenir.

Un bon projet de Knowledge Engineering part des décisions et des questions à traiter, pas des technologies disponibles.

Ce que vous allez comprendre

À la fin de cet article, vous saurez :

• cadrer un projet d’ingénierie des connaissances ;
• définir des questions de compétence ;
• identifier les sources et les experts ;
• choisir une forme de représentation ;
• construire un premier modèle ;
• tester la qualité des connaissances ;
• organiser la gouvernance et la maintenance ;
• éviter les principales causes d’échec.

Vue d’ensemble de la méthode

1. Définir le problème
2. Identifier les utilisateurs
3. Formuler les questions
4. Définir le périmètre
5. Recenser les sources
6. Acquérir les connaissances
7. Construire le vocabulaire
8. Modéliser
9. Implémenter
10. Tester
11. Valider
12. Déployer
13. Maintenir
14. Mesurer et améliorer

Le processus n’est pas entièrement linéaire.

Les tests peuvent révéler :

• un concept manquant ;
• une règle incorrecte ;
• une source insuffisante ;
• une ambiguïté ;
• un besoin mal défini.

Le projet doit donc fonctionner par itérations.

Étape 1 — Définir le problème

Le problème doit être formulé de manière opérationnelle.

Formulation trop vague

Améliorer la gestion des connaissances.

Formulation plus précise

Permettre aux techniciens de retrouver la procédure applicable à un incident réseau en moins de deux minutes.

Autre exemple :

Déterminer si un participant possède les prérequis nécessaires pour une formation.

Une bonne définition précise :

• la situation ;
• l’utilisateur ;
• la décision ;
• le résultat attendu ;
• le niveau de qualité ;
• les limites.

Étape 2 — Identifier les utilisateurs

Les utilisateurs peuvent être :

• experts ;
• débutants ;
• clients ;
• techniciens ;
• juristes ;
• commerciaux ;
• responsables qualité ;
• développeurs ;
• agents IA.

Leurs besoins diffèrent.

Un expert peut vouloir :

• une réponse détaillée ;
• les sources ;
• les exceptions ;
• le raisonnement complet.

Un client peut vouloir :

• une réponse simple ;
• une procédure courte ;
• une orientation claire.

Étape 3 — Définir les décisions et actions

Le système doit-il :

• classer ;
• recommander ;
• expliquer ;
• comparer ;
• alerter ;
• vérifier ;
• rechercher ;
• résumer ;
• diagnostiquer ?

Cette étape évite de construire une base de connaissances sans usage réel.

Étape 4 — Formuler les questions de compétence

Les questions de compétence décrivent ce que le système devra savoir traiter.

Exemple pour la formation :

• quelles compétences possède ce participant ?
• quel niveau est requis ?
• quelle formation développe le niveau manquant ?
• quelle certification valide cette compétence ?
• quelles sessions sont disponibles ?

Exemple pour le support :

• quel produit est concerné ?
• quels symptômes sont observés ?
• quelles causes sont possibles ?
• quel test doit être effectué ?
• quelle procédure est applicable ?
• quand faut-il transmettre au niveau supérieur ?

Les questions servent à :

• définir le périmètre ;
• identifier les concepts ;
• tester la couverture ;
• évaluer le système.

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

Un projet ne doit pas chercher à représenter tout un domaine.

Exemple :

Un assistant de support consacré aux routeurs n’a pas nécessairement besoin de représenter :

• la comptabilité ;
• tous les produits ;
• toutes les équipes ;
• toute l’histoire de l’entreprise.

Le périmètre doit préciser :

• les produits ;
• les utilisateurs ;
• les pays ;
• les types de décisions ;
• les dates ;
• les sources ;
• les exclusions.

Étape 6 — Identifier les parties prenantes

Les parties prenantes peuvent inclure :

Partie prenante	Rôle
Expert métier	Fournir et valider les connaissances
Knowledge Engineer	Structurer le modèle
Utilisateur	Définir les besoins réels
Développeur	Implémenter le système
Responsable qualité	Contrôler les processus
Responsable sécurité	Gérer les accès
Direction	Définir les priorités
Responsable documentaire	Maintenir les sources

Étape 7 — Recenser les sources

Les sources peuvent être :

• experts ;
• procédures ;
• bases de données ;
• rapports ;
• contrats ;
• normes ;
• historiques ;
• observations ;
• logiciels existants ;
• pages web ;
• API.

Pour chaque source, il faut évaluer :

• l’autorité ;
• la date ;
• la couverture ;
• la qualité ;
• le niveau de confidentialité ;
• la fréquence de mise à jour.

Matrice des sources

Source	Fiabilité	Fraîcheur	Couverture	Accès
Procédure officielle	Élevée	Variable	Partielle	Interne
Expert principal	Élevée	Actuelle	Contextuelle	Disponible
Historique des incidents	Moyenne	Actuelle	Large	Restreint
Ancienne documentation	Faible	Ancienne	Large	Libre

Cette matrice aide à prioriser.

Étape 8 — Acquérir les connaissances

L’acquisition des connaissances peut utiliser :

• entretiens ;
• observation ;
• analyse documentaire ;
• ateliers ;
• cartes conceptuelles ;
• questionnaires ;
• scénarios ;
• analyse des décisions historiques ;
• extraction automatique.

Il faut recueillir :

• les concepts ;
• les relations ;
• les règles ;
• les exceptions ;
• les critères ;
• les sources ;
• les niveaux de confiance.

Étape 9 — Recueillir des cas réels

Les cas concrets permettent d’éviter les modèles trop théoriques.

Il faut sélectionner :

• cas fréquents ;
• cas critiques ;
• cas limites ;
• erreurs passées ;
• exceptions ;
• désaccords ;
• situations nouvelles.

Pour chaque cas :

Situation
Informations disponibles
Décision prise
Règle utilisée
Exception éventuelle
Résultat

Étape 10 — Construire le vocabulaire

Le vocabulaire doit définir :

• les termes principaux ;
• les synonymes ;
• les acronymes ;
• les homonymes ;
• les traductions ;
• les termes interdits ou obsolètes.

Exemple :

Terme principal :
Graphe de connaissances

Synonyme :
Knowledge graph

Définition :
Structure représentant des entités et leurs relations.

Étape 11 — Définir les concepts

Chaque concept doit posséder une définition.

Exemple :

Concept :
Session de formation

Définition :
Événement daté mettant en œuvre une formation pour un groupe de participants.

Cette définition distingue la session du programme de formation.

Étape 12 — Construire une taxonomie

La taxonomie organise les concepts.

Personne
├── Participant
├── Formateur
└── Administrateur

Ressource pédagogique
├── Formation
├── Certification
└── Évaluation

La taxonomie constitue souvent la première version du modèle.

Étape 13 — Définir les relations

Exemples :

Participant → possède → Compétence

Formation → développe → Compétence

Session → met en œuvre → Formation

Formateur → anime → Session

Chaque relation doit être définie.

Fiche de relation

Nom :
développe

Sujet :
Formation

Objet :
Compétence

Définition :
Indique qu’une formation vise l’acquisition ou l’amélioration d’une compétence.

Étape 14 — Formaliser les règles

Exemple :

SI le participant possède le niveau requis
ALORS il peut s’inscrire à la formation.

Une règle doit préciser :

• les conditions ;
• la conclusion ;
• la source ;
• le périmètre ;
• les exceptions ;
• la priorité ;
• la date de validité.

Étape 15 — Identifier les contraintes

Exemples :

Une session doit correspondre à exactement une formation.

Une formation doit développer au moins une compétence.

Une date de fin doit être postérieure à la date de début.

Les contraintes permettent de contrôler la cohérence.

Étape 16 — Choisir la représentation

Le choix dépend du besoin.

Besoin	Représentation
Classer des contenus	Taxonomie
Gérer des synonymes	Thésaurus
Définir les concepts	Ontologie
Relier des entités	Graphe
Appliquer des décisions	Règles
Rechercher des textes	Index vectoriel
Répondre avec un LLM	RAG
Relier plusieurs sources	GraphRAG
Combiner plusieurs besoins	Architecture hybride

Étape 17 — Construire un modèle minimal

Il est préférable de commencer petit.

Exemple :

4 types d’entités
6 relations
10 règles
20 cas de test

Le modèle minimal doit déjà répondre à une question utile.

Cette approche réduit le risque de surmodélisation.

Étape 18 — Choisir les outils

Le choix des outils intervient après le modèle.

Les familles possibles comprennent :

• éditeur Markdown ;
• tableur ;
• outil de taxonomie ;
• éditeur d’ontologie ;
• base SQL ;
• base graphe ;
• moteur de règles ;
• moteur de recherche ;
• base vectorielle ;
• LLM.

La page Outils de Knowledge Engineering présente ces options.

Étape 19 — Implémenter

L’implémentation peut comprendre :

• création des tables ;
• import des documents ;
• construction de l’ontologie ;
• création du graphe ;
• ajout des règles ;
• indexation vectorielle ;
• connexion au LLM ;
• création de l’interface.

Étape 20 — Conserver la provenance

Chaque connaissance importante doit être accompagnée de :

Source
Date
Version
Auteur
Statut
Périmètre
Niveau de confiance

Exemple :

Règle :
Un incident sans solution de contournement est critique.

Source :
Procédure support 4.2.

Statut :
Validée.

Date :
12 juillet 2026.

Étape 21 — Construire les tests

Les tests doivent être définis avant le déploiement.

Tests de couverture

Le système répond-il aux questions prévues ?

Tests d’exactitude

Les réponses sont-elles correctes ?

Tests d’exceptions

Les cas particuliers sont-ils traités ?

Tests de contradiction

Le système détecte-t-il les sources incompatibles ?

Tests de fraîcheur

Les anciennes versions sont-elles exclues ?

Tests de refus

Le système sait-il signaler qu’il ne sait pas ?

Tests de sécurité

Les droits d’accès sont-ils respectés ?

Étape 22 — Valider avec les experts

La validation doit porter sur :

• définitions ;
• relations ;
• règles ;
• exceptions ;
• conclusions ;
• sources ;
• explications.

Les experts ne doivent pas seulement valider le modèle abstrait.

Ils doivent tester des cas réels.

Étape 23 — Tester avec les utilisateurs

Les utilisateurs doivent vérifier :

• la compréhension des réponses ;
• la vitesse ;
• la pertinence ;
• la navigation ;
• le niveau de détail ;
• les explications ;
• la facilité de correction.

Un modèle techniquement correct peut rester inutilisable.

Étape 24 — Définir les indicateurs

Exemples :

• taux de réponses correctes ;
• taux de questions sans réponse ;
• temps moyen de recherche ;
• nombre d’erreurs signalées ;
• couverture des cas prioritaires ;
• fraîcheur des sources ;
• taux d’utilisation ;
• satisfaction des utilisateurs.

Étape 25 — Déployer progressivement

Un déploiement progressif peut suivre :

Prototype
  ↓
Test expert
  ↓
Pilote limité
  ↓
Déploiement à un service
  ↓
Extension

Cette approche réduit les risques.

Étape 26 — Organiser la gouvernance

La gouvernance définit :

• qui propose ;
• qui valide ;
• qui publie ;
• qui corrige ;
• qui archive ;
• qui gère les accès ;
• qui arbitre les désaccords.

Cycle de vie

Proposée
  ↓
À valider
  ↓
Validée
  ↓
Publiée
  ↓
À réviser
  ↓
Obsolète

Étape 27 — Maintenir les connaissances

Les connaissances évoluent.

La maintenance peut être déclenchée par :

• une nouvelle réglementation ;
• une modification de produit ;
• une procédure mise à jour ;
• une erreur ;
• un retour utilisateur ;
• un nouveau cas ;
• un changement organisationnel.

Étape 28 — Gérer les versions

Il faut savoir :

• quelle version est active ;
• quand elle a été publiée ;
• quelles règles ont changé ;
• quelles pages ou systèmes sont affectés ;
• comment revenir à une version antérieure.

Étape 29 — Améliorer par boucles

Une boucle d’amélioration peut être :

Utilisation
  ↓
Erreur ou manque détecté
  ↓
Analyse
  ↓
Modification de la connaissance
  ↓
Validation
  ↓
Nouveau test
  ↓
Publication

Exemple complet : assistant de support

Problème

Les techniciens mettent trop de temps à retrouver les procédures.

Utilisateurs

• techniciens débutants ;
• techniciens confirmés ;
• responsables support.

Questions

• quelle procédure s’applique ?
• quelle cause est probable ?
• quel test effectuer ?
• quand transmettre au niveau supérieur ?

Sources

• manuels ;
• incidents historiques ;
• entretiens ;
• procédures ;
• fiches produits.

Concepts

Produit
Incident
Symptôme
Cause
Test
Procédure
Solution
Technicien

Relations

Incident → concerne → Produit

Symptôme → peut indiquer → Cause

Test → vérifie → Cause

Procédure → traite → Cause

Règles

SI voyant rouge
ET connexion absente
ALORS vérifier la synchronisation.

Architecture

Documents
  +
Graphe
  +
Règles
  +
LLM

Tests

• incident simple ;
• incident critique ;
• produit obsolète ;
• procédure contradictoire ;
• absence de source ;
• utilisateur non autorisé.

Indicateur

Temps moyen nécessaire pour identifier la bonne procédure.

Exemple complet : recommandation de formation

Problème

Proposer un parcours adapté aux compétences du participant.

Concepts

Participant
Compétence
Niveau
Formation
Prérequis
Certification

Relations

Participant → possède → Compétence

Formation → développe → Compétence

Formation → exige → Prérequis

Règle

SI le participant ne possède pas le niveau requis
ALORS recommander une formation préparatoire.

Test

Marie possède le niveau débutant.
La formation avancée exige le niveau intermédiaire.

Résultat attendu :

Recommander la formation intermédiaire.

Les principaux risques

Surmodélisation

Construire un modèle trop vaste avant de tester son utilité.

Sous-modélisation

Créer une simple liste de documents alors que des règles sont nécessaires.

Dépendance à un seul expert

Le modèle reproduit ses biais ou ses habitudes personnelles.

Sources obsolètes

Les anciennes connaissances restent actives.

Absence de gouvernance

Personne ne sait qui doit corriger ou valider.

Automatisation excessive

Le système prend des décisions sans contrôle adapté.

Confusion entre performance du LLM et qualité des connaissances

Un meilleur modèle ne corrige pas une mauvaise base.

Principes de réussite

1. Commencer par un problème précis.
2. Définir les questions attendues.
3. Construire un modèle minimal.
4. Utiliser des cas réels.
5. Conserver les sources.
6. Valider avec plusieurs experts.
7. Tester les exceptions.
8. Comparer les solutions simples et complexes.
9. Déployer progressivement.
10. Organiser la maintenance dès le début.

À retenir

1. Un projet de Knowledge Engineering commence par un besoin, pas par un outil.
2. Les questions de compétence définissent ce que le système doit savoir traiter.
3. Le périmètre doit rester limité.
4. Les sources doivent être évaluées.
5. L’acquisition combine experts, documents, données et observation.
6. Le vocabulaire précède la modélisation.
7. Le choix entre taxonomie, ontologie, graphe ou règles dépend de l’usage.
8. Un modèle minimal doit être testé rapidement.
9. La provenance est indispensable.
10. Les tests doivent couvrir les cas fréquents, critiques et exceptionnels.
11. La gouvernance définit les responsabilités.
12. La maintenance fait partie du projet dès le départ.

Vérifiez votre compréhension

Quelle est la première étape d’un projet ?

Définir précisément le problème et la décision à soutenir.

À quoi servent les questions de compétence ?

À délimiter le système et à vérifier qu’il répond aux besoins.

Pourquoi commencer par un modèle minimal ?

Pour tester rapidement la valeur du projet et éviter la surmodélisation.

Pourquoi conserver les sources ?

Pour vérifier, expliquer et mettre à jour les connaissances.

Pourquoi tester les exceptions ?

Parce qu’une règle générale peut produire des erreurs dans des situations particulières.

Pourquoi la maintenance doit-elle être prévue dès le début ?

Parce que les connaissances, procédures et règles évoluent.

Questions fréquentes

Combien de temps dure un projet ?

La durée dépend du périmètre. Un prototype ciblé peut être réalisé rapidement, tandis qu’un système d’entreprise peut nécessiter plusieurs itérations.

Faut-il commencer par une ontologie ?

Non. Une taxonomie, un tableau ou une base documentaire enrichie peut suffire pour un premier prototype.

Combien d’experts faut-il consulter ?

Il faut couvrir les principales pratiques et responsabilités. Plusieurs points de vue sont préférables lorsqu’ils existent.

Peut-on automatiser l’acquisition ?

Partiellement. Les LLM et outils d’extraction peuvent proposer des connaissances, mais la validation reste nécessaire.

Comment savoir si le projet est réussi ?

Le système doit améliorer une décision, une recherche ou une tâche mesurable.

Quelle est l’erreur la plus fréquente ?

Construire une solution techniquement complexe sans problème précis ni gouvernance.

Continuer le parcours

Étape précédente

GraphRAG : fonctionnement et cas d’usage

Étape suivante

La prochaine étape consiste à découvrir les outils et standards utilisés pour implémenter ces méthodes.

➡️ Outils de Knowledge Engineering : technologies et usages

Revenir au sommaire

Voir le parcours complet de Knowledge Engineering