Knowledge Engineer : quel est le rôle d’un ingénieur des connaissances ?

Le Knowledge Engineer, ou ingénieur des connaissances, transforme l’expertise d’un domaine en modèles, règles et structures exploitables par des systèmes informatiques.

Il intervient entre plusieurs mondes :

• les experts métier ;
• les documents ;
• les données ;
• les équipes techniques ;
• les utilisateurs ;
• les systèmes d’intelligence artificielle.

Son travail ne consiste pas uniquement à installer une base de données ou à écrire des prompts.

Il doit comprendre :

• ce que les professionnels savent ;
• comment ils utilisent leurs connaissances ;
• quelles décisions doivent être assistées ;
• quels concepts structurent le domaine ;
• quelles règles et exceptions doivent être représentées ;
• comment le système sera validé et maintenu.

Le Knowledge Engineer construit le passage entre l’expertise humaine et les systèmes capables de l’exploiter.

Ce que vous allez comprendre

À la fin de cet article, vous saurez :

• définir le métier de Knowledge Engineer ;
• comprendre ses principales missions ;
• distinguer son rôle de ceux du data engineer, du développeur et du knowledge manager ;
• identifier ses compétences techniques et relationnelles ;
• comprendre son travail avec les LLM et le RAG ;
• découvrir le déroulement d’un projet ;
• construire un parcours d’apprentissage vers ce métier.

Quelle est la mission principale ?

La mission centrale consiste à rendre les connaissances :

• explicites ;
• structurées ;
• cohérentes ;
• interrogeables ;
• traçables ;
• validées ;
• maintenables ;
• utilisables par un système.

Cette mission peut produire :

• un glossaire ;
• une taxonomie ;
• une ontologie ;
• une base de connaissances ;
• un graphe ;
• un système de règles ;
• un assistant RAG ;
• une architecture GraphRAG ;
• une documentation métier structurée.

Le Knowledge Engineer comme intermédiaire

Un expert peut dire :

Quand la machine chauffe après un changement de série, je vérifie d’abord le réglage avant de suspecter la mécanique.

Le Knowledge Engineer doit transformer cette déclaration.

Concepts

Machine
Température
Changement de série
Réglage
Panne mécanique

Relation temporelle

Changement de série → précède → Augmentation de température

Règle

SI la température augmente après un changement de série
ALORS vérifier le réglage avant la mécanique.

Source

Expert maintenance

Validation

À confirmer sur les incidents historiques.

Le travail consiste donc à préserver le sens tout en rendant la connaissance exploitable.

Les principales missions

1. Cadrer le problème

Le Knowledge Engineer aide à définir :

• l’utilisateur ;
• le besoin ;
• la décision ;
• le périmètre ;
• le niveau d’automatisation ;
• les risques ;
• les critères de réussite.

Il évite les objectifs vagues comme :

Créer une intelligence artificielle qui connaît toute l’entreprise.

Il cherche une formulation testable :

Permettre aux techniciens d’identifier la bonne procédure pour les dix incidents les plus fréquents.

2. Identifier les sources de connaissances

Il recense :

• experts ;
• documents ;
• bases de données ;
• procédures ;
• historiques ;
• normes ;
• logiciels ;
• API ;
• retours utilisateurs.

Il évalue :

• la fiabilité ;
• la fraîcheur ;
• la couverture ;
• l’autorité ;
• les droits d’accès.

3. Conduire les entretiens

Le Knowledge Engineer interroge les experts.

Il ne demande pas seulement :

Comment travaillez-vous ?

Il demande plutôt :

• décrivez le dernier cas difficile ;
• quelles informations avez-vous vérifiées ?
• quelles hypothèses avez-vous rejetées ?
• quelle exception a modifié votre décision ?
• qu’aurait fait un débutant ?
• quelle erreur vouliez-vous éviter ?

Ces questions permettent d’extraire la connaissance tacite.

4. Observer les pratiques

La procédure officielle et le travail réel peuvent être différents.

L’observation permet d’identifier :

• les étapes oubliées ;
• les vérifications informelles ;
• les adaptations ;
• les outils utilisés ;
• les interactions ;
• les signaux faibles.

