Cas d’usage du Knowledge Engineering : à quoi sert l’ingénierie des connaissances ?

Le Knowledge Engineering devient utile lorsqu’une activité dépend de connaissances dispersées, complexes ou difficiles à transmettre.

Ces connaissances peuvent se trouver dans :

• les documents ;
• les bases de données ;
• l’expérience des professionnels ;
• les procédures ;
• les réglementations ;
• les logiciels ;
• les échanges entre équipes.

L’ingénierie des connaissances cherche à rendre ces savoirs explicites, structurés, interrogeables et réutilisables.

Elle peut permettre à un système de :

• répondre à une question ;
• recommander une action ;
• expliquer une décision ;
• diagnostiquer un problème ;
• contrôler une conformité ;
• retrouver un expert ;
• construire un parcours ;
• relier plusieurs sources ;
• alimenter un LLM.

Un cas d’usage de Knowledge Engineering apparaît lorsqu’il ne suffit plus de retrouver un document : il faut comprendre comment les informations sont reliées et comment elles doivent être appliquées.

Ce que vous allez comprendre

À la fin de cet article, vous saurez :

• reconnaître un bon cas d’usage ;
• distinguer recherche documentaire et exploitation des connaissances ;
• comprendre les applications dans différents secteurs ;
• identifier les concepts, relations et règles nécessaires ;
• déterminer le niveau de structuration adapté ;
• évaluer la valeur d’un projet ;
• éviter les cas d’usage artificiellement complexes.

Comment reconnaître un bon cas d’usage ?

Un projet est particulièrement pertinent lorsque plusieurs conditions sont réunies.

Les connaissances sont dispersées

Les informations se trouvent dans :

• plusieurs documents ;
• plusieurs bases ;
• plusieurs équipes ;
• plusieurs logiciels ;
• l’expérience de quelques spécialistes.

Les relations sont importantes

La réponse dépend de plusieurs liens.

Exemple :

Produit
  → couvert par → Contrat
  → concerne → Client
  → soumis à → Niveau de service

Les règles doivent être appliquées

Exemple :

SI le contrat est expiré
ALORS la garantie standard ne s’applique pas.

Les exceptions sont nombreuses

La procédure générale ne suffit pas.

La connaissance risque d’être perdue

Quelques experts détiennent l’essentiel du savoir.

Les erreurs sont coûteuses

Une mauvaise décision peut provoquer :

• un risque juridique ;
• une panne ;
• un retard ;
• une perte financière ;
• une atteinte à la sécurité ;
• une mauvaise orientation.

Les réponses doivent être expliquées

L’utilisateur doit connaître :

• les faits utilisés ;
• les règles appliquées ;
• les sources ;
• les limites.

Cas d’usage 1 — Support technique

Un service de support doit traiter de nombreux incidents.

Les connaissances sont réparties dans :

• les manuels ;
• les procédures ;
• les historiques ;
• les messages ;
• l’expérience des techniciens ;
• les bases produits.

Concepts

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

Relations

Un incident concerne un produit.

Un symptôme peut indiquer une cause.

Un test confirme ou écarte une cause.

Une procédure traite une cause.

Un technicien possède une compétence.

Règles

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

SI le redémarrage a échoué
ET si la ligne est active
ALORS vérifier la configuration.

Fonctionnement possible

1. Le technicien décrit le symptôme.
2. Le système identifie le produit.
3. Il recherche des incidents similaires.
4. Il propose les causes possibles.
5. Il recommande un test.
6. Il affiche la procédure.
7. Il cite la source.
8. Il indique quand transmettre au niveau supérieur.

Valeur produite

• réduction du temps de diagnostic ;
• homogénéisation des réponses ;
• transmission de l’expertise ;
• diminution des erreurs ;
• meilleure formation des débutants.

Cas d’usage 2 — Maintenance industrielle

Une usine doit relier :

• les machines ;
• les composants ;
• les capteurs ;
• les incidents ;
• les opérations ;
• les fournisseurs ;
• les techniciens.

Graphe possible

Machine A
  ├── contient → Pompe 12
  ├── produit → Vibration anormale
  ├── a subi → Incident 458
  └── entretenue par → Technicien Paul

Connaissances

Une vibration à haute fréquence peut indiquer une usure du roulement.

Une augmentation simultanée de la température renforce cette hypothèse.

Applications

• diagnostic ;
• planification de la maintenance ;
• recherche d’incidents similaires ;
• identification des pièces ;
• analyse des causes ;
• transfert de compétences.