5. Analyser les documents

Il recherche :

• les termes ;
• les règles ;
• les versions ;
• les contradictions ;
• les exceptions ;
• les sources ;
• les responsabilités ;
• les dates.

L’analyse peut être manuelle ou assistée par des outils d’extraction.

6. Construire le vocabulaire

Le Knowledge Engineer définit :

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

Exemple :

Terme principal :
Graphe de connaissances

Synonyme :
Knowledge graph

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

7. Construire une taxonomie

Il organise les concepts.

Incident
├── Incident réseau
├── Incident matériel
├── Incident logiciel
└── Incident de sécurité

La taxonomie permet de classer et de naviguer.

8. Concevoir une ontologie

Lorsque le projet l’exige, il définit :

• les classes ;
• les instances ;
• les propriétés ;
• les relations ;
• les contraintes ;
• les axiomes.

Exemple :

Incident → concerne → Produit

Symptôme → peut indiquer → Cause

Procédure → traite → Cause

Cette activité relève de l’ontologie informatique.

9. Construire un graphe de connaissances

Il organise les entités concrètes.

Incident 458 → concerne → Routeur X200

Incident 458 → présente → Voyant rouge

Voyant rouge → peut indiquer → Perte de synchronisation

Il doit notamment gérer :

• les identités ;
• les doublons ;
• les dates ;
• les sources ;
• les niveaux de confiance.

10. Formaliser les règles

Il transforme une expertise en règles testables.

SI le participant possède le niveau requis
ALORS il est éligible à la formation.

Il doit préciser :

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

11. Définir les questions de compétence

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

Exemples :

• quelle procédure s’applique à ce produit ?
• quelle formation développe cette compétence ?
• quelle règle justifie cette décision ?
• quel contrat couvre cet incident ?
• quelles sources sont encore valides ?

Elles servent à construire et tester le modèle.

12. Collaborer avec les équipes techniques

Le Knowledge Engineer travaille avec :

• développeurs ;
• data engineers ;
• architectes ;
• spécialistes IA ;
• administrateurs ;
• experts sécurité ;
• designers d’interface.

Il traduit les besoins métier en structures implémentables.

13. Tester les connaissances

Il construit des cas de test :

• cas fréquent ;
• cas critique ;
• cas limite ;
• exception ;
• contradiction ;
• absence de donnée ;
• source obsolète.

14. Organiser la validation

Les experts doivent vérifier :

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

15. Organiser la gouvernance

Le Knowledge Engineer aide à définir :

• qui propose une connaissance ;
• qui la valide ;
• qui la publie ;
• qui la corrige ;
• qui la retire ;
• qui gère les droits.

16. Maintenir le système

Les connaissances évoluent.

Il faut gérer :

• les versions ;
• les changements ;
• les corrections ;
• les nouvelles règles ;
• les connaissances obsolètes ;
• les nouveaux cas.

Knowledge Engineer et Knowledge Manager

Les deux rôles sont proches mais différents.

Knowledge Engineer	Knowledge Manager
Formalise les connaissances	Organise leur partage
Construit des modèles	Anime les processus
Travaille sur concepts et règles	Travaille sur communautés et documents
Conçoit ontologies et graphes	Facilite la circulation du savoir
Intègre les connaissances aux systèmes	Développe les pratiques collaboratives
Vise l’exploitation informatique	Vise l’efficacité organisationnelle

Les deux rôles peuvent collaborer.

Knowledge Engineer et Data Engineer

Knowledge Engineer	Data Engineer
Travaille sur le sens	Travaille sur les flux de données
Définit concepts et relations	Construit pipelines et infrastructures
Formalise les règles métier	Organise le stockage et le traitement
Conçoit des modèles de connaissances	Conçoit des modèles de données
Collabore avec les experts	Collabore avec les équipes data

Le Data Engineer garantit que les données circulent.

Le Knowledge Engineer garantit qu’elles possèdent une signification exploitable.

Knowledge Engineer et Data Scientist

Le Data Scientist cherche principalement à :

• analyser ;
• prédire ;
• classifier ;
• modéliser des régularités ;
• évaluer des modèles statistiques.

Le Knowledge Engineer cherche principalement à :

• expliciter ;
• définir ;
• relier ;
• formaliser ;
• contrôler ;
• expliquer.

Les deux approches peuvent se compléter.

Knowledge Engineer et développeur

Le développeur construit l’application.

Le Knowledge Engineer définit le modèle de connaissance que l’application doit exploiter.

Dans une petite équipe, une même personne peut occuper les deux rôles.

Knowledge Engineer et prompt engineer

Le prompt engineer travaille principalement sur les instructions fournies au modèle.

Le Knowledge Engineer travaille sur :

• les sources ;
• les concepts ;
• les relations ;
• les règles ;
• les structures ;
• les validations.

Un prompt ne remplace pas une base de connaissances bien conçue.

Knowledge Engineer et ingénieur IA

L’ingénieur IA construit et intègre les modèles.

Le Knowledge Engineer organise les connaissances utilisées par ces modèles.

Ils collaborent notamment sur :

• le RAG ;
• GraphRAG ;
• les agents ;
• les outils ;
• les évaluations ;
• les garde-fous ;
• les sources.

Les compétences conceptuelles

Comprendre la notion de connaissance

Il faut distinguer :

• donnée ;
• information ;
• connaissance ;
• compétence ;
• règle ;
• preuve ;
• hypothèse.

Modéliser

Il faut savoir transformer un domaine en :

• concepts ;
• catégories ;
• relations ;
• règles ;
• contraintes ;
• cas.

Abstraire sans déformer

Une représentation doit simplifier suffisamment pour être utile, mais pas au point de perdre le sens.

Gérer le contexte

Une règle peut dépendre :

• du pays ;
• de la date ;
• du client ;
• du produit ;
• de la situation ;
• du niveau de risque.

Les compétences méthodologiques

• conduite d’entretien ;
• observation ;
• analyse documentaire ;
• animation d’atelier ;
• construction de taxonomies ;
• modélisation d’ontologies ;
• validation ;
• gestion des versions ;
• conception de tests ;
• gouvernance.

Les compétences techniques

Selon le projet, le Knowledge Engineer peut connaître :

• Markdown ;
• tableurs ;
• SQL ;
• RDF ;
• RDFS ;
• OWL ;
• SPARQL ;
• SHACL ;
• bases graphes ;
• moteurs de règles ;
• index vectoriels ;
• API ;
• Python ou JavaScript ;
• systèmes RAG ;
• LLM.

Il n’est pas nécessaire de maîtriser tous ces outils au même niveau.

Les compétences relationnelles

Le travail dépend fortement des échanges humains.

Il faut savoir :

• écouter ;
• reformuler ;
• détecter une ambiguïté ;
• faire préciser une exception ;
• arbitrer un désaccord ;
• expliquer un modèle ;
• faciliter la validation ;
• collaborer avec plusieurs métiers.

Une journée type

Une journée peut comprendre :

• entretien avec un expert ;
• analyse de documents ;
• modification d’une taxonomie ;
• test d’une ontologie ;
• revue d’un graphe ;
• validation de règles ;
• réunion avec les développeurs ;
• analyse d’erreurs du RAG ;
• mise à jour de la documentation.

Le métier est donc à la fois analytique, technique et relationnel.

Exemple de projet

Objectif :

Construire un assistant pour le support technique.

Phase 1 — Cadrage

Le Knowledge Engineer définit :

• les utilisateurs ;
• les incidents couverts ;
• les questions ;
• les indicateurs ;
• les risques.

Phase 2 — Acquisition

Il analyse :

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

Phase 3 — Modélisation

Il construit :

Produit
Incident
Symptôme
Cause
Test
Procédure
Solution

Phase 4 — Règles

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

Phase 5 — Architecture

Documents
+
Métadonnées
+
Graphe
+
Règles
+
LLM

Phase 6 — Validation

Les techniciens testent les cas réels.

Phase 7 — Maintenance

Les erreurs signalées alimentent une boucle de correction.