Cas d’usage 3 — Gestion des compétences

Une organisation souhaite connaître :

• les compétences disponibles ;
• les niveaux ;
• les besoins ;
• les formations ;
• les certifications ;
• les postes ;
• les experts.

Relations

Personne → possède → Compétence

Poste → exige → Compétence

Formation → développe → Compétence

Certification → valide → Compétence

Questions traitées

• qui possède la compétence nécessaire ?
• quelles compétences manquent dans l’équipe ?
• quelle formation réduit cet écart ?
• qui peut encadrer un débutant ?
• quels postes sont accessibles à une personne ?

Cas d’usage 4 — Recommandation de formation

Un système peut construire un parcours à partir des prérequis.

Faits

Marie possède le niveau débutant.

Formation intermédiaire exige le niveau débutant.

Formation avancée exige le niveau intermédiaire.

Certification X exige le niveau avancé.

Résultat

Marie
  ↓
Formation intermédiaire
  ↓
Formation avancée
  ↓
Certification X

Le système ne recommande pas seulement des contenus similaires.

Il construit un chemin fondé sur les connaissances et les contraintes.

Cas d’usage 5 — Recherche juridique

La recherche juridique nécessite de relier :

• les textes ;
• les articles ;
• les décisions ;
• les juridictions ;
• les dates ;
• les notions ;
• les faits ;
• les exceptions.

Graphe possible

Décision → interprète → Article

Article → appartient à → Code

Décision → rendue par → Juridiction

Règle → comporte → Exception

Questions possibles

• quelle règle s’applique à cette situation ?
• quelles décisions interprètent cet article ?
• la décision est-elle antérieure à une réforme ?
• quelles exceptions ont été reconnues ?
• quelles sources justifient la réponse ?

Le Knowledge Engineering ne remplace pas l’analyse juridique.

Il structure les éléments nécessaires à cette analyse.

Cas d’usage 6 — Conformité réglementaire

Une organisation doit relier :

• les obligations ;
• les activités ;
• les contrôles ;
• les documents ;
• les personnes responsables ;
• les dates ;
• les preuves.

Relations

Obligation → s’applique à → Activité

Activité → réalisée par → Service

Contrôle → vérifie → Obligation

Document → prouve → Contrôle

Responsable → supervise → Activité

Questions

• quelles obligations concernent ce service ?
• quelles preuves sont manquantes ?
• quelle règle expire prochainement ?
• qui doit effectuer le contrôle ?
• quels documents sont obsolètes ?

Cas d’usage 7 — Santé

Dans un domaine médical, les connaissances peuvent représenter :

• les symptômes ;
• les pathologies ;
• les examens ;
• les traitements ;
• les interactions ;
• les contre-indications ;
• les protocoles.

Exemple conceptuel

Symptôme → peut indiquer → Pathologie

Examen → confirme ou écarte → Pathologie

Traitement → traite → Pathologie

Traitement → contre-indiqué avec → Condition

Les usages possibles comprennent :

• aide à la recherche ;
• orientation ;
• vérification de protocoles ;
• recherche de littérature ;
• détection d’interactions.

Les décisions critiques nécessitent des connaissances validées et une supervision adaptée.

Cas d’usage 8 — Recherche scientifique

Un graphe scientifique peut relier :

• les auteurs ;
• les articles ;
• les institutions ;
• les méthodes ;
• les résultats ;
• les jeux de données ;
• les concepts.

Relations

Auteur → écrit → Article

Article → utilise → Méthode

Article → analyse → Jeu de données

Article → soutient → Hypothèse

Article → contredit → Résultat

Questions

• quels articles utilisent cette méthode ?
• quels résultats sont contradictoires ?
• quelles institutions travaillent sur ce thème ?
• quels jeux de données sont réutilisés ?
• quelles communautés de recherche apparaissent ?

Cas d’usage 9 — Intelligence économique

Une organisation peut relier :

• les entreprises ;
• les dirigeants ;
• les produits ;
• les marchés ;
• les partenariats ;
• les acquisitions ;
• les événements ;
• les sources.

Exemple

Entreprise Alpha → acquiert → Entreprise Beta

Entreprise Beta → développe → Technologie X

Technologie X → cible → Marché Y

Le système peut détecter des relations indirectes et reconstruire une évolution.

Cas d’usage 10 — Relation client

Une base de connaissances peut relier :