Le rôle dans un projet RAG

Dans un projet RAG, le Knowledge Engineer peut intervenir sur :

• la sélection des sources ;
• la taxonomie ;
• les métadonnées ;
• le découpage ;
• le vocabulaire ;
• les questions de test ;
• les règles de citation ;
• les critères de refus ;
• l’analyse des erreurs.

Il aide à distinguer plusieurs problèmes :

• le document n’a pas été retrouvé ;
• le mauvais fragment a été sélectionné ;
• le LLM a mal interprété la source ;
• la source est ancienne ;
• une exception manque ;
• le modèle conceptuel est ambigu.

Le rôle dans GraphRAG

Dans un projet GraphRAG, il définit :

• les types d’entités ;
• les relations ;
• les propriétés ;
• les identifiants ;
• les règles de fusion ;
• les sources ;
• les contraintes ;
• les questions relationnelles.

Il vérifie que le graphe possède un sens métier, et pas seulement une structure technique.

Le rôle avec les agents IA

Un agent peut :

• rechercher ;
• interroger une base ;
• appeler un outil ;
• modifier une donnée ;
• déclencher une action.

Le Knowledge Engineer aide à définir :

• les connaissances accessibles ;
• les conditions d’action ;
• les règles ;
• les autorisations ;
• les limites ;
• les validations humaines.

Les livrables

Un projet peut produire :

• cartographie des connaissances ;
• registre des sources ;
• glossaire ;
• taxonomie ;
• ontologie ;
• dictionnaire de relations ;
• base de règles ;
• graphe ;
• jeu de tests ;
• documentation ;
• procédure de gouvernance ;
• tableau de qualité.

Exemple de fiche concept

Concept :
Session de formation

Définition :
Événement daté mettant en œuvre une formation.

Relations :
- met en œuvre une formation ;
- est animée par un formateur ;
- accueille des participants.

Contraintes :
- possède une date de début ;
- possède une capacité maximale.

Source :
Service pédagogique.

Statut :
Validé.

Exemple de fiche règle

Règle :
Un participant peut suivre une formation s’il possède le prérequis.

Conditions :
- participant identifié ;
- compétence validée ;
- niveau suffisant.

Exception :
Validation manuelle possible par le responsable pédagogique.

Source :
Règlement des formations.

Statut :
Validé.

Comment apprendre le métier ?

Étape 1 — Maîtriser les concepts

Commencer par :

• donnée, information, connaissance ;
• connaissance tacite ;
• acquisition ;
• représentation ;
• taxonomie ;
• ontologie ;
• graphe ;
• règles.

Étape 2 — Modéliser un domaine simple

Exemple :

Formation
Compétence
Participant
Prérequis
Certification

Étape 3 — Construire une taxonomie

Organiser les concepts.

Étape 4 — Ajouter les relations

Formation → développe → Compétence

Étape 5 — Formaliser quelques règles

SI niveau insuffisant
ALORS recommander une étape préparatoire.

Étape 6 — Tester avec des cas

Utiliser des situations réelles.

Étape 7 — Découvrir les technologies

• RDF ;
• OWL ;
• SPARQL ;
• SHACL ;
• base graphe ;
• index vectoriel.

Étape 8 — Construire un petit RAG

Relier un corpus de documents à un LLM.

Étape 9 — Ajouter un graphe

Créer quelques entités et relations utiles.

Étape 10 — Documenter

Conserver :

• sources ;
• choix ;
• tests ;
• limites ;
• versions.

Projet d’apprentissage conseillé

Construire une petite base sur un sujet maîtrisé.

Exemple :

Représenter un catalogue de formations et recommander un parcours selon les compétences.

Livrables :

1. glossaire ;
2. taxonomie ;
3. ontologie légère ;
4. graphe ;
5. cinq règles ;
6. vingt cas de test ;
7. documentation.

Qualités importantes

• précision ;
• curiosité ;
• capacité d’analyse ;
• rigueur ;
• écoute ;
• esprit de synthèse ;
• sens du contexte ;
• capacité à détecter les ambiguïtés ;
• attention aux sources ;
• goût de la modélisation.