• les clients ;
• les produits ;
• les contrats ;
• les incidents ;
• les demandes ;
• les solutions ;
• les engagements.

Question

Quel niveau de service s’applique à cet incident ?

Le système doit suivre :

Incident
  → concerne → Produit
  → couvert par → Contrat
  → définit → Niveau de service

La réponse dépend de plusieurs entités et documents.

Cas d’usage 11 — Commerce électronique

Un catalogue riche peut représenter :

• les produits ;
• les catégories ;
• les marques ;
• les caractéristiques ;
• les compatibilités ;
• les usages ;
• les alternatives.

Relations

Produit → appartient à → Catégorie

Produit → fabriqué par → Marque

Produit → compatible avec → Accessoire

Produit → adapté à → Usage

Applications

• filtres intelligents ;
• comparaison ;
• recommandation ;
• recherche conversationnelle ;
• détection de compatibilité ;
• enrichissement SEO.

Cas d’usage 12 — Gestion documentaire

Une organisation peut enrichir ses documents avec :

• les auteurs ;
• les sujets ;
• les produits ;
• les clients ;
• les dates ;
• les versions ;
• les réglementations ;
• les concepts.

Exemple

Document 458
  ├── concerne → Produit X200
  ├── remplace → Document 312
  ├── rédigé par → Équipe support
  └── valide jusqu’au → 31 décembre 2026

Le système peut alors éviter de proposer une ancienne version.

Cas d’usage 13 — Assistant interne

Un assistant interne peut combiner :

• les documents ;
• la taxonomie ;
• le graphe ;
• les règles ;
• les droits ;
• un LLM.

Question

Quelle procédure doit suivre un commercial pour faire valider une remise exceptionnelle ?

Le système doit identifier :

• le montant ;
• le type de client ;
• la marge ;
• le niveau d’autorisation ;
• le responsable ;
• la procédure ;
• les exceptions.

Un simple chatbot documentaire risque de retrouver un texte sans appliquer correctement les conditions.

Cas d’usage 14 — Transmission de l’expertise

Une organisation risque de perdre l’expertise d’un professionnel expérimenté.

Le projet peut recueillir :

• les critères ;
• les cas ;
• les erreurs fréquentes ;
• les exceptions ;
• les signaux faibles ;
• les procédures réelles.

Les connaissances peuvent ensuite être transformées en :

• guide ;
• base de cas ;
• graphe ;
• règles ;
• parcours pédagogique ;
• assistant.

Cas d’usage 15 — SEO et architecture éditoriale

Le Knowledge Engineering peut également structurer un site.

Il peut représenter :

• les sujets ;
• les concepts ;
• les relations ;
• les prérequis ;
• les intentions ;
• les pages ;
• les liens internes.

Exemple

Ontologie
  ├── est une forme de → Représentation des connaissances
  ├── structure → Graphe de connaissances
  └── utilise souvent → OWL

Cette structure aide à construire :

• une architecture éditoriale ;
• un maillage logique ;
• des parcours pédagogiques ;
• un glossaire ;
• des pages comparatives ;
• des contenus complémentaires.

Choisir le niveau de complexité

Tous les cas d’usage ne nécessitent pas une ontologie ou GraphRAG.

Niveau 1 — Documentation

Utiliser lorsque :

• les réponses se trouvent dans quelques pages ;
• les relations sont simples ;
• les règles sont limitées.

Niveau 2 — Taxonomie et métadonnées

Utiliser lorsque :

• le volume augmente ;
• les filtres sont nécessaires ;
• le vocabulaire doit être harmonisé.

Niveau 3 — RAG

Utiliser lorsque :

• l’utilisateur veut poser des questions ;
• les documents sont nombreux ;
• une recherche sémantique est utile.

Niveau 4 — Graphe et règles

Utiliser lorsque :

• les relations sont centrales ;
• les décisions dépendent de plusieurs étapes ;
• les règles doivent être contrôlées.

Niveau 5 — Architecture hybride

Utiliser lorsque :

• documents, graphes, règles et génération doivent coopérer ;
• les réponses sont critiques ;
• les explications sont obligatoires.

Matrice de sélection

Caractéristique	Solution probable
Réponse dans un document précis	Recherche documentaire
Vocabulaire complexe	Taxonomie ou ontologie
Nombreux synonymes	Thésaurus
Relations entre plusieurs entités	Graphe
Décisions conditionnelles	Moteur de règles
Recherche en langage naturel	RAG
Questions traversant plusieurs documents	GraphRAG
Besoin d’explication	Graphe et règles
Données fortement structurées	Base de données
Corpus très variable	Recherche vectorielle

Évaluer la valeur

La réussite doit être mesurée.

Indicateurs possibles

• temps de recherche ;
• taux de réponses correctes ;
• nombre d’erreurs ;
• taux de résolution ;
• nombre de transmissions ;
• couverture des cas ;
• temps de formation ;
• fraîcheur des connaissances ;
• taux d’utilisation ;
• satisfaction.

Exemple avant-après

Avant :

15 minutes pour retrouver une procédure.

Après :

2 minutes avec une réponse sourcée.

Le bénéfice est mesurable.

Risques

Automatiser une mauvaise pratique

Une règle existante n’est pas nécessairement correcte.

Simplifier l’expertise

Le système peut perdre les nuances.

Utiliser des sources anciennes

La réponse devient obsolète.

Confondre recommandation et décision

Le système ne doit pas toujours décider seul.

Créer une architecture disproportionnée

Le coût dépasse la valeur.

Oublier les utilisateurs

Le système répond techniquement mais reste inutilisable.

Ne pas organiser la maintenance

Les connaissances deviennent rapidement fausses.

Méthode de sélection d’un premier cas d’usage

Choisissez un problème :

• fréquent ;
• limité ;
• mesurable ;
• fondé sur des sources disponibles ;
• validable par des experts ;
• suffisamment important ;
• sans risque incontrôlé.

Exemple adapté :

Recommander la bonne procédure pour cinq types d’incidents fréquents.

Exemple trop large :

Automatiser toute la connaissance de l’entreprise.

À retenir

1. Le Knowledge Engineering est utile lorsque la connaissance est dispersée ou complexe.
2. Les cas d’usage reposent souvent sur des concepts, relations et règles.
3. Le support technique constitue un cas fréquent.
4. Les graphes sont utiles pour les relations entre plusieurs entités.
5. Les moteurs de règles conviennent aux décisions explicites.
6. Le RAG convient à la recherche documentaire conversationnelle.
7. GraphRAG devient pertinent pour les questions relationnelles ou globales.
8. Tous les projets ne nécessitent pas une ontologie.
9. La valeur doit être mesurée par des indicateurs opérationnels.
10. Un premier projet doit rester limité et validable.
11. Les sources, dates et responsabilités doivent être conservées.
12. Le système doit souvent assister le professionnel plutôt que le remplacer.

Vérifiez votre compréhension

Quand un projet de Knowledge Engineering devient-il pertinent ?

Lorsque les connaissances sont dispersées, relationnelles, difficiles à transmettre ou soumises à des règles.

Quel cas d’usage nécessite souvent un graphe ?

Un cas où la réponse dépend de plusieurs entités et relations.

Quand un moteur de règles est-il utile ?

Lorsque des conditions explicites doivent produire une conclusion contrôlée.

Un RAG suffit-il pour appliquer des règles complexes ?

Pas toujours. Il peut être complété par un modèle de connaissances et un moteur de règles.

Comment mesurer la valeur ?

Avec des indicateurs comme le temps de recherche, l’exactitude ou le taux de résolution.

Pourquoi commencer par un périmètre limité ?

Pour tester la valeur et réduire les risques.

Questions fréquentes

Quels secteurs utilisent le Knowledge Engineering ?

Tout secteur dépendant de connaissances complexes peut l’utiliser : industrie, droit, santé, formation, commerce, recherche ou support.

Faut-il disposer de millions de documents ?

Non. Un petit corpus critique peut justifier un projet.

Le Knowledge Engineering est-il réservé aux grandes entreprises ?

Non. Une petite organisation peut commencer avec une taxonomie, des règles et une documentation structurée.

Un LLM suffit-il pour construire un assistant métier ?

Pas toujours. Les sources, règles, droits et validations doivent également être organisés.

Quel est le meilleur premier cas d’usage ?

Un problème fréquent, limité, mesurable et validable.

Un système doit-il prendre la décision finale ?

Cela dépend du risque. Dans de nombreux cas, il doit fournir une recommandation explicable à un humain.

Continuer le parcours

Étape précédente

Outils de Knowledge Engineering

Étape suivante

La dernière étape présente le rôle de la personne chargée d’organiser la transformation de l’expertise en système de connaissances.

➡️ Knowledge Engineer : métier, missions et compétences

Revenir au sommaire

Voir le parcours complet de Knowledge Engineering