Difficultés du métier

L’expertise est difficile à verbaliser

Les professionnels ne savent pas toujours expliquer ce qu’ils savent.

Les experts peuvent être en désaccord

Le modèle doit parfois conserver plusieurs points de vue.

Les sources se contredisent

Il faut gérer les versions et les contextes.

La modélisation simplifie

Il faut éviter de déformer le domaine.

Les besoins changent

Le modèle doit évoluer.

Les outils peuvent imposer leur logique

Le Knowledge Engineer doit préserver le besoin métier.

La qualité est difficile à mesurer

Il faut construire des tests concrets.

Erreurs fréquentes

Se concentrer uniquement sur la technologie

Le métier commence par la compréhension du domaine.

Construire une ontologie trop vaste

Le modèle devient inutilisable.

Interroger un seul expert

Le résultat peut être biaisé.

Formaliser sans cas réels

Les règles deviennent abstraites.

Oublier les sources

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

Confondre plausible et exact

Une proposition de LLM doit être validée.

Ne pas prévoir la maintenance

Le système devient obsolète.

Négliger l’expérience utilisateur

La connaissance structurée doit rester accessible.

À retenir

1. Le Knowledge Engineer transforme l’expertise en structures exploitables.
2. Il travaille entre les experts métier et les équipes techniques.
3. Il recueille les connaissances tacites et explicites.
4. Il construit des vocabulaires, taxonomies, ontologies et graphes.
5. Il formalise les règles et les exceptions.
6. Il définit les questions auxquelles le système doit répondre.
7. Il organise les tests, la validation et la gouvernance.
8. Il intervient dans les projets RAG, GraphRAG et agents IA.
9. Son rôle diffère de celui du Data Engineer et du Knowledge Manager.
10. Le métier demande des compétences conceptuelles, techniques et relationnelles.
11. Les sources et la traçabilité sont centrales.
12. La maintenance fait partie intégrante du travail.

Vérifiez votre compréhension

Quelle est la mission principale du Knowledge Engineer ?

Transformer les connaissances d’un domaine en modèles utilisables par des humains et des systèmes.

Pourquoi conduit-il des entretiens ?

Pour recueillir l’expertise et faire apparaître les critères implicites.

Quelle différence existe-t-il avec un Data Engineer ?

Le Data Engineer construit les flux de données. Le Knowledge Engineer formalise leur sens et leurs relations.

Quel rôle joue-t-il dans un RAG ?

Il structure les sources, le vocabulaire, les métadonnées, les règles et les tests.

Doit-il savoir programmer ?

La programmation est utile pour l’implémentation, mais la modélisation et l’analyse métier sont également centrales.

Pourquoi organise-t-il la gouvernance ?

Pour assurer la validation, la mise à jour et la responsabilité des connaissances.

Questions fréquentes

Knowledge Engineer est-il un métier informatique ?

Il comporte une forte dimension informatique, mais également des dimensions métier, documentaire et cognitive.

Faut-il être expert du domaine traité ?

Il n’a pas besoin de remplacer l’expert métier, mais il doit comprendre suffisamment le domaine pour le modéliser correctement.

Quelle formation suivre ?

Les parcours peuvent venir de l’informatique, de la gestion de l’information, de l’intelligence artificielle, de la linguistique ou d’un métier spécialisé.

Le métier est-il lié aux LLM ?

Oui. Les LLM renforcent le besoin de structurer les sources, relations et règles qu’ils utilisent.

Peut-on exercer ce rôle dans une petite entreprise ?

Oui. Le rôle peut être assumé par un développeur, un documentaliste, un consultant ou un expert métier formé à la modélisation.

Quelle est la première compétence à développer ?

Apprendre à identifier précisément les concepts, les relations, les règles et les exceptions d’un domaine.

Terminer le parcours

Étape précédente

Cas d’usage du Knowledge Engineering

Revenir au parcours complet

Voir les 16 étapes du parcours Knowledge Engineering

Revenir à l’accueil

Knowledge Engineering : transformer la connaissance en intelligence exploitable